JP7735734B2 - 情報処理装置およびプログラム - Google Patents

Description

本発明は、情報処理装置およびプログラムに関する。

特許文献１には、ユーザの活動状態が第１の状態と決定された場合、操作対象を第１の操作で操作させるための第１の操作入力方式を選定し、ユーザの活動状態が第２の状態と決定された場合、操作対象を第１の操作とは異なる第２の操作で操作させるための第２の操作入力方式を選定する処理が開示されている。
特許文献２には、現在時刻から行動開始時刻までの時間が所定時間に達すると、記憶したスケジュールデータをユーザに対して通知する処理が開示されている。
特許文献３には、出発地から目的地までの行動予定を生成し、その行動予定に基づいて表示制御部及び第１表示部に道案内表示を行わせる処理が開示されている。

特開２０１７－１２０５５０号公報 特開２００２－１０８８２９号公報 特開２００８－７７３１１号公報

ユーザの周囲に存在する物や、この物とは異なる場所に存在する物についての情報をユーザに提示することで、ユーザの周囲に存在する物や、この物とは異なる場所に存在する物についての情報をユーザは知ることができるようになる。
この場合、物に対して予め対応付けられている情報をユーザに提示するだけでは、ユーザの各々に対して、共通の情報が一律に提示されることになる。
本発明の目的は、ユーザの予定情報を用い、物についての情報の提示に関する決定を行ったうえで、ユーザに対し、物についての情報が提示されるようにすることにある。

請求項１に記載の発明は、プロセッサを有する情報処理装置であって、前記プロセッサは、ユーザの周辺の状況が写っている映像に基づき、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第１物が存在することを特定し、前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第１物についての情報である第１物情報の前記ユーザへの提示に関する決定を行い、前記第１物は、前記予定情報に含まれない物である、情報処理装置である。
請求項２に記載の発明は、前記プロセッサは、前記予定情報に基づき、前記第１物情報の前記ユーザへの提示の有無についての決定、及び／又は、前記ユーザに提示される前記第１物情報の内容の決定を行う請求項１に記載の情報処理装置である。
請求項３に記載の発明は、前記プロセッサは、前記予定情報が予め定められた条件を満たす場合、前記第１物情報に、前記第１物のキャンペーン情報が含まれるように制御する請求項１に記載の情報処理装置である。
請求項４に記載の発明は、プロセッサを有する情報処理装置であって、前記プロセッサは、ユーザの周辺の状況が写っている映像、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第２物が存在することを特定し、前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第２物と予め定められた関係にある第１物であって、前記第２物とは異なる場所に存在する第１物についての第１物情報の前記ユーザへの提示に関する決定を行い、前記第１物は、前記予定情報に含まれない物である、情報処理装置である。
請求項５に記載の発明は、前記プロセッサは、前記予定情報が予め定められた条件を満たす場合、前記第１物情報に前記第１物のキャンペーンの情報が含まれるよう制御し、前記予定情報が予め定められた条件を満たさない場合、前記第１物情報に、前記第１物のキャンペーンの情報が含まれないよう制御する、請求項１又は４に記載の情報処理装置である。
請求項６に記載の発明は、前記プロセッサは、前記ユーザの視界内に存在する前記第２物についての第２物情報が前記ユーザに提示される際に、前記第１物情報も前記ユーザに提示されるよう制御する請求項４に記載の情報処理装置である。
請求項７に記載の発明は、前記プロセッサは、前記第１物情報が、前記ユーザに見えている前記第１物に重ならないように前記ユーザに提示されるよう制御する請求項１に記載の情報処理装置である。
請求項８に記載の発明は、前記プロセッサは、前記第１物情報が、前記ユーザに見えている前記第２物に重ならないように前記ユーザに提示されるよう制御する請求項４に記載の情報処理装置である。
請求項９に記載の発明は、前記プロセッサは、前記第１物についての第１物情報の前記ユーザへの提示に関する決定を行う、請求項４に記載の情報処理装置である。
請求項１０に記載の発明は、前記プロセッサは、前記第２物情報として、前記第１物の利用を条件として有効となる、前記第２物のキャンペーンの情報が前記ユーザに提示されるよう制御する、請求項６に記載の情報処理装置である。
請求項１１に記載の発明は、前記ユーザに提示される前記第２物情報は、前記第２物にて提供されるサービスの予約を促す、請求項６に記載の情報処理装置である。
請求項１２に記載の発明は、前記プロセッサは、前記第１物情報として、前記第２物の利用を条件として有効となる、前記第１物のキャンペーンの情報が提示されるよう制御する請求項４に記載の情報処理装置である。
請求項１３に記載の発明は、前記ユーザに提示される前記第１物情報は、前記第１物にて提供されるサービスの予約を促す請求項１又は４に記載の情報処理装置である。
請求項１４に記載の発明は、前記プロセッサは、前記第２物に対して複数の物が関連付けられている場合、前記第２物の状況情報に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置である。
請求項１５に記載の発明は、前記プロセッサは、前記第２物に対して複数の物が関連付けられている場合、前記複数の物の各々の状況情報に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置である。
請求項１６に記載の発明は、前記プロセッサは、前記第２物に対して複数の物が関連付けられている場合、前記複数の物の各々に対するユーザの関心度に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置である。
請求項１７に記載の発明は、前記プロセッサは、前記予定情報として、前記第１物の近くを通りかかった前記ユーザの次の予定の場所および開始時刻についての情報を取得し、前記予定情報として取得した前記次の予定の場所および開始時刻と、前記第１物の次の予約開始時刻とに基づき、前記ユーザが前記第１物を利用した場合における利益又は不利益であって前記第１物の提供者側にとっての利益又は不利益を決定し、決定した前記利益又は不利益に基づき、前記第１物情報の前記ユーザへの提示に関する決定を行う、請求項１に記載の情報処理装置である。
請求項１８に記載の発明は、前記プロセッサは、前記利益又は不利益として、前記ユーザの前記第１物の予測利用時間を決定する請求項１７に記載の情報処理装置である。
請求項１９に記載の発明は、前記予定情報は、前記ユーザの予定の種類を含み、前記プロセッサは、前記種類に基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う、請求項１又は４に記載の情報処理装置である。
請求項２０に記載の発明は、前記予定情報は、前記ユーザの予定に関連する人物の情報を含み、前記プロセッサは、前記人物の数に基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う、請求項１又は４に記載の情報処理装置である。
請求項２１に記載の発明は、前記プロセッサは、前記予定情報として、少なくとも、前記ユーザの予定の開催場所と開始時刻とを取得し、現在時刻から前記開始時刻までの残り時間と、現在地から前記開催場所への移動に要する時間である所要時間とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項１又は４に記載の情報処理装置である。
請求項２２に記載の発明は、前記プロセッサは、取得した前記予定情報と前記第１物の状況情報とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項１又は４に記載の情報処理装置である。
請求項２３に記載の発明は、前記プロセッサは、取得した前記予定情報と前記第２物の状況情報とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項４に記載の情報処理装置である。
請求項２４に記載の発明は、前記情報処理装置は、前記ユーザとともに移動するカメラにより得られた映像を基に、前記ユーザの周囲に存在する物を特定する請求項１又は４に記載の情報処理装置である。
請求項２５に記載の発明は、前記情報処理装置は、前記ユーザとともに移動する移動装置であり、前記プロセッサは、前記ユーザの現在地と前記ユーザが向いている方角とに基づき、前記ユーザの周辺に存在する物を特定する請求項１又は４に記載の情報処理装置である。
請求項２６に記載の発明は、前記情報処理装置は、前記ユーザの眼球の前に装着される装置である、請求項１又は４に記載の情報処理装置である。
請求項２７に記載の発明は、前記情報処理装置は、透視可能なディスプレイを有し、前記プロセッサは、前記ディスプレイを介して前記ユーザが視認する現実空間の現実物に前記第１物情報を対応付ける、請求項２６に記載の情報処理装置である。
請求項２８に記載の発明は、前記プロセッサは、前記第１物の周辺に存在する複数のユーザ各々の予定についての情報を前記予定情報として取得し、前記予定情報に基づいて、前記複数のユーザの中から特定の条件を満たすユーザを特定し、特定したユーザを、前記第１物情報を提示する先となるユーザとして決定する、請求項１に記載の情報処理装置である。
請求項２９に記載の発明は、前記プロセッサは、前記第２物の周辺に存在する前記複数のユーザ各々の予定についての情報を前記予定情報として取得し、前記予定情報に基づいて、前記複数のユーザの中から特定の条件を満たすユーザを特定し、特定したユーザを、前記第１物情報を提示する先となるユーザとして決定する、請求項４に記載の情報処理装置である。
請求項３０に記載の発明は、前記情報処理装置は、前記ユーザとともに移動する移動装置と通信を行い、前記プロセッサは、前記移動装置のディスプレイに前記第１物情報が表示されるよう制御する請求項１又は４に記載の情報処理装置である。
請求項３１に記載の発明は、ユーザの周辺の状況が写っている映像に基づき、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第１物が存在することを特定する機能と、前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第１物についての情報である第１物情報の前記ユーザへの提示に関する決定を行う機能と、をコンピュータに実現させるためのプログラムであり、
前記第１物は、前記予定情報に含まれない物である、プログラムである。
請求項３２に記載の発明は、ユーザの周辺の状況が写っている映像、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第２物が存在することを特定する機能と、前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第２物と予め定められた関係にある第１物であって、前記第２物とは異なる場所に存在する第１物についての第１物情報の前記ユーザへの提示に関する決定を行う機能と、をコンピュータに実現させるためのプログラムであり、前記第１物は、前記予定情報に含まれない物である、プログラムである。

請求項１の発明によれば、ユーザの予定情報を用い、物についての情報の提示に関する決定を行ったうえで、ユーザに対し、物についての情報が提示されるようにすることができる。
請求項２の発明によれば、予定情報に基づき、第１物情報のユーザへの提示の有無についての決定や、ユーザに提示される第１物情報の内容の決定を行うことができる。
請求項３の発明によれば、予定情報が予め定められた条件を満たす場合に、第１物情報に、第１物のキャンペーン情報が含まれるようにすることができる。
請求項４の発明によれば、ユーザの予定情報を用い、物についての情報の提示に関する決定を行ったうえで、ユーザに対し、物についての情報が提示されるようにすることができる。
請求項５の発明によれば、予定情報が予め定められた条件を満たす場合、第１物情報に第１物のキャンペーンの情報が含まれるようにすることができ、予定情報が予め定められた条件を満たさない場合、第１物情報に、第１物のキャンペーンの情報が含まれないようにすることができる。
請求項６の発明によれば、ユーザの視界内に存在する第２物についての第２物情報がユーザに提示される際に、第１物情報もユーザに提示されるようにすることができる。
請求項７の発明によれば、第１物情報が、ユーザに見えている第１物に重ならないようにユーザに提示されるようにすることができる。
請求項８の発明によれば、第１物情報が、ユーザに見えている第２物に重ならないようにユーザに提示されるようにすることができる。
請求項９の発明によれば、第１物についての第１物情報のユーザへの提示に関する決定を行ったうえで、第１物情報のユーザへの提示を行える。
請求項１０の発明によれば、第１物の利用を条件として有効となる、第２物のキャンペーンの情報をユーザに提示されるようにすることができる。
請求項１１の発明によれば、ユーザに提示される第２物情報として、第２物にて提供されるサービスの予約を促す情報を提示できる。
請求項１２の発明によれば、第１物情報として、第２物の利用を条件として有効となる、第１物のキャンペーンの情報が提示されるようにすることができる。
請求項１３の発明によれば、ユーザに提示される第１物情報を、第１物にて提供されるサービスの予約を促す情報とすることができる。
請求項１４の発明によれば、第２物に対して複数の物が関連付けられている場合に、第２物の状況情報に基づき、第１物を複数の物の中から決定することができる。
請求項１５の発明によれば、第２物に対して複数の物が関連付けられている場合、この複数の物の各々の状況情報に基づき、第１物を複数の物の中から決定することができる。
請求項１６の発明によれば、第２物に対して複数の物が関連付けられている場合、この複数の物の各々に対するユーザの関心度に基づき、第１物をこの複数の物の中から決定することができる。
請求項１７の発明によれば、ユーザが第１物を利用した場合の利益又は不利益であって第１物の提供者側にとっての利益又は不利益に基づき、第１物情報のユーザへの提示に関する決定を行うことができる。
請求項１８の発明によれば、ユーザの第１物の予測利用時間に基づき、第１物情報のユーザへの提示に関する決定を行うことができる。
請求項１９の発明によれば、ユーザの予定の種類に基づき、第１物情報のユーザに対する提示に関する決定を行うことができる。
請求項２０の発明によれば、ユーザの予定に関連する人物についての情報に基づき、第１物情報のユーザに対する提示に関する決定を行うことができる。
請求項２１の発明によれば、現在時刻からインベントの開始時刻までの残り時間と、現在地から予定の開催場所への移動に要する時間である所要時間とに基づき、第１物情報のユーザに対する提示に関する決定を行うことができる。
請求項２２の発明によれば、ユーザの予定情報と第１物の状況情報とに基づき、第１物情報のユーザに対する提示に関する決定を行うことができる。
請求項２３の発明によれば、ユーザの予定情報と第２物の状況情報とに基づき、第１物情報のユーザに対する提示に関する決定を行うことができる。
請求項２４の発明によれば、ユーザとともに移動するカメラにより得られた映像を基に、ユーザの周囲に存在する物を特定することができる。
請求項２５の発明によれば、ユーザの現在地とユーザが向いている方角とに基づき、ユーザの周辺に存在する物を特定することができる。
請求項２６の発明によれば、情報処理装置を、ユーザの眼球の前に装着される装置とすることができる。
請求項２７の発明によれば、ディスプレイを介してユーザが視認する現実空間の現実物に第１物情報を対応付けることができる。
請求項２８の発明によれば、第１物の周辺に存在する複数のユーザのうちの特定の条件を満たすユーザへの第１物情報の提示を行える。
請求項２９の発明によれば、第２物の周辺に存在する複数のユーザのうちの特定の条件を満たすユーザへの第１物情報の提示を行える。
請求項３０の発明によれば、ユーザとともに移動する移動装置に、第１物情報が表示されるようにすることができる。
請求項３１の発明によれば、ユーザの予定情報を用い、物についての情報の提示に関する決定を行ったうえで、ユーザに対し、物についての情報が提示されるようにすることができる。
請求項３２の発明によれば、ユーザの予定情報を用い、物についての情報の提示に関する決定を行ったうえで、ユーザに対し、物についての情報が提示されるようにすることができる。

情報処理システムの構成例を示した図である。 外部サーバのハードウエアの構成の一例を示したである。 ユーザの端末装置のディスプレイに表示される表示画面を説明する図である。 ユーザの端末装置のディスプレイに表示される表示画面を説明する図である。 ユーザの端末装置のディスプレイに表示される表示画面を説明する図である。 周辺物情報の表示レベルを説明する図である。 周辺物情報の表示レベルを説明する図である。 周辺物情報の表示レベルを説明する図である。 端末装置の表示画面における他の表示例を示した図である。 端末装置の表示画面における他の表示例を示した図である。 端末装置の表示画面における他の表示例を示した図である。 ユーザの端末装置における他の表示例を示した図である。 ユーザの端末装置における他の表示例を示した図である。 端末装置のハードウエアの構成を示した図である。 本実施形態にて実行される処理の流れの一例を示したフローチャートである。 他の処理例を示したフローチャートである。 他の処理例を示したフローチャートである。 他の処理例を示したフローチャートである。 他の処理例を示したフローチャートである。 ユーザの移動経路を示した図である。 ユーザの移動経路を示した図である。 端末装置における他の表示例を示した図である。 端末装置における他の表示例を示した図である。 端末装置における他の表示例を示した図である。 端末装置における他の表示例を示した図である。 端末装置における他の表示例を示した図である。 次の予定までに予め定められた閾値以上の時間的な余裕があるユーザが、周辺物まで歩いてきた場合における表示例を示した図である。 端末装置における他の表示例である。 処理の流れを示したフローチャートである。 ＣＰＵが参照するデータベースを示した図である。

以下、添付図面を参照して、本発明の実施の形態について詳細に説明する。
図１は、本実施形態の情報処理システム１の構成例を示した図である。
本実施形態では、複数の情報処理装置がシステムとして連携している。具体的には、ユーザが有する端末装置２００、および、端末装置２００と情報の通信を行う外部サーバ１００とが設けられている。
本実施形態では、インターネット回線などの通信回線を介して、端末装置２００と、外部サーバ１００とが接続される。
図１に示す例では、端末装置２００の例として眼鏡型の端末装置２００Ａと手首装着型の端末装置２００Ｂがユーザに装着されている。なお、図１では端末装置２００はユーザに装着されているが、端末装置２００はユーザに装着される端末装置に限定されるものではない。例えば、端末装置２００はスマートフォン型であってもよい。また、１人のユーザが有する端末装置２００の数は２つである必要はなく、１つであっても、３つ以上であってもよい。
また、図１では図示を省略するが、端末装置２００は、複数のユーザの各々に対応して設けられ、本実施形態では、複数のユーザの端末装置２００が、外部サーバ１００に接続される。

図２は、外部サーバ１００のハードウエアの構成の一例を示したである。
外部サーバ１００（情報処理装置の一例）には、情報処理部１０１と、情報を記憶する情報記憶装置１０２と、ＬＡＮ（＝Local Area Network）ケーブル等を介した通信を実現するネットワークインターフェース１０３とが設けられている。

情報処理部１０１は、プロセッサの一例としてのＣＰＵ（＝Central Processing Unit）１１１と、基本ソフトウエアやＢＩＯＳ（＝Basic Input Output System）等が記憶されたＲＯＭ（＝Read Only Memory）１１２と、ワークエリアとして用いられるＲＡＭ（＝Random Access Memory）１１３とを有する。
ＣＰＵ１１１はマルチコアでもよい。また、ＲＯＭ１１２は、書き換え可能な不揮発性の半導体メモリでもよい。
情報記憶装置１０２は、ハードディスクドライブ、半導体メモリ、磁気テープなど、既存の情報記憶装置により実現される。
情報処理部１０１と、情報記憶装置１０２と、ネットワークインターフェース１０３とは、バス１０６や不図示の信号線を通じて接続される。

ＣＰＵ１１１によって実行されるプログラムは、磁気記録媒体（磁気テープ、磁気ディスクなど）、光記録媒体（光ディスクなど）、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で、外部サーバ１００へ提供しうる。また、ＣＰＵ１１１によって実行されるプログラムは、インターネットなどの通信手段を用いて、外部サーバ１００へ提供してもよい。

外部サーバ１００は、ユーザとともに移動する端末装置２００（図１参照）と通信を行う。
外部サーバ１００のＣＰＵ１１１は、ユーザに提示する情報の制御を行う。一例として、外部サーバ１００は、ユーザの周囲に位置する周辺物についての情報（以下では「周辺物情報」と呼ぶこともある）の提示の制御を行う。
外部サーバ１００のＣＰＵ１１１は、ユーザとともに移動するカメラ２１４（図１参照）（例えば端末装置２００に設けられたカメラ２１４）により得られた映像を基に、このユーザの周囲に存在する周辺物を特定する。なお、周辺物の特定は、外部サーバ１００以外で行われてもよく、例えば、端末装置２００で行われてもよい。

外部サーバ１００のＣＰＵ１１１は、特定された周辺物についての情報の提示を制御する。
より具体的には、外部サーバ１００のＣＰＵ１１１は、端末装置２００のディスプレイ２１７（図１参照）における周辺物情報の表示を制御する。

なお、本実施形態では、端末装置２００における情報の提示を外部サーバ１００で制御する場合を説明するが、外部サーバ１００を利用せず、端末装置２００のいずれかで制御してもよい。
なお、ユーザに提示する情報を外部サーバ１００以外で制御する場合であっても、ユーザの予定情報などの各種の情報を、外部サーバ１００に格納してもよい。この場合、端末装置２００は、外部サーバ１００にアクセスすることで予定情報などのユーザについての情報を取得し、取得した情報に基づいて、ユーザに提示する情報についての決定を行う。
また、情報の提示の方法はディスプレイへの表示などの視覚的な手法に限られず、例えば、音声により提示されてもよい。

本実施形態では、外部サーバ１００の情報記憶装置１０２（図２参照）に、端末装置２００を有するユーザの予定についての情報である予定情報が格納される。そして、外部サーバ１００のＣＰＵ１１１が、この予定情報に基づき、ユーザに提示する情報についての決定を行う。そして、提示すると決定された情報が端末装置２００に送信されると、端末装置２００でその情報が提示される。
ここで、予定とは、予定されている、または、予定されていた事柄を指す。予定されていた事柄には、実際に予定どおり行われた事柄だけでなく、予定どおりに行われなかった事柄を含めてもよい。予定の例としては、会議、出張、授業、試験、旅行、食事、宿泊、人と会うこと、商品を買うこと、病院に行くこと、美容院に行くこと、幼稚園に子供を迎えに行くこと、宿題をすることが挙げられる。なお、予定は特別感や非日常感のある事柄である必要はない。

予定情報の例としては、予定の名称、種類、場所、予定時刻（開始時刻、終了時刻、期限など）、繰り返し設定の有無、関連人物（出席者や主催者など）、通知設定、添付ファイル、関連ＵＲＬ、開催場所の地図、メモなどが挙げられる。
予定情報の取得元としては、（ｉ）カレンダー、（ii）コミュニケーションの履歴、（iii）予約システムや検索サービスの履歴などが挙げられる。なお、（ｉ）～（iii）は、情報記憶装置１０２に格納されていてもよいし、それ以外の情報記憶装置に格納されていてもよい。ＣＰＵ１１１は、格納された情報や履歴から予定情報を必要なタイミングで都度要求して取得してもよいし、予め定められたタイミングで事前に取得しておいてもよい。

（ｉ）のカレンダーの例としては、ユーザの端末装置にインストールされたカレンダーアプリケーションによって提供されるカレンダーや、クラウドサービスによって提供されるカレンダーが挙げられる。カレンダーの例には行程表も含まれる。ユーザの予定は、ユーザ本人によって登録されることもあれば、他のアプリケーションや連動するサービスなどから自動的に抽出され登録されることもある。ユーザがカレンダーを公開したり他人と共有したりしている場合は、ユーザの予定が他人によって登録されることもある。さらに、医療機関等が利用するカレンダーでは、複数のユーザの来訪予定が管理されている場合もある。

（ii）のコミュニケーションの履歴の例としては、音声通話やビデオ通話の録音・録画や、電子メール、会話型メッセージアプリケーション、ＳＮＳの履歴などが挙げられる。なお、コミュニケーションの例には、文字、絵、画像、映像などによる視覚的コミュニケーション、音声などによる聴覚的コミュニケーション、および、その組み合わせが含まれる。
コミュニケーションの履歴から予定情報を取得するには、音声認識、画像解析、言語解析などの技術を適宜用いる。例えば、会話型メッセージアプリケーションにおいてユーザとＡさんとの間に以下のような一連のメッセージのやりとりがあったという履歴が、ユーザのスマートフォンの情報記憶装置や会話型メッセージアプリケーション提供者の情報記憶装置（非図示）に格納されている。
ユーザ：「７月５日に久しぶりに東京に行きます。ご都合が良ければ会いませんか？」
Ａさん：「ぜひ会いましょう」
ユーザ：「場所と時間はどこがいいですか？」
Ａさん：「新幹線で行くので東京駅近辺だと助かります。午後1時頃のご都合はいかがですか？」
ユーザ：「では、午後１時に東京駅で会いましょう」

（iii）の予約システムや検索サービスの履歴の例としては、ホテル、レストラン、レンタルオフィス、会議室、セミナー、コンサート、交通機関などの予約システムにおける予約履歴と、経路検索サービスの検索履歴などが挙げられる。経路検索サービスの検索履歴からは、出発地、出発時刻、目的地、到着時刻、移動手段（徒歩、電車、自動車など）などの予定情報が取得できる。
予定情報の取得方法については、（ｉ）～（iii）の情報がそのまま予定情報として利用されてもよいし、音声認識、画像解析、言語解析などの処理を行った結果が予定情報として利用されてもよい。例えば、（ii）のユーザとＡさんとのやりとりの例では、この履歴を解析し、「予定ＩＤ：００１（任意のＩＤでよい）、名称：Ａさんと会う、開始時刻：午後１時、場所：東京駅、出席者：Ａさん」というユーザの予定情報を取得する。

また、本実施形態では、ユーザの予定情報だけでなく、実情報を順次取得し、取得した実情報を蓄積する。これにより、ユーザが現在行っている行動、過去に行った行動、ユーザの現在の状態、ユーザの過去の状態の情報が得られる。ユーザの実情報とは、ユーザの実際の行動についての情報とユーザの実際の状態についての情報の総称である。
なお、ユーザが実際にとった行動、ユーザの実際の状態についての情報はタイムスタンプを付すことによって日時と紐づけて管理することもできる。

実情報の取得元としては、例えば、（ａ）位置情報、（ｂ）コミュニケーションの履歴、（ｃ）購入や電子決済の履歴、（ｄ）予定の完了情報（ｅ）バイタル情報、（ｆ）視覚情報、（ｇ）聴覚情報、（ｈ）その他、各種アプリケーションやサービスで管理されている情報が挙げられる。

（ａ）位置情報
位置情報は、ＧＰＳ、通行履歴、通話やライブ動画の発信地、ＳＮＳ投稿やＳＮＳに投稿された写真に付与された位置情報を基に取得できる。通行履歴には、入場履歴、退場履歴なども含まれる。通行履歴の具体例には、駅の改札の入場履歴、退場履歴、施設や部屋に設けられたゲートの通過履歴などが挙げられる。

（ｂ）コミュニケーションの履歴
コミュニケーションの履歴は前述の（ii）と同様のものを利用できる。
一例として、ユーザが通話中に「今、東京駅の中央改札前にいる」と発言した場合、この通話が行われているとき、ユーザが東京駅の中央改札前にいるという実情報が取得できる。別の一例として、ユーザが会話型メッセージサービスでの「今、野球の試合終わった。楽しかった」というメッセージを送信した場合、ユーザが野球の試合を見ていたという実情報が取得できる。別の一例として、ユーザがＳＮＳでハンバーガーの写真と「おいしかった」というテキストを投稿した場合、ユーザがハンバーガーを食べたという実情報が取得できる。別の一例として、オンライン会議への参加状況や参加履歴からは、ユーザが会議中であるという実情報やユーザが会議に出席していたという実情報が取得できる。

（ｃ）購入や電子決済の履歴
電子決済の利用履歴としては、例えば、クレジットカード、交通系ＩＣ、コード決済（例えばＱＲコード（登録商標）やバーコード決済）などの利用履歴が挙げられる。

購入履歴は、店舗（実店舗でもオンライン店舗でもよい）の販売履歴データベース、家計管理アプリケーションの登録内容、レシートや請求書の読み取り結果を基に取得できる。

（ｄ）予定の完了情報
予定の完了情報の例としては、ユーザのやるべきことを登録したやることリストやユーザの買い物予定を登録した買い物リストの完了状態が挙げられる。
具体的には、例えば、やることリストに登録されている各項目のステータスが、未了から完了に変わった場合に、その項目（例えば「お母さんに母の日のプレゼントを送る」）が実施されたことが特定でき、実情報が取得できる。
また、買い物リストに上がっている商品のチェックが行われたら、この商品が実際に購入されたことが特定でき、実情報が取得できる。
なお、カレンダーに登録された予定が実際に行われたか否かを管理する機能がある場合は、カレンダーの予定の完了情報に基づいて得ることもできる。

（ｅ）バイタル情報
バイタル情報としては、例えば、心拍、血圧、呼吸、体温、血糖値、酸素レベル、意識状態、脳波、瞳孔反応などについての情報が挙げられる。
これらの情報は、一例として、ユーザが装着するデバイスのセンサによって測定される。別の一例として、街中や病院等に設けられた装置（例えば検温装置や血圧計）で測定された情報を受信して利用してもよい。

（ｆ）視覚情報
視覚情報は、ユーザに見えているものについての情報である。
ユーザが見ているものは、例えば、ユーザの前方方向を撮影した画像データ（静止画であっても動画であってもよい）を解析することで特定できる。より具体的には、例えば、ユーザが乗車している乗り物（例えば車）の進行方向を撮影するカメラにより得られた画像データを解析することで、ユーザが見ているものの特定を行える。また、眼鏡型の端末装置にユーザの顔が向いている方向を撮影するように設けられたカメラにより得られた画像データを解析することでもユーザが見ているものの特定を行える。

また、道路や店舗に設置されたカメラにより得られた画像データであって、ユーザの前方の状況を撮影したカメラにより得られた画像データを解析することでも、ユーザが見ているものの特定を行える。
また、例えば、ユーザの頭部や眼球に設置されるウエアラブルな端末装置に設けられたカメラにより得られた画像データを解析することで、ユーザが見ているものの特定を行える。

また、その他に、ユーザが見ているものは、ユーザが携帯しているスマートフォンのカメラで撮影した画像や動画を解析することでも特定できる。
また、ユーザが見ているものは、ユーザの現在地の情報、ユーザが向いている方向、および、電子地図によっても特定できる。
また、ユーザが見ているものは、ユーザの視線とその先にあるものを検知することによっても特定できる。

（ｇ）聴覚情報
聴覚情報は、ユーザに聞こえている音についての情報である。この聴覚情報は、ユーザの現在地にあるマイクや、ユーザが有する端末装置２００に設けられたマイクなどにより取得される。

（ｈ）その他、各種アプリケーションやサービスで管理されている情報
各種アプリケーションやサービスで管理されている情報とは、ユーザの端末装置にインストールされているアプリケーションや、ユーザが利用するサービスで管理されている情報である。
一例として、健康管理アプリケーションやサービスで管理されている身体情報が挙げられる。身体情報としては、例えば、身長、体重、体脂肪率、ＢＭＩなどの値が挙げられる。身体情報は、ユーザが体重計に乗ったタイミングなどで自動的に収集されるものであってもよいし、ユーザが手動で入力するものであってもよい。
別の一例として、運動管理アプリケーションやサービスで管理されている運動の記録が挙げられる。運動情報は、自動的に認識された運動の情報であってもよいし、ユーザが手動で入力するものであってもよい。
別の一例として、食事管理アプリケーションやサービスで管理されている食事情報や栄養情報が挙げられる。食事管理アプリケーションやサービスの中には、例えば、食べたもの（調理前の状態であっても調理済みの状態であってもよい）の写真から、カロリーや栄養素などの情報を取得するものがある。なお、その他に、ユーザが手動で、食べたものや摂取した栄養（カロリー、糖質量、塩分量など）についての情報を入力してもよい。
その他の例として、ゲーム、音楽、動画、地図、オンライン会議、動画、電子書籍などのアプリケーションやサービスの利用履歴などが挙げられ、ユーザが再生した曲についての情報や星を付けた曲についての情報、ウェブブラウザやファイルビューワーの閲覧履歴や改訂履歴などの情報を利用することもできる。

本実施形態では、後述するように、例えば、ユーザの急ぎ具合や、周辺物に対するユーザの関心や、ユーザの状態についての情報を取得する。
ここで、ユーザの急ぎ具合は、例えば、予定情報、実情報、および、これらの組み合わせに基づいて特定できる。
一例として、ユーザの急ぎ具合は、ユーザの現在地（実情報の一例）から予定の開催場所（予定情報の一例）までの所要時間と、現在時刻から予定の開始時刻（予定情報の一例）までの残り時間との基づき特定できる。
別の一例として、ユーザの急ぎ具合は、ユーザの移動速度（実情報の一例）や、ユーザのバイタル情報（実情報の一例）を基に特定できる。移動速度が通常よりも大きい場合や、心拍数や血圧が上がっている場合、ユーザが急いでいると考えることができる。
別の一例として、ユーザの急ぎ具合は、ユーザが装着しているウエアラブルな端末装置に設けられたカメラにより得られた画像データ（実情報の一例）を解析することで特定できる。例えば、ユーザが時計を見る頻度が増えている場合、そのユーザは時間を気にしており急いでいると考えることができる。

周辺物に対するユーザの関心は、例えば、予定情報、実情報、および、これらの組み合わせに基づいて特定できる。
一例としては、現在時刻から予め定められた時間以内にユーザがレストランの予約（予定情報の一例）を入れている場合、このユーザは、そのレストランまでの道のりにある他のレストランで食事を取ることへの関心が低いことを特定できる。
別の一例として、カレンダーに、ユーザがＡさんに会うという予定（予定情報の一例）が入っている場合、このユーザはＡさんにプレゼントを渡す可能性があるため、このユーザは、Ａさんに会う前に、Ａさんへのプレゼントとなりうるものを販売する店舗に関心を有する可能性があることを特定できる。また、このユーザがＡさんへのプレゼントを購入した（実情報の一例）ことが特定された場合、Ａさんへのプレゼントとなりうるものを販売する他の店舗への関心が失われたとみなすこともできる。

別の一例として、ユーザに食事の予定（予定情報の一例）が入っている場合、この食事の予定から一定期間が経過するまでの間は、ユーザがレストランで食事を取ることに関心がない可能性を特定できる。
別の一例として、ユーザの先週の予定が詰まっていた場合（予定情報の一例）、ユーザが疲れている可能性を特定できる。
別の一例として、来週に飛行機を利用しての遠方への出張が予定されている（予定情報の一例）場合、ユーザが旅行用品に関心がある可能性を特定できる。
別の一例として、現在時刻から予め定められた期間内（現在時刻より前であっても後であっても、前後両方を含んでもよい）に病院の予約が入っている（予定情報の一例）場合、ユーザの健康面に問題がある可能性を特定できる。

その他の例として、ユーザが対象に対して関心があるか否かや、ユーザの関心の対象について、ユーザの心拍数などのバイタル情報、ユーザの対象の訪問回数、対象での滞在時間、購入履歴、お気に入りへの登録状況、「ＸＸが欲しい」などの発言、頻繁に開いているアプリケーション、頻繁に開いているウエブサイト、頻繁に聞いている曲、ＳＮＳでの反応（特定の投稿に高評価を付けたなど）などの情報（いずれも実情報の例）を基に特定できる。

その他の例として、ユーザの状態を、ヒーリング系の音楽をよく聞いているか否か、睡眠時間、居眠りの検知の有無、カフェインを含有する飲料の摂取量、バイタル情報、身体に関するＳＮＳへの投稿、運動管理アプリケーションにより取得された情報、ユーザの食欲の有無（例えば食事管理アプリケーションにより取得された情報により特定される食欲についての情報）、体重の増減、病院や薬局における履歴、薬の処方履歴などの情報（いずれも実情報の例）を基に特定することもできる。

本実施形態では、予定情報と実情報が、外部サーバ１００の情報記憶装置１０２に格納されるものとするが、予定情報と実情報は、端末装置２００の情報記憶装置や、外部サーバ１００や端末装置２００が接続可能な他のシステムの情報記憶装置に格納されてもよい。
また、予定情報と実情報は、１箇所のみに格納される必要はなく、複数のサーバや端末装置に分散して格納されてもよい。

本実施形態では、端末装置２００（図１参照）を携行するユーザの予定情報を用い、端末装置２００に設けられたカメラ２１４により撮影された映像の中から、このユーザに情報を提示すべき物を選定する。そして、選定された物についての情報をユーザに提示する。より好ましくは、選定された物に、その物についての情報を対応付けて提示する。なお、物に情報を対応付けて提示することの例には、物をユーザが見ているタイミングで、情報が物に重なるように、あるいは、物の付近にくるように表示することや、物と情報の対応付けを示す矢印や吹き出しなどを表示することが含まれる。
撮影により得られた映像に含まれる物についての情報を提示する機能は、既存技術として存在する。しかしながら、その多くは、認識された全ての物について情報を提示するものであったり、どのユーザに対しても同じように情報を提示するものであったりする。
異なるユーザが同じ情報に対して同じように反応するとは限らず、その情報を有難いと思うユーザが存在する一方で、その情報を欲していないユーザや、その情報が提示されることが逆に迷惑だと感じるユーザも存在する。
本実施形態では、これらの背景に鑑み、情報の提示の制御を行う。なお、ＣＰＵ１１１が実行する各種の機能は、ユーザと共に移動する端末装置２００のプロセッサによって実行されてもよく、例えば、端末装置２００のＣＰＵ２１１Ａによって実行されてもよい。

図３～５は、ユーザの端末装置２００のディスプレイ２１７に表示される表示画面の例を説明する図である。図３～５が示す表示画面は、それぞれ異なる条件下で表示される。
本実施形態では、図３に示す表示画面を、ユーザの急ぎ具合が予め定められた第１の条件を満たし、かつ、ユーザの前に存在する道が、ユーザが予め定められた回数未満しか通ったことがない道である場合（例えば、一度も通ったことがない道である場合）に表示する。なお、ユーザの急ぎ具合が予め定められた第１の条件を満たす場合の一例としては、ユーザの時間的な余裕を示す指標が予め定められた条件を満たす場合が挙げられる。ユーザの時間的な余裕を示す指標には、例えば、ユーザが現在時刻から次の予定の開始時刻までの残り時間と、ユーザが現在地から次の予定の開催場所までに移動するのにかかる所要時間との差がある。この差が大きいほど、ユーザの時間的な余裕が大きいといえる。また、ユーザの急ぎ具合が予め定められた第１の条件を満たす場合の別の一例としては、ユーザが次の予定の開催地に向かって走っている状態であることが特定できる場合が挙げられる。なお、ユーザが走っていることは、例えば、移動速度と心拍がそれぞれ予め定められた閾値以上であることによって特定できる。また、ユーザが走っていることは、例えば、カメラ２１４によって取得された映像を解析することでも特定できる。ユーザが急いで移動している場合には、カメラ２１４によって取得された映像に写っているものの変化の速度が、普通に歩いているときと比較して速くなる。また、ユーザが走っているときには、カメラ２１４によって取得された映像が、歩いているときと比較して上下に大きく揺れる。この揺れの程度を検出することで、ユーザが走っていることの特定を行える。なお、予め定められた第１の条件は、後述の予め定められた第２の条件よりも急ぎ具合が高いものとする。また、急ぎ具合は、急いでいるか否かであってもよいし、どの程度急いでいるかであってもよいし、どの程度急いでいないか（つまりどの程度余裕があるか）であってもよい。

図３に示す表示画面では、ユーザの周囲に存在する周辺物の案内は行われていない。言い換えると、ユーザの周囲に存在する周辺物についての情報である周辺物情報の表示は行われていない。
本実施形態では、ユーザの急ぎ具合が第１の条件を満たす場合に、ＣＰＵ１１１は、ユーザに周辺物情報を提示しないことを決定する。

図３にて示す表示画面では、道路に対応して、色が付された帯状の画像９２が表示され、ユーザが進むべき道の案内が行われている。なお、ユーザが進むべき道とは、例えば、ユーザが目的地に行くために進むべき道である。
本実施形態では、ＣＰＵ１１１は、ユーザの前に存在する道が、ユーザが予め定められた回数未満しか通ったことがない道である場合に、ユーザの現在地から目的地までの道を案内する情報である道案内情報を提示することを決定する。

なお、ＣＰＵ１１１は、ユーザの前に存在する道をユーザが通ったことがある回数に関わらず、ユーザの急ぎ具合が第１の条件を満たす場合に、ユーザの現在地から目的地までの道を案内する情報である道案内情報を提示することを決定してもよい。そうすることで、ユーザが寄り道せず経路どおりに進むことが期待できる。

本実施形態では、図４に示す表示画面を、ユーザの急ぎ具合が第１の条件とは異なる予め定められた第２の条件を満たし、かつ、ユーザの前に存在する道が、ユーザが予め定められた回数以上通ったことのある道である場合に表示する。
図４に示す表示画面では、図３で行われている道の案内は行われていない。本実施形態では、ＣＰＵ１１１は、ユーザの前に存在する道が、ユーザが予め定められた回数以上通ったことのある道である場合にユーザの現在地から目的地までの道を案内する情報である道案内情報を提示しないことを決定する。
一方で、図４に示す表示画面では、符号４Ａ、４Ｂに示すように、ユーザの周辺に位置する周辺物についての情報が表示され、周辺物の案内が行われている。本実施形態では、ユーザの急ぎ具合が第１の条件とは異なる予め定められた第２の条件を満たす場合に、ＣＰＵ１１１は、ユーザに周辺物情報を提示することを決定する。

本実施形態では、端末装置２００のカメラ２１４（図１参照）が、端末装置２００を装着しているユーザの顔が向いている方向を撮影するように設けられている。そして、ＣＰＵ１１１が、ユーザとともに移動するカメラ２１４により得られた映像を基に、ユーザの周辺に存在する一以上の周辺物を特定する。言い換えると、ＣＰＵ１１１は、ユーザの現在地とユーザが向いている方角とに基づき、ユーザの周辺に存在する周辺物を特定する。周辺物情報の一例としては、ユーザの周囲に存在する周辺施設についての情報である周辺施設情報が挙げられる。
なお、ユーザの周辺物の特定には必ずしもカメラを用いる必要はなく、ユーザの現在地とユーザが向いている方角と、電子地図とに基づき、ユーザが向いている方向に位置する周辺物を特定してもよい。
なお、ユーザの現在地は、端末装置２００に設けられたＧＰＳにより特定でき、ユーザが向いている方角は、端末装置２００に設けられた方位センサに基づき特定できる。

本実施形態では、図５に示す表示画面を、ユーザの急ぎ具合が第１の条件とは異なる予め定められた第２の条件を満たし、かつ、ユーザの前に存在する道がユーザの頻繁に通る道でない場合に表示する。
図５に示す表示画面では、符号５Ａ、５Ｂに示すように、ユーザの周辺に位置する周辺物についての情報である周辺物情報が表示され、かつ、符号５Ｃで示すように、ユーザが進むべき道を案内する帯状の画像９２が表示されている。

図６～８は、周辺物情報の表示量レベルを説明する図である。
周辺物情報の表示は、表示が行われるようにする表示の有効と表示が行われないようにする表示の無効とを切り替える制御を行うだけでなく、予定情報に基づき表示量レベルを設定し、表示画面では、決定されたこの表示量レベルに応じた表示を行ってもよい。
本実施形態では、図６に示す表示画面を、急ぎ具合が第１の条件を満たす移動中のユーザに表示する。第１の条件は後に登場する第２の条件と第３の条件よりも急ぎ具合が高い場合に満たされるものとする。この場合、ＣＰＵ１１１は、例えば、周辺物情報の表示量レベルを０に設定する。図６に示す表示画面では、周辺物情報の表示が行われていない。一方で、図６に示す表示画面では、道の案内が表示されている。ユーザの急ぎ具合が高い場合に道の案内を表示すれば、ユーザが寄り道せず経路どおりに進むことがより期待できる。

本実施形態では、図７に示す表示画面を、急ぎ具合が第２の条件を満たす移動中のユーザに表示する。第２の条件は第１の条件よりも急ぎ具合が低く、後に登場する第３の条件よりも急ぎ具合が高い場合に満たされるものとする。
この場合、ＣＰＵ１１１は、例えば、周辺物情報の表示量レベルを１に設定する。この場合、符号７Ａで示すように、周辺物情報の表示が行われる。

本実施形態では、図８に示す表示画面を、急ぎ具合が第３の条件を満たす移動中のユーザに表示する。第３の条件は第１の条件と第２の条件よりも急ぎ具合が低い場合に満たされるものとする。
この場合、本実施形態では、ＣＰＵ１１１は、周辺物情報の表示レベルを２に設定する。この場合、符号８Ａ、８Ｂで示すように、２箇所に周辺物情報が表示され、図７における表示に比べ、周辺物情報がより多く表示される。

本実施形態では、このように、プロセッサの一例としてのＣＰＵ１１１は、予定情報に基づき、ユーザに提示する周辺物情報の量を制御する。
なお、周辺物情報の量の制御としては、周辺物情報を表示する対象となる周辺物の数の制御を行ってもよいし、１つの周辺物に関して表示される周辺物情報の量の制御を行ってもよい。

なお、上記にて説明した例では、周辺物情報そのものが表示される場合を一例に説明したが、これに限らず、周辺物情報としては、周辺物に対応したアイコンがまず表示されるようにしてもよい。
そして、このアイコンに対する操作をユーザが行った場合に、上記にて示したような、周辺物情報が表示されるようにしてもよい。

なお、アイコンに対するユーザの操作としては、例えば、音声による操作や、視線による操作や、指を指すことによる操作などが挙げられる。
また、表示画面に表示されるアイコンについては、周辺物の種類や、アイコンに対する操作をユーザが行うことに伴い提示される情報の種類によって、アイコンの種類を変えてもよい。

ここで、周辺物の案内については、行う、あるいは、行わないの２者択一に限られない。
周辺物の案内にあたっては、例えば、周辺物情報を最初から表示する態様と、まずはアイコンを表示する態様の２つの態様を用意し、ユーザの選択または予め定められた条件による切り替えにより、周辺物情報を最初から表示する処理と、まずは表示できる周辺物情報があることを示すアイコンのみを表示する処理の何れかが行われるようにしてもよい。

また、周辺物についての案内にあたっては、例えば、周辺物情報を最初から表示する態様、まずはアイコンを表示する態様、および、アイコンすら表示しない態様の３つの態様を用意し、何れかの態様の処理が行われるようにしてもよい。
また、例えば、アイコンすら表示しない態様であっても、例えば、「このコーヒーショップの評判はどうですか？」との問い合わせがユーザからあった場合、そのコーヒーショップについての情報の提示を行ってもよい。

また、アイコンすら表示しない態様であっても、例えば、周辺物情報が対応付けられている周辺物に対し、ユーザが、所定の動作（予め定められた時間を超えて視線を向けるなど）を行った場合には、この周辺物情報が提示されるようにしてもよい。
言い換えると、アイコンすら表示しない態様であっても、例えば、周辺物情報が対応付けられている周辺物に対して、ユーザが関心を有していることが検知された場合には、この周辺物情報が表示されるようにしてもよい。

図９～１１は、端末装置２００の表示画面における他の表示例を示した図である。
図９は、現在から予め定められた時間以内に食事の予定（終わった予定であってもよいし、これからの予定であってもよい）が入っているユーザの端末装置２００における表示例を示している。
より具体的には、図９は、例えば、現在から予め定められた時間以内にレストランなどの飲食店の予約が入っているユーザの端末装置２００における表示例を示している。

なお、図９の表示例は、現在から予め定められた時間以内に、実際にレストランに行ったことが確認できるユーザの端末装置２００に表示されてもよい。
この場合、このユーザの端末装置２００の表示画面には、レストランなどの飲食店の情報が表示されず、図９では、レストランなどの飲食店に対応した周辺物情報が表示されないようになる。
より具体的には、この例では、符号９Ａで示す箇所にレストランが存在しているにも関わらず、このレストランについての情報が表示されないようになる。

図１０は、時間的な余裕があまりないユーザであって徒歩で移動中のユーザが有する端末装置２００における表示画面を示している。
時間的な余裕があまりないユーザの場合、このユーザから見えてはいるが、道路を横断しなければ行けないような周辺物についての案内を行わない。
具体的には、符号１０Ａで示す箇所に、ホテルが存在しているが、このホテルについての案内は行わない。
また、本実施形態では、このように、時間的な余裕があまりないユーザの場合、ユーザから見えていても、ユーザの移動経路外にある周辺物についての案内を行わない。

図１１は、旅行中のユーザが有する端末装置２００における表示画面を示している。
具体的には、図１１では、ロンドン旅行という情報が予定情報に含まれているユーザが有する端末装置２００における表示画面を示している。
この表示例では、符号１１Ａで示すように、ホテルの案内が行われている。より具体的には、この表示例では、ユーザが予約済みの滞在予定のホテル（不図示）である滞在予定ホテルよりも好条件のホテルを通りかかった時に、好条件のホテルの案内が行われた場合を例示している。

本実施形態では、ＣＰＵ１１１は、ユーザの予定情報に基づき、ユーザに提示する周辺物情報を決定する。
図１１に示す例では、ユーザの予定情報により特定される予定は、旅行であるため、この旅行という情報に基づき、ユーザに提示する周辺物情報を決定する。
これにより、本実施形態では、ユーザに対して、ホテルの情報が提示される。

より具体的には、この例では、ユーザが既に予約している滞在予定ホテルよりも料金が安かったり、滞在予定ホテルよりも近い場所に位置したりするホテルの案内が行われた場合を例示している。
ここで、滞在予定ホテルは、ユーザの予定情報で明示されておりユーザの予定情報に含まれている物についての情報である。
一方、上記の好条件のホテルは、ユーザの予定情報で明示されておらず、好条件のホテルの情報は、ユーザの予定情報に含まれない周辺物についての情報である。

本実施形態では、外部サーバ１００の、プロセッサの一例としてのＣＰＵ１１１は、周辺物情報の提示にあたり、ユーザの予定情報を取得する。
そして、ＣＰＵ１１１は、ユーザに提示する、ユーザの現在地の周辺物についての情報を、このユーザの予定情報に基づいて決定する。

ここで、ユーザに提示される周辺物情報が、「予定情報に含まれない周辺物についての情報である」とは、例えば、ユーザのカレンダーに登録されていない施設についての情報や、ユーザの行程表内に記載されていない施設についての情報が、ユーザがこれらの施設の周辺に来たときにユーザに提示されることを指す。
一方で、例えば、ユーザの施設（例えばホテル）の予約情報に基づいて、ユーザがその施設の周辺に来たときにその施設の情報（例えば、そのホテルの名前や、そのホテルの場所や方向）をユーザに提示することは、ユーザの予定情報に基づいて、予定情報には含まれない周辺物についての情報をユーザに提示することにはならない。

図１２は、ユーザの端末装置２００における他の表示例を示した図である。
この表示例では、図中符号１２Ａで示す店舗を頻繁に利用しているユーザの端末装置２００における表示画面を示している。
この表示画面では、店舗の基本的な情報は、表示されていない。具体的には、この表示画面では、店舗の名称や、店舗の評価などの情報は表示されていない。

その一方で、この表示画面では、ユーザが店舗を通過するタイミングに関連している情報が表示されている。
具体的には、この表示例では、ユーザが店舗を通過するタイミングにおいて、飲み物の価格が１０％オフとなっており、飲み物の価格が１０％オフとなっていることを示す情報の表示が行われている。

図１３は、ユーザの端末装置２００における他の表示例を示した図である。
この表示例では、ホテルについての情報が表示されている。
具体的には、この表示画面が表示された端末装置２００を有するユーザは、旅行中であり、且つ、このユーザの予定情報に、具体的な宿泊施設についての情報が登録されていないユーザとなっている。
この場合、本実施形態では、符号１３Ａに示すように、ユーザの周辺に存在するホテルの本日の空き状況と、このホテルの本日の利用料金が表示される。

本実施形態では、このように、ユーザに対して、周辺物情報の提示を行う。
周辺物情報の提示は、無料としてもよいし、有料としてもよい。
また、周辺物情報の提示が有料である場合は、周辺物情報の配信を希望する配信希望者に課金を行ってもよいし、周辺物情報の受信を希望する受信希望者に課金を行ってもよい。また、配信希望者および受信希望者の両者に対して、課金を行ってもよい。

また、配信希望者に課金を行う場合は、周辺物情報の配信回数に応じた課金を行ってもよい。
ここで、配信希望者は、配信する周辺物情報に反応する可能性が高いユーザを狙って、周辺物情報の配信を行いたい。また、受信希望者も、欲しくない周辺物情報を受信したり、不都合なタイミングで周辺物情報を受信したりすることを望んではおらず、受信希望者は、欲しい周辺物情報をタイミングよく得られることを望んでいる。

周辺物情報としてユーザへ提示する情報としては、例えば、施設の名称、営業日、営業時間、混雑状況、休業日、提供サービス（メニュー、販売商品など）、おすすめのサービス、クーポン、評価、内観写真、外観写真、地図上での場所、住所、電話番号、公式サイトのＵＲＬ、ＳＮＳのＵＲＬや、ＳＮＳでの投稿内容などが挙げられる。
周辺物情報としてユーザへ提示する情報は、施設を運営する事業者が、本実施形態の情報処理システム１に対して登録した情報であってもよいし、施設の利用者が本実施形態の情報処理システム１に対して登録した情報であってもよいし、個人情報の利用規約に同意したユーザから自動的に収集された情報や、これらの情報に基づいて生成された情報であってもよい。

例えば、施設の混雑状況についての情報は、施設を運営する事業者が自らデータベースに登録した情報を用いてもよいし、施設の利用者がデータベースに登録した情報を用いてもよいし、この施設に滞在している人の数や、施設に滞在している人が所有している端末装置２００の数や、オンラインオーダーによる注文数などに基づいて自動的に決定された情報を用いてもよい。

また、その他に、他の事業者よりも優先的に情報が配信されることを望む事業者のために、プロモーション機能を備えてもよい。
この場合、優先的に情報が配信されることを望む事象者の情報が、他の事業者の情報よりも優先して提示される。
この場合、優先的に情報が配信されることを望む事象者に対して、課金を行ってもよい。

ユーザに対して周辺物情報を提示する手段としては、電子メール、チャット、ウエアラブルな端末装置やスマートフォンの通知機能、情報配信との親和性が高いアプリケーションなどを介した情報配信サービスなどを挙げることができる。
情報配信との親和性が高いアプリケーションとしては、例えば、検索機能、地図機能、道案内機能などを有するアプリケーションを挙げることができる。
本実施形態では、道案内機能を有するナビゲーションアプリ上で、周辺物情報や、道案内のための情報を配信する場合を例示する。

〔端末装置２００の説明〕
図１４は、端末装置２００のハードウエアの構成を示した図である。
端末装置２００は、情報処理装置の一例である。
端末装置２００は、スマートフォン型であってもよいし、眼鏡型であってもよいし、手首装着型であってもよいし、他の形態であってもよい。端末装置２００はユーザが携行可能な装置となっている。
端末装置２００は、プロセッサの一例としてのＣＰＵ２１１Ａ、ＲＯＭ２１１Ｂ、ＲＡＭ２１１Ｃ、情報記憶装置２１２、センサ２１３、カメラ２１４（視覚情報入力手段の一例）、マイク２１５（音声情報入力手段の一例）、スピーカ２１６（音声情報出力手段の一例）、ディスプレイ２１７（視覚情報出力手段の一例）、プロジェクタ２１８（視覚情報出力手段の一例）などのハードウエアを有する。なお、端末装置２００はこれらすべてを有さなくてもよい。
センサ２１３としては、ＧＰＳセンサ、方位センサ、バイタル情報を取得するセンサなどが一例に挙げられる。ディスプレイ２１７としては、ディスプレイを通してこのディスプレイの背後を透視可能なディスプレイや、液晶ディスプレイのような透視可能でないディスプレイが一例に挙げられる。

ここで、ＣＰＵ２１１Ａによって実行されるプログラムは、磁気記録媒体（磁気テープ、磁気ディスクなど）、光記録媒体（光ディスクなど）、光磁気記録媒体、半導体メモリなどのコンピュータが読取可能な記録媒体に記憶した状態で、端末装置２００へ提供しうる。
また、ＣＰＵ２１１Ａによって実行されるプログラムは、インターネットなどの通信手段を用いて、端末装置２００へ提供してもよい。

本明細書において、プロセッサとは、広義的なプロセッサを指し、汎用的なプロセッサ（例えばＣＰＵ：Central Processing Unit、等）や、専用のプロセッサ（例えばGPU： Graphics Processing Unit、ASIC： Application Specific Integrated Circuit、FPGA： Field Programmable Gate Array、プログラマブル論理デバイス、等）を含むものである。
また、プロセッサの動作は、１つのプロセッサによって成すのみでなく、物理的に離れた位置に存在する複数のプロセッサが協働して成すものであってもよい。また、プロセッサの各動作の順序は、本実施形態において記載した順序のみに限定されるものではなく、変更してもよい。

端末装置２００には、メール、カレンダーなどの様々なアプリケーションが予めインストールされ、あるいは、追加でインストールされる。
また、端末装置２００は、通信規格（Wi-Fi、3G、4G、5G、Bluetooth（登録商標）、NFCなど）に適合した通信インターフェース（不図示）を有し、外部の機器や、ネットワークに接続してデータを送受信する。
なお、上記の全ての構成を端末装置２００が備える必要はなく、予算やユーザの希望に応じて、機能が省略される場合もある。

図１で示す眼鏡型の端末装置２００Ａや手首装着型の端末装置２００Ｂのような端末装置２００は、ウエアラブルであり、ユーザの身体の一部に装着される。
ウエアラブルな端末装置２００は、眼鏡型や手首装着型に限られず、その他に、靴、服、指輪、ヘッドセット、コンタクトレンズなどの形態を有する場合もある。

端末装置２００は、ディスプレイ２１７に情報を表示することによって、ユーザに視覚的に情報を提示することが可能である。
端末装置２００が眼鏡型やコンタクトレンズ型の場合、端末装置２００にはディスプレイ２１７として、ユーザが透視可能なディスプレイが設置され、ユーザは、この透視可能なディスプレイを通じ、このディスプレイの背後の視認を行える。言い換えると、端末装置２００は、ユーザが透視可能な透明部を有する場合があり、ユーザは、この透明部を通して現実空間を見ることが可能である。
端末装置２００のディスプレイ２１７として、このような透視可能なディスプレイが設置されている場合においては、ディスプレイ２１７に情報が表示されると、ユーザは、ディスプレイ２１７に表示される情報と現実空間の両者の視認を行える。
この場合、ユーザの周辺にある周辺物についての情報を、ディスプレイ２１７を介してユーザが視認する現実空間の現実物に対して対応付けることが可能である。

本実施形態では、ＣＰＵ１１１は、透視可能なディスプレイ２１７を介してユーザが視認する現実空間の現実物に対して、周辺物情報を対応付けるが、ディスプレイ２１７が液晶ディスプレイのように透視可能でない場合もある。例えば、図１の手首装着型の端末装置２００Ｂのディスプレイや、スマートフォンのディスプレイは、通常、透視可能でない。透視可能でないディスプレイを有する端末装置２００においては、ユーザの周辺を撮影するカメラ２１４により得られた映像上で、ユーザの周辺にある周辺物と、その周辺物についての情報を対応付けることが可能である。

ここで、眼鏡型やコンタクトレンズ型の端末装置２００は、ユーザの眼球の前に装着される装置と言える。
眼鏡型やコンタクトレンズ型の端末装置２００では、透視可能なディスプレイ２１７が、ユーザの眼球の前に配置され、この端末装置２００は、少なくも一部が、ユーザの眼球の前に配置される装置であるといえる。

本実施形態では、端末装置２００のカメラ２１４は、ユーザの視界内に存在する状況を捉える。
本実施形態では、端末装置２００に設けられたカメラ２１４が取得した画像データは、例えば、この端末装置２００の画像解析機能により解析される。より具体的には、端末装置２００のカメラ２１４が取得した画像データは、この端末装置２００のＣＰＵ２１１Ａによって解析される。
なお、これに限らず、端末装置２００のカメラ２１４が取得した画像データは、この端末装置２００とは異なる他の端末装置２００や、外部サーバ１００に設けられたＣＰＵ１１１が解析してもよい。

本実施形態では、この解析によって、ユーザの周辺物が特定される。
具体的には、本実施形態では、例えば、公知の画像解析技術が用いられて、画像データに含まれている施設がユーザの周辺物として認識される。言い換えると、本実施形態では、ユーザの視界内にある施設の認識が行われる。
なお、その他に、ユーザの周辺物は、ユーザの現在地と、このユーザが向いている方角と、電子地図とに基づき特定してもよい。
具体的には、この場合、電子地図を参照し、ユーザの現在地とこのユーザが向いている方角とに基づき、ユーザの視界内にある施設を特定する。

本実施形態においては、端末装置２００のカメラ２１４により取得された画像データは、この端末装置２００の情報記憶装置２１２や、外部サーバ１００などの他の装置の情報記憶装置に、一または複数の動画ファイルとして保存される。
なお、これに限らず、端末装置２００のカメラ２１４により取得された画像データは、静止画のファイルとして保存されるようにしてもよい。

ここで、端末装置２００に設けられるセンサ２１３としては、上記の通り、ユーザのバイタル情報を取得するセンサ２１３が一例に挙げられる。
バイタル情報を取得するセンサ２１３としては、ユーザの頭部の回転や向きを検知するセンサ、ユーザの視線の先を検知するセンサ、ＧＰＳと連携してユーザの地球上での位置を特定するためのセンサ、装着者のバイタルサイン（心拍、血圧、呼吸、体温、血糖値、酸素レベル、意識状態、脳波、瞳孔反応など）を測定するセンサなどが挙げられる。

なお、その他に、ユーザのバイタル情報等を取得するセンサ２１３は、ユーザが保持する端末装置２００に限らず、ユーザから離れた箇所に設置されるようにしてもよい。
例えば、店舗の入口に設けられた装置に、ユーザの体温を検知するセンサ２１３を設け、このセンサ２１３で、ユーザの体温を測定してもよい。
また、例えば、ユーザの体格などの情報を取得するセンサ２１３を、ユーザとは異なる箇所に設置し、このセンサ２１３で、ユーザの体格についての情報を取得してもよい。

ここで、ユーザに携帯される端末装置２００としては、上記の通り、コンタクトレンズ型の装置も挙げられる。このコンタクトレンズ型の装置も、少なくとも一部が、ユーザの眼球の前に配置される装置であるといえる。
このコンタクトレンズ型の装置の場合、この装置は、主に表示装置としての機能を果たす。コンタクトレンズ型の装置における表示の制御は、この装置とは異なる他の装置により行われるようにしてもよい。
この他の装置としては、スマートフォンや、ユーザのＰＣ、外部サーバ１００などが挙げられる。

また、本実施形態にて提供される各種の機能は、外部サーバ１００のＯＳの機能として提供されてもよいし、ＯＳ上で動作するアプリケーションとして提供されてもよい。
また、本実施形態にて提供される各種の機能は、１以上の端末装置２００によって単独で提供されてもよいし、２以上の端末装置２００が協働することによって提供されてもよい。この場合、この各種の機能は、端末装置２００のＯＳの機能として提供されてもよいし、このＯＳ上で動作するアプリケーションにより提供されてもよい。
また、本実施形態では、端末装置２００にインストールされるナビゲーションアプリによって、各種の機能が提供されるが、他のアプリケーションにより、本実施形態の機能が提供されるようにしてもよい。

本実施形態の端末装置２００にインストールされるナビゲーションのアプリケーションは、２つの機能を有する。
具体的には、このナビゲーションのアプリケーションは、目的地までの道を案内する道案内機能と、ユーザの周辺に存在する周辺物についての情報である周辺物情報を提示する周辺物情報提示機能とを有する。

道案内機能は、ユーザに対して、ユーザが進むべき道や方向を提示する機能である。本実施形態では、この道案内機能によって、図３等に示したような、ユーザに道を案内するための表示が行われる。
周辺物情報提示機能は、ユーザに対して、ユーザの現在地の周辺に存在する周辺物についての情報である周辺物情報を提示する機能である。なお、周辺物情報提示機能は、本実施形態の情報処理システム１とは別に設けられた外部の情報配信システムと連携してもよい。

道案内機能、周辺物情報提示機能のこの２つの機能の各々は、ユーザからの指示に応じて、有効と無効を切り替えられるようにしてもよい。
また、この２つの機能の各々は、ユーザの指示以外の予め定められた条件が満たされか否かによって、有効と無効を切り替えられるようにしてもよい。
本実施形態では、道案内機能、周辺物情報提示機能の２つの機能の両方を有効にすることも、片方のみを有効にすることも、両方を無効にすることもできる。

なお、条件が満たされたか否かによって、有効と無効を切り替えられるようにする場合は、条件が満たされ且つユーザの承諾がさらにあった場合に、この有効と無効の切り替えが行われるようにしてもよい。
具体的には、この場合、条件が満たされたら、例えば、ユーザに対して、「道案内をしましょうか？」、「周辺物情報提示機能を無効にしますか？」等の問い合わせを行い、この問い合わせに対するユーザからの回答があった場合に、有効と無効の切り替えを行う。

周辺物の例としては、施設などの人工物や、草木などの自然物が挙げられる。施設の例としては、レストラン、ホテル、スーパーマーケット、美術館、学校、展望台などが挙げられる。
施設では各種サービスが提供される。例えば、レストランは、飲食物を提供するサービス提供施設であり、また、スーパーマーケットは、食品や日用品を販売するサービス提供施設である。

周辺物情報提示機能が提示する周辺物情報としては、例えば、施設の名称（例えば東京タワー）、種類（例えば、レストラン、ホテル、公園、学校、観光名所などの種類）、評価（例えば点数や、自由記述による感想）などが挙げられる。
なお、周辺物情報提示機能が提示する情報は、これらに限られない。周辺物が、外部の情報配信システムに登録された施設であれば、この外部の情報配信システムから提供される情報を、周辺物情報として提示してもよい。

端末装置２００としては、図１に示すように、ユーザが頭部に装着する眼鏡型の端末装置２００Ａが一例に挙げられる。
本実施形態では、ユーザがこのような眼鏡型の端末装置２００を装着して街を歩くと、そのユーザの視界内にある周辺物についての情報が眼鏡型の端末装置２００のディスプレイ２１７に表示される。より具体的には、ユーザの視界にある周辺物に対して周辺物情報が対応付けられて表示される。なお、周辺物情報は、眼鏡型の端末装置２００に加えて、または眼鏡型の端末装置２００に代えて、このユーザが携帯する他の端末装置２００（例えばスマートフォン型の端末装置２００や手首装着型の端末装置２００）で提示されてもよい。

図１５は、本実施形態にて実行される処理の流れの一例を示したフローチャートである。
なお、図１５にて示すこのフローチャートでは、ユーザが、端末装置２００として眼鏡型の端末装置２００を装着している場合を想定する。
この処理例では、眼鏡型の端末装置２００を装着したユーザの移動が開始されたことを検知すると（ステップＳ１０１）、このユーザの予定情報を基に、このユーザの行き先を特定する（ステップＳ１０２）。

次いで、ユーザに道案内をすべきか判断し（ステップＳ１０３）、道案内をすべきと判断した場合、道案内機能を有効にする（ステップＳ１０４）。その後、ステップＳ１０５の処理に進む。
一方、ステップＳ１０３にて、道案内をすべきと判断しなかった場合、道案内機能を有効にせずに、ステップＳ１０５の処理に進む。

ステップＳ１０５では、ユーザに周辺物情報の提示を行うべきかを判断する（ステップＳ１０５）。
そして、周辺物情報の提示を行うべきと判断した場合、周辺物情報提示機能を有効にしたうえで（ステップＳ１０６）、ステップＳ１０７の処理に進む。
一方、ステップＳ１０５にて、周辺物情報の提示を行うべきと判断しなかった場合、周辺物情報提示機能を有効にせずに、ステップＳ１０７の処理に進む。
その後、本実施形態では、ユーザの移動の終了を検知すると（ステップＳ１０７）、道案内機能、周辺物情報提示機能を無効にする（ステップＳ１０８）。
より具体的には、ユーザの移動の終了を検知した場合において、道案内機能、周辺物情報提示機能が有効となっている場合には、これらの機能を無効にする。

図１６は、他の処理例を示したフローチャートである。
図１６にて示すこの処理では、まず、ユーザの過去の移動履歴を取得する（ステップＳ２０１）。具体的には、例えば、眼鏡型の端末装置２００に設けられたＧＰＳにより得られた情報であって、外部サーバ１００の情報記憶装置１０２に格納された過去の情報を取得して、ユーザの過去の移動の履歴についての情報を取得する。
本実施形態では、ユーザの過去の移動の履歴についての情報は、外部サーバ１００の情報記憶装置１０２に格納され、この情報記憶装置１０２に格納された情報を参照することで、ユーザの過去の移動の履歴についての情報の取得を行える。
次いで、眼鏡型の端末装置２００に設けられたＧＰＳにより得られた情報を取得して、ユーザの現在地を特定する（ステップＳ２０２）。

なお、ステップＳ２０１では、移動履歴を取得する代わりに、又は、移動履歴に加えて、他の実情報を取得してもよい。
また、処理の順番は上記に限られず、先に、ユーザの現在地を特定し、次いで、ユーザの過去の移動履歴についての情報を取得してもよい。

ステップＳ２０３では、現在地から、ユーザの行き先までの経路を、ユーザが予め定められた閾値以上の頻度で通ったことがあるかを判断する（ステップＳ２０３）。
そして、ステップＳ２０３にて、現在地から行き先までの経路をユーザが予め定められた閾値以上の頻度で通ったことがあると判断した場合、ユーザへの道案内を行わないことを決定する（ステップＳ２０４）。
一方、ステップＳ２０３にて、現在地から行き先までの経路をユーザが予め定められた閾値以上の頻度で通ったことがあると判断しなかった場合、ユーザへの道案内を行うことを決定する（ステップＳ２０５）。この場合、道案内機能を有効にすることになる。

図１７は、他の処理例を示したフローチャートである。
この処理例では、まず、ユーザの予定情報を基に、ユーザの次の予定の場所についての情報と、この次の予定の開始時刻についての情報とを取得する（ステップＳ３０１）。なお、開始時刻に限らず、終了時刻についての情報を取得してもよい。また、開始時刻についての情報、終了時刻についての情報の両者を取得してもよい。
次いで、現在時刻についての情報と、ユーザの現在地についての情報とを取得する（ステップＳ３０２）。

言い換えると、本実施形態では、ステップＳ３０１にて、外部サーバ１００のＣＰＵ１１１は、予定情報として、予定の開始時刻および終了時刻の少なくとも一方と、予定の開催場所についての情報とを少なくとも取得する。
なお、処理の順番はこれに限らず、現在時刻、現在地についての情報を先に取得し、次いで、次の予定の場所、次の予定の開始時刻についての情報を取得してもよい。

次いで、この処理例では、ステップＳ３０３にて、残り時間に余裕があるかを判断する。
「残り時間」とは、現在時刻から次の予定の開始時刻までの残り時間から、現在地から次の予定の開催場所までの移動に要する所要時間を減じることにより得られる時間を言う。
そして、本実施形態では、ステップＳ３０３にて、残り時間に余裕があると判断した場合、ＣＰＵ１１１は、周辺物情報を提示するとの決定を行う（ステップＳ３０４）。
言い換えると、この場合、ＣＰＵ１１１は、ユーザの周辺物についての情報をユーザに提示するとの決定を行う。この場合、周辺物情報提示機能が有効にされる。

一方、ステップＳ３０３にて、残り時間に余裕があると判断しなかった場合、ＣＰＵ１１１は、周辺物情報を提示しないとの決定を行う（ステップＳ３０５）。

本実施形態では、ＣＰＵ１１１は、このように、現在時刻から予定の開始時刻までの残り時間と、現在地から予定の開催場所への移動にかかる所要時間とに基づき、ユーザに提示する周辺物情報についての決定を行う。
なお、ＣＰＵ１１１は、現在時刻から開始時刻までの残り時間に対して、現在地から開催場所への移動にかかる所要時間が占める割合が大きいほど、表示画面の情報量が少なくなるように、表示画面における表示内容を制御してもよい。

ここで、残り時間に対する所要時間の占める割合が大きいほど、表示画面の情報量が少なくなるようにする処理を行う場合、例えば、ユーザが目的地への移動する際、移動開始直後は多くの情報を表示していても（例えば「情報量：多め」モードで制御していても）、移動中に信号にたくさん引っ掛かったり、寄り道をしたりすると、残り時間に対して所要時間が占める割合が大きくなり、表示画面の情報量が少なくなる（例えば「情報量：少なめ」モードで制御する）。
また、例えば、友人から途中で連絡があり予定の時間が後ろにずれた場合や、所要時間を求めた際の基準としたユーザの移動速度よりも大きい移動速度でユーザが移動した場合（例えば、徒歩を基準として移動速度を求めていたがユーザが実際には走って移動した場合）には、移動開始直後は少ない情報を表示していても（例えば「情報量：少なめ」モードで制御していても）、移動中に残り時間に対して所要時間が占める割合が小さくなり、表示画面の情報量が多くなる（例えば「情報量：多め」モードで制御する）。

また、本実施形態では、ＣＰＵ１１１は、ユーザが実質的に同じ場所に滞在している場合であっても、時間が経過すると周辺物情報の決定を繰り返し行う。
言い換えると、本実施形態では、ＣＰＵ１１１は、ユーザが実質的に同じ場所に滞在しユーザが移動していない場合であっても、予め定められた時間が経過する度に、周辺物情報の提示についての決定を行う。
これにより、予め定められた一定の時間が経過する度に、ユーザの端末装置２００における表示が最新のものとなる。

図１８は、他の処理例を示したフローチャートである。
この処理例では、まず、ユーザの予定情報を取得する（ステップＳ４０１）。次いで、このユーザの周辺に存在する周辺物の特定を行う（ステップＳ４０２）。なお、周辺物の特定を先に行い、次いで、ユーザの予定情報を取得してもよい。
また、ステップＳ４０１の処理では、ユーザの予定情報の代わりに、又は、この予定情報に加えて、実情報を取得してもよい。

次いで、この処理では、ステップＳ４０３にて、ステップＳ４０２にて特定した周辺物についての情報である周辺物情報をユーザに提示した場合に、このユーザが提示された情報に反応しそうであるかを判断する。ここで、提示された情報に反応するとは、提示されたリンクをクリックしたり、提示された施設を予約したり、提示された施設を訪れたりすることを指す。
そして、ステップＳ４０３にて、ユーザが反応しそうであると判断した場合、周辺物情報をユーザに提示するとの決定を行う（ステップＳ４０４）。この場合、この周辺物情報が表示される。
一方、ステップＳ４０３にて、反応しそうであると判断しなかった場合、周辺物情報をユーザに提示しないとの決定を行う（ステップＳ４０５）。この場合、この周辺物情報の表示は行われない。
なお、ユーザが提示された情報に反応しそうであるか否かは、一例として、ユーザが提示された情報に反応する可能性を求め、その値が閾値以上であるか未満であるかによって判断することができる。

図１９は、他の処理例を示したフローチャートである。
この処理例では、まず、ユーザの周辺に存在する周辺物を特定する（ステップＳ５０１）。なお、ここでユーザの周辺に存在する周辺物が複数あれば、複数の周辺物を特定してもよい。次いで、特定された周辺物についての情報（周辺物情報）を取得する。複数の周辺物を特定した場合は、それぞれの周辺物についての情報を取得する（ステップＳ５０２）。

次いで、取得された周辺物情報の各々について、ユーザが関心があるかを判断する（ステップＳ５０３）。そして、関心があると判断した周辺物情報については、ユーザに提示されるようにする決定を行う（ステップＳ５０４）。この場合、この周辺物情報は、ユーザに提示される。
一方、関心があると判断しなかった周辺物情報については、ユーザに提示されないようにする決定を行う（ステップＳ５０５）。この場合、この周辺物情報は、ユーザに提示されない。

本実施形態では、ＣＰＵ１１１は、各周辺物についての、ユーザの関心度情報を取得する。
そして、ＣＰＵ１１１は、予定情報とこの関心度情報とに基づき、表示画面における表示内容を決定する。

なお、予定情報および関心度情報の両者に基づかずに、関心度情報のみに基づき、表示画面における表示内容を決定してもよい。
また、ユーザが関心を有しているものの特定にあたっては、具体的な施設（例えばレストランＮ）や具体的な商品（例えばレストランＮのランチコースＡ）を特定してよいし、これに限らず、ユーザが関心を抱いているより大きな対象（例えばグルメ）を特定してもよい。
図１９に示す処理例では、ユーザが関心がある周辺物の情報が、ユーザに提示される。
なお、図１７～図１９の処理例では、ユーザの周辺にあると特定された周辺物の情報の提示に関する決定を行ったが、後述するように、周辺物の情報に加えて、または、周辺物の情報の代わりに、ユーザの周辺にないが周辺物と予め定められた関係にある関連物の情報の提示に関する決定を行う場合にも、図１７～図１９の処理を参考に、予定情報、実情報、または、その両方に基づいて、関連物の情報の提示に関する決定を行うことができる。

図２０、図２１を参照しながら、処理の具体例を説明する。
図２０、図２１は、ユーザの移動経路を示した図である。
まず、処理の前提を説明する。
以下では、ユーザＹが街を移動する場合における処理を説明する。
ユーザＹのカレンダー（予定情報の一例）によれば、ユーザＹの３／１４（日）の予定として、１２：００～１４：３０に、友人Ｓと、レストランＮ（図２０参照）というレストランで、ランチするという予定が登録されている。
言い換えると、ユーザＹの予定情報によれば、ユーザＹは、３／１４（日）の１２：００～１４：３０に、友人Ｓと、レストランＮというレストランで、食事をとることになっている。
レストランＮは、渋谷駅から徒歩５分のところにある。また、ユーザＹは、池袋駅（図２１）から、徒歩８分のところに住んでいる。池袋駅は、渋谷駅から電車で１０分のところにある駅である。

３／１４(日)におけるユーザＹの行動は、以下の通りである。
・１０：３０ 自宅を出発
・１０：４０ 最寄り駅の池袋駅から、渋谷駅に行く電車に乗る。
・１０：５０ 渋谷駅（図２０参照）に到着。洋服店Ｔに向かう。
ユーザＹは、渋谷駅で電車を降りた後、予定としては入っていないが、以前から行きたいと思っていた洋服店Ｔに向かって歩き始める。なお、図２０に示すように、洋服店Ｔは、渋谷駅を挟んでレストランＮとは反対側の方面にある。
・１０：５５ 洋服店Ｔに到着。
ユーザＹは、洋服店Ｔでスーツを購入し、裾上げを依頼する。
裾上げの完了予定は、３／１４(日)の１５：００であった。ユーザＹは、店舗名と引取期間が記載されたメールを受け取る。引換え期間の終期（期限の一例）は、１週間後であった。

・１１：２０ 洋服店Ｔを出発。レストランＮのある方向に向かって歩き始める。洋服店ＴからレストランＮまでの所要時間は、最短で１５分となっている。
・１１：３５ 公園Ｓに到着。時間を潰す。
・１１：５５ レストランＮに到着。
・１４：３０ レストランＮを出発。
・１４：３５ 書店Ｅに立ち寄る。
・１５：４０ 書店Ｅを出発。
・１５：００ 洋服店Ｔに到着。裾上げが完了したスーツを引き取る。
・１５：０５ 洋服店Ｔを出発。
・１５：１０ 渋谷駅に到着。
・１５：１５ 渋谷駅から池袋駅に行く電車に乗る。
・１５：２５ 池袋駅（図２１参照）に到着。歩き始める。
・１５：３０ ベーカリーＫに到着。パンを買う。
・１５：４５ スーパーマーケットＦに到着。夕食用の食材を買う。
・１６：１５ 帰宅。

以上の前提の基、本実施形態にて実行される処理の詳細を説明する。
〔スマートフォンの経路検索アプリケーションで確認〕
ユーザＹは、自宅（図２１参照）を出発する前に、自宅からレストランＮまでの経路を、スマートフォンの経路検索アプリで検索した
そして、ユーザＹは、複数の検索結果の中から、「３／１４(日) 徒歩(８分)→ＪＲ山手線（１０：４０池袋駅→１０：５０渋谷駅）→徒歩(５分)」という経路を選択した。

また、ユーザＹは、経路検索アプリケーションを閉じず、選択した経路が表示された表示画面を開いたまま、スマートフォンを携行した。言い換えると、ユーザＹは、経路検索アプリケーションがアクティブな状態のスマートフォンを携行した。
「ＪＲ山手線（１０：４０池袋駅→１０：５０渋谷駅）」は、ユーザＹのカレンダーから取得される予定情報ではないが、ユーザＹの選択履歴から取得される予定情報であり、ユーザＹの予定情報の一例である。

〔ウェアラブルな端末装置を装着〕
ユーザＹはこの日、端末装置２００として、スマートフォン型の端末装置２００を携行し、さらに、スマートフォン型の端末装置２００と無線通信（例えばBluetooth）で接続された、眼鏡型の端末装置２００Ａ、および、手首装着型の端末装置２００Ｂを装着してその日の１日を過ごした。
この処理例では、眼鏡型の端末装置２００のカメラ２１４（図１参照）により、ユーザＹの視界にあるものについての情報が取得される。
また、この処理例では、眼鏡型の端末装置２００のカメラ２１４やセンサ２１３により、ユーザＹの位置情報、ユーザＹのバイタルサイン（心拍、血圧、呼吸、体温、血糖値、酸素レベル、意識状態、脳波、瞳孔反応など）などが取得される。
取得されたこれらの情報は、例えば、外部サーバ１００に設けられた情報記憶装置１０２に保存される。

また、この処理例では、手首装着型の端末装置２００のセンサによっても、ユーザＹの位置情報、ユーザＹのバイタルサイン（心拍、血圧、呼吸、体温、血糖値、酸素レベル、意識状態など）が取得される。
取得されたこれらの情報は、同様に、例えば、外部サーバ１００の情報記憶装置１０２に保存される。

情報記憶装置１０２には、ユーザＹについて取得した過去の情報も保存されている。
本実施形態では、情報記憶装置１０２に格納された情報を基に、ユーザＹの状態や、ユーザＹが関心を持っていることを特定できる。
言い換えると、本実施形態では、対象がユーザの視界に存在した過去の時点でのこの対象に対する関心を示す情報が、情報記憶装置１０２に格納されている。

本実施形態では、関心度情報も考慮して、表示画面における表示内容を決定する。ここで、この関心度情報は、対象がユーザの視界に存在した過去の時点でのユーザのこの対象に対する関心を示す情報である。
なお、ユーザＹの状態や、ユーザＹが関心を持っている対象を特定するにあたっては、情報記憶装置１０２に格納された情報を単独で用いてもよいし、情報記憶装置１０２に格納された複数の情報を組み合わせて用いてもよい。

本実施形態では、例えば、ユーザＹが、特定の周辺物を予め定められた時間を超えて見ていた場合に、この特定の周辺物についての情報と、この特定の周辺物を見ていたときに得られたバイタルサインとが関連付けられた状態で情報記憶装置１０２に格納される。
この場合、情報記憶装置１０２に格納されたこの情報を取得することで、ユーザＹが関心を持っていることを特定できる。
言い換えると、この場合、ＣＰＵ１１１は、ユーザの生体から得られる情報であるバイタル情報を利用する。そして、このバイタル情報を基に、ユーザが関心を持っていることを特定する。

具体的には、この場合、例えば、特定の周辺物に対して対応付けられたバイタルサインに含まれる心拍数が、通常の平均値よりも大きい場合に、ユーザＹがこの特定の周辺物に関心を持っていることを特定できる。
また、本実施形態のように、ユーザＹのバイタルサインを取得する場合、このバイタルサインを基に、ユーザＹの疲労度、空腹度、発熱の有無などを特定できる。

〔位置情報の追跡〕
ユーザＹは、ユーザと共に移動する端末装置２００のうち少なくとも１つにおいて、位置情報機能(例えばＧＰＳ)を有効にした。また、ユーザＹは、位置情報機能を有効にした状態で、その日の１日を過ごした。
ユーザＹの位置情報は、外部サーバ１００に設けられた情報記憶装置１０２に保存される。
なお、この情報記憶装置１０２には、ユーザＹについて得られた過去の位置情報も保存されている。

本実施形態では、この過去の位置情報を基に、ユーザＹの過去の行動傾向を分析したり、ユーザＹの未来の行動を予測したり、ユーザＹの現在の行動の特異度についての情報を取得したりする。
ユーザＹの現在の行動の特異度は、例えば、ユーザＹがいる道が、普段通っている道と同じであるかについての情報や、ユーザＹの現在地が、ユーザＹが普段よく訪れる場所であるかについての情報に基づき求める。

ユーザＹがいる道が、普段通っている道と同じである場合や、ユーザＹの現在地が、ユーザＹが普段よく訪れる場所である場合、特異度は小さくなる。
また、ユーザＹがいる道が、普段通っている道ではない場合や、ユーザＹの現在地が、ユーザＹが普段よく訪れる場所でない場合、特異度は大きくなる。

また、本実施形態では、ユーザの過去の位置情報を参照することで、ユーザのカレンダー（予定情報の一例）には登録はされてはいないが、実質的にユーザの予定として組み込まれている予定を特定できる。
具体的には、例えば、過去の位置情報を基に、特定の曜日の特定の時間帯に、特定の場所にいるなどの情報を取得した場合に、特定の曜日の特定の時間帯に、特定の場所にいるというユーザの実質的な予定の特定を行える。

ユーザＹの過去の位置情報は、ユーザＹの行動の履歴についての情報とも言える。
ユーザＹの位置情報により特定される位置が、例えばレストランである場合、ユーザＹが、このレストランで食事をとったことを推定できる。
なお、その他に、店舗での購入履歴や、電子決済システムを利用した際の決済履歴、予約システムにおける予約履歴などに基づいても、ユーザＹの行動の履歴を特定できる。

〔自宅を出発し、最寄りの池袋駅に向かう〕
ユーザＹは、日頃、自宅（図２１参照）と、最寄り駅である池袋駅とを結ぶ経路を頻繁に通っている。
具体的には、ユーザＹは、通勤の際や、他の駅に行く際、池袋駅からの電車に乗ることが多く、ユーザＹは、日頃、自宅と、最寄り駅である池袋駅とを結ぶ経路（自宅と池袋駅との間の道路）を頻繁に通っている。

ここで、ユーザが普段頻繁に通る経路に、このユーザがいる場合や、ユーザの日常の行動範囲に、このユーザがいる場合は、ユーザに対して周辺物情報を提示しないという処理を行ってもよい。
また、ユーザが普段頻繁に通る経路に、このユーザがいる場合や、ユーザの日常の行動範囲に、このユーザがいる場合は、ユーザに対して、特定の種類の周辺物情報のみを提示する処理を行ってもよい。
具体的には、例えば、ユーザが周辺物を通過したときのタイミングを含む予め定められた一定の期間内でのみ有効な情報（キャンペーン情報など）のみを提示する処理を行ってもよい。

ここで、例えば、ユーザＹがほぼ毎日通っている経路上にある店舗について、ユーザＹに対し、「営業時間：９：００～２０：００（年中無休）」「評価：★★★★☆」のような情報を提示しても、この情報は、このユーザＹには有用ではない可能性が高い。
ユーザＹに有用な情報としては、例えば、その店舗の通常とは異なる、特別な、あるいはイレギュラーな事柄についての情報がある。例えば、「本日限り！卵１パック９８円」、「只今ハッピーアワー中です」、「３／３１は年度末決算のため臨時休業します」等の情報である。なお、開催中の特売情報などは、ユーザＹが対象となる店舗を通過したときのタイミングを含む予め定められた一定の期間内でのみ有効な情報であるとも言える。

以上の事情に鑑み、周辺物情報を提示する場合は、周辺物情報を一律に提示するのではなく、ユーザの情報に応じて、提示する周辺物情報の内容を変えることが好ましい。
言い換えると、周辺物情報を提示する場合は、ユーザの情報に応じて、周辺物情報のうちの特定の周辺物情報が、他の周辺物情報よりも優先して表示されるようにすることが好ましい。

なお、ユーザが普段頻繁に通る経路や、ユーザの日常の行動範囲については、ユーザに入力してもらうようにし、この入力された情報を基に、ユーザが普段頻繁に通る経路や、ユーザの日常の行動範囲を特定してもよい。
ユーザが普段頻繁に通る経路や、ユーザの日常の行動範囲についての情報をユーザに入力してもらう場合は、例えば、ユーザに、経路や行動範囲を指定してもらうようにする。

具体的には、例えば、ユーザに最寄り駅や自宅の場所を設定してもらうようにし、最寄り駅と自宅の場所との結ぶ経路を、頻繁に通る経路としてもよい。
また、最寄り駅と自宅の場所との結ぶ経路を含む一定の範囲を、ユーザの日常の行動範囲としてもよい。
また、ユーザが普段頻繁に通る経路や、ユーザの日常の行動範囲は、ユーザの過去の移動履歴や行動履歴を基に特定してもよい。

また、ユーザへの周辺物情報の提示にあたり、ユーザが「行きか帰りか」を判断してもよい。
言い換えると、ユーザへの周辺物情報の提示にあたり、ユーザが目的地に向かって行く途中にあるのか、あるいは、ユーザが自宅に向かって帰る途中にあるのかを判断してもよい。

例えば、ユーザＹが、自宅を出発し最寄りの池袋駅に向かう途中にある場合、ユーザが目的地に向かって行く途中にあると考えることができ、この場合、帰宅の途中ではない。
この場合、ユーザＹが、その日の夕食で使う生鮮食材を経路上のスーパーマーケットで買おうとしている場合であっても、目的地に向かう途中に生鮮食品をユーザが買うことは考えにくい。
このため、「行きか帰りか」を判別するようにし、この判別の結果に基づき、周辺物情報の提示についての決定を行うことが好ましい。
上記の夕食で使う生鮮食材についての情報は、ユーザが自宅に向かって帰る途中に提示されるようにすることが好ましい。

ユーザが、目的地に向かう途中であるか、帰宅途中であるかは、ユーザの移動方向、ユーザの移動履歴や行動履歴から割り出した行動傾向、ユーザの予定情報などに基づき判断する。これらの情報は、単独で用いてもよいし、組み合わせて用いてもよい。
ユーザの予定情報に基づく場合は、例えば、現在時刻以降にユーザの予定が入っているか否かを判断するようにする。
そして、例えば、現在時刻以降にユーザの予定が入っている場合は、ユーザが目的地に向かう途中にあると判断する。また、例えば、現在時刻以降にユーザの予定が入っていない場合は、ユーザが帰宅途中にあると判断する。

言い換えると、ユーザが、対象となるスーパーマーケットが存在する経路を予め定められた期間内に通るか否かを予定情報に基づき判断し、この判断の結果によって、周辺物情報の内容を異ならせるようにしてもよい。
具体的には、例えば、上記のように、ユーザがスーパーマーケットの前にいる場合において、現在時刻以降にユーザの予定が入っていない場合は、スーパーマーケットが存在する経路を予め定められた期間内にユーザが通らないと判断する。この場合、スーパーマーケットについての情報が提示されるようにする。
より具体的には、ユーザがスーパーマーケットの前にいる場合において、ユーザのその日の予定として、現在時刻以降にユーザの予定が入っていない場合、スーパーマーケットが存在する経路を予め定められた期間（例えば、その日の２４時までの期間）内にユーザが通らないと判断する。この場合、スーパーマーケットについての情報が提示されるようにする。

一方、例えば、ユーザがスーパーマーケットの前にいる場合において、現在時刻以降にユーザの予定が入っている場合は、スーパーマーケットが存在する経路を予め定められた期間内にユーザが再び通ると判断する。
より具体的には、ユーザがスーパーマーケットの前にいる場合において、ユーザのその日の予定として、現在時刻以降にユーザの予定が入っている場合、スーパーマーケットが存在する経路を予め定められた期間（例えば、その日の２４時までの期間）内にユーザが再び通ると判断する。
この場合、スーパーマーケットについての情報がこの時点では提示されないようにする。この場合、ユーザが後にスーパーマーケットに再び来た際に、スーパーマーケットについての情報が提示される。

ユーザが帰宅途中に提示されることが好ましい情報としては、重い商品についての情報や、要冷蔵や要冷凍の商品についての情報や、いつでも売っており販売時間が特に制限されていない商品についての情報が一例に挙げられる。
また、ユーザが帰宅途中に提示されることが好ましい情報としては、その他に、例えば、ユーザの帰宅の時間帯のときにしか売っていない商品についての情報や、ユーザの帰宅の時間帯に特に安くなっている商品についての情報や、ユーザが自身のために買う商品についての情報や、ユーザが家族のために買う商品についての情報が挙げられる。

また、ユーザが出かける途中に提示されることが好ましい情報としては、例えば、ユーザの帰宅時間にはやっていないタイムセールについての情報や、帰宅時間には店が閉まってしまうことを示す情報が一例に挙げられる。
また、ユーザが出かける途中に提示されることが好ましい情報としては、その他に、例えば、その日の予定で使うものについての情報や、その日の予定で使うものを売っている店舗の情報や、その日の予定の開催場所の近辺では手に入らない商品についての情報や、その日の予定の開催場所の近辺では手に入らない商品を売っている店舗の情報が挙げられる。
なお、上記の、その日の予定で使うものとしては、例えば、その日の予定に必要な持ち物や、その日会うことになっている人に渡すプレゼントなどが一例に挙げられる。

具体的な処理についてさらに説明を続ける。
この処理例では、ユーザＹは、１０：３０に自宅を出発しており、ユーザＹが、選択経路に含まれる「ＪＲ山手線（１０：４０池袋→１０：５０渋谷）」に乗る場合、ユーザＹには、時間的な余裕がほとんどない状態となる。
この場合、ユーザＹは、経路の途中にある店舗に寄って買い物をしている余裕はない。
このような状況にある場合、ＣＰＵ１１１は、周辺物情報の提示を行わないようにしたり、提示される周辺物情報を減らしたりする処理を行う。

言い換えると、本実施形態では、ユーザＹの現在地から次の予定の場所（ここでは池袋駅）への移動に要する所要時間と、現在時刻から次の予定の開始時刻（ここでは電車の出発時刻１０：４０）までの時間との差を取得して、この差に基づき、ユーザＹの余裕度を取得する。
そして、この余裕度に基づき、周辺物情報を提示するか否かの決定や、周辺物情報の内容や量についての決定を行う。

〔池袋駅から渋谷駅に行く電車に乗る〕
池袋駅から渋谷駅への、電車による移動経路は、ユーザＹの自宅からレストランＮへ行くための一般的な移動経路の一つである。池袋駅から渋谷駅への移動経路は、レストランＮがある方向に向かう移動経路である。
池袋駅から渋谷駅へのこの移動経路は、徒歩による移動経路ではなく、交通機関を利用する移動経路である。
この移動経路を通る電車は、徒歩よりも高速で移動する移動手段である。また、移動経路を通るこの電車は、公共の交通機関であり、一個人の意志では止まらない移動手段である。

池袋駅と渋谷駅の間には、新宿駅（不図示）があり、新宿駅のすぐ近くには、百貨店Ｉ新宿店がある。
ユーザＹが乗った電車が、新宿駅に近づくと、百貨店Ｉ新宿店に掲げられた「百貨店Ｉ」の看板が、ユーザＹの視界に入る。

本実施形態では、ＣＰＵ１１１は、ユーザが現在利用中の移動手段が特定の移動手段である場合、周辺物情報を表示しないよう制御する。なお、ユーザが、その後、特定の移動手段以外の移動手段で移動し始めた場合、周辺物情報が再び表示されるように制御する。
具体的には、本実施形態では、ユーザが電車に乗ったことが検知された場合、周辺物情報提示機能を無効にする。本実施形態では、ユーザが電車に乗っている場合、ユーザが周辺物に対してアクセスできないため、周辺物情報提示機能を無効にする。
また、本実施形態では、ユーザが、電車から降りたことが検知された場合、周辺物情報提示機能を有効にする。

本実施形態では、ユーザが利用する移動手段は、ユーザの現在地、移動速度、通過地点、電子決済の履歴情報（決済端末、決済額、決済場所などの情報）、移動手段の時刻情報、経路案内アプリケーションの使用状況、経路案内アプリケーションの検索履歴などから特定する。
移動手段としては、徒歩、自家用車、タクシー、電車、飛行機、フェリーなどが一例に挙げられるが、移動手段は、これらに限定されない。
また、移動手段は、「地上と地下」「陸、水上、空」「個人的な移動手段と公共交通機関」などの様々な分類が可能であるが、分類方法もこれらに限定されない。
また、移動手段は、「徒歩」や「ＪＲ山手線」のような個別具体的な移動手段であってもよいし、「時速ＸＸｋｍ以上の移動手段」のような包括的なものであってもよい。

電車などの公共交通機関に乗っているユーザに対し、百貨店Ｉ新宿店について「現在の混雑度：低」、「現在の駐車場：空きあり」などの情報を提示しても、ユーザは好きな場所で電車を止めることができないため、すぐに百貨店Ｉ新宿店に立ち寄ることはできない。つまり、百貨店Ｉ新宿店の現在の状況についての情報を提示しても、ユーザに有益であるとは言い難い。したがって、ユーザの視界に百貨店Ｉ新宿店が入っても、百貨店Ｉ新宿店についての情報の提示が行われないよう制御することが好ましい。
一方、例えば、百貨店Ｉ新宿店に入っているテナントの紹介やユーザによる百貨店Ｉ新宿店の評価など、百貨店Ｉ新宿店を説明する一般的な情報は、ユーザが将来百貨店Ｉを利用する際に役に立つ情報であり、ユーザに有用な情報となりうるため、このような一般的な情報はユーザにされるようにしてもよい。言い換えると、特定の移動手段で移動中のユーザに対して、百貨店Ｉ新宿店に関する特定の種類の情報のみを提示し、他の種類の情報を提示しないよう制御してもよい。

また、その他に、百貨店Ｉ新宿店が視界にあるユーザに対して、そのユーザの予定情報に基づいて、特定の情報を表示するか否かを決定してもよい。
例えば、ある特定の期間内に、特定の周辺物の付近をユーザが訪れる予定が入っているか否かを判断し、訪れる予定が入っている場合と入っていない場合とで、周辺物情報の表示の制御を変えてもよい。

具体的には、百貨店Ｉの情報として、「クーポン：３０００円以上購入でエコバック（登録商標）をプレゼント（３月３１日まで百貨店Ｉ全店で利用可）」という期間限定の情報があるとする。もし、ユーザＹが行く予定のある場所の近辺やそこまでの経路上に位置し、百貨店Ｉ新宿店と予め定められた関係にある関連物（例えば、同系列の百貨店Ｉ渋谷店）にもこの情報が関連している場合、この情報を百貨店Ｉ新宿店が視界内にあるユーザＹに提示した場合、ユーザは百貨店Ｉ渋谷店に立ち寄ろうと思わせることができる。

また、その他に、ユーザが百貨店Ｉ渋谷店の付近を通る予定の日時が、クーポンの有効期限内であることを条件として、百貨店Ｉ新宿店が視界にあるユーザにこのクーポンが提示されるようにすることが好ましい。

〔渋谷駅に到着し洋服店Ｔに向かう〕
本実施形態では、ユーザＹは、渋谷駅（図２０参照）で電車を降りた後、予定としてカレンダーに登録されていないが以前から行きたいと思っていた洋服店Ｔに向かって歩き始める。
なお、図２０に示すように、洋服店Ｔは、渋谷駅を挟み、レストランＮとは反対側の方面にある。
ここで、洋服店Ｔに向かっているユーザＹに対して、洋服店Ｔへの経路上にある他の店舗についての情報を提示したり、提示しすぎたりすると、ユーザＹがこの他の店舗に寄り道しすぎてしまい、ユーザＹは、「レストランＮでランチ」という、当初の目的を果たせなくなるおそれがある。

このため、この場合、ユーザに対して周辺物情報を提示するにあたっては、（１）ユーザの現在地と、（２）ユーザの次の予定の場所とこの予定の開始時刻とに基づいて、周辺物情報を提示するか否かの決定や、周辺物情報をどの程度提示するかについての決定を行うことが好ましくなる。
具体的には、この場合、ユーザの現在地から次の予定の場所（ここではレストランＮ）までの移動に要する所要時間と、現在時刻から次の予定の開始時刻までの残り時間との差を基に、周辺物情報を提示するか否かや、周辺物情報をどの程度提示するかについての決定を行うことが好ましくなる。
具体的には、例えば、上記の差が、閾値よりも小さい場合、周辺物情報を提示しないという決定や、周辺物情報の提示量を減らすという決定を行う。
また、その他に、上記の差が小さくなるに応じて、提示する周辺物情報の量を減らす処理を行ってもよい。

また、その他に、ユーザの進行方向に基づき、ユーザに周辺物情報を提示するか否かの決定や、周辺物情報をどの程度提示するかについての決定を行ってもよい。
具体的には、例えば、次の予定の場所へ向かう際に通る一般的な経路から外れてユーザが移動している場合や、次の予定の場所とは異なる方向に向かってユーザが移動している場合、ユーザに周辺物情報を提示しないとする決定や、周辺物情報の情報量を減らす決定を行う。

ユーザが、一般的な経路から外れて移動している場合や、次の予定の場所とは異なる方向に向かって移動している場合は、例えば、カレンダー（予定情報の一例）に登録されている次の予定の前に、カレンダーには登録されていない予定を果たすためにユーザが移動していることが想定される。
この場合、ユーザに情報を提示すると、逆にユーザに邪魔となる可能性があるため、上記の通り、ユーザに周辺物情報を提示しないとする決定や、周辺物情報の情報量を減らす決定を行ってもよい。

また、その他に、ユーザの端末装置２００に設けられたセンサ２１３による検知結果や、ユーザの端末装置２００に設けられたカメラ２１４により得られた映像を基に、周辺物情報の提示や道案内情報の提示に関する決定を行ってもよい。
具体的には、センサ２１３やカメラ２１４により得られた情報を基に、例えば、ユーザが、道に迷っていることを検知し、また、ユーザの心拍数などの生体情報を基に、ユーザが焦っていることを検知する。

この場合、例えば、周辺物情報の提示を停止したり周辺物情報の提示量を減らすなどの処理を行ったり、また、逆に、道案内機能を有効にして、道案内情報が表示されるようにする処理を行ったりする。
ここで、道案内情報としては、上記の通り、ユーザが通るべき道路を指し示す表示を行ったり、ユーザが向かうべき方向を示す矢印などを表示したり、経路から外れていることを警告する表示を行ったりする。

また、その他に、例えば、ユーザの移動速度についての情報を取得するようにし、この移動速度についての情報に基づき、周辺物情報の提示や、道案内情報の提示に関する決定を行ってもよい。
具体的には、例えば、ユーザの移動速度が予め定められた閾値より小さい場合、ユーザが急いでおらず、通り道にある施設などに立ち寄りながら移動を行っていると捉えることができ、この場合、周辺物情報が提示されるようにし、また、道案内情報が表示されないようにする。

また、例えば、ユーザの移動速度が予め定められた閾値以上である場合、例えば、ユーザが目的地に向かって移動していると捉えることができ、この場合、例えば、周辺物情報が提示されないようにし、道案内情報が表示されるようにする。
なお、ユーザの移動速度が小さくなる状況として、ユーザが通り道にある施設などに立ち寄りながら移動している場合以外に、ユーザが道に迷っている可能性もある。そこで、移動速度についての情報に代わって、または追加して、端末装置２００に設けられたセンサ２１３や、カメラ２１４の映像を基に、周辺物情報の提示や道案内情報の提示に関する決定を行ってもよい。

具体的には、ユーザが道に迷っている場合、焦って気持ちが落ち着かなくなったり、周りを頻繁に見回したり、標識や地図を見たりすることが考えられる。カメラ２１４が、ユーザが見ているものを捉えるように設けられている場合、ユーザが周りを頻繁に見回していることは、カメラ２１４の映像が捉えるものが横方向に閾値よりも速く頻繁に変化していることで特定でき、ユーザが標識や地図を見たことは、カメラ２１４により得られた映像に標識や地図がどの程度の時間にわたって入ったかによって特定できる。また、ユーザが焦っていることはユーザのバイタル情報（例えば心拍）に現れるため、例えば、端末装置２００に設けられたセンサ２１３により得られた心拍数が大きくなっている場合、ユーザが道に迷っていると判断する。
ユーザが道に迷っていると判断された場合、周辺物情報の提示を停止したり、周辺物情報の提示量を減らしたりする。また、ユーザが道に迷っていると判断された場合、道案内情報が提示されるようにしてもよい。

また、逆に、端末装置２００に設けられたカメラ２１４やセンサ２１３により、ユーザが迷っていることを示す上記のような事象が検知されない場合、ユーザが道に迷っていないと判断する。
この場合、周辺物情報を提示したり、周辺物情報の量を増やしたりする。また、この場合、道案内情報を非表示としたり、道案内についての情報の量を減らしたりする。

本実施形態のＣＰＵ１１１は、ユーザの状態を、このユーザの予定情報と、このユーザの生体から得られる情報であるバイタル情報及びこのユーザとともに移動するカメラ２１４により得られた映像の少なくとも一方とに基づき特定する。
そして、ＣＰＵ１１１は、特定した状態に応じて、上記のように、周辺物情報の提示を停止したり、周辺物情報の提示量を減らしたりする。また、この場合、ＣＰＵ１１１は、道案内情報が提示されるようにする。

言い換えると、ＣＰＵ１１１は、少なくとも予定情報に基づいて、ユーザが道に迷った状態にあるなど、ユーザが予め定められた状態にあることを特定する。
そして、ＣＰＵ１１１は、ユーザが予め定められた状態にあることが特定された場合、例えば、道案内情報がこのユーザに提示されるように制御する。

〔洋服店Ｔに到着〕
ユーザＹは、洋服店Ｔでスーツを購入し、裾上げを依頼する。裾上げの完了は、３／１４(日)の１５：００であった。また、ユーザＹは、店舗名と、スーツの引取期間とが記載されたメールを受け取った。引取期間は、１週間であった。
ユーザＹが受け取ったメールの「引取期間：３／１４(日)１５：００から１週間」という情報は、「ユーザＹのカレンダーから取得される予定情報」には該当しないが、「ユーザＹのメールから取得される予定情報」であり、「ユーザＹの予定情報」の一例である。

「３／１４(日)１２：００～１４：３０レストランＮでランチ」という予定は、ユーザＹを、３／１４(日)の１２：００～１４：３０の間、拘束する拘束型の予定である。
これに対し、「引取期間：３／１４(日)１５：００から１週間」は、この期間内のどこかのタイミングで特定の行為を行えばよい猶予型の予定である。
予定が拘束型であるか猶予型であるかは、ユーザが設定してもよい。また、その他に、予定の特徴などに基づいて、予定が拘束型であるか猶予型であるかを自動で判断してもよい。
自動で判断する場合、例えば、予約を伴う予定である会議、食事、運動、授業などの予定は、拘束型の予定と判断する。また、例えば、申込期間、引取期間などの期間が設定されている予定については、猶予型の予定と判断する。

〔洋服店Ｔを出発〕
ユーザは、洋服店Ｔを出発後、レストランＮのある方向に向かって歩き始める。洋服店ＴからレストランＮまでの所要時間は、最短で１５分である。
現在時刻は、１１：２０であり、レストランＮの予約時間である１２：００までの残り時間は、４０分である。

洋服店Ｔ、渋谷駅、レストランＮのそれぞれの周辺の繁栄度は、「渋谷駅＞洋服店Ｔ＞レストランＮ」である。レストランＮは、隠れ家的な場所にある。
ある場所の繁栄度は、例えば、その周辺（例えば半径５０ｍ内）に存在する店舗の数により求めることができ、店舗の数が多いほど、繁栄度が大きくなる。
本実施形態では、レストランＮの周辺の店舗数は、閾値よりも小さく、レストランＮの周辺の繁栄度は、閾値よりも小さい。

この場合、ユーザＹが、早いタイミングでレストランＮに着いてしまうと、周辺に時間を潰せる施設が少なく、ユーザは、暇を有する状態となってしまう。
このため、本実施形態では、ユーザＹがレストランＮの周辺にいる時よりも洋服店Ｔの周辺にいるとき、また、洋服店Ｔの周辺にいるときよりも渋谷駅周辺にいるときに、このユーザＹに対して、より多くの周辺物情報が提示されるようにする。

言い換えると、外部サーバ１００のＣＰＵ１１１は、ユーザの予定情報を基に特定されるユーザの経路上の繁栄度に基づいて、ユーザに提示する周辺物情報の内容を決定する。
外部サーバ１００のＣＰＵ１１１は、ユーザの予定情報を基に特定されるユーザの経路上の繁栄度に基づいて、ユーザに提示する周辺物情報の内容を決定してもよい。
ＣＰＵ１１１は、移動経路上のうちの繁栄度が高い箇所ほど、ユーザに対してより多くの情報が提示されるように、表示画面における表示内容を決定する。

より具体的には、本実施形態では、ユーザが現在地から予定の開催場所に向かう途中に通る通過予定物の分布が、現在地の方面に偏っているほど、この現在地の方面にいるユーザにより多くの周辺物が案内されるように周辺物を選定する。
また、本実施形態では、通過予定物の分布が、予定の開催場所の方面に偏っているほど、現在地方面にいるユーザにより少ない周辺物が案内されるように周辺物を選定する。

レストランＮの予約時間までの残り時間は、時間の経過とともに変化し、レストランＮまでの移動に要する時間である所要時間も、ユーザＹの行動によって変化する。
例えば、ユーザＹが、レストランＮまで向かう際に通る経路上にある店舗に滞在したり、迷子や寄り道などによって最短経路を外れたりする場合があり、これに応じ、残り時間と所要時間との比が変化する。

残り時間に余裕がある場合は、多くの周辺物情報を提示したり、個々の周辺物情報の情報量を多くしたりする。
これに対し、残り時間に余裕がなくなってきた場合には、提示する周辺物情報を減らしたり、周辺物情報の提示をやめたりすることが好ましい。
また、残り時間に余裕がなくなってきた場合には、ユーザＹが予定の開始時刻までに予定の場所に到着できるように、道案内を行うことが好ましい。

ユーザＹの予定情報によると、ユーザＹは、レストランＮで友人Ｓと会うことになっている。
ユーザＹがレストランＮに向かう途中において、ユーザＹの関心に合う周辺物情報をユーザＹに提示してもよいが、これに限らず、将来の予定であるランチに関連する人である友人Ｓの関心に合った周辺物情報をユーザＹに提示してもよい。

ユーザＹの関心に合う周辺物情報としては、例えば、ユーザＹがよく訪れる店舗のクーポンなどの情報が一例に挙げられる。
また、友人Ｓの関心に合った周辺物情報としては、友人Ｓの関心があるブランドを扱う店舗についての情報が一例に挙げられる。

例えば、友人ＳがＳＮＳでお気に入りのブランドとして登録しているブランドＧの店舗がユーザＹの視界に入ったときに、ユーザＹに対して、ブランドＧの店舗の情報を提示してもよい。より好ましくは、ブランドＧの店舗と友人Ｓの情報を関連付けて提示するとよい。例えば、ユーザＹに対して、「もうすぐあなたが会う予定の友人ＳはブランドＧが好きですよ」という情報を提示してもよい。より好ましくは、「クーポンを使って友人ＳにブランドＧのギフトセットを買ってあげましょう」という提案とともに、ギフトセットの１０％引きのクーポンを提示することによって、ユーザＹをブランドＧの店舗に誘導してもよい。

ユーザＹの予定情報には、友人Ｓについての情報など、ユーザＹ以外の人物である関連人物についての情報が含まれることがある。
ＣＰＵ１１１は、例えば、この関連人物が関心を示す店舗や、この関連人物が関心を示す商品を販売する店舗についての情報を、周辺物情報としてユーザＹに提示する。

なお、上記の友人Ｓのような特定の人物の関心事や関心の度合いは、例えば、友人ＳのＳＮＳのアカウントのお気に入りとして登録された情報に基づき特定できる。
また、その他に、友人ＳのＳＮＳでの活動や、友人Ｓの行動履歴などを基に、友人Ｓの関心事や関心の度合いを特定してもよい。
友人ＳのＳＮＳでの活動を基に、友人Ｓの関心事や関心の度合いを特定する場合は、例えば、友人Ｓが投稿したテキストや写真、友人Ｓがシェアした記事、友人Ｓが好評価を行った、友人Ｓ以外の人の投稿内容などを基に、友人Ｓの関心事や関心の度合いを特定する。
また、例えば、友人Ｓの位置情報、購買情報、友人Ｓが着用したスマートグラスが取得したバイタル情報、このスマートグラスが取得した、友人Ｓの視界についての情報などを基に、友人Ｓの関心事や関心の度合いを特定してもよい。

ユーザＹの次の予定は、レストランＮでの食事である。
これは、ユーザＹのカレンダー（予定情報）に登録された「友人Ｓとランチ」という文字列を解析することによって特定できるし、予定の場所がレストランＮというレストランであることからも特定できる。
この場合、レストランＮに向かっているユーザＹに対して、ラーメンショップＭを勧める情報を提示しても、ユーザＹが、ラーメンショップＭに立ち寄る可能性は低い。
ユーザＹに提示すべき周辺物情報は、ユーザの予定情報に基づいて決定することが好ましい。より具体的には、この場合、ユーザの予定情報と、周辺物が提供するサービスの内容とに基づき、ユーザＹに提示する周辺物情報を決定することが好ましい。

また、上記では説明を省略したが、ユーザＹは、前日に出張から帰ってきたばかりであり、ユーザＹは疲労している。
ユーザＹのカレンダーの先週分（過去の予定の一例）には、長時間の会議の予定が１０件以上入っている。言い換えると、ユーザＹのカレンダーの先週分には、複数の予定が入っている。

本実施形態では、ユーザの予定情報（過去の予定情報）や、ユーザのバイタル情報などに基づき、ユーザの疲労度を推定する。
ユーザのバイタル情報としては、例えば、睡眠についての情報が挙げられる。上記では説明を省略したが、ユーザＹは、池袋駅から渋谷駅に向かう電車の中で眠ってしまい、また、この睡眠の情報がバイタル情報として取得された。

本実施形態では、このように、ユーザが、本来予定されていないタイミングに眠ってしまった場合などに、ユーザの疲労度が高いと判断する。
なお、ユーザの疲労度は、予定情報、バイタル情報のうちの１つの情報を用いてもよいし、この２つの情報を組み合わせ用いてもよい。
また、ユーザの睡眠についての情報は、例えば、スマートフォンなどにインストールされた睡眠分析のアプリケーションを用いて取得してもよい。

ユーザＹの疲労度が高いと推定される場合、ＣＰＵ１１１は、マッサージ店Ａ（図２０参照）やアロマショップＫのようなリラクゼーションを提供する店舗を勧める情報を、周辺物情報としてユーザＹに提示する。
言い換えると、ＣＰＵ１１１は、予定情報に基づいてユーザが予め定められた状態にあることを特定する。そして、ＣＰＵ１１１は、ユーザの現在地の複数の周辺物のうち、この予め定められた状態に対応する特定の周辺物についての情報を、周辺物情報として、ユーザに提示する。

予定情報と、ユーザの生体から得られる情報であるバイタル情報と用いる場合、ＣＰＵ１１１は、この予定情報と、ユーザの生体から得られる情報であるバイタル情報とに基づき、表示画面における表示内容を決定することになる。
言い換えると、この場合、ＣＰＵ１１１は、予定情報と、ユーザの生体から得られる情報であるバイタル情報とに基づき、ユーザの疲労度を特定し、この疲労度に基づき、端末装置２００の表示画面における表示内容を決定する。
表示内容としては、例えば、ユーザに対してサービスを提供するサービス提供施設の利用を促す情報を挙げることができる。
マッサージ店Ａは、マッサージのサービスを提供する店舗である。アロマショップＫは、アロマキャンドルなどのリラクゼーションを提供する製品を販売する店舗である。

疲労度の特定は、予定情報、バイタル情報の両者に基づき行ってもよいし、予定情報、バイタル情報の一方の情報のみに基づき行ってもよい。
ここで、上記と同様、マッサージ店ＡやアロマショップＫについての情報は、ユーザの予定情報には含まれておらず、本実施形態では、ユーザの予定情報に基づき、この予定情報には含まれていない施設についての情報がユーザＹに提示される。

なお、その他に、ＣＰＵ１１１は、予定情報に基づいてユーザの状態の程度を特定してもよい。そして、ＣＰＵ１１１は、特定したこの程度に応じて、ユーザに提示する周辺物情報の量を制御してもよい。
具体的には、例えば、会議の件数に基づき、ユーザの疲労の程度を特定してもよい。

図２０に示す地図によれば、マッサージ店ＡとアロマショップＫは互いに近くに位置しており、ユーザの視界内に同時に入ることが可能である。複数のリラクゼーションを提供する施設がユーザの周辺にある場合、そのすべてをユーザに提示してもよいし、一部のみを提示してもよい。
一例として、ＣＰＵ１１１は、マッサージ店ＡとアロマショップＫの混雑状況によって、それぞれの施設の情報を提示するか否かを判断したり、それぞれの施設の情報を提示する優先度を変化させたりしてもよい。別の一例として、ＣＰＵ１１１は、マッサージ店ＡとアロマショップＫの予測滞在時間に基づいて、それぞれの施設の情報を提示するか否かを判断したり、それぞれの施設の情報を提示する優先度を変化させたりしてもよい。なお、各施設の混雑状況は、実際に施設にいる人の数により求めてもよいし、過去の同じ曜日の利用者数や同じ時間帯の利用者数により求めてもよいし、施設の予約状況により求めてもよい。

具体的には、ＣＰＵ１１１は、マッサージ店Ａの周辺にいるユーザＹの残り時間が、マッサージ店Ａを利用するには十分でないと判断した場合、マッサージ店Ａを勧める情報を提示しないか、あるいは、この情報の提示についての優先度を下げる。一例として、過去の利用者の履歴からマッサージ店Ａの平均滞在時間が１時間と算出され、ユーザＹの残り時間が２５分しかない場合、ＣＰＵ１１１はマッサージ店Ａを利用するには十分でないと判断する。また、別の一例として、本実施形態の情報処理システム１に登録されている、マッサージ店Ａが提供するサービスのメニューが、「マッサージ３０分／１５００円」であって、ユーザＹの残り時間が２５分しかない場合、ＣＰＵ１１１は、ユーザＹの残り時間（２５分）が、マッサージ店Ａを利用するには十分でないと判断する。

一方、アロマショップＫの周辺にいるユーザの残り時間が２５分であって、アロマショップＫの平均滞在時間が２０分である場合、ユーザＹにはアロマショップＫを利用するのに十分な時間が残っている。
この場合、本実施形態のＣＰＵ１１１は、周辺物情報として、アロマショップＫについての情報を提示すると決定する。
これにより、この例では、ユーザＹに対して、アロマショップＫを勧める情報が提示される。

ＣＰＵ１１１は、上記のように、ユーザの周囲に存在する周辺物（対象物）の各々の状況についての情報である状況情報を取得する。
具体的には、上記のように、ＣＰＵ１１１は、マッサージ等の提供を行う各周辺物の各々の状況情報として、例えば、施設を利用するのに要する時間を特定する。
そして、本実施形態のＣＰＵ１１１は、この状況情報も考慮して、各施設についての情報を周辺物情報に含めるか否かを決定する。言い換えると、本実施形態のＣＰＵ１１１は、予定情報と状況情報とに基づき、各施設についての情報を周辺物情報に含めるか否かを決定する。
これにより、上記のように、周辺物情報として、アロマショップＫについての情報が表示されるようになる一方で、マッサージ店Ａについての情報は表示されないようになる。

〔公園Ｓに到着、レストランＮに到着〕
ユーザＹが、洋服店ＴからレストランＮへ向かう途中、上記の通り、ユーザＹに対して、周辺物情報が提示された。しかしながら、ユーザＹは、結局、いずれの店舗にも寄ることはなかった。
その後、ユーザＹは、レストランＮの隣にある公園Ｓのベンチで、友人Ｓとの待ち合わせ時間まで昼寝をして過ごした。本実施形態では、この昼寝についての情報は、睡眠管理のアプリケーションによって、情報処理システム１に登録された。

ユーザＹの端末装置２００の周辺物情報提示機能が、有効になっていたとしても、ユーザＹに対して、周辺物情報が提示されない場合がある。
例えば、情報を提示できる周辺物がユーザＹの周囲にない場合や、ユーザＹに情報を提示すべきと判断された周辺物がない場合である。

周辺物情報提示機能が有効になっている場合、周辺物を探し続け、バッテリーの消耗や通信料の増加につながるため、特定の条件が満たされたら、周辺物情報提示機能を無効にしてもよい。
具体的には、例えば、周辺物が認識できない状況が一定時間続いたり、ユーザが同じ場所に滞在した状態が予め定められた時間を超えて継続したりしたら、周辺物情報提示機能を無効にしてもよい。

その後、ユーザＹは、レストランＮで、友人Ｓとランチをした。
ユーザＹは、自身が有するスマートフォンに、栄養管理のアプリケーションをインストールしている。
ユーザＹは、食事中、この栄養管理のアプリケーションで、食事についての記録を行った。具体的には、ユーザＹは、食べた時間、および、食べたものについての記録を行った。
また、ユーザＹは、出てきた料理の写真を撮った。また、ユーザＹは、ＳＮＳに、「友人Ｓとランチ」という説明文とともに、デザートの写真を投稿した。なお、この際、写真または投稿に、ユーザＹの位置情報が付された。

栄養管理のアプリケーションは、ユーザＹが摂取したカロリーや栄養素を記録する機能を有する。
摂取したカロリーや栄養素は、例えば、栄養管理のアプリケーションが、料理の写真（画像の一例）を解析することで特定される。
また、その他に、摂取したカロリーや栄養素についての情報は、店舗やデータベースから、この栄養管理のアプリケーションに提供されてもよい。

〔レストランＮを出発〕
ユーザＹがレストランＮを出発する際、ユーザＹは、満腹の状態である。
本実施形態では、以下の（ａ）～（ｇ）の情報を、個別に、又は、組み合わせて利用することによって、ユーザＹの空腹度を判断できる。

（ａ）ユーザＹの予定についての情報である、例えば、ユーザＹのカレンダーに登録された「友人Ｓとランチ@レストランＮ」という予定を基に、ユーザＹの空腹度を判断できる。これは、予定情報に基づき空腹度を判断するものである。つまり、ユーザＹがこの予定をキャンセルしたにも関わらずカレンダーから削除し忘れていた場合、ユーザＹの予定情報に基づいてユーザＹの空腹度を判断すると、誤った判断をしてしまう可能性がある。
（ｂ）また、レストランＮというレストランに２時間３５分滞在していたという位置情報および滞在時間情報を基に、ユーザＹの空腹度を判断できる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
しかし、ユーザＹがレストランＮに滞在していたとしても、滞在の目的が取材などの食事以外の目的であったり、レストランＮがユーザの職場であったりする可能性もある。
位置情報および滞在時間情報に基づく場合、ユーザＹが実際には食事をとっていないかもしれない可能性を無視してユーザＹの空腹度を判断することになる。
（ｃ）血糖値などの空腹度と関連するバイタル情報を基に、ユーザＹの空腹度を判断することができる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
なお、バイタル情報に基づく場合は、空腹度についての判断結果が、服用中の薬や持病による影響を受けるおそれがある。また、バイタル情報に基づく場合は、食後しばらくしないと、空腹度の変化が、バイタル情報の変化として現れない場合もある。
（ｄ）ユーザＹの栄養管理のアプリケーション上の食事の記録を基に、ユーザＹの空腹度を判断することができる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
なお、栄養管理のアプリケーションへの食事の記録は、ユーザが忘れてしまったり、実際に食事をとったタイミングから遅れて行われたりする場合があり、ユーザＹの空腹度の状態の判断にすぐには用いることができないおそれがある。
（ｅ）ユーザＹによるＳＮＳへの投稿（例えば「これ食べた」というテキストと食べたものの写真）を基に、ユーザＹの空腹度を判断することができる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
この場合は、ユーザがいつもＳＮＳへ投稿するとは限らず、また、食事の際や食後すぐに投稿されずに、遅れて投稿される場合がある。
（ｆ）レストランＮのメンバーシップカードにレストランを利用したことによるポイントが付与されたことに基づき、ユーザＹの空腹度を判断できる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
なお、このように、ポイントに基づく場合、メンバーシップカードを採用していない店舗では、空腹度の判断を行えない。また、メンバーシップカードの提示をユーザが忘れた場合は、ポイントが付与されないため、ポイントの付与歴による空腹度の判断は行えない。
（ｇ）レストランＮへの支払の記録を基に、ユーザＹの空腹度を判断することができる。より具体的には、店舗側のデータベースに登録された情報、ユーザＹの決済情報、家計簿のアプリケーションなどに登録された情報を基に、ユーザＹの空腹度を判断できる。これは、予定情報に基づくものではなく、実際に起きた事象に基づき、空腹度の判断を行うものである。
なお、この場合、ユーザＹ以外の者である友人Ｓが決済した場合や、現金で支払った場合、ユーザＹの空腹度の判断を行えないことになる。

ユーザの空腹度は、（ａ）～（ｇ）のいずれか一つのみによって行われてもよいが、上記の（ａ）～（ｇ）の判断要素の何れにおいても、短所が存在し、（ａ）～（ｇ）の判断要素の１つのみを用いると、ユーザの空腹度の判断の精度が低くなるおそれがある。このため、（ａ）～（ｇ）の判断要素のうちの複数の判断要素に基づいて、空腹度を判断することが好ましい。
特に、上記の（ａ）の予定情報に基づいて判断を行う判断要素と、（ｂ）～（ｇ）の判断要素のうちの何れか１つ以上の判断要素とを用いて、空腹度の判断を行うことが好ましい。
また、（ｂ）～（ｇ）の判断要素を用いる場合、センサ２１３を用いてユーザの生体から実際に取得された情報に基づきユーザの空腹度を判断する判断要素を用いることが好ましい。具体的には、（ｃ）の判断要素を用いることが好ましい。

その後、ユーザＹは、レストランＮを出て歩き始めた。
なお、この時点で、例えば、周辺物情報提示機能および道案内機能が無効になっている場合、ユーザＹの移動開始を検知したことに応じて、周辺物情報提示機能および道案内機能を有効にする。
ユーザＹの次の予定は、「洋服店Ｔ 引取期間：３／１４(日)１５：００～１週間」である。

この予定は、上記の通り、猶予型の予定である。また、ユーザＹがレストランＮを出た時点において、ユーザＹは、この予定の場所の近くにいる。
また、本実施形態では、ＣＰＵ１１１が、ユーザＹの３／２１(日)１５：００までの予定を検索した結果、引取期間である３／２１までに、現在位置よりも洋服店Ｔに近い場所へユーザが来る予定がないことが分かった。

この場合、本実施形態の周辺物情報提示機能は、ユーザＹに対して、「洋服店Ｔでの引取期間は本日１５：００から１週間です。今日を逃すとしばらく洋服店Ｔの近くまで来る予定がないようですが、今日、この後、引き取りに行きますか？」と尋ねる処理を行う。
そして、ユーザＹが、「はい」と答えた場合、周辺物情報提示機能は、「他にこの辺りで済ませたい用事はありますか？」とユーザＹに対して尋ねる。

そして、ユーザＹが、例えば「ないです」と答えると、周辺物情報提示機能が、「では、洋服店Ｔに着くまで、周辺施設のお得な情報をご案内します」というメッセージをユーザＹに提示し、周辺物情報提示機能は、周辺物情報の提示を開始する。
本実施形態では、次の予定の開始時刻は１５：００、レストランＮの出発時刻が１４：３０、レストランＮから洋服店Ｔまでは所要時間１５分となっている。
このため、本実施形態では、周辺物情報提示機能が有効にされ、周辺物情報提示機能による案内が開始される。

なお、この際、周辺物情報提示機能による、ユーザＹへの、洋服店Ｔへの到着時間についての問い合わせが行われるようにしてもよい。
具体的には、ユーザＹに対して、「洋服店Ｔにはいつ頃着きたいですか？」などの問い合わせを行って、ユーザＹに対し、洋服店Ｔへの到着時間の問い合わせを行ってもよい。
そして、ユーザＹが、「１５時より１０分くらい早め」「１６時くらい」などの回答を行った場合、周辺物情報提示機能は、この回答に応じて、周辺物情報の提示を行う。

周辺物の案内にあたっての基準の時刻を、「次の予定の開始時刻そのもの」とするのではなく、上記のように、ユーザが希望する時刻としてもよい。
ユーザによっては、大事な予定なので早く着きたいという希望を有していたり、早めに到着して他の作業を行ったりしたい場合がある。
この場合に、ユーザが希望する時刻の問い合わせをこのユーザに対して行うことで、周辺物の案内にあたっての基準の時刻を、ユーザが希望する時刻に対応させられる。

また、猶予型の予定の場合には、予定の開始時刻に間に合う必要性はない。
このため、猶予型の予定の場合は、時間的余裕の重みよりも、ユーザによる周辺物への関心の重みを大きくしたうえで、周辺物情報の提示が行われるようにしてもよい。
また、次の予定が、猶予型の予定の場合には、拘束型の予定である場合よりも多くの周辺物情報が提示されるようにする処理が行われるようにしてもよい。

〔書店Ｅに立ち寄る〕
ＣＰＵ１１１は、満腹状態にあるユーザＹへの飲食店についての情報の提示を控える。
また、渋谷駅の周辺は、ユーザＹの日常的な行動範囲内にある場所ではない。このため、ユーザＹには、日常的な行動範囲に存在する周辺物についての情報よりも、日常的な行動範囲に存在しない周辺物についての情報を優先して提示するようにする。
具体的には、ＣＰＵ１１１は、例えば、ユーザＹがレストランＮに向かう途中でこのユーザＹが関心を示した周辺物についての情報を提示する。

なお、これに限らず、ＣＰＵ１１１は、例えば、ユーザＹがレストランＮに向かう途中でこのユーザＹが関心を示した周辺物であって、且つ、ユーザＹが帰りにも関心を示した周辺物についての情報を提示するようにしてもよい。
また、その他に、例えば、ユーザＹがレストランＮに向かう途中でこのユーザＹが関心を示した周辺物について、ユーザＹに対して、「帰りに寄りたいですか？」などの問い合わせを行って、ユーザＹに本当に関心があるかを確認しておいてもよい。
そして、ユーザＹに本当に関心がある周辺物についての情報を、帰りの途中にあるユーザＹに提示してもよい。

また、ユーザＹが目的地に向かう途中に得られた情報に限らず、現在までに収集された情報に基づいて、ユーザＹへの情報の提示を行う周辺物を決定してもよい。
上記では説明を省略したが、ユーザＹは、車が好きであり、毎月第２日曜日に発売される車雑誌Ａという雑誌を欠かさず購入している。具体的には、ユーザＹは、第２日曜日や、その数日後くらいまでに、この雑誌を購入している。

本実施形態では、この雑誌の購入履歴が、決済アプリケーションの「決済履歴@書店」として蓄積されている。
また、この雑誌の購入履歴は、家計簿アプリケーションの購入履歴（例えば「Ｘ月Ｙ日：車雑誌Ａ（５００円）@水野書店」）としても蓄積されている。
また、この雑誌の購入履歴は、書店の販売履歴としても蓄積されている（顧客ＩＤ：yamada、販売日時：２０２０年２月１４日１５：３４：５０、購入商品：車雑誌Ａ）。

今日は、第２日曜日であり、ＣＰＵ１１１は、ユーザＹの過去の行動パターンから、ユーザＹは書店に行く可能性が高いと判断し、ユーザＹに対して、書店の情報を提示する。
言い換えると、ＣＰＵ１１１は、上記の購入履歴、販売履歴を基に、ユーザＹは書店に行く可能性が高いと判断し、ユーザＹに対して、書店の情報を提示する。
具体的には、ＣＰＵ１１１は、ユーザＹの購入の対象となっているもの（この例では車雑誌Ａ）の在庫がある書店を検索し、在庫がある書店をユーザＹに提示する。

この処理例では、書店Ｅに在庫があり、書店Ｅの情報がユーザＹに提示される。具体的には、ユーザの視界内に、この書店Ｅが入った際に、例えば、「車雑誌Ａ販売中」という情報を、ユーザＹに提示する。
その後、この処理例では、ユーザＹが、この情報に反応し、書店Ｅに入り、車雑誌Ａという雑誌を購入した。また、ユーザＹは、車雑誌Ａの近くにあった他の雑誌にも目を通した。

〔書店Ｅを出発〕
その後、ユーザＹは、書店Ｅを出発した。
この場合、ＣＰＵ１１１は、書店の優先度を下げる。具体的には、この場合、ユーザＹが雑誌を既に購入し書店に寄る目的が果たされたと考えられるため、ＣＰＵ１１１は、書店の優先度を下げる。
これにより、ユーザＹが、書店Ｅ以外の書店の前を今後通るときに、その書店が、周辺物情報の提示が行われる周辺物として選定されないようになる。

なお、ＣＰＵ１１１は、ユーザＹが書店Ｅを訪問した後に他の書店に入ったことが確認された場合、書店の優先度を再び上げてもよい。
この場合、ユーザＹが、例えば、書店巡りをしている可能性があると考えられるため、書店の優先度を上げることで、ユーザＹに有用な情報がユーザＹに提示される。
このように、ユーザが、ある特定の種類の店舗（書店、靴屋など）に複数回入った場合、この特定の種類の店舗の提示についての優先度を上げてもよい。

〔洋服店Ｔに到着。裾上げが完了したスーツを引き取る。〕
その後、ユーザＹは、洋服店Ｔに到着し、裾上げが完了したスーツを引き取った。その後、「引き取りありがとうございました」というメールが、ユーザに届いた。
これをもって、「引取期間：３／１４(日)１５：００～１週間」という予定の終了時間は、到来していないが、この予定は、すでに完了したとみなされる。

〔洋服店Ｔを出発〕
その後、ユーザＹは、渋谷駅へ向かって歩いた。
カレンダーからも、メールや予約システムからも、この日のこれ以降の時間帯のユーザＹの予定は抽出されなかった。
言い換えると、カレンダーからや、メールや予約システムなどから、情報を抽出して解析しても、ユーザＹの予定情報は抽出されなかった。この場合は、「次の予定まで時間を潰す」という状況ではない。

ユーザには、「早く帰宅したい派」と「早く帰宅したくない派」が存在すると考えられる。
「早く帰宅したい派」のユーザが寄りそうな場所は、スーパーや、日用品店などを扱っている店舗である。「早く帰宅したい派」のユーザは、カフェ、レストラン、ブランド店などには寄る可能性が低いと考えられる。
ユーザＹが、早く帰宅したい派であるか否かは、過去の行動情報を解析することで判断できる。具体的には、早く帰宅したい派であるか否かは、例えば、ユーザＹの１日の最後の予定の後に寄り道をする傾向があるか否かを基に判断できる。

ＣＰＵ１１１は、ユーザが帰路の途中にあるか否かを考慮する。
具体的には、ＣＰＵ１１１は、ユーザＹが自宅までの経路上を移動しているため、ユーザが帰路の途中にあると判断する。
そして、この場合、ＣＰＵ１１１は、ユーザが帰路の途中にあることを考慮して、ユーザへの情報の提示についての決定を行う。

帰路では、ユーザは、電車を渋谷駅で乗り、池袋駅に向かって移動する。
ＣＰＵ１１１は、荷物を持って電車に乗りたくない、食材や日用品などはできれば自宅の最寄り駅に着いてから買いたいなどのユーザの希望を考慮する。
また、帰宅時間が遅い場合などには、ユーザが移動している間に、このユーザの最寄り駅周辺のスーパーマーケットが閉まってしまう可能性もある。この場合、ユーザが良く訪れる場所（例えば最寄り駅周辺のスーパーマーケット）の閉店時間と、ユーザがそこを通る予定時刻とを比較し、ユーザが最寄り駅周辺のスーパーマーケットに着くころには閉まってしまう場合には、ユーザが渋谷駅近辺にあるスーパーマーケットを通ったときに、周辺物情報として渋谷駅近辺にあるスーパーマーケットの情報をユーザに提示することが好ましくなる。

例えば、ユーザが渋谷駅周辺を歩いているときにスーパーマーケットを通りかかった時に、「食材を買う必要はありませんか？この先の帰り道にもスーパーマーケットはありますが、あなたが着くころには閉まっているでしょう。ここで買っておくことをお勧めします」などの情報をユーザに提示する。

〔ユーザＹが渋谷駅に到着、渋谷駅から池袋駅に行く電車に乗る〕
この場合は、例えば、行きと同様、例えば、周辺物情報提示機能を無効にする。また、電車が池袋駅に着き、ユーザが、電車から降りたことが検知されたことに応じて、周辺物情報提示機能を有効にする。
より具体的には、ユーザが電車に乗ったことが検知された場合に、周辺物情報提示機能を無効にする。また、ユーザが、電車から降りたことが検知されたことに応じて、周辺物情報提示機能を有効にする。

〔池袋駅に到着、歩き始める〕
その後、ユーザＹは、池袋駅（図２１参照）に到着し、歩き始めた。
本実施形態では、上記の通り、ユーザが電車から降りたことが検知されたことに応じて、周辺物情報提示機能が有効にされる。
ここで、ユーザは、最寄り駅と自宅との間を頻繁に通っているため、通常、最寄り駅と自宅との間では、道案内情報の提示は必要ない。このため、ＣＰＵ１１１は、この場合、道案内情報の提示を行わないようにする。

但し、本実施形態では、ＣＰＵ１１１は、ユーザが帰り道によく購入するものや、よく立ち寄る店がある場合、このよく購入する物を扱う店舗や、よく立ち寄るこの店舗の前をユーザが通った際に、情報の提示を行ってもよい。
具体的には、ＣＰＵ１１１は、例えば、この店舗におけるお得な情報を周辺物情報として、ユーザに提示してもよい。お得な情報としては、例えば、この店舗の特売情報が挙げられる。

また、ＣＰＵ１１１は、特定の条件が満たされた場合、ユーザＹが普段は通らない道を案内する。これにより、ユーザＹの行動範囲が拡がる。
例えば、ＣＰＵ１１１は、例えば、ユーザが予め定められた期間内の最後の予定を終えた場合（例えば１日の最後の予定を終えた場合）に、ユーザが普段は通らない道へ進むことを提案する。

より具体的には、この場合、ＣＰＵ１１１は、現在時刻が、ユーザの予め定められた期限内の最後の予定よりも前であるか否かを判断する。
そして、ＣＰＵ１１１は、この判断の結果によって、ユーザに案内する道を異ならせる。
ＣＰＵ１１１は、判断の結果が、例えば、現在時刻が、ユーザの予め定められた期間内の最後の予定よりも後である場合、普段は通らない道へ進むことをユーザに提案する。
一方、ＣＰＵ１１１は、判断の結果が、例えば、現在時刻が、ユーザの予め定められた期限内の最後の予定よりも前である場合は、普段は通らない道へ進むことを提案しない。

ユーザＹは、ほぼ毎日、最寄り駅（池袋駅）から自宅までは最短経路を通る。
ところで、最近、ユーザＹが普段通っているこの道から１本外れた道に、ベーカリーＫというパン屋が新しくオープンした。
また、ユーザＹの購買履歴やＳＮＳの投稿から、ユーザＹがパン好きであることが判明した。

この場合、ＣＰＵ１１１は、例えば、「ここから徒歩２分くらいの場所に、ベーカリーＫというパン屋が昨日オープンしました。ご自宅までの最短所要時間にプラス５分くらいで、このベーカリーＫに寄ることができます。行ってみますか？地図で場所を確認したい場合は、スマートフォンを見てください」などのメッセージをユーザＹに提示することで、ユーザが普段は通らない道へ進むことを提案する。

ベーカリーＫまでの道は、ユーザＹが普段通らない道であるため、ユーザが提案された道へ進む場合（例えば、ユーザＹが「ベーカリーＫに行きたいです」と答えた場合）には、ＣＰＵ１１１は、道案内機能を有効にし、ベーカリーＫまでの道を案内してもよい。
なお、この際、ＣＰＵ１１１は、ベーカリーＫまでの道の案内を行いながら、ユーザＹがベーカリーＫに行くまでに通る経路沿いにある店舗についての情報を、周辺物情報としてユーザに提示してもよい。

また、その他に、ＣＰＵ１１１は、ユーザＹが普段通る道におけるユーザＹへの案内を、様々な観点で行ってもよい。
ここで、ユーザＹは、３０歳、男性、既婚、子供（例えば３歳の息子）あり、Ｘ社の部長である。
ユーザＹ以外の他の「３０代男性」がどのような周辺物を見て歩いているのかをユーザＹが知りたい場合、ＣＰＵ１１１は、例えば、「３０代男性モード」で、表示画面における表示の制御を行う。

また、その他に、例えば、「ユーザＹの妻モード」で、ユーザＹへの案内を行うこともできる。
この場合、例えば、ユーザＹの妻が普段目にとめているものをユーザに案内する。この普段目にとめているものについての情報は、妻が普段付けている端末装置２００のカメラ２１４により取得された映像を解析することで取得できる。
ユーザＹの妻が普段目にとめているもののユーザＹへの案内は、例えば、ユーザＹからの指示に応じて行う。

また、例えば、ユーザＹのカレンダーに登録されている情報（予定情報の一例）を基に、ユーザＹの妻の誕生日を特定し、例えば、妻の誕生月の前の月に、「ユーザＹの妻モード」でのユーザＹへの案内が行われるようにしてもよい。
これにより、ユーザＹは、ユーザＹの妻が関心を持っている店舗についての情報を得ることができ、例えば、この店舗にて、妻へのプレゼントの購入を行える。

また、例えば、「社長モード」というモードを用意し、この社長モードが選択された場合は、社長という肩書を有する人たちが関心を持つ周辺物についての情報が、ユーザＹに提示されるようにしてもよい。
ユーザＹが、上昇志向を有する場合、このような情報をユーザに提示すると、この情報が、ユーザＹにとって有用なものとなる。

〔ベーカリーＫに到着。パンを買う。〕
その後、ユーザＹは、ベーカリーＫに到着し、ベーカリーＫでパンを購入した。
この場合、本実施形態では、ＣＰＵ１１１が、「ベーカリーＫを紹介しませんか？」とユーザＹに尋ね、ユーザＹに対して、ＳＮＳへの投稿を促す。
具体的には、例えば、ユーザＹが店舗の外に出たことに応じて、ＳＮＳへの投稿を促す。

また、その他に、ベーカリーＫを出たユーザＹが移動中に、このユーザＹに喋ってもらうようにして、ユーザの音声を基に、ＳＮＳに投稿するテキストを作成してもよい。この場合、ユーザＹは、時間を節約できる。
また、その他に、端末装置２００のカメラ２１４で撮影された静止画や動画の加工（例えば切り出しやモザイク処理などの加工）を行い、加工した静止画や動画を投稿するよう、ユーザに提案してもよい。

また、その他、端末装置２００のカメラ２１４で撮影された映像に長時間写っている商品を特定し、その商品が写っている部分を、静止画や動画として切り出してもよい。この商品は、ユーザＹの関心が高い商品と考えられる。
また、個人情報の保護のため、人や、人の声が入らないように、静止画や動画を加工してもよい。
また、ＣＰＵ１１１は、「ベーカリーＫを評価しませんか？」とユーザＹへの問い合わせを行い、ユーザＹへの評価の依頼を行ってもよい。

また、ＣＰＵ１１１は、ユーザＹがベーカリーＫを出た後、ユーザＹに対して、「自宅に帰りますか？」との問い合わせを行ってもよい。
そして、ユーザＹが「はい」と答えた場合、ユーザＹが池袋駅から自宅に帰るために普段通っている道にユーザＹがたどり着くように道案内を行う。なお、この場合、ユーザＹが普段通っている道に達したことに応じて、道案内を終了してもよい。

なお、店舗の種類や、ユーザＹが受けたサービスによっては、ユーザＹが店を出てすぐに評価をすることが難しい場合も想定される。
例えば、ベーカリーＫでパンをテイクアウトした場合、店を出てすぐに、接客や店の雰囲気についての評価を行うことは可能であるが、パンはまだ食べていないため、店を出てすぐには、パンの味についての評価を行うことは難しい。

このため、パンについての評価については、ユーザが店を出てから時間が経過した後にこのユーザにより行われることになる。具体的には、３日後や１週間後など、ユーザＹが確実にパンを食べた頃に、ユーザによる評価が行われることになる。
なお、ユーザが確実にパンを食べた頃（３日後や１週間後など）に、接客などについての評価をユーザに依頼する場合は、すでに接客や店の雰囲気についての、このユーザの記憶が薄れてしまっているおそれがある。
このため、接客や店の雰囲気についての評価は、ユーザが店舗を訪問した直後にこのユーザに対して依頼することが好ましい。

ここで、評価には、真正ではない評価が含まれることがある。
真正ではない評価は、例えば、実際に訪問したことがない場所についての評価や、商品を使ったことがない、あるいは食べたことがないユーザーによる商品の評価や、接客を受けていないユーザによる接客に対する評価である。

ユーザの評価が真正であるか否かの判断は、ユーザの端末装置２００により取得される、映像や音声の情報を基に、ユーザが商品を実際に見ていたか否かや、ユーザが実際に店員とコミュニケーションをとっていたか否かを判断することによって行ってもよい。

ユーザの端末装置２００により取得される映像とは、例えば、端末装置２００のカメラ２１４により取得された映像である。この映像に基づき、ユーザの視界に入っていたものを確認し、これにより、ユーザの評価が真正であるか否かの判断を行う。
また、ユーザの端末装置２００により取得される音声とは、例えば、端末装置２００のマイク２１５により取得された音声である。この音声を分析することにより、例えば、ユーザと店員との会話の内容を特定でき、この特定の結果に基づき、ユーザの評価が真正か否かの判断を行う。

また、ユーザの端末装置２００により取得される、映像や音声の情報を基に、商品を確実に視認していたユーザや、店員とコミュニケーションをとっていたユーザを特定し、特定されたユーザーに、そのユーザが評価できる内容の評価を依頼することによって、不正な評価を回避してもよい。
具体的には、例えば、店員とコミュニケーションをとっていたユーザに対して、「接客はどうでしたか？」という問い合わせを行う。また、例えば、商品を視認していたユーザに対して、「品揃えはどうでしたか？」「欲しい商品はありましたか？」などの問い合わせを行う。

ここで、ユーザが、店舗を実際に訪れたか否かの判断は、例えば、店舗におけるユーザの滞在時間を基に行える。
ところで、この場合、店内の椅子にユーザが座っていた場合であっても、また、単に店舗をユーザが通過した場合であっても、店舗をユーザが実際に訪れたと判断されてしまうおそれがある。
これに対し、映像や音声の情報を基に判断する場合は、上記のように、商品を確実に視認していたユーザや、店員とコミュニケーションをとっていたユーザに対して評価の依頼を行える。

また、その他、店舗におけるユーザの行動に基づき、ユーザに依頼する評価の内容を異ならせてもよい。
具体的には、例えば、セルフレジを利用し接客を受けていないユーザに対しては、接客以外の要素についての評価をこのユーザに依頼するようにしてもよい。
この場合、接客を受けていないにも関わらず、接客についての良否についての回答が行われて、評価の精度が低下するという不具合が生じにくくなる。

また、その他に、ユーザの評価の内容が真正であるか否かを、ユーザの端末装置２００で取得したデータに基づいて判断してもよい。
例えば、「店員さんに「ＸＸＸ」と言われ大変不快でした」というユーザの評価がなされた場合、このユーザの端末装置２００が取得した音声情報を基に、この評価が真正であるか否かを判断してもよい。

また、例えば、「家に帰って商品に傷があることに気付きました」などの評価がなされた場合、ユーザの端末装置２００が取得した映像情報や加速度情報を基に、この評価が真正であるか否かを判断してもよい。
具体的には、この場合、ユーザの端末装置２００が取得した映像情報や加速度情報を基に、ユーザが店舗を出た後のこのユーザの行動を分析する。

そして、例えば、ユーザが店舗を出た後のこのユーザの行動が、商品を傷付けるほどの激しい動きを示す行動であった場合、ユーザの評価が真正ではない可能性があると判断する。
このような処理を行う場合、実際には起きていない事象に基づき評価がなされることを抑制できる。

〔スーパーマーケットＦに入店。夕食用の食材の買い物をする。〕
その後、ユーザＹは、スーパーマーケットＦに入店し、夕食用の食材の買い物をした。
上記の通り、夕食で使う生鮮食材についての情報は、ユーザが自宅に向かって帰る途中に提示されるようにすることが好ましい。
このため、本実施形態では、夕食で使う生鮮食材についての情報については、ユーザＹが、帰りの途中でスーパーマーケットＦに寄り、ユーザＹの視界に、スーパーマーケットＦが入ったタイミングで、このユーザＹに提示されるようにする。

〔帰宅〕
その後、ユーザＹは、自宅に着いた。この場合、ＣＰＵ１１１は、ユーザＹが自宅に着いたことに応じて、「お疲れさまでした！」という情報を、端末装置２００に表示し、次いで、ナビゲーションを終了する。
言い換えると、ＣＰＵ１１１は、道案内機能、周辺物情報提示機能を無効にする。

なお、その後、ＣＰＵ１１１は、ユーザＹに対して、ナビゲーションの満足度を尋ねてもよい。
具体的には、ＣＰＵ１１１は、「ナビゲーションに満足していますか？」や、「情報量は適切でしたか？」などの問い合わせを行う。
そして、ユーザが、満足していないとの回答を行った場合や、情報量は適切ではないとの回答を行った場合、ＣＰＵ１１１は、この回答の内容に応じて、以後に行う処理の内容を修正する。

また、ＣＰＵ１１１は、例えば、「情報は正確でしたか？」などの問い合わせを行ってもよい。そして、ユーザが、情報は正確ではなかったとの回答を行った場合、ＣＰＵ１１１は、情報を修正する処理を行う。
また、ＣＰＵ１１１は、例えば、「必要な情報を提供されましたか？」という問い合わせを行う。そして、ユーザが、必要な情報が提供されなかったと回答した場合、ＣＰＵ１１１は、ユーザの回答に応じて、情報の提示に関する処理の修正を行う。

〔変形例〕
上記では、ユーザＹの現在地の周辺にある周辺物についての情報である周辺物情報を、この現在地にいるユーザＹに提示する例を説明した。
ここでは、周辺物情報ではなく、ユーザＹの現在地の周辺にある周辺物と予め定められた関係にある関連物についての関連物情報を現在地にいるユーザＹに提示する処理を説明する。ここでは、一例として、周辺物と共通点のある類似物を特定し、関連物情報として類似物についての情報を提示する。

上記では、移動を行っているユーザＹの視界に、アロマショップＫ（図２０参照）という店舗が入ったときに、アロマショップＫを勧める情報をユーザＹに提示する処理を一例に説明した。
本実施形態では、図２０に示すように、アロマショップＫの３０ｍ先に、アロマショップＵという、アロマショップＫとほぼ同じサービスを提供する別のアロマ雑貨の販売店が存在する。
ユーザＹがアロマショップＫの前にいるときには、ユーザＹの視界に、アロマショップＵは入らない。アロマショップＵは、ユーザＹがレストランＮ（次の予定の場所の一例）に向かう際に通る経路上にある。
アロマショップＵとアロマショップＫとは、ともにアロマに関するサービスを提供するという点で、共通点を有するサービス施設となっている。

また、本実施形態では、アロマショップＫが、本実施形態の情報処理システム１の運営者に対してプロモーション料を払っていないのに対し、アロマショップＵは、プロモーション料を払っている。
言い換えると、本実施形態では、アロマショップＫの運営者は、アロマショップＫについての情報が提示されるようにする料金を払っていない。
これに対し、アロマショップＵの運営者は、アロマショップＵについての情報が提示されるようにする料金を払っている。
なお、料金の支払いは必須ではなく、料金が支払われない場合であっても、アロマショップＵについての情報が提示されるようにしてもよい。

本実施形態の処理例では、ユーザＹは、アロマショップＫをアロマショップＵよりも先に通過する。
この場合、ユーザＹが、アロマショップＫで必要なものを買ってしまうと、アロマショップＵには立ち寄らない可能性が高くなる。
これに対し、本実施形態のように、アロマショップＫの周辺にいるユーザＹに対して、アロマショップＵについての情報が提示されると、アロマショップＵに立ち寄る可能性が高まる。

ユーザＹに対して提示される、アロマショップＵについての情報としては、例えば、アロマショップＵの場所に関する情報（例えば、「３０ｍ先」という情報）や、割引クーポンなどのアロマショップＵの利用を促す情報が挙げられる。
このような情報を提示すると、ユーザＹが、アロマショップＫで買い物をする代わりに、アロマショップＵで買い物をしようと思う可能性が高まる。
又は、このような情報を提示すると、ユーザが、アロマショップＫで価格や品揃えなどを確認はするものの、商品を購入する前に、アロマショップＵも見てみようと思う可能性が出てくる。

なお、アロマショップＵについて情報の提示を行う場合であっても、アロマショップＵが、ユーザＹの経路上になければ、アロマショップＵの情報をユーザＹに提示する効果は薄れてしまう。
このため、ユーザＹの予定情報を考慮して、アロマショップＵについての情報を、ユーザＹに提示すべきか否かを決定することが好ましい。例えば、ユーザＹの予定情報に含まれる情報のうち、ユーザＹが向かおうしている予定の場所についての情報に基づき、アロマショップＵについての情報を、ユーザＹに提示すべきか否かを決定するとよい。

本実施形態では、ユーザＹの予定情報に基づき、ユーザＹが、予定の場所まで向かう際のこのユーザＹの経路を予測する。
そして、本実施形態では、周辺物の類似物であって、且つ、このユーザの経路上にある類似物を選択する。言い換えると、周辺物と予め定められた関係にある関連物であって、且つ、この経路上にある関連物を選択する。
本実施形態では、データベースに登録されている情報によりアロマショップＫの業種とアロマショップＵの業種とが同じであることを特定する。
本実施形態では、ユーザが、アロマショップＫを視認すると、このアロマショップＫと同業であるアロマショップＵが選択される。

なお、類似物の提示にあたっては、周辺物との間の距離が予め距離内にある類似物を提示することが好ましい。
また、アロマショップＫを見ているユーザＹに対し、アロマショップＫについての情報、アロマショップＵについての情報の両方が提示されるようにしてもよい。
また、例えば、ユーザＹが欲しい商品についての価格であって、アロマショップＵにおける価格と、アロマショップＫにおける価格とを比較し、価格が安い方の店舗についての情報が、ユーザＹに提示されるようにしてもよい。

具体的には、例えば、アロマショップＵにおける価格（例えばアロマショップＵの利用にあたっての目安の価格（例えば平均価格）であってもよいし、特定の商品の価格であってもよい）の方が、アロマショップＫにおける価格よりも安い場合に、アロマショップＵについての情報をユーザＹに提示してもよい。
また、その他に、アロマショップＵについての評価と、アロマショップＫについての評価とを比較し、例えば、アロマショップＵの評価の方が良い場合に、アロマショップＵについての情報をユーザＹに提示してもよい。

また、その他に、類似物についての情報を提示する機能については、有効と無効を切り替えられるようにし、この機能が有効となっている場合に、上記のアロマショップＵについての情報など、類似物についての情報が提示されるようにしてもよい。
また、その他に、類似物についての情報が提示される条件をユーザが設定できるようにしてもよい。具体的には、例えば、「より高評価な類似物がある場合に類似物についての情報を表示する」などの条件をユーザが設定できるようにしてもよい。

〔機器同士の連携〕
また、その他に、眼鏡型の端末装置２００に表示されている、周辺物で利用可能なクーポンなどの情報を、他の端末装置２００（例えばスマートフォン型の端末装置２００や手首装着型の端末装置２００）に対して、メール等で送信できるようにしてもよい。
この場合、眼鏡型の端末装置２００に表示されているクーポンなどを他の端末装置２００に表示させたり、保存したりすることができる。

周辺物についての情報の他の端末装置２００への送信や、周辺物についての情報の他の端末装置２００での表示や、周辺物についての情報の他の端末装置２００における保存などは、ユーザの音声による指示があった場合や、ユーザによるジェスチャによる指示があった場合に行われるようにしてもよい。
また、ハードウエアのボタンやソフトウエアのボタンがユーザによって選択された場合に、行われるようにしてもよい。

例えば、提示した周辺物情報にユーザが反応した場合に、反応した周辺物情報に対応するクーポン等の情報を、スマートフォン型の端末装置２００や、手首装着型の端末装置２００へ送信する。
より具体的には、提示した周辺物情報または提示した周辺物情報に対応する周辺物そのものをユーザが一定時間以上見た場合や、この周辺物へのユーザの訪問が検出された場合などに、この周辺物にて使えるクーポンを、スマートフォン型の端末装置２００や、手首装着型の端末装置２００へ送信する。
そして、この場合、スマートフォン型の端末装置２００や、手首装着型の端末装置２００の表示画面に、このクーポンが表示されたり、クーポンがある旨の情報が表示されたりする。

例えば、バーコードやＱＲコード（登録商標）をスキャンするタイプのクーポンの場合、眼鏡型の端末装置２００に表示されたクーポンをバーコードリーダや店員に対して提示しにくい。
これに対して、上記のように、クーポンが、スマートフォン型の端末装置２００や、手首装着型の端末装置２００に表示されると、このクーポンが提示しやすく、また、スキャンされやすくなる。
また、その他に、会計時にクーポンの提示を忘れないようにするため、ユーザが電子決済をしようとした場合に、決済に利用しようとしている端末装置２００や、他の端末装置２００に、「クーポンがありますよ」などの表示が行われるようにしてもよい。

〔他の具体例〕
次に、貸し出しスペースの一例である個室型ブース（以下、単に「ブース」と称する）を施設の例として、処理の一例を説明する。
本実施形態のブースは、街の中に設置され、出入口と、出入口を介してユーザが内部に入ることができる筐体を備える。ユーザは、ブースを利用することで、隙間時間に、仕事を行える。ユーザはこのスペースを事前に予約して利用することができ、利用料は例えば特定の時間単位で設定される（例えば１５分３００円）。

この処理例では、ユーザの予定情報に基づき、ブースにユーザを勧誘するか否かを決める。言い換えると、ユーザの予定情報に基づき、ブースの情報の提示に関する決定を行う。より具体的には、あるユーザの次の予定に基づき、このユーザを勧誘するか否かを決定する。
一例としては、ユーザの次の予定の開始時刻を利用し、このユーザを勧誘するか否かを決める。より好ましくは、現在地、現在時刻とこのユーザの次の予定の開始時刻と開催場所を利用して、このユーザの急ぎ具合を判断し、このユーザを勧誘するか否かを決める。
この処理例では、例えば、サービスを利用する時間的な余裕がある人を勧誘し、サービスを利用する時間的な余裕がない人の勧誘は行わないことができる。サービスを利用する時間的な余裕がある人の例は、次の予定が予め定められた期間内（例えば、現在時刻からその日の終わりまで）に予定されている人や、次の予定の開催場所と開始時刻に対して予め定められた程度以上の時間がある人である。サービスを利用する時間的な余裕がない人の例は、次の予定が予め定められた期間内に予定されていない人や、次の予定の開催場所と開始時刻に対して予め定められた程度以上の時間がない人である。

別の一例としては、ユーザの次の予定の種類によって、このユーザをブースに勧誘するか否かを決める。
例えば、ユーザの次の予定が、プライベートの予定（例えば友人とのランチ）である場合、このユーザの勧誘を行わず、ユーザの次の予定がビジネス（例えば会議）である場合、このユーザを勧誘する。

また、その他に、例えば、ユーザの予定情報に基づき、このユーザが周辺物を利用した場合のこの周辺物にとっての利益又は不利益を決定し、この利益又は不利益に基づき、その周辺物についての情報のユーザへの提示に関する決定を行ってもよい。
具体的には、例えば、ブースの次の予約開始時刻と、このブースの近くを通りかかったユーザの次の予定の場所およびこの次の予定の開始時刻とに基づき、このユーザがブースを利用した場合のブースにとっての利益又は不利益を決定し、この利益又は不利益に基づき、ブースについての情報のユーザへの提示に関する決定を行ってもよい。
より具体的には、この場合、例えば、まず、ブースの次の予約開始時刻と、このブースの近くを通りかかったユーザの次の予定の場所およびこの次の予定の開始時刻とに基づき、このユーザがブースを使う場合の利用料（ブースの利益又は不利益の一例）を予測する。そして、この利用料を基に、このユーザを勧誘するか否かを決定する。そして、勧誘すると決定した場合、ユーザを勧誘するための提示をユーザに対して行う。

具体的には、この場合、利用料が予め定められた閾値を超える場合、ユーザを勧誘し、利用料が予め定められた閾値を超えない場合、ユーザを勧誘しない。
また、このユーザを勧誘した場合において、ユーザがこの勧誘にのってくれなかった場合には、新たなユーザを探す。言い換えると、勧誘を行ったユーザの視界から、ブースが外れた場合、新たなユーザを探す。

ブースの貸し出しによる収入を増やすには、例えば、ブースを長時間連続して使ってくれそうな人を優先して勧誘することが好ましくなる。
ユーザの次の予定の開始時刻と次の予定の場所までの移動時間を考慮した場合において、ブースを、例えば、長くても１５分しか利用できないユーザを勧誘するよりも、３０分利用する可能性があるユーザを勧誘する方が、ブースの収入の観点からは好ましい。

また、その他に、ユーザ毎に、ある施設で提供されるサービスのうち、ユーザが使ってくれそうなサービスを予測することによって利益を予測してもよい。また、サービスの提供にかかるコストを予測することによって、そのユーザからサービス提供施設に支払われる金額（サービス提供施設の利益または不利益の一例）を予測してもよい。

具体例を挙げて説明すると、例えば、先ほどまでランチの予定が入っていたユーザについては、飲み物しか買わないことが予測できる。
また、例えば、「髪にパーマかけたい」とＳＮＳで言及しているユーザの場合は、髪にパーマをかけることが予測でき、「髪のカットを行いたい」とＳＮＳで言及しているユーザの場合は、髪のカットを行うことが予測できる。
なお、サービス提供施設の利益または不利益を決定する際に、サービスの提供にかかるコストを考慮してもよい。サービスの提供にかかるコストには、商品や材料などの仕入れにかかるコスト、サービス提供施設における人件費、サービスを提供するための場所代などが含まれる。例えば、一般的には、カットの方がパーマよりも短時間で施術できるため人件費が安く、また薬剤などのコストがかからないため、利益率が高いといわれており、周辺物がヘアサロンである場合において、ユーザを勧誘する場合は、髪のカットを行いたがっているユーザを勧誘することが好ましくなる。

また、周辺物が飲食店などのサービス提供施設である場合は、短時間で飲食を済ませて帰ってくれるユーザや、飲食物をテイクアウトしてくれるユーザを優先して勧誘することで、その飲食店の回転率が上がり（利益又は不利益の一例）、より多くのユーザに飲食物を提供することでその飲食店は収益をのばすことができる。
例えば、ユーザの次の予定を基に判断した結果、最長２時間滞在する可能性があるユーザと、最長１時間滞在する可能性があるユーザとがいた場合、前者のユーザがその飲食店を利用すると、その人が２時間にわたり席を占有してしまい、その飲食店の回転率が下がるリスクが生じるが、後者のユーザを勧誘することによって、このリスクを回避できる。

また、その他に、ある周辺物の周囲にいるユーザのうち、他の人と一緒にいるユーザへ勧誘を行えば、複数人がその周辺物が提供するサービスを利用してくれる可能性が高く、サービス提供者にとっては得になることが多い（利益又は不利益の一例）。言い換えると、周辺物の周囲にいるユーザのうち、他の人と一緒にいるユーザに対して、その周辺物の情報の提示を行うことが好ましい。
具体的には、例えば、デートしているユーザのように、他の人と一緒に移動中であるユーザを探し、このユーザを、他の人と一緒に移動中であると推定できないユーザよりも、優先的に勧誘するようにする。なお、ユーザが他の人と一緒にいるかどうかは、例えば、ユーザのカレンダーに登録された予定から特定できる。

また、他の人と一緒にいるユーザを勧誘すると、２人掛けや４人掛けのテーブル席の稼働率を高められるため、サービス提供者側にとっては得になる（利益又は不利益の一例）。
ここで、他の人と一緒にいない１人のユーザを勧誘した場合、２人掛けや４人掛けのテーブルを１人で使ってもらうことになるため、空席が生じて、稼働率が下がってしまう。
これに対して、他の人と一緒にいると推定できるユーザ、特に、偶数の人数のグループ（例えば２人や４人のグループ）に含まれているユーザへの勧誘を行うと、席の稼働率を高められる。なお、本実施例は、奇数の人数のグループを勧誘することを妨げるものではなく、３人掛けの席があれば、３人のグループを勧誘することで席の稼働率を高められる。

そこで、本実施形態では、ＣＰＵ１１１が、ユーザの予定情報に基づき、このユーザがある施設を利用した場合のその施設にとっての利益又は不利益を決定する。
一例として、ＣＰＵ１１１は、例えば、このユーザの施設の予測利用時間を求める。
そしてＣＰＵ１１１は、この予測利用時間に基づき、その施設の情報のユーザへの提示に関する決定を行う。

別の一例として、ユーザの予定に関連する人物に基づき、その施設の情報のユーザに対する提示に関する決定を行ってもよい。
具体的には、ＣＰＵ１１１は、例えば、ユーザの予定に関連する人物の数が偶数である場合、ユーザに対してある施設の情報が提示されるようにし、ユーザの予定に関連する人物の数が１人である場合、ユーザに対してその施設の情報が提示されないようにする。

また、その他に、ブースよりも手前にある、ブースと提携関係にある提携店舗を勧誘対象のユーザが通ったときに、このユーザに対して、この提携店舗にて利用可能なクーポンを提示してもよい。
より具体的には、この場合、ブースの利用を条件として有効となるクーポンを、提携店舗の前を通ったユーザに対して提示してもよい。
より具体的には、ブースの利用を条件として有効となるクーポンが、提携店舗の前を通ったユーザの端末装置２００に表示されるようにしてもよい。

また、その他に、勧誘対象のユーザが、他のユーザにより使用されている、使用中のブースを通ったときに、この勧誘対象のユーザに対して、ブースが空くまでの時間を潰す手段についての情報と、ブースの予約を促す情報とを提示してもよい。
また、その他に、ブースへのユーザの関心度によって、このユーザを勧誘するか否かを決めてもよい。
また、ブースへのユーザの関心度に基づき、ユーザに提示する情報の内容を決めてもよい。具体的には、例えば、ブースへのユーザの関心度が高い場合には、ブースの予約状況や、予約を勧める情報や、ブースの説明を、このユーザに提示するようにしてもよい。

〔ブースについての事例１〕
具体的な事例を挙げてブースについての処理を説明する。
１３時から客先での会議の予定が入っているユーザＢが、ブースＸの前を通りかかった。
現在時刻は１２：３５である。また、ユーザＢの現在地（ブースＸの前）から、次の予定の場所である会議の開催場所までの徒歩による所要時間は５分弱である。
この場合、ユーザＢがブースＸを利用できる時間は、長くても、１２：３５～１２：５５の２０分間である。
現在、ブースＸは、空いている。また、現在から１５：００までは、ブースの予約は入っていない。

ユーザＢの次の予定は、「会議」であり、仕事の予定である。ブースＸのサービスの内容は、仕事のための空間の提供である。
ブースＸは、会議の準備や予習に利用することができ、ブースＸにより提供されるサービスの内容と、ユーザＢの次の予定の内容との相性は良好である。言い換えると、ブースＸにより提供されるサービスの内容と、ユーザＢの次の予定の内容とが、予め定められた関係となっている。
この場合、ＣＰＵ１１１は、ユーザＢの勧誘を行う。

言い換えると、この処理例では、ＣＰＵ１１１は、ユーザの周辺にブースＸが存在することを特定し、ＣＰＵ１１１は、このユーザの予定についての情報である予定情報に基づき、ブースＸについての情報のユーザへの提示に関する決定を行う。
この例では、ＣＰＵ１１１は、ブースＸについての情報のユーザへの提示を行うと決定する。ここで、上記と同様、ブースＸは、ユーザの予定情報で明示されていない物である。言い換えると、ブースＸは、ユーザの予定情報には含まれない物である。

ＣＰＵ１１１は、ブースＸについての情報のユーザへの提示を行うと決定した場合、ユーザに対してブースＸについての情報が提示されるように制御する。
また、ＣＰＵ１１１は、ブースＸについての情報のユーザへの提示を行わないと決定した場合、ユーザに対してブースＸについての情報が提示されないように制御する。
なお、仮に、ユーザＢの次の予定の内容が「デート」の場合、ＣＰＵ１１１は、ユーザＢへの勧誘は行わない。

本実施形態では、ＣＰＵ１１１は、ユーザの予定の種類に基づき、ブースＸについての情報のユーザに対する提示に関する決定を行う。
本実施形態では、予定情報に、予定の名称、内容、種類についての情報が含まれる。具体的には、本実施形態では、予定情報に、予定の種類についての情報として、会議という情報が含まれている。
ＣＰＵ１１１は、この予定の種類に基づき、ブースＸについての情報のユーザに対する提示に関する決定を行う。

なお、本実施形態では、後述するように、ユーザの周辺に存在する周辺物に関連した関連物についての情報の提示を行うこともある。ユーザの周辺に存在する周辺物に関連した関連物についての情報の提示にあたっても、ユーザの予定の種類に基づき、この情報の提示についての決定を行うようにしてもよい。

なお、その他の例として、ブースＸのすぐ近くに、ブースを４０分利用してくれる可能性のある他のユーザであるユーザＥが居る場合は、ユーザＢよりもこのユーザＥを優先して勧誘してもよい。
また、ユーザＢへの勧誘にあたり、ユーザＢのブースの過去の利用傾向に基づき、ユーザＢの勧誘を行うか否かを決定してもよい。

ここで、例えば、ユーザＢの過去のブースの予約傾向を参照した場合において、ユーザＢが１時間未満の単位で、ブースＸを予約したことがほぼないことが判明した場合を想定する。
本実施形態の例では、上記のように、ユーザＢがブースＸを利用できる時間は２０分であり、この場合、ユーザＢの過去のブースの利用傾向とは異なる。この場合、ＣＰＵ１１１は、ユーザＢの勧誘を行わないようにしてもよい。

（他の処理例）
ヘアサロンの事業者が、自身が経営しているヘアサロンの周囲にいるユーザを勧誘する場合を想定する。
この場合、次の予定が「ヘアサロン」となっているユーザを勧誘しても、ユーザの反応が悪いことが予想される。言い換えると、この場合、同業者からのサービスをこれから受ける予定のユーザを勧誘する形となり、ユーザの反応が悪いことが予想される。
次の予定が「ヘアサロン」となっているユーザは、行きつけのヘアサロンを既に予約をしている場合が多い。また、次の予定が「ヘアサロン」となっているユーザが、キャンセルの手間をかけたうえで、また、キャンセル料を負担したうえで、新規のヘアサロンに行くことは考えにくい。

このため、この場合、勧誘にあたっては、例えば、ヘアサロンで施術を受けるだけの時間を有し、且つ、その日に「デート」や「友人とランチ」などの、おしゃれをする動機づけとなるような予定が入っているユーザを勧誘することが好ましい。このようなユーザは、ヘアサロンに行く動機が強いためである。
また、久しくヘアサロンの予定が入っていないユーザも、ヘアサロンに行く動機を有し、このようなユーザを勧誘することも好ましい。

〔ブースについての事例２〕
１７時から客先での会議の予定が入っているユーザＮが、ブースＸを通りかかった。
現在時刻は、１５：５０である。ユーザＮが、現在地から次の予定の場所である会議の開催場所までに要する所要時間は１０分である。この場合、ユーザＮがブースＸを利用できる時間は、長くて１５：５０～１６：５０の６０分である。
ブースＸは、１６：００まで他の人の予約が入っている。このため、ユーザＮがすぐにブースＸを使い始められる状態にはない。

この場合、本実施形態のＣＰＵ１１１は、ブースＸを通りかかったユーザＮに対して、例えば、周辺物であるブースＸの情報としてブースＸの１６：００からの予約を勧める情報を提示し、ブースＸに関連する関連物の情報として、ブースＸの近隣のサービス提供施設のクーポンを提示する。
より具体的には、この例では、ＣＰＵ１１１は、このユーザについて取得した予定情報（例えば、このユーザの次の予定の開催場所、開始時刻、種類）と、ブースについての状況を示す情報であるブース状況情報（ブースの予約状況、使用状況など）とに基づき、ブースＸについての情報のユーザに対する提示に関する決定を行っている。さらに、このユーザについて取得した予定情報と、ブースについての状況を示す情報であるブース状況情報とに基づき、ブースＸの近隣のサービス提携施設についての情報のユーザに対する提示に関する決定を行っている。
この例では、ＣＰＵ１１１は、ブースＸの１６：００からの予約を勧める情報と、ブースＸの近隣のサービス提供施設のクーポンとをユーザＮに提示する、との決定を行う。

なお、この場合、近隣のサービス提供施設の選定にあたっては、現在時刻からユーザＮがブースＸを使えるようになる１６：００までの間の時間の長さと、ユーザＮの場所（すなわちブースＸの場所）から各サービス提供施設までの往復の移動にかかる時間とを考慮することが好ましい。
この場合、近隣のサービス提供施設としては、例えば、コンビニエンスストアを挙げることができる。また、近隣のサービス提供施設のクーポンとしては、例えば、コーヒーの無料券などが挙げられる。

〔ブースについての事例３〕
１７時から客先での会議が入っているユーザＨが、ブースＸと提携しているサービス施設を通りかかった。このサービス施設は、ブースＸから徒歩１分のところにある。
現在時刻は１５：４７である。ブースＸから、ユーザＨの次の予定の場所である、会議の開催場所までの所要時間は、１０分である。この場合、ユーザＨがブースＸを利用できる時間は、長くて１５：４８～１６：５０の６２分である。
ブースＸは、１６：００まで他の人の予約が入っており、ユーザＨがどこかに立ち寄ることなく歩いた場合、ユーザＨがブースＸを通りかかるのは、１５：４８である。この場合、ブースＸが、他の人によってまだ使用中であることが予測される。

この場合、ＣＰＵ１１１は、例えば、ブースＸと提携しているサービス施設の利用を勧める情報と、ブースＸの１６：００からの予約を勧める情報とをユーザに提示する。
なお、ブースＸと提携している提携施設が複数ある場合は、この複数の提携施設の中から、勧誘を行う提携施設を選定する。

具体的には、複数の提携施設の中から提携施設を選定する場合、各提携施設でサービスを受けるのに必要と推定される時間（滞在時間、待ち時間、施術時間などを元に算出される時間）と、現在時刻からブースの予約開始時刻までの時間とに基づき、複数の提携施設から、ユーザが時間を潰せる提携施設を選定する。
また、その他に、提携施設へのユーザの関心度も加味して、ブースＸの予約と組み合わせる提携施設を選定してもよい。

図２２は、端末装置２００における他の表示例を示した図である。
なお、図２２では、端末装置２００の一例として、スマートフォン型の端末装置２００にユーザの周辺物の情報を表示した例を示している。
この表示例では、コーヒーショップＳがユーザの視界に入っているときの端末装置２００における表示例を示している。
本実施形態では、この場合、ＣＰＵ１１１は、上記と同様、ユーザの周辺にコーヒーショップＳが存在することを特定する。

そして、この場合、ＣＰＵ１１１は、このユーザの予定についての情報である予定情報に基づき、このコーヒーショップＳについての情報のユーザへの提示に関する決定を行う。
ここで、コーヒーショップＳは、ユーザの予定情報で明示されていない物である。言い換えると、コーヒーショップＳは、ユーザの予定情報に含まれていない物である。

本実施形態では、この場合、ＣＰＵ１１１は、ユーザの予定情報に基づき、コーヒーショップＳの情報としてユーザに提示する情報の内容を決定する。

具体的には、ＣＰＵ１１１は、例えば、ユーザが会議に向かっている場合には、コーヒーショップＳについての情報として、例えば、「眠気覚ましにコーヒーはいかがですか？」という情報が端末装置２００に表示されるようにする。
また、ＣＰＵ１１１は、コーヒーショップＳについての情報として、例えば、ユーザが旅行中である場合には、「地域限定商品あります！」という情報が端末装置２００に表示されるようにする。
なお、これらの情報が端末装置２００に表示される際、ユーザに見えているコーヒーショップＳに、これらの情報が重ならないように制御してもよい。

また、その他に、ＣＰＵ１１１は、ユーザの予定情報が予め定められた条件を満たす場合、ユーザに提示される、コーヒーショップＳについての情報に、コーヒーショップＳのキャンペーン情報が含まれるように制御する。
例えば、ＣＰＵ１１１は、ユーザの予定情報を基に特定したユーザの時間的な余裕が、予め定められた閾値よりも大きい場合、ユーザに提示される、コーヒーショップＳについての情報に、例えば、「コーヒー１０％オフ」などの、コーヒーショップＳについてのキャンペーン情報が含まれるように制御する。

ここで、「キャンペーン情報」とは、クーポンだけでなく、ディスカウントコード、特売の情報、フリーギフト（例えばノベルティプレゼントやドリンク１杯サービス）などについての情報も含まれる。

また、その他に、ＣＰＵ１１１は、直後の予定が入っているユーザなど、商品のテイクアウトをしてくれそうなユーザに対して提示される、コーヒーショップＳについての情報に、例えば、「コーヒー１０％オフ」などのキャンペーン情報が含まれるように制御する。
テイクアウトをしてくれそうなユーザは、店内座席の回転率を下げることがないため、このユーザが来店すると、売り上げに貢献する。
なお、直後の予定が入っていないユーザに対しては、店の混雑状況と店の評価のみを提示し、値引きクーポンは提示しないようにしてもよい。

本実施形態のＣＰＵ１１１は、予定情報が予め定められた条件を満たす場合、コーヒーショップＳの情報にコーヒーショップＳのキャンペーンの情報が含まれるよう制御する。
また、ＣＰＵ１１１は、予定情報が予め定められた条件を満たさない場合、コーヒーショップＳの情報に、コーヒーショップＳのキャンペーンの情報が含まれないよう制御する。
ここで、キャンペーン情報とは、ユーザが得をする情報を指す。キャンペーン情報の例としては、クーポンや特別価格の案内などが挙げられる。

本実施形態では、ユーザの予定情報を基に、ユーザの現在の予定や、次の予定についての情報を得られる。これにより、ユーザに訴求しそうな情報が分かる。
また、本実施形態では、ユーザの予定情報を基に、ユーザの次の予定の場所や開始時刻についての情報を得られる。
ここで、例えば、ＣＰＵ１１１は、ユーザの予定情報を解析した結果、現在の予定の関係者や次の予定の関係者とユーザとが一緒にいる可能性が高いことが判明した場合は、上記の「コーヒー１０％オフ」など、コーヒーショップＳについてのキャンペーン情報が含まれるように制御する。
この場合、ユーザ以外に上記の関係者の分も、商品が購入される可能性が高まる。

また、例えば、ユーザの周辺に存在する物がヘアサロンである場合においては、ユーザの予定情報に基づき、ヘアサロンについての情報のユーザへの提示に関する決定を行える。
具体的には、例えば、あるユーザの予定情報を参照した場合に、このユーザの最後のヘアカットの予定の予約日が３か月前であった場合は、このユーザに対して、ヘアカットを進める情報が提示されるようにし、また、例えば、「カット本日だけ３０％オフ」という、キャンペーン情報が含まれるようにする。

また、例えば、ユーザの予定情報を参照した場合に、このユーザの最後のヘアカットの予定の予約日が３週間前であった場合は、このユーザに対して、トリートメントを勧める情報が提示されるようにし、また、例えば、「トリートメント本日だけ３０％オフ」という、キャンペーン情報が含まれるようにする。

また、その他に、ユーザに提示されるコーヒーショップＳやヘアサロンについての情報は、コーヒーショップＳやヘアサロンにて提供されるサービスの予約を促す情報であってもよい。

また、その他に、ＣＰＵ１１１は、ある施設の周辺に存在する複数のユーザ各々の予定についての情報を予定情報として取得してもよい。
そして、ＣＰＵ１１１は、取得した複数の予定情報に基づいて、この複数のユーザの中からこの施設の情報を提示する先となるユーザを決定してもよい。
この場合、この施設の周辺に存在する複数のユーザの全員に対して、この施設の情報が提示されずに、例えば、特定の条件を満たすユーザに対してのみ、この施設の情報が提示される。

特定の条件としては、例えば、その施設に来る可能性を挙げることができ、この場合、その施設に来る可能性が閾値を超えるユーザに対してのみ、その施設の情報が提示されるようになる。
この可能性は、例えば、各ユーザの次の予定の開始時刻までの残り時間などを基に求めることができ、残り時間が大きい場合には、その施設に来る可能性が高いと判断でき、また、残り時間が小さい場合には、その施設に来る可能性が小さいと判断できる。

図２３は、端末装置２００における他の表示例を示した図である。
この表示例では、コーヒーショップＳが視界に入ったユーザに、このユーザの視界には入っていない（もしくは、視界に入ってはいるがユーザが認識できるほどの近さにない）他のコーヒーショップＤの情報を提示する場合を例示している。

図２３に示すこの表示例では、ユーザが有する端末装置２００のカメラ２１４（図２３では不図示）による撮像範囲内に、コーヒーショップＳが入った場合における表示例を示している。
この表示例では、コーヒーショップＳについての情報に加えて、撮像範囲内に入っていないコーヒーショップＤについての情報が表示されている。
ここで、コーヒーショップＳとコーヒーショップＤとは運営者は異なるが、同じ業種である。つまり、コーヒーショップＤはコーヒーショップＳと予め定められた関係にある関連物であるといえる。

この処理例では、現在、コーヒーショップＳには、空席がなく、また、このコーヒーショップＳでは、会計のために長い列ができている。ユーザが、コーヒーショップＳで飲食物を買うのにかかる時間は、列に並んでいる人数に基づくと、約１５分と予測された。この処理例では、コーヒーショップＳにおける待ち時間が、１５分である旨の表示が行われている。
また、この処理例は、コーヒーショップＤについての情報として、コーヒーショップＤが、現在地から５０ｍ先にあることを示す情報、および、コーヒーショップＤにおける待ち時間が３分であることを示す情報が表示されている。

コーヒーショップＳが視界に入ったこのユーザのカレンダーに登録されている情報（予定情報の一例）によると、このユーザの行き先（次の予定の開催場所）は、ユーザの前にある道の突き当りにあるコンサートホール（不図示）である。
また、ユーザに提示されたコーヒーショップＤは、現在地から、コンサートホール（予定の開催場所の一例）までの間にある。

コーヒーショップＤは、ユーザが、このコーヒーショップＤに立ち寄っても、このユーザがコンサートの開始に間に合う位置にある。
なお、ユーザの移動時間だけでなく、コーヒーショップＤでの待ち時間も考慮し、移動時間および待ち時間の両者に基づき、コンサートの開始にユーザが間に合うと判断された場合に、コーヒーショップＤについての情報が、ユーザに提示されるようにしてもよい。

この処理例では、ＣＰＵ１１１は、まず、ユーザの周辺にコーヒーショップＳが存在することを特定する。
そして、ＣＰＵ１１１は、このユーザの予定情報に基づき、ユーザの周辺に存在するコーヒーショップＳとは異なる場所に存在するコーヒーショップＤについての情報のユーザへの提示に関する決定を行う。より具体的には、ユーザの周辺に存在するコーヒーショップＳと予め定められた関係にある関連物であるコーヒーショップＤについての情報のユーザへの提示に関する決定を行う。
ここで、コーヒーショップＤは、ユーザの予定情報に明示されていない物である。

本実施形態では、コーヒーショップＳと提携する提携施設を後述するデータベースを用いて特定する。
つまり、本実施形態では、ユーザの視界内にある施設を特定した後、この施設を基に、データベースを参照して、その施設と予め定められた関係にある関連施設を特定する。

ここで、データベースにおいて、１つの施設に対して関連施設が複数存在する場合も想定される。
ユーザの周辺にあると特定された周辺施設に対して複数の関連施設が複数存在する場合、ＣＰＵ１１１は、例えば、周辺施設の状況情報に基づき、ユーザに情報を提示する関連施設を、複数の関連施設の中から決定する。
具体的には、ＣＰＵ１１１は、例えば、上記のように、ユーザの周辺にあると特定されたコーヒーショップＳが混雑している場合、複数の関連施設の各々の混雑状況に基づいて、ユーザに情報を提示する関連施設を決定する。例えば、複数の関連施設の中から、コーヒーショップＳよりも混雑していない施設を選定してもよいし、複数の関連施設の中から、最も混雑していない施設を選定してもよい。

本実施形態では、ＣＰＵ１１１は、コーヒーショップＳに対して複数の関連施設がある場合、この複数の関連施設の各々の状況情報に基づき、この複数の関連施設の中から、ユーザへの情報の提示を行うべき関連施設を決定する。
また、その他に、コーヒーショップＳに対して複数の関連施設がある場合、複数の関連施設の各々に対するユーザの関心度に基づき、この複数の関連施設の中から、ユーザへの情報の提示を行うべき関連施設を決定してもよい。

また、その他に、ＣＰＵ１１１は、ユーザの周辺に存在するコーヒーショップＳの状況情報に基づいて、コーヒーショップＳの関連施設の情報のユーザに対する提示に関する決定を行ってもよい。

具体的には、ＣＰＵ１１１は、例えば、コーヒーショップＳの混雑度が小さい場合には関連施設の情報の提示を取りやめ、コーヒーショップＳの混雑度が大きい場合には関連施設の情報の提示を行うよう制御してもよい。
また、ＣＰＵ１１１は、例えば、コーヒーショップＳの混雑度に応じて、関連施設の情報量を増減させてもよい。具体的には、コーヒーショップＳの混雑度が大きいほど、関連施設の情報量を増やしてもよい。

また、その他に、ユーザの周辺に存在するコーヒーショップＳの関連施設であるコーヒーショップＤの情報をユーザに提示することを決定する条件として、次のような条件の一つ以上を用いてもよい。
（１）ユーザが、コーヒーショップＳよりもコーヒーショップＤの方が好きである。
（２）ユーザが、コーヒーショップＳを一定時間以上見ている状況にある場合など、ユーザが、コーヒーショップ自体に関心を示している。
（３）コーヒーショップＤにコーヒーショップＳよりも勝る点がある。
具体例としては、コーヒーショップＤでは、コーヒーショップＳよりも短い時間でサービスの提供を受けることができる場合や、コーヒーショップＤの方がコーヒーショップＳよりも安い場合や、コーヒーショップＤにて特売が行われている場合などが挙げられる。
（４）コーヒーショップＤが、ユーザがコーヒーショップＤの周辺にいない場合でもコーヒーショップＤの情報が提示される契約を結んでおり、そのように設定がされている。
（５）ユーザが、コーヒーショップＤの情報の配信を希望する設定を行っている。
（６）次の予定の開催場所と次の予定の開始時刻とを考慮すると、コーヒーショップＳには寄れないが、コーヒーショップＤには寄れる状況にある。

なお、上記で説明したアロマショップＫの周辺にいるユーザＹにアロマショップＵ（図２０参照）についての情報を提示することも、ユーザの周辺物と予め定められた関係にある関連物を提示する一例として捉えることができる。
ユーザが、関連物の提示を希望しているか否かは、例えば、関連物情報の提示機能をユーザが有効としているか否かや、関連物情報の提示が行われるようにするための料金をユーザが払っているか否かなどの情報に基づき判断できる。

また、その他に、ユーザの周辺に存在するコーヒーショップＳの関連施設であるコーヒーショップＤの情報をユーザに提示しないことを決定する条件として、次のような条件の一つ以上を用いてもよい。
（１）ユーザが、コーヒーショップＤが嫌いである。
（２）ユーザが、コーヒーショップに関心を示していない。
（３）ユーザが、関連物情報の提供機能を無効に設定している。
（４）コーヒーショップＤの条件が、コーヒーショップＳの条件よりも悪い。
コーヒーショップＤの条件が、コーヒーショップＳの条件よりも悪い場合としては、例えば、コーヒーショップＤでは、コーヒーショップＳよりもサービスの提供に時間を要する場合や、コーヒーショップＤの方がコーヒーショップＳよりも価格が高い場合や、コーヒーショップＳが特売中にある場合などが挙げられる。
（５）情報処理システム１の運営者と、コーヒーショップＳとの間で、ユーザがコーヒーショップＳの周辺にいる間にコーヒーショップＤについての情報が表示されないようにする契約を結んでおり、そのように設定がされている。
具体的には、例えば、「自身の店であるコーヒーショップＳの前を通っているユーザに対して、同業の他の店舗についての情報の提示を行わない」という契約を結んでおり、そのように設定がされている場合が挙げられる。

ここで、実在する店舗に対して直接広告を貼ったり、実在する店舗にてサイネージにより広告等を表示したりしてもらうには、店の許可を得たり、広告料を払ったりしなければならない場合が多い。
しかしながら、本実施形態のように、ユーザの個人の所有物である端末装置２００上で情報を表示する場合、ユーザが視認している店舗に対して、この店舗の競合の店舗についての情報なども表示できてしまう。また、情報の表示の仕方によっては、店舗の外装が見えづらくなることも考えられる。
この場合、営業妨害や、景観の破壊などにつながる恐れがある。

このため、ユーザが視認している周辺物に関連する関連物の情報を表示する場合は、ユーザに見えている周辺物に対して、関連物の情報ができるだけ重ならないように表示されるように制御することが好ましい。
言い換えると、コーヒーショップＤについての情報が、ユーザに見えているコーヒーショップＳに重ならないようにユーザに提示されるようにすることが好ましい。

また、コーヒーショップＳについての情報は、コーヒーショップＳに重ねて表示し、コーヒーショップＤについての情報は、コーヒーショップＳを避け、ユーザに見えているコーヒーショップＳにできるだけ重ならないように表示制御を行うことが好ましい。
なお、コーヒーショップＳの情報も、コーヒーショップＳに重ねて表示されないようにしてもよい。この場合、ＣＰＵ１１１は、コーヒーショップＳを認識し、コーヒーショップＳについての情報が、ユーザに見えているコーヒーショップＳにできるだけ重ならないように表示制御を行う。

図２４－１は、端末装置２００における他の表示例を示した図である。
コーヒーショップＤの情報をユーザに見えているコーヒーショップＳにできるだけ重ならないように表示する処理の一例として、コーヒーショップＤの情報を図２４－１の符号２４Ａで示すように、端末装置２００の表示画面の縁や隅に表示してもよい。
別の一例として、ＣＰＵ１１１がコーヒーショップＳを認識し、コーヒーショップＳを避けるようにコーヒーショップＤの情報の表示を行ってもよい。
別の一例として、ＣＰＵ１１１が他の施設がない部分を認識するようにし、その部分にコーヒーショップＤの情報が重なるようにコーヒーショップＤの情報の表示を行ってもよい。より具体的には、空または道路を認識し、図２４－２の符号２４Ｂ、２４Ｃに示すように、認識した空または道路にコーヒーショップＤの情報が重なるように、コーヒーショップＤの情報の表示を行ってもよい。
なお、ＣＰＵ１１１は、ユーザの周囲の道路標識、通行人、自転車、車などを認識し、コーヒーショップＤの情報がこれらに重ならないように制御することが好ましい。一例として、コーヒーショップＤの情報が表示されているときにユーザに車が近づいてきたら、コーヒーショップＤの情報を非表示にし、車が通り過ぎたらコーヒーショップＤの情報を再表示してもよい。別の一例として、車が動くにつれ、車を避けるようにコーヒーショップＤの情報を移動させてもよい。
また、ＣＰＵ１１１は、コーヒーショップＤの情報を、コーヒーショップＤの情報の表示が許された領域の大きさに合わせて調整してもよい。例えば、コーヒーショップＤの情報を改行する位置を調整したり、コーヒーショップＤの情報の文字サイズを調整したり、コーヒーショップＤの情報の文字列の表示方向を調整（例えば、通常は文字列を水平方向に表示している場合、調整によって垂直方向や斜め方向に表示する）したり、コーヒーショップＤの情報を簡略化（例えば、コーヒーショップＤの情報を部分的に抜粋する、コーヒーショップＤの情報を領域サイズに適した文言で表現する、コーヒーショップＤの情報の文字列の一部または全部を略語、記号、絵文字、アイコン等に置き換える）したりしてもよい。
なお、ユーザの周辺に存在すると特定されたコーヒーショップＳの情報を、ユーザに見えているコーヒーショップＳに重ねて表示されないようにする場合においても、コーヒーショップＤの情報をユーザに見えているコーヒーショップＳに重ねて表示されないようにする場合の上記の処理と同様の処理を行うようにしてもよい。
即ち、コーヒーショップＳの情報をユーザに見えているコーヒーショップＳにできるだけ重ならないように表示する処理の一例として、コーヒーショップＳの情報を端末装置２００の表示画面の縁や隅に表示してもよい。
別の一例として、ＣＰＵ１１１がコーヒーショップＳを認識し、コーヒーショップＳを避けるようにコーヒーショップＳの情報の表示を行ってもよい。
別の一例として、ＣＰＵ１１１が他の施設がない部分を認識するようにし、その部分にコーヒーショップＳの情報が重なるようにコーヒーショップＳの情報の表示を行ってもよい。
また、コーヒーショップＳの情報をユーザに見えているコーヒーショップＳに重ねて表示されないようにする場合においても、道路標識、通行人、自転車、車などを認識し、コーヒーショップＳの情報がこれらに重ならないように制御することが好ましい。この場合、上記と同様、コーヒーショップＳの情報が表示されているときにユーザに車が近づいてきたら、コーヒーショップＳの情報を非表示にし、車が通り過ぎたらコーヒーショップＳの情報を再表示してもよい。別の一例として、車が動くにつれ、車を避けるようにコーヒーショップＳの情報を移動させてもよい。
また、コーヒーショップＳの情報をコーヒーショップＳに重ねて表示されないようにする場合において、コーヒーショップＤの情報を表示するときの処理と同様、コーヒーショップＳの情報を、コーヒーショップＳの情報の表示が許された領域の大きさに合わせて調整してもよい。

なお、ＣＰＵ１１１は、コーヒーショップＳの周辺に存在する複数のユーザ各々の予定についての情報を予定情報として取得してもよい。
そして、ＣＰＵ１１１は、複数取得するこの予定情報に基づいて、複数のユーザの中から、コーヒーショップＤについての情報を提示する先としてのユーザを決定するようにしてもよい。
この場合、コーヒーショップＳの周辺に存在する複数のユーザの全員に対して、コーヒーショップＤの情報が提示されずに、例えば、特定の条件を満たすユーザに対してのみ、コーヒーショップＤの情報が提示される。

特定の条件としては、例えば、コーヒーショップＤに来る可能性を挙げることができる。ユーザを勧誘した場合に、コーヒーショップＤに来る可能性を挙げることができ、この場合、コーヒーショップＤに来る可能性が閾値を超えるユーザに対してのみ、コーヒーショップＤが提示されるようになる。
なお、この可能性は、例えば、ユーザの次の予定までの残り時間に基づき求めることができる。また、この可能性は、例えば、コーヒーショップＤに対するユーザの関心度に基づき求めることができる。

図２３、図２４－１、図２４－２に示す表示例では、コーヒーショップＤについての情報として、コーヒーショップＤまでの距離、コーヒーショップＤにおける待ち時間を表示したが、表示される情報はこれに限られない。
例えば、これ以外に、「５０ｍ先にコーヒーショップＤがあります。今オーダーしておけば早く受け取れます。」や、「５０ｍ先にコーヒーショップＤがあります。通る頃にできあがるようにオーダーしますか？」というように、サービスの予約をユーザに促す情報をユーザに提示してもよい。

言い換えると、ユーザに提示されるコーヒーショップＤの情報は、コーヒーショップＤにて提供されるサービスの予約を促す情報としてもよい。
ここで、予約を促す情報の表示の態様としては、予約ボタンのみや予約サイトのリンクのみを表示する態様も含む。
サービスの予約が促されたユーザは、例えば、端末装置２００にインストールされている、コーヒーショップＤについてのアプリケーションに対する操作を行うことで、コーヒーショップＤにおける予約を行える。
また、上記のように、予約ボタンや、予約サイトのリンクが表示される場合には、ユーザは、この予約ボタンや、予約サイトのリンクに対する操作を行うことで、コーヒーショップＤにおける予約を行える。

また、その他に、例えば、図２５（端末装置２００における他の表示例を示した図）に示すように、コーヒーショップＳの情報は表示せず、コーヒーショップＤの情報のみを表示してもよい。
図２５に示す例では、ＣＰＵ１１１によりコーヒーショップＳがユーザの周辺に存在することが認識され、その関連物として特定されたコーヒーショップＤの情報は表示されているが、このコーヒーショップＳの情報は表示されていない。

図２２、図２３、図２４、図２４－１に示す例では、コーヒーショップＳについての情報も表示したが、コーヒーショップＳはユーザの近くにあり、ユーザに見えている。
この場合、このコーヒーショップＳについての情報を提示しないでも、ユーザは、コーヒーショップＳそのものからコーヒーショップＳの店名や混雑状況などを認識しうる。
図２５のように、ユーザの周辺物についての情報はユーザに提示せず、周辺物の関連物についての情報だけを提示すると、表示画面の情報量が減り、ユーザが、表示画面を視認しやすくなる。

図２６は、次の予定までに予め定められた閾値以上の時間的余裕があるユーザが、コーヒーショップＳまで歩いてきた場合における表示例を示した図である。つまり、このときコーヒーショップＳはユーザの周辺物である。
この例では、コーヒーショップＳまで歩いてきたこのユーザは、コーヒーショップＳを好きなユーザである。また、この例では、コーヒーショップＳは、混雑している。
また、この例では、コーヒーショップＳと予め定められた関係にある関連物についての関連物情報として、時計店Ｃについての情報が表示された場合を例示している。

この表示例では、ユーザがコーヒーショップＳにて販売されている商品を注文すると、時計店Ｃにて使える割引クーポンがもらえる旨の表示が行われている。
より具体的には、この表示例では、ユーザがコーヒーショップＳにて販売されている商品をオンラインで注文すると、時計店Ｃにて使える５％オフのクーポンがもらえる旨の表示が行われている。

この例では、ＣＰＵ１１１は、時計店Ｃのキャンペーンの情報を、ユーザの周辺物として認識されたコーヒーショップＳと予め定められた関係にある関連物の情報として表示している。
より具体的には、この表示例では、ＣＰＵ１１１は、ユーザの周辺物であるコーヒーショップＳの利用を条件として有効となる、時計店Ｃのキャンペーンの情報を、コーヒーショップＳの関連物についての情報として表示している。

この処理例では、コーヒーショップＳにおけるユーザの待ち時間が、１５分となっている。このため、ユーザが、コーヒーショップＳにて販売されている商品をオンラインで注文したとしても、商品を受け取れるのは１５分後、あるいはそれ以降になるため、ユーザには空き時間が生じる。
この場合に、上記のように、ユーザが、時計店Ｃにて使える５％オフのクーポンをもらえると、このユーザが、この空き時間を利用して時計店Ｃに向かう可能性が高まる。

ここで、周辺物（ここではコーヒーショップＳ）の関連物として複数の候補がある場合、それらの候補の中からより良い候補を選定することが好ましい。具体的には、例えば、コーヒーショップＳの待ち時間、コーヒーショップＳと各候補までの距離、コーヒーショップＳと各候補までの移動時間、各候補でサービスを受けるのにかかる時間、ユーザの関心、またはこれらの２つ以上の組み合わせに基づいて、ユーザに情報を提示すべき関連物を選定することが好ましい。
この例では、コーヒーショップＳと時計店Ｃとの間を移動に要する時間は、２．５分であり、また、時計店Ｃの平均滞在時間は、９．５分となっている。
この場合、ユーザが、時計店Ｃを平均的な滞在時間で利用した後にコーヒーショップＳに戻って来れば、ちょうどよいタイミングで、コーヒーショップＳで注文した商品を受け取れる。

図２７は、端末装置２００における他の表示例である。
この表示例は、次の予定が「会議」であるユーザであって、予め定められた閾値以上の時間的余裕があるユーザが、コーヒーショップＳの前まで移動してきた場合における表示例を示している。つまり、このときコーヒーショップＳはユーザの周辺物である。
この表示例では、ユーザの周辺物として認識されたコーヒーショップＳと予め定められた関係にある関連物の情報として、コーヒーショップＳと提携関係にあるブースについての情報が表示されている。ブースは、コーヒーショップＳから徒歩５分のところにある。
この表示例では、ブースについての情報として、ブースまでの所要時間が５分である旨、また、ブースの予約を行うためのリンクが表示されている。
この表示例では、ユーザがこのリンクを選択すると、ブースの予約のための表示画面に遷移する。

また、この表示例では、ＣＰＵ１１１は、ブースの利用を条件として有効となる、コーヒーショップＳのキャンペーンの情報の表示を行っている。
具体的には、この例では、キャンペーン情報として、ブースの予約をすると、コーヒーショップＳにて販売されているドリンクのカスタマイズが無料となる旨の情報が表示されている。

図２７にて示すこの表示例では、ユーザの周辺物についての情報として、コーヒーショップＳにて販売されているドリンクのカスタマイズが無料となる旨のキャンペーンの情報が表示されている。また、周辺物の関連物についての情報として、ブースまでの所要時間が５分である旨、また、ブースの予約を行うためのリンクが表示されている。

図２８は、図２３～図２７にて説明した処理の流れを示したフローチャートである。
本実施形態では、ユーザの移動を検知すると（ステップＳ６０１）、このユーザの次の予定についての情報を取得する（ステップＳ６０２）。
次いで、ユーザの周辺にある周辺物を順次特定する（ステップＳ６０３）。言い換えると、ユーザの端末装置２００に設けられたカメラ２１４により取得された映像に含まれている施設を順次特定する。
さらに、本実施形態では、周辺物を特定する度に、特定された周辺物に関連付けられた関連物を特定する（ステップＳ６０４）。

そして、ステップＳ６０４にて特定した関連物が、ユーザの次の予定の開始時刻までに寄れる範囲内にあるか否かを判断する（ステップＳ６０５）。
そして、寄れる範囲内にあると判断した場合、関連物が、ユーザの次の予定の開催場所へユーザが向かう際に通る経路上にあるかを判断する（ステップＳ６０６）。
さらに、本実施形態では、関連物に周辺物よりも勝る点があるかを判断する（ステップＳ６０７）。

そして、ステップＳ６０７にて、関連物に周辺物よりも勝る点があると判断した場合、関連物についての情報を表示するとの決定を行う（ステップＳ６０８）。
一方、ステップＳ６０５にて、関連物が寄れる範囲内にあると判断されなかった場合、ステップＳ６０６にて、経路上に関連物があると判断されなかった場合、ステップＳ６０７にて、関連物に周辺物よりも勝る点があると判断されなかった場合、ステップＳ６０９の処理に進む。

ステップＳ６０９の処理では、関連物についての情報を表示しないとの決定を行う。
なお、ステップＳ６０５～ステップＳ６０７の処理は必須ではなく、これらの処理うちの１つ又は２つの処理が行われるようにしてもよい。また、これらの処理を行わず、ステップ６０４にて、関連物を特定したら、特定したこの関連物についての情報の表示が行われるようにしてもよい。また、関連物と周辺物の両方の情報が表示されてもよい。

図２９は、周辺物情報や関連物情報の表示を行う際にＣＰＵ１１１が参照するデータベースを示した図である。このデータベースは、例えば、外部サーバ１００の情報記憶装置１０２（図２参照）に格納される。
本実施形態では、図２９に示すように、施設についての情報が、データベースに登録されている。
具体的には、本実施形態では、施設ＩＤ、施設名、位置情報、業種、評価、現在の混雑状況、滞在時間の目安、テイクアウトの可否、オンライン予約の可否／オンライン予約のためのＵＲＬ、関連施設としての表示の希望の有無、提携施設、キャンペーンの有無が登録されている。なお、位置情報には、例えば、経度緯度の情報や、電子地図上の座標の情報が登録される。このデータベースには、その他に、キャンペーンの内容、施設からのお知らせ、施設の営業時間などが登録されてもよい。このデータベースは、ユーザに提示される情報が格納されているデータベースの一例と捉えることもできるし、ユーザに提示する情報の決定に用いる情報が格納されているデータベースの一例と捉えることもできる。

本実施形態では、ステップＳ６０４にて、コーヒーショップＳと予め定められた関係にある施設をこのデータベースを用いて特定する。一例として、データベースの提携施設の欄を参照して、コーヒーショップＳと提携している施設を特定する。
なお、予め定められた関係にある施設は、提携関係にある施設に限られない。別の一例として、位置情報を参照して、特定の距離内にある施設を予め定められた関係にある施設として特定してもよい。別の一例として、業種の欄を参照して、同業の施設を予め定められた関係にある施設として特定してもよい。なお、同業の施設かつ提携関係にある施設を特定するなど、複数の関係を満たす施設を特定してもよい。また、複数の関係に優先的順位を付け、第１の関係を満たす施設があればその施設を特定し、なければ第２の関係を満たす施設を特定してもよい。

本実施形態では、ステップＳ６０５において、一例として、ステップＳ６０４で特定された関連施設の位置情報の欄を参照し、その位置情報と現在時刻、ユーザの現在地、ユーザの次の予定の開催場所および開始時刻に基づいて、ステップＳ６０４で特定された関連施設が次の予定の開始時刻までに寄れる範囲内にあるかを判断する。なお、より好ましくは、関連施設の位置情報だけでなく、混雑状況の欄も参照し、例えば、関連施設でこのユーザに発生しうる待ち時間も考慮して、その関連施設でサービスを受ける時間があるかを判断するとよい。
本実施形態では、ステップＳ６０６において、一例として、ステップＳ６０４で特定された関連施設の位置情報の欄を参照し、ユーザの現在地、ユーザの次の予定の開催場所および開始時刻に基づいて、ステップＳ６０４で特定された関連施設が次の予定の開催場所までの経路上にあるかを判断する。
本実施形態では、ステップＳ６０７において、一例として、ステップＳ６０３で特定された周辺施設の混雑状況の欄とステップＳ６０４で特定された関連施設の混雑状況の欄とを参照し、関連施設の待ち時間がより短い場合には関連施設に周辺施設より勝る点があると判断する。
本実施例では、これらの処理の結果として、コーヒーショップＤの情報を表示すべきであると判断される。図２３、図２４－１、図２４－２、図２５に示す例では、コーヒーショップＳと予め定められた関係にあるコーヒーショップＤについての情報がコーヒーショップＳの近くにいるユーザが有する端末装置２００に表示されている。コーヒーショップＤまでの距離やコーヒーショップＤの待ち時間の情報は、図２９のデータベースを参照して取得することができる。

なお、上記で説明した各構成は、上記の実施形態及びその変形例に限られるものではなく、趣旨を逸脱しない範囲で変更可能である。言い換えると、特許請求の範囲の趣旨及び範囲から逸脱することなく、形態や詳細の多様な変更が可能なことが理解される。
例えば、上記にて説明した各構成の一部を省略したり、上記にて説明した各構成に対して他の機能を付加したりしてもよい。
また、上記では、複数の実施形態を説明したが、一の実施形態に含まれる構成と他の実施形態に含まれる構成とを入れ替えたり、一の実施形態に含まれる構成を他の実施形態に付加したりしてもよい。

１…情報処理システム、１００…外部サーバ、１１１…ＣＰＵ、２００…端末装置、２１４…カメラ、２１７…ディスプレイ

Claims (32)

1. プロセッサを有する情報処理装置であって、
   前記プロセッサは、
   ユーザの周辺の状況が写っている映像に基づき、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第１物が存在することを特定し、
   前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第１物についての情報である第１物情報の前記ユーザへの提示に関する決定を行い、
   前記第１物は、前記予定情報に含まれない物である、
   情報処理装置。
2. 前記プロセッサは、
   前記予定情報に基づき、前記第１物情報の前記ユーザへの提示の有無についての決定、及び／又は、前記ユーザに提示される前記第１物情報の内容の決定を行う請求項１に記載の情報処理装置。
3. 前記プロセッサは、
   前記予定情報が予め定められた条件を満たす場合、前記第１物情報に、前記第１物のキャンペーン情報が含まれるように制御する請求項１に記載の情報処理装置。
4. プロセッサを有する情報処理装置であって、
   前記プロセッサは、
   ユーザの周辺の状況が写っている映像、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第２物が存在することを特定し、
   前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第２物と予め定められた関係にある第１物であって、前記第２物とは異なる場所に存在する第１物についての第１物情報の前記ユーザへの提示に関する決定を行い、
   前記第１物は、前記予定情報に含まれない物である、
   情報処理装置。
5. 前記プロセッサは、
   前記予定情報が予め定められた条件を満たす場合、前記第１物情報に前記第１物のキャンペーンの情報が含まれるよう制御し、
   前記予定情報が予め定められた条件を満たさない場合、前記第１物情報に、前記第１物のキャンペーンの情報が含まれないよう制御する、
   請求項１又は４に記載の情報処理装置。
6. 前記プロセッサは、
   前記ユーザの視界内に存在する前記第２物についての第２物情報が前記ユーザに提示される際に、前記第１物情報も前記ユーザに提示されるよう制御する請求項４に記載の情報処理装置。
7. 前記プロセッサは、
   前記第１物情報が、前記ユーザに見えている前記第１物に重ならないように前記ユーザに提示されるよう制御する請求項１に記載の情報処理装置。
8. 前記プロセッサは、
   前記第１物情報が、前記ユーザに見えている前記第２物に重ならないように前記ユーザに提示されるよう制御する請求項４に記載の情報処理装置。
9. 前記プロセッサは、
   前記第１物についての第１物情報の前記ユーザへの提示に関する決定を行う、
   請求項４に記載の情報処理装置。
10. 前記プロセッサは、
    前記第２物情報として、前記第１物の利用を条件として有効となる、前記第２物のキャンペーンの情報が前記ユーザに提示されるよう制御する、
    請求項６に記載の情報処理装置。
11. 前記ユーザに提示される前記第２物情報は、前記第２物にて提供されるサービスの予約を促す、
    請求項６に記載の情報処理装置。
12. 前記プロセッサは、
    前記第１物情報として、前記第２物の利用を条件として有効となる、前記第１物のキャンペーンの情報が提示されるよう制御する請求項４に記載の情報処理装置。
13. 前記ユーザに提示される前記第１物情報は、前記第１物にて提供されるサービスの予約を促す請求項１又は４に記載の情報処理装置。
14. 前記プロセッサは、
    前記第２物に対して複数の物が関連付けられている場合、前記第２物の状況情報に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置。
15. 前記プロセッサは、
    前記第２物に対して複数の物が関連付けられている場合、前記複数の物の各々の状況情報に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置。
16. 前記プロセッサは、
    前記第２物に対して複数の物が関連付けられている場合、前記複数の物の各々に対するユーザの関心度に基づき、前記第１物を前記複数の物の中から決定する請求項４に記載の情報処理装置。
17. 前記プロセッサは、
    前記予定情報として、前記第１物の近くを通りかかった前記ユーザの次の予定の場所および開始時刻についての情報を取得し、
    前記予定情報として取得した前記次の予定の場所および開始時刻と、前記第１物の次の予約開始時刻とに基づき、前記ユーザが前記第１物を利用した場合における利益又は不利益であって前記第１物の提供者側にとっての利益又は不利益を決定し、決定した前記利益又は不利益に基づき、前記第１物情報の前記ユーザへの提示に関する決定を行う、
    請求項１に記載の情報処理装置。
18. 前記プロセッサは、
    前記利益又は不利益として、前記ユーザの前記第１物の予測利用時間を決定する請求項１７に記載の情報処理装置。
19. 前記予定情報は、前記ユーザの予定の種類を含み、
    前記プロセッサは、
    前記種類に基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う、
    請求項１又は４に記載の情報処理装置。
20. 前記予定情報は、前記ユーザの予定に関連する人物の情報を含み、
    前記プロセッサは、
    前記人物の数に基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う、
    請求項１又は４に記載の情報処理装置。
21. 前記プロセッサは、
    前記予定情報として、少なくとも、前記ユーザの予定の開催場所と開始時刻とを取得し、
    現在時刻から前記開始時刻までの残り時間と、現在地から前記開催場所への移動に要する時間である所要時間とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項１又は４に記載の情報処理装置。
22. 前記プロセッサは、
    取得した前記予定情報と前記第１物の状況情報とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項１又は４に記載の情報処理装置。
23. 前記プロセッサは、
    取得した前記予定情報と前記第２物の状況情報とに基づき、前記第１物情報の前記ユーザに対する提示に関する決定を行う請求項４に記載の情報処理装置。
24. 前記情報処理装置は、前記ユーザとともに移動するカメラにより得られた映像を基に、前記ユーザの周囲に存在する物を特定する請求項１又は４に記載の情報処理装置。
25. 前記情報処理装置は、前記ユーザとともに移動する移動装置であり、
    前記プロセッサは、
    前記ユーザの現在地と前記ユーザが向いている方角とに基づき、前記ユーザの周辺に存在する物を特定する請求項１又は４に記載の情報処理装置。
26. 前記情報処理装置は、前記ユーザの眼球の前に装着される装置である、
    請求項１又は４に記載の情報処理装置。
27. 前記情報処理装置は、透視可能なディスプレイを有し、
    前記プロセッサは、前記ディスプレイを介して前記ユーザが視認する現実空間の現実物に前記第１物情報を対応付ける、
    請求項２６に記載の情報処理装置。
28. 前記プロセッサは、
    前記第１物の周辺に存在する複数のユーザ各々の予定についての情報を前記予定情報として取得し、
    前記予定情報に基づいて、前記複数のユーザの中から特定の条件を満たすユーザを特定し、特定したユーザを、前記第１物情報を提示する先となるユーザとして決定する、
    請求項１に記載の情報処理装置。
29. 前記プロセッサは、
    前記第２物の周辺に存在する前記複数のユーザ各々の予定についての情報を前記予定情報として取得し、
    前記予定情報に基づいて、前記複数のユーザの中から特定の条件を満たすユーザを特定し、特定したユーザを、前記第１物情報を提示する先となるユーザとして決定する、
    請求項４に記載の情報処理装置。
30. 前記情報処理装置は、前記ユーザとともに移動する移動装置と通信を行い、
    前記プロセッサは、
    前記移動装置のディスプレイに前記第１物情報が表示されるよう制御する請求項１又は４に記載の情報処理装置。
31. ユーザの周辺の状況が写っている映像に基づき、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第１物が存在することを特定する機能と、
    前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第１物についての情報である第１物情報の前記ユーザへの提示に関する決定を行う機能と、
    をコンピュータに実現させるためのプログラムであり、
    前記第１物は、前記予定情報に含まれない物である、
    プログラム。
32. ユーザの周辺の状況が写っている映像、又は、電子地図とユーザの現在地とユーザが向いている方向とに基づき、前記ユーザの周辺に第２物が存在することを特定する機能と、
    前記ユーザの予定についての情報である予定情報に基づき、存在を特定した前記第２物と予め定められた関係にある第１物であって、前記第２物とは異なる場所に存在する第１物についての第１物情報の前記ユーザへの提示に関する決定を行う機能と、
    をコンピュータに実現させるためのプログラムであり、
    前記第１物は、前記予定情報に含まれない物である、
    プログラム。