【解決手段】情報処理装置は、種々のセンサから得られる各々のイベントの内容を、入力同期併合処理部、条件判断処理部、学習データ処理部、を通じて、ADL識別処理部に引き渡す。ADL識別処理部は、受信したイベントを、人の状態、物の状態、場所の状態、時間の状態が、ツリー構造で記述されていることによってADLを定義するOWL定義ファイルを参照して、観察対象者のADLを判定する。
前記オントロジー推論処理部は、ADLとFIMを定義するOWL定義ファイルを参照して、前記観察対象者のADLとFIMを判定する、ADL・FIMオントロジー解析処理部を有し、
前記ADL・FIMオントロジー解析処理部は、前記セマンティックコンテキストデータ群の特定の条件において、ダミーの任意コンテキストを挿入した上で、判定処理を遂行する、
請求項2に記載の情報処理装置。
前記セマンティックコンテキストデータ群は、少なくとも意味的役割として、動作主、対象、道具、共役者、場所、空間的始点、空間的終点、時間的始点、時間的終点、補助、姿勢、移動距離を有する、
請求項3に記載の情報処理装置。
前記ADL識別処理部は、前記入力同期併合処理部と、前記条件判断処理部と、前記学習データ処理部から出力されるイベントを、人の状態、物の状態、場所の状態、時間の状態が、ツリー構造で記述されていることによってADLを定義するOWL定義ファイルを参照して、前記観察対象者のADLを判定する、
請求項5に記載の情報処理装置。
前記入力同期併合処理部と、前記条件判断処理部と、前記学習データ処理部は、定義ファイルに記述されたディレクティブに従い、イベントの処理に際し、前記入力同期併合処理部と、前記条件判断処理部と、前記学習データ処理部をそれぞれ複数個配置することが可能であることを特徴とする、請求項6に記載の情報処理装置。
【発明を実施するための形態】
【0013】
ADLは、その内容によって幾つかの段階に分けられる。
最も下位に位置するADLは、Basic ADLとも呼ばれる、基本的日常生活行動である。すなわち、食事、着替え、洗面、トイレ、移動、移乗等の、物理的な特徴を有するADLである。これらのADLは、観察対象者の生活自立度(介護度)の判定に利用される。
次に上位に位置するADLは、IADL(Instrumental ADL)と呼ばれる、手段的日常生活行動である。買い物、料理、掃除、金銭管理、乗り物を使った移動等の精神的な特徴を有するADLであり、前述のBasic ADLよりも複雑な手順で構成される。これらADLは、観察対象者の社会的活動判定に利用される。
最後に、最上位に位置するADLは、職務に係るIADL、すなわち職務分野別IADLである。例えば、オフィス内IADLでは、電子メールの送受信、職務における会議、書類作成、電話、インターネットwebサイト検索等、オフィスワークに必要なスキルであり、前述のIADLよりも更に高度な処理手順と処理内容を有するADLである。
【0014】
上述の様々なADLには、動作または作業の開始、動作または作業の経過、動作または作業の終了と、最低でも3個の動作または作業の連鎖によって構成される。更に、これら動作または作業には時間経過が存在する。ADLによっては、動作または作業の経過によっては複数の動作または作業が存在し得る。
このような複雑な動作または作業の、時間軸を跨いだ組み合わせの全ての認識を、学習型情報処理装置に負担させることは困難である。
【0015】
本発明は、発明者らが出願した特願2018−53454に開示した技術の応用である。
発明者らは、センサと学習型情報処理装置として、観察対象者の基本的な状態のみを認識する用途にのみ用い、ADLの認識にはルールベースの仕組みを採用することとした。また、発明者らは、ADLを認識するルールベースのシステムとして、ウェブオントロジー言語OWL(Web Ontology Language)の機能を利用することとした。
【0016】
[第一の実施形態:情報処理装置101:全体構成]
図1は、本発明の第一の実施形態に係る情報処理装置101の全体構成を示すブロック図である。
情報処理装置101は、例えば、観察対象者である独居高齢者や老人施設における高齢者が適切に生活を営んでいるのかを1日観察する。そして、情報処理装置101は観察対象者を1日観察した結果、どのようなADLを遂行したのか、当該ADLの達成度等を記したレポートデータを作成する。このレポートデータは、観察対象者の要介護度認定等に利用される。
従来、このような作業は医療従事者が行っていたが、本発明に係る情報処理装置101を採用することで、極めて客観的なレポートデータを作成できると共に、医療従事者の人手不足解消に大きく貢献できる。
【0017】
情報処理装置101には、顔認識カメラ102、赤外線センサや非接触温度センサ等の種々のセンサ103a、103b…が接続されている。情報処理装置101はこれらセンサから、観察対象者を計測した結果得られる情報(時系列データ)を受信する。そして、観察対象者の照合結果に応じて、観察対象者のADLを判断、あるいは推定する。
【0018】
情報処理装置101が観察対象者のADLを推定する際には、情報処理装置101は、学習アルゴリズムに基づく推定処理を、ネットワークを通じて外部の学習型情報処理装置104に依頼し、外部の学習型情報処理装置104から推定結果を受信する。また、情報処理装置101は、必要に応じて操作部105の操作に従い、液晶ディスプレイ等の表示部106に所定の情報を表示する等の処理を行う。
なお、学習型情報処理装置104のソフトウェア機能を情報処理装置101に内包させてもよい。
【0019】
[第一の実施形態:情報処理装置101:ハードウェア構成]
図2は、情報処理装置101のハードウェア構成を示すブロック図である。
情報処理装置101は、バス201に接続された、CPU202、ROM203、RAM204、操作部105、表示部106、不揮発性ストレージ205を備える。
バス201には更に、現在日時情報を出力するリアルタイムクロック(RTC)206、ネットワークインターフェース(NIC)207、シリアルインターフェース(シリアルI/F)208及びA/D変換器209が接続されており、シリアルI/F208を通じて顔認識カメラ102、センサ103a、103b等が接続されている。また、A/D変換器209を通じてマイク107が接続されている。
【0020】
情報処理装置101としては、英国ラズベリーパイ財団(http://www.raspberrypi.org/)が開発する「Raspberry Pi」等を始めとする、近年普及している安価なシングルボードコンピュータが利用可能である他、パソコン等も利用可能である。
学習型情報処理装置104は、十分な演算能力を有するパソコン等が利用可能である。但し、学習型情報処理装置104において実行される学習アルゴリズムが要求する演算量が少ない場合は、学習型情報処理装置104の持つ機能を情報処理装置101に内蔵させてもよい。
【0021】
[第一の実施形態:情報処理装置101:ソフトウェア機能]
図3は、情報処理装置101のソフトウェア機能を示すブロック図である。
入出力制御部301には、顔認識カメラ102、赤外線センサや非接触温度センサ等の種々のセンサ103a、103b…が接続されている。また、A/D変換器209を通じて観察対象者の音声を認識するためのマイク107も接続されている。
顔認識カメラ102や種々のセンサは、情報処理装置101におけるマルチモーダルセンサ(multimodal sensor)として扱われる。すなわち、顔認識カメラ102や種々のセンサは、観察対象者や観察対象とする事象を、映像、音声、温度、加速度等、様々な物理量等で計測するセンサ群としてみなされる。
【0022】
情報処理装置101の主たる機能は、入出力制御部301に集約されている。この入出力制御部301は、サンプリングクロック毎、あるいは所定の時間間隔毎にセンサから得られる情報に、オブジェクト指向の思想に基づいて種々の情報を付加する。種々の情報が付加された情報はイベントと呼ばれる。入出力制御部301の大部分の機能は、オープンソースのデータ収集ソフトウェアであるFluentd( https://www.fluentd.org/ )に、後述する情報処理機能をプラグインとして追加することで実現される。
【0023】
センサから得られる情報をイベントに格納する際のルールは、センサの種類によって異なる。
例えば温度や湿度、加速度等の一般的な物理現象を計測するセンサの場合は、A/D変換器209のサンプリングクロック毎にデータが取得される。
一方、例えばマイク107等から得られる音声データのように、ある程度連続した時間間隔のデータが必要になる場合は、A/D変換器209のサンプリングクロック毎にデータを取得しても、どのような音が鳴動しているのかわからない。したがってマイク107の場合には、無音検出等の周知の技術を用いて、会話等の推定が可能な程度の長さの音声データを取得することが好ましい。
【0024】
入出力制御部301の機能として備わっている入出力整形処理部302は、各種センサから得られる情報を、統一されたデータフォーマットに従うプレインテキストで記述されたイベントに変換する。また入出力整形処理部302は、必要に応じて、イベントから内容を取り出して、表示部106に表示する内容等に変換する。この統一されたデータフォーマットは、基本的には一定のルールさえ満たされていれば何でもよいのであるが、データの可搬性という観点から、JSON(JavaScript Object Notation(「JAVASCRIPT」は登録商標))が望ましい。
【0025】
以下に、JSONフォーマットにて記述されたイベントの一例を示す。
【0026】
2017-11-03 19:35:32.000000000 +0900 sensor.microwave:
{"heart":79, "breath":12}
【0027】
イベントは、「time tag:record」という記述順で記載される。「time」はPOSIX timeフォーマットの絶対日時情報、「record」はJSON形式であるので、始め波括弧("{")で始まり、終わり波括弧("}")で終わる。
「tag」はJSON形式オブジェクトに与えられる名前(以下「タグ名」)であり、オブジェクト指向の慣例に倣い、「name1.name2.name3…」というように、ピリオドで連結する。すなわち、ピリオドはタグ名のフィールドセパレータである。「time」と「tag」の間はスペース(" ")で区切られ、「tag」と「record」の間はコロン(":")で区切られる。
入出力整形処理部302はイベントを生成する際、RTC206からイベントに付すための絶対日時情報を読み取る。
【0028】
入出力制御部301の機能として備わっている介護度判定演算処理部303は、後述するADL識別処理部312が出力するADL識別結果に従い、観察対象者の要介護度をADL毎にスコアリングして、レポートデータを作成する。レポートデータは不揮発性ストレージ205に記憶され、情報処理装置101の管理責任者によって観察対象者の評価等に利用される。
【0029】
入出力制御部301は、マルチモーダルセンサから種々のデータの入力を受けると、入出力整形処理部302によって前述のJSON形式のイベントに変換した後、定義ファイル304に記述されている内容に従い、入力同期併合処理部305、条件判断処理部306、学習データ処理部307にてイベントの加工等を行う。
【0030】
[第一の実施形態:入力同期併合処理部305]
ここで
図4Aを参照して、入力同期併合処理部305について説明する。
図4Aは、入力同期併合処理部305の入出力を説明するためのブロック図である。
入出力制御部301の機能として備わっている入力同期併合処理部305は、複数のイベントを受け入れて、各々のイベントの内容を単一のイベントに併合して出力する。単一のイベントを出力する際、入力同期併合処理部305は、定義ファイル304に記述することで指定されたタイミングで、イベントを出力する。イベント同士を併合するタイミングは、「before」、「after」、「simple」の3種類である。
【0031】
定義ファイル304において併合タイミングに「before」が指定された場合には、入力同期併合処理部305は、定義ファイル304の「main_tag」(主入力側)に記述された第一のイベントを受け取ると、第一のイベントを受け取った直前の、「sub_tag」(副入力側)に記述された第二のイベントを、第一のイベントと共に併合して出力する。したがって、「before」の場合は、第一のイベントを受け取った日時が、出力されるイベントに付加される。
【0032】
定義ファイル304において併合タイミングに「after」が指定された場合には、入力同期併合処理部305は、定義ファイル304の「main_tag」に記述された第一のイベントを受け取ると、第一のイベントを受け取った直後の、「sub_tag」に記述された第二のイベントを、第一のイベントと共に併合して出力する。したがって、「after」の場合は、第二のイベントを受け取った日時が、出力されるイベントに付加される。
【0033】
定義ファイル304において併合タイミングに「simple」が指定された場合には、入力同期併合処理部305は、定義ファイル304の「main_tag」に記述された第一のイベントを受け取ると、第一のイベントを受け取った直前の、「sub_tag」に記述された第二のイベントを、第一のイベントと共に併合して出力する。また、第一のイベントを受け取った直後の、「sub_tag」に記述された第二のイベントも、第一のイベントと共に併合して出力する。すなわち、「simple」は「before」と「after」の論理和である。したがって、「simple」の場合は、第一のイベントを受け取った時のみならず、第二のイベントを受け取った時にも、イベントを出力する。
【0034】
以下に、定義ファイル304にて記述される入力同期併合処理部305の指示(ディレクティブ(directive))の一例を示す。定義ファイル304のディレクティブは、XML(eXtensible Markup Language)に類似するマークアップ言語の形式で記述される。
【0035】
<match sensor.{temp, humid}.to_merge>
@type record_merger
tag sensor.temp_humid
main_tag sensor.temp.to_merge
sub_tag1 sensor.humid.to_merge
merge_timing simple
<record>
temp ${main["temp"]}
humid ${sub1["humid"]}
</record>
</match>
【0036】
「<match sensor.{temp, humid}.to_merge>」は、ディレクティブの開始の宣言であると共に、「sensor.temp.to_merge」タグが付されたイベントと「sensor.humid.to_merge」タグが付されたイベントを、タグ名でマッチングさせることを示す。
「@type record_merger」は、本ディレクティブが入力同期併合処理部305の処理を実行する「record_merger」であることを示す。
「tag sensor.temp_humid」は、本ディレクティブが出力するイベントのタグ名が「sensor.temp_humid」であることを示す。
【0037】
「main_tag sensor.temp.to_merge」は、前述の「main_tag」である。すなわち、「sensor.temp.to_merge」が第一のイベントである。
「sub_tag1 sensor.humid.to_merge」は、前述の「sub_tag」である。すなわち、「sensor.humid.to_merge」が第二のイベントである。
「merge_timing simple」は、前述の併合タイミングである。
「<record>」から「</record>」で囲まれる中身は、出力するイベントの中に記述される要素を示す。これはJSONフォーマットで、「名前文字列:値」に変換される。
「</match>」は、「<match sensor.{temp, humid}.to_merge>」ディレクティブの終了を示す。
【0038】
[第一の実施形態:条件判断処理部306]
次に
図4Bを参照して、条件判断処理部306について説明する。
図4Bは、条件判断処理部306の入出力を説明するためのブロック図である。
入出力制御部301の機能として備わっている条件判断処理部306は、単一のイベントを受け入れて、イベントに含まれているデータに対し、所定の条件判断を行う。条件判断は、タグ名の一致または不一致、また数値データの、記述された閾値との比較結果である。条件判断は定義ファイル304内にて、プログラミング言語において一般的な「if...then...else...」の記述が可能である。
以下に、定義ファイル304にて記述される条件判断処理部306のディレクティブの一例を示す。
【0039】
<match sensor.temp>
@type condition_checker
tag1 sensor.room_temp.is_too_cold
tag2 sensor.room_temp.is_too_hot
tag_else sensor.room_temp.is_good
renew_record false
condition1 record ["temp"] <= 18 && record ["season"] == "winter"
condition2 record ["temp"] >= 26 && record ["season"] == "winter"
<record1>
status "cold"
</record1>
<record2>
status "hot"
</record2>
<record_else>
status "good"
</record_else>
</match>
【0040】
「<match sensor.temp>」は、ディレクティブの開始の宣言であると共に、「sensor.temp」タグが付されたイベントを、タグ名でマッチングさせることを示す。
「@type condition_checker」は、本ディレクティブが条件判断処理部306の処理を実行する「condition_checker」であることを示す。
「tag1 sensor.room_temp.is_too_cold」は、後述する「condition1」の条件に合致した場合において出力するイベントのタグ名が「sensor.room_temp.is_too_cold」であることを示す。
【0041】
「tag2 sensor.room_temp.is_too_hot」は、後述する「condition2」の条件に合致した場合において出力するイベントのタグ名が「sensor.room_temp.is_too_hot」であることを示す。
「tag_else sensor.room_temp.is_good」は、condition1及びcondition2の何れにも当てはまらなかった場合において出力するイベントのタグ名が「sensor.room_temp.is_good」であることを示す。
「renew_record false」は、受信したイベントに含まれるレコード(値)の内容を更新しないことを示す。
【0042】
「condition1 record ["temp"] <= 18 && record ["season"] == "winter"」は、「condition1」の条件判断文である。「temp」の値が18以下("<=")、且つ("&&")、「season」の値が「winter」であるか否かを判断する。
「condition2 record ["temp"] >= 26 && record ["season"] == "winter"」は、「condition2」の条件判断文である。「temp」の値が26以上(">=")、且つ("&&")、「season」の値が「winter」であるか否かを判断する。
【0043】
「<record1>」から「</record1>」に囲まれる中身は、「condition1」の条件に合致した際に、イベントに「status:"cold"」というレコードを追加することを定義する。
同様に、「<record2>」から「</record2>」に囲まれる中身は、「condition2」の条件に合致した際に、イベントに「status:"hot"」というレコードを追加することを定義する。
そして、「<record_else>」から「</record_else>」に囲まれる中身は、「condition1」及び「condition2」の、何れの条件にも合致しなかった際に、イベントに「status:"good"」というレコードを追加することを定義する。
「</match>」は、「<match sensor.temp>」ディレクティブの終了宣言である。
【0044】
[第一の実施形態:学習データ処理部307]
次に
図4Cを参照して、学習データ処理部307について説明する。
図4Cは、学習データ処理部307の入出力を説明するためのブロック図である。
学習データ処理部307は、入力されたイベントの内容を学習型情報処理装置104に特徴ベクトル(説明変数)として出力し、学習型情報処理装置104から目的変数を受け取り、イベントの形式に変換して出力する。
【0045】
学習データ処理部307には、「train」と「analyze」という2種類のモードが存在する。
trainモードでは、学習データ処理部307は、入力されるイベントを、ラベルとDatumというキーバリュー形式のデータの組に変換し、学習型情報処理装置104に送信する。これにより、学習型情報処理装置104における学習モデルの訓練(学習)を行う。
本発明の第一の実施形態に係る情報処理装置101は、学習型情報処理装置104の一例として、オンライン機械学習向け分散処理フレームワークであるJubatus( http://jubat.us/ja/ )を使用している。Datumとは、このJubatusが解釈可能なkey−valueデータ形式を指す。
【0046】
analyzeモードでは、学習データ処理部307は、入力されるイベントをDatum形式に変換して学習型情報処理装置104に送信する。これにより、学習データ処理部307は、分類・推薦・異常検知等、学習型情報処理装置104が提供している機能を使用して分析した結果をリアルタイムで受け取ることができる。
以下に、定義ファイル304にて記述される、学習データ処理部307のanalyzeモードにおけるディレクティブの一例を示す。
【0047】
<match concept.accelerometer.analyze>
@type active_online_learner
host <jubatus server's ip address>
client_api 'classifier'
train_analyze analyze
num_keys ax_mean,ay_mean,az_mean,ax_var,ay_var,az_var
threshold 9.0
tag_for_train concept.unclassifiable
</match>
【0048】
「<match concept.accelerometer.analyze>」は、ディレクティブの開始の宣言であると共に、「concept.accelerometer.analyze」タグが付されたイベントを、タグ名でマッチングさせることを示す。
「@type active_online_learner」は、本ディレクティブが学習データ処理部307の処理を実行する「active_online_learner」であることを示す。
「host <jubatus server 's ip address>」は、学習型情報処理装置104のIPアドレスまたはホスト名が記述される。
「client_api 'classifier'」は、学習型情報処理装置104のクライアント側アプリケーションプログラムインターフェース、すなわち学習データ処理部307に対し、「分類器」として動作すべく指示することを示す。
【0049】
「train_analyze analyze」は、学習データ処理部307に対し、analyzeモードで動作すべく指示することを示す。
「num_keys ax_mean,ay_mean,az_mean,ax_var,ay_var,az_var」は、学習型情報処理装置104に引き渡すデータ、すなわち特徴ベクトルの一例を示す。この例では、3軸センサの各軸方向の平均値と、3軸センサの各軸方向にて検出した値が列挙されている。
「threshold 9.0」は、学習型情報処理装置104から受信した値を判定する際の閾値を示す。
「tag_for_train concept.unclassifiable」は、学習型情報処理装置104から受信した値が全て閾値に満たなかった場合に、出力するイベントに付すタグ名である。
「</match>」は、「<match concept.accelerometer.analyze>」ディレクティブの終了宣言である。
【0050】
以下に、上述の定義ファイル304にて記述される、学習データ処理部307のanalyzeモードにおけるディレクティブによって、学習データ処理部307が学習型情報処理装置104から得た分類結果であるイベントの一例を示す。なお、行頭の"#"はコメントを指し示す。
【0051】
# 既知の概念の中で分類できた場合
2018-01-24T23:42:42+09:00 behavior.recognized
{"cleaning":0.0,"blow-drying":0.0,"sitting":9.84092903137207,
"standing":0.0,"walking":0.0 ,
"estimated_label":"sitting","max_score":9.84092903137207}
【0052】
上記のイベントでは、「"estimated_label":"sitting"」にて、推定結果が「sitting」であり、「"max_score":9.84092903137207」にて、最大スコアが「9.84092903137207」という値であることが示されている。
【0053】
# 既知の概念にあてはまるものがないと判断された場合
2018-01-24T22:46:42+09:00 concept.for_train
{"cleaning":0.0,"blow-drying":1.9574897289276123,
"sitting":7.8311076164245605,"standing":0.0,"walking":0.0,
"estimated_label":"sitting","max_score":7.8311076164245605,
"data":{
"ax_mean":0.143426513671875,"ay_mean":0.0136016845703125,
"az_mean":-0.50174560546875,"mx_mean":0.48634033203125,
"my_mean":0.26500244140625,"mz_mean":-1.013330078125,
"gx_mean":-0.0011932373046875,"gy_mean":0.0130523681640625,
"gz_mean":0.0047119140625
}}
【0054】
上記のイベントでは、「"estimated_label":"sitting"」にて、推定結果が「sitting」であり、「"max_score":7.8311076164245605」にて、最大スコアが「7.8311076164245605」という値であることが示されている。そして、最大スコアが閾値の「9」に満たないので、学習用のデータが付加されている。
学習用バッファ308は、このような推定に失敗したデータを所定の件数、蓄積する。そして、所定の件数に達した時に、trainモードにて学習型情報処理装置104にそれら複数のイベントを送信して、学習型情報処理装置104に学習を行わせる。
【0055】
[第一の実施形態:ADL識別処理部312]
次に
図4Dを参照して、ADL識別処理部312について説明する。
図4Dは、ADL識別処理部312の入出力を説明するためのブロック図である。
ADL識別処理部312は、データ形式変換処理部401、データ形式逆変換処理部402、基礎情報記憶部403、ADL判定処理部404を有する。
学習データ処理部307がanalyzeモードにおいて出力する、既知の概念の中で正常に分類できた観察対象者のイベント(
図4D中「behavior.recognized」)や、図示はしていないが、入力同期併合処理部305や条件判断処理部306が出力する、観察対象者のイベントは、ADL識別処理部312のデータ形式変換処理部401に入力される。
【0056】
データ形式変換処理部401は、入力されるJSON形式のイベントを、一旦ADL判定処理部404が扱うことができる、XML形式に変換する。そして、XML形式に変換されたイベントは、イベントに記述されている日時情報と共に基礎情報記憶部403に記憶される。
ADL判定処理部404は、OWL定義ファイル313に記述されている論理推論の条件と、基礎情報記憶部403に記憶されている観察対象者のイベントとを照合して、観察対象者が何月何日何時何分から何分間、OWL定義ファイル313に記述されているADLを実行したのかを判定する。
ADL判定処理部404が出力したADL判定結果は、データ形式逆変換処理部402によって、XML形式からJSON形式に変換されて、介護度判定演算処理部303へ出力される。この時、イベントのタグは「action.recognized」となる。
【0057】
これまでのADL認識技術は、センサから観察対象者の体動と呼吸と心拍を同時に取得したデータを基に、観察対象者の瞬間的な動作や状態から、機械学習でADLの認識をしていた。
機械学習は、観察対象者の未定義の挙動に対し、新たにラベリングを付与する必要がある。
また、機械学習は、入力される特徴ベクトルに対して所定のラベルを推定するが、推定の根拠は確率計算の結果であるため、なぜ入力された特徴ベクトルに対して機械学習装置が提示したラベルであると推定したのか、その理由を明確に説明することができない。
【0058】
一方、情報科学の分野では、近年になって人工知能(AI:Artificial Intelligence)の技術情報の一環として、知識を記述する「オントロジー(ontology)」という言葉が台頭し始めた。人工知能の用語としてのオントロジーは、「概念の明示的な仕様」と定義される。
この考え方をADLに当てはめると、ADLも観察対象者の行動であるので、その行動を言葉で明確に定義することが可能である。
行動は、人と物と場所と時間の、四つの要素で成り立っている。したがって、ADLにおいてこれら四つの要素を定義することで、複雑なADLもより単純な情報要素に分解することが可能である。
【0059】
例えば、観察対象者が歯を磨く、というADLを実行することを考える。
観察対象者はシンクのある部屋に立っていて、何れかの手に歯ブラシを持っており、数分程度、歯を磨く動作を行う。このような状況をよく観察すると、
・人の状態:観察対象者が立っている
・物の状態:歯ブラシが観察対象者の近くに存在する
・場所の状態:観察対象者はシンクのある部屋に居る
・時間の状態:観察対象者は数分程度、あるいは日中や朝晩等の時間帯において、立っている状態を維持している
というように、各々の事象を文章化することが可能である。
【0060】
学習型情報処理装置において、観察対象者が立っているか否かの推定は、観察対象者が歯磨きを行っているか否かを推定するよりも単純であることは明白である。
そこで発明者らは、学習型情報処理装置には観察対象者のごく単純な挙動のみを学習させ、より高次のADLは、複数の挙動や状態からルールベースで判断するように、情報処理装置を再構築することが好ましいと考えた。
【0061】
OWL言語はRDF(Resource Description Framework)の語彙を拡張したものである。本発明の実施形態に係るADL判定処理部404と基礎情報記憶部403は、Java(登録商標)で構成されるOWL言語インタプリタ(https://github.com/owlcs/owlapi/)である。
OWL定義ファイル313には、ADLを定義するために、人の状態、物の状態、場所の状態、時間の状態が、ツリー構造で記述されている。ADL判定処理部404は、入力された事象に合致するルールのツリー構造を辿ることで、観察対象者のADLを判定することが可能になる。
【0062】
[第一の実施形態:OWLの一例]
以下、OWLの一例を説明する。
図5及び
図6は、オープンソースのオントロジー編集用エディタである「Protege」( https://protege.stanford.edu/ 、"Protege"の2個の"e"はアキュート・アクセント付きのeである。)を用いた、観察対象者のADLを編集する様子を示す画面イメージである。
図5Aは、Protegeの編集画面である。
図5Bは、Protegeの編集画面のうち、左端に表示されているクラス一覧表示欄(Protegeでは「Class View」と呼ぶ)を一部拡大した図である。
図6Aは、Protegeの編集画面のうち、右上に表示されているクラス「BrushingTeeth」のクラス総合関係表示欄を一部拡大した図である。
図6Bは、Protegeの編集画面のうち、右下に表示されているクラス「BrushingTeeth」のクラス詳細編集欄を一部拡大した図である。
【0063】
例えば、整容ADLの1つである「歯みがき行動(BrushingTeeth)」のOWLによる定義は以下のようになる。
(1)
図5及び
図6を参照して説明する。
まず、クラスとして「行動(Activity)」、「人(Person)」、「もの(Artifact)」、「場所(SymbolicLocation)」を定義し、それぞれのクラス階層を定義する。たとえば、「行動」のサブクラスとして「単独行動(Individial Activity)」、そのサブクラスとして「個人行動(Personal Activity)」が定義され、その下に認識対象のADLである「歯磨き(Brushing Teeth)」「整髪(CombingHair)」などが定義される。
【0064】
(2)次に、クラスオブジェクトの間の関係をObject Propertyで定義する。たとえば、「〜の行動は〜の場所で行われる(canTakePlaceOn)」は、行動と場所クラスのオブジェクト間の関係を定義する。この他には「〜の者は〜を使う(usingArtifact)」や、「〜の場所は〜を備える(has Artifact)」などが定義される。
上記のクラスと関係を用いて、個々のADLを定義する。たとえば、「歯磨きは、個人行動であり、歯ブラシを持って行われ、流しのある場所で行われる。」と定義され、
図6Aに表示される、以下のようなOWLとなる。
【0065】
BrushingTeeth SubClassOf PersonalActivity and (hasActor only (usingArtifact some Comb))
BrushingTeeth SubClassOf canTakePlaceOn only (hasArtifact some Sink)
【0066】
(3)最後に、定義されたOWLはRDF/XML記述として出力され、これを用いて、ADLクラス判定のための論理推論を行うReasonerが動作する。
【0067】
[第一の実施形態:情報処理装置101:データ処理のアーキテクチャ]
図7は、情報処理装置101が実行するデータ処理のアーキテクチャ(設計思想)を示す概念図である。
情報処理装置101は、Fluentdにて形成される3種類のデータフローを定義ファイル304にて定義し、それらデータフローをイベントのタグ名で区別する。また、Fluentdの外部に設けられるADL認識層C704は、観察対象者の全てのADLの判定を実行する。
【0068】
先ず、マルチモーダルセンサC701から生じる種々のデータは、センサレベルデータフローC702に入力される。センサレベルデータフローC702では、各々のイベントに「sensor.**」で始まるタグが付される。そして、センサレベルデータフローC702の内部では、入力同期併合処理部305によって複数のイベントが1個のイベントに併合される、あるいは概念レベルデータフローC703やADL認識層C704に転送される。特に、ADL認識層C704に転送されるイベントには「behavior.**」で始まるタグが付される。
なお、「sensor.**」の"**"(アスタリスク2文字)は、情報処理装置101が扱うイベントに付されるタグ名の文字列マッチング処理において、タグ名のフィールドセパレータである"."(ピリオド)で区切られるフィールド単位のワイルドカードを意味する。
【0069】
センサレベルデータフローC702にて形成されたイベントのうち、そのままでは観察対象者の基礎的な振る舞いを認識できないイベントは、学習型情報処理装置104によって推定を行う必要が生じる。そこで、そのような「行動不可能な」イベントは、「concept.**」で始まるタグが付され、概念レベルデータフローC703に入力される。
【0070】
概念レベルデータフローC703に属する、学習アルゴリズムを用いる学習型情報処理装置104は、観察対象者の基礎的な振る舞いを推定する。そして、概念レベルデータフローC703が出力したイベントは、「behavior.**」で始まるタグが付され、ADL認識層C704に入力される。
【0071】
ADL認識層C704によって観察対象者のADLを認識または推定可能になったイベントは、認識したADLに基づいてスコアリング処理を行う、認識したADLをデータベース309にログ記録されるか、あるいは会話音声を発する等、何らかの行動を可能とする。このような「行動可能な」イベントは「action.**」で始まるタグが付され、行動レベルデータフローC705に入力される。行動レベルデータフローC705では、最終的に得られた認識結果に従って、スコアリング処理が行われるか、ログ記録されるか、あるいは会話音声を発する等の、所定のアクションが実行される。このアクションがアクティベータC706である。
【0072】
図5を見ると情報処理装置101は、マルチモーダルセンサC701から生じるイベントをセンサレベルデータフローC702に入力する。センサレベルデータフローC702から出力されるイベントは、概念レベルデータフローC703に入力されるか、またはADL認識層C704に直接入力される。ADL認識層C704が出力するイベントは全て行動レベルデータフローC705に入力される。
すなわち、センサレベルデータフローC702と、概念レベルデータフローC703が出力するイベントの何れも、ADL認識層C704に入力され、観察対象者のADLの判定処理が行われる。
【0073】
本発明の第一の実施形態に係る情報処理装置101では、入出力制御部301の大部分の機能にFluentdを使用した。しかし、使用するソフトウェアは必ずしもFluentdには限らない。定義ファイル304の記述によってデータの流れを自由に定義することができる仕組みがあれば、Fluentdでなくとも、情報処理装置101を実現することは可能である。一例として、名前付きパイプを応用して、シェルスクリプト等を使用すること等が考えられる。
【0074】
[第二の実施形態:情報処理装置801:ソフトウェア機能]
発明者らは、第一の実施形態に係る情報処理装置101を完成した後も更に改良を続け、より実用的な情報処理装置801を構築するに至った。
これより説明する第二の実施形態では、主に高齢者の日常生活における機能的自立度を計測して評価するための情報処理装置801を開示する。機能的自立度の計測には、医療・介護領域で広く用いられているADL評価指標である、機能的自立度評価法(FIM:Functional Independence Measure)を用いる。
【0075】
従来、FIMは専門の教育を受けた担当者が被験者である高齢者を例えば1週間程度観察して、各種項目毎に自立度を評価し、それら項目毎に点数を付与し、それら点数を合算することで、当該被験者の機能的自立度を評価する。すなわち、機能的自立度評価には人手が必要で、また機能的自立度評価に要する労力も軽微ではない。このような機能的自立度評価の仕組みを機械化できれば、介護従業者の大幅な省力化に寄与することが期待できる。
【0076】
図8は、本発明の第二の実施形態に係る情報処理装置801の、ソフトウェア機能の全体像を示すブロック図である。
図9は、本発明の第二の実施形態に係る情報処理装置801の、ソフトウェア機能におけるデータ処理の流れを示すブロック図である。
本発明の第二の実施形態に係る情報処理装置801の、全体構成は
図1と同一であり、ハードウェア構成も
図2と同一であるので、これらの説明は割愛する。
図8に示す本発明の第二の実施形態に係る情報処理装置801の、
図3に示す本発明の第一の実施形態に係る情報処理装置101との相違点は、入出力制御部802に含まれる機能ブロックである。逆に、入出力制御部802の外側に存在する機能ブロックは、
図3と等しい。
また、
図9に示すデータ処理の流れを説明するブロック図は、
図7に示すデータ処理のアーキテクチャに類似する。
【0077】
マルチモーダルセンサC701は、
図3及び
図8における顔認識カメラ102、センサ103a、103b…及びマイク107に相当する。
マルチモーダルセンサC701から生じる種々のデータは、時系列データ群901としてRAM204や不揮発性ストレージ205に記憶される。
【0078】
データフォーマット処理部803は、時系列データ群901に対して、以下に例示列挙する種々の整形処理を施す。
(1)マルチモーダルセンサC701から入力される各々のデータのクリーニング(クレンジング)
・移動平均等のノイズ除去処理
・欠損値補完処理
・同一サンプリング周波数へのリサンプリング処理
(2)各々のセンサデータの統合
・複数センサからのデータの統合
・機械学習推定処理部に特徴ベクトルを入力させるための特徴量としての選択
(3)データの変換
・特徴量生成
・正規化
【0079】
データフォーマット処理部803は、以上のようなデータの整形処理を行う。これにより、出力形式やサンプリング周波数及び出力タイミングの異なる複数種類のセンサから得られるデータ群は、出力形式が統一され、サンプリング周波数及び出力タイミングが揃えられ、ノイズが抑制され、欠損データが補完される。
時系列データ群901とデータフォーマット処理部803は、
図7におけるセンサレベルデータフローC702と実質的に等しい。
本発明の第二の実施形態に係る情報処理装置801は、後述するADL・FIMオントロジー解析処理部904がOWL言語インタプリタであり、XML形式のデータを要求するため、データフォーマット処理部803はXML形式のデータを出力する。
【0080】
データフォーマット処理部803によって整形処理された時系列データ群901は、その一部を除いて、データ駆動処理部902に供給される。
データ駆動処理部902は、データマイニング判定処理部804と、機械学習推定処理部805を含む。
データマイニング判定処理部804は、ルールベースのデータ処理を行う。すなわち、データマイニング判定処理部804は、予めシステム構築者の手作業によってルールを作成する。そして、単一または複数のデータに対して作成したルールによる明示的な条件を当てはめて、後述するセマンティックコンテキストに変換する。
【0081】
例えば、高齢者の部屋の天井にアンテナが複数個配置される。そして、スリッパに装着したRFIDが、第一の時間において地点A近傍のアンテナから最大の信号強度を得たとする。次に、スリッパに装着したRFIDが、第一の時間から所定時間経過した第二の時間において地点B近傍のアンテナから最大の信号強度を得たとする。このような、アンテナ毎の信号強度の変化があった場合、当該スリッパは、第一の時間から第二の時間において、地点A近傍から地点B近傍へ移動したと判断することができる。
このような、機械学習による判定を行うまでもなく、明示的に判断可能な事象に対しては、データマイニング判定処理部804は、システム構築者の手作業によって作成したルールを用いて、時系列データ群901をセマンティックコンテキストに変換する。
【0082】
機械学習推定処理部805は、第一の実施形態における学習データ処理部307に相当する。機械学習推定処理部805は、主に分類学習アルゴリズムに基づくデータ処理を行う。すなわち、予め学習処理を施して形成した近似関数に、所定のデータを特徴ベクトルとして入力し、推定結果と類似度を出力する。そして、機械学習推定処理部805は、複数の近似関数を組み合わせて、所定のデータから後述するセマンティックコンテキストに変換する。
【0083】
データフォーマット処理部803によって整形処理された時系列データ群901の一部、及びデータマイニング判定処理部804と機械学習推定処理部805が出力するデータは、セマンティックコンテキストデータ群903としてRAM204や不揮発性ストレージ205に記憶される。
データ駆動処理部902とセマンティックコンテキストデータ群903は、
図7における概念レベルデータフローC703と実質的に等しい。
【0084】
[第二の実施形態:情報処理装置801:各種テーブルのフィールド構成]
時系列データ群901は、センサが出力するデータそのものである。これに対し、セマンティックコンテキストデータ群903は、イベント、すなわち事象を表現するデータである。
ここで、時系列データ群901とセマンティックコンテキストデータ群903とのデータ形式の相違を説明する。
図10は、各種テーブルのフィールド構成を示す図である。
時系列データ群901は、日時フィールドと、センサIDフィールドと、属性IDフィールドと、属性値フィールドを有する。
【0085】
日時フィールドには、センサがデータを出力した時点の日時情報が格納される。
センサIDフィールドには、センサを一意に識別するセンサIDが格納される。なお、センサIDはセンサの種類を示すセンサ種別情報と組にしてもよい。
属性IDフィールドには、センサが出力するデータの属性を一意に識別する属性IDが格納される。属性IDは例えば、RFIDを検出するアンテナが、あるRFIDを検出した際の、RFIDが受信機へ返信する識別IDである。
属性値フィールドには、属性IDフィールドに格納された属性IDに対応する属性値が格納される。属性値は例えば、RFIDを検出するアンテナが、あるRFIDを検出した際の、RFIDが受信機へ識別IDを返信した際の電波の強度である。
【0086】
属性IDフィールドと属性値フィールドは、センサの種類や数が増えても、属性IDの一意性を維持することで、様々なセンサの出力データを格納することが可能である。
【0087】
セマンティックコンテキストデータ群903は、開始日時フィールドと、終了日時フィールドと、イベントIDフィールドと、属性IDフィールドと、属性値フィールドを有する。
開始日時フィールドには、イベントIDフィールドに記載されたイベントIDで指定されるイベントが発生した日時が格納される。
終了日時フィールドには、イベントIDフィールドに記載されたイベントIDで指定されるイベントが終了した日時が格納される。
【0088】
イベントIDフィールドには、イベントを一意に識別するイベントIDが格納される。イベントとは、被験者が何らかの動作を行った、あるいは何らかの状態に至ったことを指す。このイベントIDに共通する複数のレコードは、同一のイベントを指し示す。
属性IDフィールドには、イベントの発生の具体的内容を示す意味的役割を一意に識別する属性IDが格納される。
属性値フィールドには、属性IDフィールドに記述された意味的役割に付随するデータが格納される。なお、意味的役割については
図11で後述する。
【0089】
セマンティックコンテキストデータ群903の、テーブルのフィールド構成は、
図10に示す形式ではあるが、セマンティックコンテキストデータ群903のデータ形式そのものは、本発明の第一の実施形態に係る情報処理装置101と同様の、XML形式である。
【0090】
再び
図8及び
図9を参照して、データ処理の流れを説明する。
セマンティックコンテキストデータ群903は、オントロジー推論処理部806に読み込まれる。
オントロジー推論処理部806は、本発明の第一の実施形態に係る情報処理装置101のADL識別処理部312に相当し、ADL・FIMオントロジー解析処理部904と、DL推論器905を含む。
【0091】
ADL・FIMオントロジー解析処理部904は、セマンティックコンテキストデータ群903をOWL定義ファイル313に記述されている論理推論の条件に基づいて解釈する。そして、観察対象者が何月何日何時何分から何分間、OWL定義ファイル313に記述されているADLを実行したのかを判定する。更に、ADL・FIMオントロジー解析処理部904は、ADLの下位に定義されているFIMを判定できる場合にはFIMも判定する。この時、ADL・FIMオントロジー解析処理部904は、セマンティックコンテキストデータ群903に含まれる複数のセマンティックコンテキストをOWL定義ファイル313に基づいて紐付け、OWLオントロジーオブジェクトインスタンス908を生成する。
【0092】
ADL・FIMオントロジー解析処理部904の判定結果は、DL推論器905に入力される。DL推論器905は、例えば Fact++(http://owl.man.ac.uk/factplusplus/)であり、セマンティックコンテキストデータ群903とOWLオントロジーオブジェクトインスタンス908をも読み込んで、論理推論を実行する。そして、FIMを判定する。
オントロジー推論処理部806は、以上の処理を経て、行動クラス判定結果及び自立度クラス判定結果906を出力する。
【0093】
再び
図10を参照して、テーブルのフィールド構成を説明する。
行動クラス判定結果1001は、開始日時フィールドと、終了日時フィールドと、個人IDフィールドと、ADLフィールドを有する。
開始日時フィールドには、個人IDフィールドに記載された被験者がADLフィールドに記載されたADLの実行を開始した日時が格納される。
終了日時フィールドには、個人IDフィールドに記載された被験者がADLフィールドに記載されたADLの実行を終了した日時が格納される。
個人IDフィールドには、被験者を一意に識別する個人IDが格納される。
ADLフィールドには、ADL・FIMオントロジー解析処理部904が判定したADLが格納される。
【0094】
自立度クラス判定結果1002は、開始日時フィールドと、終了日時フィールドと、個人IDフィールドと、ADLフィールドと、FIMフィールドを有する。
開始日時フィールドと、終了日時フィールドと、個人IDフィールドと、ADLフィールドは、行動クラス判定結果1001の同名フィールドと同一である。
FIMフィールドには、ADL・FIMオントロジー解析処理部904またはDL推論器905によって判定されたFIMが格納される。
【0095】
再び
図8及び
図9を参照して、データ処理の流れを説明する。
行動クラス判定結果及び自立度クラス判定結果906は、確信度演算処理部807に入力される。
確信度演算処理部807は、DL推論器905で判定できなかったFIMについて、OWLオントロジーオブジェクトインスタンス908を参照しながら、後述する「クラスの確信度」を計算することで、FIMの判定を実行する。そして、確信度演算処理部807は最終的にADL認識結果及びFIM採点結果907を出力する。
セマンティックコンテキストデータ群903とオントロジー推論処理部806と行動クラス判定結果及び自立度クラス判定結果906と確信度演算処理部807は、
図7におけるADL認識層C704と実質的に等しい。
【0096】
オントロジー推論処理部806がFIMの判定に失敗する場合を想定して、ADL・FIMオントロジー解析処理部904は、予めセマンティックコンテキストデータ群903の、特定の条件において、ダミーの任意コンテキストをOWLオントロジーオブジェクトインスタンス908に挿入する。確信度演算処理部807は、このダミーコンテキストの存在を加味して、FIMの確からしさを計算する。これにより、マルチモーダルセンサC701から得られる時系列データ群901に不具合が生じ、不完全なセマンティックコンテキストデータ群903しか得られなかった場合でも、オントロジー推論処理部806は、確度の高いFIMを判定することができる。
【0097】
[第二の実施形態:情報処理装置801:セマンティックコンテキスト]
図11は、セマンティックコンテキストにおける意味的役割を説明する図である。
図11に示すように、本発明の第二の実施形態に係る情報処理装置801において、セマンティックコンテキストにおける意味的役割としては、「動作主」「対象」「道具」「共役者」「場所」「空間的始点」「空間的終点」「時間帯」「時間的始点」「時間的終点」「補助」「姿勢」「移動距離」「所要時間」が存在する。特に、情報処理装置801では、高齢者のFIMが扱われるため、上述した意味的役割の中の「補助」の概念が必要になる。
【0098】
セマンティックコンテキストは、格文法における深層格を独自に拡張した概念を用いる。深層格とは、述語(動詞)とそれに係る名詞句の意味役割をまとめたものである。格文法では、文の意味構造が述語(動詞)と深層格の組み合わせによって表現される。こうした言語の意味的表現は多言語翻訳の際の中間言語としても用いられる。深層格の種類は、一般的には動作主格(Agent)、経験者格(Experiencer)、道具格(Instrument)、対象格(Object)、源泉格(Source)、目標格(Goal)、場所格(Location)、時間格(Time)の8種類とされることが多い。
【0099】
時系列データ群901をデータ駆動処理部902で認識した結果は、
図11に示すセマンティックコンテキストの意味的役割のいずれかに当てはまる。
セマンティックコンテキストを構成する意味的役割を抽出するためには、様々なセンサが用いられる。例えば、慣性センサやマイクロフォンが搭載されたスマートフォンやスマートウォッチ、そしてRFIDが貼られた衣服等のウェアラブルセンサなどが、主に対象となる行動、動作、姿勢などを検出するために用いられる。
【0100】
RFIDタグやコンタクトセンサ等の、物に取り付けることができるオブジェクトセンサは、主にオブジェクトの場所、物体間の空間的関係、そして移動や使用状況などを捉えるために利用される。
ウェアラブルセンサは、人間に取り付けられる一種のオブジェクトセンサと見なすこともできる。このウェアラブルセンサにより、対象範囲にどのようなオブジェクトがあるか、対象の人物とインタラクションを持つオブジェクト(道具)があるか、そして被介助者の周囲に介助者がいるかといったコンテキスト情報を得ることができる。
人感センサや温度センサや湿度センサなどの環境センサは、部屋の状態を監視するために用いられる。
【0101】
図12は、セマンティックコンテキストデータ群903から形成される、セマンティックコンテキストの具体例を示す図である。
図13Aは、データ駆動処理部902で認識されたセマンティックコンテキストの、場所における具体例を示す図である。
図13Bは、データ駆動処理部902で認識されたセマンティックコンテキストの、姿勢における具体例を示す図である。
図13Cは、データ駆動処理部902で認識されたセマンティックコンテキストの、道具における具体例を示す図である。
図14は、データ駆動処理部902で認識されたセマンティックコンテキストの、対象における具体例を示す図である。
【0102】
第一のテーブル1201は、動作主フィールド、場所フィールド、時間的始点フィールド、時間的終点フィールド、所要時間フィールド、時間帯フィールドを有する。
第二のテーブル1202は、動作主フィールド、姿勢フィールド、時間的始点フィールド、時間的終点フィールド、所要時間フィールド、時間帯フィールドを有する。
第三のテーブル1203は、動作主フィールド、道具フィールド、時間的始点フィールド、時間的終点フィールド、所要時間フィールド、時間帯フィールドを有する。
第四のテーブル1204は、動作主フィールド、共役者フィールド、補助フィールド、対象フィールド、空間的始点フィールド、空間的終点フィールド、移動距離フィールド、時間的始点フィールド、時間的終点フィールド、所要時間フィールド、時間帯フィールドを有する。
【0103】
図13Aのテーブルは、動作主が何月何日何時何分から何月何日何時何分まで、どこに居たのかを記したセマンティックコンテキストである。
図13Aのテーブルは、
図12の第一のテーブル1201に対応する。
図13Aのテーブルでは、所要時間フィールドと時間帯フィールドが省略されている。
図13Bのテーブルは、動作主が何月何日何時何分から何月何日何時何分まで、どのような姿勢であったのかを記したセマンティックコンテキストである。
図13Bのテーブルは、
図12の第二のテーブル1202に対応する。
図13Bのテーブルでは、所要時間フィールドと時間帯フィールドが省略されている。
【0104】
図13Cのテーブルは、動作主が何月何日何時何分から何月何日何時何分まで、何の道具を持っていたのかを記したセマンティックコンテキストである。
図13Cのテーブルは、
図12の第三のテーブル1203に対応する。
図13Cのテーブルでは、所要時間フィールドと時間帯フィールドが省略されている。
図14のテーブルは、動作主が何月何日何時何分から何月何日何時何分まで、どこからどこまで、何をしていたのかを記したセマンティックコンテキストである。
図14のテーブルは、
図12の第四のテーブル1204に対応する。
図14のテーブルでは、共役者フィールド、補助フィールド、所要時間フィールドと時間帯フィールドが省略されている。
以上の、
図13A、
図13B、
図13C及び
図14において省略されているフィールドは、必ずしもデータの記入を必要としないフィールドである。
【0105】
図15は、FIMオントロジーの一部抜粋をOWLエディタのProtege上で表示した図である。
本発明の第一の実施形態に係る情報処理装置101では、ADLのオントロジーを作成したが、本発明の第二の実施形態に係る情報処理装置801では、ADLに加えて、FIMのオントロジーを作成する。
ADLは「昼食を食べた」というような、事象を認識するだけに留まる。これに対し、FIMは「一人で昼食を食べた」あるいは「介護者の介護を伴って昼食を食べた」というような、事象に加えて機能的自立度評価の元となる評価要素を伴う。
【0106】
オントロジーは、W3C標準に従ってOWL(Web Ontology Language)形式で作成される。OWLオントロジーは、 Individual, Property, Class から構成される。Individual はそのドメイン内のオブジェクトを表す。例えば、PersonA, Chair1, ActivityOfPersonA などである。Property は2つの Individual の二項関係である。例えば、 hasCurrentActivity Property は PersonA Individual とActivityOfPersonAIndividual を関連付け、 PersonA が現在行っている行動 ActivityOfPersonA を持っていることを示す。Class は Individual の集合に関連付けられる。例えば、PersonAIndividual は Person Class に関連付けられる。
図15に示すオントロジーの一部抜粋は、左から順に Class, Object Property, および Individual の一部を切り出している。これらのオントロジーの作成には、IRF−PAI(Inpatient Rehabilitation Facility, Patient Assessment Instrument)トレーニングマニュアル(https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/IRF-Quality-Reporting/IRF-PAI-and-IRF-PAI-Manual)を参照した。
【0107】
図16は、ADL/FIMオントロジーにおける、FIMの定義の一部を説明する図である。
ADL及びFIMは、オブジェクト指向に基づいて定義される。
FIM Class は、
図16に示すように階層構造を用いて各項目が表現されている。 FIM Class のサブクラスとして Motor Class があり、その中に Self-Care, Locomotion といったカテゴリがある。そして、カテゴリクラスのサブクラスとして、 Eating 等の各評価項目が定義されており、更にそのサブクラスとして自立度スコアに対応したクラスが定義されている。 Eating や Bathing, Toileting といった各評価項目レベルのクラスは、ADLクラスのサブクラスでもある。なお、
図16では画像の大きさの都合上、省略しているが、 Self-Care 以外のカテゴリについても各評価項目および自立度に対応するサブクラスが定義されている。
【0108】
図17は、FIM評価項目とコンテキストとの関係の一例を説明する図である。
図17に示すように、各FIM評価項目は、 Activity Class に様々なコンテキストを has-Context Property で関連付けることで定義される。このContext はセマンティックコンテキストデータ群903と対応しており、例えば
図17の左側のisTaking-PlaceOn DiningRoom は、その行動の場所コンテキストが Dining Room であるということ、中央の hasAssistance ModerateAssistance は介助コンテキストが中等度介助であるということ、右側の usingArtifact EatingUtensil は道具コンテキストが食事用具であるということを意味している。
【0109】
図18は、作成したADL/FIMオントロジーにおける定義の一例をOWLエディタのProtege上で表示した図である。
図18には、ADL/FIMオントロジーにおける Eating-6 Class の定義が掲載されている。ここで、 Eating-6 Class とは、FIM項目における食事に該当し、“-6”はその行動における自立度が6であることを意味する。
図18の定義は、 Eating-6 Class は、ダイニングルームもしくはSemanticEatingPlace2 で行われ、飲食物を口に運ぶ動作を伴い、介助は必要なく、時間帯は朝・昼・夕食時、姿勢は座位、補助食事用具を使用している PersonalActivity であることを意味している。
【0110】
図19は、継続して発生するコンテキストの表現例を示す図である。
図19に示すように、時間軸上に継続して発生するコンテキストは、hasPrecedentContext または hasSubsequentContext Property を使用して表現される。この例では、リビングルームからトイレ、さらに居室(プライベートルーム) への遷移が示されている。また、 hasPrecedentContext は TransitiveProperty であるから、両端のコンテキストは hasPrecedentContext と暗黙的にリンクされる。
【0111】
図20は、DL推論器905が実施する推論タスクの一覧を示す図である。
作成したADL/FIMオントロジーでは、各 Person Individual が hasCurrentActivityProperty によって Activity Class の Individual と紐付けられている。そして、データ駆動層で抽出されたセマンティックコンテキストのインスタンスが Activity Class の Individual に hasContext Property によって紐付けられる。そして、 Fact++ や Pellet (https://github.com/stardog-union/pellet)といったDL推論器905を用いて、“概念のインスタンス” タスクにより Activity Individual がFIMの評価項目のどのクラスに属するかを特定することでFIM計測が実現される。
【0112】
ここでは、概念記述はオントロジーの Class 階層や定義(
図15の左側)、個体記述は Individual (データ駆動層で認識されたコンテキストおよび予め挿入されていたインスタンス(
図15の右側)) を指す。つまり、DL推論器905は、作成されたFIMオントロジーと環境に応じて予め挿入されていたインスタンス、認識されたコンテキスト情報を用いて、
図20にある推論タスクを実行し、対象の人物が持つ Acitivity クラスの Individual がどの行動およびスコアに対応するクラスに属するのかを判定する。
【0113】
図21は、DL推論器905の動作の一例をOWLエディタのProtege上で表示した図である。
図21では、 PersonA が持つActivityOfPersonA が、DL推論器905によって Eating-6 クラスに属すると判定された例を示す。表示箇所P2101は、実際には表示部106において背景が黄色くなっており、Eating-6 が推論により導出されたことを意味している。
【0114】
オントロジー推論においては、クラスの定義を不足なく満たしていれば意図した通りに結果を出力することができるが、得られたセマンティックコンテキストが不完全な場合は自立度を含むサブクラスまで絞り込むことができなくなってしまう。つまり、オントロジー推論の枠組みを利用するには、FIMを測定するためには対象のクラスに定義された全てのコンテキストは必ず得られるようにする必要がある。
しかし、現実環境においては、環境の違いによってセンサの数や種類に制限がある、またセンサやネットワーク障害が原因で一部のセンサデータが得られないといったことがしばしば発生する。これでは、現実の環境に適用するには有効性にかけていると言わざるを得ない。そこで、現実環境に適用するためには、不完全なデータからでも、その不完全なデータから考えられる最大限の結果を出力できるようにすることが求められる。
【0115】
そこで本発明の第二の実施形態に係る情報処理装置801では、不完全なコンテキストによる推論の失敗を防ぐために、必ず認識されるべき必須コンテキストだけでなく、必ずしも認識される必要はない任意コンテキストという概念を新たに導入する。
任意コンテキストは、対象とするクラスの定義において、 hasContext Property の代わりに hasOptionalContext Property を使うことで表現される。 hasOptional-Context Property が関連付けられたコンテキストは、初期状態として予めダミーの Context インスタンスを Activity インスタンスに関連付けられる。そして、実際に対応するコンテキストが観測された際には、ダミーの Context インスタンスを有効なコンテキストと入れ替わる。ダミーのコンテキストにはA isOptional Property が紐付けられているため、実際に認識されたコンテキストなのか、初期状態からダミーとして挿入されていたコンテキストなのかを判別することができる。
【0116】
これにより、任意コンテキストに関しては実際にデータ駆動層で認識されなかったとしても、必須コンテキストが全て認識されてさえいれば、DL推論器905はその ActivityClass のIndividual をその対象クラスのインスタンスとして認識する。そして、DL推論器905は、この認識されたクラスで定義されているコンテキストの数(必須コンテキスト+任意コンテキスト)に対する実際に認識されたコンテキストの割合を計算することで、そのクラスの確信度を計算する。
このように、DL推論器905は、 Activity Class の Individual が複数のクラスのインスタンスとして認識した場合に、各FIMクラスごとの確信度を計算することによって最も可能性の高い結果を出力することができる。
【0117】
図22は、任意コンテキストを含むセマンティックコンテキストの一例を示す図である。
図22は、対象となる動作(PickingUpFood, BringingFoodToMouth)が認識されなかった場合でも、任意コンテキストの存在によりEating-6 と認識される例を図示したものである。
図22に示すように、中心にある Activity Class から7つのコンテキストへ7本の矢印が延びている。このうち、実線の矢印は、実際に認識されたコンテキストであり、点線の矢印は初期状態からダミーとして挿入されていたコンテキストを意味している。この場合は、定義にある7つのコンテキストうち5つのコンテキストが実際に認識されているため、確信度は5/7(=0.71)となる。
【0118】
本発明の第二の実施形態に係る情報処理装置801の動作を検証するため、実験を行った。
本実験では発明者らが所属する研究室の学生4名に協力してもらい、介護者・被介護者役をお願いし、スリッパやネームプレート、机・椅子等にRFIDタグを取り付け、データの収集を行った。また、研究室実験においては、予め想定されるFIMスコアが異なる3つの動作シナリオを用意し、協力者にはそれに従った動作をお願いした。
シナリオ1は、最も健常者に近い、FIMスコアを高く想定したシナリオである。シナリオ2は、シナリオ1よりもFIMスコアを低く想定したシナリオである。シナリオ3は、シナリオ2よりもFIMスコアを低く想定した、すなわち最もFIMスコアを低く想定したシナリオである。
【0119】
図23Aは、シナリオ1での実験結果をガントチャートにて示す図である。
図23Bは、シナリオ2での実験結果をガントチャートにて示す図である。
図23Cは、シナリオ3での実験結果をガントチャートにて示す図である。
図23A、
図23B及び
図23Cは、情報処理装置801から出力された結果をガントチャートにプロットした結果である。
また、各区間において複数カテゴリ(e.g. Loco, Transfer,Self-care)のクラスが出てきた場合には、その区間のクラスに対応したものを優先して出力している。全体的な結果としては、各シナリオで想定していた通りにFIMスコアは Scenario-1 が一番高く、 Scenario-3 が一番低いという結果になっている。
【0120】
本発明の各実施形態においては、情報処理装置を開示した。
本発明の第一の実施形態に係る情報処理装置101は、種々のセンサ(マルチモーダルセンサC701)を利用して、多種多様なADLの識別あるいは推定を行う。
入力同期併合処理部305は、複数のイベントを受け入れて、各々のイベントの内容を単一のイベントに併合して出力する。その際、入力同期併合処理部305は、定義ファイル304に記述することで指定されたタイミングで、イベントを出力する。
【0121】
学習データ処理部307は、入力されたイベントの内容を学習型情報処理装置104に特徴ベクトルとして出力し、学習型情報処理装置104から目的変数を受け取り、イベントの形式に変換して出力する。
条件判断処理部306は、単一のイベントを受け入れて、イベントに含まれているデータに対し、所定の条件判断を行うことで、条件に応じて異なるイベントを出力する。
ADL識別処理部312は、入力される様々なイベントで明らかになる基礎的な事象に基づいて、観察対象者における高次のADLを判定する。
高次のADLをルールベースで定義することで、ADL識別処理部312は、低負荷でありながら高い判定精度のADL判定を実現することができる。
【0122】
本発明の第二の実施形態に係る情報処理装置801は、マルチモーダルセンサC701を利用して、ADL及びFIMの判定を行う。
マルチモーダルセンサC701から生成される、時系列データ群901は、データ駆動処理部902によって、事象を表現するセマンティックコンテキストデータ群903に変換される。セマンティックコンテキストデータ群903は、オントロジー推論処理部806によってADLが判定される。
オントロジー推論処理部806がFIMの判定に失敗する場合を想定して、ADL・FIMオントロジー解析処理部904において、予めセマンティックコンテキストデータ群903の、特定の条件において、ダミーの任意コンテキストを挿入する。そして、最終的に確信度演算処理部807がFIMの確からしさを計算することで、マルチモーダルセンサC701から得られる時系列データ群901に不具合が生じ、不完全なセマンティックコンテキストデータ群903しか得られなかった場合でも、確信度演算処理部807は、確度の高いFIMを判定することができる。
【0123】
以上、本発明の実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、請求の範囲に記載した本発明の要旨を逸脱しない限りにおいて、他の変形例、応用例を含む。
【0124】
101…情報処理装置、102…顔認識カメラ、103a…センサ、104…学習型情報処理装置、105…操作部、106…表示部、107…マイク、201…バス、202…CPU、203…ROM、204…RAM、205…不揮発性ストレージ、206…RTC、207…ネットワークインターフェース、208…シリアルインターフェース、209…A/D変換器、301…入出力制御部、302…入出力整形処理部、303…介護度判定演算処理部、304…定義ファイル、305…入力同期併合処理部、306…条件判断処理部、307…学習データ処理部、308…学習用バッファ、309…データベース、312…ADL識別処理部、313…OWL定義ファイル、401…データ形式変換処理部、402…データ形式逆変換処理部、403…基礎情報記憶部、404…ADL判定処理部、801…情報処理装置、802…入出力制御部、803…データフォーマット処理部、804…データマイニング判定処理部、805…機械学習推定処理部、806…オントロジー推論処理部、807…確信度演算処理部、901…時系列データ群、902…データ駆動処理部、903…セマンティックコンテキストデータ群、904…ADL・FIMオントロジー解析処理部、905…DL推論器、906…行動クラス判定結果及び自立度クラス判定結果、907…FIM採点結果、908…OWLオントロジーオブジェクトインスタンス、1001…行動クラス判定結果、1002…自立度クラス判定結果、1201…第一のテーブル、1202…第二のテーブル、1203…第三のテーブル、1204…第四のテーブル