JP6352732B2 - 生活パターン管理システム及びアプリケーションサーバ - Google Patents

Description

本発明は、例えば、施設で生活する居住者の生活パターンを管理する生活パターン管理システム及びアプリケーションサーバに関する。

従来、介護施設等で生活する居住者の健康状態を検知するために様々なシステムが提供されてきた。このようなシステムでは、居住者が使用したガスや水道の使用量に基づいて居住者の健康状態に異常が発生したことを介護事業者に知らせていた。

例えば、特許文献１には、ガスや水の使用状況に基づき、居住者の体調変化などを通報可能な方法が開示されている。この方法では、居住者宅でのガスおよび／または水道の使用状況を検出し、検出された使用状況を、居住者の健康時における生活パターンを反映したガスおよび／または水道の健康時使用パターンと比較する。そして、検出された使用状況が健康時使用パターンと乖離している場合には、居住者に異常が発生している旨の異常発生通報を、予め定められている通報先に対して行う。

特開２００３−１４１６６７号公報

ところで、上述した特許文献１に開示された技術では、単純にガスや水の使用量の時間平均値と実際の使用量との乖離量が所定値より大きいかどうかを判断しているに過ぎない。このため、時間帯によっては、平均値に対する実使用量の乖離量がわずかであっても居住者の生活パターンが変化したことを検知する必要があるのに異常と捉えず通報しないことがある。逆に、時間帯によっては乖離量が大きくても通常の生活パターンの範囲内と考えられることもあり、この場合には異常発生を誤検知して通報しかねない。

また、多くの居住者がどのような生活パターンで暮らしているかは居住者毎に異なる。このため、居住者の生活実態に合わせてきめ細かく生活パターンの変化を管理できることが望まれていた。

本発明はこのような状況に鑑みて成されたものであり、居住者の長期的な生活パターンの変化を管理することを目的とする。

本発明は、居住者が在室している専有部で使用される特定時間帯におけるエネルギー使用量と、エネルギー使用量の確率密度関数に示されるエネルギー使用量の最頻値との乖離量に基づいて居住者の生活パターンの変化を求める。この確率密度関数は、特定期間かつ特定時間帯に対応して単位時間毎に作成されたものである。そして、専有部の生活パターンを管理するための管理者端末に居住者の生活パターンの変化に基づく情報を知らせる。

本発明によれば、居住者毎に異なる生活パターンの変化に基づく情報を、エネルギー使用量の確率密度関数とエネルギー使用量に基づいて求めることができる。このため、居住者の長期的な生活パターンの変化をきめ細かく管理することが可能となる。

本発明の第１の実施の形態例に係る生活パターン管理システムの構成例を示すブロック図である。 本発明の第１の実施の形態例に係るアプリケーションサーバ及び管理データベースの内部構成例を示すブロック図である。 本発明の第１の実施の形態例に係る計算機のハードウェア構成例を示すブロック図である。 本発明の第１の実施の形態例に係る確率密度関数の例を示すグラフである。 本発明の第１の実施の形態例に係る異常度の正負の内容を示す一覧表である。 本発明の第１の実施の形態例に係る異常度判定表の構成図である。 本発明の第１の実施の形態例に係る異常カウント蓄積テーブルの構成図である。 本発明の第１の実施の形態例に係る表示項目一覧表の構成図である。 本発明の第１の実施の形態例に係る異常判定部が行う異常判定処理と発報部が行う発報処理の例を示すフローチャートである。 本発明の第１の実施の形態例に係る異常又は正常と判定された日のカウントパターン毎に発報部がどのようにして発報の判断を行うかを示す一覧表である。 本発明の第１の実施の形態例に係る家族端末に発報される通報メールの表示例を示す画面構成図である。 本発明の第１の実施の形態例に係る居住者端末に発報される通報内容の表示例を示す画面構成図である。 本発明の第１の実施の形態例に係る管理者端末に表示される管理画面の例を示す画面構成図である。 本発明の第２の実施の形態例に係る生活パターン管理システムの構成例を示すブロック図である。

［第１の実施の形態例］
以下、本発明の第１の実施の形態例に係る生活パターン管理システムについて、図１〜図１３を参照して説明する。
本明細書及び図面において、実質的に同一の機能又は構成を有する構成要素については、同一の符号を付することにより重複する説明を省略する。

＜生活パターン管理システムの構成例＞
図１は、生活パターン管理システム１の構成例を示す。

生活パターン管理システム１は、施設２内の各装置、管理センタ８の各装置、及び家族端末９を備える。施設２内の各装置、管理センタ８の各装置、及び家族端末９は、無線又は有線のネットワーク７（ＬＡＮ（Local Area Network）、インターネット、専用線等）を介して接続され、互いにデータの送受信が可能である。

施設２は、専有部３、ルータ５、管理者端末６を備える。専有部３は、施設２で生活する居住者（ユーザの一例）毎に割り当てられた居室であり、居住者が専有している。専有部３は、例えば、２０１号室、２０２号室のように識別される。

そして、専有部３は、それぞれ専有部コントローラ３１、電力計測部３２（エネルギー計測部の一例）、変流器（ＣＴ：Current Transformer）３３、居住者端末３４を備える。専有部コントローラ３１は、専有部３に対応して設けられる。そして、専有部コントローラ３１は、電力計測部３２が計測した専有部３の電気使用量と、専有部３における居住者の在室又は不在を示す在室判定結果とを、ルータ５及びネットワーク７を介してアプリケーションサーバ８１に通知する。

図１において電力計測部３２は、専有部コントローラ３１に内蔵されているが、専有部コントローラ３１から分離されていてもよい。この場合、電力計測部３２を専有部３に設けておき、専有部コントローラ３１を管理センタ８に設けてもよい。

電力計測部３２は、専有部３内の電力計測ポイントに設置されたＣＴ３３から入力する小電流の電流値を計測し、この電流値を所定倍する演算を行って、ＣＴ３３で使用される消費電力量を求める。そして、電力計測部３２は、専有部３毎かつ単位時間（例えば、３０分間）毎の電気使用量を算出する。この電気使用量としては、季節変動の影響を受ける家電製品（例えば、空調機、給湯器）の消費電力量は除かれ、季節変動の影響を受けない家電製品（例えば、照明器具）の消費電力量が加味される。これによりアプリケーションサーバ８１は、居住者の生活パターンの変化を正確に把握することができる。そして、専有部コントローラ３１は、各ＣＴ３３の単位時間毎の電気使用量と、在室判定部４の在室判定結果とをルータ５、ネットワーク７を介してアプリケーションサーバ８１に送る。なお、季節変動の影響を受ける家電製品の消費電力量を除く処理は、専有部コントローラ３１で行ってもよいし、アプリケーションサーバ８１で行ってもよい。

変流器３３は、例えば、専有部３内の不図示のコンセントの内側に設けられており、電力計測部３２に対して導線によって接続されている。変流器３３は、コンセントから電力供給を受ける家電製品が使用されたときに導線を流れる電流を小電流に変換して電力計測部３２に送る。

また、専有部３内には、例えば、人の動きを検知する動体センサ（不図示）や電気錠が設けられている。そして、在室判定部４は、動体センサや電気錠からデータを収集し、在室判定結果を専有部コントローラ３１に送る。なお、在室判定部４は、専有部３内に設けられたカメラが撮像した画像から居住者の在室又は不在を判定することもできる。

居住者端末３４は、居住者自身の体調変化を知らせる表示項目（後述する図８を参照）を表示する。居住者は、居住者端末３４の表示内容を確認することで、居住者自身の体調変化を知ることができる。居住者端末３４としては、例えば、インターフォンが用いられる。

ルータ５は、専有部コントローラ３１及び管理者端末６がネットワーク７を介して管理センタ８に接続するための中継装置として用いられる。

管理者端末６は、管理画面（後述する図１３を参照）を表示する。管理者端末６を操作する施設管理者（本実施の形態例では介護事業者）は、管理者端末６に表示された情報に基づいて専有部３内の居住者の生活パターンに異常が発生したかどうか判断することができる。

管理センタ８は、アプリケーションサーバ８１、管理データベース８２、Ｗｅｂサーバ８３、管理者端末８４を備える。管理センタ８は、専有部３毎に居住者の生活パターンを管理し、居住者の生活パターンの変化により居住者の体調変化を推測する。

アプリケーションサーバ８１は、ネットワーク７を介して専有部コントローラ３１から通知された在室判定結果が専有部３に居住者が在室していることを示す場合に、居住者の生活パターンの変化を求める処理を行う。この処理は、特定時間帯における専有部３の電気使用量と、特定期間かつ特定時間帯（後述する図６を参照）に対応して単位時間毎に作成された電気使用量の確率密度関数（後述する図４を参照）に示される電気使用量の最頻値との乖離量に基づいて行われる。そして、アプリケーションサーバ８１は、専有部３の生活パターンを管理するための家族端末９、居住者端末３４、管理者端末８４に居住者の生活パターンの変化に基づく情報を知らせる。

管理データベース８２は、不図示の様々なテーブル（例えば、施設テーブル、専有部テーブル、居住者テーブル等）を備える。そして、アプリケーションサーバ８１が作成した確率密度関数、専有部３における単位時間毎の電気使用量といったデータを蓄積する。

Ｗｅｂサーバ８３は、管理データベース８２から読み出したデータに基づいて、発報部８１ｄが警報を発報した異常の履歴を含む管理画面を作成する。この管理画面は、管理者端末６、８４に表示される。

管理者端末８４は、アプリケーションサーバ８１に接続される。この管理者端末８４は、例えば、施設２内で施設管理者を置かない場合に、管理センタ８内のセンタ管理者が専有部３内の居住者の生活パターンに異常が発生したかどうかを判断するために用いられる。管理者端末８４にも、Ｗｅｂサーバ８３が作成した管理画面の表示が可能である。
以下の説明にて、施設管理者とセンタ管理者を区別しない場合には、「管理者」と総称する。

家族端末９は、例えば、居住者の家族によって所持される。アプリケーションサーバ８１が、居住者の体調変化が異常であると判定すると、家族端末９に通報メールを送信する。家族端末９を操作する家族は、受信した通報メールにより、居住者の体調変化を確認することができる。

＜アプリケーションサーバ及び管理データベースの構成例＞
図２は、アプリケーションサーバ８１及び管理データベース８２の内部構成例を示す。

アプリケーションサーバ８１は、電気使用量取得部８１ａ（エネルギー使用量取得部の一例）、確率密度関数作成部８１ｂ、異常判定部８１ｃ、発報部８１ｄを備える。
また、管理データベース８２は、電気使用量蓄積テーブル８２ａ、確率密度関数蓄積テーブル８２ｂ、異常度判定表８２ｃ、異常カウント蓄積テーブル８２ｄ、表示項目一覧表８２ｅ、発報情報蓄積テーブル８２ｆを備える。

電気使用量取得部８１ａは、専有部コントローラ３１から各専有部３における電気使用量と在室判定結果を単位時間毎に取得する。そして、電気使用量取得部８１ａは、単位時間毎に取得した電気使用量と在室判定結果を電気使用量蓄積テーブル８２ａに蓄積する。

確率密度関数作成部８１ｂは、特定期間かつ特定時間帯における単位時間当たりの電気使用量毎に確率密度関数を作成する。具体的に説明すると、確率密度関数作成部８１ｂは、電気使用量蓄積テーブル８２ａに特定期間の電気使用量が蓄積された後、例えば１月毎に電気使用量蓄積テーブル８２ａから単位時間毎の電気使用量を読み出す。そして、確率密度関数作成部８１ｂは、特定期間における単位時間当たりの電気使用量の分布に基づいて、専有部３毎かつ単位時間毎の電気使用量の発生頻度を確率密度関数として求め、確率密度関数蓄積テーブル８２ｂに確率密度関数を蓄積する。ここで、本実施の形態例では、単位時間を３０分と定めているため、１つの特定期間に対して１日（２４時間）で作成される確率密度関数の総数は４８個となる。

特定期間とは、確率密度関数作成部８１ｂが確率密度関数を作成する日から見て以下の５種類がある。
（ａ）前月１ヶ月
（ｂ）前月を含む過去３ヶ月
（ｃ）前年同月±１ヶ月の３ヶ月
（ｄ）前年までの１年
（ｅ）固定で、居住開始後の２ヶ月目〜４ヶ月目

そして、確率密度関数作成部８１ｂは、特定期間毎に確率密度関数を作成するため、単位時間毎に５種類の確率密度関数がある。このため、最終的に確率密度関数蓄積テーブル８２ｂに蓄積される確率密度関数の総数は、専有部３毎に４８×５＝２４０（個）となる。ただし、確率密度関数作成部８１ｂは、上記の５種類のいずれかを特定期間として選択して、確率密度関数を作成することもできる。

異常判定部８１ｃは、専有部３毎に確率密度関数蓄積テーブル８２ｂから読み出した確率密度関数に示される最頻値からの電気使用量の乖離量に基づいて特定時間帯における異常度を単位時間毎に求める。そして、異常判定部８１ｃは、異常度と、異常度判定表８２ｃ（後述する図６を参照）に含まれる所定の判定値との比較に基づいて居住者の生活パターンの変化に異常が発生したかどうかを判定する。異常判定部８１ｃは、生活パターンの変化に異常が発生していると判定した場合には、異常パターン毎に異常カウント蓄積テーブル８２ｄ（後述する図７を参照）に含まれる異常の発生回数を示す異常カウント数を「１」加算する。

異常判定部８１ｃが判定に用いる確率密度関数は、例えば、上述した（ａ）前月１ヶ月について確率密度関数作成部８１ｂが作成したものとなる。（ｂ）〜（ｅ）についての確率密度関数は、例えば、警報が多発したり、全く警報が発生しなかったりするため、（ａ）についての確率密度関数による判定処理の結果が妥当でない場合に、異常判定部８１ｃによって選択される。

発報部８１ｄは、異常カウント蓄積テーブル８２ｄから異常カウント数を読出し、異常パターン毎に異常カウント数が所定値に達したかどうかを判断する。そして、異常パターン毎に異常カウント数が所定値「５」に達すると、居住者の生活パターンの変化に基づく情報として、生活パターンに異常が発生したことを示す警報を発報する。この警報には、例えば、通報メールを管理者端末６、８４、家族端末９に送信すること、通報メールと同じ内容の表示項目を管理画面に表示することが含まれる。そして、発報部８１ｄは、警報を発報したことを異常判定部８１ｃに通知する。

発報部８１ｄが行う警報の発報は、異常の発生時間に関係なく、例えば、早朝、深夜を除いた８：００〜２０：００の間とする。通報メールに表示される項目は、表示項目一覧表８２ｅ（後述する図８を参照）に基づいて定められる。この通報メールのタイトル及び文頭には、専有部３の部屋番号が付されている。このため管理者及び家族は、居住者の生活パターンに異常が発生しているかを知ることができる。そして、通報メールを受信した管理者（主に施設管理者）は、居住者と面談等を行って、居住者の健康状態を管理する。

発報情報蓄積テーブル８２ｆは、発報部８１ｄが発報した警報の発報情報が発報日時、居室番号、体調変化の内容として蓄積される。Ｗｅｂサーバ８３は、発報情報蓄積テーブル８２ｆを検索して、管理画面（後述する図１３を参照）を作成する。

＜計算機のハードウェア構成例＞
次に、生活パターン管理システム１の各装置を構成する計算機１０のハードウェア構成を説明する。
図３は、計算機１０のハードウェア構成例を示すブロック図である。

計算機１０は、いわゆるコンピュータとして用いられるハードウェアである。計算機１０は、バス１４にそれぞれ接続されたＣＰＵ（Central Processing Unit：中央処理装置）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３を備える。さらに、計算機１０は、表示部１５、操作部１６、不揮発性ストレージ１７、ネットワークインタフェース１８とを備える。

ＣＰＵ１１は、本実施の形態例に係る各機能を実現するソフトウェアのプログラムコードをＲＯＭ１２から読み出して実行する。ＲＡＭ１３には、演算処理の途中に発生した変数やパラメータ等が一時的に書き込まれる。ＣＰＵ１１により、例えば、管理者端末６、８４、家族端末９、専有部コントローラ３１、アプリケーションサーバ８１、Ｗｅｂサーバ８３の各機能が実行される。

表示部１５は、例えば、液晶ディスプレイモニタであり、計算機１０で行われる処理の結果等を表示する。操作部１６としては、例えば、キーボード、マウス等が用いられ、この操作部１６から管理者等が所定の操作入力、指示を行うことが可能である。表示部１５、操作部１６は、管理者端末６、８４、家族端末９、専有部コントローラ３１、アプリケーションサーバ８１、Ｗｅｂサーバ８３が有している。

不揮発性ストレージ１７には、例えば、ＨＤＤ（Hard disk drive）、フレキシブルディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード等が用いられる。この不揮発性ストレージ１７には、ＯＳ（Operating System）、各種のパラメータの他に、計算機１０を機能させるためのプログラムが記録されている。不揮発性ストレージ１７は、専有部コントローラ３１、管理者端末６、８４、家族端末９、アプリケーションサーバ８１、Ｗｅｂサーバ８３が備えている。また、管理データベース８２は、例えば、ＲＤＢＭＳ（Relational Data Base Management System）を用いた構成により不揮発性ストレージ１７に構築されている。

ネットワークインタフェース１８には、例えば、ＮＩＣ（Network Interface Card）等が用いられ、端子が接続されたネットワーク７を介して各種のデータを送受信することが可能である。ネットワークインタフェース１８は、専有部コントローラ３１、管理者端末６、８４、家族端末９、アプリケーションサーバ８１、Ｗｅｂサーバ８３が有している。

＜確率密度関数及び異常度判定の説明＞
次に、確率密度関数及び異常度判定の方法について、図４〜図１０を参照して説明する。
図４は、確率密度関数の例を示す。

確率密度関数は、確率密度関数作成部８１ｂが電気使用量蓄積テーブル８２ａから読み出した特定期間における単位時間当たりの電気使用量の分布をガンマ分布に近似させるフィッティング処理（例えば、最尤法）により作成したものである。ここで、電気使用量の標準データを最頻値Ｘ_ｓｔｄとする。そして、最頻値Ｘ_ｓｔｄにおいて確率密度関数の頂点が定まり、最頻値Ｘ_ｓｔｄの確率密度関数に対応する確率密度Ｐ_ＳＴＤが求まる。

次に、異常判定部８１ｃは、電気使用量取得部８１ａから入力した単位時間当たりの実際の電気使用量Ｘと、電気使用量Ｘの確率密度関数に対応する確率密度Ｐ_Ｘを求める。図４の例では、実際の電気使用量Ｘが最頻値Ｘ_ｓｔｄよりも大きいことが示される。

そして、異常判定部８１ｃは、確率密度Ｐ_Ｘ、最頻値の確率密度Ｐ_ＳＴＤ、電気使用量Ｘ、電気使用量の最頻値Ｘ_ｓｔｄを次式（１）に当てはめて異常度を求める。

式（１）で求めた異常度には、正負いずれかの符号が含まれる。ここで、異常度に含まれる符号の意味について説明する。
図５は、異常度の正負の内容を示す一覧表である。

電気使用量Ｘが最頻値Ｘ_ｓｔｄ以上であれば、異常度の符号は正となる。図４及び図５には、異常度の符号が正となる箇所に［１］と示した。
一方、電気使用量Ｘが最頻値Ｘ_ｓｔｄに満たなければ、異常度の符号は負となる。図４及び図５には、異常度の符号が負となる箇所に［２］と示した。

異常度の符号は、各専有部３の居住者の電気使用量が、普段の電気使用量より多い（＋）、又は少ない（−）ことを示している。なお、異常度の符号が正負のいずれであるかは、次に説明する異常度判定にも関係する。

次に、管理データベース８２が管理するテーブルの一部と、表の構成例を図６〜図８を参照して説明する。

図６は、異常度判定表８２ｃを示す。
異常度判定表８２ｃには、所定の判定値として、特定時間帯における上限判定値及び下限判定値が設けられている。そして、異常度判定表８２ｃには、異常度が上限判定値を超えた場合、又は異常度が下限判定値に満たない場合に該当する異常パターンが規定されている。なお、上限判定値又は下限判定値のいずれかに「−（ハイフン）」が含まれていると、異常度が上限判定値を超えた場合、又は下限判定値に満たない場合のいずれも警報の発報対象とならないことを表す。異常度判定表８２ｃには、例えば、昼間（１１：００〜２０：００）には下限判定値だけが設けられ、深夜（２２：３０〜５：００）には上限判定値だけが設けられている。昼間は居住者の活動が活発であり、深夜は居住者が睡眠をとることで居住者の活動が低下しているのが一般的であるためである。

そして、異常判定部８１ｃは、特定時間帯における単位時間毎の異常度が、特定時間帯における上限判定値を超過し、又は下限判定値に満たない場合に異常の内容を示す異常パターン毎に異常カウント数を加算する。そして、異常判定部８１ｃは、異常カウント数を加算している途中で、正常と判定した回数が所定数（例えば、「４」）だけ連続した場合、又は発報部８１ｄから異常の発生を発報したことの通知を受けた場合に、異常カウント数を「０」にリセットする。

上限判定値及び下限判定値の選定は居住者がどのような生活パターンであるかによって変わりうる。異常判定部８１ｃが、例えば、居住者が標準データで示される時間よりも３０分早く起床した場合に異常と判定するか、又は２時間早く起床した場合に異常と判定するかは施設２毎に異なる場合が多い。このため、異常度判定表８２ｃの内容は、管理者端末６又は８４によって変更可能である。

図７は、異常カウント蓄積テーブル８２ｄを示す。
異常カウント蓄積テーブル８２ｄは、居室番号フィールド、異常パターンフィールド、異常カウント数フィールドを備える。

居室番号フィールドには、専有部３を特定するために、例えば、「２０１」、「２０２」といった居室番号が格納される。
異常パターンフィールドには、図６の異常度判定表８２ｃ、及び図８の表示項目一覧表８２ｅに示される各異常パターンが居室番号毎に格納される。
異常カウント数フィールドには、異常判定部８１ｃが異常判定を行って、異常度が異常パターンに該当する場合に、異常判定部８１ｃが加算した異常カウント数が格納される。本実施の形態例において、異常カウント数は、「０」〜「５」までの値を取り得る。そして、異常カウント数は、専有部３毎、かつ異常パターン毎に異常判定部８１ｃによって加算される。

図８は、表示項目一覧表８２ｅを示す。
表示項目一覧表８２ｅは、異常パターンフィールド、異常を発報する際の表示項目フィールドの各項目を備える。

異常度判定表８２ｃにおいて、例えば、「０：００〜５：００」の間は居住者の就寝時間に該当し、電気使用量もわずかである。しかし、異常度が上限判定値「０．８」を超えていれば、居住者が起きて照明を点け、何らかの活動をしていると考えられる。この場合、異常パターン（１）に該当し、「深夜、夜間の活動が増えています。」という表示項目が警報の発報対象となる。

なお、発報部８１ｄは、異常パターン（１）に該当しても直ちに警報を発報するわけではない。発報部８１ｄは、後述する図９と図１０に示す処理を経て、例えば連続して５日以上異常パターン（１）に該当した場合に、警報を発報することとなる。このことは、他の異常パターンについても同様である。

異常度判定表８２ｃの別の時間帯について説明を行う。例えば、「５：００〜９：３０」の間は居住者の起床時間に該当し、電気使用量も増え始める。しかし、電気使用量が多すぎれば、居住者は普段よりも早く起きて活動を開始していると考えられる。この場合、異常パターン（２−１）に該当し、「起床時間が早くなっています。」という表示項目が警報の発報対象となる。

一方、「５：００〜９：３０」の間でも電気使用量が少なすぎれば、居住者の起床時間が普段より遅くなっていると考えられる。この場合、異常パターン（２−２）に該当し、「起床時間が遅くなっています。」という表示項目が警報の発報対象となる。

また、「９：３０〜２２：３０」の間で異常度が下限判定値に満たなければ、居住者はあまり活動していないと考えられる。この場合、異常パターン（３）に該当し、「活動レベルが低下しています。」という表示項目が警報の発報対象となる。

また、「２０：００〜２４：００」の間で異常度が上限判定値を超えていれば、夜間にも関わらず居住者は活発に活動していると考えられる。この場合、異常パターン（４）に該当し、「就寝時間が変化しています。」という表示項目が警報の発報対象となる。

図９は、異常判定部８１ｃが行う異常判定処理と発報部８１ｄが行う発報処理の例を示す。

始めに、異常判定部８１ｃは、電気使用量取得部８１ａが専有部コントローラ３１から取得した在室判定結果に基づいて、居住者が専有部３に在室しているかどうかを判断する（Ｓ１）。異常判定部８１ｃは、居住者が専有部３に不在であれば異常判定処理を終了する。

一方、居住者が在室していれば、異常判定部８１ｃは、上式（１）及び図４の確率密度関数を用いて異常度を求め、図６の異常度判定表８２ｃに基づいて、異常度が異常パターンに該当するかどうかを判定する。そして、異常判定部８１ｃは、異常度が異常パターンに該当すれば、この異常パターンの異常カウント数を「１」加算する（Ｓ２）。

次に、発報部８１ｄは、異常カウント蓄積テーブル８２ｄから読み出した、同一の異常パターン（図８を参照）毎の異常カウント数が所定値「５」に達したかどうかを判定する（Ｓ３）。この所定値「５」は、例えば、４日前から現在日まで５日連続で同一の異常パターンによる異常が発生したことを意味する。ステップＳ３における異常カウント数の判定処理は後述する（図１０を参照）。

発報部８１ｄは、ステップＳ３にて異常カウント数が所定値「５」に達していないと判定すると、異常判定処理を終了する。一方、発報部８１ｄは、異常カウント数が所定値「５」に達したと判定すると、警報を発報する（Ｓ４）。発報部８１ｄが発報する通報メールの先頭（例えば、通報メールのタイトル及びメール本文）には、専有部３の部屋番号と、図８に示す表示項目を含む発報情報が付される。そして、発報部８１ｄは、発報情報を発報情報蓄積テーブル８２ｆに書き込み、発報したことを異常判定部８１ｃに通知する。これにより、異常判定部８１ｃは、発報された異常パターンの異常カウント数をリセットする。

図１０は、異常又は正常と判定された日のカウントパターン毎に発報部８１ｄがどのようにして発報の判断を行うかを示す一覧表である。

この一覧表では、異常判定部８１ｃが、居住者の生活パターンの変化を異常パターン毎に異常又は正常と判定した日の並びがカウントパターンとして示されている。すなわち、異常判定部８１ｃが異常と判定した日は黒丸で示され、異常判定部８１ｃが正常と判定した日は白丸で示される。

例えば、異常判定部８１ｃが異常パターン（１）を判定した場合に、異常カウント数を「１」加算する。また、異常判定部８１ｃが同日に異常パターン（２−１）、（３）を判定した場合には、異常判定部８１ｃが各異常パターンについてそれぞれ異常カウント数を「１」加算する。

なお、異常判定部８１ｃが異常パターン（１）の異常カウント数を判定した時間帯とは異なる時間帯に再び異常パターン（１）を判定する場合がある。しかし、異常判定部８１ｃは、異常パターン（１）の異常カウントを判定した日が同日であれば、この異常パターン（１）に対する異常カウント数を加算しない。これは複数の時間帯にわたって同じ異常パターンの異常カウント数を何度も加算しても、居住者の長期的な生活パターンの管理には不要となるからである。

次に、カウントパターン（ｂ）〜（ｄ）は、それぞれ異常判定部８１ｃが異常パターン（１）の異常カウント数を２〜４日にわたり「１」ずつ連続して加算したことを示す。この場合、発報部８１ｄは警報を発報しない。
しかし、カウントパターン（ｅ）は、異常判定部８１ｃが異常パターン（１）の異常カウント数を５日にわたり「１」ずつ連続して加算したことを示す。本実施の形態例では、異常カウント数が所定数「５」に達すると、発報部８１ｄが警報を発報する。

また、カウントパターン（ｆ）は、異常判定部８１ｃが異常パターン（１）の異常カウント数を４日にわたり「１」ずつ連続して加算した後、３日間の正常判定が連続し、再び異常パターン（１）の異常カウント数を「１」加算したことを示す。この場合、異常カウント数はリセットされない状態で所定数「５」に達する。このため、発報部８１ｄが警報を発報する。なお、１日間、２日間の正常判定が連続した場合も異常カウント数はリセットされない。

一方、カウントパターン（ｇ）は、異常判定部８１ｃが異常パターン（１）の異常カウント数を４日にわたり「１」ずつ連続して加算した後、４日間の正常判定が連続し、再び異常パターン（１）の異常カウント数を「１」加算したことを示す。この場合、異常判定部８１ｃが生活パターンを正常と判定した日が４日間続いているので、異常判定部８１ｃは異常パターン（１）の異常カウント数を「０」にリセットする。このため、再び加算された異常パターン（１）の異常カウント数は「１」であり、発報部８１ｄは警報を発報しない。

なお、カウントパターン（ｅ）、（ｆ）に示したように発報部８１ｄが警報を発報すると、発報部８１ｄは、発報した異常パターンに該当する異常カウント数をリセットし、異常カウント数を「０」とする。このため、発報部８１ｄは、同じ専有部３にて同じ異常パターンによる発報を連日行うことはない。

次に、家族端末９、居住者端末３４、管理者端末６、８４に表示される発報内容の表示画面の構成例について、図１１〜図１３を参照して説明する。

図１１は、家族端末９に発報される通報メールの表示例を示す。
アプリケーションサーバ８１は、通報メールを送信することで、発報部８１ｄが発報した居住者の生活パターンの変化に基づく情報として生活パターンに異常が発生したことを、居住者の家族が使用する家族端末９に表示させる。この通報メールのメール本文には、例えば、「夜間の電気使用量が増えています。」といった体調変化を示す表示項目が表示される。なお、通報メールのタイトルには、居住者の住居番号が記載されている（不図示）。

図１２は、居住者端末３４に発報される通報内容の表示例を示す。
居住者端末３４には、居住者自身の体調変化が表示される。例えば、「夜間の電力使用量が増えています。」といった表示内容と共に、「就寝時間帯（０：００〜５：００）における電力使用量が５日連続で高い状態が続いています。」といった発報根拠が示される。

図１３は、管理者端末６、８４に表示される管理画面の例を示す。
この管理画面は、発報日時の入力ボックス、居室番号の選択ボックスを備える。これらのボックスは、管理者が検索に用いる項目を具体的に指定するために用いられる。そして、管理者が検索ボタンの押下操作を行うと、Ｗｅｂサーバ８３が管理データベース８２から検索した該当レコードが管理画面に表示される。

この例では、発報日時として「２０１４年８月１日０時００分〜２０１４年８月７日１５時００分」の検索期間が指定されており、居室番号としてスペース、すなわち全ての居室番号が指定されている。そして、検索結果として、発報日時、居室番号、体調変化の内容が時系列表示されている。

なお、画面下部には、鳴動停止ボタンと発報詳細ボタンが設けられる。
鳴動停止ボタンは、管理画面に新たな警報が発生した場合に管理者に注意を促すためのブザー等による鳴動を停止するためのボタンである。
発報詳細ボタンは、例えば、警報が発生した居住者に対して管理者が面談等の対処を行ったことをコメントとして残すためのコメント入力画面を呼び出すボタンである。

以上説明した第１の実施の形態例に係るアプリケーションサーバ８１は、確率密度関数に示される専有部３毎の最頻値からの電気使用量がどれだけ乖離しているかに基づいて居住者の長期的な生活パターンに対する変化の異常を判定することができる。このため、アプリケーションサーバ８１は、特定時間帯の単位時間毎に居住者の電気使用量が標準的な電気使用量から離れすぎている場合には、異常発生を管理者に発報することができる。そして、管理者は、異常発生が通報された居住者に重点的に対処することで、多数の居住者を管理するための負担が軽減される。

ここで、確率密度関数作成部８１ｂは、特定期間における単位時間当たりの電気使用量に基づき特定時間帯毎に確率密度関数を作成している。このようにして作成された確率密度関数は万人向けではなく、個々の居住者の生活パターンに合わせたものとなる。このため、異常判定部８１ｃは、居住者の普段の生活パターンとは異なる生活パターンを速やかに異常と判定することが可能となる。

また、電気使用量取得部８１ａが複数の時間帯にわたる複数の電気使用量を一度に取得しても、異常判定部８１ｃは、最新の電気使用量に基づいて異常度の判定を行う。このため、生活パターンの変化に異常が発生した場合には、発報部８１ｄが速やかに警報を発報することができる。

また、電気使用量取得部８１ａは、膨大な単位時間当たりの電気使用量及び在室判定結果を取得して電気使用量蓄積テーブル８２ａに蓄積している。そして、確率密度関数作成部８１ｂは、電気使用量蓄積テーブル８２ａから読み出した膨大な電気使用量及び在室判定結果に基づいて、専有部３毎に特定期間かつ特定時間帯毎に単位時間当たりの確率密度関数を作成している。このようにアプリケーションサーバ８１は、膨大な量のデータ（いわゆるビッグデータ）を、確率密度関数を作成するための元データとして取り扱うことにより、居住者毎に詳細な生活パターンを把握することが可能となり、生活パターンの変化が捉えやすくなる。

なお、専有部３から居住者が退去するときには、施設管理者が管理者端末６を操作して居住者が退去したことを電気使用量取得部８１ａに通知する。この通知により、電気使用量取得部８１ａは、居住者が退去した日から該当する専有部３における電気使用量の取得処理を終了する。そして、確率密度関数作成部８１ｂは、確率密度関数蓄積テーブル８２ｂから居住者が退去した専有部３について作成していた確率密度関数を削除する。そして、異常判定部８１ｃは、異常カウント蓄積テーブル８２ｄから全ての異常パターンの異常カウント数をリセットする。そして、発報部８１ｄは発報を停止する。なお、異常判定部８１ｃは、居住者が専有部３から退去し、長期（例えば、２０日以上）にわたって在室判定部４が不在を判定するか、電気使用量がほとんどない場合に、自動的に居住者の退去を電気使用量取得部８１ａに通知するようにしてもよい。

その後、専有部３に新たな居住者が入居したときには、施設管理者が管理者端末６を操作して専有部３に居住者が入居したことを電気使用量取得部８１ａに通知する。この通知により、電気使用量取得部８１ａは、専有部３における電気使用量及び在室判定結果の取得を開始する。そして、確率密度関数作成部８１ｂは、電気使用量取得部８１ａが電気使用量及び在室判定結果の取得を開始してから、例えば１月を経過した後、新たな確率密度関数を作成し、異常判定部８１ｃは新たな確率密度関数に基づいて生活パターンの異常発生を判定する。このため、専有部３に居住者が入居してから少なくとも１月の間は生活パターンの変化は判定されない。

［第２の実施形態例］
次に、本発明の第２の実施形態例に係る生活パターン管理システムについて説明する。
図１４は、生活パターン管理システム１Ａの内部構成例を示す。

生活パターン管理システム１Ａが上述した第１の実施形態例に係る生活パターン管理システム１と異なるところは、施設２、ルータ５及び管理者端末６が取り除かれ、専有部３が戸建てを示す専有部３Ａに変わったことである。なお、専有部３Ａは、戸建て以外の住居（マンション、アパート等）であってもよい。
また、在室判定部４は、専有部３Ａ内の部屋毎に設けられている。

各戸に設けられる専有部コントローラ３１Ａは、電力計測部３２に加えて、ガス使用量計測部３５、水道使用量計測部３６を、それぞれエネルギー計測部の一例として備える。
ガス使用量計測部３５は、ガスメータ３７に接続されており、専有部３Ａで使用するガス使用量を計測する。水道使用量計測部３６は、水道メータ３８に接続されており、専有部３Ａで使用する水道使用量を計測する。
そして、専有部コントローラ３１Ａは、電気使用量、ガス使用量、水道使用量を、ネットワーク７を介してアプリケーションサーバ８１に送る。

アプリケーションサーバ８１は、各専有部３Ａの専有部コントローラ３１Ａから取得した電気使用量、ガス使用量、水道使用量に基づき、電気、ガス、水道毎に、かつ特定時間帯毎に単位時間当たりの確率密度関数を作成する。そして、電気、ガス、水道毎に居住者の生活パターンの変化を求め、居住者の生活パターンの変化に基づく情報を家族端末９、居住者端末３４、管理者端末８４に知らせる。

以上説明した第２の実施の形態例に係る生活パターン管理システム１Ａによれば、専有部３Ａ内の部屋毎に、居住者がどのような生活パターンを持つかが管理される。そして、専有部３Ａ毎に居住者の生活パターンの変化に基づく情報が家族端末９、居住者端末３４、管理者端末８４に知らされる。このため、特定の部屋（例えば、リビング、寝室）で居住者がどのように生活しているかを把握しやすくなる。

また、電気使用量に加えて、ガス使用量、水道使用量についても管理対象とされる。これによりアプリケーションサーバ８１は、例えば、居住者が料理をしていたり、風呂に入っていたりするような生活パターンについても確実に管理することができる。このため、例えば、親にとってみれば、子どもの生活パターンの変化（帰宅時間が遅くなっていること等）を把握しやすくなる。また、独居者の家族にとってみれば、独居者の生活パターンの変化（夜間に活動していること等）を把握しやすくなる。

［変形例］
また、居住者の生活パターンの特性によっては、同じ異常パターンによる警報が多発しても、実際には居住者の体調変化が正常と判定して差し支えない場合がある。この場合には、管理者が管理者端末６、８４を操作して、一部の異常パターンについては異常カウント数の加算対象から除く設定を行うことが可能である。

また、図９に示した処理フローは、全ての施設２について共通して用いられる。一方、各テーブル、各表は、施設２毎に異なる内容で用いてもよい。これにより施設２の特性に応じて適切な内容の通報を行うことが可能となる。

また、アプリケーションサーバ８１は、ＣＴ３３や専有部コントローラ３１が故障すると、故障した時間を含む時間帯の電気使用量、在室判定結果を専有部コントローラ３１から取得できない。このため、この時間帯における電気使用量は欠損データとして扱い、異常判定には用いないものとする。ただし、専有部コントローラ３１は、過去１月程度の電気使用量及び在室判定結果を蓄積可能である。このため、ＣＴ３３や専有部コントローラ３１が故障から復旧した後、アプリケーションサーバ８１が電気使用量、在室判定結果を取得できれば、アプリケーションサーバ８１は、改めて異常判定を行ってもよい。

また、異常判定部８１ｃが図９のステップＳ３で異常カウント数の比較に用いる所定値は、「５」以外の任意の値を取り得る。また、異常カウント数を「０」にリセットするタイミングについても任意とすることが可能である。さらに、居住者の特性に合わせて、居住者毎又は異常パターン毎に、所定値の値、異常カウント数をリセットするタイミングを変えてもよい。

また、アプリケーションサーバ８１が管理するエネルギー使用量としては、ガス又は水道のいずれか一つであってもよいし、電気、ガス、水道のいずれかの組合せであってもよい。

また、居住者端末３４、管理者端末６、８４、家族端末９は、いわゆるパーソナルコンピュータ装置を用いるだけでなく、タブレット端末、フィーチャーフォン、ページャー等の様々なものにより、その機能を実現させることが可能である。

なお、本発明は上述した実施の形態例に限られるものではなく、特許請求の範囲に記載した本発明の要旨を逸脱しない限りその他種々の応用例、変形例を取り得ることは勿論である。
例えば、上述した実施の形態例は本発明を分かりやすく説明するために装置及びシステムの構成を詳細且つ具体的に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることは可能であり、更にはある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加、削除、置換をすることも可能である。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。

１…生活パターン管理システム、３…専有部、４…在室判定部、６…管理者端末、８…管理センタ、９…家族端末、３１…専有部コントローラ、３２…電力計測部、３３…変流器、３４…居住者端末、８１…アプリケーションサーバ、８２…管理データベース、８３…Ｗｅｂサーバ、８４…管理者端末

Claims (11)

1. 居住者が専有する専有部に対応して設けられる専有部コントローラと、前記居住者の生活パターンを管理するアプリケーションサーバと、を備え、
   前記専有部コントローラは、
   エネルギー計測部が計測した前記専有部で使用されるエネルギーのエネルギー使用量と、前記専有部に前記居住者が在室又は不在であることを示す在室判定結果とを前記アプリケーションサーバに通知し、
   前記アプリケーションサーバは、
   前記専有部コントローラから通知された前記在室判定結果が前記専有部に居住者が在室していることを示す場合に、特定時間帯における前記専有部の前記エネルギー使用量と、特定期間かつ前記特定時間帯に対応して単位時間毎に作成された前記エネルギー使用量の確率密度関数に示される前記エネルギー使用量の最頻値との乖離量に基づいて前記居住者の生活パターンの変化を求め、前記専有部の生活パターンを管理するための管理者端末に前記居住者の生活パターンの変化に基づく情報を知らせる
   生活パターン管理システム。
2. 前記アプリケーションサーバは、
   前記エネルギー計測部が計測した単位時間当たりの前記エネルギー使用量、及び前記在室判定結果を前記専有部コントローラから取得するエネルギー使用量取得部と、
   前記特定期間かつ前記特定時間帯における前記単位時間当たりの前記エネルギー使用量毎に前記確率密度関数を作成する確率密度関数作成部と、
   前記専有部毎に前記乖離量に基づいて前記特定時間帯における異常度を求め、前記異常度と所定の判定値との比較に基づいて前記居住者の生活パターンの変化に異常が発生したことを判定すると、前記異常の発生回数を示す異常カウント数を加算する異常判定部と、
   前記異常カウント数が所定値に達すると、前記居住者の生活パターンの変化に基づく情報として前記生活パターンに異常が発生したことを発報する発報部と、を備える
   請求項１に記載の生活パターン管理システム。
3. 前記確率密度関数作成部は、前記特定期間における前記単位時間当たりの前記エネルギー使用量の分布をガンマ分布に近似させて前記確率密度関数を作成する
   請求項２に記載の生活パターン管理システム。
4. 前記所定の判定値として、前記特定時間帯における上限判定値及び下限判定値が設けられ、
   前記異常判定部は、前記特定時間帯における前記異常度が、前記特定時間帯における前記上限判定値を超過し、又は前記下限判定値に満たない場合に前記異常の内容を示す異常パターン毎に前記異常カウント数を加算し、
   前記発報部は、前記異常パターン毎に前記異常の回数が前記所定値に達したかどうかを判断する
   請求項２に記載の生活パターン管理システム。
5. 前記異常判定部は、前記異常カウント数を加算している途中で、正常と判定した回数が所定数だけ連続した場合、又は前記発報部から前記異常の発生を発報したことの通知を受けた場合に、前記異常カウント数をリセットする
   請求項４に記載の生活パターン管理システム。
6. 前記異常判定部は、前記特定時間帯毎に前記単位時間当たりのエネルギー使用量Ｘ、前記エネルギー使用量の最頻値Ｘ_ｓｔｄ、前記エネルギー使用量Ｘの前記確率密度関数に対応する確率密度Ｐ_Ｘ、前記最頻値Ｘ_ｓｔｄの前記確率密度関数に対応する確率密度Ｐ_ＳＴＤを式（１）に当てはめて前記異常度を求める
   

   

   請求項２に記載の生活パターン管理システム。
7. 昼間には前記下限判定値だけが設けられ、深夜には上限判定値だけが設けられる
   請求項４に記載の生活パターン管理システム。
8. さらに、前記発報部が発報した前記異常の履歴を含む管理画面を作成するＷｅｂサーバを備え、
   前記管理者端末は、前記管理画面を表示する
   請求項２に記載の生活パターン管理システム。
9. さらに、前記発報部が発報した前記居住者の生活パターンの変化に基づく情報として前記生活パターンに異常が発生したことを、前記居住者の家族が使用する家族端末に表示させる
   請求項２に記載の生活パターン管理システム。
10. 前記エネルギーは、電気、ガス、水道のいずれか一つ、又はいずれか若しくは全ての組合せである
    請求項１に記載の生活パターン管理システム。
11. 居住者が専有する専有部で使用されるエネルギーのエネルギー使用量と、前記専有部に前記居住者が在室又は不在であることを示す在室判定結果とを専有部コントローラから受け取り、
    前記在室判定結果が前記専有部に居住者が在室していることを示す場合に、特定時間帯における前記専有部の前記エネルギー使用量と、特定期間かつ前記特定時間帯に対応して単位時間毎に作成された前記エネルギー使用量の確率密度関数に示される前記エネルギー使用量の最頻値との乖離量に基づいて前記居住者の生活パターンの変化を求め、
    前記専有部の生活パターンを管理するための管理者端末に前記居住者の生活パターンの変化に基づく情報を知らせる
    アプリケーションサーバ。

Images