JP2017126305A - 情報提供装置、システム及びプログラム - Google Patents

Abstract

【課題】最初に簡単な基本個人情報を情報提供装置に入力するだけで、その後は情報提供装置との擬似コミュニケーションにより適宜に追加の個人情報を入力することで、情報入力の負担を軽減するとともに、情報提供装置から健康に関する適切な情報を適切なタイミングで提供できるようにする。【解決手段】ユーザから取得したい個人情報のうち幾つかを予め受け付ける操作部１０７と、操作部１０７によって受け付けていない個人情報に対応する属性の質問を行う制御部１０１及び表示部１０８と、表示部１０８による質問に対する返答である個人情報を操作部１０７が受け付けて、操作部１０７によって受け付けられた個人情報と当該個人情報に対応する属性とが紐付けた状態で格納される記憶部１０２と、を備える。【選択図】図２

Description

本発明は、情報提供装置、システム及びプログラムに関し、特に、ユーザの日常生活に対して適切な情報を提供する情報提供装置、システム及びプログラムに関する。

従来、人間の健康を維持するために、様々な情報が提供されている。特に、近年飛躍的に普及しているスマートフォンなどの携帯端末を利用した健康に関するアプリケーションが注目されている。例えば、特許文献１に開示されている発明によれば、ユーザの自宅に、通信機能付又はそれに準じる機能が付与されている各種センサが設置され、脈拍や呼吸等の測定、血圧、脈拍、体組成計、血糖値計、体重計等による測定を行う構成になっている。これらの測定データは通信機能を介してサーバに蓄えられ、ユーザごとに健康管理が把握できるようになっている。

特開２０１０−２８７１９５号

しかし、特許文献１に開示されている発明は、ユーザ自身が、脈拍や呼吸等の測定、血圧、脈拍、体組成計、血糖値計、体重計等による測定を少なくとも数日ごとに繰り返し行う必要があるため、その様々な個人情報の入力のための煩雑な作業がユーザの負担になってしまう。

特に、例えば、サラリーマンなど仕事をしている多くの人々は、いくら自分の健康維持のためとはいえ、毎日の多忙な生活の中で面倒な個人情報の入力を持続して行うことは困難であるという課題があった。

そこで、本発明は、特許文献１とは異なるアプローチとして、情報提供装置との擬似コミュニケーションにより適宜に追加の個人情報を入力することで、情報提供装置から健康に関する情報を含む各種情報を適切なタイミングで提供できるようにすることを課題とする。

上記課題を解決するために、本発明の情報提供装置は、
ユーザから取得したい個人情報のうち幾つかを予め受け付ける第１受付手段と、
前記第１受付手段によって受け付けていない個人情報に対応する属性の質問を行う質問手段と、
前記質問手段による質問に対する返答である個人情報を受け付ける第２受付手段と、
前記第１及び第２受付手段によって受け付けられた個人情報と当該個人情報に対応する属性とが紐付けた状態で格納される格納媒体と、
を備える。

また、本発明の情報提供システムは、
上記情報提供装置を複数有しており、
当該情報提供装置が相互にネットワークを介して接続された場合に、最新の個人情報が格納されている格納媒体の内容で、他方の格納媒体の内容を更新する。

また、本発明の情報提供プログラムは、
ユーザから取得したい個人情報のうち幾つかを予め受け付けるステップと、
受け付けていない個人情報に対応する属性の質問を行うステップと、
前記質問に対する返答である個人情報を受け付けるステップと、
前記受け付けられた個人情報と当該個人情報に対応する属性とを紐付けた状態で格納するステップと、
を情報提供装置に実行させる。

本発明によれば、ユーザから最初に受け付けた個人情報以外の個人情報を取得することができるので、それらの情報に基づいて健康に関する情報を含む各種情報を提供することができる。

本発明の実施形態１における情報提供システムの構成例を示す図である。 図１の情報提供装置を構成するユーザ端末のブロック図である。 図２のユーザ端末の動作を示すフローチャートである。 図３に続くフローチャート例を示す図である。 図２の表示部に表示された基本情報入力の画面例を示す図である。 図５の基本情報入力に続く画面例を示す図である。 図６の基本情報入力に続く画面例を示す図である。 図７の基本情報入力に続く画面例を示す図である。 基本情報入力の確認の画面例を示す図である。 図２の表示部に表示された詳細情報入力の画面例を示す図である。 図１０の詳細情報入力に続く画面例を示す図である。 図２の表示部に表示されたイベント通知情報の画面例を示す図である。 図２の表示部に表示されたアドバイス情報の画面例を示す図である。 図２の表示部に表示された嗜好情報質問の画面例を示す図である。 図２の表示部に表示された生活情報質問の画面例を示す図である。 本発明の実施形態２の情報提供装置の動作を示すフローチャートである。

１００ ユーザ端末
１０１ 制御部
１０２ 記憶部
１０３ 通信部
１０４ 時計部
１０５ 温度センサ部
１０６ 加速度センサ部
１０７ 操作部
１０８ 表示部
１０９ 音声入力部
１１０ 音声出力部
１１１ 振動部
１１２ 位置検出部
１１３ バス
１１４ タッチパネル
２００ ロボット
３００ サーバ
４００ ネットワーク

発明の実施の形態

以下、本発明の実施形態について、図面を参照して説明する。

（実施形態１）
図１は、本発明の実施形態１における情報提供システムの構成例を示す図である。図１の情報提供システムは、以下説明する、ユーザ端末１００Ａ〜１００Ｅ（これらの総称を「ユーザ端末１００」と称する。）と、ロボット２００と、ウェブサーバ３００と、ネットワーク４００とを備えている。

ユーザ端末１００は、例えば、電話機能及び通信機能を有するスマートフォン１００Ａ〜１００Ｄ、腕時計型のリスト端末１００Ｅなどの情報提供装置の総称である。もっとも、ユーザ端末１００は、スマートフォンやリスト端末のみならず、パーソナルコンピュータ、タブレットなどの各種の情報提供装置とすることもできる。

ロボット２００は、例えばユーザ端末１００Ａ及びリスト端末１００Ｅを保有するユーザの家屋内に設置された情報提供装置である。ロボット２００は、ネットワーク４００を介して、ユーザ端末１００Ａ及びリスト端末１００Ｅとの間で後述する個人情報を共有することができる。なお、この実施形態において、ロボット２００は、家屋内の部屋においては、ユーザの指示に応じて移動することが可能である。このために、ロボット２００は既知の移動手段を備えている。

ウェブサーバ３００は、例えば、健康に関する情報を含む、様々な情報が蓄積されているものである。ウェブサーバ３００は、ネットワーク４００を介してアクセスされたユーザ端末１００、ロボット２００からの要求に応じた情報を発信する。

ネットワーク４００は、インターネットなどで構成され、ユーザ端末１００、ロボット２００、ウェブサーバ３００、及び、他のウェブサーバとの間における通信を実現するものである。

図２は、図１のユーザ端末１００（１００Ａ〜１００Ｅ）の構成を示すブロック図である。図２において、ユーザ端末１００は、以下説明する、制御部１０１と、記憶部１０２と、通信部１０３と、時計部１０４と、温度センサ部１０５と、加速度センサ部１０６と、操作部１０７と、表示部１０８と、音声入力部１０９と、音声出力部１１０と、振動部１１１と、位置検出部１１２と、バス１１３と、操作部１０７及び表示部１０８を含むタッチパネル１１４とを備えている。

なお、図２には示していないが、ユーザ端末１００は、静止画又は動画を撮像するカメラ部、近距離通信のための赤外線又はブルートゥースなどを用いる近距離用通信部、及び各構成要素に電力を供給する電源部を備えている。

制御部１０１は、例えば、ＣＰＵ（Central Processing Unit）などの演算処理デバイスを含み、制御プログラムに従って、バス１１３を介して上記の各構成要素との間で指令及びデータの入出力を行って、ユーザ端末１００全体の動作を制御するものである。

記憶部１０２は、例えば、制御部１０１によって実行される制御プログラム、及び、ユーザ端末１００の電源がオンされたときに行われるイニシャライズ処理に必要な初期データを記憶するＲＯＭ（Read Only Memory）と、制御部１０１によって処理されるデータを記憶するデータメモリとを有する。なお、データメモリは、データを一時的にストアするとともに、ユーザ端末１００の電源がオフになるとストアしたデータが消去するＲＡＭ（Random Access Memory）などの揮発性のメモリと、ユーザ端末１００の電源がオフになってもストアしたデータを保持するフラッシュメモリなどの不揮発性のメモリとを含む。この不揮発性メモリは、後述するユーザの個人情報、生活パターンなどを格納する格納媒体としても用いられる。

通信部１０３は、所定の無線通信プロトコルに従って、他のユーザ端末１００との通話機能又はメール機能によりデータ通信を行うとともに、ロボット２００、ウェブサーバ３００、及び、他のウェブサーバとの間における情報通信を行うものである。

時計部１０４は、現在時刻を計時して、制御部１０１に時間情報、現在の年月日の情報を、制御部１０１に出力するものである。また、これらの情報は、カレンダーアプリでも用いられる。

温度センサ部１０５は、適宜に又は制御部１０１の指示を入力し、ユーザ端末１００の周囲の温度を検出して、検出結果である温度情報を制御部１０１に出力するものである。

加速度センサ部１０６は、適宜に又は制御部１０１の指示を入力し、重力方向を基準として、上下、左右、及び前後の３軸の加速度の変化を検出して、ユーザ端末１００を携帯しているユーザ自身の歩行、走行、運動中の動作、及び、電車、自動車などの乗物での移動に伴う、ユーザ端末１００の位置変化情報を検出して、制御部１０１に出力するものである。

操作部１０７は、ユーザの入力操作を受けて、その操作情報を制御部１０１に出力するものである。

表示部１０８は、制御部１０１からの指令及びデータに応じて、各種の情報画面を表示するものである。

操作部１０７及び表示部１０８の一部は、操作入力機能と表示機能とを併せて備えたタッチパネル１１４で実現することができる。タッチパネル１１４は、後述するように、制御部１０１、記憶部１０２と協働して、ユーザから取得したい個人情報を予め受け付ける第１受付手段と、第１受付手段によって受け付けていない個人情報に対応する属性の質問を表示によって行う質問手段と、質問手段による質問に対する返答である個人情報を受け付ける第２受付手段とを実現することができる。

音声入力部１０９は、例えば、ユーザからの音声やユーザの周囲の環境音を電気信号に変換するマイクロフォンを含む。通話中のユーザの音声は、アナログ信号からデジタル信号に変換され、その後、通信部１０３によって相手側に送信される。さらに、音声入力部１０９は、音声認識機能を備えており、音声出力部１１０とともに、ユーザとユーザ端末１００との間で音声を媒体とする擬似コミュニケーションを実現するものである。擬似コミュニケーションについては、さらに後述する。

音声出力部１１０は、スピーカを含み、また、イヤホン、ヘッドホン用のコネクタを含む。音声出力部１１０は、通話中に通信部１０３によって受信された通話先のユーザ端末１００からのデジタル信号をアナログ信号である音声に変換して出力する。また、音声出力部１１０は、上記した擬似コミュニケーションを実現するために、音声合成機能を備えている。

振動部１１１は、いわゆるマナーモードが設定されている場合に、電話の着信、メールの受信などを、振動によってユーザに通知するものである。さらに、振動部１１１は、制御部１０１の指令に応じて、擬似コミュニケーションを促す場合に振動するものである。振動部１１１を備えると、ユーザがタッチパネル１１４を見ていない場合や、マナーモードの設定中に音声を媒体とした擬似コミュニケーションができない場合に有効である。

位置検出部１１２は、ＧＰＳ（Global Positioning System：全地球測位システム）検出部によって実現でき、ユーザが携帯しているユーザ端末１００の現在位置を検出して、適宜に又は制御部１０１の指令に応じて、その現在位置情報を制御部１０１に出力するものである。

バス１１３は、システムバス、データバス、及びアドレスバスなどで構成され、制御部１０１と他の構成要素との間で、指令及びデータを伝送する伝送路である。

ここで、図１に示すロボット２００の構成は、図２に示すユーザ端末１００の構成とほぼ同じとすることができる。ただし、ロボット２００は、家屋内に据え付ける場合には、転居その他の特別な場合を除き、家屋内の所定の部屋以外では、位置が変化することがないため、位置検出部、加速度センサ部及び振動部などは、必ずしも備えなくてもよい。

さらに、図１に示すように、例えば、ユーザ端末１００とロボット２００とが相互にネットワーク４００を介して接続される場合には、ユーザ端末１００とロボット２００との記憶部内の情報を同期させて、いずれの記憶部にも最新の個人情報が格納されるようにするとよい。

つぎに、図２に示すユーザ端末１００の動作について、制御部１０１によって実行される制御プログラムのフローチャート、バス１１３を介して入出力される指令及びデータ、及びタッチパネル１１４に表示される画面に基づいて説明する。

図３は、図２に示すユーザ端末１００の初期動作を示すフローチャートである。ここでは、以下説明する動作を実現可能なアプリケーション（以下、「コンシェルジュアプリ」と称する。）が、ダウンロードされ、かつ、インストールされている、ユーザ端末１００の動作例を説明する。

ユーザ端末１００の電源がオンされている状態で、ユーザによって選択的に既知のロック画面を通じてパスワードが入力されたことを条件に、メニュー画面をタッチパネル１１４に表示するというメニュー画面表示処理を実行する（ステップＳ１０２）。メニュー画面には、電話、メール、インターネット、カメラ、目覚まし設定、マナーモード設定などのメニューとともに、コンシェルジュアプリのメニューが表示される。

この状態で、タッチパネル１１４に表示コンシェルジュアプリのアイコンを、ユーザがタッチするなどして起動を選択すると、制御部１０１は、このことを特定して（ステップＳ１０３）、ユーザの個人情報のうち以下の基本情報が、ユーザから入力済みであるか否かを判別する（ステップＳ１０４）。基本情報が入力済みでない場合には、基本情報入力画面をタッチパネル１１４に表示するという入力画面表示処理を実行する（ステップＳ１０５）。

なお、ステップＳ１０２の実行により表示されるメニュー画面で、ステップＳ１０３に示すコンシェルジュアプリが選択されず、他のアプリが選択された場合には、その選択されたメニューの処理が実行される（ステップＳ１０８）。例えば、目覚まし設定のメニューが選択された場合には、設定時刻や目覚まし有効曜日などの設定操作に応じて、その内容を記憶部１０２の不揮発性メモリにストアされる。

図５〜図９は、図３に示すステップＳ１０５の入力画面表示処理を実行することによってユーザ端末１００のタッチパネル１１４に表示される基本情報入力の画面例を示す図である。

図５に示すように、タッチパネル１１４には、基本情報として、例えば、ユーザの氏名、性別、及び、年齢だけといった極めてわずかな情報の入力又は選択を促す旨が表示される。なお、ここで重要なのは、当初入力等させる情報が少ないということである。したがって、基本情報を構成する情報は、必ずしも、ユーザの氏名等に限定されるものではないし、これらを必ず用いなければわけではない点に留意されたい。

また、タッチパネル１１４には、ＹＥＳボタン１１４ａ、ＮＯボタン１１４ｂ、及び、カーソルボタン１１４ｃといったタッチボタンと、現時点の年月日及び時刻を示す表示枠１１４ｄと、ユーザによる入力対象を示す指定マーク１１４ｅとが表示されるようにしている。これらのボタンは、一例として示しており、例えば、「進む」ボタン・「戻る」ボタンなどとしてもよい。

図６には、図５に示す状態でユーザが例えばＹＥＳボタン１１４ａをタッチしたときに移行する画面例である。図６には、キーボード画像１１４ｉがマルチウインドウで表示される例を示している。ユーザは、キーボード画面１１４ｉを通じて、自己の氏名を入力することが可能となる。

なお、カーソルボタン１１４ｃ又はキーボード画像１１４ｉに漢字変換予測結果を表示する表示欄を設けてもよい。ユーザが氏名の入力を完了した後、ＹＥＳボタン１１４ａをタッチにすると、キーボード画像１１４ｉの表示が消えて、図７に示すように指定マーク１１４ｅが「性別」に移動する。

図７に示す画面は、デフォルトの画面であり、ラジオボタンでは「男」が選択されている状態となる。したがって、この状態で、ユーザがＹＥＳボタン１１４ａをタッチすると、性別が男性であることが選択される。一方、図７に示す状態で、一度、カーソルボタン１１４ｃをタッチすると、ラジオボタンは「女」を選択している状態に移行する。したがって、この状態で、ユーザがＹＥＳボタン１４ａをタッチすると、性別が女性であることが選択される。

こうして、男性・女性といった性別情報が選択されると、キーボード画像１１４ｉの表示が消えて、図８に示すように指定マーク１１４ｅが「年齢」に移動する。

図８に示すように、指定マーク１１４ｅが年齢の文字に移動すると、これとともに、再びキーボード画像１１４ｉが表示される。もっとも、キーボード画像１１４ｉに代えて、スクロールタイプの年齢選択画面を表示させることもできる。つぎに、ユーザが年齢を入力又は選択してＹＥＳボタン１１４をタッチにすると、図９に示すように入力された基本情報の確認画面が表示される。

図９に示す確認画面において、ユーザがＮＯボタン１１４ｂをタッチにすると、図５〜図８に示す画面を通じて入力された全ての情報が例えば消去されて、再び、図５に示した基本情報の入力を促す画面に移行する、或いは、直前に入力した情報が消去されて、図８に示す画面に移行、つまり、直前に表示していた画面に戻る。一方、図９に示す確認画面において、ユーザがＹＥＳボタン１１４ａをタッチすると、ユーザによる情報入力処理は終了する。

ユーザ端末１００の動作としては、その後に、基本情報の入力が完了すると、制御部１０１は、入力された基本情報を記憶部１０２の不揮発性メモリにストアするといったストア処理を実行する（ステップＳ１０６）。

その後、温度センサ部１０５で検出された現在の温度情報、加速度センサ部１０６で検出された変位情報、音声入力部１０９で検出されたユーザの周囲音の情報、位置検出部１１２で検出されたユーザ端末１００の位置情報などの各種情報（以下、「環境情報」と称する。）を取得するために、後述するサブルーチンを例えば１０分ごとにコールできるようにするセット処理を実行する（ステップＳ１０７）。

こうして、図３に示す処理が終了する。以上の処理により、ユーザの氏名・性別・年齢といった基本的な情報が、コンシェルジュアプリと紐づけられることになる。なお、ここで入力される氏名等の情報は、必ずしも真のものでなくてもよく、例えば氏名の情報であれば、ユーザが任意に、架空の人物のもの、ニックネーム或いはハンドルネームなどとすることもできる。

また、ステップＳ１０７の実行により、サブルーチンをコールする時間の到来を監視するプログラムが起動される。このプログラムによって、当該時間が到来すると、制御部１０１は、後述するステップＳ１１０の処理を実行する。

なお、当該時間が到来しても、直ちに、ステップＳ１１０の処理を実行するのではなく、後述するように、そのときの加速度センサ部１０６、位置検出部１１２、及び、音声入力部１０９から得られる環境情報を考慮した上で実行タイミングを決定してもよい。

さらに、ユーザ端末１００にカレンダーアプリがインストールされている場合に、ユーザが予め所定のイベントの種別又は内容、更には、その開催日時等といったイベント情報をユーザ端末１００に入力することができる。カレンダーアプリは、その開催日時に基づいて、ユーザに対してイベント開催日時が到来することのリマインダーを発することができる。

本実施形態では、コンシェルジュアプリとカレンダーアプリ等とを連動させて、ステップＳ１１０の処理の一環として、或いは、これとは別の処理として、後述のステップＳ１１１〜Ｓ１１６の各処理を実行するようにしている。

図４は、図３に示す初期動作が完了した後にコンシェルジュアプリによってなされる制御部１０１の動作例を示すフローチャートである。制御部１０１は、ステップＳ１０７でセットされた時間が到来すると、各種センサ部１０５等をオンする。各種センサ部１０５等は、これによって環境情報を取り込み、それらを記憶部１０２のＲＡＭに一時的にストアするといった環境情報ストア処理を実行する（ステップＳ１１０）。

この処理は、全てのセンサ部からの情報を同時刻にセンシングして一度に取り込んでもよいし、順次、所定時間内に取り込んでもよい。また、例えば、温度センサ部１０５によって得られる温度情報などは、頻繁に変化しないと考えられるので、この種のセンサ部については、例えば１時間ごとにオンすることとしてもよい。

つぎに、例えば、ユーザ端末１００のカレンダーアプリを通じて新たなイベント情報が登録されたか否かを判別する（ステップＳ１１１）。判別の結果、新たなイベント情報が登録されていない場合には、図４に示す処理を終了する。一方、新たなイベント情報が登録された場合には、当該情報を抽出して、記憶部１０２のＲＡＭに一時的にストアするといったイベント情報ストア処理を実行する（ステップＳ１１２）。

その後、当該イベント情報に関連する質問の発生要因があるか否かを判別する（ステップＳ１１３）。具体的には、例えば、カレンダーアプリを通じて「今週末の１８：００から飲み会」といった旨のイベント情報がユーザ端末１００に入力された場合には、「お酒は好きですか？」、「ビール党ですか？」、「週にどのくらいお酒を飲みますか？」などの質問の発生原因があるという判別結果が得られるようにしている。

別の例としては、「来週日曜日の１３：００からサッカー」といった旨のイベント情報が入力された場合には、「サッカーチームに所属しているのですか？」、「サッカーの試合は良く観戦するのですか？」、「いつからサッカーを始めたのですか？」などの質問の発生原因があるという判別結果が得られるようにしている。

判別の結果、発生要因がない場合には、図４に示す処理を終了する。一方、発生要因がある場合には、これらの質問を既に行っていないことを確認した場合には、発生要因に基づく質問画面作成して、タッチパネル１１４に表示といった質問画面表示処理を実行する（ステップＳ１１４）。こうして、質問画面を通じて、ステップＳ１０５の実行によって取得する基本情報とは異なるユーザの詳細情報の入力をユーザに促す。

ここで、実際のコミュニケーションの場面では、複数の質問を一度に投げかけることがないわけではないが、一つの質問をして、それに対する返答に応じた次の質問をするといった、言葉のキャッチボールをする場面が多いと考えられる。したがって、質問は一つずつすることも一法である。

なお、コンシェルジュアプリの使用開始から相対的に短期間の場合などには、ＹＥＳ又はＮＯで返答できるような質問として、かつ、その質問画面内にＹＳＥボタン、ＮＯボタンも表示すれば、ユーザが回答にあたり行う入力操作が簡便になるので、操作が面倒であることを理由としてコンシェルジュアプリをアンインストールしようといったインセンティブがユーザに働くことは少ないと考えられる。このように、質問の仕方を工夫すると、コンシェルジュアプリの使用頻度が高まり、ひいては、ユーザ情報の収集に寄与することが期待できる。

ちなみに、上記の質問例はいずれもＹＥＳ又はＮＯで回答できる質問である。ゆえに、典型的には、「お酒は好きですか？」という第１の質問画面を表示し、それに対してユーザがＹＥＳを回答した場合、つづいて「ビール党ですか？」という第２の質問画面を表示し、それに対してユーザがＹＥＳ又はＮＯを回答した場合、つづいて「週にどのくらいお酒をみますか？」という第３の質問画面を表示して、それに対するユーザの回答を促すことができる。

なお、ユーザからの回答がＹＥＳであるのか、ＮＯであるのかは必ずしも予測できるものではないので、第１〜第３の質問画面における質問事項は相互に従属性のあるものとしないことも一法である。そうすると、質問画面の表示順序も制限を受けることがないといったメリットもある。

また、ユーザからの回答結果の集積数が多くなればなるほど、質問していない事項に対する回答が予測できることもある。その際には、ユーザに対して回答時の負荷を与える原因とならないように、敢えて、その事項について質問をしないということも一法である。

ここでいう予測の例としては、例えば、「お酒は好きですか？」という第１の質問画面を表示した際に、ユーザからの回答がなされなかったとする。それでも、その後に、カレンダーアプリを通じて飲み会に関するイベント情報が幾つか入力された場合には、このユーザはお酒を飲むことが好きであろうという予測をする。

係る場合には、第１の質問画面を再度表示することなく、ＹＥＳが回答された場合に行う処理と同じ処理をすることもできる。これにより、ユーザに対して回答操作を強いることが軽減されるので、特に、多忙なユーザへの対応としては好ましいということができる。

また、予め用意している一又は複数の質問に対する回答がなされ、ユーザからの詳細情報の入力の完了がされると、ユーザから回答された詳細情報を記憶部にストアするといった詳細情報ストア処理を実行して、図４に示す処理を終了する（ステップＳ１１５）。

本実施形態では、取得したいユーザ情報を回答させるような質問を幾つか用意している。これは、ユーザとの疑似コミュニケーションにも非常に貢献をすることになる。この種の質問の例を挙げると、ユーザの典型的な生活パターンを把握するための質問が考えられるが、これだけに留まらず、基本情報の取得の場面ではあえて聞いていない多岐に亘る質問を用意するとよい。

この種の質問としては、例えば、趣味に関する情報（スポーツが好きなのか、そうだとしたら野球なのかサッカーなのか、また、どのくらいの頻度でプレイ又は観戦をしているのか、など。）、仕事／学校に関する情報（どのような業種／学部（学科）なのか、勤続年／大学（高校）何年生なのか、など）、生活に関する情報（休日の過ごし方だとか、既婚・未婚の別だとか、通常の帰宅時刻だとか、生活習慣を含む衣食住の好みとか、など）についての質問が考えられる。

そして、最終的には、用意している全ての質問に関する回答が取得又は予想できれば、ユーザとの間で非常に好適な疑似コミュニケーションを図ることが可能となるし、一歩進んで、ユーザに対する種々の提案をすることも可能となる。ユーザに対する種々の提案については、実施形態２として後述する。

質問の仕方も工夫するとよい。例えば、ユーザにとって明らかに無関係と思われる質問をすることは、ユーザに対して回答時の負荷を与える原因の一つとも考えられる。これは、コンシェルジュアプリアンインストールさせる一因となるかもしれない。

そこで、ユーザの基本情報として、例えば、「４０歳」・「男性」という基本情報を取得していた場合には、多くの場合、当該ユーザは社会人であると考えられるので、学生用の質問はしないし、女性用の質問もしないということが考えられる。

そして、当該ユーザが実際に社会人であるか否かを特定するためには、まずは、「通常の退社時刻は何時くらいですか？」というような社会人固有の内容に関する質問をすることも香苗らえれる。なお、ユーザの基本情報が仮に「１７歳」・「女性」であれば、多くの場合、当該ユーザは高校生であると考えられるので、上記の「退社」時刻に代えて「学校を出る」時刻を尋ねる質問になろう。

もちろん、例えば、コンシェルジュアプリの使用開始から相対的に短期間では、社会人用にも学生用にも共通する質問をすることも考えられる。この種の質問の例としては、通常の就寝時刻であったり、通常の休日がいつであるかだったり、休日の通常の過ごし方であったり、といった質問が挙げられる。

話を戻すと、「４０歳」・「男性」という基本情報を取得していた場合に、その後に、社会人用の質問をすることで、最終的には、当該ユーザが、通常であればほぼ午後６時頃には会社を退出するとか、普段はデスクワークをしているとか、といった、当該ユーザの生活パターンを特定することも可能となる。

そして、このような生活パターンのユーザが、仮に、平日午後７時頃になっても、角速度センサ部１０６のセンシング結果に変化がない場合、或いは、位置検出部１１２からのユーザの位置情報が会社内であることを検出した場合には、そのタイミングで、或いは、更にもう１時間後、又は、通常の就寝時刻の例えば１時間前などの適当なタイミングで、疑似コミュニケーションとして「今日は残業ですか？」といった問いかけをユーザに発することも可能である。

また、相対的にコンシェルジュアプリの使用開始から短期間などでは、まだ、ユーザ情報の取得量はそれほど多くないと考えられるので、上記の場合に単なる問いかけに代えて、さらに、ユーザ情報を更に取得するための質問をすることも考えられる。この点については、図１０及び図１１を用いて後述する。

ユーザとの疑似コミュニケーションを促進することに繋がれば、その結果としてユーザも、積極的にコンシェルジュアプリによる質問に回答しようとするインセンティブに繋がると考えられる。なお、例えば、コンシェルジュアプリの使用開始から相対的に長い期間が経過しているような場合には、フリーワードでの回答が好適な場合もあると考えられるので、ＹＥＳ又はＮＯで回答可能な質問とせずに、フリーワードで回答可能な質問としてもよい。

なお、ここでは、カレンダーアプリにイベント情報が入力されたことをトリガーとして、ユーザに質問をする例を説明したが、トリガーとなる事象は、イベント情報の入力に限定されるものではない。

例えば、ユーザが電話をしている際に、ユーザの会話の内容を、音声入力部１０９などが備える音声認識機能を活用して、これらのキーワードを抽出し、当該キーワードに基づく質問としてもよい。

すなわち、「来週日曜日の１３：００からサッカーの試合がある」といった内容の会話をユーザがしていた場合には、「サッカー」、「試合」といったキーワードを抽出して、既述のような質問をすることもできる。同様に、メールの送受信の内容から、同じくキーワードを抽出して、それらに基づく質問をすることもできる。

図１０は、タッチパネル１１４に表示される詳細情報入力の画面例を示す図である。例えば、普段、平日午後６時に帰宅のため会社を出発するユーザが、平日午後８時を過ぎても会社にいる場合には、「働き過ぎていませんか？」といったメッセージを表示するとともに、記憶部１０２を参照してユーザの社会人に関する情報のうち取得できていない情報を特定して、それらに関する情報の入力を促すことが考えられる。

ここでは、取得できていない情報の例が、職業、年収、家族構成だった場合の例を示している。また、疑似コミュニケーションも兼ねて、ユーザの最近の体調をチェックするため、ユーザのＢＭＩ（Body Mass Index）を算出するメッセージ（図示せず）を示して、このために、身長及び体重の個人情報の入力を促すということをしてもよい。

なお、秘匿性を要する個人情報の回答を促す質問をする場合には、それに先立って、その質問画面表示をする前に、音声入力部１０９をアクティブにするなどして、ユーザの周囲で他人の音声を検出しないことを確認するようにしてもよい。

また、本実施形態では、ユーザがその種の個人情報を入力できない、或いは、したくない状況もあろうと考えられるので、ＮＯボタン１１４ｂをタッチすることで、その状況では回答の入力拒否をすることができるように配慮している。

また、コンシェルジュアプリの使用開始から相対的に時間が経過していない場合などには、簡単な個人情報を回答させるための質問を行うとよい。そして、ユーザがさらなる個人情報を回答できる、或いは、したい環境の中で、疑似コミュニケーションを交えたりしながら、詳細情報の入力を促すとよい。こうすると、ユーザに対して、いわばコンシェルジュアプリとの信頼感が高まっている状況で詳細な個人情報の入力を促すことになるので、詳細情報を入力しやすくとなると考えられる。

例えば毎日の多忙な生活を送る現代人の多くにとっては、コンシェルジュアプリの使用開始直後から多数のユーザ情報を回答することを面倒であることも考えられるが、本実施形態によれば、ユーザは、多数の個人情報の回答を使用開始直後から一度に行う必要はないし、コンシェルジュアプリに対する信頼感を高めていきながら、疑似コミュニケーションを楽しみつつ、持続的にユーザ情報を回答することができる。

図１１は、図１０に続く詳細情報入力の画面例を示す図である。図１１に示すように、ユーザが身長及び体重の情報を入力した後、指定マーク１１４ｅで入力を促す職業について、文字入力のためのキーボード画像１１４ｉが表示される。このような回答の場面では、ＹＥＳ又はＮＯでの回答ではなく、フリーワードでの回答ができるようにすることが必須である。

そして、実際に、ユーザがすべての詳細情報を入力した後、ＹＥＳボタン１１４ａをタッチすると、入力された詳細情報についての確認画面（図示せず）が表示され、この確認画面でユーザがＹＥＳボタン１１４aをタッチすると、質問に対する情報入力が終了する。

（実施形態２）
図１６は、本発明の実施形態２における情報提供システムの制御部１０１の動作を示すフローチャートであり、図４に示すものに対応する。本実施形態では、ユーザに対する健康管理の提案をする場合の動作について説明する。なお、本実施形態の情報提供システム及びユーザ端末１００の構成は、図１及び図２に示したものと同様である。また、図１６に示す処理を実行するタイミングは、例えば、１週間に１度とすることができ、この場合には図３のステップＳ１０７でセットする時間を１週間とすればよい。

本実施形態では、まず、ユーザの生活パターン（予測によるものを含む）を示すパターン情報につき作成済みであるか否かを判別する（ステップＳ１１７）。パターン情報につき作成済みである場合には、それに従ったアドバイスをすることが考えられ、ステップＳ１２０に移行する。

なお、ここでいうパターン情報が作成済みという状況は、例えば、既述の趣味に関する情報、嗜好情報などを含む、予め用意されているユーザに関する質問事項に対する全ての回答をもって情報が作成された状態をいう。もっとも、本システムの管理者は、新たに質問を増やしたり、既存の質問内容を新たな質問内容に更新したりといった、コンシェルジュアプリのバージョンアップをすることも考えられるので、一度、ステップＳ１１７からステップＳ１２０に移行したからといって、その後にステップＳ１１７からステップＳ１１８に移行することがないわけではない。

一方、パターン情報につき作成済みでない場合には、例えば平日及び休日におけるユーザの具体的な生活習慣を、以下に示す経験則から導出される判断指針に基づいて予測する（ステップＳ１１８）。

仮に、ユーザの平日の典型的なスケジュールが、実施形態１による質問に対する回答から、以下のものであると特定又は予想したとする。ここでは、種々の例を示すため、＜ ＞が付されている項目は、ユーザから質問に対する回答によって取得したのではなく、＜ ＞内に示している習慣などに基づいて、ユーザ端末１００で予想したものとして説明する。

（１）６：００ 起床＜目覚ましのアラームの設定時刻＞
（２）７：００頃 朝食
（３）７：３０頃 自宅を出発＜角速度センサ部で変位検出＋位置センサ部で位置変化検出＞
（４）７：４５頃 自宅の最寄駅から電車に乗る＜ブラウザ等の起動開始＞
（５）８：４５頃 会社の最寄駅で電車を降りる＜ブラウザ等の起動終了＞
（６）９：００頃 午前の業務を開始
（７）１２：００頃 午前の業務が終了して昼食＜角速度センサ部で変位検出＞
（８）１３：００頃 午後の業務を開始
（９）１８：００頃 午後の業務を完了して退社
（１０）１８：３０頃 ＜夕食（外食）＞
（１１）１９：００頃 会社の最寄駅から電車に乗る＜ブラウザ等の起動開始＞
（１２）２０：００頃 自宅の最寄駅で電車を降りる＜ブラウザ等の起動終了＞
（１３）２０：１５頃 帰宅＜角速度センサ部で変位検出＋位置センサ部で位置変化検出＞
（１４）２３：００頃 就寝＜角速度センサ部で変位未検出＞

なお、実施形態１にも関係することであるので先に説明しておくと、この例では、平日の場合、このユーザのユーザ端末１００の目覚ましアラームは６：００に設定されていて、また、このユーザは２３：００頃に就寝するので、ユーザの就寝中である２３：００から６：００までの時間は、環境情報を取得しないようにして、ユーザ端末１００の低消費電力化を図ってもよい。

ここで、本実施形態では、加速度センサ部１０６からのセンシング結果が、例えば、
・前後方向に第１の閾値以下で揺れ、かつ、上下方向に第２の閾値以下で揺れがある場合には、ユーザが徒歩によって移動中であろうというと予測し、
・前後方向に第１の閾値以下で揺れ、かつ、上下方向に第２の閾値を超える揺れがある場合には、ユーザが階段を上昇又は下降中であろうというと予測し、
・前後方向に第１の閾値を超えて揺れ、上下方向に第２の閾値を超える揺れがある場合には、ユーザが走って移動中であろうというと予測し、
・周期的な上下方向の揺れがある場合には、自転車によって移動中であろうということを予測し、
・ほぼ揺れがない場合には（位置センサ部によるセンシング結果で位置変化があると判断され、かつ、ユーザ端末１００の操作がされていないとき）、自動車・オートバイによって移動中であろうということを予測するようにしている。

このような予測を行うことにしている場合には、上記の例では、加速度センサ部１０６からのセンシング結果に基づいて、７：３０頃〜７：４５頃及び２０：００頃〜２０：１５頃に、ユーザが徒歩・自転車・自動車のいずれで移動しているかを予測することができる。

なお、７：４５頃及び２０：００頃には、階段を利用する場合には、上下の揺れが大きくなるが、エスカレータ等を利用する場合には、乗降時のみわずかな揺れがあるだけなので、加速度センサ部１０６からのセンシング結果に基づいて、ユーザが階段を利用しているか、エスカレータ又はエレベータを利用しているかを予測することもできる。予測結果は記憶部１０２に記憶しておく。

また、７：４５頃〜８：４５頃では、ユーザはユーザ端末１００でニュースをチェックするなどするためにブラウザを使用する習慣があるところ、この間は徒歩、自転車、自動車などの移動中は考えにくく、また、仕事を開始したということも考えにくい。

そして、加速度センサ部１０６からのセンシング結果が、数分ごとなどに所定方向の揺れを示すならば、電車が駅で発着するときの角速度変化であろうと予測できるので、ユーザは、この期間で電車によって移動中であろうと判断できる。

したがって、係る場合には、制御部１０１は、このユーザは、７：４５頃に電車に乗り、８：４５頃に下車するのであろうという生活パターンを予測することができる。そうすると、このパターンとは異なる状態も検出したときには、ユーザが途中下車したかもしれないとか、出張かもしれないとか、クライアント先に外出したかもしれないとか、交通トラブルなどで運航遅延があったかもしれないとか、といった予測することもできる。係る場合には、この種の予測結果に基づいて疑似コミュニケーションを図ることもできる。

とりわけ、通常の生活パターンとは異なる状態も検出した際に、ニュース等をチェックすることが停止されている場合には、ユーザの体調が悪くなって、ユーザが途中下車している可能性もあろう。そこで、このような場合には、ユーザに体調に関して問いかけるといった擬似コミュニケーションを実行するとよい。

この際、不測の事態が生じた可能性もあるので、活用できるすべての構成要素（すなわち、表示部１０８、音声出力部１１０、振動部１１１）を駆使して、周囲に向けてアラートを出すようにするとよい。

また、問いかけに対して、ユーザからの応答がない場合には、緊急事態である可能性があるため、救急車の手配をしたり、病院の手配をしたりといった必要な機関に対して、ユーザの基本情報（すなわち、氏名、性別、年齢）及び現在の位置情報を通報することも一法である。或いは、基本情報として、家族のユーザ端末の連絡先を予め登録させておき、ユーザからの応答がない場合に当該連絡先に連絡をするようにしてもよい。

なお、電車の座席には幾つかのタイプが実在しているが、同じ時刻に発着する電車であれば、同じタイプの座席の電車であることが多いと考えられるので、いつもとは約９０度異なる方向に揺れていることがセンシングされた場合には、その日は、いつもと違って座席に腰を掛けているかもしれないとか、或いは、その逆で吊革につかまるなどして立った状態で乗車しているかもしれないと想定できる。

係る場合には、ユーザに対して、疑似コミュニケーションも兼ねて「今日は座れたのですか？」といったことを問いかけることもできるし、また、その結果の返答により、揺れの方向性と、座る／立つとの関係を把握することもできる。そして、例えば、通常良く座っているユーザに対しては、「健康維持のため、車内で立って通勤する日も増やしましょう」などの問いかけをすることもできる。

これを実現するためには、例えば、一般的に良いと考えられていることをリスト化した情報をユーザ端末１００に格納しておき、当該情報とのマッチングとユーザの生活パターンとを突き合わせて、相違する項目について問いかけをするということが考えられる。

また、８：４５頃に会社最寄駅で降車したであろうことを把握した場合には、加速度センサ部１０６からの情報によって、ユーザが階段を利用しているか、又は、エスカレータ或いはエレベータを利用しているかを把握することができる。

ユーザが１２：００頃に昼食を、１８：３０頃に夕食を、それぞれ外食で採る習慣があることを把握していることを把握している場合には、これらの時刻頃に、音声入力部１０９をアクティブにして、ユーザがどのような料理を注文しているかを音声認識機能によって把握することができる。

仮に、ユーザが同じような料理ばかりを摂取していることを把握した場合には、制御部１０１は、ネットワーク４００を介して、該当するウェブサーバ３００にアクセスし、食事と健康とに関する情報を、ユーザがニュース等をチェックするタイミングでアドバイスをすることもできる。

制御部１０１は、平日におけるユーザの生活習慣を予測した後は、図１６のフローチャートにおいて、ユーザの生活パターンを示すパターン情報を作成して、記憶部１０２の不揮発性メモリにストアする（ステップＳ１１９）。例えば、平日におけるユーザの生活習慣に従って、横軸を時間に取り、縦軸を行動の内容に取った生活パターンを示すパターン情報を作成してストアする。

ユーザがこのストアされたパターン情報と対比して、これと大きく異なる行動をした場合、又は、その恐れがある場合には、生活のリズムが崩れたり、不規則な生活となったりしがちなので、それを是正するような表示を行うことができる。係る場合の例としては、例えば、翌日が仕事であろうと予想される前日に、２４：００を過ぎてもニュース等をチェックしている、或いは、そうしそうだということを把握したときは、「夜更かしは良いことではないので早く寝ましょう」といったメッセージを表示することができる。

図１６のフローチャートのステップＳ１１９においてパターン情報がストアされた場合には、制御部１０１は、例えば健康のアドバイスといった各種アドバイスが必要かどうかを判別する（ステップＳ１２０）。例えば、図３のフローチャートのステップＳ１１２において、飲み会の情報を一時的にストアした場合において、例えば、昼休みのニュース等のチェックのタイミングを見計らって、健康のアドバイスをすることができる。

図１２は、図２のタッチパネル１１４に表示されたイベント通知情報の画面例を示す図である。図１２に示すように、飲み会のイベント情報を表示するとともに、「飲みすぎないように！」とアドバイスのメッセージを出力してユーザの注意を促す（ステップＳ１２１）。

次に、種々のアドバイスの出力に対して、所定時間内にユーザから了解の応答があるか否かを判別する（ステップＳ１２２）。所定時間内に応答がない場合には、アドバイスを閲覧していない可能性もあるので、メッセージの表示だけでなく、例えば、音声出力部１１０による音声でのメッセージを出力することもできる（ステップＳ１２１）。

なお、ユーザによっては、メッセージを閲覧したものの、応答をしないタイプの人もいることが想定されるので、係るタイプのユーザに対して操作上の負担とならないように、ステップＳ１２２からステップＳ１２１へ移行するというフローは、例えば１回のみ実行するということも一法である。

ところで、ユーザの休日における生活習慣を予測することは容易でない。しかし、位置検出部１１２によって、ユーザが外出したか又は自宅で過ごしたかどうかを把握することはできる。また、自宅で過ごしている場合でも、仮に、ユーザがユーザ端末１００を携帯している場合には、加速度センサ部１０６によってユーザが体操その他、体を動かしているかどうかも把握することができる。

例えば、自宅で過ごしている場合において、ユーザがあまり体を動かしていないと予想される場合には、体を動かすことが健康にとって大切である旨のメッセージを画面や音声でアドバイスをすることができる。

その場合において、スポーツ等に関する質問をタッチパネル１１４に表示して、「スポーツジムなどで体を動かしていますか？」や「学生時代には何か運動をしていましたか？」など、現在の生活の流れの中で、スポーツ等に関連するユーザの個人情報を詳細情報として回答するように、さりげなく促すことができる。

したがって、ユーザは、自然な流れの中で詳細情報を回答するので、休日でのんびりしたい中でも、負担を感じることなく個人情報の入力をすることができる。

ユーザが、自宅で体を動かして体操をしているか、あるいは大工仕事をしているかどうかは、制御部１０１はその内容までは把握できない。しかし、加速度センサ部１０６からの情報でなんらかの活動を検出した場合に、時計部１０４からの情報に基づいて、一休みすることを促すメッセージを出力することができる。

図１３は、図２のタッチパネル１１４に表示されたアドバイス情報の画面例を示す図である。図１３に示すように、コーヒーを飲むことを勧めるアドバイスを表示しながら、さりげなくコーヒーが好きかどうかの質問を行う。ここで、ユーザがＹＥＳボタン１１４ａ又はＮＯボタン１１４ｂをオン操作すると、広く愛好されている一般的な飲み物であるコーヒーについてのユーザの個人情報を把握することができる。

この後は、さらに、ユーザの嗜好情報についての細かい質問を用意することができる。図１４は、図２のタッチパネル１１４に表示された嗜好情報質問の画面例を示す図である。図１３の画面において、ユーザがＹＥＳボタン１１４ａをオン操作したときは、図１４に示すように、ユーザの詳細な個人情報を知るために、さりげなく詳細情報の入力を促す流れにユーザを誘う。

さらに、この自然な流れの中で、コーヒー、紅茶、酒、タバコなどの嗜好品の種類や頻度といったユーザの嗜好情報に関する質問を表示して、広範で且つ細かい個人情報について取得することができる。

ユーザの嗜好情報を取得して記憶部１０２の不揮発性メモリにストアした後は、例えば、酒を飲まないユーザ又はタバコを吸わないユーザに対してまで、「お酒又はタバコを控えた方がよい」など、ユーザの生活習慣に合致しないメッセージを出力することが避けられる。

図１５は、図２のタッチパネル１１４に表示された生活情報質問の画面例を示す図である。例えば、制御部１０１は、休日にユーザが外出したことを位置検出部１１２からの情報で把握した場合には、この場合もさりげなく、どこに出かけたかという質問を表示する。

同時に、予想できる行先の施設として、公園アイコン１１４ｊその他のメニューアイコンを表示する。例えば、ユーザがその他のメニューアイコン１１４ｋを選択したときは、文字入力のためのキーボード画像１１４ｉを表示する。

さらに、休日であることから、ユーザが文字入力を煩雑であると感じることも考慮して、音声入力部１０９をアクティブして、音声での入力ができる旨の音声入力アイコン１１４ｇを表示することもできる。

したがって、制御部１０１は、ユーザとの間で音声による自然な流れの擬似コミュニケーションを行う中で、ユーザの生活情報に関連する詳細な個人情報を取得することができる。

ユーザから入力される個人情報は、上記した例示以外にも多く存在するので、制御部１０１は、ストアする個人情報の蓄積に応じて、ユーザのパターン情報をより精度を高める必要がある。

なお、ステップＳ１１８で予測した生活習慣情報が、その後にユーザとの疑似コミュニケーションを通じて正しかったと判断される場合には、パターン情報の更新が必要であるとして、ステップＳ１１９へ移行して更新すべきパターン情報をストアし、パターン情報の更新が必要でない場合には、図１６に示す処理を終了する（ステップＳ１２３）。

以上説明したように、本発明の各実施形態における情報提供装置によれば、タッチパネル１１４を構成する操作部１０７若しくは音声入力部１０９又はその双方は、ユーザから取得したい個人情報のうち幾つかを予め受け付ける第１受付手段を構成する。また、タッチパネル１１４を構成する表示部１０８若しくは音声出力部１１０又はその双方は、第１受付手段によって受け付けていない個人情報に対応する属性の質問を行う質問手段を構成する。そして、操作部１０７若しくは音声入力部１０９又はその双方は、質問手段による質問に対する返答である個人情報を受け付ける第２受付手段を構成する。さらに、記憶部１０２の不揮発性メモリは、第１及び第２受付手段によって受け付けられた個人情報と当該個人情報に対応する属性とが紐付けた状態で格納される格納媒体を構成する。

また、本発明の各実施形態における情報提供システムによれば、上記情報提供装置を複数有しており、当該情報提供装置が相互にネットワーク４００を介して接続された場合に、最新の個人情報が格納されている格納媒体の内容で、他方の格納媒体の内容を更新する。

さらに、上記実施形態によれば、ユーザ端末１００は、外部メモリ又はネットワーク４００を介して、健康情報に関するウェブサーバ３００から情報提供プログラムをインストール又はダウンロードすることができる。

すなわち、情報提供プログラムは、
ユーザから取得したい個人情報のうち幾つかを予め受け付けるステップと、
受け付けていない個人情報に対応する属性の質問を行うステップと、
前記質問に対する返答である個人情報を受け付けるステップと、
前記受け付けられた個人情報と当該個人情報に対応する属性とを紐付けた状態で格納するステップと、
を情報提供装置に実行させる。

図１６のフローチャートのステップＳ１１９においてパターン情報がストアされた場合には、制御部１０１は、例えば健康のアドバイスといった各種アドバイスが必要かどうかを判別する（ステップＳ１２０）。例えば、図４のフローチャートのステップＳ１１２において、飲み会の情報を一時的にストアした場合において、例えば、昼休みのニュース等のチェックのタイミングを見計らって、健康のアドバイスをすることができる。

Claims (5)

1. ユーザから取得したい個人情報のうち幾つかを予め受け付ける第１受付手段と、
   前記第１受付手段によって受け付けていない個人情報に対応する属性の質問を行う質問手段と、
   前記質問手段による質問に対する返答である個人情報を受け付ける第２受付手段と、
   前記第１及び第２受付手段によって受け付けられた個人情報と当該個人情報に対応する属性とが紐付けた状態で格納される格納媒体と、
   を備える情報提供装置。
2. 前記格納媒体に格納されている個人情報に基づく情報を提供する提供手段を備える、
   請求項１記載の情報提供装置。
3. 前記提供手段は、ユーザの振る舞いに基づく情報を提供する、
   請求項２記載の情報提供装置。
4. 請求項１記載の情報提供装置を複数有しており、
   当該情報提供装置が相互にネットワークを介して接続された場合に、最新の個人情報が格納されている格納媒体の内容で、他方の格納媒体の内容を更新する、
   情報提供システム。
5. ユーザから取得したい個人情報のうち幾つかを予め受け付けるステップと、
   受け付けていない個人情報に対応する属性の質問を行うステップと、
   前記質問に対する返答である個人情報を受け付けるステップと、
   前記受け付けられた個人情報と当該個人情報に対応する属性とを紐付けた状態で格納するステップと、
   を情報提供装置に実行させる情報提供プログラム。

Images