(57)【要約】【課題】  音響センサー部からの情報に基づいて、種々のアクティビティーに対応したロギング情報を適切に求める情報処理システム及びプログラム等を提供すること。【解決手段】  情報処理システム３００は、アクティビティーにより発生する音響をセンシングする音響センサー１１１を有する音響センサー部からの検出結果情報をネットワーク１０を介して受信する受信処理部３１０と、検出結果情報に基づいて、アクティビティーについてのロギング情報を求めるロギング処理を行う処理部３２０と、ロギング情報を記憶する記憶部３４０を含む。【選択図】      図３
2013210233.tif 000002
【特許請求の範囲】
【請求項１】
アクティビティーにより発生する音響をセンシングする音響センサーを有する音響センサー部からの検出結果情報を、ネットワークを介して受信する受信処理部と、
前記検出結果情報に基づいて、前記アクティビティーについてのロギング情報を求めるロギング処理を行う処理部と、
前記ロギング情報を記憶する記憶部と、
を含むことを特徴とする情報処理システム。
【請求項２】
請求項１において、
前記処理部は、
前記アクティビティーの発生頻度情報が、時間情報に関連づけられた情報を、前記ロギング情報として求めることを特徴とする情報処理システム。
【請求項３】
請求項２において、
前記処理部は、
前記検出結果情報に基づいて、前記アクティビティーが発生したか否かの判定処理を行い、前記判定処理の結果に基づいて前記発生頻度情報を求めることを特徴とする情報処理システム。
【請求項４】
請求項３において、
前記処理部は、
前記発生頻度情報に基づいて、前記判定処理の判定レベルを制御することを特徴とする情報処理システム。
【請求項５】
請求項４において、
前記処理部は、
前記検出結果情報に基づいて得られた情報と、前記判定レベルの情報を関連づけた情報を、前記ロギング情報として求めることを特徴とする情報処理システム。
【請求項６】
請求項５において、
前記情報処理システムはサーバーシステムであり、
前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記検出結果情報に基づいて得られた情報と前記判定レベルを関連づけた情報である前記ロギング情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含むことを特徴とする情報処理システム。
【請求項７】
請求項１乃至６のいずれかにおいて、
前記処理部は、
前記検出結果情報により表される音響レベルと、所与の音響閾値との比較処理に基づいて、前記アクティビティーについての前記ロギング情報を求めることを特徴とする情報処理システム。
【請求項８】
請求項７において、
前記処理部は、
前記検出結果情報に基づいて、前記音響レベルが前記音響閾値を超えた回数の総和である総和回数情報、又は前記音響レベルが前記音響閾値を超えた期間の長さの総和である総和期間情報を、前記ロギング情報として各計測期間ごとに求めることを特徴とする情報処理システム。
【請求項９】
請求項８において、
前記処理部は、
前記総和回数情報又は前記総和期間情報を前記ロギング情報として求める第１のロギング処理と、前記総和回数情報及び前記総和期間情報とは異なるデータ構造の情報を前記ロギング情報として求める第２のロギング処理のうちの一方の処理を、前記ロギング処理として実行することを特徴とする情報処理システム。
【請求項１０】
請求項９において、
前記処理部は、
前記総和回数情報が所与の回数閾値を超えるまで、又は前記総和期間情報が所与の期間閾値を超えるまでは、前記第１のロギング処理を前記ロギング処理として実行し、
前記総和回数情報が前記回数閾値を超えた場合、又は前記総和期間情報が前記期間閾値を超えた場合には、前記第２のロギング処理を前記ロギング処理として実行することを特徴とする情報処理システム。
【請求項１１】
請求項９又は１０において、
前記処理部は、
前記音響レベルが前記音響閾値を上回ったタイミングである第１のタイミングに対応する前記時間情報、及び前記音響レベルが前記音響閾値を下回ったタイミングである第２のタイミングに対応する前記時間情報の少なくとも一方を、前記第２のロギング処理における前記ロギング情報として求めることを特徴とする情報処理システム。
【請求項１２】
請求項１１において、
前記処理部は、
前記時間情報に対して、前記第１のタイミングと前記第２のタイミングのいずれに対応するかを表す情報を関連づけた情報を、前記第２のロギング処理における前記ロギング情報として求めることを特徴とする情報処理システム。
【請求項１３】
請求項７乃至１２のいずれかにおいて、
前記情報処理システムはサーバーシステムであり、
前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記検出結果情報に基づいて得られた情報と前記音響閾値を関連づけた情報である前記ロギング情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含むことを特徴とする情報処理システム。
【請求項１４】
請求項１乃至１３のいずれかにおいて、
前記処理部は、
前記ロギング情報と、所与の日常パターンとの比較処理を行い、前記比較処理により前記ロギング情報が前記日常パターンとは異なると判定された場合には、アラーム情報を出力することを特徴とする情報処理システム。
【請求項１５】
請求項１４において、
前記情報処理システムはサーバーシステムであり、
前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記アラーム情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含むことを特徴とする情報処理システム。
【請求項１６】
アクティビティーにより発生する音響をセンシングする音響センサーを有する音響センサー部からの検出結果情報を、ネットワークを介して受信する受信処理部と、
前記検出結果情報に基づいて、前記アクティビティーについてのロギング情報を求めるロギング処理を行う処理部と、
前記ロギング情報を記憶する記憶部として、
コンピューターを機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理システム及びプログラム等に関する。
【背景技術】
【０００２】
従来、音響センサーにより種々のアクティビティーを音響イベントとして捉える手法が知られている。典型的には、カメラ等の機器では検出が困難な、地下でのアクティビティーの検出に用いることが想定される。
【０００３】
地面に耳をつけることで、地上を走る車の音や人の足音を聞くことができる、或いは地震の時に地鳴りがする、といったことから容易に理解できるように、音は地上に限定されず地下をも伝わる現象である。つまり、地下で何らかのアクティビティーが発生した場合には、当該アクティビティーに起因して音が発生し、発生した音は地下を伝わっていく。その音を音響センサーでセンシングすることで、アクティビティーの発生を検出することができる。
【０００４】
例えば、特許文献１では、地中埋設体と地下管路の貫通状態を音響センサーで判定する手法が開示されている。特許文献１の手法を用いることで、地中を掘削することなく、地下の状態を判定することができる。ただし特許文献１は、貫通状態に応じて、地中埋設体の地上露出部分をハンマーでたたいた際の音響に差異が生じることに基づいて、貫通しているか否かを判定しており、厳密には貫通したというアクティビティーにより発生した音を認識しているわけではない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開平７−１９４５９７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
音響センサーを用いた手法は、カメラを用いたりユーザーによる視認を行ったりする手法と比べた場合に、視覚的な制約を受けないという利点がある。例えば、上述したように地下でのアクティビティーの検出の際には、地中を掘削するという労力が不要になる。また、地上でのアクティビティーの検出の際にも、壁等の遮蔽物の裏側で起こっているアクティビティーにも対応可能である。
【０００７】
一方で、音響センサーは判定の対象としているアクティビティー以外に起因する音の影響を受けやすいという問題もある。例えば、地上で強風が吹いている場合などは、風の音の影響が大きく、所望のアクティビティーに起因する信号が相対的に小さくなってしまう。よって、周囲の環境やその他要因を考慮して、センサー信号に対して適切な処理を行わないと、精度のよいアクティビティー検出は困難である。しかし、従来手法では音響イベントの処理を動的に変更する手法等は開示されていない。
【０００８】
本発明の幾つかの態様によれば、音響センサー部からの情報に基づいて、種々のアクティビティーに対応したロギング情報を適切に求める情報処理システム及びプログラム等を提供することができる。
【課題を解決するための手段】
【０００９】
本発明の一態様は、アクティビティーにより発生する音響をセンシングする音響センサーを有する音響センサー部からの検出結果情報を、ネットワークを介して受信する受信処理部と、前記検出結果情報に基づいて、前記アクティビティーについてのロギング情報を求めるロギング処理を行う処理部と、前記ロギング情報を記憶する記憶部と、を含む情報処理システムに関係する。
【００１０】
本発明の一態様では、ネットワークを介して音響センサー部からの検出結果情報を受信し、受信した検出結果情報に基づいてロギング処理を行う。これにより、ネットワークを介して接続された音響センサー部からの情報に基づいて、適切なロギング処理を行うこと等が可能になる。
【００１１】
また、本発明の一態様では、前記処理部は、前記アクティビティーの発生頻度情報が、時間情報に関連づけられた情報を、前記ロギング情報として求めてもよい。
【００１２】
これにより、アクティビティーの発生頻度情報と時間情報を関連づけた情報を求めることができるため、アクティビティーの発生状況を理解しやすい形式でユーザーに提示すること等が可能になる。
【００１３】
また、本発明の一態様では、前記処理部は、前記検出結果情報に基づいて、前記アクティビティーが発生したか否かの判定処理を行い、前記判定処理の結果に基づいて前記発生頻度情報を求めてもよい。
【００１４】
これにより、発生頻度情報を検出結果情報に基づいて求めることが可能になる。
【００１５】
また、本発明の一態様では、前記処理部は、前記発生頻度情報に基づいて、前記判定処理の判定レベルを制御してもよい。
【００１６】
これにより、検出対象アクティビティーによらずに検出結果情報が変動する場合等でも、適切に発生頻度情報、及び発生頻度情報と時間情報を関連づけたロギング情報等を求めることが可能になる。
【００１７】
また、本発明の一態様では、前記処理部は、前記検出結果情報に基づいて得られた情報と、前記判定レベルの情報を関連づけた情報を、前記ロギング情報として求めてもよい。
【００１８】
これにより、変更制御されることが想定される判定レベルの情報を、ロギング情報に含めること等が可能になる。
【００１９】
また、本発明の一態様では、前記情報処理システムはサーバーシステムであり、前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記検出結果情報に基づいて得られた情報と前記判定レベルを関連づけた情報である前記ロギング情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含んでもよい。
【００２０】
これにより、情報処理システムをサーバーシステムで実現し、上記ロギング情報をネットワークを介して接続されたクライアント装置に送信すること等が可能になる。
【００２１】
また、本発明の一態様では、前記処理部は、前記検出結果情報により表される音響レベルと、所与の音響閾値との比較処理に基づいて、前記アクティビティーについての前記ロギング情報を求めてもよい。
【００２２】
これにより、音響レベルと音響閾値との比較処理に基づいてロギング情報を求めること等が可能になる。
【００２３】
また、本発明の一態様では、前記処理部は、前記検出結果情報に基づいて、前記音響レベルが前記音響閾値を超えた回数の総和である総和回数情報、又は前記音響レベルが前記音響閾値を超えた期間の長さの総和である総和期間情報を、前記ロギング情報として各計測期間ごとに求めてもよい。
【００２４】
これにより、総和回数情報又は総和期間情報をロギング情報として求めることが可能になる。
【００２５】
また、本発明の一態様では、前記処理部は、前記総和回数情報又は前記総和期間情報を前記ロギング情報として求める第１のロギング処理と、前記総和回数情報及び前記総和期間情報とは異なるデータ構造の情報を前記ロギング情報として求める第２のロギング処理のうちの一方の処理を、前記ロギング処理として実行してもよい。
【００２６】
これにより、ロギング処理を切り替えることで、求めるロギング情報のデータ構造を変更すること等が可能になる。
【００２７】
また、本発明の一態様では、前記処理部は、前記総和回数情報が所与の回数閾値を超えるまで、又は前記総和期間情報が所与の期間閾値を超えるまでは、前記第１のロギング処理を前記ロギング処理として実行し、前記総和回数情報が前記回数閾値を超えた場合、又は前記総和期間情報が前記期間閾値を超えた場合には、前記第２のロギング処理を前記ロギング処理として実行してもよい。
【００２８】
これにより、総和回数情報と回数閾値との比較処理の結果、又は総和期間情報と期間閾値との比較処理の結果に基づいて、ロギング情報のデータ構造を変更すること等が可能になる。
【００２９】
また、本発明の一態様では、前記処理部は、前記音響レベルが前記音響閾値を上回ったタイミングである第１のタイミングに対応する前記時間情報、及び前記音響レベルが前記音響閾値を下回ったタイミングである第２のタイミングに対応する前記時間情報の少なくとも一方を、前記第２のロギング処理における前記ロギング情報として求めてもよい。
【００３０】
これにより、総和回数情報や総和期間情報とは異なるデータ構造のロギング情報として、第１、第２のタイミングに対応する時間情報を求めることが可能になり、より詳細な情報を取得することができる。
【００３１】
また、本発明の一態様では、前記処理部は、前記時間情報に対して、前記第１のタイミングと前記第２のタイミングのいずれに対応するかを表す情報を関連づけた情報を、前記第２のロギング処理における前記ロギング情報として求めてもよい。
【００３２】
これにより、時間情報が第１、第２のタイミングのいずれに対応するかの情報をロギング情報に含めること等が可能になる。
【００３３】
また、本発明の一態様では、前記情報処理システムはサーバーシステムであり、前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記検出結果情報に基づいて得られた情報と前記音響閾値を関連づけた情報である前記ロギング情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含んでもよい。
【００３４】
これにより、情報処理システムをサーバーシステムで実現し、上記ロギング情報をネットワークを介して接続されたクライアント装置に送信すること等が可能になる。
【００３５】
また、本発明の一態様では、前記処理部は、前記ロギング情報と、所与の日常パターンとの比較処理を行い、前記比較処理により前記ロギング情報が前記日常パターンとは異なると判定された場合には、アラーム情報を出力してもよい。
【００３６】
これにより、ロギング情報と日常パターンとの比較処理に基づいて、異常が発生しているかを判定すること等ができ、異常発生時等にはアラート情報を出力しユーザーに警告を発することが可能になる。
【００３７】
また、本発明の一態様では、前記情報処理システムはサーバーシステムであり、前記サーバーシステムに前記ネットワークを介してクライアント装置が通信接続されている場合に、前記アラーム情報を、前記ネットワークを介して前記クライアント装置に送信する送信処理部を含んでもよい。
【００３８】
これにより、情報処理システムをサーバーシステムで実現し、上記アラート情報をネットワークを介して接続されたクライアント装置に送信すること等が可能になる。
【００３９】
また、本発明の他の態様は、上記の各部としてコンピューターを機能させるプログラムに関係する。
【図面の簡単な説明】
【００４０】
【図１】本実施形態のセンサーシステムの構成例。
【図２】音響センサー部の構成例。
【図３】本実施形態の情報処理システムを含むシステムの構成例。
【図４】音響センサー部の他の構成例。
【図５】音響センサーのセンサー情報の例。
【図６】閾値判定処理後の信号の例。
【図７】波形整形回路の出力信号の例。
【図８】図８（Ａ）〜図８（Ｃ）はロギング情報の例。
【図９】本実施形態のロギング処理を説明するフローチャート。
【図１０】計測処理の全体の流れを説明するフローチャート。
【図１１】モードＢ又はモードＣでの計測処理を説明するフローチャート。
【図１２】モードＡでの計測処理を説明するフローチャート。
【図１３】センシング感度又は判定レベルの制御を説明するフローチャート。
【図１４】ロギング情報に基づいて取得されるグラフの例。
【発明を実施するための形態】
【００４１】
以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
【００４２】
１．本実施形態の手法
まず本実施形態の手法について説明する。従来、何らかのアクティビティーを音響センサーを用いて検出する手法が知られている。音響センサーを用いることで、地下のアクティビティー、或いは遮蔽物の多い状況でのアクティビティー等、視覚的な検出が困難なものも検出可能となる。
【００４３】
音響センサーを用いれば、例えば、地下工事現場等での空洞の崩落や、地下埋設物（水道管、ガス管等）の破損等を地面の掘削を行わなくても検出することができる。また、防犯用の監視システム等で用いる場合には、室内に設置したとしても壁を隔てた庭や、廊下、隣の室内等までカバーすることができる。監視システムでは、監視カメラ等の存在をアピールすることで防犯効果を高めることもできるが、それが逆に威圧感を与えてしまい好ましくない状況も考えられる。その点、音響センサーを用いる場合には、直接視認できない場所（例えば箱の中等）に設置したとしても検出精度の低下は大きくないため、監視システムの存在を目立たせなくすることもできる。
【００４４】
このような手法を考えた場合、音響センサーによるセンシングが短期的に行われることも十分考えられる。例えば、水道管の破損検出であれば、数ヶ月に１回程度の頻度で検査を行い、１回あたりの検査は数分〜数十分程度のセンシングしか行わないような使い方が考えられる。しかし、検出対象となるアクティビティーによっては、長期間センシングを行いロギング情報を取得することが望ましいケースもある。例えば、工事現場での空洞の崩落等は避ける必要がある。よって、工事の開始から終了までは常時センシングすることが望ましいといえる。また、監視システムで用いるのであれば、常時且つ長期間動作しなければ効果を発揮しない。
【００４５】
しかし、ロギング処理を行うことを想定した場合には問題が生じる。アクティビティーにより発生する音響イベントが特定の周波数を有する等の特段の事情がない限り、ロギング処理は音響センサーのセンサー情報により表される値（以下、音響レベルとも表記する）に基づいて行うことになる。しかし、音響レベルをそのまま用いても、アクティビティーの有無の判定は困難である。なぜなら、設置場所、時間帯、環境変化等に応じて、検出対象となるアクティビティーが発生していない状態での音響レベルが異なる可能性があるためである。
【００４６】
例えば、空洞崩落を検出対象アクティビティーとして説明する。検出領域が森の中等であれば崩落以外の音源が多くないため検出は容易であるのに対して、都市部では人の歩行や車の走行等、さまざまな音源が近くに存在しうるため、検出対象アクティビティーの非発生時であっても音響レベルが大きいことがありえる。つまり、単純に音響レベルの大小を判定するだけでは、検出対象アクティビティーの発生の有無を判定することができない。よって、検出対象アクティビティー、及び検出対象ではないアクティビティーの全てに起因する音響イベントの状況に応じて、音響レベルに基づく処理を適切に切り替える必要がある。
【００４７】
同様に、同一の設置箇所においても、時間帯による変動があり、例えば通勤時間帯を中心とする昼間は、車の音等により音響レベルが大きいのに対して、夜間では音響レベルが小さくなる。つまり、時間帯に応じても音響レベルに基づく処理を変更する必要がある。さらに、天候の変動等による影響も考えられ、例えば音響センサーは風の音を拾ってしまうため、台風が接近した場合等には音響レベルは非常に大きくなる。この場合、台風が接近しているか否かで処理を切り替えることが望ましい。
【００４８】
特に、地下のアクティビティーを効率的に検出するために、音響センサー（及び必要に応じてはロギング処理を行う処理部等）を地下に設置する場合には、ユーザーによるメンテナンスが容易でないため、システムにより自律的に処理内容を変更することの利点は大きい。
【００４９】
そこで本出願人は、長期間のロギング処理を適正に行うために、処理内容を動的に変更する手法を提案する。具体的には、ロギング情報を求める際に音響レベルをそのまま用いるのではなく、過去の履歴等からセンシング感度（或いは判定レベル）を制御する。このようにすれば、ユーザーが逐一設定しなくても、アクティビティーに対応したロギング情報を適切に取得することが可能になる。
【００５０】
また、処理内容の変更はセンシング感度等の変更にとどまらず、ロギング処理の結果として取得されるロギング情報の形式についても考慮することが望ましい。検出対象ではないアクティビティーによっても音響レベルが変動することに鑑みれば、音響センサーのセンサー情報をそのままロギング情報として取得しても、ユーザーは直感的に検出対象アクティビティーの有無を判定することはできない。よって、ユーザーによる何らかの処理が必要となるためユーザー負担が問題となる。さらに、センサー情報を再現可能な程度の情報量を記憶するとなると、記憶部の容量等も問題となる。
【００５１】
特に音響センサー等が地下に設置される場合には、記憶容量の制限が大きくなるためロギング情報についても適切な形式をとる必要性が増す。なお、取得したロギング情報を即座に地上のホスト等に送信してしまうことで、記憶容量の問題を回避するアプローチも考えられるが、その場合には高頻度での通信が必要となるため、消費電力の観点から現実的ではない。
【００５２】
以上のことから、本実施形態の処理は、検出対象アクティビティーの非発生時でも音響レベルが変動すること等による悪影響を抑止する処理を、音響センサーのセンサー情報に対して行う第１のステップと、第１のステップにより得られた信号からロギング情報を求める第２のステップを含むものとする。
【００５３】
以下、装置全体が一体となるセンサーシステム（この場合、センサーシステム全体が地下に設置されることが想定されるが、これに限定されない）の構成例と、音響センサー部分と処理部等が別体として構成される情報処理システムの構成例について述べる。その後、第１のステップである、検出対象でないアクティビティーの発生時にも音響レベルが変動すること等を考慮した処理と、第２のステップであるロギング情報の取得処理について説明する。最後にフローチャートを用いて処理の詳細を説明する。
【００５４】
２．システム構成例
ここでは、音響センサーを含む部分と、ロギング処理を行う部分が一体として設けられる場合と、別体として設けられる場合に分けて説明する。一体の例としては、センサーシステム（図１に示したように音響センサー部１１０と処理部１２０を含む）について図１を用いて説明する。別体の例としては、情報処理システム（図５に示したように処理部３２０は含むが、音響センサー部１１０−１等は含まない）について図３を用いて説明する。
【００５５】
２．１  センサーシステムの構成例
図１にセンサーシステムの構成例を示す。図１に示したように、センサーシステム１００は、音響センサー部１１０と、処理部１２０と、通信部１３０と、記憶部１４０と、タイマー１５０を含む。ただし、センサーシステムは図１の構成に限定されず、これらの一部の構成要素を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
【００５６】
音響センサー部１１０は、図２に示したように音響センサー１１１と、アンプ１１２と、閾値判定部１１３と、波形整形回路１１４と、ゲインレジスター１１５と、シリアル受信回路１１６を含むことができる。ただし、音響センサー部１１０は図２の構成に限定されず、これらの一部の構成要素を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。
【００５７】
音響センサー１１１は、アクティビティーによる音響をセンサー情報として取得する。音響センサー１１１のセンサー情報により表される信号値を音響レベルとも表記する。アンプ１１２はセンサー情報に対して増幅処理を行う。アンプ１１２での増幅率は設定により変更可能である。閾値判定部１１３は、アンプ１１２で増幅されたセンサー情報により表される信号値（この値も音響レベルに含める）と所与の音響閾値との比較処理を行う。閾値判定部１１３の出力は、例えば音響レベルが音響閾値を超えた場合に１となり、超えない場合に０となる２値の信号であってもよい。波形整形回路１１４は、閾値判定部１１３からの信号を入力値として、波形整形の処理を行う。波形整形回路１１４は、例えばチャタリング防止回路、微分回路、デューティ検出回路、またはこれらの組合わせであってもよい。
【００５８】
また、音響センサー部１１０は、アンプ１１２での増幅率を制御するために、処理部１２０からの指示を受け付けるシリアル受信回路１１６と、指示されたゲイン値を保持するゲインレジスター１１５を含んでもよい。
【００５９】
処理部１２０は、音響センサー部１１０からの出力（アクティビティーの検出結果を表す検出結果情報）に基づいてロギング情報を生成する。処理部１２０は、センシング感度制御部１２３と、ロギング情報生成部１２５を含んでもよい。
【００６０】
センシング感度制御部１２３は、音響センサー部１１０でのセンシング感度を制御する。センシング感度制御部１２３での制御は、上述した第１のステップでの処理に相当するものであり、詳細は後述する。
【００６１】
ロギング情報生成部１２５は、検出結果情報に基づいてロギング情報を生成する。ロギング情報生成部１２５での処理は、上述した第２のステップでの処理に相当し、ロギング情報の具体例、及び生成手法の詳細は後述する。
【００６２】
通信部１３０は、処理部１２０で生成されたロギング情報を外部機器に対して送信する。センサーシステム１００は地下に設置されることが想定されるため、通信部１３０は無線通信により実現されることが望ましいが、有線通信であってもよい。また、センサーシステム１００で用いられるパラメーター（センシング感度等を含む）は、センサーシステム１００内で自律的に制御できるが、外部機器２００からの指示により制御されてもよく、通信部１３０は、その場合のパラメーター情報を受信する。
【００６３】
記憶部１４０は、処理部１２０で生成されたロギング情報を記憶するとともに、処理部１２０等のワーク領域となるもので、その機能はＲＡＭ等のメモリーやＨＤＤ（ハードディスクドライブ）などにより実現できる。
【００６４】
タイマー１５０は、時間情報（狭義には時刻情報）を取得するものであり、例えば年月日や時分秒等を含む実時間情報を取得するものであってもよい。ロギング情報は時系列的にまとめられた情報であることが望ましいため、処理部１２０は、タイマー１５０からの時刻情報（或いは時刻情報に基づき取得された時間情報）と、検出結果情報に基づき取得された情報とを関連づけた情報を、ロギング情報として生成することが考えられる。
【００６５】
２．２  情報処理システムの構成例
図３に情報処理システムを含むシステムの構成例を示す。図３に示したように、このシステムは、Ｎ個の音響センサー部１１０−１〜１１０−Ｎと、情報処理システム３００と、クライアント装置４００とを含み、それらはネットワーク１０を介して接続されている。
【００６６】
ネットワーク１０は、移動通信網、インターネット網等の公衆網、或いは固定電話網等を含むことができる。移動通信網は、ＣＤＭＡ（Code division multiple Access，登録商標）方式やＰＤＣ（personal Digital Cellular）方式等の移動電話網や、ＰＤＣ−Ｐ（PDC-Packet）方式等の移動データ通信網を含むことができる。また、ネットワーク１０はＷＡＮ（Wide Area Network）やＬＡＮ（Local Area Network）などにより実現することができ、有線・無線を問わない。
【００６７】
音響センサー部１１０−１〜１１０−Ｎは、それぞれ図４に示したように、音響センサー１１１と、通信部１１７を含む。通信部１１７は、音響センサー１１１のセンサー情報をネットワーク１０に対して送信する。つまりこの例では、音響センサー部１１０−１〜１１０−Ｎは、音響センサー１１１のセンサー情報をそのまま送信しても良い。あるいは、図２に示した回路構成の一部を含むようにしても良い。例えば、アンプ１１２による増幅や波形整形を行っても良い。
【００６８】
情報処理システム３００は、受信処理部３１０と、処理部３２０と、送信処理部３３０と、記憶部３４０と、タイマー３５０を含む。ただし、情報処理システム３００は図３の構成に限定されず、これらの一部の構成要素を省略したり、他の構成要素を追加するなどの種々の変形実施が可能である。情報処理システム３００は、例えばサーバーシステム等であってもよい。
【００６９】
受信処理部３１０は、音響センサー部１１０−１〜１１０−Ｎからの検出結果情報（ここではセンサー情報を想定）を取得し、処理部３２０に出力する。
【００７０】
処理部３２０は、増幅部３２１と、閾値判定部３２２と、判定レベル制御部３２３と、ロギング情報生成部３２５を含む。
【００７１】
増幅部３２１は、受信した検出結果情報に対して増幅処理を行う。増幅部３２１において図２のアンプ１１２での処理を行っても良い。閾値判定部３２２は、増幅処理後の検出結果情報により表される値（この値も上述した音響レベルに含めるものとする）と、所与の音響閾値との比較処理を行う。これは図２の閾値判定部１１３での処理に相当する。つまり、図３のシステムでは、音響センサー部１１０−１等が、図４に示したように図２に比べて簡略化された分、増幅処理や閾値判定処理が処理部３２０において行われることになる。
【００７２】
判定レベル制御部３２３は、判定レベルの制御を行う。これは図１のセンシング感度制御部１２３での処理に相当する。ロギング情報生成部３２５での処理は、図１のロギング情報生成部１２５での処理と同様であるため、詳細な説明は省略する。
【００７３】
記憶部３４０は図１の記憶部１４０と同様であり、タイマー３５０は図１のタイマー１５０と同様であるため、これについても詳細な説明は省略する。
【００７４】
クライアント装置４００は、ロギング情報を参照するユーザーにより操作される装置が想定され、情報処理システム３００に対してロギング情報の取得リクエストを送信し、レスポンスとしてロギング情報を取得する。クライアント装置４００は表示部を含んでもよく、取得したロギング情報を当該表示部に表示することでユーザーに対して提示する。
【００７５】
なお、図３、図４では、音響センサー部１１０−１等の構成が簡略化され、その分の処理が処理部３２０で行われるものとしたがこれに限定されない。例えば、音響センサー部１１０−１等は図２と同様の構成でもよく、その場合、処理部３２０の構成は図１の処理部１２０と同様になる。そして、センシング感度制御部１２３からの制御情報は、ネットワーク１０を介して音響センサー部１１０−１等に送信されることになる。
【００７６】
３．音響センサーのセンサー情報に対する処理
音響センサー１１１の出力であるセンサー情報に対する処理について説明する。ここでは図１、図２のセンサーシステム１００を例に説明するが、図３、図４のシステムにおいて同様の処理を行ってもよい。その場合、アンプ１１２を増幅部３２１に、閾値判定部１１３を閾値判定部３２２に、センシング感度制御部１２３を判定レベル制御部３２３に置き換えて考えればよい。
【００７７】
上述したように、検出対象ではないアクティビティーによっても音響レベル（音響センサー１１１から出力されるセンサー情報の値）が変動することを考慮しなければ適切なロギング処理は行えない。検出対象ではないアクティビティーにより音響レベルが変動したとしても、検出対象アクティビティーの発生の有無を適切に判定するための手法は種々考えられるが、ここでは基準値との比較処理を行い、当該基準値を可変にするものとする。つまり、検出対象でないアクティビティーにより音響レベルが高くなる場合には、基準値が高くなるように設定し、そうでなければ基準値が低くなるように設定する。
【００７８】
本実施形態では、基準値の設定はアンプ１１２での増幅率、又は閾値判定部１１３で用いられる音響閾値の値の少なくとも一方を制御することで行う。例えば、検出対象でないアクティビティーにより音響レベルが高くなる場合には、センサー出力である音響レベルが大きかったとしても、基準値を超えないようにすればよいため、増幅率を小さくする制御、及び音響閾値を大きくする制御の少なくとも一方を行えばよい。逆の場合には、比較的小さな音響レベルの変動であっても、基準値を超えるようにしたいため、増幅率を大きくする制御、及び音響閾値を小さくする制御の少なくとも一方を行う。
【００７９】
図５に音響センサー１１１の出力であるセンサー情報の信号波形の例を示す。図５に示したように、センサー情報は音響に応じた信号値の変動を表す波形となる。アンプ１１２による増幅処理後も、信号レベルが変化するものの、基本的な波形は図５と同様である。
【００８０】
閾値判定部１１３では、音響レベルと音響閾値との比較処理が行われ、音響レベルが音響閾値を超えたか否かの情報を表す信号波形を取得する。具体的には、図６に示したように、音響レベルが音響閾値を超えている期間で値が１となり、そうでない期間で値が０となる２値信号波形となる。ロギング情報の具体的な形式については後述するが、図６の２値信号波形に基づき、ロギング情報を生成することが可能である。
【００８１】
ただし、処理部１２０への出力信号は図６のものに限定されず、図２に示したように波形整形回路１１４による処理を行ってもよい。波形整形回路１１４として、微分回路を用いることで、図７に示したように、２値信号波形において、０から１へと変化する第１のタイミング（立ち上がりタイミング）、及び１から０へと変化する第２のタイミング（立ち下がりタイミング）に対応するタイミングで、その値が１となる信号を取得することができる。本実施形態では、図７で示した信号を処理部１２０への出力としてもよい。
【００８２】
上述した増幅率や音響閾値の制御は、センシング感度制御部１２３において行われる。検出対象でないアクティビティーによる音響レベルの変動は、予測が可能なもの（例えば１回設置してしまえばほとんど変化しない場合、１日を単位とした周期性がある場合等）もあるが、必ずしも予測通りになるとは限らないため、本実施形態では実際に取得された信号に基づいて増幅率等の制御を行う。
【００８３】
具体的には、所与の計測期間（例えば３０分や１時間等）を単位として、図６に示した波形において、各計測期間のうちどれだけの期間で値が１となったかを求め、１となった期間が長い場合には、センシング感度を下げる（増幅率を下げるか、音響閾値を上げる）処理を行うものとする。逆に、１となった期間が短ければ、センシング感度を上げればよい。この制御は例えば、閾値Ｔｈ１とＴｈ２（＞Ｔｈ１）を用いて、１となった期間Ｔが、Ｔ＜Ｔｈ１の場合にはセンシング感度を上げ、Ｔｈ１≦Ｔ＜Ｔｈ２の場合にはセンシング感度を維持し、Ｔｈ２≦Ｔの場合にはセンシング感度を下げることで実現してもよい。
【００８４】
また、他の手法としては、図７の波形を用いて、上記各計測期間における立ち上がりの回数をカウントし、カウント値が大きい場合にセンシング感度を下げ、カウント値が小さい場合にセンシング感度を上げてもよい。
【００８５】
なお、図６の信号で値が１となっている期間や、図７の波形での立ち上がりの回数等は、後述するようにロギング情報（具体的には総和期間情報や総和回数情報）として求められることが想定される。よって、センシング感度制御用の指標値を算出する処理を別途設ける必要はなく、ロギング情報生成部１２５で生成されたロギング情報をそのまま用いてもよい。
【００８６】
４．ロギング情報の例
次にロギング情報の具体例について説明する。上述したように、センサー情報である図５の波形からは検出対象アクティビティーの有無を直感的に理解することは難しく、ここでは閾値判定部１１３での処理後の図６の波形を用いる。つまり、ロギング情報は図６の波形の特性を反映するものを用いることになる。狭義には図６の波形を完全に再現できるだけの情報をロギング情報としてもよく、この例をモードＡとして説明する。また、図６の波形のうち必要な特徴が反映されていれば、一部情報が捨てられたとしても問題ない場合もある。具体例をモードＢ、モードＣとして後述する。
【００８７】
まずモードＡについて説明する。この方式では、生成したロギング情報から図６の波形を再現することが求められる。よって例えば、デジタル信号の取得タイミングごとの信号値をそのまま記憶する手法が考えられる。これは、デジタル信号の取得間隔をｔとした場合に、時刻Ｔでの信号値は０、時刻Ｔ＋ｔでの信号値は０、時刻Ｔ＋２ｔの信号値は１、といったように、ｔの取得間隔で全てのデータを保存するものである。しかし、ｔの大きさは十分小さく（例えば長くても１秒に満たない程度）、長期間のロギング処理を行った場合データ量が膨大なものになってしまう。
【００８８】
そこで本実施形態では、図６で信号値が変化したタイミング、つまり、図７で示した立ち上がり又は立ち下がりのタイミングの時刻情報を記憶するものとする。具体例を図８（Ａ）に示す。例えば、時刻Ｔ１（形式としては図８（Ａ）に示したように、年月日時刻分を含むものが考えられる）で立ち上がりが発生し、時刻Ｔ２で立ち下がりが発生、時刻Ｔ３で立ち上がりが発生、といったように図６での信号波形の変化タイミングを記録すればよい。この場合、音響センサー部１１０からの出力は図６の信号であってもよいが、図７の信号の方が処理が容易であり、図７の信号値が１となったタイミングの時刻情報をタイマー１５０から取得してロギング情報とすればよい。
【００８９】
このようにすることで、立ち上がり立ち下がりの時刻情報から図６の波形を再現し、値が１の期間や、当該期間の総和等を求めることができる。しかし、波形が再現できたとしても、それだけでは音響レベルに関する情報が欠落してしまっている。上述したように、検出対象アクティビティーの有無の判定という観点で考えれば、基準値との比較処理を行えばよく、音響レベル（図５の波形の信号値に対応）そのものは重要ではないため、閾値判定部１１３において閾値判定を行っている。しかし、本実施形態のシステムは検出対象アクティビティーに限定されない周囲環境の変化等を検出することにも用いることができるため、音響レベルの情報を完全に失ってしまうのは好ましくない。ただし、データ量を考慮すれば図５の波形を完全に再現する必要はなく、ここではセンシング感度を記憶するものとする。センシング感度がわかれば、増幅率と音響閾値がわかるため、それと再現した図６の波形を組み合わせることで音響レベルの概要を知ることが可能である。例えば、図６の波形で信号値が１の期間とは、増幅後の音響レベルが音響閾値を上回っているということがわかるし、値が０の期間はそうではないということがわかる。
【００９０】
なお、センシング感度は上述したように所与の計測期間（３０分や１時間等）ごとに変動しうるため、当該計測期間を１単位とした場合に、図８（Ａ）に示したように１つのセンシング感度を表す情報と、立ち上がり立ち下がりの回数に相当するだけの時刻情報、及び各時刻情報が立ち上がりと立ち下がりのいずれに対応するかを表す情報からロギング情報が構成されることになる。
【００９１】
ここで、ロギング情報のさらなるデータ量の削減を図ってもよい。例えば、全ての時刻情報が年月日時刻分の情報を持つ必要はなく、最初の１つを年月日時刻分で記憶し、２つめ以降の時刻情報は上記最初の時刻情報との差分値（例えばｍｍ／ｓｓ等の形式）で表現してもよい。また、信号波形が正常であれば、立ち上がりが連続する、或いは立ち下がりが連続するということはないため、最初の時刻情報にだけ立ち上がりと立ち下がりのいずれに対応するかを表す情報を関連づけ、それ以降の時刻情報には特に立ち上がり等を表す情報を関連づけなくてもよい。この場合、２つめ以降の時刻情報の立ち上がり立ち下がりについては、ロギング情報を読み出して処理する際に、直前の時刻情報とは異なる状態を対応づければよい。
【００９２】
次にモードＢについて説明する。モードＢでは各計測期間（３０分や１時間等）のうち、どれだけの期間で音響レベルが音響閾値を超えていたかを表す情報（総和期間情報）をロギング情報とする。この場合、音響レベルが音響閾値を超えていたタイミング等の情報は失われるため、ロギング情報から図６の波形を再現することはできないが、モードＡに比べてデータ量を非常に小さくでき、且つ検出対象アクティビティーの発生有無の判別には十分であるため有用である。
【００９３】
音響レベルが音響閾値を超えていた期間を求める手法は種々考えられる。例えば、音響センサー部１１０から図６の信号を取得するのであれば、各計測期間内で、音響センサー部１１０から１が出力された回数をカウントすればよい。なお、このカウント値をそのままロギング情報としてもよいし、秒単位での情報に変換してもよい。変換は例えばカウント値と、信号値取得間隔との積を取ればよい。
【００９４】
また、音響センサー部１１０から図７の信号を取得する場合に、立ち上がりタイミングでの時刻情報と、立ち下がりタイミングでの時刻情報との差分を求め、各計測期間内で求めた差分値の総和をロギング情報とすればよい。なお、立ち上がりが起きた後、立ち下がりが起きることなく前記計測期間が終了することもあり得るため、その場合には立ち上がりタイミングと計測期間の終了タイミングの差分を求める処理等が必要となる。
【００９５】
なお、ロギング情報とは時系列的な解析に用いられることが想定されるため、総和期間情報だけでなく、当該総和期間情報の取得タイミング等を表す情報も併せて記憶することが望ましい。具体的には、上記計測期間を表す情報を記憶すればよく、計測期間の継続時間（３０分や１時間等）が固定であれば、計測期間の開始タイミングを表す時刻情報を記憶すればよい。ただし、計測期間に関する情報の形式はこれに限定されず、例えば開始タイミングの時刻情報と終了タイミングの時刻情報の両方を記憶したり、開始タイミングの時刻情報と継続時間情報（３０分や１時間等に相当する情報）を記憶するものであってもよい。
【００９６】
また、モードＢにおいても、センシング感度の情報をロギング情報に含めてもよいことは同様である。モードＢのロギング情報の一例を図８（Ｂ）に示す。
【００９７】
次にモードＣについて説明する。モードＣでは、各計測期間において図６の波形で何回立ち上がりが起きたかのカウント値（総和回数情報）をロギング情報とする。モードＢと同様に、ロギング情報から図６の波形を再現することはできないが、モードＡに比べてデータ量を非常に小さくでき、且つ検出対象アクティビティーの発生有無の判別には十分であるため有用である。
【００９８】
総和回数情報の取得は、音響センサー部１１０から図６の信号を取得するのであれば、信号値が０から１に切り替わったことを検出した場合にカウンターをインクリメントすればよい。また、音響センサー部１１０から図７の信号を取得するのであれば、単純に信号値が１となる回数をカウントすればよい。
【００９９】
モードＣにおいても、前記計測期間に関する情報、或いはセンシング感度等をあわせて記憶することが望ましいことは同様であり、モードＣでのロギング情報の一例は図８（Ｃ）のようになる。
【０１００】
なお、Ａ〜Ｃの各方式はいずれか１つを用いればよいが、その選択はロギング処理開始時に固定するものであってもよいし、ロギング処理中に動的に変更するものであってもよい。動的に変更する場合には、具体的には、より細かい解析を行いたいケースでは、情報量が多く図６の波形を再現できるモードＡを用い、細かい解析が不要なケースやデータ量削減が重視されるケースでは、モードＢ又はモードＣを用いればよい。
【０１０１】
選択手法は種々考えられるが、直前のロギング処理の結果、総和期間情報又は総和回数情報により表される値が、所与の閾値よりも大きかった場合には、モードＢ又はモードＣからモードＡに変更するものであってもよい。逆に直前のモードＡでのロギング情報から総和期間情報等に相当する情報を求めた結果、それにより表される値が所与の閾値よりも小さい場合には、モードＡからモードＢ又はモードＣに変更する。或いは、センシング感度の変更にあわせる手法でもよく、センシング感度が下げられた場合には、音響レベルが上がっているため詳細な情報が必要と考えモードＡに設定し、センシング感度が上げられた場合には逆にモードＢ又はモードＣに設定してもよい。
【０１０２】
図１４に上記モードＣを用いて取得されたロギング情報を図示した例を示す。図１４の横軸は時間を表し、縦軸は総和回数情報により表される総和回数である。ここでは、センサーシステム１００が地上（具体的にはオフィスの一室）に設置され、人為的なアクティビティーを対象としており、例えば監視システム等としてセンサーシステム１００を用いた場合に相当する。なお図１４のグラフは、上述のセンシング感度制御により、人為的なアクティビティー以外の音響による総和回数情報の変動は抑制されているものである。
【０１０３】
７月１３日、及び７月１５は音響センサー１１１の設置場所付近で頻繁に作業が行われていた。よって、図１４のＡ１に示したように、センサーシステム１００では当該作業や、作業時に行われる会話に起因する音響が検出され、総和回数が非常に大きくなっている。また、７月１４日は作業自体は行われなかったが、平日でオフィスに人がいたため、室内に人が立ち入ったり、或いは廊下を歩いたりしていた。よって、図１４のＡ２に示したように、Ａ１ほどではないが人為的なアクティビティーを検出しており、総和回数は数十程度の値をとっている。
【０１０４】
一方、７月１６日以降は休日となったため、オフィスに人がおらず人為的なアクティビティーはほとんど検出されない。なお、図１４のＡ３に示したものは、警備員による巡回に対応するものであり、毎日決まった時間にアクティビティーが検出されていることがわかる。
【０１０５】
以上のように、本実施形態の手法を用いることで、周囲のアクティビティーを適切に検出できることがわかる。なお、ここでは人為的なアクティビティーを対象とした監視システムを考えたため、Ａ１〜Ａ３のように特に問題とならない状況（平常時）でもアクティビティーが検出されている。この点は、平常時にはアクティビティーが検出されないことを前提とする地下の空洞崩落検出等とは異なる。つまり図１４の場合には、アクティビティーの検出回数が多い（例えば図１４のＡ１の状況）からといって異常であるという判断はできない。よって、日常パターンを設定し、ロギング情報と日常パターンとの比較処理を行って、日常パターンから大きく異なるロギング情報が取得された場合に、異常であると判定するとよい。日常パターンは過去のロギング情報等から求めればよく、例えば図１４の状況であれば平日昼間はアクティビティーの検出回数が多く、平日夜や休日はアクティビティーの検出回数が少ないパターンを設定する。なお、日常パターンと取得したロギング情報との比較処理の手法は種々考えられ、公知のパターンマッチング手法等を用いればよい。
【０１０６】
また、空洞崩落等を検出対象アクティビティーとした場合、理想的には上述したように、正常時ではアクティビティーが検出されず、異常時にアクティビティーが検出されるはずである。しかし、本実施形態では、センシング感度（或いは判定レベル）の制御が３０分や１時間等の計測期間ごとに行われるため、検出対象ではないアクティビティーに起因する音響イベントをアクティビティーであるとして検出する可能性は否定できない。よってこのような場合でも、正常異常の判定をアクティビティーの発生有無だけから判定するのではなく、上記日常パターンに相当する何らかのパターンを用意し、ロギング情報と当該パターンの比較処理を行うことが望ましい。
【０１０７】
５．処理の詳細
本実施形態のロギング処理の詳細をフローチャートを用いて説明する。図９に本実施形態のロギング処理の全体の流れを示す。この処理が開始されると、まず各種の設定値が初期化される（Ｓ１０１）。Ｓ１０１では、センシング感度の見直し間隔に相当する計測期間の長さの設定が行われ、例えば３０分や１時間等の時間が設定される。
【０１０８】
次にセンシング感度（或いは判定レベル）の見直しを行う（Ｓ１０２）。Ｓ１０２の処理が初めて行われる場合には、所与の初期値を設定すればよく、２回目以降の処理の場合には、過去の（狭義には前回の）ロギング処理の結果に基づいて値を設定する。そして、各種変数の初期化を行う（Ｓ１０３）。上述したモードＢ又はモードＣを用いる場合には、総和期間情報又は総和回数情報の算出にカウンター等を用いるため、Ｓ１０３の処理において当該カウンター等が初期化されることになる。その他、Ｓ１０１で設定した計測期間ごとに算出される情報に対応する変数の初期化を行う。
【０１０９】
その後、ロギング処理が終了するかの判定を行い（Ｓ１０４）、Ｙｅｓの場合は処理を終了する。Ｎｏの場合は実際の計測処理を実行する（Ｓ１０５）。Ｓ１０５の処理の詳細は、図１１、図１２を用いて後述する。
【０１１０】
一単位時間での計測処理後、Ｓ１０１で設定した計測期間が終了したかの判定を行い（Ｓ１０６）、Ｎｏの場合にはＳ１０４に戻り計測処理を継続する。Ｓ１０６でＹｅｓの場合には、当該計測期間での計測処理を終了する。その際、モードＡではＳ１０５での計測処理（図１２を用いて後述）の中で逐次ロギング情報が生成されるため、Ｓ１０７の処理は特に行われずＳ１０２に戻る。一方、モードＢ又はモードＣでは、Ｓ１０５の処理（図１１を用い後述）では総和期間情報又は総和回数情報に相当する変数の更新が行われるが、Ｓ１０６でＹｅｓとなるまではロギング情報としての記憶等は行われていない。よって、Ｓ１０３で初期化され、Ｓ１０５でその値が更新された変数の最終的な値を、ロギング情報として取得する（Ｓ１０７）。Ｓ１０７の処理後はモードＡと同様にＳ１０２に戻る。
【０１１１】
次に、計測処理の具体例を図１０〜図１２を用いて説明する。図１０が計測処理の全体の流れであり、モードの判定を行い（Ｓ２０１）、モードＡであればモードＡ用の処理を行い（Ｓ２０２）、モードＢ又はモードＣであれば、モードＢ，Ｃ用の処理を行う（Ｓ２０３）。
【０１１２】
Ｓ２０３でのモードＢ，Ｃ用の処理の詳細を図１１に示す。なお、図１１、図１２では音響センサー部１１０からは図７の信号が出力されているものとするが、これに限定されない。モードＢ，Ｃ用の処理が開始されると、まず音響センサー部１１０からの信号を取得する（Ｓ３０１）。そして、イベントが発生したか（ここではＳ３０１で取得した信号値が１であるか）の判定を行い（Ｓ３０２）、Ｎｏの場合には処理を終了する。Ｓ３０２でＮｏの場合には、当該タイミングでの図１０のＳ２０３の処理が終了することになり、結果として当該タイミングでの図９のＳ１０５の処理も終了する。
【０１１３】
Ｓ３０２でＹｅｓの場合には、立ち上がり又は立ち下がりのどちらか一方が発生したということであるから、それが立ち上がりであるかの判定を行う（Ｓ３０３）。立ち上がりであった場合には、モードの判定を行い（Ｓ３０４）、モードＣである場合（Ｓ３０４でＹｅｓの場合）には、立ち上がりの回数である総和回数情報に対応するカウンターの値をインクリメントする（Ｓ３０５）。モードＢである場合（Ｓ３０４でＮｏの場合）には、立ち下がりまでの時間を計測する必要があるため、立ち上がりタイミングに相当する時刻情報Ｔｓを記憶する（Ｓ３０６）。
【０１１４】
一方、立ち下がりであった場合（Ｓ３０３でＮｏの場合）にも、モードの判定を行い（Ｓ３０７）、モードＢの場合（Ｓ３０７でＹｅｓの場合）には立ち下がりタイミングに相当する時刻情報Ｔｅを記憶し、総和期間情報に相当する変数の値を、Ｔｓ−Ｔｅだけ増加させる（Ｓ３０８）。また、モードＣの場合（Ｓ３０７でＮｏの場合）には特に処理は行われない。
【０１１５】
Ｓ３０５，Ｓ３０６，Ｓ３０８の処理後、及びＳ３０７でＮｏの場合には処理を終了する。
【０１１６】
Ｓ２０２でのモードＡ用の処理の詳細を図１２に示す。この処理が開始されると、Ｓ３０１，Ｓ３０２と同様に、音響センサー部１１０からの信号を取得し、イベントが発生したかの判定を行う（Ｓ４０１，Ｓ４０２）。モードＡでは立ち上がり、立ち下がりの両方の時刻情報を記憶するため、イベント発生時にはそのタイミングに対応する時刻情報を記憶する（Ｓ４０３）。そしてイベントが立ち上がりであったかの判定を行い（Ｓ４０４）、Ｙｅｓの場合にはＳ４０３で記憶した時刻情報に、当該時刻でのイベントが立ち上がりであることを示す情報を関連づけて記憶する（Ｓ４０５）。同様に、Ｓ４０４でＮｏの場合にはＳ４０３で記憶した時刻情報に、当該時刻でのイベントが立ち下がりであることを示す情報を関連づけて記憶する（Ｓ４０６）。
【０１１７】
また、図９のＳ１０２でのセンシング感度（又は判定レベル）の設定処理の例を図１３に示す。この処理が開始されると、集計変数（例えば総和期間情報や総和回数情報）と上限値との比較処理を行う（Ｓ５０１）。上限を超えていた場合には、センシング感度を下げる（ゲインを下げる、或いは音響閾値を上げる）処理を行う（Ｓ５０２）。
【０１１８】
Ｓ５０１でＮｏの場合には、集計変数と下限値との比較処理を行う（Ｓ５０３）。下限を下回った場合には、センシング感度を上げる（ゲインを上げる、或いは音響閾値を下げる）処理を行う（Ｓ５０４）。Ｓ５０２、Ｓ５０４の処理を行った場合には、センシング感度の設定処理を終了する。また、Ｓ５０３でＮｏの場合（つまり、集計変数の値が下限値と上限値の間にある場合）には、特にセンシング感度は変更されずにセンシング感度の設定処理を終了する。
【０１１９】
以上の本実施形態では、情報処理システム３００は図３に示したように、アクティビティーにより発生する音響をセンシングする音響センサー部（１１０−１等）からの検出結果情報をネットワーク１０を介して受信する受信処理部３１０と、検出結果情報に基づいて、アクティビティーについてのロギング情報を求めるロギング処理を行う処理部３２０と、ロギング情報を記憶する記憶部３４０を含む。
【０１２０】
ここで、検出結果情報とは、音響センサー部が図４に示した構成であれば、図５のように音響センサー１１１のセンサー情報そのもの（或いは処理を加えるとしても、Ａ／Ｄ変換処理程度にとどまる情報）を指すものとする。ただし、音響センサー部の構成は図２に示したように、アンプ１１２や閾値判定部１１３を含むものであってもよく、その場合の検出結果情報は、図６の信号や図７の信号等であってもよい。ただし、音響センサー部と処理部３２０が別体として設けられる場合には、閾値判定処理等を処理部３２０で行うことで、複数の音響センサー部からの信号に対する処理（判定レベルの制御を含む）を情報処理システム３００に一元化することができる。また、各音響センサー部の構成が簡略化できるため、消費電力の低減やコスト削減等が可能になる。よって、ここでの検出結果情報は図５〜図７のいずれであってもよいが、図５であること（つまり音響センサー部の構成は図４のようなものであること）が望ましい。
【０１２１】
これにより、音響センサー１１１を用いて、アクティビティーについてのロギング情報を求める情報処理システムを実現することが可能になる。特に、情報処理システム３００と音響センサー部はネットワーク１０を介して接続されればよいため、別体として設けることが可能である。ただし、ネットワーク１０はインターネットに限定されるものではなく、また有線で構成されるネットワークであってもよいため、音響センサー部１１０−１等と情報処理システム３００とが物理的に近い位置に設置されることを妨げるものではない。
【０１２２】
また、処理部３２０は、アクティビティーの発生頻度情報が、時間情報に関連づけられた情報を、ロギング情報として求めてもよい。
【０１２３】
これにより、図１４に示したように、ユーザーが直感的に理解しやすい形式でロギング情報を求めることが可能になる。図５等を用いて上述したように、音響センサー１１１のセンサー情報は検出対象でないアクティビティーによってもその信号レベル（音響レベル）が変動しうるため、そのままでは検出対象アクティビティーの発生の有無等を判断することが難しい。その点、発生頻度情報が時間情報に関連づけられた情報（例えば図１４のように発生回数の時間変化を表した情報）を用いることで、ユーザーの理解が容易となる。
【０１２４】
また、処理部３２０は、検出結果情報に基づいて、アクティビティーが発生したか否かの判定処理を行い、判定処理の結果に基づいて発生頻度情報を求めてもよい。
【０１２５】
これにより、検出結果情報に基づいて発生頻度情報を求めることが可能になる。検出結果情報はアクティビティーに起因する音響イベントを反映するものであることから、検出結果情報に基づいたアクティビティーの発生有無判定は可能と考えられる。
【０１２６】
また、処理部３２０は、求めた発生頻度情報に基づいて、判定処理の判定レベルを制御してもよい。
【０１２７】
ここで、判定レベルとは、アクティビティーが発生しているか否かを判定する基準となるレベルのことであり、例えば判定レベルが高い場合には、検出結果情報により表される値が大きくないとアクティビティーが発生していると判定されないものとする。逆に、判定レベルが低い場合には、検出結果情報により表される値が小さくてもアクティビティーが発生していると判定する。
【０１２８】
これにより、発生頻度情報に基づいて判定レベルを制御することができ、検出対象でないアクティビティーにより検出結果情報が変動する場合等にも適切にロギング処理を行うことが可能になる。発生頻度情報を求めたとしても、当該発生頻度情報により表される発生頻度（例えば所定時間内での発生回数等）が上限値やそれに近い数値、又は０やそれに近い数値である場合には、検出対象でないアクティビティーに起因する音響レベルの変動による影響を受けている可能性が高いためである。
【０１２９】
また、検出対象でないアクティビティーによりセンサー情報の信号レベルが変化しているわけではない場合（つまり、検出対象アクティビティーが実際に非常に高い頻度で発生している場合等）であっても、発生頻度が極端である状況は好ましくない。なぜなら、例えば発生回数が上限値をとっている場合、それはセンサー情報の信号レベルが基準値よりある程度大きいだけなのか、それとも数十倍や数百倍といった大きな値をとっているのか、という情報が発生頻度情報には全く反映されないためである。よって、そのような情報を発生頻度情報に反映させるためにも、センシング感度を制御することが望ましい。ただしこの場合には、実際のアクティビティーは上限値に近い頻度で発生しているにもかかわらず、発生頻度情報により表される値がそれよりも小さくなる等のケースが起こりえるため、注意を要する。
【０１３０】
また、処理部３２０は、検出結果情報に基づいて得られた情報と、判定レベルを関連づけた情報を、ロギング情報として求めてもよい。
【０１３１】
ここで、検出結果情報に基づいて得られた情報とは、例えば図８（Ａ）の時刻情報や、図８（Ｂ）の総和期間情報、図８（Ｃ）の総和回数情報が考えられるが、これに限定されない。つまり、検出結果情報に基づいて得られた情報とは、上述した発生頻度情報であってもよいし、他の情報であってもよい。なお、他の情報を用いる場合には、当該情報から発生頻度情報を算出可能であることが望ましい。
【０１３２】
これにより、検出結果情報から得られる情報だけでなく、当該情報を取得する際に用いられた判定レベルの情報を関連づけて、ロギング情報とすることが可能になる。判定レベルの情報を保持することで、発生頻度に関する情報だけでなく、その際の信号レベル等に関する情報を推定することが可能になる。
【０１３３】
また、情報処理システム３００はサーバーシステムであってもよい。図３に示したように、サーバーシステムにネットワーク１０を介してクライアント装置４００が通信接続されている場合を考える。この場合、サーバーシステムは検出結果情報に基づいて得られた情報と判定レベルを関連づけた情報であるロギング情報を、ネットワーク１０を介してクライアント装置４００に送信する送信処理部３３０を含んでもよい。
【０１３４】
これにより、情報処理システム３００をサーバーシステムにより実現すること、及びサーバーシステムでの処理結果として取得されたロギング情報をクライアント装置４００に対して送信することが可能になる。情報処理システム３００がサーバーシステムである場合、ロギング情報を利用したいユーザーが当該サーバーシステムを直接操作できない状況も大いに考えられる。よって、ユーザーは自身が操作可能なクライアント装置４００を用いてサーバーシステムにアクセスし、ロギング情報を取得する必要があり、そのためにはサーバーシステムはクライアント装置４００のリクエストを受け付け、ロギング情報をレスポンスとして返すことになる。
【０１３５】
また、処理部３２０は、検出結果情報により表される音響レベルと、所与の音響閾値との比較処理に基づいて、アクティビティーについてのロギング情報を求めてもよい。
【０１３６】
ここで、音響レベルとは音響センサー１１１のセンサー情報により表される値であってもよいし、音響センサー１１１のセンサー情報に対して増幅部３２１で増幅処理を行った後の信号値であってもよい。
【０１３７】
これにより、音響レベルと音響閾値との比較処理に基づいてロギング情報を求めることが可能になる。閾値判定処理は例えば閾値判定部３２２で行えばよい。この場合、判定レベルの制御は、増幅部３２１での増幅率及び閾値判定部３２２で用いる音響閾値の少なくとも一方を調整することで行うことができる。
【０１３８】
また、処理部３２０は、検出結果情報に基づいて、音響レベルが音響閾値を超えた回数の総和である総和回数情報、又は音響レベルが音響閾値を超えた期間の長さの総和である総和期間情報を、ロギング情報として各計測期間ごとに求めてもよい。
【０１３９】
これにより、図８（Ｂ）のモードＢ又は図８（Ｃ）のモードＣによりロギング情報を求めることが可能になる。総和回数情報や総和期間情報からは、音響レベルが音響閾値を上回った具体的なタイミング等を特定することはできない。しかし、アクティビティーの発生頻度を表す指標値としては十分な情報であり、モードＡのように信号を再現可能な情報を用いる場合に比べてデータ量を小さくすることが可能である。
【０１４０】
また、処理部３２０は、総和回数情報又は総和期間情報をロギング情報として求める第１のロギング処理と、総和回数情報及び総和期間情報とは異なるデータ構造の情報をロギング情報として求める第２のロギング処理のうちの一方の処理を、ロギング処理として実行してもよい。
【０１４１】
これにより、状況に応じてロギング処理の内容を切り替えることが可能になり、具体的にはロギング処理の結果求められるロギング情報のデータ構造を切り替えることが可能になる。なお、総和期間情報は上述したモードＢに対応し、総和回数情報はモードＣに対応するが、ロギング処理変更後のロギング情報のデータ構造は種々考えられる。例えば、上述したモードＡのように、総和回数情報や総和期間情報よりも情報量の多いデータ構造を用いてもよいし、総和回数情報や総和期間情報よりもさらにデータ量が削減された簡略的なデータ構造を用いてもよい。また、実行するロギング処理の選択手法は種々考えられるが、過去のロギング情報に基づいて次のロギング処理内容が決定されてもよいし、センシング感度等の制御と連動して決定されるものであってもよい。
【０１４２】
また、処理部３２０は、総和回数情報が所与の回数閾値を超えるまで、又は総和期間情報が所与の期間閾値を超えるまでは、第１のロギング処理をロギング処理として実行してもよい。また、総和回数情報が回数閾値を超えた場合、又は総和期間情報が期間閾値を超えた場合には、第２のロギング処理をロギング処理として実行してもよい。
【０１４３】
これにより、総和回数情報により表される値、又は総和期間情報により表される値に基づいて、ロギング情報のデータ構造を変更することが可能になる。ここでは、総和回数情報により表される値，或いは総和期間情報により表される値が大きい場合にデータ構造を変更する。これはアクティビティーの発生頻度が高い場合に相当するため、より詳細なロギング情報を求めることが必要であると推測される。つまり、変更後のデータ構造は、狭義には総和回数情報や総和期間情報よりも情報量の多い情報である。
【０１４４】
また、処理部３２０は、音響レベルが音響閾値を上回ったタイミングである第１のタイミングに対応する時間情報、及び音響レベルが音響閾値を下回ったタイミングである第２のタイミングに対応する時間情報の少なくとも一方を、第２のロギング処理におけるロギング情報として求めてもよい。
【０１４５】
これにより、上述した総和回数情報や総和期間情報とは異なるデータ構造のロギング情報として、図８（Ａ）に示したモードＡの情報を用いることが可能になる。第１のタイミングとは狭義には図６の立ち上がりに相当するタイミングであり、第２のタイミングとは狭義には図６の立ち下がりに相当するタイミングである。音響レベルと音響閾値との比較処理を前提とするため、処理結果の信号は閾値を超えたか超えないかの２値により表されることが想定される。よって、２値信号での値変化のタイミングに相当する時間情報（例えば時刻情報）をロギング情報とすることで、図６の波形を再現することもできる。
【０１４６】
なお、ここでは総和回数情報や総和期間情報に基づいてモードＡに移行するものとして説明したが、総和回数情報や総和期間情報とは独立してモードＡに設定されてもよい。また、一旦モードＡに移行した後に、モードＢやモードＣに移行してもよい。その場合の移行条件は種々考えられるが、例えばモードＡでのロギング情報から総和回数情報や総和期間情報に相当する情報を求め、その値に基づいてモードＢやモードＣに移行してもよい。
【０１４７】
また、処理部３２０は、時間情報に対して、第１のタイミングと第２のタイミングのいずれに対応するかを表す情報を関連づけた情報を、第２のロギング処理におけるロギング情報として求めてもよい。
【０１４８】
これにより、時間情報により表される時間が、第１のタイミング（立ち上がり）に対応するか、第２のタイミング（立ち下がり）に対応するかの情報をロギング情報に含めることが可能になる。ロギング処理の開始時において、音響レベルが音響閾値よりも小さいとすれば、理想的な信号では最初の時間情報は第１のタイミングに対応し、その後の時間情報は直前の時間情報とは異なる方に対応する。同様に、ロギング処理の開始時において、音響レベルが音響閾値よりも大きいとすれば、理想的な信号では最初の時間情報は第２のタイミングに対応し、その後の時間情報は直前の時間情報とは異なる方に対応する。よって理想的には、第１のタイミングと第２のタイミングのいずれに対応するかを表す情報をロギング情報に含めなくてもよい。しかし、何らかのエラーにより一部の情報が欠落する等のことがあれば、ある時間情報が直前の時間情報とは異なる状態に対応するとは限らない。その場合、ロギング情報と実際の信号の立ち上がり立ち下がりとの関係性が適切なものでなくなり、その後の処理（例えばアクティビティーの発生頻度情報の算出）の精度が低下することになる。よって、イレギュラーな場合にも正確な処理が行えるように、第１のタイミングと第２のタイミングのいずれに対応するかを表す情報をロギング情報に含めることが望ましい。
【０１４９】
また、情報処理システム３００はサーバーシステムであってもよい。図３に示したように、サーバーシステムにネットワーク１０を介してクライアント装置４００が通信接続されている場合を考える。この場合、サーバーシステムは検出結果情報に基づいて得られた情報と音響閾値を関連づけた情報であるロギング情報を、ネットワーク１０を介してクライアント装置４００に送信する送信処理部３３０を含んでもよい。
【０１５０】
これにより、検出結果情報に基づいて得られた情報と音響閾値を関連づけた情報をロギング情報として、クライアント装置４００に送信することが可能になる。情報処理システム３００をサーバーシステムとすることの利点等は上述したとおりである。
【０１５１】
また、処理部３２０は、ロギング情報と、所与の日常パターンとの比較処理を行い、比較処理によりロギング情報が日常パターンとは異なると判定された場合には、アラーム情報を出力してもよい。
【０１５２】
これにより、日常パターンと異なるロギング情報が取得された場合に、警告を発することが可能になる。地下の空洞崩落をアクティビティーとした場合のように、アクティビティーが全く発生しないことが通常であるケースでは、アクティビティーの有無を判定することで異常事態を検出することも可能である。しかし、平常時にもある程度の回数が発生しうるアクティビティーも考えられる。例えば、監視システムでは人為的な行為をアクティビティーとするが、監視領域には関係者や警備員等も入るため、アクティビティーがあったからといって即座に異常事態であるという判定はできない。このような場合には、発生回数が平常時よりも明らかに多い状況、或いは深夜等の人の活動が想定されない時間にアクティビティーが発生している状況等をもって異常事態と判定する必要がある。つまり、通常の状態を表す情報を日常パターンとして保持しておき、ロギング情報と当該日常パターンとの比較処理を行うとよい。
【０１５３】
また、情報処理システム３００はサーバーシステムであってもよい。図３に示したように、サーバーシステムにネットワーク１０を介してクライアント装置４００が通信接続されている場合を考える。この場合、サーバーシステムはアラーム情報をネットワーク１０を介してクライアント装置４００に送信する送信処理部３３０を含んでもよい。
【０１５４】
これにより、アラート情報をクライアント装置４００に送信することが可能になる。情報処理システム３００をサーバーシステムとすることの利点等は上述したとおりである。
【０１５５】
なお、本実施形態の情報処理システム３００等は、その処理の一部または大部分をプログラムにより実現してもよい。この場合には、ＣＰＵ等のプロセッサーがプログラムを実行することで、本実施形態の情報処理システム３００等が実現される。具体的には、情報記憶媒体に記憶されたプログラムが読み出され、読み出されたプログラムをＣＰＵ等のプロセッサーが実行する。ここで、情報記憶媒体（コンピューターにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＤＶＤ、ＣＤ等）、ＨＤＤ（ハードディスクドライブ）、或いはメモリー（カード型メモリー、ＲＯＭ等）などにより実現できる。そして、ＣＰＵ等のプロセッサーは、情報記憶媒体に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち、情報記憶媒体には、本実施形態の各部としてコンピューター（操作部、処理部、記憶部、出力部を備える装置）を機能させるためのプログラム（各部の処理をコンピューターに実行させるためのプログラム）が記憶される。
【０１５６】
なお、以上のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語と共に記載された用語は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。またセンサーシステム、情報処理システム等の構成、動作も本実施形態で説明したものに限定されず、種々の変形実施が可能である。
【符号の説明】
【０１５７】
１０  ネットワーク、１００  センサーシステム、１１０  音響センサー部、
１１１  音響センサー、１１２  アンプ、１１３  閾値判定部、
１１４  波形整形回路、１１５  ゲインレジスター、１１６  シリアル受信回路、
１１７  通信部、１２０  処理部、１２３  センシング感度制御部、
１２５  ロギング情報生成部、１３０  通信部、１４０  記憶部、１５０  タイマー、
２００  外部機器、３００  情報処理システム、３１０  受信処理部、
３２０  処理部、３２１  増幅部、３２２  閾値判定部、３２３  判定レベル制御部、
３２５  ロギング情報生成部、３３０  送信処理部、３４０  記憶部、
３５０  タイマー、４００  クライアント装置
【図１】
2013210233.tif 000003
【図２】
2013210233.tif 000004
【図３】
2013210233.tif 000005
【図４】
2013210233.tif 000006
【図５】
2013210233.tif 000007
【図６】
2013210233.tif 000008
【図７】
2013210233.tif 000009
【図８】
2013210233.tif 000010
【図９】
2013210233.tif 000011
【図１０】
2013210233.tif 000012
【図１１】
2013210233.tif 000013
【図１２】
2013210233.tif 000014
【図１３】
2013210233.tif 000015
【図１４】
2013210233.tif 000016