以下、図面に基づいて、本発明の実施の形態を説明する。本実施形態に係る在宅/不在判定処理は、ユーザにできるだけ意識されないように、消費電力量の時間変化と電気機器の稼働状態とに基づいて、ユーザが在宅しているか判定する。以下に述べる各テーブルの内容、閾値などは可変に設定可能である。
図1は、本実施形態に係る在宅判定システム1の全体概要を示す。在宅判定システム1は、ユーザの住宅2、つまり家庭用需要家2と通信可能に接続されている。さらに、在宅判定システム1は、サービス契約会社のコンピュータシステム3や情報配信サーバ4(いずれも図2参照)にも通信可能に接続されている。図中では、「総合判定部」を「総合判定」と示すように「部」の記載を省略する場合がある。
在宅判定システム1は、判定方法の異なる複数の在宅判定部112A,112B,113を適宜結合させることで、ユーザの住宅2が在宅状態であるか判定する。総合判定部114は、消費電力量用在宅判定部111と、特定機器用在宅判定部112Aと、その他機器用在宅判定部112Bと、環境センサ用在宅判定部113との、それぞれの判定結果を考慮して、ユーザの在宅可能性を判定する。図2で述べる在宅/不在判断部110は、各判定部111,112A,112B,113,114を含む。後述の実施例では、消費電力量用在宅判定部111の行う処理を第1の判定処理と呼び、特定機器用在宅判定部112Aおよびその他機器用在宅判定部112Bの行う処理を第2の判定処理と呼ぶ。
「第1在宅判定部」としての消費電力量用在宅判定部111は、ユーザの住宅2の消費電力量の時間変化に基づいて、ユーザの在宅/不在を判定する。住宅2の消費電力量の時間変化D1は、住宅2のブレーカ21内に設けられた電流センサ22からの検出信号から取得することができる。電流センサ22は、住宅2内の各電気機器20に流れる電流値を直接計測するのではなく、全ての電気機器20の消費電流の合計である根幹の電流値を計測して在宅判定システム1へ送信する。
波形解析部190は、電流センサ22により測定した消費電力量の時間変化D1を解析することで、電気機器20の稼動に対応する波形D2,D3を抽出する。波形D2は、住宅2に設置された電気機器のうちユーザの在宅可能性との関連が高いとして事前に指定された特定機器20Aの稼動状態を表す。波形D3は、特定機器20A以外のその他機器20Bの稼動状態を表す。特定機器20Aとその他機器20Bを区別しない場合、電気機器20と呼ぶ。
波形解析部190は、在宅判定システム1内に設けてもよいし、在宅判定システム1とは別のシステムとして構成してもよい。つまり、在宅判定システム1は、住宅2の消費電力量の時間変化を解析する波形解析サービス業者から波形の解析結果を取得することもできる。
特定機器用在宅判定部112Aは、特定機器20Aの稼動状態を示す波形D2に基づいて、ユーザの在宅/不在を判定する。その他機器用在宅判定部112Bは、その他機器20Bの稼動状態を示す波形D3に基づいて、ユーザの在宅/不在を判定する。特定機器用在宅判定部112Aとその他機器用在宅判定部112Bとは、「第2在宅判定部」に該当する。
環境センサ用在宅判定部113は、ユーザの住宅2に設置されている環境センサ23の検出信号に基づいて、ユーザの在宅/不在を判定する。環境センサ23は、ユーザの住宅2の住宅環境に関する情報を測定して出力する。住宅環境としては、例えば、温度、湿度、照度、音、二酸化炭素濃度(CO2濃度)、赤外線、気圧などがある。詳しくは、例えば、室温、外気温、住宅2の内外の湿度、住宅2の内外の照度、住宅2内のCO2濃度、住宅2内のユーザ等の発熱源から放射される赤外線の強さ、住宅2内の気圧などのうち少なくとも一つを環境センサ23で検出する。
なお、環境センサ23は、必ずしも判定対象の住宅2に設置されている必要はない。環境センサ用在宅判定部113は、目的の住宅2とは別の場所に設置された環境センサを利用することで、目的の住宅2の在宅/不在を判定することもできる。例えば、目的の住宅2の外部の温度(外気温)や湿度、照度といった情報は、住宅2の近所に設置された別のセンサからの情報で推測することができる。また、環境センサ用在宅判定部113は、目的の住宅2の天候などについては、目的の住宅2の環境センサ23に頼らずに、気象データを配信するサーバから取得することもできる。
各在宅判定部111,112A,112B,113で使用する判定用のパラメータは、それぞれ複数ずつ用意することができる。パラメータ管理部120は、在宅判定部ごとに予め用意されたパラメータセット121を、所定の情報にしたがって選択する。選択されたパラメータセット121は、対応する在宅判定部へ送られる。
パラメータセット121を切り替えるための所定の情報としては、例えば、年月日や曜日などの時間情報、ユーザの家族構成や生活パターンなどの生活環境情報、気温や湿度、気圧などの居住環境情報がある。
パラメータ管理部120は、カレンダ160から年月日や曜日、祝祭日情報、時刻といった時間情報を取得することができる。パラメータ管理部120は、在宅判定システム1の外部に位置する情報配信サーバ4から天候や災害などの気象情報や、最寄り駅での乗降客数の変化などを取得することができる。
ここで、季節が異なれば、消費電力量の時間変化のパターンも変化する。天候が異なっても、消費電力量の時間変化のパターンは変化する。家族構成、いわゆる昼型か夜型か、平日勤務か休日勤務か、昼型か夜型かといった生活環境によっても、消費電力量の時間変化のパターンは変化する。同様に、季節、天候、曜日、時間、家族構成、生活パターンなどの時間情報、生活環境情報、居住環境情報によって、電気機器20の稼動パターンも変化する。
顧客情報151Aは、図2で後述する第1データベース151に含まれるデータの例であり、顧客としてのユーザの家族構成などを管理する。
判定履歴152Aは、図2で後述する第2データベース152に含まれるデータの例であり、総合判定部114の判定結果の履歴を管理する。
本実施形態のパラメータ管理部120は、種々のケースに対応すべく、予め複数のパラメータセット121を保持している。パラメータ管理部120は、上述のように、時間情報、生活環境情報、居住環境情報にしたがってパラメータセット121を選択し、在宅判定部へ設定する。パラメータ管理部120は、判定履歴152Aも考慮してパラメータセット121を選択することもできる。
なお、パラメータセットを選択するとは、あらかじめ用意された複数のパラメータセットの中からパラメータセットを選択する場合に限らず、あらかじめ用意されたパラメータセットを修正して使用する場合、あるいは所定の計算式に基づいてパラメータを生成する場合も含む。
可視化部170は、総合判定部114の判定結果を可視化して外部へ出力する。可視化部170は、「判定結果出力部」あるいは「判定結果提供部」と呼ぶこともできる。可視化部170は、例えば、ユーザの在宅可能性をランク分けまたは数値で表現して、画面出力することができる。
サービス実現部180は、可視化部170から受領するユーザの在宅可能性の判定結果を利用して、所定のサービスを提供する。所定のサービスとしては、例えば、個人ごとのまたは地域ごとの在宅可能性を提供する在宅可能性予想サービスがある。宅配業者や訪問業者、調査会社等は、在宅可能性予想サービスを利用することで、配達や訪問の効率を向上させることができる。
このように構成される本実施形態によれば、複数の在宅判定部111,112A,112B,113によってユーザの在宅可能性を判定し、それらの判定結果に基づいて総合判定部114は、ユーザが住宅2に在宅しているかを判定することができる。この結果、消費電力量だけに基づいてユーザの在宅を判定する場合に比べて、判定精度を高めることができる。
図2〜図13を用いて第1実施例を説明する。図2は、在宅判定システム1の機能ブロック図である。
在宅判定システム1は、通信ネットワークCN1を介して、各ユーザの住宅2と、情報配信サーバ4とに接続されている。在宅判定システム1は、それぞれ異なる複数の情報配信サーバ4に接続することもできる。情報配信サーバ4としては、例えば、気象情報を配信するサーバ、ニュースを配信するサーバなどがある。
さらに、在宅判定システム1は、他の通信ネットワークCN2を介して、サービス契約会社の運営するコンピュータシステム3にも接続されている。以下、サービス契約会社のコンピュータシステム3をサービス契約会社3と呼ぶことがある。図中、通信ネットワークCN1とCN2とはそれぞれ別々の通信ネットワークであるかのように示すが、共通のネットワークとして構成することもできる。
住宅2について説明する。住宅2は、それぞれ後述するように、例えば、電気機器20A,20Bと、ブレーカ21と、電流センサ22と、環境センサ23を含む。
住宅2には、例えば、エアコン、洗濯機、電子レンジ、冷蔵庫、炊飯器、テレビ、掃除機、IHクッキングヒータ、電気ポット、電気ストーブ、照明などの電気機器20が設けられている。これら電気機器20には、ユーザが在宅している可能性を判定するために使用される重みパラメータがあらかじめ設定されている。
電気機器20は、2つの種類に大別することができる。一つは、ユーザが住宅2内に存在する可能性(在宅可能性)との関連が高いと推定される特定機器20Aである。他の一つは、特定機器20A以外のその他の機器(その他機器)20Bである。
本実施例では、特定機器20Aとして電気掃除機(ユーザが手動操作するタイプ)を例に挙げて説明する。手動操作型の電気掃除機は、ユーザにより操作されるため、電気掃除機が稼動していることを検知できた場合は、ユーザが在宅している可能性が高いと考えられるためである。手動操作型の電気掃除機以外に、例えば、アイロン、電子レンジなどのユーザが手動で操作する可能性の高い電気機器を特定機器20Aとして設定することもできる。その他機器20Bには、ユーザの在宅可能性との関連が低いと推定される機器、例えば、常時稼動している電気機器、戸外のユーザが遠隔操作可能な電気機器、タイマに設定した時刻で稼動可能な電気機器がある。
住宅2には、図外の電力系統から受電した電力を住宅2内の電気機器20へ分配したり、負荷側(電気機器20側)に過電流が流れた場合に電源を遮断したりするためのブレーカ21が設けられている。ブレーカ21内には、ブレーカ21を介して住宅2内へ分配される大元の電流の波形をモニタするための電流センサ22が設けられている。電流センサ22の計測した電流波形は、通信ネットワークCN1を介して在宅判定システム1へ定期的に送信される。電力系統から住宅2のブレーカ21へ供給される電力の電圧は契約に基づいて一定であるため、電流波形から消費電力量の時間変化を得ることができる。
環境センサ23は、住宅2内の環境に関する情報(居住環境情報)を測定し、通信ネットワークCN1を介して在宅判定システム1へ送信する。環境センサ23の計測した情報と電流センサ22の計測したデータとは、それぞれ別々のタイミングで在宅判定システム1へ送信してもよいし、同時に送信してもよい。
環境センサ23は、例えば、室温を測定する温度計、外気温を測定する温度計、室内の湿度を測定する湿度計や、室内の二酸化炭素(CO2)濃度を測定するセンサ、人間の存在を判断する赤外線センサ、音声を検出する音圧センサ(振動センサ)、気圧センサ、室内の明るさを検出する照度センサ、戸外の明るさを検出する照度センサなどである。例示列挙した全てのセンサが住宅2に備えられている必要はない。また、外気温度計や戸外の照度計の代わりに、他の住宅2の外気温時計や照度計を用いてもよいし、気象情報から推定してもよい。
在宅判定システム1について説明する。在宅判定システム1は、例えば、CPU(Central Processing Unit)100、メモリ101、通信部102等を備えるコンピュータシステムとして構成される。CPU100は、メモリ101に格納された所定のコンピュータプログラムを読み込んで実行することにより、後述の機能110〜180を実現する。
通信部102は、通信ネットワークCN1を介して、各住宅2(電流センサ22,環境センサ23)、情報配信サーバ4と通信する。さらに、通信部102は、通信ネットワークCN2を介してサービス契約会社のコンピュータシステム3と通信する。
在宅判定システム1は、その機能として、在宅/不在判断部110、パラメータ管理部120、顧客管理部130、API140、第1データベース151、第2データベース152、カレンダ160、可視化部170、サービス実現部180を持つ。
在宅/不在判断部110は、例えば、消費電力量の時間変化、電気機器20の稼動状態、カレンダ160から取得する時間情報、環境センサ23から取得する居住環境情報、顧客管理部130から取得する生活環境情報に基づいて、ユーザが在宅している可能性を判定する。
パラメータ管理部120は、在宅/不在判断部110で使用するパラメータ(重みパラメータ)を管理する。
顧客管理部130は、第1データベース151に格納された各ユーザの生活環境情報を管理する。生活環境情報には、例えば、ユーザと同居する家族の構成、年齢、生活パターンなどである。生活環境情報は、ユーザがパーソナルコンピュータや携帯電話(いわゆるスマートフォンを含む)などを用いて、在宅判定システム1の第1データベース151へ登録してもよい。あるいは、電力会社のサーバから取得した契約者データを第1データベース151へ登録してもよいし、電子商取引システムから取得したユーザデータを第1データベース151へ登録してもよい。第1データベース151は、第1記憶部と呼ぶこともできる。
API(Application Programming Interface)140は、各住宅2から受信するデータ(電流センサ22のデータ、環境センサ23のデータ)を受け付ける機能である。API140を介して受け付けられた各データは、第2データベース152に記憶される。在宅/不在判断部110は、第2データベース152に格納されたデータに基づいて、ユーザが在宅している可能性を判断する。在宅/不在判断部110による判定結果(ユーザの在宅可能性)は、第2データベース152に格納される。第2データベース152は、第2記憶部と呼ぶこともできる。
第1データベース151に記憶されたデータ(生活環境情報)は、在宅の可能性を判定するためのパラメータセットの選択のために使用される。これに限らず、在宅/不在判断部110は、第1データベース151に格納されたデータと第2データベース152に格納されたデータの両方を用いて、ユーザの在宅可能性を判断してもよい。
カレンダ160は、年月日や時刻、曜日や祝祭日などの時間を管理する。カレンダ160は、在宅判定システム1の内部に設けることできるし、情報配信サーバ4の一つとして在宅判定システム1の外部に設けることもできる。
可視化部170は、在宅/不在判断部110の判定結果を、サービス実現部180が利用しやすいように可視化して出力する。例えば、可視化部170は、各住宅2の在宅状況を数値やグラフ等で表現して出力する。
サービス実現部180は、可視化部170で可視化された結果に基づく付加価値を提供するサービスを実現する。例えば、サービス実現部180は、住所やユーザ氏名、郵便番号、電話番号、宅配の伝票番号、調査票の識別番号等が入力されると、それに対応する住宅2にユーザが在宅している可能性を出力するといったサービスを提供する。あるいは、サービス実現部180は、後述のように、ある地域におけるユーザの在宅可能性をランク分けし、ランクの時間変化を出力するといったサービスを提供する。
図3および図4を用いて、消費電力量に基づく在宅判定の例を説明する。図3は、消費電力量に基づいて在宅/不在を判定する場合の消費電力量の時系列データと、在宅/不在を判定するための閾値との関係を示す。
図3において、縦軸は住宅2の消費電力量Wを示し、横軸は時間を示す。「max」は、ある期間(例えば1日間)における消費電力量Wの最大値を示す。「min」は、同じくある期間における消費電力量の最小値を示す。「ave」は、ある期間の消費電力量Wの平均値である。閾値ThUは、ユーザが在宅している可能性が高いと判断できる消費電力量である。閾値ThLは、ユーザが在宅していない可能性が高いと判断できる消費電力量である。
図4は、閾値ThU,ThLと在宅/不在の判定結果との関係を示す判定テーブルT1である。判定テーブルT1は、番号欄C11と、条件欄C12と、判定結果欄C13とを対応付けて管理する。
番号欄C11は、各判定条件に設定された番号を管理する。条件欄C12は、住宅2の消費電力量と閾値との大小関係から在宅の可能性を判定するための条件を定義する。判定結果欄C13は、判定結果を格納する。
本実施例では、住宅2の消費電力量Wが在宅判定用閾値ThUを超えている場合(W>ThU)、ユーザは在宅している可能性が高いと判定する(図中、丸印)。これに対し、消費電力量Wが不在判定用閾値ThLを下回っている場合(W<ThL)、ユーザは不在である可能性が高いと判定する(図中、バツ印)。ここでのユーザとは、家族を構成する各個人ではなく、その住宅2に住む家族を示している。家族のうち誰か一人でも住宅2内に存在する場合、在宅/不在判断部110は在宅していると判定する。家族の全員が住宅2内に居ない場合、在宅/不在判断部110は不在であると判定する。
消費電力量Wが不在判定用閾値ThL以上であって、かつ、在宅判定用閾値ThU以下である場合(ThL≦W≦ThU)、ユーザは在宅しているか否か不明であると判定する(図中、三角印)。在宅しているか否か不明とは、ユーザが在宅している可能性はあるが、その可能性は丸印の評価ほどには高くない状況である。
在宅判定用閾値ThUおよび不在判定用閾値ThLは、それぞれ統計処理で決定してもよいし、過去蓄積されたデータから決定してもよい。家族構成や家族の年齢構成等から導出される生活パターン(生活リズム)と消費電力量の推移パターンとを照合することで、閾値ThU,ThLを決定してもよい。なお、図中では、ユーザの在宅可能性を丸印、バツ印、△印のように記号で表現しているが、これに代えて、確率やランクなどの数値で表現することもできる。
図5,図6は、電気機器20の稼動状態からユーザの在宅可能性を判定する様子を示す説明図である。
図5は、電気機器20に設定される在宅係数の時間変化を示す。本実施例では、電気機器ごとに「重みパラメータ」の例である在宅係数を設定する。本実施例では、各電気機器20の在宅係数に基づいて、ユーザの在宅可能性を算出する。
上述の通り、本実施例では、家庭で使用される電気機器(家庭電気製品)には、ユーザの在宅と密接に関連する特定機器20Aと、ユーザの在宅とは関連の薄いその他機器20Bとがあることに着目する。
例えば、手動操作型の電気掃除機はユーザが手動で操作する電気機器である。したがって、電気掃除機の稼働が検出された場合は、ユーザが在宅している可能性が高い。これに対し、冷蔵庫は、通常、常時稼動している。エアコンは、ペットなどのために一日中稼動される場合がある。テレビ、照明などは、外出先のユーザが遠隔操作で稼動させたり停止させたりする場合がある。したがって、それらエアコン、テレビ、照明などの特定機器20A以外の機器20Bは、ユーザの在宅との関連が低いと考えられる。
図5を参照する。住宅2のブレーカ21内に設けられた電流センサ22が検出した消費電力量を解析することで、その住宅2に置かれた各電気機器20がいつ稼動し、いつ停止したかの稼動状態を推定することができる。
図5の上側には、2種類の電気機器20の特性L1,L2が示されている。特性L1は、例えば手動操作型の電気掃除機である。特性L2は、例えばエアコンである。手動操作型の電気掃除機は、ユーザが手動で操作しないと使用することができないため、その在宅係数Ch1は高く設定される。これに対し、エアコンは、ユーザが不在であっても稼動する可能性が高いため、その在宅係数Ch2は低く設定される。
手動操作型の電気掃除機は、時刻t1で起動されて時刻t2まで時間Tonだけ稼動したとする。在宅係数は、起動時刻t1で値Ch1となり、停止時刻t2までその値Ch1が継続する。
ここで、停止時刻t2で手動操作型の電気掃除機が停止された後、在宅係数Ch1は直ちに0になるのではなく、所定の傾きθで徐々に低下し、時刻t4で0になる。この理由は、手動操作型の電気掃除機を用いて掃除した後も、ユーザは、少なくとも所定時間Tcの間は、在宅している可能性が高いからである。手動操作型の電気掃除機の稼動を停止させた後、ユーザの在宅可能性は次第に低下すると考えられる。
そこで、本実施例では、電気機器の稼働停止から所定時間Tcが経過した後に、その在宅係数が0になるように設定することができるようになっている。所定時間Tcを本実施例では移行時間Tcと呼ぶ。移行時間Tcは、電気機器の種類などに応じて事前に設定することができる。
特性L2は、時刻t3で起動し、時刻t5で停止したものとする。在宅係数は、起動時刻t3で値Ch2(<Ch1)となり、停止時刻t5で0となる。特性L2では、移行時間が短く設定されているため、電気機器の稼働が停止した後、速やかに在宅係数の値は0になる。移行時間Tcは0以上の値に設定することができる。
図5の下側には、特性L1,L2を合成した特性L3が示されている。本実施例では、住宅2内の各電気機器20の在宅係数を総合的に判断することで、ユーザの在宅可能性を判定する。
なお、図5の例では、手動操作型の電気掃除機を主に説明したが、これに限らず、例えば、炊飯器であれば、炊飯動作がOFFした後、しばらくの間はユーザは在宅している可能性が高い。通常の場合、食事をする可能性が高いためである。また、洗濯機であれば、洗濯動作がOFFした後、ユーザは洗濯物を干したり乾燥機に入れたりする可能性が高いため、30分程度は在宅している可能性が高いと予測できる。一方、エアコンの場合、稼動を停止させた後、比較的短時間で外出する可能性が高いと予測できる。このように、本実施例では、電気機器の使われ方に応じて、ユーザの在宅可能性との関係を示す在宅係数(重みパラメータ1)および移行時間(重みパラメータ2)を設定する。本実施例では、在宅係数と移行時間の設定を調整することで、電気機器ごとにユーザの在宅可能性との関連性を表現している。
図6は、在宅係数に基づいて在宅/不在を判断する判定テーブルT2を示す。この判定テーブルT2は、例えば、番号欄C21と、条件欄C22と、判定結果欄C23とを対応付けて管理する。
番号欄C21は、各判定条件に設定された番号を管理する。条件欄C22は、電気機器20の在宅係数と閾値との大小関係からユーザの在宅可能性を判定するための条件を定義する。判定結果欄C33は、判定結果を格納する。
本実施例では、特定機器20Aの在宅係数Ch1が閾値ThC1を超過した場合(Ch1>ThC1)、その住宅2は在宅可能性が高い(丸印)と判定する。各電気機器20の在宅係数が全て閾値ThC2以下の場合(0を含む)、その住宅3は在宅可能性が低いと判定する(バツ印)。特定機器20A以外のその他機器20Bの在宅係数Ch2の合計値ΣCh2が閾値ThC2を超過した場合(ΣCh2>ThC2)、その住宅の在宅可能性は不明であると判定する(三角印)。不明とは、上述の通り、在宅の可能性はあるが丸印評価の場合ほどには高くないという状態である。なお、判定結果は、丸印、三角印、バツ印のような記号に代えて、確率やランクなどの数値で表現してもよい。
図7は、電気機器20の動作時間を管理するテーブルT3の例である。このテーブルT3は、電気機器毎の稼働時における想定動作時間を管理する。電気機器20は、いったん起動されると、その起動目的を果たすまで継続して稼動することが多い。電気機器20が起動した後、どの程度稼動し続けるかは、その電気機器の使用目的や性質、ユーザの性格、生活スタイルなどに依存する。しかし、電気機器毎の動作時間を調査して統計処理することで、およその値を得ることができる。
本実施例では、住宅2の消費電力量の時間変化を波形解析することで、その住宅2で使用される電気機器20の稼動状態を推定する。さらに、本実施例では、図7に示すテーブルT3を参照することで、電気機器20の稼動状態の推定精度を高める。
本実施例では、電気機器の起動をいったん検出した場合、途中で波形解析結果が不安定になったとしても、テーブルT3に規定する想定動作時間だけは稼動を続けるものと推定できる。例えば、洗濯機の稼動開始(起動)が検出された後、何らかの理由で洗濯機の消費電力量の波形を見失った場合でも、洗濯機は30分程度は稼動を続けるものとみなして、洗濯機の稼働状態をモニタすることができる。これにより、電気機器20の波形の検出が断続した場合でも、電気機器の在宅係数に基づいて、ユーザの在宅可能性を安定して判定することができる。なお、統計データなどから作成する想定動作時間の管理テーブルT3に代えて、あるいはテーブルT3と共に、他のデータから動作時間を推定することもできる。例えば、テレビの場合、ユーザの家族構成と世代別の視聴率情報とに基づいて、テレビの稼働時間を推定することもできる。
図8は、重みづけパラメータである在宅係数と移行時間の例を示すパラメータ管理テーブルT4を示す。
パラメータ管理テーブルT4は、例えば、機器種別欄C41と、パラメータ1欄(在宅係数欄)C42と、パラメータ2欄(移行時間欄)C43とを対応付けて管理する。
機器種別欄C41は、電気機器20の種類が記憶される。パラメータ1欄C42には、図5で述べた在宅係数の値が設定される。パラメータ2欄C43には、在宅係数が0に低下するまでの移行時間が設定される。在宅係数は、値が大きいほどユーザの在宅している可能性が高いものとし、値が小さいほどユーザの在宅可能性は低いものとする。移行時間は、値が大きいほど、その電気機器が稼働を停止した後でもユーザが在宅している可能性が高いことを示す。移行時間の値が小さい場合は、電気機器の稼働が停止した後、ユーザの在宅可能性は低いことを示す。
図9は、パラメータ管理テーブルT4の他の例を示す。パラメータ管理テーブルT4は、例えば、生活パターン(生活スタイル)、季節、家族構成などの指標の組合せに応じて、それぞれ用意することができる。
例えば、パラメータ管理テーブルT4(1)では、生活パターンと季節の組合せで、図8で述べたパラメータ管理テーブル4の重みづけパラメータ(在宅係数、移行時間)の値を調整する。同様に例えば、パラメータ管理テーブルT4(2)では、ユーザの家族構成と生活パターンの組合せで、重みづけパラメータの値を調整する。さらに例えば、パラメータ管理テーブルT4(3)では、天候状態と季節の組合せで、重みづけパラメータの値を調整する。図9に示す例以外にも、種々の観点から重みづけパラメータを設定することができる。
図10は、在宅/不在判定の全体処理を示すフローチャートである。在宅判定システム1は、API140を介して所定周期でデータを取り込むことにより、更新データがあるか否か判定する(S10)。取込み対象のデータは、住宅2の消費電力量の時間変化を示す消費電力データと、消費電力データから抽出された電気機器20の稼動状態を示す電気機器データ(電気機器稼動状態情報)と、センサ23や情報配信サーバ4から取得する環境データ(環境情報)である。
在宅判定システム1は、更新データがあると判定すると(S10:YES)、その更新データをAPI140から取得して(S11)、第2データベース152へ格納する(S12)。在宅判定システム1の在宅/不在判断部110は、データベース152に格納された各データ(消費電力データ、電気機器稼動状態情報、環境情報)と、パラメータ管理部120から提供されるパラメータ(重みづけパラメータである在宅係数と移行時間)とを参照し(S13)、ユーザの在宅可能性を判定する(S14)。ステップS14の詳細は図11で後述する。
在宅/不在判断部110による判定結果は、第2データベース152へ格納される(S15)。判定結果を格納するためのデータベースを別に用意してもよい。可視化部170は、在宅/不在判断部110の判定結果をデータベース152から取得して、グラフや表などの形式で可視化する(S16)。後述のように、ユーザの在宅可能性を統計処理して地図情報上に対応付けて表示することもできる。
図11は、図10中のステップS14の例を示すフローチャートである。本実施例では、消費電力量の時間変化に基づく判定処理S100と電気機器20の在宅係数に基づく判定処理S200との複数の異なる処理を結合させることで、ユーザの在宅可能性を総合的に判定する。
ここで、処理S100は、在宅/不在判断部110のうち図1中に示す消費電力量用在宅判定部111が担当する。処理S200は、在宅/不在判断部110のうち図1中に示す特定機器用在宅判定部112Aおよびその他機器用在宅判定部112Bが担当する。環境センサ用在宅判定部113の動作例は別の実施例で後述する。
先に消費電力量に基づく判定処理S100について説明する。在宅/不在判断部110は、消費電力データと閾値パラメータを取得し(S101)、消費電力量Wが在宅判定用閾値ThUを超えているか判定する(S102)。在宅/不在判断部110は、消費電力量Wが在宅判定用閾値ThUを超えていると判定すると(S102:YES)、ユーザの在宅可能性は高いと判定する(S103)。
在宅/不在判断部110は、消費電力量Wが在宅判定用閾値ThU以下であると判定すると(S102:NO)、消費電力量Wが不在判定用閾値ThLを下回っているか判定する(S104)。在宅/不在判断部110は、消費電力量Wが不在判定用閾値ThLを下回っていると判定すると(S104:YES)、ユーザは不在である可能性が高いと判定する(S105)。
在宅/不在判断部110は、消費電力量Wが不在判定用閾値ThL以上であると判定すると(S104:NO)、ユーザが在宅している可能性はあるものの不明であると判定する(S106)。在宅/不在判断部110は、消費電力量の時間変化に基づく判定結果を在宅ランクを計算するステップS300へ出力する(S107)。在宅ランクは、「ユーザが在宅している可能性を示す所定の指標値」の例である。ステップS300は、在宅/不在判断部110のうち図1中に示す総合判定部114が担当する。
次に、電気機器20の在宅係数に基づく判定処理S200について説明する。在宅/不在判断部110は、住宅2内の各電気機器20の稼動状態を示す情報と在宅係数および移行時間の基準値を取得する(S201)。
在宅/不在判断部110は、家族構成、季節、時間帯、室温、天候などの情報を考慮して、在宅係数の基準値から在宅係数を生成する(S202)。
在宅/不在判断部110は、特定機器20Aの例としての掃除機の在宅係数が閾値Thc1を超えているか判定する(S203)。在宅/不在判断部110は、特定機器20Aの在宅係数Ch1が閾値ThC1を超過していると判定すると(S203:YES)、ユーザが在宅している可能性が高いと判定する(S204)。
在宅/不在判断部110は、特定機器20Aの在宅係数が閾値ThC1以下であると判定すると(S203:NO)、その他機器20Bの在宅係数Ch2の合計値ΣC2が閾値ThC2を超えているか判定する(S205)。在宅/不在判断部110は、その他機器20Bの在宅係数の合計値ΣC2が閾値ThC2を超えていないと判定すると(S205:NO)、在宅の可能性は低いと判定する(S207)。
在宅/不在判断部110は、その他機器20Bの在宅係数の合計値ΣC2が閾値ThC2を超えている場合(S205:YES)、ユーザの在宅可能性はあるが、ステップS204での評価ほど可能性は高くないと判定する(S206)。在宅/不在判断部110は、在宅係数に基づく判定結果をステップS300へ出力する(S208)。
在宅/不在判断部110は、消費電力量に基づく判定結果(S107)と在宅係数に基づく判定結果(S208)とから、ユーザが在宅している可能性を総合評価し、その結果を在宅ランクとして出力する(S300)。
図12は、在宅ランクを判定するテーブルT5の例を示す。テーブルT5は、例えば、番号欄C51、消費電力量に基づく判定結果欄C52、在宅係数に基づく判定結果欄C53、在宅ランク欄C54を対応付けて管理する。
消費電力量判定結果欄C52は、消費電力量に基づいて判定された在宅可能性の結果を示している。在宅係数判定結果欄C53は、在宅係数に基づいて判定された在宅可能性の結果を示している。在宅ランク欄C54は、消費電力量に基づく判定結果と在宅係数に基づく判定結果とから算出されるランクの値を示す。在宅ランクは、総合評価と呼ぶこともできる。
図12の例では、番号「1」に示すように、消費電力量に基づく在宅可能性が高く(丸印)、かつ、在宅係数に基づく在宅可能性も高い場合(丸印)、最高ランク「5」が与えられる。これに対し、番号「9」に示すように、消費電力量に基づく在宅可能性が低く(バツ印)、かつ、在宅係数に基づく在宅可能性も低い場合(バツ印)、最低ランク「0」が与えられる。
番号「2」,「3」に示すように、消費電力量に基づく在宅可能性が高い場合であっても(丸印)、在宅係数に基づく在宅可能性が高くはない場合(三角印、バツ印)、在宅ランクの値は最高ランク「5」よりも低くなる。消費電力量に基づく在宅可能性が高くても、在宅係数に基づく在宅可能性が低い場合、「総合評価」としての在宅ランクは低い値に修正される。
番号「4」,「7」に示すように、消費電力量に基づく在宅可能性が高くない場合であっても(三角印、バツ印)、在宅係数に基づく在宅可能性が高い場合(丸印)、在宅ランクは高い値に修正される。
このように、本実施例では、消費電力量に基づく在宅可能性を在宅係数に基づく在宅可能性により修正することができ、信頼性の高い総合評価を算出できる。
図13は、変形例に係る在宅ランク判定テーブルT6を示す。このテーブルは、例えば、番号欄C61と、消費電力量に基づく判定結果欄C62と、在宅係数に基づく判定結果欄C63と、予測欄C64と、在宅ランク欄C65とを対応付けて管理する。ここで欄C61,C62,C63,C65は、図12で述べた欄C51,C52,C53,C54に対応するため、説明を省略する。
予測欄C64は、過去の判定結果に基づく在宅可能性の予測である。例えば、一週間前の同じ時間帯のような過去の判定結果を参考にすることで、今回の在宅可能性の判定精度を向上させることができる。一週間や一ヶ月程度の過去の判定結果であれば、季節による気温変化や生活パターンの変化があまりないと見込まれるため、予測値として参考にすることができる。本日に対応する一年前の同じ曜日の在宅可能性を予測値として参考にしてもよい。予測値は、過去に実施した在宅可能性の判定結果(推定値)でもよいし、鉄道利用履歴などの他のデータで後から確認した実績値であってもよい。
図13の予測欄C64では、番号「5」〜「8」および「10」,「11」には丸印またはバツ印のいずれかを記載し、それ以外にはハイフンを記載している。これは、消費電力量に基づく在宅可能性と在宅係数に基づく在宅可能性だけでは判断が難しいケースに限って、予測値C64を参照することを意味する。消費電力量に基づく在宅可能性と在宅係数に基づく在宅可能性だけで判断可能な場合は、予測値C64を参照しない。予測値C64を参照しないケースでは、ハイフンを記載している。
なお、在宅/不在の予測値を参照するか否かは、住宅毎で異なったり、在宅/不在判定の結果を適用するサービスによっても異なると考えられる。したがって、条件や状況等によって、在宅/不在の予測値を参照するか否かを設定してもよい。
このように構成される本実施例によれば、消費電力量に基づく在宅可能性と在宅係数に基づく在宅可能性とから総合判断することで、ユーザの在宅可能性を従来よりも高い精度で判定することができる。
本実施例では、ユーザの住宅2に設けられた電気機器20を、ユーザの在宅可能性との関連が高いとして事前に指定された特定機器20Aとその他機器20Bとに分類し、特定機器20Aの稼動状態を表す在宅係数と、その他機器20Bの稼動状態を表す在宅係数とから、ユーザの在宅可能性を判定する。したがって、例えば手動操作型の電気掃除機のように、ユーザが手動で操作する可能性が高い特定機器20Aの稼動を検出した場合は、在宅可能性を高い精度で判定できる。特定機器20Aの稼動を検出できない場合でも、特定機器20Aの稼動停止後から一定時間内であれば、その他機器20Bの稼動状態を加味することで在宅可能性を高精度に判定できる。
本実施例では、電気機器20の稼動状態を示す在宅係数を、電気機器の稼動停止後にただちに0として扱うのではなく、所定の移行時間が経過するまでは徐々に低下させて、在宅可能性の判定に使用する。したがって、ユーザの生活実態に即して電気機器20の稼動状態を解釈することができ、従来よりも高精度に在宅可能性を判定できる。
本実施例では、図7で述べたように、電気機器20の種別ごとに想定動作時間を設定するため、消費電力量の時間変化を示す波形データを完全に解析できない場合でも、想定動作時間に基づいて電気機器の稼働状態を検出することができる。
図14〜図17を用いて第2実施例を説明する。本実施例を含む以下の各実施例では、第1実施例との相違を中心に説明する。本実施例では、第1実施例で述べた判定アルゴリズムを前提としつつ、温度や湿度などの環境データを用いることで在宅/不在の判定精度を向上させる。
図14は、環境データを定義するテーブルT7の例である。このテーブルT7は、例えば、番号C71、項目欄C72、内容欄C73を備える。項目欄C72は、環境データの種類、例えば、温度(室温、外気温)、湿度、照度、二酸化炭素濃度(CO2濃度)、音、人感(赤外線の有無)を記憶する。内容欄C73は、項目欄C72に設定された環境データの内容を説明する。
住宅2が最初から人感センサを備えており、その人感センサの検出信号を在宅判定システム1が利用できるのであれば、ユーザが在宅しているか否かを高い確率で判断することができる。ペットが飼われていないことを前提にすると、二酸化炭素濃度が高ければ、ユーザが在宅している可能性が高いと判定できる。ユーザが在宅している場合、何らかの生活音が発生するため、音センサや音圧センサの検出信号から、ユーザが在宅している可能性を判定できる。
このように環境データを測定する環境センサ23が住宅2に設置されており、その環境センサ23を在宅判定システム1が利用できる場合、環境データを利用してユーザの在宅可能性を判定できる。しかし、環境データのみでは、在宅可能性の判定精度を高くすることができない可能性がある。そこで、本実施例では、第1実施例の在宅/不在判定アルゴリズムと環境データとを組み合わせることで、判定精度を向上させる。
なお、環境データは、全て住宅2内の環境センサ23から取得する必要はなく、サーバ4などから取得して利用することもできる。
図15は、本実施例による在宅/不在判定処理の第1の変形例を示すフローチャートである。この第1変形例では、消費電力量に基づいて在宅/不在を判定する第1の判定処理S100(図中、判定処理1)と、在宅係数に基づいて在宅/不在を判定する第2の判定処理S200(図中、判定処理2)とに加えて、第3の判定処理S400(図中、判定処理3)を実施する。第3の判定処理400では、後述のように、常時稼動する冷蔵庫のような機器と室温との関係から、在宅/不在を判定する。
第3の判定処理S400では、常時稼働することの多い冷蔵庫に着目する。通常、冷蔵庫は庫内の温度を維持するために、冷却に使用するコンプレッサを間欠制御する。間欠動作では、庫内の温度が上昇した場合に電流値を増加させ、庫内の温度が設定温度以下に到達すると電流値を減少させる。この間欠動作の周期は、室温や人の開閉動作による庫内温度の変化に依存すると考えられる。
そこで、本実施例では、冷蔵庫の電力変化と室温とに着目した第3の判定処理S400を実施する。
在宅/不在判断部110は、消費電力量などのデータと閾値などのパラメータとを取得した後(S401)、判定対象の常時稼動機器の単位時間あたりの消費電力量の変化ΔWが所定の閾値ThΔW以上であるか判定する(S402)。
常時稼動機器の消費電力量の時間変化ΔWが閾値ThΔW以上の場合、在宅/不在判断部110は、室温が所定の閾値ThTA以下であるか判定する(S403)。
常時稼動機器の消費電力量の時間変化ΔWが閾値ThΔW未満である場合(S402:NO)、在宅/不在判断部110は、在宅可能性は低い(バツ印)ものと判定する(S404)。在宅の場合、ユーザが常時稼動機器を時々使用すると考えられる。常時稼動機器の消費電力量の時間変化ΔWが少ないということは、ユーザにより使用されていないと考えられる。したがって、在宅可能性は低いと判定することができる。
常時稼動機器の消費電力量の時間変化ΔWが閾値ThΔW以上の場合であっても(S402:YES)、室温が所定の閾値ThTAを超えている場合(S403:NO)、高温の室温に対応すべくコンプレッサが稼働したと考えることができる。そこで、在宅/不在判断部110は、在宅可能性は低いと判定する(S404)。
これに対し、常時稼動機器の消費電力量の時間変化ΔWが閾値ThΔW以上であって(S402:YES)、かつ、室温が所定の閾値ThTA以下であるときは(S403:YES)、室温が高くないにもかかわらず消費電力量が閾値ThΔWを超えて増大した場合である。つまり、在宅中のユーザが常時稼動機器を使用した結果、消費電力量が増大したと考えられるため、在宅/不在判断部110は、在宅可能性は高い(丸印)と判定する(S405)。
第3の判定処理S400の判定結果は、在宅ランクを計算するステップS300へ出力される(S406)。在宅/不在判断部110は、消費電力量に基づく第1の判定処理S100の判定結果と、在宅係数に基づく第2の判定処理S200の判定結果と、常時稼動機器の稼働状態と室温の関係に基づく第3の判定処理S400の判定結果とに基づいて、ユーザの在宅可能性を算出し、ランク分けする(S300)。
例えば、在宅/不在判断部110は、第1の判定処理S100の判定結果と第2の判定処理S200の判定結果だけでは在宅可能性が不明な場合に、第3の判定処理S400の判定結果を考慮して在宅可能性があるか否かを決定することができる。または、在宅/不在判断部110は、各判定処理S100,S200,S400の判定結果を数値化し、重みを付けて合計した値から、在宅可能性をランク分けしてもよい。
なお、アナログ値である電力量の時間変化を閾値ThΔWとして用いたが、これに代えて、間欠動作時のオンオフ期間を参照し、オン時間の長さや、所定期間内におけるオン状態の頻度などから常時稼動機器の稼働状況を推定してもよい。
図16は、本実施例による在宅/不在判定処理の第2の変形例を示すフローチャートである。この第2変形例では、環境センサ23の例として人感センサを用いた第4の判定処理S500(図中、判定処理4)を実施する。人感センサとは、例えば人間の体温が発する赤外線、人間の出す音などを計測して、人間の存在を検知するセンサである。
在宅/不在判断部110は、人感センサからの測定データと閾値などのパラメータとを取得し(S501)、人感センサが人間の存在を検知したか判定する(S502)。例えば、所定波長範囲の赤外線の強さが所定の閾値以上である場合、あるいは、所定周波数の音が所定期間以上継続した場合に、人間が存在すると推定することができる。
在宅/不在判断部110は、人感センサが人間の存在を検知すると(S502:YES)、在宅可能性が高い(丸印)と判定する(S503)。これに対し、在宅/不在判断部110は、人感センサが人間の存在を検知できなかった場合(S502:NO)、在宅可能性は低い(バツ印)と判定する(S504)。第4の判定処理S500の判定結果は、在宅ランクを計算するステップS300へ送られる。ステップS300では、消費電力量に基づく第1の判定処理S100の判定結果と、在宅係数に基づく第2の判定処理S200の判定結果と、第4の判定処理S500の判定結果とに基づいて、ユーザの在宅可能性を計算し、ランク分けして出力する。
図17は、在宅/不在判定処理の第3の変形例を示すフローチャートである。この第3変形例では、環境センサとして二酸化炭素濃度センサを使用し、二酸化炭素濃度に基づいて在宅可能性を判定する第5の判定処理(図中、判定処理5)を実施する。
在宅/不在判断部110は、二酸化炭素濃度センサの測定データと閾値などのパラメータとを取得し(S601)、二酸化炭素濃度が所定の閾値ThCO2以上であるか判定する(S602)。
在宅/不在判断部110は、二酸化炭素濃度が閾値ThCO2以上であると判定すると(S602:YES)、在宅可能性は高い(丸印)と判定する(S603)。人間が住宅2内に存在すれば、二酸化炭素濃度は高くなるためである。これに対し、在宅/不在判断部110は、二酸化炭素濃度が閾値ThCO2未満であると判定すると(S602:NO)、在宅可能性は低い(バツ印)と判定する(S604)。第5の判定処理の結果は、在宅ランクを計算するステップS300へ出力される(S605)。
在宅/不在判断部110は、消費電力量に基づく第1の判定処理S100の判定結果と、在宅係数に基づく第2の判定処理S200の判定結果と、二酸化炭素濃度センサの測定結果に基づく第5の判定処理S600の判定結果とに基づいて、ユーザの在宅可能性を算出し、ランク分けする(S300)。
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに本実施例では、常時稼動機器の稼働状態、環境センサ23の測定データ(室温、人感、二酸化炭素濃度)も考慮するため、第1実施例の場合に比べてより高精度に在宅可能性を判定することができる。
本実施例では、ユーザの在宅可能性との関連が低いと思われがちな冷蔵庫などの常時稼動機器の稼働状況を消費電力量の波形データから抽出し、その稼働状況と室温とを照合することで、在宅可能性を判断する。本実施例では、環境データである室温と組み合わせることで、常時稼動機器の稼働状態をユーザの在宅可能性に結びつけることができ、常時稼動機器の稼働状態から在宅可能性を判定できる。
なお、図15,図16,図17に示す在宅/不在判定処理は適宜組み合わせてもよい。例えば、消費電力量に基づく第1の判定処理S100と、在宅係数に基づく第2の判定処理S200と、常時稼動機器の稼働状態に基づく第3の判定処理S400と、人感センサの測定データに基づく第4の判定処理S500と、二酸化炭素濃度センサの測定データに基づく第5の判定処理S600とをそれぞれ実行し、ステップS300において総合的に判定してランク分けしてもよい。
図18を用いて第3実施例を説明する。本実施例では、在宅/不在を判定する機能と、その判定結果を利用してサービスを提供する機能とを別々のコンピュータシステム上に実現する。
図18は、在宅判定システム1Aを含む情報処理システムの全体概要を示す。本実施例では、図1で述べた在宅判定システム1のうち、サービス実現部180と顧客管理部130と第1データベース151とを、サービス提供者の管理するコンピュータシステム5上で実現する。図中では、サービス提供者の管理するコンピュータシステムを1つだけ示すが、在宅判定システム1Aは、複数のコンピュータシステムに対して在宅可能性の判定結果を供給することができる。同様に、サービス提供者のコンピュータシステム5は、それぞれ異なるサービス契約会社に対してサービスを提供することができる。
本実施例の在宅判定システム1Aは、在宅/不在判断部110、パラメータ管理部120、API140、第2データベース152、カレンダ160、可視化部170を含んで構成される。住宅2の構成などは第1実施例と同一であるため、説明を省略する。
例えば電力会社などのサービス事業者の管理するコンピュータシステム5(サービス提供システム5)は、在宅判定システム1Aと連携することで、各住宅2の在宅可能性を宅配業者などのサービス契約会社1に提供することができる。
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに、本実施例では、在宅/不在を判定する機能と、在宅/不在の判定結果(在宅可能性)を用いてサービスを提供する機能とを異なる事業者の管理するコンピュータシステムに分散させて連携させる。したがって、在宅判定システム1Aの判定結果を種々のサービスに応用することができ、使い勝手が向上する。
図19〜図21を用いて第4実施例を説明する。本実施例では、在宅/不在の判定結果を地域ごとに統計処理して提供する。
図19は、本実施例の在宅判定システム1Bの機能構成図である。在宅判定システム1Bは、第1実施例で述べた在宅判定システム1に比べて、地図管理部1000を備える点で相違する。
地図管理部1000は、所定範囲の地図データを在宅/不在判断部100と顧客管理部130と可視化部170とに供給する。顧客管理部130は、在宅判定システム1の対象となる住宅2の住所を管理している。したがって、在宅/不在判断部110の判定結果を地域ごとに集計することで、可視化部170は、各地域の時間帯毎の在宅可能性を表示出力することができる。さらに、隣接する地域同士で在宅可能性の時間変化を比較することで、人の流れを可視化することも可能である。
図20は、地域別時間帯別の在宅可能性を集計して表示する画面G1の例である。例えば、A地区、B地区、C地区、D地区があるものとして説明する。
本実施例の在宅判定システム1Bは、各地区に存在する各住宅の在宅可能性の判定結果の時系列データを合計し、その地区のデータ収集戸数の合計で除算する。これにより、在宅判定システム1Bは、地域毎の在宅ランクの平均値を算出し、グラフ化して提供することができる。図20中のグラフにおいて、縦軸は在宅ランク、横軸は時間を示す。
図21は、在宅ランクの提示方法の一例を示す。図21の例では、7段構成になっており、最上段から順番に、全体の消費電力量、エアコンの稼動状況、洗濯機の稼動状況、炊飯器の稼動状況、テレビの稼動状況、掃除機の稼動状況、在宅/不在判定の結果を示す在宅ランクである。これら7種類のデータは、それぞれ一日分の時系列データである。エアコンや炊飯器等の電気機器20の稼動状態(機器分離データ)は、最上段に示す消費電力量の波形データを解析することで抽出することができる。
11:00付近において全体消費電力はわずかに上昇しているが、それだけでは在宅と判断できなかったとする。しかし、炊飯器の稼動状態がオン状態であるため、在宅している可能性がある(在宅ランク=2)と判断している。なお、炊飯器と在宅との相関性は各住宅によって異なるだろうから、図21は一例であることは言うまでもない。
図21の例では、在宅ランクは0〜5の6段階とし、1段階あたり在宅可能性(在宅率)20%に対応させる。したがって、在宅ランク0は在宅可能性0%、在宅ランク1は在宅可能性20%、在宅ランク2は在宅可能性40%、在宅ランク3は在宅可能性60%、在宅ランク4は在宅可能性80%、在宅ランク5は在宅可能性100%となる。
しかし、在宅可能性とランクとの対応付けは、上述の例に限定されない。在宅可能性を利用するサービスの種類に応じて、ランク付けの定義や閾値を設定できる。例えば、宅配業者が配達の可能性を判断する場合、在宅ランクは3段階に分け、在宅ランク0は配達すべきではない、在宅ランク1は不在のリスクはあるが配達してもよい、在宅ランク2はほぼ在宅なので配達すべし、と定義してもよい。いずれにしても、可視化部170は、図21で示すような時系列データの可視化画面をサービス提供者へ提供する。
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに本実施例では、在宅可能性を地域毎/時間帯毎に統計処理して可視化して出力することができ、サービス提供者にとって使い勝手が向上する。サービス提供者は、地域毎時間帯毎の在宅可能性を、宅配時の経路選択のような、様々なサービス適用における判断基準として利用することができる。
本実施例では、消費電力量、各電気機器の稼働状態、在宅ランクの時系列データを一覧できるようにグラフ表示することができる。したがって、在宅判定システム1の管理者やサービス提供者は、在宅ランクの時間変化を容易に把握することができる上に、在宅ランクの算出根拠もグラフから比較的簡単に読み取ることができ、使い勝手が高い。
図22を用いて第5実施例を説明する。本実施例では、消費電力量に基づく第1の判定処理では在宅可能性を判断できない場合に、在宅係数に基づく第2の判定処理の結果を参考にする。
図22は、在宅ランクを算出するステップS300Aのフローチャートである。在宅/不在判断部110は、消費電力量に基づく第1の判定処理S100の結果が不明(三角印)であるか判定する(S301)。
消費電力量に基づく第1の判定処理の結果が「不明」である場合(S301:YES)、在宅/不在判断部110は、在宅係数に基づく第2の判定処理S200の判定結果を参照する(S302)。
在宅/不在判断部110は、第2の判定処理が在宅可能性は高い(丸印)と判定しているか判定する(S303)。第2の判定処理が在宅可能性は高いと判定している場合(S303:YES)、在宅/不在判断部110は、総合判定結果として、在宅可能性は高い(丸印)と判定する(S304)。
第2の判定処理が在宅可能性は高くないと判定している場合(S303:NO)、在宅/不在判断部110は、第2の判定処理の判定結果が「不明」であるか判定する(S305)。第2の判定処理の判定結果が「不明」である場合(S305:YES)、在宅/不在判断部110は、総合判定結果として、在宅可能性は不明(三角印)と判定する(S306)。これに対し、第2の判定処理が在宅可能性は「不明」でもない、すなわち在宅可能性は低い(バツ印)と判定している場合(S305:NO)、在宅/不在判断部110は、総合判定結果として、在宅可能性は低い(バツ印)と判定する(S307)。
このように構成される本実施例も第1実施例と同様の作用効果を奏する。さらに、本実施例では、消費電力量に基づく判定処理だけでは在宅可能性を明確に判定できない場合に、在宅可能性に基づく判定処理の結果を参考にする。つまり、第1の判定処理だけでは判定できない場合に、第2の判定処理が第1の判定処理を補完する。
なお、本発明は上記各実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記各実施例は本発明を分かりやすく説明するために詳細に記載したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
また、上記の各構成、機能、処理部、および処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。 また、上記の各構成、機能、処理部、および処理手段等は、それらの一部又は全部を、例えば仮想マシンで設計する等によりクラウドシステムで実現してもよい。
また、上記の各構成、および機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。 各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、SSD(Solid State Drive)等の記録装置、または、ICカード、SDカード、DVD等の記録媒体に置くことができる。
また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
また、本発明の各構成要素は、任意に取捨選択することができ、取捨選択した構成を具備する発明も本発明に含まれる。さらに特許請求の範囲に記載された構成は、特許請求の範囲で明示している組合せ以外にも組み合わせることができる。