JP2013219553A - データ収集システム、及びデータ収集方法 - Google Patents

Abstract

【課題】サーバが各ユーザの管理対象のデバイスから遅延無く確実にデータを収集でき、当該デバイスに対してアクションをリアルタイムに返すことができる技術を提案する。
【解決手段】本発明のデータ収集システムは、それぞれが複数のユーザデバイスを含む、複数の宅内デバイス群と、複数の宅内デバイス群から所定のデータを受信して加工する、複数の中間サーバと、複数の中間サーバから加工されたデータを収集して、データベースに保存する収集サーバと、を有する。そして、複数の中間サーバのそれぞれは、収集サーバに収集される加工データを生成するために必要な複数のモジュールを有する。また、収集サーバは、複数のモジュールの少なくとも１つを更新するための更新モジュールデータを複数の中間サーバに配信する。そして、複数の中間サーバのそれぞれは、更新対象であるモジュールに対して更新モジュールデータを適用し、適用後のモジュールを起動することにより旧モジュールを更新する。
【選択図】図１

Description

本発明は、データ収集システム、及びデータ収集方法に関する。

センサや家電などのデバイスの情報を活用したサービスを提供するために、サーバに情報を収集する方式について国際標準化が進んでいる。例えば、非特許文献１は、EUの標準化団体ETSIにおいて定められるデータ収集のアーキテクチャを示している。

非特許文献１では、データ収集対象のデバイスと収集サーバの間にゲートウェイ装置を配置し、デバイスがゲートウェイにデータを送信し、そのデータをゲートウェイが収集サーバにデータを送信する。そして、サーバにデータを収集し、収集したデータを分析した上で、サーバよりデバイスに分析結果をふまえたアクションを送信する。このようにすることにより、ゲートウェイ装置がデバイスの通信プロトコルをETSIが定めるプロトコルに変換し、サーバに送信するため、サーバはETSIプロトコルのみサポートすればよいというメリットがある。

ETSI TS 102 690: （http://webapp.etsi.org/WorkProgram/Report_WorkItem.asp?WKI_ID=30459）

しかしながら、非特許文献１の方式をそのまま実装しただけでは、例えば１００万個のデバイスから１分毎にデータがゲートウェイを介してサーバに送信されるような場合、サーバに負荷が集中する。このため、サーバがダウンし、本来収集すべきデータが収集できなかったり、サーバからデバイスへのアクション送信が遅延したりする。さらに、本来必要で無いデータが収集され、収集サーバ側のストレージ容量が多く必要になるという課題もある。

本発明はこのような状況に鑑みてなされたものであり、サーバが各ユーザの管理対象のデバイスから遅延無く確実にデータを収集でき、当該デバイスに対してアクションをリアルタイムに返すことができる技術を提案する。

上記課題を解決するために、本発明のデータ収集システムは、それぞれが複数のユーザデバイスを含む、複数の宅内デバイス群と、複数の宅内デバイス群から所定のデータを受信して加工する、複数の中間サーバと、複数の中間サーバから加工されたデータを収集して、データベースに保存する収集サーバと、を有する。そして、複数の中間サーバのそれぞれは、収集サーバに収集される加工データを生成するために必要な複数のモジュールを有する。また、収集サーバは、複数のモジュールの少なくとも１つを更新するための更新モジュールデータを複数の中間サーバに配信する。そして、複数の中間サーバのそれぞれは、更新対象であるモジュールに対して更新モジュールデータを適用し、適用後のモジュールを起動することにより旧モジュールを更新する。

本発明によれば、サーバが各ユーザの管理対象のデバイスから遅延無く確実にデータを収集でき、当該デバイスに対してアクションをリアルタイムに返すことができるようになる。また、収集サーバにおける必要なストレージ容量を抑えることもできるようになる。

本発明に関連する更なる特徴・作用・効果は、本明細書の記述、添付図面から明らかになるものである。また、本発明の態様は、要素及び多様な要素の組み合わせ及び以降の詳細な記述と添付される特許請求の範囲の様態により達成され実現される。

本明細書の記述は典型的な例示に過ぎず、本発明の特許請求の範囲又は適用例を如何なる意味に於いても限定するものではないことを理解する必要がある。

本発明の実施形態によるデータ収集システムの全体概略構成を示す図である。 本発明の実施形態による収集サーバの概略構成を示す図である。 本発明の実施形態による中間サーバの概略構成を示す図である。 本発明の実施形態によるソフトウェアモジュールの構成を示す図である。 本発明の実施形態によるリアルタイム処理モジュールの構成を示す図である。 本発明の実施形態によるデータフィルタモジュールの構成を示す図である。 本発明の実施形態による宅内デバイス群の通信データの例を示す図である。 本発明の実施形態によるデータベースに保存されるデータ例を示す図である。 本発明の実施形態によるリアルタイム処理モジュールの処理を説明するためのフローチャートである。 本発明の実施形態によるデータフィルタモジュールの処理を説明するためのフローチャートである。 本発明の実施形態によるデータ収集全体の処理のシーケンスを示すシーケンス図である。 ソフトウェアモジュール更新処理のシーケンスを示すシーケンス図である。

以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。

本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。

更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。

なお、以後の説明では「テーブル」形式によって本発明の各情報について説明するが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」や「データ」と呼ぶことがある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

以下では「機能」を主語（動作主体）として本発明の実施形態における各処理について説明を行うことがあるが、「機能」はプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、「機能」に対応する処理は、一部または全てが専用ハードウェアで実現してもよく、また、モジュール化されていても良い。

＜データ収集システムの構成＞
図１は、本発明の実施形態によるデータ収集システムの概略構成を示す図である。データ収集システム１００は、収集サーバ１１０と、当該収集サーバ１１０とネットワーク１２０を介して接続される複数の中間サーバ１３０と、収集サーバ１１０とネットワーク１２０を介して接続される、或いは中間サーバ１３０とネットワーク１４０を介して接続される、複数の宅内デバイス群１５０、１７０及び１８０と、を有している。

収集サーバ１１０は、宅内デバイス群１５０、１７０及び１８０からの情報を収集し、収集した情報を基に、ユーザ１６０の要求に応答して或いは収集サーバ１１０の管理者に対してデータ可視化などのサービスを提供する。収集サーバ１１０の詳細な構成は図２に示す。

中間サーバ１３０は、収集サーバ１１０の負荷を少なくする目的で、宅内デバイス群１５０からの情報を、ネットワーク１４０を介して収集し、加工した上でネットワーク１２０を介して収集サーバ１１０に送信する機能を持つ。上記データ可視化のサービス（情報提供サービス）は、例えば、携帯電話（携帯デバイス）１５３や図示しないＰＣ（パーソナルコンピュータ）に対してなされるものである。

宅内デバイス群１５０は、ユーザ１６０の宅内にあるデバイス群である。宅内デバイス群１５０は、例えば、宅内の電力消費量情報を保有するスマートメータ１５１、複合センサ(防犯センサ等を含む)１５２、携帯電話１５３、ディスプレイ、ＰＣ等を含む。これらのデバイスは、直接ネットワーク１４０に接続されてもよいし、ゲートウェイ装置のようなものを介してネットワーク１４０に接続されてもよい。なお、複合センサ(防犯センサ等を含む)１５２は、ここでは、バッテリを内蔵しておりバッテリで駆動していると想定する。中間サーバは、参照番号１７０で示されるように、複数のユーザのデバイス群がネットワーク１４０を介して接続されるようにしても良い。また、中間サーバは、参照番号１８０で示されるように複数台存在するようにしても良い。本実施形態では、説明の簡略化のため、宅内デバイス群１５０からの情報収集の例で説明する。

＜収集サーバの構成＞
図２は、収集サーバ１１０の概略構成を示す図である。収集サーバ１１０は、各機能を実行するＣＰＵ（単にプロセッサとも言う）２００と、データベース２４０と、各機能に対応するプログラムを格納するメモリ（図示せず）と、を有している。

ＣＰＵ２００は、メモリからプログラムを読み出して、ソフトウェアモジュール配信機能２１０と、データ受付・保存機能２２０と、データ可視化機能２３０と、を実現する。

ソフトウェアモジュール配信機能２１０は、図３で説明するソフトウェアモジュール管理フレームワークの上で管理されるソフトウェアモジュールを中間サーバ１３０に配信する機能である。

データ受付・保存機能２２０は、中間サーバからのデータを受け付け、データベース２４０に保存する機能である。

データ可視化機能２３０は、データベース２４０に保存されたデータをユーザ１６０に提示する機能である。

これらの機能がどう使われるかは図１１及び１２を参照して説明する。

＜中間サーバの構成＞
図３は、本発明の実施形態による中間サーバ１３０の概略構成を示した図である。中間サーバ１３０は、各機能や各モジュールを実行・制御するＣＰＵ（プロセッサ）３００と、ソフトウェアモジュール管理フレームワーク３１０と、ソフトウェアモジュール群３２０と、ソフトウェアモジュール構成データベース３３０と、を有している。

ソフトウェアモジュール管理フレームワーク３１０は、図４で説明するソフトウェアモジュールを管理するために、インストール・アンインストール機能３１１と、起動・停止機能３１２と、アップデート機能３１３と、を有している。

インストール・アンインストール機能は、ソフトウェアモジュールをインストール・アンインストールする機能である。起動・停止機能３１２は、ソフトウェアモジュールの機能を停止したり、起動したりする機能である。アップデート機能３１３は、ソフトウェアモジュールのアップデート時に対象のソフトウェアモジュールを停止し、その後起動する機能である。なお、ここでインストールとは、ソフトウェアモジュールに含まれるファイル群をファイルシステムに展開するだけであり、インストールされたソフトウェアモジュールの機能自体は起動しない。したがって、既存のソフトウェアモジュールのバージョンアップ版をインストールする場合は、ファイルは展開されるが、動作中のソフトウェアモジュールは旧バージョンのもののままである。動作中のソフトウェアモジュールを更新するためには、更新版のインストール後、起動・停止機能３１２により、停止してから起動するか、更新機能３１３により、停止・起動指示を出す必要がある。以上のような機能を持つソフトウェアモジュール管理フレームワークの例としては、ＯＳＧｉフレームワークがある。

ソフトウェアモジュール管理フレームワーク３１０の管理対象として、ソフトウェアモジュール群３２０がある。ソフトウェアモジュール群３２０は、例えば、データ受付モジュール３２１と、リアルタイム処理モジュール３２２と、データフィルタモジュール３２３と、データ送信モジュール３２４と、を含んでいる。このような複数のソフトウェアモジュールが、ファイルシステム上に展開され、ソフトウェアモジュール構成データベース３３０にてバージョン番号・モジュール名・展開されているファイルパスが管理されている。

データ受付モジュール３２１は、宅内デバイス群１５０から送信するデータを受け付ける機能を持つモジュールである。リアルタイム処理モジュール３２２は、データ受付モジュール３２１が受信したデータを基に、リアルタイムな対応が必要なものを処理するモジュールである。リアルタイム処理モジュール３２２の構成については図５を参照して説明する。データフィルタモジュール３２３は、データ受付モジュール３２１が受信したデータを一時蓄積・加工する機能を持つモジュールである。データ受付モジュールの構成については図６を参照して説明する。

＜ソフトウェアモジュールの構成＞
図４は、ソフトウェアモジュール管理フレームワーク３１０上が管理する各ソフトウェアモジュールの構成を示す図である。各ソフトウェアモジュールは、バージョン情報４１０と、モジュール名４２０と、ソフトウェアモジュール本体４３０と、を有している。

バージョン情報４１０は、ソフトウェアモジュールのバージョン番号である。モジュール名４２０は、ソフトウェアモジュールの名称である。ソフトウェアモジュール本体４３０には、ソフトウェアモジュールのプログラムロジックが格納されている。

＜リアルタイム処理モジュールの構成＞
図５は、リアルタイム処理モジュール３２２の構成を示した図である。リアルタイム処理モジュールは、データマッチ機能５１０と、アクション機能５２０とを有している。

データマッチ機能５１０は、入力データと予め定められたパターンを照合する機能である。アクション機能５２０は、予め定められたアクションに基づいた命令を実行する機能である。当該アクションには、例えば、収集データから異常が検知された場合に、異常を例えば携帯電話に通知することや、所定期間の電力使用量の合計が所定料を超えた場合にそのことを通知することが含まれる。これらの処理例は、図９を参照して後述する。

＜データフィルタモジュールの構成＞
図６は、データフィルタモジュール３２３の構成を示す図である。データフィルタモジュールは、データ一時蓄積機能６１０と、データ集計機能６２０と、を有している。

データ一時蓄積機能６１０は、入力データを一時的に保存する機能である。データ集計機能６２０は、入力データを集計（総和、平均、不要データ破棄等）する機能である。これらの処理例については図１０を参照して後述する。

＜送信データ例＞
図７は、宅内デバイス群１５０が中間サーバ１３０に送信するデータの例を示す図である。
データ７５１から７５５は、複合センサ(防犯センサ等を含む)１５２が送信するデータを示している。当該送信データは、例えば、機器ＩＤ７１０と、時刻情報７２０と、フラグ情報７３０と、バッテリ残量７４０と、を構成項目として有している。機器ＩＤ７１０は、機器を一意に識別・特定するための情報である。時刻７２０は、センサがデータを取得した時刻の情報である。フラグ７３０は、防犯センサが反応したか否かを示す識別情報である。フラグが１の場合、ガラスが割られた等、防犯上問題がある状況が検知されたことを意味する。バッテリ残量７４０は、センサの内蔵バッテリの残量を示す情報である。内蔵バッテリの残量は、バッテリ交換時期の推定などに活用することを想定している。

データ７９１から７９５は、スマートメータ１５１が中間サーバ１３０に送信するデータ例を示している。機器ＩＤ７６０は、機器を一意に識別・特定するための情報である。時刻７２０は、スマートメータがデータを取得した時刻の情報である。今回は、１分おきにデータを取得するとする。電力使用量７８０は、１分間に宅内で消費した電力である。

なお、データ７５１から７９５は、表のフォーマットになっているが、実際はバイナリ形式などにエンコードされて中間サーバに送信される。また、センサやスマートメータが直接中間サーバ１３０と通信する機能を持っていない場合は、ゲートウェイ装置にいったん接続し、ゲートウェイ装置が中間サーバ１３０と通信する実施形態もありえる。

＜データベースの内容＞
図８は、データベース２４０に保存されるデータ例を示す図である。データ８４１は、複合センサ(防犯センサ等を含む)１５２からのデータを保存したものであり、所定時刻（２０１２／１／３１ １２：００：００）のデータ（バッテリ残量）を示している。なお、所定期間（２０１２／１／３１ １２：００：００〜１２：０４：００）のデータの平均値（バッテリ残量）を保存するようにしても良い。

データ８８１は、スマートメータ１５１からのデータを保存したものであり、所定時刻（２０１２／１／３１ １２：００：００）のデータ（電力使用量）を示している。なお、所定期間（２０１２／１／３１ １２：００：００〜１２：０４：００）のデータ（電力使用量）の平均値を保存するようにしても良い。

＜リアルタイムモジュールの処理＞
図９は、リアルタイム処理モジュール３２２による処理内容を説明するためのフローチャートである。以下、図７のデータを受信した例を使って説明する。
（i）ステップ９１０
データ受付モジュール３２１は、宅内デバイス群からデータを受信する。今回の例では、データ受付モジュール３２１は、データ７５１及び７９１をまず受け取り、その１分後にデータ７５２及び７９２を受け取り、その１分後にさらにデータ７５３及び７９３を受け取り…のようにデータを受信する。データを受け取ると、即座に次のステップの処理が実行される。
（ii）ステップ９２０
データマッチ機能５１０は、受け取ったデータについて予めモジュール内に定められたマッチング処理を行う。今回は、フラグ７３０が「１」であるか否かのマッチングを行う。フラグが「１」に合致（マッチ）した場合、処理はステップ９３０に進み、合致しなければモジュールの処理は終了する。今回の例では、データ７５３を受け取った際に合致するものとする。
（iii）ステップ９３０
アクション機能５２０は、合致（マッチ）した内容に応じたアクションを行う。今回の例では、携帯電話１５３にメールを送信するアクションが実行される。

＜データフィルタモジュールの処理＞
図１０は、データフィルタモジュール３２３の処理内容を説明するためのフローチャートである。以下、図７のデータを受信した例を使って説明する。
（i）ステップ１０１０
データ受付モジュール３２１は、宅内デバイス群からデータを受信する。今回の例では、データ７５１及び７９１をまず受け取り、その１分後にデータ７５２及び７９２を受け取り、さらにその１分後にデータ７５３及び７９３を受け取り…のようにデータを受信する。
（ii）ステップ１０２０
データ一時蓄積機能６１０は、受信データを定められた間隔だけ一時的に蓄積する。例えば、ここでは、５分間分のデータを蓄積するとする。つまり図７のデータ全てが保存されることになる。
（iii）ステップ１０３０
データ集計機能６２０は、ステップ１０２０で蓄積したデータを集計する。今回の例では、フラグ７３０を省略、バッテリ残量７４０の平均を取り、電力使用量７８０の和を取る。結果、図８のようなデータが生成される。

なお、中間サーバ１３０が複数設置されている場合、それぞれの中間サーバ１３０が互いに通信し合い、他の中間サーバのデータの蓄積の程度や情報量等の情報を取得して、互いに収集サーバ１１０に対してデータを送信するタイミングを調整するようにしても良い。

＜データ集計全体処理＞
図１１は、データ収集全体の処理内容を説明するためのシーケンス図である。
（i）シーケンス１１１０
中間サーバ１３０が、宅内デバイス群１５０からデータを受信する。今回の例では、中間サーバ１３０は、データ７５１及び７９１をまず受け取り、その１分後にデータ７５２及び７９２を受け取り、さらにその１分後にデータ７５３及び７９３を受け取り…のようにデータを受信する。
（ii）シーケンス１１２０
リアルタイム処理モジュール３２２が、受け取ったデータを基に図９で説明したような処理を行う。今回の例では、データ７５３を処理した際に、アクションとしてメールを携帯電話に送信する。
（iii）シーケンス１１３０
ユーザ１６０は、携帯電話１５３によって通知のメールを受け取り、それを見ることにより、防犯上の問題が発生したことを知ることができる。
（iv）シーケンス１１４０
データフィルタモジュール３２３は、受け取ったデータについて図１０で説明した処理を実行する。今回の例では、図８のようなデータが生成され、生成されたデータが収集サーバ１１０に送信される。
（v）シーケンス１１５０
収集サーバ１１０は、受け取ったデータをデータベース２４０に保存する。ここでは、図８のようなデータが保存される。
（vi）シーケンス１１６０
収集サーバ１１０は、データベース２４０のデータを可視化する。例えば、データを表にして出力したり、グラフ化したり、ユーザ１６０の要求に応じて当該情報を提供したり、収集サーバ１１０のディスプレイに表示する等して管理者に提示したりする。これにより、ユーザ１６０や収集サーバ１１０の管理者は、宅内の消費電力や防犯センサのバッテリ残量を知ることが出来る。

＜モジュール更新処理＞
図１２は、モジュール更新の処理内容を説明するためのシーケンス図である。図９や図１０のリアルタイム処理モジュール３２２の処理、及びデータフィルタモジュール３２３の処理は一例であり、実際には、ユーザ１６０のニーズに合わせた処理を記述したモジュールを開発した上で、図１２のように、ソフトウェア配信機能２１０を使ってモジュールを入れ替えることで処理を変えることができる。
（i）シーケンス１２１０
収集サーバ１１０は、モジュール配信機能を用いて、リアルタイム処理モジュールやデータフィルタモジュール（それぞれ苦心されたモジュール）を中間サーバ１３０に配信する。
（ii）シーケンス１２２０
中間サーバ１３０は、受け取ったモジュールをインストール・アンインストール機能３１１を使って、中間サーバ１３０上のファイルシステムに展開する。
（iii）シーケンス１２３０
中間サーバ１３０は、アップデート機能３１２を用いて、展開されたソフトウェアモジュールを起動する。

＜まとめ＞
本発明の実施形態では、宅内デバイス群（ゲートウェイ装置があっても良い）と収集サーバの間に中間サーバを設ける。中間サーバには、モジュール毎にリモートからソフトウェアをインストール・アンインストールできるソフトウェアモジュール管理フレームワークを設け、ソフトウェア管理フレームワーク上で動作するリアルタイム処理モジュールとデータフィルタモジュールを設ける。リアルタイム処理モジュールでは、デバイスから受信したデータを解析し、アクションが必要か否かを判定し、アクションが必要ならばデバイスにアクションを返す機能を持っている。アクションは中間サーバによって即座に送られるため、従来のように収集サーバからアクションを送信するよりもアクションが送信されるタイミングが早くなることが期待される。

また、データフィルタモジュールは、受信したデータを一定期間一時保存し、一時保存したデータを集計、整形を行った上で、収集サーバに送信する機能を持っている。つまり、図７のようなデータが直接収集サーバに送信される代わりに、図８のようなデータが送信されるようになる。よって、収集サーバの負荷は軽減される。

さらに、収集サーバはモジュール配信サーバとしても機能する。中間サーバ上のこれらのモジュールを配信、更新することで、リアルタイム処理モジュールやデータフィルタモジュールの処理をニーズに合わせて柔軟に変更できるようにする。このようにすることにより、収集サーバには、フィルタモジュールによりデータ量を削減されたデータのみが送信される。このため、収集サーバの負荷が軽減することが期待される。さらに、デバイスに対するアクションが収集サーバではなく、よりデバイスに近い中間サーバから発行されるため、アクションのレスポンスが早くなると期待される。

本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。

また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。

さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。

最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。

１００ データ収集システム（情報処理システム）
１１０ 収集サーバ
１２０、１４０ ネットワーク
１３０ 中間サーバ
１５０、１７０、１８０ 宅内デバイス群

Claims (6)

1. それぞれが複数のユーザデバイスを含む、複数の宅内デバイス群と、
   前記複数の宅内デバイス群から所定のデータを受信して加工する、複数の中間サーバと、
   前記複数の中間サーバから前記加工されたデータを収集して、データベースに保存する収集サーバと、を有し、
   前記複数の中間サーバのそれぞれは、前記収集サーバに収集される前記加工データを生成するために必要な複数のモジュールを有し、
   前記収集サーバは、前記複数のモジュールの少なくとも１つを更新するための更新モジュールデータを前記複数の中間サーバに配信し、
   前記複数の中間サーバのそれぞれは、更新対象であるモジュールに対して前記更新モジュールデータを適用し、適用後のモジュールを起動することにより旧モジュールを更新することを特徴とするデータ収集システム。
2. 請求項１において、
   前記複数の中間サーバのそれぞれは、前記収集サーバに送信すべきデータの送信間隔を調整した上で前記収集サーバにデータを送信することを特徴とするデータ収集システム。
3. 請求項１において、
   前記複数の中間サーバのそれぞれは、前記宅内デバイス群から取得したデータを解析し、解析結果に基づいて、前記宅内デバイス群の少なくとも１つのデバイスに対して前記解析結果に対応するアクションを送信することを特徴とするデータ収集システム。
4. 複数の中間サーバが、複数のモジュールを用いて、複数のユーザデバイスをそれぞれ含む複数の宅内デバイス群から所定のデータを受信して加工するステップと、
   収集サーバが、前記複数の中間サーバから前記加工されたデータを収集して、データベースに保存するステップと、
   前記収集サーバが、前記複数のモジュールの少なくとも１つを更新するための更新モジュールデータを前記複数の中間サーバに配信するステップと、
   前記複数の中間サーバのそれぞれが、更新対象であるモジュールに対して前記更新モジュールデータを適用し、適用後のモジュールを起動することにより旧モジュールを更新するステップと、
   を有することを特徴とするデータ収集方法。
5. 請求項４において、
   さらに、前記複数の中間サーバのそれぞれが、前記収集サーバに送信すべきデータの送信間隔を調整した上で前記収集サーバにデータを送信するステップを含むことを特徴とするデータ収集方法。
6. 請求項４において、
   前記複数の中間サーバそれぞれが、前記宅内デバイス群から取得したデータを解析するステップと、
   前記複数の中間サーバのそれぞれが、前記解析結果に基づいて、前記宅内デバイス群の少なくとも１つのデバイスに対して前記解析結果に対応するアクションを送信するステップと、
   を含むことを特徴とするデータ収集方法。

Images