JP6263135B2 - サーバ装置の動作方法、サーバ装置およびコンピュータプログラム - Google Patents

Description

本発明は、サーバ装置の動作方法、サーバ装置およびコンピュータプログラムに関する。

近年においては、センサデータから人間の行動を推定する技術が多く提案されている。人間の行動を記録するために、人間にセンサデバイスを装着させて記録する方法と、環境にセンサデバイスを設置して記録する方法がある。例えば、人間の腕にセンサを装着して手元での作業を推定する方法（例えば特許文献１）や、カメラの画像から人物の姿勢を推定する方法（例えば特許文献２）などがある。これらの方法においては、事前に学習を行い、正解ラベルとデータと紐付けるものが主流であった。

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

バイタルデータなど個人差の大きいデータや、宅内のデータなど環境差の大きいデータは、汎用的なラベルを予め作成することが難しく、データの意味を理解するためには、個人ごと、環境ごとに、正解のラベルを作成する必要がある。バイタルデータや宅内のデータに関して、ユーザにラベル付けを要求する手法が考えられるが、ユーザは常時ラベリング可能な状況にあるわけではなく、ラベル付けの要求が生じた直後にユーザが要求に回答することは実生活では考え難い。過去に起きたセンサデータの変化に対してユーザにラベル付けを要求する場合、センサデータをそのまま提示してもユーザがそのデータが生じた状況を想起することは難しく、ユーザがその状況を正しく想起できる表現でユーザに問い合わせる必要がある。
本発明は、正解のラベルを得やすい質問文を生成するための技術を提供することを目的とする。

上記課題を解決するために、第１の本発明は、サーバ装置の動作方法であって、前記サーバ装置が、ユーザの周囲におけるセンサの設置場所、当該センサの種別および当該センサから出力されるセンサデータにより検出されるトリガの種別で表現されるイベントを入力するステップと、前記サーバ装置が、前記ユーザに質問を発信するタイミングの契機として予め定められた条件を検出するステップと、前記サーバ装置が、前記契機としての条件が検出されるまでの質問対象区間に入力されたイベントまたはイベントパターンであり且つ予めシステム重要度に対応づけられたイベントまたはイベントパターンと同じものを質問対象候補として検出し、複数の当該各質問対象候補について、該当のシステム重要度を用いて選択のための値を計算し、最大の当該値に対応する質問対象候補を質問対象として選択するステップとを含むことを特徴とする。

例えば、前記サーバ装置は、前記質問対象に予め対応づけられた質問対象文を含む質問文を生成する。

例えば、前記サーバ装置が、前記質問対象と同時もしくは連続して入力されたイベントまたはイベントパターンを検出し、複数の当該各イベントまたはイベントパターンの出現頻度の低さを示す値を計算し、最も低い出現頻度を示す当該値に対応するイベントまたはイベントパターンを選択する。

例えば、前記サーバ装置が、少なくとも１つのイベントまたはイベントパターンにつき、当該１つのイベントまたはイベントパターンに対応する補助情報文を記憶している場合において、前記出現頻度を用いて計算した値により選択したイベントまたはイベントパターンが前記１つのイベントまたはイベントパターンに対応する場合は、当該補助情報文を用いて前記質問文を生成する。

第２の本発明は、サーバ装置であって、ユーザの周囲におけるセンサの設置場所、当該センサの種別および当該センサから出力されるセンサデータにより検出されるトリガの種別で表現されるイベントを入力する手段と、前記ユーザに質問を発信するタイミングの契機として予め定められた条件を検出する手段と、前記契機としての前記条件が検出されるまでの質問対象区間に入力されたイベントまたはイベントパターンであり且つ予めシステム重要度に対応づけられたイベントまたはイベントパターンと同じものを質問対象候補として検出し、複数の当該各質問対象候補について、該当のシステム重要度を用いて選択のための値を計算し、最大の当該値に対応する質問対象候補を質問対象として選択する手段とを備えることを特徴とする

第３の本発明は、第２の本発明に係るサーバ装置としてコンピュータを機能させるためのコンピュータプログラムである。

本発明によれば、正解のラベルを得やすい質問文を生成するための技術を提供することができる。

本発明の実施の形態におけるシステム構成図である。 実施例１のブロック図である。 実施例１のフローチャートである。 トリガー関数の例である。 イベントログの例である。 イベントと自然文の対応テーブルの例である。 ３日間の夜間の照度を例示する図である。 質問対象リストを例である。 イベントセグメントの例である。 質問対象文テーブルの例である。 補助情報文テーブルの例である。 質問文の提示例である。 実施例２の質問対象文テーブルの例である。 実施例３の質問対象文テーブルの例である。 実施例４の質問対象文テーブルの例である。 実施例４のブロック図である。

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

［実施例１］
図１は、本発明の実施の形態におけるシステム構成図である。図２は、実施例１のブロック図である。

本システムは、ユーザ（図示せず）の周囲に配置される複数のセンサ１と、センサ１と通信可能なサーバ装置２と、サーバ装置２と通信可能なユーザ端末３とを備える。
各センサ１は、各種センサデータを取得するセンシング手段１０１と、センサデータをサーバ装置２に送信するセンシング通信手段１０２を備える。

サーバ装置２は、サーバ通信手段２０１と、サーバ通信手段２０１がセンサ１から受信したセンサデータを格納するセンサデータログ格納手段２０２と、受信したセンサデータからトリガー関数により特定のパターン（トリガーという）を検出し、対象のセンサ１の設置箇所、当該センサの種別および当該トリガーの種別で表現されるイベントと呼ばれる一次解析結果を出力するイベント検出手段２０３と、イベントおよび当該イベントに対応するトリガー（変化）の開始時刻と終了時刻を含むイベントログを格納するイベントログ格納手段２０４と、質問対象候補となるイベントを検出する質問対象検出手段２０５と、質問対象候補を一時的に格納する質問対象候補一時格納手段２０６と、質問を発信するタイミングを検出する質問発信タイミング検出手段２０７と、質問を生成する質問生成手段２０８と、生成された質問を一時的に格納する質問/回答格納手段２０９とを備える。

ユーザ端末３は、ユーザ端末通信手段３０１と、サーバ装置２で生成された質問を音声またはテキスト等で提示する提示手段３０２と、ユーザが音声、テキスト、または選択ボタン等で回答を入力する入力手段３０３とを備える。

図３は、実施例１のフローチャートである。
（Ｓ１）
各センサ１は、センサデータを取得してサーバ装置２に送信する。
サーバ装置２は、センサデータを受信し、受信時のタイムスタンプとセンサデータをセンサデータログ格納手段２０２に格納する。

（Ｓ３）
サーバ装置２のイベント検出手段２０３は、受信したセンサデータを所定のトリガー関数に逐次入力して処理を行うことによりイベントを検出し、イベントおよび当該イベントに対応するトリガー（変化）の開始時刻と終了時刻を含むイベントログをイベントログ格納手段２０４に格納する。

図４は、トリガー関数の例である。
実施例１では、変化を検出するトリガー関数として、単調増加を検出するup関数、単調減少を検出するdown関数、ステップ応答的に値が上昇するstepup関数、ステップ応答的に値が下降するstepdown関数、上昇と下降が繰り返されるchange関数、値に変化が生じないkeep関数が定義されており、この関数がセンサデータを常時監視しているとする。

なお、トリガー関数としては、上述の変化以外の変化を検出するトリガー関数を設定してもよい。例えば、異常値検出アルゴリズムをトリガー関数として設定してもよい。そして、コップに設置された加速度センサを監視する場面を考えるとき、コップの加速度で異常値が現れた場合に出力されるイベントを、cup.acc.anomalyとしてもよい。

例えば、コップに加速度センサと温度センサが内蔵されている場合に、コップを持ち上げたりコップで飲み物を飲んだりすると、加速度センサに変化が生じ、change関数がchangeというトリガーを検出する。

この場合、「コップに設置した加速度センサでchangeという変化を検出した」という意味であるcup.acc.changeというイベントを含むイベントログがイベントログ格納手段２０４に格納される。

また、コップに冷たい飲み物や温かい飲み物を注ぐと、down関数やup関数が、downやupというトリガーを検出する。コップに冷たいものが注がれた場合、コップ全体の温度が下がり、「コップに設置した温度センサでdownという変化を検出した」という意味であるcup.temp.downというイベントが検出され、コップに温かいものが注がれた場合、コップ全体の温度が上がり、「コップに設置した温度センサでupという変化を検出した」という意味であるcup.temp.upというイベントが検出される。

なお、センサ設置箇所を示す識別情報（上記例の場合のcup）は、予め決められていてもよいし、ユーザが入力してもよい。また、識別情報の表現の粒度は、上記の例のように具体的な「cup」等でもよいし、抽象度の高い「device1」等としてもよい。

図５は、イベントログの例である。
トリガー関数にてイベントが検出されると、当該イベントおよび当該イベントに対応するトリガー（変化）の開始時刻(start:に続く時刻）と終了時刻(end:に続く時刻）を含むイベントログがイベントログ格納手段２０４に格納される。

図６は、イベントと自然文の対応テーブルの例である。
イベントは、図６のように、意味との対応テーブルを持つ事により、さらに意味的に変換を加えて保存してもよい。例えば、cup.acc.changeと保存するのではなく、「コップを使った」と保存してもよい。

また、上記説明では、センサ１がセンサデータをサーバ装置２に送信し、サーバ装置２がトリガー関数を駆動したが、センサ１がトリガー関数を駆動し、イベントに対応するフラグをサーバ装置２に送信してもよい。

こうすることで、センサデータではなくイベントに対応するフラグのみが送信され、データ送信量が軽減されるので、センサ１のバッテリー消費量が軽減されるという効果がある。

図３に戻る。
（Ｓ５）
質問対象検出手段２０５は、イベントログ格納手段２０４に格納されたイベントログから、質問対象リストに登録されたイベントやイベントのパターン（イベントパターンという。詳しくは後述する。）と同じものが検出された場合、このイベントやイベントパターンを質問対象候補として一時的に質問対象候補一時格納手段２０６に格納し、ステップＳ７に進み、質問対象リストに登録されたイベントやイベントパターンと同じものが検出されないなら、ステップＳ１に戻る。

イベントパターンとは複数のイベントeから構成されるパターン{e1, e2, .. , eN}である。例えば、「照度の値がdata1からdata3に変化して、data3が3回検出されてからdata4に遷移した」というイベントパターンは、{device1.lumi.keep@data1, device1.lumi.keep@data3, device1.lumi.keep@data3, device1.lumi.keep@data3, device1.lumi.keep@data4}というイベント表現で表現される。

なお、サーバ装置２が、その動作中において、イベントやイベントパターンを質問対象リストに登録していってもよい。この場合、当初の質問対象リストにはイベントやイベントパターンがなくてもよい。

実施例１では、予め質問対象リストにイベントやイベントパターンが登録される場合について説明する。ユーザに依存せず、環境に依存するイベントやイベントパターンについては、このように予め質問対象リストに登録するのが好ましい。

例えば、照度計（センサ１）をユーザが宅内のどこかに導入したものとする。また、照度計の他に玄関ドア、冷蔵庫ドア、ソファに加速度センサが設置されており、玄関ドア及び冷蔵庫ドアの開閉及びソファへの着座が検出できるものとする。さらに、テレビに照度センサが設置されており、テレビの電源のONとOFFが検出できるものとする。1LDKの宅内の場合、リビング、ダイニング、キッチンがドアで仕切られることなく空間として続いているため、例えばリビングに照度計を設置した場合であっても、ダイニングやキッチンからの照明の光も照度計に届く。照度計の設置箇所が固定である場合、夜間の日照時間外は宅内の照明のみが光源となる。日照時間外を考えた場合、照明点灯の組み合わせは有限であり、ある組み合わせで照明が点灯している場合、照度計の設置箇所が固定であり照度計を遮る遮蔽物がない限り照度は一定になると考えられるため、照度計で計測される照度は有限のクラスタに分類されると考えられる。照度のクラスタに照明条件のラベルが付与されれば、照度の観測によりどの場所の照明が点灯しているかが推測可能となる。リビング、ダイニング、キッチンといった空間で行われる行動は、例えばそれぞれ「団らん」「食事」「調理」といった行動が代表的である。このため、照明条件のイベントログには生活パターンが反映されるものと考えられる。実施例１では、照度のクラスタに紐づけられる照明条件のラベルをユーザに問う場面を考える。

このような場面の例について、質問対象リストの生成方法を説明する。本処理は前処理として与えるものとし、詳細なフローチャートは省略する。

図７は、３日間の夜間の照度を例示する図である。
ユーザが宅内に照度計を導入してから3日間照度の計測を行い、図７のようになったとする。３日間のデータ計測後、日照時間外の照度を自動的にクラスタリングする。自動クラスタリングの手法は、x-means法など一般的な手法を用いる。

図８は、質問対象リストの例である。
抽出されたクラスタの照度は、図８のような質問対象リストに格納される。ここでは、設置した照度計の名称をdevice1とし、クラスタリングした結果得られた照度をdevice1.lumi.keep@data1のようなイベント表現で表現する。ここで、keep関数はある一定時間一定の照度が計測された場合にkeepというイベントを検出する関数であり、device1.lumi.keep@data1は、「デバイス1の照度がdata1の照度で一定である」ことを検出した場合に生成されるイベントと同じこととする。照度のクラスタリングの結果、4つの照度のイベント表現device1.lumi.keep@data1からdevice1.lumi.keep@data4が得られ、これらと該当の照度が質問対象リストに格納される。

当初、サーバ装置２は、キッチンの照明点灯やリビングの照明点灯等のラベルは得ておらず、質問対象リストは照度を含むがラベルを含まない。
質問対象リストには、そのラベルを問う重要度（システム重要度という）が設定される。

システム重要度は、例えば、０，１，２の3段階とする。システム重要度の算出方法は様々に考えられるが、ここでは以下のようにする。例えば、device1.lumi.data1とdevice1.lumi.data4は、出現頻度が高いため、システム重要度に2が与えられ、device1.lumi.data3は、出現頻度が中程度であるため、システム重要度に1が与えられ、device1.lumi.data2は、出現頻度が低いため、システム重要度に0が与えられるとする。

ユーザにラベルを要求する最も単純な例としては、あるクラスタ（クラスタAという）の照度が現れた場合に、「いまどこの電気がついているの？」とユーザに問い合わせるというものが考えられる。ユーザからの回答が「リビング」であった場合、クラスタAには「リビング」のラベルを付与する。
しかし、照度に変化が生じないうちに回答を得られればよいが、問い合わせたい照度条件の際に、ユーザが常に回答可能な状況であるとは限らない。また、ユーザは無意識のうちに様々な箇所の照明を点灯したり消灯したりして過ごす。このため、「さっきどこの電気がついてたの？」という問いに対して答えるのはユーザにとって想起するのが容易ではなく、ユーザが過去の照明点灯について想起できるように質問を生成する必要がある。

図３に戻る。
（Ｓ７）
質問発信タイミング検出手段２０７は、質問を発信するタイミングを検出したなら、ステップＳ９に進み、検出されないなら、ステップＳ１に戻る。
具体的には、質問発信タイミング検出手段２０７は、イベントログ格納手段２０４に格納されたイベントログから、質問発信タイミングとして定義されたイベントやイベントパターンが検出されたならステップＳ９に進む。
実施例１では、ソファに掛けたことが質問発信タイミングとして定義されているものとする。

（Ｓ９）
質問生成手段２０８は、まず、質問対象候補一時格納手段２０６に格納された質問対象候補群の中から、各種重要度に基づいて、ユーザ及び環境理解に関して重要かつユーザが想起しやすい質問対象となるイベントまたはイベントパターンを選択する。これを質問対象選択という。

質問生成手段２０８は、次に、各種重要度に基づいて、質問対象となる場面を最も想起しやすく説明するように用いられる補足情報を選択する。これを補足情報選択という。
質問生成手段２０８は、最後に、質問対象選択で選択されたイベント等と、補足情報選択で選択された補足情報を組み合わせて、質問文を生成する。

（Ｓ１１）
サーバ通信手段２０１は、次に、質問文をユーザ端末３に送信し、これにて、質問生成の処理が終わる。
ここで、上述の重要度のカテゴリは二種類あり、それは、システムがユーザを理解していくという観点での重要度と、人が想起しやすいという観点での重要度である。ここでは、前者の重要度として、システム重要度、後者の重要度として、ユーザ重要度、セグメント長に基づく重要度、イベント出現頻度に基づく重要度、イベント発生からの経過時間に基づく重要度、質問対象の複雑さに基づく重要度、通常値からの乖離度に基づく重要度、及びデータ強度に基づく重要度を定義している。各種重要度に関して、詳しくは後述する。

実施例１では、システム重要度とセグメント長に基づく重要度の和から、質問対象となる１つまたは連続する複数の同種イベント（イベントセグメントと総称する）を選択し、イベント出現頻度に基づく重要度を用いて、質問対象となるイベントセグメントを想起しやすくなるように補足情報となるイベントセグメントを選択し、質問文を生成する。

図９は、イベントセグメントの例である。
ここで、イベントは連続して検出される場合があり、同種イベントの検出開始から検出終了までを１つのイベントセグメントとする。イベントが連続する場合とは、例えば、図9に示すように連続的に同じ照度data1が観測され、連続的にdevice.lumi.keep@data1が検出されるといった場合を指す。イベントセグメントの最小単位はイベントが1度だけ検出された場合である。イベントの時系列データ（イベントログ）をセグメンテーションすることをイベントのセグメント化と呼ぶものとする。セグメント化では、イベントセグメントが生成される。

実施例１では、点灯している照明のラベルをユーザに問い合わせることを考える。例えば、仕事帰りに食材の買い物をして帰宅し、以下のような一連の流れが生じた場合を考える。帰宅して部屋に入り、キッチンの照明をつける。荷物をキッチンに置き、キッチンにある冷蔵庫に買って来た食材をしまう。キッチンにて調理を行う。調理を済ませたら、ダイニングの照明をつけ、食事の用意を整え、キッチンの照明を消灯して食事をする。食事を済ませてキッチンに一時的に照明をつけて食器を片付け、キッチンとダイニングの照明を消灯して、リビングの照明を点灯し、ソファに掛ける。このとき、質問発信タイミングが検出され、質問生成の処理に移る。この時点で生成されているイベントセグメントは図９の通りである。イベントセグメントのうち、質問対象リストに含まれているものは斜線で表示している。

まず、質問対象選択について述べる。
実施例１の質問対象選択ではシステム重要度とセグメント長に基づく重要度を各イベントセグメントについて算出し、各種重要度の和が最大となるイベントセグメントを質問対象として選択する。
システム重要度は、前述の通り予め設定されているものとする。

セグメント長に基づく重要度は、当該イベントの継続時間が長い方が印象に残りやすく想起しやすいことを反映するパラメータであり、セグメント長が長い程、重要度が高く、セグメント長が短い程、重要度が低くなるように定義する。質問対象候補が検出されてから質問発信タイミングが検出されるまでの間に発生したイベントのセグメント長を算出し、イベントセグメント長を重要度とする。

例えば、図９の例の場合、イベントセグメント１のセグメント長に基づく重要度は９、イベントセグメント５のセグメント長に基づく重要度は５、イベントセグメント３のセグメント長に基づく重要度は２となる。

システム重要度とセグメント長に基づく重要度の和を各イベントセグメントに対して算出し、和が最大となるイベントセグメントを、質問対象として選択する。

実施例１の場合、イベントセグメント１において、device1.lumi.data1のシステム重要度が２、セグメント長に基づく重要度が９、和が１１と最も大きくなるため、イベントセグメント１が質問対象として選択される。

続いて、補足情報選択について述べる。
実施例１では、イベント出現頻度に基づく重要度を用いて、質問対象のイベントセグメントとして選択されたイベントグメント１を最もよく説明する想起しやすい質問文を生成する。イベント出現頻度に基づく重要度は、イベントパターンのうち、質問対象区間Tqにて1度しか生じていないイベントパターンは複数回生じたイベントパターンに比べて想起しやすいことを反映する値である。

例えば、もしも質問対象として選択されたイベントセグメントが質問対象区間Tqにおいて1度しか生じていないイベントである場合には、そのイベントのみを用いて質問すれば良い。例えば、質問対象区間Tqに、点灯を照明するというイベントが1度しか生じていない場合には、「さっきどこの電気つけたの？」と問い合わせればよい。

しかし、実施例１のような場合には、電気の点灯と消灯が複数回生じており、「さっきどこの電気つけたの？」という聞き方はできない。このような場合には、他のイベントセグメントと組み合わせて、質問対象のイベントセグメントを想起しやすい形で表現する必要がある。

実施例１では、想起しやすい形で表現するための補足情報として、玄関のドア、冷蔵庫のドア、ソファ、テレビに取り付けられたセンサを用いるとする。補足情報として用いるイベントセグメントは、質問対象のイベントセグメントと同時に生じている、または前後Ta以内に生じているイベントセグメントを候補とする。Taは予め設定されている閾値とし、実施例１の場合には、Taを5分とする。ここで、図９における１マスはTa（５分）とする。実施例１の場合、質問対象として選択されたイベントセグメントと同時または連続関係にあるのは、イベントセグメント６、７、８であり、これを補足情報イベントセグメントの候補とする。ここで、前述の通り複数のイベントから構成されるイベントパターンにおいて、イベントパターンを構成する2つのイベントセグメントの時系列関係を、イベントAのあとにイベントBが生じた場合を「A→B」、イベントBのあとにイベントAが生じた場合を「B→A」、イベントAと同時にイベントBが生じた場合を「A=B」と記載するものとする。

補足情報としてイベントセグメント６を用いるdoor.acc.change→device1.lumi.keep@data1というイベントパターンが生じる回数は質問対象区間において1回であるのに対して、補足情報としてイベントセグメント7または8を用いるdevice1.lumi.keep@data1=fridege.acc.changeというイベントパターンは質問対象区間において2回生じている。イベントパターンの出現回数が1に近いほど、補足情報として選択される。

質問対象選択と補足情報選択を、関数として表現すると、以下のようになる。
まず、質問対象選択であるが、セグメント番号をi、システム重要度をI_system (i)、セグメント長に基づく重要度をI_length(i)とするとき、以下を満たすiを求め、i番目のセグメントを質問対象として選択する（質問対象選択関数）。なお、argmax()は、()内の値が最大となった場合の変数（この場合はｉ）を示すものである。
argmax(I_system (i)+I_length(i)) （１）

また、補足情報選択であるが、セグメント番号をi、イベント出現頻度に基づく重要度をI_frequency(i)とし、イベント出現回数cntの負の値を代入するものとする。例えば、イベントパターンの出現回数が2回であるセグメントのI_frequency(i)は−２であり、イベントパターンの出現回数が1回であるセグメントのI_frequency(i)は−１となる。このときの以下を満たすiを求め、i番目のセグメントを補足情報として選択する（補足情報選択関数）。
argmax(I_frequency(i)) （２）

このとき、質問対象選択関数と補足情報選択関数は、単純な線形和ではなく、例えば、システム重要度の影響を大きくする等、重み付けを設定して和を取ってもよいし、非線形和としてもよい。また、用いる重要度は、システム重要度、セグメント長に基づく重要度、及びイベント出現頻度に基づく重要度だけでなく、ユーザ重要度、イベント発生からの経過時間に基づく重要度、質問対象の複雑さに基づく重要度、通常値からの乖離度に基づく重要度、及びデータ強度に基づく重要度のうちいずれかを用いてもよい。また、各種重要度は、各関数の双方に入ってもよい。

このように質問対象選択と補足情報選択が行われたあと、質問文が生成される。質問文の生成は、質問対象文と補助文を合成することにより行う。

なお、図９の説明では、質問対象選択で２以上の連続する同種のイベントからなるイベントセグメント１（イベントパターンの１種）を選択したが、１つのイベントを選択してもよいし、イベントセグメント以外のイベントパターンを選択してもよい。
また、補足情報選択では、１つのイベントからなるイベントセグメント６、７、８を選択したが、イベントセグメント以外のイベントパターンを選択してもよい。

図１０は、質問対象文テーブルの例である。
質問対象文テーブルは、例えば、予め質問生成手段２０８に保持される。
質問対象文テーブルには、前処理で抽出された質問対象候補のイベントやイベントパターンのイベント表現が登録される。各イベント表現には、質問対象文が関連づけられている。質問対象選択にて、例えば、ある１つのイベントが選択された場合、そのイベント表現に関連づけられている質問対象文が質問文の合成に用られる。

図１１は、補助情報文テーブルの例である。
補助情報文テーブルは、例えば、予め質問生成手段２０８に保持される。
補助情報文テーブルには、検出しうるイベントが予め登録されており、各イベントに、これが補足情報選択で選択された場合に用いられる補助情報文が関連づけられている。なお、補助情報文テーブルにおいては、イベントパターンについて補助情報文を登録してもよい。

図１１においてＡは質問対象となるイベントまたはイベントパターンを指し、Bは補助情報となるイベントを指す。AとBの時系列関係に基づく接続詞が選択され、補助情報となるイベントを表す主語と合成した補助情報文を質問文の合成に用いる。

例えば、質問対象であるイベントパターンＡとして、{device1.lumi.stepup,device1.lumi.keep@data1}が選択されたとする。この場合、質問対象文として「どこの電気つけたの」が選択される。イベントパターンＡを想起しやすく補足する補助情報であるイベントＢとして、door.acc.changeが選択されたとする。このとき、AとBの時系列関係はB→Aであるので、補助情報文として「玄関のドア開けたあと」が選択される。こうして選択された補助情報文と質問対象文を合成して、「さっき玄関のドア開けたあと、どこの電気つけたの」という質問文が生成される。

なお、想起しやすい形で表現するための補足情報は、センサ１のログやユーザ端末３の操作ログでもよく、ウェブ上での操作ログを用いてもよい。また、イベントセグメントの組み合わせで構成されるイベントパターンは、３つ以上のイベントセグメントから構成されるものとしてもよい。

図３に戻る。
（Ｓ２１）
ユーザ端末３のユーザ端末通信手段３０１は、質問文を受信し、提示手段３０２は、受信された質問文をユーザに提示する。

図１２は、質問文の提示例である。
提示手段３０２は、受信された質問文を図１２に示すように提示する。
提示方法はテキストを表示するのでもよいし、グラフィック表現を用いてもよいし、音声出力を用いてもよい。ユーザ端末３がロボットのようにモータ制御も可能である場合、動きと合わせて表示してもよい。他の提示手段を用いてもよい。
（Ｓ２３）
ユーザ端末３の入力手段３０３にユーザからの回答を入力する。

（Ｓ２５）
ユーザ端末通信手段３０１は、入力された回答をサーバ装置２に送信し、回答送信が終了する。サーバ装置２は、回答を受信し、質問/回答格納手段２０９に格納する。すなわち、回答をラベルとして、質問対象として選択したイベントやイベントパターンに対応づけることができる。

なお、回答格納状況に応じて，システム重要度を変更してもよい。すなわち、device1.lumi.keep@data1というイベントに関するユーザからのラベルが十分に収集され、ラベルの確度が高まった場合には、当該イベントに関するシステム重要度を2から0に変更してもよい。

以上のように質問文を生成することにより、システムはユーザにとっての想起の手がかりと合わせて質問を投げかけることになるため、ユーザは回答を想起しやすくなるという効果が生じるものと考えられる。また、実世界でのコンテキストをシステムが検知するとユーザが認知するので、システムに対する親近感が増す効果も期待される。

なお、実施例１では、ユーザに質問を発信するタイミングの条件として、予め定められたイベントやイベントパターンを検出したが、条件は、イベントやイベントパターンに限らない。すなわち、ユーザに質問を発信するタイミングとして予め定められた条件が充足されればよい。以下の実施例でも同様である。

［実施例２］
実施例２では、実施例１と同様に、質問対象リストが予め作成される。実施例１ではユーザ環境に導入されてから質問対象リストが作成されたのに対し、実施例２では、ユーザ環境に導入された時点で質問対象リストが既に用意されている。
システム構成図、ブロック図、フローチャートは実施例１と同様である。
実施例２では、ユーザの嗜好やパーソナリティを対話の中で集めていくような状況を考える。

図１３は、実施例２の質問対象文テーブルの例である。
質問対象文テーブルには、例えば、ユーザの嗜好やパーソナリティのラベルを問い合わせるのに適した質問対象文が登録される。

ユーザとシステムの音声対話を通じてユーザの嗜好やパーソナリティを収集及び蓄積していくことにより、ユーザついてより詳細にシステムが把握していくような効果があると考えられる。また、単に嗜好やパーソナリティを対話システムにて唐突に尋ねるのではなく、実世界での出来事を起点として尋ねることにより、システムに対する親近感が増加する効果もあると考えられる。嗜好についてシステムから尋ねる具体的な内容としては、例えば、飲み物や食事に関する嗜好や、休憩時間の過ごし方の嗜好等が挙げられる。こうした嗜好に関する質問とセンサデータが予め対応付けられているものとする。

この場合、生成される質問の種別として、センサ設置箇所.物理量.トリガー関数で表現されるイベントから類推される動詞の目的語を尋ねる質問、センサが設置されておらず動詞そのものが不明である場合に動詞を尋ねる質問、または漠然とした内容を尋ねる質問が考えられる。具体的には、目的語を尋ねる質問としては、「コップに設置した温度センサでupという変化を検出した」という意味であるcup.temp.upというイベントが検出された場合に、温かいものがコップに注がれた事は推定できるが、コップの温度以外のデータがない場合、何が注がれたかまでは推定することができない。このような場合に、「さっき温かい飲み物飲んでいたね。何飲んでたの？」と尋ねる等、cup.temp.upから類推される「飲む」という行動の目的語を尋ねる質問が考えられる。また、「ソファに設置した加速度センサでchangeという変化を検出した」という意味であるsofa.acc.changeというイベントが検出された際、ソファに座ったことは検出できたがそれ以外のデータが検出されない場合、ソファで何をして過ごしていたのか不明となる。このような際に動詞を尋ねる質問として、「さっきソファで何してたの？」と尋ねる質問が考えられる。また、漠然とした内容を尋ねる質問としては、「ドアに設置された加速度センサでchangeという変化を検出した」という意味であるdoor.acc.changeというイベントが検出された際、どこかへ出掛けたことは検出できるが、その出掛けた内容がどうであったかという感想は抽出できない。このような際に例えば感想や印象を尋ねる質問として、「さっき出掛けたみたいだけど、どうだった？」と尋ねる質問が考えられる。こうした質問に対する回答を収集していくことにより、ユーザプロファイル情報を蓄積していくことが可能となる。

詳細なフローとしては、常時センサデータを取得し、イベントに変換する部分（Ｓ１、Ｓ３）は、実施例１と同様である。また、質問対象候補検出/格納処理において、質問対象となるイベント、またはイベントパターンが生じていないか常時監視する部分（Ｓ５）も実施例１と同様である。

実施例２では、質問対象選択のパラメータとして、システム重要度、セグメント長に基づく重要度、イベント発生からの経過時間に基づく重要度、質問対象の複雑さに基づく重要度を用いて、質問対象候補の中から質問対象を選択する。

システム重要度の定義は、第１の実施例と同じく、システムにとってそのラベルを問う重要度が質問対象リストと対応して設定されるものとし、０，１，２の3段階とする。システム重要度の設定方法は様々に考えられるが、実施例２の場合、未だ1度も問い合わせていない質問を2とし、1度は問い合わせた質問は1とし、閾値回数だけ該当するイベントに関する回答が得られた質問は0と定義する。システム重要度の値の設定方法はこれ以外の形式でもよく、該当する質問対象が検出されたら2回に1回、システム重要度を上げるように設計してもよいし、質問対象が検出されるたびにランダムにシステム重要度を変更してもよい。
セグメント長に基づく重要度は、実施例１と同様とする。

イベント発生からの経過時間に基づく重要度は、人の記憶の強度がイベント発生からの経過時間に応じて減衰することを反映したパラメータで、イベントが発生してから経過した時間が該当するイベントの想起しやすさに対して負の影響を与えるように定義する。ここでは、n分経過したイベントは、−０．１×ｎとして質問対象選択関数に寄与するものとする。

質問対象の複雑さに基づく重要度は、質問対象となる目的語や動詞の複雑さに応じて、想起しやすさが異なることを反映したパラメータである。例えば、「飲む」「掃除する」といった無意識でも取れるような行動を表す動詞の目的語を質問対象とする質問と比較し、「書く」「調べる」といったより高度な知的作業を含む動詞の目的語を質問対象とする質問の方が、回答内容が複雑であり、回答を想起しにくいことを反映させる。複雑さの度合いが高く想起しにくい質問対象は0, 中程度のものは1、複雑さの度合いが低く想起しやすい質問対象は2と、予め定義しておくものとする。

以上を質問対象選択関数としてまとめると以下のようになる。
argmax(I_system(i)+I_length(i)+I_lapse(i)+I_complexity(i)) （３）
ここでは、システム重要度をI_system(i)、セグメント長に基づく重要度をI_length(i)、イベント発生からの経過時間に基づく重要度をI_lapse(i)、質問対象の複雑さに基づく重要度をI_complexity(i)とする。

上記質問対象選択関数にて質問対象候補から、質問対象を選択した後、実施例１と同様にイベント出現頻度に基づく重要度を算出して補足情報を選択し、質問文を合成し、ユーザ端末３に質問文を表示して回答を得る。
補足情報選択後の処理は実施例１と同様である。

ここで、質問対象選択と補足情報選択で用いるパラメータは、実施例２で用いているパラメータの一部を用いるものとしてもよいし、入れ替えてもよい。実施例２で用いていないパラメータを追加してもよい。

［実施例３］
実施例３は、バイタルデータに対するラベルに関する実施例である。
バイタルデータは個人差が大きく、ラベリングの対象とするデータを個人ごとに決める必要がある。
実施例３では、実施例１と同様に、質問対象リストが予め作成される。また、実施例１と同様に、ユーザ環境に導入されてから質問対象リストが作成される。

図１４は、実施例３の質問対象文テーブルの例である。
質問対象文テーブルには、例えば、バイタルデータに対するラベルを問い合わせるのに適した質問対象文テーブルが登録される。
システム構成図、ブロック図、フローチャートは実施例１と同様である。
システムを導入してから定められた期間をキャリブレーション期間とし、キャリブレーション期間で得られたデータに対して分類器を作成する。入力されるバイタルデータは、心電、脈派、脈拍、呼吸量、筋電、皮膚電位、眼電位、脳波等が考えられる。分類器とは、入力されたバイタルデータから疲労、ストレス、感情等の度合いを分類するものであるとする。分類器で分類されたデータの挙動が質問対象リストとして作成される。以上は前処理としてフローチャートには記載しない。

前処理で作成された分類器で分類した結果に正解ラベルを付与するために、質問生成を行う。
詳細なフローとしては、常時センサデータを取得し、イベントに変換する部分（Ｓ１、Ｓ３）は、実施例１と同様である。また、質問対象候補検出/格納処理において、質問対象となるイベント、またはイベントパターンが生じていないか常時監視する部分（Ｓ５）も実施例１と同様である。

実施例３では、質問対象選択のパラメータとして、システム重要度、セグメント長に基づく重要度、イベント発生からの経過時間に基づく重要度、通常値からの乖離度に基づく重要度、及びデータ強度に基づく重要度を用いて、質問対象候補の中から質問対象を選択する。

ここで、データ強度に基づく重要度とは、強度が強いセンサデータほど重要度を高く設定するパラメータとする。例えば、指定区間のデータ平均を決められた窓幅で算出する場合に、キャリブレーション期間で得られたデータの平均から大きく逸脱する場合を１とし、平均的な挙動である場合には0とする。この２つを分類する閾値はキャリブレーション期間に得られたデータから決定するものとする。

また、通常値からの乖離度に基づく重要度とは、出現頻度が少ないセンサデータの波形ほど重要度を高く設定するパラメータとする。一般的な異常値検出アルゴリズムを用いてバイタルデータに対して異常値検出を行い、検出された場合に１とし、検出されない場合には０を出力するものとする。

なお、異常値検出アルゴリズムとしては、特定パターンを異常値として検出するものや、珍しいパターンを異常値として検出するもの等が挙げられるが、データ強度を用いる異常値検出アルゴリズムを通常値からの乖離度に基づく重要度に用いた場合は、前記データ強度に基づく重要度は等価となる。

以上を質問対象選択関数としてまとめると以下のようになる。
argmax(I_system(i)+I_length(i)+I_lapse(i)＋I_anomaly(i)+ I_intensity(i)) （４）
ここでは、システム重要度をI_system(i)、セグメント長に基づく重要度をI_length(i)、イベント発生からの経過時間に基づく重要度をI_lapse(i)、通常値からの乖離度に基づく重要度をI_anomaly(i)、データ強度に基づく重要度をI_intensity(i)とする。

上記質問対象選択関数にて質問対象候補から、質問対象を選択した後、実施例１と同様にイベント出現頻度に基づく重要度を算出して補足情報を選択し、質問文を合成し、ユーザ端末に質問文を表示して回答を得る。

補足情報選択後の処理は実施例１と同様で、例えば、疲労度が非常に強く検出された場合に、強い疲労を検出した後コップにおいてcup.acc.changeとcup.temp.upが1度だけ検出されていたためにこれを補足情報として選択したとし、「さっき何か温かいものを飲む前にすごく疲れてた？」という質問文を生成する。

なお、質問対象選択と補足情報選択で用いるパラメータは、実施例３で用いているパラメータの一部を用いるものとしてもよいし、入れ替えてもよい。実施例３で用いていないパラメータを追加してもよい。

［実施例４］
実施例４は、車椅子の走行に対するラベルに関する実施例である。
実施例４では、実施例１と同様に、質問対象リストが予め作成される。また、実施例２と同様に、ユーザ環境に導入された時点で質問対象リストが既に用意されているものとする。

図１５は、実施例４の質問対象文テーブルの例である。
質問対象文テーブルには、例えば、車椅子の走行に対するラベルを問い合わせるのに適した質問対象文が登録される。

図１６は、実施例４のブロック図である。
サーバ装置２は、特にユーザに問い合わせたい質問対象となる特定のイベントをユーザに印象づけるべく、当該イベントが生じた際に、メッセージをユーザ端末３に出力するイベントインデックス手段２１０を更に備える。イベントインデックス手段２１０を起動させるイベントは予め質問対象リストの中で定義されているものとする。

メッセージを出力するイベントの検出はイベントインデックス手段２１０で行い、メッセージの出力はユーザ端末３で行うものとする。メッセージの形態は音声出力でもテキスト出力でもよいし、その他の出力の形態でもよい。例えば、質問対象リストに急停止のイベントが定義してある場合、急停止が生じた際、当該イベントを検出した直後にユーザ端末３からから「うわ！」というメッセージを出力する。このように特定のイベントに対してメッセージを出力することにより、メッセージが出力されたイベントに関してはユーザにとって印象づけられ、記憶が強化されて想起しやすくする効果があると考えられる。ここで、出力するメッセージは、予めイベントに対応づけておくのでもよいし、イベントに関わる信号の強度に応じてメッセージ内容を動的に変更するようにしてもよい。

例えば、前進、後進、右折、左折、右旋回（右Uターン）、左旋回（左Uターン）、停止、急停止、迂回といった操作を判定するトリガー関数が予め設定されており、これらに対するイベントである、wheelchair.innertial.forward、wheelchair.innertial.backward、wheelchair.innertial.turn-right、wheelchair.innertial.turn-left、wheelchair.innertial.u-turn-right、wheelchair.innertial.u-turn-left、wheelchair.innertial.normal-stop、wheelchair.innertial.sudden-stop、wheelchair.innertial.detourが出力されるものとする。

ここで、innertialとは慣性センサを指しており、これらの操作を慣性センサである加速度センサとジャイロセンサで判定するものとする。各操作判定のうち、特に街中のバリアに関するものであると考えられる、左右のUターン及び迂回、危険に関するものであると考えられる急停止のイベントについて、Uターン、迂回、及び急停止をした理由を問うような場面を考える。ユーザとシステムの音声対話を通じてバリアや危険に関するラベルを収集及び蓄積していくことにより、車いすユーザ目線の意見を反映したバリアフリーに関する地図を作成可能になると考えられる。バリアや危険に関する質問とイベントが予め対応付けられているものとする。

この場合、生成される質問の種別として、センサ設置箇所、物理量、トリガー関数で表現されるイベントが生じた理由を尋ねる質問が考えられる。具体的には、理由を尋ねる質問としては、「車いすに設置した慣性センサで急停止を検出した」という意味であるwheelchair.innertial.sudden-stopというイベントが検出された場合に、急停止したことは推定できるが、急停止した理由までは推定することができない。このような場合に、「さっき急停止したね。どうしたの？」と尋ねる等、wheelchair.innertial.sudden-stopから判定される「急停止」という行動の理由を尋ねる質問が考えられる。こうした質問に対する回答を収集していくことにより、車いすユーザ目線のバリアや危険に関する情報を蓄積していくことが可能となる。

詳細なフローとしては、常時センサデータを取得し、イベントに変換する部分（Ｓ１、Ｓ３）は、実施例１と同様である。また、質問対象候補検出/格納処理において、質問対象となるイベント、またはイベントパターンが生じていないか常時監視する部分（Ｓ５）も実施例１と同様である。

予めイベントインデックス手段２１０が発動するように設定されたイベントが生じた際には、予め設定されたメッセージが出力される。

実施例４では、質問対象選択のパラメータとして、システム重要度、ユーザ重要度、セグメント長に基づく重要度、イベント発生からの経過時間に基づく重要度、通常値からの乖離度に基づく重要度、データ強度に基づく重要度、及びイベントインデックスに基づく重要度を用い、質問対象候補の中から質問対象を選択する。

ここで、ユーザ重要度とは、ユーザの観点から見た重要度であり、予めイベントと併せて定義されているものとする。例えば慣性センサだけでなく本実施例のシステムがGPSを有する場合、位置情報に関して、場所Aはユーザにとって意味の強い場所で、場所Bはユーザにとって意味の弱い場所であるというユーザ重要度が定義されているものとする。この場合、場所Aに滞在するとユーザ重要度として1を返し、場所Bに滞在するとユーザ重要度として0を返す。場所Aに関する出来事について尋ねた方が、場所Bに関する出来事について尋ねるよりも、ユーザにとって意味があるので、ユーザが想起しやすいという効果があると考えられる。

また、イベントインデックスに基づく重要度とは、システムからのメッセージ出力の効果を反映したパラメータであり、本実施例の場合、システムから音声メッセージが出力されたイベントに関しては1、そうでないイベントに関しては0が与えられるものとする。

以上を質問対象選択関数としてまとめると以下のようになる。
argmax(I_system(i)+I_user(i)+I_length(i)+I_lapse(i)＋I_anomaly(i)+ I_intensity(i)+ I_index(i)) （5）
ここでは、システム重要度をI_system(i)、ユーザ重要度をI_user(i)、セグメント長に基づく重要度をI_length(i)、イベント発生からの経過時間に基づく重要度をI_lapse(i)、通常値からの乖離度に基づく重要度をI_anomaly(i)、データ強度に基づく重要度をI_intensity(i)、イベントインデックスに基づく重要度をI_index(i)とする。

上記質問対象選択関数にて質問対象候補から、質問対象を選択した後、実施例１と同様にイベント出現頻度に基づく重要度を算出して補足情報を選択し、質問文を合成し、ユーザ端末に質問文を表示して回答を得る。
補足情報選択後の処理は実施例１と同様である。

なお、質問対象選択と補足情報選択で用いるパラメータは、実施例４で用いているパラメータの一部を用いるものとしてもよいし、入れ替えてもよい。実施例４で用いていないパラメータを追加してもよい。

その他、重要度の段階数や関数の構成等について、この発明の要旨を逸脱しない範囲で種々変形して実施可能である。例えば、重要度の段階数は３段階でなくともよいし、離散的ではなく連続的値を取ってもよい。また、各実施例において、質問対象選択関数と補足情報選択関数は各パラメータが線形に影響するように設計しているが、非線形の要素を加えてもよいし、重みを与えてもよい。

また、サーバ装置２としてコンピュータを機能させるためのコンピュータプログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録でき、また、インターネットなどの通信網を介して伝送させて、広く流通させることができる。

１ センサ
２ サーバ装置
３ ユーザ端末
１０１ センシング手段
１０２ センシング通信手段
２０１ サーバ通信手段
２０２ センサデータログ格納手段
２０３ イベント検出手段
２０４ イベントログ格納手段
２０５ 質問対象検出手段
２０６ 質問対象候補一時格納手段
２０７ 質問発信タイミング検出手段
２０８ 質問生成手段
２０９ 質問/回答格納手段
２１０ イベントインデックス手段
３０１ ユーザ端末通信手段
３０２ 提示手段
３０３ 入力手段

Claims (6)

1. サーバ装置の動作方法であって、
   前記サーバ装置が、ユーザの周囲におけるセンサの設置場所、当該センサの種別および当該センサから出力されるセンサデータにより検出されるトリガの種別で表現されるイベントを入力するステップと、
   前記サーバ装置が、前記ユーザに質問を発信するタイミングの契機として予め定められた条件を検出するステップと、
   前記サーバ装置が、前記契機としての条件が検出されるまでの質問対象区間に入力されたイベントまたはイベントパターンであり且つ予めシステム重要度に対応づけられたイベントまたはイベントパターンと同じものを質問対象候補として検出し、複数の当該各質問対象候補について、該当のシステム重要度を用いて選択のための値を計算し、最大の当該値に対応する質問対象候補を質問対象として選択するステップと
   を含むことを特徴とするサーバ装置の動作方法。
2. 前記サーバ装置が、前記質問対象に予め対応づけられた質問対象文を含む質問文を生成する
   ことを特徴とする請求項１記載のサーバ装置の動作方法。
3. 前記サーバ装置が、前記質問対象と同時もしくは連続して入力されたイベントまたはイベントパターンを検出し、複数の当該各イベントまたはイベントパターンの出現頻度の低さを示す値を計算し、最も低い出現頻度を示す当該値に対応するイベントまたはイベントパターンを選択する
   ことを特徴とする請求項１または２記載のサーバ装置の動作方法。
4. 前記サーバ装置が、少なくとも１つのイベントまたはイベントパターンにつき、当該１つのイベントまたはイベントパターンに対応する補助情報文を記憶している場合において、前記出現頻度を用いて計算した値により選択したイベントまたはイベントパターンが前記１つのイベントまたはイベントパターンに対応する場合は、当該補助情報文を用いて前記質問文を生成する
   ことを特徴とする請求項３記載のサーバ装置の動作方法。
5. サーバ装置であって、
   ユーザの周囲におけるセンサの設置場所、当該センサの種別および当該センサから出力されるセンサデータにより検出されるトリガの種別で表現されるイベントを入力する手段と、
   前記ユーザに質問を発信するタイミングの契機として予め定められた条件を検出する手段と、
   前記契機としての前記条件が検出されるまでの質問対象区間に入力されたイベントまたはイベントパターンであり且つ予めシステム重要度に対応づけられたイベントまたはイベントパターンと同じものを質問対象候補として検出し、複数の当該各質問対象候補について、該当のシステム重要度を用いて選択のための値を計算し、最大の当該値に対応する質問対象候補を質問対象として選択する手段と
   を備えることを特徴とするサーバ装置。
6. 請求項５記載のサーバ装置としてコンピュータを機能させるためのコンピュータプログラム。
   

Images