(57)【要約】【課題】Ｍ２Ｍサービスにおけるゲートウェイ単位のデータの取得を低負荷で実行させるとともに、Ｍ２Ｍサービスで収集したデータの分析業務の運用性を高める（どんなデータベースが追加されても、ユーザが多くの知識を持たずにデータベースを運用することができるようになること）技術を提供する。【解決手段】本発明は、Ｍ２Ｍサーバによるデータ処理について提案する。Ｍ２Ｍサーバは、ゲートウェイ機器又は閲覧用機器からのリクエストを受け付け、当該リクエストを解析する。そして、Ｍ２Ｍサーバは、リクエストの内容によって、ゲートウェイ機器に接続される各デバイスで発生する生データ或いはその生データの統計データを登録、検索、又は削除する先のデータベースを識別し、対応する処理を実行する。さらに、Ｍ２Ｍサーバは、閲覧用機器からの閲覧リクエストを受け付けると、生データ格納用データベースから全ての生データを取得し、所定のフォーマットで構成されるビューデータを生成し、閲覧用機器に当該ビューデータを送信する。【選択図】図２
2014146123.tif 000002
【特許請求の範囲】
【請求項１】
Ｍ２Ｍサーバと、
データの発生元となる複数のデバイスと、
前記複数のデバイスとネットワークを介して接続され、各デバイスで発生した前記データを前記Ｍ２Ｍサーバに中継する複数のゲートウェイ機器と、
前記デバイスで発生したデータを前記Ｍ２Ｍサーバ経由で閲覧する閲覧用機器と、
前記複数のデバイスのそれぞれで発生した生データを格納する生データ格納用データベースと、前記生データに関する統計データを格納する統計データ格納用データベースと、を含むデータベース群と、を有し、
前記Ｍ２Ｍサーバは、前記ゲートウェイ機器又は前記閲覧用機器からのリクエストを受け付け、当該リクエストを解析し、当該リクエストの内容によって、前記生データ或いは前記統計データを登録、検索、又は削除する先のデータベースを識別し、対応する処理を実行し、
さらに、前記Ｍ２Ｍサーバは、前記閲覧用機器からの閲覧リクエストを受け付けると、前記生データ格納用データベースから全ての生データを取得し、所定のフォーマットで構成されるビューデータを生成し、前記閲覧用機器に当該ビューデータを送信することを特徴とするサーバシステム。
【請求項２】
請求項１において、
前記Ｍ２Ｍサーバは、前記複数のゲートウェイ機器のそれぞれが管理する複数のデバイスのそれぞれと対応付けてデバイスの生データ及び統計データを前記データベース群に格納することを特徴とするサーバシステム。
【請求項３】
請求項２において、
さらに、所定時間単位で前記生データ格納用データベースから各ゲートウェイ機器が管理する各デバイスの生データを取得し、当該取得した生データに対して統計処理を実行して統計データを生成し、前記Ｍ２Ｍサーバを介して、前記統計データを前記統計データ格納用データベースに格納する統計データ処理部を有することを特徴とするサーバシステム。
【請求項４】
サーバシステムにおけるデータ処理方法であって、
前記サーバシステムは、Ｍ２Ｍサーバと、データの発生元となる複数のデバイスと、前記複数のデバイスとネットワークを介して接続され、各デバイスで発生した前記データを前記Ｍ２Ｍサーバに中継する複数のゲートウェイ機器と、前記デバイスで発生したデータを前記Ｍ２Ｍサーバ経由で閲覧する閲覧用機器と、前記複数のデバイスのそれぞれで発生した生データを格納する生データ格納用データベースと、前記生データに関する統計データを格納する統計データ格納用データベースと、を含むデータベース群と、を有し、
前記データ処理方法は、
前記Ｍ２Ｍサーバが、前記ゲートウェイ機器又は前記閲覧用機器からのリクエストを受け付ける工程と、
前記Ｍ２Ｍサーバが、前記リクエストを解析し、当該リクエストの内容によって、前記生データ或いは前記統計データを登録、検索、又は削除する先のデータベースを識別し、対応する処理を実行する工程と、を有し、
前記対応する処理を実行する工程において、前記Ｍ２Ｍサーバは、前記リクエストが前記閲覧用機器からの閲覧リクエストである場合、前記生データ格納用データベースから全ての生データを取得し、所定のフォーマットで構成されるビューデータを生成し、前記閲覧用機器に当該ビューデータを送信することを特徴とするデータ処理方法。
【請求項５】
請求項４において、さらに、
前記Ｍ２Ｍサーバが、前記複数のゲートウェイ機器のそれぞれが管理する複数のデバイスのそれぞれと対応付けてデバイスの生データ及び統計データを前記データベース群に格納する工程を有することを特徴とするデータ処理方法。
【請求項６】
請求項５において、
前記サーバシステムは、さらに、統計データ処理部を有し、
前記データ処理方法は、さらに、前記統計データ処理部が、前記Ｍ２Ｍサーバを介して、所定時間単位で前記生データ格納用データベースから各ゲートウェイ機器が管理する各デバイスの生データを取得し、当該取得した生データに対して統計処理を実行して統計データを生成し、前記Ｍ２Ｍサーバを介して、前記統計データを前記統計データ格納用データベースに格納する工程を有することを特徴とするデータ処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、サーバシステム、及びデータ処理方法であって、例えば、国際標準に準拠したＭ２Ｍ情報管理技術に関するものである。
【背景技術】
【０００２】
近年、大量のセンサやデバイスからデータを収集・分析し、社会に新たな価値を生み出すための技術として、マシン・ツー・マシン（以下、Ｍ２Ｍ）の標準化が欧州電気通信標準化機構（ＥＴＳＩ）によって推進されている（非特許文献１を参照）。Ｍ２Ｍは、例えば、所定のデバイスやセンサにおいて取得された情報をサーバが取得し、デバイス等を制御する、自律情報収集・制御システムのことを意味する。さらに具体的には、電力情報の収集と電力制御、ミドルウェアの自動配信等が挙げられる。
【０００３】
Ｍ２Ｍ技術の具体的な適用先の一つには、家庭向けのエネルギー消費データの管理を行うＨＥＭＳ（Home Energy Management System）がある。ＨＥＭＳでは、たとえばその管理エリア内に大規模集合住宅が増築されると、その管理対象となる世帯も増加していく。この例からも分かるように、Ｍ２Ｍが管理するセンサやデバイスの数は、社会での動きに応じて大きく変動しうる。したがって、管理対象のセンサやデバイスの数に大きな変動があっても、管理対象のセンサやデバイスから発生するデータをすべて蓄積し、検索できることが求められている。このことはデータベースサーバを増設するスケールアウトという技術によって実現される。近年、ＮｏＳＱＬ（Not Only SQL）と呼ばれる種類のデータベースの多くはこのスケールアウトをサポートしており、代表的なものにＨＢａｓｅがある（非特許文献２を参照）。
【先行技術文献】
【非特許文献】
【０００４】
【非特許文献１】http://www.etsi.org/Website/Technologies/M2M.aspx
【非特許文献２】http://hbase.apache.org/
【発明の概要】
【発明が解決しようとする課題】
【０００５】
Ｍ２Ｍサービスにおけるデータ収集では、一般的に図１のようなシステム構成を採る。図１の構成では、ゲートウェイ機器の背後にあるデバイスが電力使用量などのデータを、ゲートウェイを経由してＭ２Ｍサーバに送信する。Ｍ２Ｍサーバに送信されたデータは、データベースなどのデータストアに保存される。ところで、Ｍ２Ｍサービスにおいて、ゲートウェイ機器に接続されているすべてのデバイスのデータをまとめて取得するということは必須である。例えば、ＨＥＭＳサービスでは、世帯ごとの電力使用量を１日単位で計算するのにこのような処理が必要になる。
【０００６】
しかし、データストアの保存はデバイス単位で実行され、データの取得もデバイス単位となる。このため、ゲートウェイ機器に接続されているすべてのデバイスのデータをまとめて取得するには、ゲートウェイ機器の背後にあるデバイスについてデータを取得するという処理を、デバイス１台ずつについてネットワーク経由で実行する必要があり、ネットワークやサーバ（Ｍ２Ｍサーバ）の負荷が大きくなるという課題がある。
【０００７】
また、Ｍ２Ｍサービスで収集したデータは通常、集計や相関分析などの統計処理の入力となり、この統計処理によって分析データが作成される。分析データの例としては、ある家庭での１時間ごとの電力使用量の合計が挙げられる。Ｍ２Ｍサービスの相互運用性の観点から、このようにして作成された分析データの閲覧は、ＥＴＳＩ  Ｍ２Ｍの標準インタフェースｍＩａを通して実行されるべきである。さらに、分析業務では、データが貯まるにつれて新しい分析処理を追加で実施できるようにしたいという要望がある。ＨＥＭＳサービスの場合でも、電力使用量の合計値、電力使用量と時間帯との相関分析、世帯構成と電力使用状況の相関分析など多様な分析処理が考えられる。したがって、実行する統計処理に応じて適切なデータストアを追加できる必要がある。つまり、例えば、デバイス毎の１時間当たりの電力使用量の合計というデータと１ヶ月間での各世帯での電力使用量の合計というデータとではデータの粒度が異なるため、蓄積に適するデータベースが異なってくる。そのため、蓄積すべきデータの種類に応じて適切なデータストアが必要になってくる。
【０００８】
しかし、そのためには、Ｍ２Ｍサービスの運用管理者がデータストアを追加するための手順を踏む必要がある。取り扱う分析データによって最適なデータストアは異なり、データストアを追加するための手順（データベースのインストール、バックアップ等の運用管理）は、データストアを実装するデータベース製品によって異なる。このため、Ｍ２Ｍサービスの運用管理者が複数のデータベース製品の運用について多くの知見を必要とするという課題がある。
【０００９】
本発明はこのような状況に鑑みなされたものであり、Ｍ２Ｍサービスにおけるゲートウェイ単位のデータの取得を低負荷で実行させるとともに、Ｍ２Ｍサービスで収集したデータの分析業務の運用性を高める（どんなデータベースが追加されても、ユーザが多くの知識を持たずにデータベースを運用することができるようになること）技術を提供するものである。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、ＥＴＳＩ  Ｍ２Ｍの論理ツリーデータモデルと物理データベースとの対応関係をサーバサイドで管理する。
【００１１】
つまり、本発明では、Ｍ２Ｍサーバによるデータ処理について提案する。Ｍ２Ｍサーバは、ゲートウェイ機器又は閲覧用機器からのリクエストを受け付け、当該リクエストを解析する。そして、Ｍ２Ｍサーバは、リクエストの内容によって、ゲートウェイ機器に接続される各デバイスで発生する生データ或いはその生データの統計データを登録、検索、又は削除する先のデータベースを識別し、対応する処理を実行する。さらに、Ｍ２Ｍサーバは、閲覧用機器からの閲覧リクエストを受け付けると、生データ格納用データベースから全ての生データを取得し、所定のフォーマットで構成されるビューデータを生成し、閲覧用機器に当該ビューデータを送信する。
【発明の効果】
【００１２】
本発明によれば、閲覧用機器がゲートウェイ機器に接続されているすべてのデバイスのデータをまとめて取得するのを、ネットワークやサーバに負荷をかけずに実行することができる。さらに、Ｍ２Ｍサービスの運用管理をより少ない予備知識で実施することができる。
【００１３】
さらなる本発明の特徴は、以下本発明を実施するための形態および添付図面によって明らかになるものである。
【図面の簡単な説明】
【００１４】
【図１】Ｍ２Ｍサービスにおけるデータ収集を実現する一般的な従来のシステムの構成を示す図である。
【図２】本発明によるＭ２Ｍサービスでのデータ収集を実現するシステム（サーバシステム）の構成例を示す図である。
【図３】本発明によるＭ２Ｍサービスで用いる、ＥＴＳＩ  Ｍ２Ｍに準拠した論理ツリーデータモデルを示す図である。
【図４】本発明の実施形態によるデータ構成例を示す図である。図４Ａは、Ｍ２Ｍサービスが管理する生データの構成例を示す図である。図４Ｂは、Ｍ２Ｍサービスが生成し、管理するビューデータの構成例を示す図である。図４Ｃは、Ｍ２Ｍサービスでの、統計データの構成を示す図である。
【図５】ゲートウェイ機器がデバイスから受信した電力使用量をＭ２ＭサーバにＨＴＴＰプロトコルを用いて登録するときのＨＴＴＰリクエストの例を示す図である。
【図６】Ｍ２Ｍサーバがゲートウェイ機器から送信された、電力使用量を登録するＨＴＴＰリクエストへのレスポンスの例を示す図である。
【図７】データ処理リクエストのＵＲＬのパターンの一覧を示す図である。
【図８】Ｍ２Ｍサーバの論理ツリー管理部が実行する処理概要を説明するためのフローチャートである。
【図９】コンテナツリー作成処理の詳細を説明するためのフローチャートである。
【図１０】生データの作成内容（ルール）を示す図である。
【図１１】統計データの作成内容（ルール）を示す図である。
【図１２】図１０のルールに従って作成された生データのテーブルの構成例を示す図である。
【図１３】図１１のルールに従って作成された統計データのテーブルの構成例を示す図である。
【図１４】ツリーデータ作成処理の詳細を説明するためのフローチャートである。
【図１５】ツリーデータ取得処理の詳細を説明するためのフローチャートである。
【図１６】生データ取得処理の詳細を説明するためのフローチャートである。
【図１７】ビューデータ取得処理の詳細を説明するためのフローチャートである。
【図１８】統計データ取得処理の詳細を説明するためのフローチャートである。
【図１９】ツリーデータ削除処理の詳細を説明するためのフローチャートである。
【図２０】ツリーデータ群検索処理の概要を示すフローチャートである。
【図２１】生データ群検索処理の詳細を説明するためのフローチャートである。
【図２２】ビューデータ群検索処理の詳細を説明するためのフローチャートである。
【図２３】ビューデータ群検索処理における「レコードリストをタイムスタンプ値で分類」する処理の入出力例を示す図である。
【図２４】統計データ群検索処理の詳細を説明するためのフローチャートである。
【図２５】統計処理の内容を説明するためのフローチャートである。
【図２６】統計処理において、その過程で得られるレコードリストを基に、統計結果の中間結果であるＫｅｙ−Ｖａｌｕｅペアを作成する処理を説明するためのフローチャートである。
【図２７Ａ】統計データの作成内容（ルール）を示す図である。
【図２７Ｂ】図２７Ａのルールに従って作成された統計データのテーブルの構成例を示す図である。
【発明を実施するための形態】
【００１５】
以下、添付図面を参照して本発明の実施形態について説明する。添付図面では、機能的に同じ要素は同じ番号で表示される場合もある。なお、添付図面は本発明の原理に則った具体的な実施形態と実装例を示しているが、これらは本発明の理解のためのものであり、決して本発明を限定的に解釈するために用いられるものではない。
【００１６】
本実施形態では、当業者が本発明を実施するのに十分詳細にその説明がなされているが、他の実装・形態も可能で、本発明の技術的思想の範囲と精神を逸脱することなく構成・構造の変更や多様な要素の置き換えが可能であることを理解する必要がある。従って、以降の記述をこれに限定して解釈してはならない。
【００１７】
更に、本発明の実施形態は、後述されるように、汎用コンピュータ上で稼動するソフトウェアで実装しても良いし専用ハードウェア又はソフトウェアとハードウェアの組み合わせで実装しても良い。
【００１８】
なお、以後の説明では「テーブル」形式によって本発明の各情報について説明する場合があるが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶことがある。
【００１９】
また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。
【００２０】
以下では、Ｍ２Ｍサーバの各処理部（リクエスト受信部、リクエスト解析部、データ管理部、論理ツリー管理部）の何れかが動作主体として本発明の実施形態における各処理について説明を行うが、各処理部はプログラムをＲＡＭ上で展開してプロセッサによって実行されるので、プロセッサ（図示せず）を主語とした説明としてもよい。また、後述のフローチャートで説明される各処理は、Ｍ２Ｍサーバ以外のサーバ計算機や情報処理装置が行う処理としてもよい。各フローチャートで説明されるプログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。
【００２１】
以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。なお、本発明の実施形態では、理解を容易にするため、電力使用量の収集・分析を対象業務の例として説明するが、これに限定されるものではない。
【００２２】
＜システム構成＞
図２は、本発明の実施形態による情報収集管理システム（Ｍ２Ｍサーバシステム）１０は、データ収集の対象であるデバイス群（デバイス１〜Ｎ）１１と、デバイス群１１に接続されるゲートウェイ機器１２と、ゲートウェイ機器１２と接続されるＭ２Ｍサーバ１３と、Ｍ２Ｍサーバ１３と接続されるデータストア（データベース群）１４と、Ｍ２Ｍサーバ１３と接続される閲覧用機器１５と、Ｍ２Ｍサーバと接続される統計処理部（統計処理装置）１６と、を有している。
【００２３】
デバイス群１１（デバイス１〜Ｎ）は、スマートプラグに接続された家電、電子機器などである。また、例えば、デバイス群１１は、スマートプラグを経由して電力使用量の情報を３分ごとにゲートウェイ機器１２に転送する。なお、転送には、Ｚｉｇｂｅｅ（登録商標）などの短距離無線通信技術が用いられる。
【００２４】
ゲートウェイ機器１２は、デバイス群１１のそれぞれから転送された電力使用量の情報をＭ２Ｍサーバ１３に送信する。ゲートウェイ機器１２からＭ２Ｍサーバ１３へのデータの送信では、ＨＴＴＰ（HyperText Transfer Protocol）が用いられ、図５のような形式の電文を送信する。図５において、ｃｏｎｔｅｎｔ要素には、電力使用量の測定開始時刻を基準時刻からの経過ミリ秒数を表す整数の６４ビット表現と、測定時間の長さを表す整数の６４ビット表現と、その間の電力使用量のワット時値を表す倍精度浮動小数点数の６４ビット表現とを結合してできる１９２ビットのバイナリデータをＢＡＳＥ６４エンコードしたものである。ゲートウェイ機器１２は、処理結果として図６のような形式の電文（レスポンス）をＭ２Ｍサーバ１３から受信する。
【００２５】
Ｍ２Ｍサーバ１３は、リクエスト受信部１３１と、リクエスト解析部１３２と、データ管理部１３３と、論理ツリー管理部１３４と、を有している。
【００２６】
リクエスト受信部１３１は、ゲートウェイ機器１２から送信されたＨＴＴＰリクエストを受信し、リクエスト解析部１３２に転送する。
【００２７】
リクエスト解析部１３２は、リクエスト受信部１３１から転送されたリクエストのリクエスト先ＵＲＬを取得する。取得したリクエストのメソッドとＵＲＬパターンが図７に示す表のもののいずれかに一致するときは、リクエストをデータ管理部１３３に転送する。なお、取得したリクエストのメソッドとＵＲＬパターンが図７に示す表のもののいずれとも一致しないときの処理の説明については、本データ管理方式と関係しないので省略する。
【００２８】
データ管理部１３３では、リクエスト解析部１３２から転送されたリクエストを論理ツリー管理部１３４に委譲し、論理ツリー管理部１３４が返却する処理結果をリクエスト解析部１３２に返却する。
【００２９】
論理ツリー管理部１３４は、データ管理部１３３から委譲されたデータ処理リクエストの内容に基づいて、登録すべきデータ（生データ、統計データ等）を、データストア１４のデータベースに対応付けて格納する。データの種類によって格納場所が異なるため、論理ツリー管理部１３４は、各データをその種類に応じて振り分けてデータベースに格納する。詳細な処理の内容は、後述の図８等に示すフローチャートに示されている。
【００３０】
データストア１４は、Ｍ２Ｍサーバ１３にて収集したデータを、Ｍ２Ｍデータ閲覧アプリケーション１５１などから共有可能なように保存する。ここでは、データストアはＨＢａｓｅのデータベースである。データストア１４には、生データ用データベース１４１と統計データ用データベース１４２が含まれる。ただし、データストア１４に生データと統計データのいずれにも該当しないものを含むことを排除するものではない。なお、生データ用データベース１４１のデータは、例えばテーブル構造によって格納することができ、そのテーブル構造は、図１０に示される通りである。また、同様に、統計データ用データベース１４２のデータも、例えばテーブル構造によって格納することができ、そのテーブル構造は、図１１に示される通りである。
【００３１】
閲覧用機器１５は、典型的には電子タブレットなどのハードウェアで構成されるが、パソコンやスマートフォンであってもよい。ユーザはこの閲覧用機器１５に、該閲覧用機器１５で動作する、Ｍ２Ｍデータ閲覧用アプリケーション１５１をインストールする。ユーザは、このＭ２Ｍデータ閲覧用アプリケーション１５１を用いて所定の操作を行い、Ｍ２Ｍサーバ１３を通して電力使用量の情報を取得し、閲覧用機器１５の画面上で該情報を閲覧する。
【００３２】
統計処理部１６は、Ｍ２Ｍサーバ１３を介して、データストア１４の生データ用データベース１４１から所定期間内に蓄積された生データを取得し、統計データを生成して、Ｍ２Ｍサーバ１３を介して、データストア１４の統計データ用データベース１４２に生成した統計データを格納するように動作する。なお、統計処理部１６の更なる詳細については後述する。
【００３３】
＜取り扱うデータの種類＞
本発明の実施形態において取り扱うデータは、Ｍ２Ｍサーバ１３にゲートウェイ機器１２を介して接続されるデバイス群１１のそれぞれから収集された生データと、生データを一定の単位でまとめて論理的に１つのデータに見せるビューデータと、生データに対して統計処理を行って得られるデータである統計データの３種類を含んでいる。
【００３４】
生データは、デバイスの電力使用量である。ビューデータは、ゲートウェイの背後にあるデバイスの電力使用量の集合である。統計データは、ゲートウェイの背後にあるデバイスの電力使用量の１日単位の合計値である。
【００３５】
＜取り扱うデータの種類に対する論理ツリーデータモデル＞
図３は、本発明の実施形態において取り扱うデータの種類に対する論理ツリーデータモデルを示す図である。
【００３６】
論理ツリーデータモデルは、ゲートウェイ機器やその背後にあるデバイスの情報を含むｓｃｌｓノード３１と、ゲートウェイ機器１２やその背後のデバイス群１１からＭ２Ｍサーバ１３に収集・蓄積する電力使用量のデータの情報を含むｃｏｎｔａｉｎｅｒｓノード３２によって構成される。
【００３７】
ｓｃｌｓノード３１の下には、Ｍ２Ｍサーバ１３が管理対象とする１台のゲートウェイ機器１２に対して、該ゲートウェイ機器の情報を表すｓｃｌノード３１が１件紐づけられている。ｓｃｌノード３１の下にあるｇｗ１及びｇｗ２という文字列は、ゲートウェイの識別子を表す。また、ｓｃｌノード３１の下には、該ゲートウェイ機器１２の背後にあるデバイスの集合を表すａｔｔａｃｈｅｄＤｅｖｉｃｅｓノード３１１が設けられている。このノードの下に、該ゲートウェイ機器１２の背後にあるデバイスを表すａｔｔａｃｈｅｄＤｅｖｉｃｅノード３１１が、該ゲートウェイ機器１２の背後にあるデバイスの数だけ紐づけられる。ｄｅｖ１及びｄｅｖ２という文字列は、該ゲートウェイ機器１２の背後にあるデバイスの識別子を表している。デバイスの識別子の一意性は、上位のゲートウェイ機器１２の中で保証されていればよく、Ｍ２Ｍサーバ１３全体で一意である必要はない。
【００３８】
ｃｏｎｔａｉｎｅｒｓノード３２の下には、上述の３種類のデータ（生データ、ビューデータ、統計データ）を表すノードが紐づけられている。
【００３９】
生データのｃｏｎｔａｉｎｅｒを表す識別子は、ｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ（Ｙ＝１，２，３・・・）という形式である。ここで、ｇｗＸ（Ｘ＝１，２，３・・・）はｓｃｌｓノード３１以下に現れるゲートウェイ機器の識別子であり、ｄｅｖＹはｇｗＸが表すｓｃｌノード３１のａｔｔａｃｈｅｄＤｅｖｉｃｅｓ３１１以下に現れるデバイスの識別子と同じである。つまり、生データはデバイスごとにｃｏｎｔａｉｎｅｒノード３２を持つことになる。このｃｏｎｔａｉｎｅｒノード３２の下に該デバイスの電力使用量のデータの集合を表すｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓノード３１２が紐づけられ、その下に測定時刻ごとに電力使用量のデータが格納される。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノード３１２の識別子はタイムスタンプを用いて表されている。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノードに紐づくｃｏｎｔｅｎｔ３１２１は、電力使用量の測定開始時刻を基準時刻からの経過ミリ秒数を表す整数の６４ビット表現と、測定時間の長さをミリ秒単位で表す整数の６４ビット表現と、その間の電力使用量のワット時値を表す倍精度浮動小数点数の６４ビット表現とを結合してできる１９２ビットのバイナリデータ（図４Ａ参照）をＢＡＳＥ６４エンコードしたものとなっている。
【００４０】
ビューデータのｃｏｎｔａｉｎｅｒを表す識別子は、ｖｉｅｗ＿ｐｏｗ＿ｇｗＸ（Ｘ＝１，２，３・・・）という形式で表される。ここで、ｇｗＸはｓｃｌｓノード３１以下に現れるゲートウェイ機器１２の識別子と同一である。つまり、生データはゲートウェイ機器１２ごとにｃｏｎｔａｉｎｅｒノード３２を持つ。このｃｏｎｔａｉｎｅｒノード３２の下に該ゲートウェイ下のデバイスの電力使用量のデータの集合を表すｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓノード３１３が紐づけられ、その下に測定時刻ごとに電力使用量のデータが格納される。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノード３１３の識別子もタイムスタンプを用いて表される。そして、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノードに紐づけられるｃｏｎｔｅｎｔは、ビューデータに含まれる生データの数を表す整数の３２ビット表現と、それに続いて生データのデバイスＩＤの長さをビット単位で表す整数の３２ビット表現と、生データのデバイスＩＤのビット列と、生データを表す１９２ビットのバイナリデータを生データの数だけ連結したバイナリデータ（図４Ｂ参照）をＢＡＳＥ６４エンコードしたものである。
【００４１】
統計データのｃｏｎｔａｉｎｅｒを表す識別子は、ｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸ（Ｘ＝１，２，３・・・）という形式で表される。ここで、ｇｗＸはｓｃｌｓノード３１以下に現れるゲートウェイ機器１２の識別子と同一である。つまり、統計データはゲートウェイ機器１２ごとにｃｏｎｔａｉｎｅｒノード３２を持つ。このｃｏｎｔａｉｎｅｒノード３２の下に該デバイスの電力使用量のデータの集合を表すｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓノード３１４が紐づけられ、その下に測定時刻ごとに電力使用量のデータが格納される。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノードの識別子もタイムスタンプを用いて表される。ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅノードに紐づけられるｃｏｎｔｅｎｔは、電力使用量の測定開始時刻を基準時刻からの経過ミリ秒数を表す整数の６４ビット表現と、その間の電力使用量のワット時値を表す倍精度浮動小数点数の６４ビット表現とを結合してできる１２８ビットのバイナリデータ（図４Ｃ参照）をＢＡＳＥ６４エンコードしたものである。
【００４２】
以上のように、ｓｃｌｓノード３１とｃｏｎｔａｉｎｅｒノード３２とは、対応付けて管理される。よって、例えば、実際にいずれかのデバイスが削除されたような場合には、それに関するｃｏｎｔａｉｎｅｒノード３２に設けられた対応するデータの格納領域も削除される。また、いずれかのゲートウェイ機器１２の下にデバイスが追加されたような場合も、当該ゲートウェイ機器１２はＭ２Ｍサーバ１３にデバイスの追加を通知し、Ｍ２Ｍサーバ１３では、その追加されたデバイスに対応する格納場所が確保される。
【００４３】
＜各種データ構成の例＞
図４は、各種データの構成の例を示す図である。図４Ａは、生データの構成例を示し、図４Ｂは、ビューデータの構成例を示し、図４Ｃは、統計データの構成例を示している。
【００４４】
図４Ａに示されるように、ゲートウェイ機器１２から送信される生データは、例えば、測定開始時刻の情報４０１と、測定時間の長さの情報４０２と、電力使用量（測定期間内の合計使用量）の情報４０３と、を構成情報として含んでいる。
【００４５】
図４Ｂに示されるように、ビューデータは、Ｍ２Ｍサーバ１３において格納されている生データから生成されるデータであり、データ数の情報４１１と、デバイスＩＤの長さ（Ｎ１，Ｎ２，・・・）の情報４１２と、デバイスＩＤの情報４１３と、生データ４１４と、を構成情報として含んでいる。デバイスＩＤ４１３は、デバイスによって異なる情報であり、長さも異なるため、デバイスＩＤの長さの情報４１２を設定し、ビューデータからデバイスＩＤ４１３が抽出できるようになっている。デバイスＩＤのためのビット数を固定にすることも可能であるが、本実施形態では可変としている。
【００４６】
図４Ｃに示されるように、統計データは、測定開始時刻の情報４２１と、電力使用量の情報４２２と、を構成情報として含んでいる。統計期間は固定で決まっているため、開始時刻の情報から測定終了時刻も分かるようになっている。
【００４７】
＜各種リクエスト＞
図７は、データ処理リクエストのＵＲＬのパターンの一覧を示す図である。データ処理リクエストは、各種データ（生データ、ビューデータ、統計データ）について、各リソース（Ｃｏｎｔａｉｎｅｒ、ＣｏｎｔｅｎｔＩｎｓｔａｎｃｅｓ、ＣｏｎｔｅｎｔＩｎｓｔａｎｃｅ）について規定されている。
【００４８】
生データを格納する領域（テーブルｒａｗ＿ｐｏｗ：図１０参照）を生成する場合、ゲートウェイ機器１２がＣＲＥＡＴＥをリクエストコマンドとして用いる。具体的なＵＲＬは、ｃｏｎｔａｉｎｅｒｓ／と表され、デバイスが追加されたような場合にゲートウェイ機器１２によって発行されるリクエストである。
【００４９】
生データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅｓのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定時間内に含まれる全生データを取得する際に用いられるリクエストコマンドである。
【００５０】
生データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＣＲＥＡＴＥは、生成されたテーブル（図１０参照）に１つのレコードを生成して格納することをＭ２Ｍサーバ１３に指示するためのリクエストコマンドである。
【００５１】
生データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定時間における生データ（１件のデータ）を取得する際に用いられるリクエストコマンドである。
【００５２】
ビューデータを格納する領域（テーブルｖｉｅｗ＿ｐｏｗ：図示せず）を生成する場合、Ｍ２Ｍデータ閲覧アプリケーション１５１がＣＲＥＡＴＥをリクエストコマンドとして用いる。
【００５３】
ビューデータのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅｓのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定時間内に含まれる全ビューデータを取得する際に用いられるリクエストコマンドである。
【００５４】
ビューデータのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＣＲＥＡＴＥは、Ｍ２Ｍデータ閲覧アプリケーション１５１が、生成されたテーブル（ｖｉｅｗ＿ｐｏｗ）に１つのレコードを生成して格納することをＭ２Ｍサーバ１３に指示するためのリクエストコマンドである。
【００５５】
ビューデータのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定時間における生データ（１件のデータ）を取得する際に用いられるリクエストコマンドである。
【００５６】
統計データを格納する領域（テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗ：図１１参照）を生成する場合、統計処理部１６がＣＲＥＡＴＥをリクエストコマンドとして用いる。
【００５７】
統計データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅｓのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定時間内に含まれる全統計データを取得する際に用いられるリクエストコマンドである。
【００５８】
統計データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＣＲＥＡＴＥは、統計処理部１６が、生成されたテーブル（ｓｔａｔｉｓｔｉｃ＿ｐｏｗ）に１つのレコードを生成して格納することをＭ２Ｍサーバ１３に指示するためのリクエストコマンドである。
【００５９】
統計データのＣｏｎｔｅｎｔＩｎｓｔａｎｃｅのＧＥＴは、Ｍ２Ｍデータ閲覧アプリケーション１５１が所定期間における統計データ（１件のデータ）を取得する際に用いられるリクエストコマンドである。
【００６０】
＜リクエスト処理＞
図８は、Ｍ２Ｍサーバ１３におけるリクエスト処理の概要を説明するためのフローチャートである。
Ｓ８０１において、リクエスト受信部１３１は、ゲートウェイ機器１２や閲覧用機器（Ｍ２Ｍデータ閲覧アプリケーション１５１）１５からのデータ処理リクエストを受信し、その中に含まれるリクエストの名称を取得（特定）する。
【００６１】
Ｓ８０２において、リクエスト解析部１３２は、リクエスト受信部１３１から特定されたリクエストの名称を受信し、そのリクエストを解析する。
【００６２】
データ処理リクエストの名称がｃｏｎｔａｉｎｅｒＣｒｅａｔｅであれば、論理ツリー管理部１３４は、コンテナツリー作成処理を実行する（Ｓ８０３：図９）。
【００６３】
データ処理リクエストの名称がｃｏｎｔｅｎｔＩｎｓｔａｎｃｅＣｒｅａｔｅであれば、論理ツリー管理部１３４は、ツリーデータ作成処理を実行する（Ｓ８０４：図１４）。
【００６４】
データ処理リクエストの名称がｃｏｎｔｅｎｔＩｎｓｔａｎｃｅＲｅｔｒｉｅｖｅであれば、論理ツリー管理部１３４は、ツリーデータ取得処理を実行する（Ｓ８０５：図１５）を実行する。
【００６５】
データ処理リクエストの名称がｃｏｎｔｅｎｔＩｎｓｔａｎｃｅＤｅｌｅｔｅであれば、論理ツリー管理部１３４は、ツリーデータ削除処理を実行する（Ｓ８０６：図１９）を実行する。
【００６６】
データ処理リクエストの名称がｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓＲｅｔｒｉｅｖｅであれば、論理ツリー管理部１３４は、ツリーデータ群検索処理を実行する（Ｓ８０７：図２０）を行う。
【００６７】
＜コンテントツリー作成処理の詳細＞
図９は、コンテントツリー作成処理（Ｓ８０３）の詳細を説明するためのフローチャートである。
Ｓ９０１において、論理ツリー管理部１３４は、受け取ったリクエストのボディ部（図５参照）からｃｏｎｔａｉｎｅｒリソースのｉｄ属性を取得する。
【００６８】
そして、Ｓ９０２において、論理ツリー管理部１３４は、Ｓ９０１で取得したｉｄ属性のパターンに基づいて、リクエストが生データに関するものか、統計データに関するものか、或いはそのどちらでもないのか、チェックする。ｉｄ属性のパターンが生データに関するものである場合（ｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ）、処理はＳ９０３に移行する。ｉｄ属性のパターンが統計データに関するものである場合（ｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ）、処理はＳ９０５に移行する。その他の場合には、処理はＳ９０７に移行する。
【００６９】
Ｓ９０３において、論理ツリー管理部１３４は、ＨＢａｓｅデータベースにテーブルｒａｗ＿ｐｏｗが存在するか（つまり、生データを格納する領域が既に設けられているか）チェックする。
【００７０】
そして、該当するテーブルが存在しなければ、Ｓ９０４において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗを作成する。テーブルの構造は図１０に示す通りであり、これに倣って作成される。既にテーブルｒａｗ＿ｐｏｗが存在するときは、論理ツリー管理部１３４は何もせず、コンテントツリー作成処理を終了する。
【００７１】
Ｓ９０５において、論理ツリー管理部１３４は、ＨＢａｓｅデータベースにテーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するか（つまり、統計データを格納する領域が既に設けられているか）チェックする。
【００７２】
そして、該当するテーブルが存在しなければ、Ｓ９０６において、論理ツリー管理部１３４は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗを作成する。テーブルの構造は図１１に示す通りであり、これに倣って作成される。既にテーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するときは、論理ツリー管理部１３４は、何もせず、コンテントツリー作成処理を終了する。
【００７３】
Ｓ９０７において、論理ツリー管理部１３４は、リクエスト自体をエラーと判断し、コンテントツリー作成処理を終了する。
【００７４】
＜テーブル構造：テーブルｒａｗ＿ｐｏｗ＞
図１０は、テーブルｒａｗ＿ｐｏｗの作成ルールを示す図である。
図１０に示されるルールによれば、テーブルｒａｗ＿ｐｏｗには、項目として、ＲＯＷＫＥＹと、ｃｔｔ及びｃｔｐ（これらはカラムファミリｅに属する項目）と、ｇｗ及びｄｅｖ（これらはカラムファミリｋに属する項目）が作成される。図１２は、このルールに従って作成されたテーブル構成を示している。なお、図１２には、格納されるデータレコードの例も記載されているが、コンテントツリー作成処理では、データレコードを含まないテーブルのみが作成される。
【００７５】
＜テーブル構造：テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗ＞
図１１は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗの作成ルールを示す図である。
図１１に示されるルールによれば、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗには、項目として、ＲＯＷＫＥＹと、ｃｔｔ及びｃｔｐ（これらはカラムファミリｅに属する項目）と、ｇｗ（これはカラムファミリｋに属する項目）が作成される。図１３は、このルールに従って作成されたテーブル構成を示している。なお、図１３には、格納されるデータレコードの例も記載されているが、コンテントツリー作成処理では、データレコードを含まないテーブルのみが作成される。
【００７６】
＜ツリーデータ作成処理＞
図１４は、ツリーデータ作成処理（Ｓ８０４）の詳細を説明するためのフローチャートである。
Ｓ１４０１において、論理ツリー管理部１３４は、リクエストのＵＲＬから、ｃｏｎｔａｉｎｅｒリソースのｉｄ属性を取得する（ＵＲＬの表すパスの、ｃｏｎｔａｉｎｅｒｓの次）。
【００７７】
Ｓ１４０２において、論理ツリー管理部１３４は、ｉｄ属性パターンに基づいて、リクエストが、生データに関するものか、統計データに関するものか、或いはそのどちらでもないのか、チェックする。ｉｄ属性のパターンがｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ（生データ）に合致するとき、処理はＳ１４０３に移行する。ｉｄ属性のパターンがｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸ（統計データ）に合致するとき、処理はＳ１４０６に移行する。ｉｄ属性のパターンがいずれでもない場合、処理はＳ１４０９に移行する。
【００７８】
Ｓ１４０３において、論理ツリー管理部１３４は、ＨＢａｓｅデータベースにテーブルｒａｗ＿ｐｏｗが存在するかチェックする。該当するテーブルが存在する場合には、処理はＳ１４０４に移行する。該当するテーブルが存在しない場合には、Ｓ１４０５において、論理ツリー管理部１３４は、処理がエラーであると判断して当該ツリーデータ作成処理を終了する。
【００７９】
Ｓ１４０４において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗに、図１２の内容に従ってレコードを作成する。
【００８０】
Ｓ１４０６において、論理ツリー管理部１３４は、ＨＢａｓｅデータベースにテーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するかチェックする。該当するテーブルが存在する場合には、処理はＳ１４０７に移行する。該当するテーブルが存在しない場合には、論理ツリー管理部１３４は、処理がエラーであると判断して当該ツリーデータ作成処理を終了する。
【００８１】
Ｓ１４０７において、論理ツリー管理部１３４は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗに、図１３の内容に従ってレコードを作成する。
【００８２】
Ｓ１４０９において、論理ツリー管理部１３４は、Ｓ１４０２でｉｄ属性のパターンがいずれにも合致しないと判断されたため、エラーとしてツリーデータ作成処理を終了する。
【００８３】
＜ツリーデータ取得処理＞
図１５は、ツリーデータ取得処理（Ｓ８０５）の詳細を説明するためのフローチャートである。
Ｓ１５０１において、論理ツリー管理部１３４は、リクエストのＵＲＬから、ｃｏｎｔａｉｎｅｒリソースのｉｄ属性を取得する（ＵＲＬの表すパスの、ｃｏｎｔａｉｎｅｒｓの次）。
【００８４】
Ｓ１５０２において、論理ツリー管理部１３４は、ｉｄ属性パターンに基づいて、リクエストが、生データに関するものか、ビューデータに関するものか、統計データに関するものか、或いはそれらのどれでもないのか、チェックする。ｉｄ属性のパターンがｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ（生データ）に合致するときは生データ取得処理（Ｓ１５０３：図１６）を実行する。
【００８５】
ｉｄ属性のパターンがｖｉｅｗ＿ｐｏｗ＿ｇｗＸ（ビューデータ）に合致するときは、論理ツリー管理部１３４は、ビューデータ取得処理（Ｓ１５０４：図１７）を実行する。
【００８６】
ｉｄ属性のパターンがｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸ（統計データ）に合致するときは、論理ツリー管理部１３４は、統計データ取得処理（Ｓ１５０５：図１８）を実行する。
【００８７】
ｉｄ属性のパターンが前述のいずれにも合致しないときは、論理管理部は、エラーとしてツリーデータ取得処理を終了する（Ｓ１５０６）。
【００８８】
＜生データ取得処理＞
図１６は、生データ取得処理（Ｓ１５０３）の詳細を説明するためのフローチャートである。
Ｓ１６０１において、論理ツリー管理部１３４は、生データのデータレコードを格納するためのテーブルｒａｗ＿ｐｏｗが存在するかチェックする。該当するテーブルが存在すれば、処理はＳ１６０２に移行する。存在しなければ、処理はＳ１６０７に移行し、エラーとして生データ取得処理は終了する。
【００８９】
Ｓ１６０２において、論理ツリー管理部１３４は、リクエストＵＲＬからｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性（ＵＲＬの表すパスの、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓの次）を取得する。
【００９０】
そして、Ｓ１６０３において、論理ツリー管理部１３４は、このｉｄ属性を用いて、テーブルｒａｗ＿ｐｏｗのレコードの中から、ＲＯＷＫＥＹの値がｇｗＸ＿ｄｅｖＹ＿ｉｄであるものを検索する。
【００９１】
Ｓ１６０４において、論理ツリー管理部１３４は、該当するレコードがあるか判断する。該当レコードがある場合は、処理はＳ１６０５に移行し、該当レコードがない場合には、処理はＳ１６０６に移行する。
【００９２】
Ｓ１６０５において、論理ツリー管理部１３４は、ヒットしたレコードの内容をｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトとして返却する。
Ｓ１６０６において、論理ツリー管理部１３４は、ｎｕｌｌを返却する。
【００９３】
＜ビューデータ取得処理＞
図１７は、ビューデータ取得処理（Ｓ１５０４）の詳細を説明するためのフローチャートである。
Ｓ１７０１において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば、処理はS１７０２に移行する。当該テーブルが存在しなければ、エラーとしてビューデータ取得処理は終了する（Ｓ１７１２）。
【００９４】
Ｓ１７０２において、論理ツリー管理部１３４は、リクエストＵＲＬからｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性（ＵＲＬの表すパスの、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓの次）を取得する。
【００９５】
Ｓ１７０３において、論理ツリー管理部１３４は、論理ツリーの／ｓｃｌｓ／ｓｃｌ＿ｇｗＸ／ａｔｔａｃｈｅｄＤｅｖｉｃｅｓノードから、デバイスＩＤの一覧を取得する。このデバイスＩＤの一覧全体について繰り返し以下の処理を行う。
【００９６】
すなわち、まず、Ｓ１７０４において、論理ツリー管理部１３４は、デバイスＩＤ：ｄｅｖＹを１つ取得する。
【００９７】
そして、Ｓ１７０５において、論理ツリー管理部１３４は、取得したｄｅｖＹと前述のｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性を用いて、テーブルｒａｗ＿ｐｏｗのレコードで、ＲＯＷＫＥＹの値がｇｗＸ＿ｄｅｖＹ＿ｉｄであるものを検索する。
【００９８】
Ｓ１７０６において、論理ツリー管理部１３４は、該当するレコードがあるかチェックする。該当するレコードがある場合には、処理はＳ１７０７に移行する。該当するレコードがない場合には、当該取得したデバイスＩＤ：ｄｅｖＹについてのデータ取得処理は終了し、次のデバイスＩＤに処理は移行する。
【００９９】
Ｓ１７０７において、論理ツリー管理部１３４は、該当するレコードのデバイスＩＤと生データを取得する。
【０１００】
そして、Ｓ１７０８において、論理ツリー管理部１３４は、図４Ｂに示されるフォーマットに従ってバイナリデータを組み立てる。
【０１０１】
全てのデバイスＩＤについての処理（Ｓ１７０４〜Ｓ１７０８）の処理が終了すると、処理はＳ１７０９に移行する。
【０１０２】
Ｓ１７０９において、論理ツリー管理部１３４は、前述の繰り返し処理の中で、１回でも該当するレコードが検索されたか判断する。１件でもレコードが取得された場合には、処理はＳ１７１０に移行する。１件もレコードがなかった場合には、処理はＳ１７１１に移行する。
【０１０３】
Ｓ１７１０において、論理ツリー管理部１３４は、前述の繰り返し処理の中で組み立てたバイナリデータをｃｏｎｔｅｎｔとして含むｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトを作成して返却する。
Ｓ１７１１において、論理管理部１３４は、ｎｕｌｌを返却する。
【０１０４】
＜統計データ取得処理＞
図１８は、統計データ取得処理（Ｓ１５０５）の詳細を説明するためのフローチャートである。
Ｓ１８０１において、論理ツリー管理部１３４は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するかチェックする。当該テーブルがあれば、処理はＳ１８０２に移行する。当該テーブルが存在しなければ、エラーとして統計データ取得処理は終了する（Ｓ１８０７）。
【０１０５】
Ｓ１８０２において、論理ツリー管理部１３４は、リクエストＵＲＬからｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性（ＵＲＬの表すパスの、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓの次）を取得する。
【０１０６】
Ｓ１８０３において、論理ツリー管理部１３４は、取得したｉｄ属性を用いて、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗのレコードで、ＲＯＷＫＥＹの値がｇｗＸ＿ｉｄであるものを検索する。
【０１０７】
そして、論理ツリー管理部１３４は、該当するレコードがあるか判断する。該当するレコードがある場合には、処理はＳ１８０５に移行する。該当するレコードがない場合には、処理はＳ１８０６に移行する。
【０１０８】
Ｓ１８０５において、論理ツリー管理部１３４は、ヒットしたレコードの内容をｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトとして返却する。
Ｓ１８０６において、論理ツリー管理部１３４は、ｎｕｌｌを返却する。
【０１０９】
＜ツリーデータ削除処理＞
図１９は、テーブルからレコードを削除するためのツリーデータ削除処理（Ｓ８０６）の詳細を説明するためのフローチャートである。
Ｓ１９０１において、論理ツリー管理部１３４は、リクエストのＵＲＬから、ｃｏｎｔａｉｎｅｒリソースのｉｄ属性を取得する（ＵＲＬの表すパスの、ｃｏｎｔａｉｎｅｒｓの次）。
【０１１０】
Ｓ１９０２において、論理ツリー管理部１３４は、ｃｏｎｔａｉｎｅｒリソースのｉｄ属性のパターンが生データに関するものか（ｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹ）、統計データに関するものか（ｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸ）、或いは、いずれでもないかチェックする。
【０１１１】
ｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹに合致するときは、Ｓ１９０３において、論理ツリー管理部１３４は、さらに、ＨＢａｓｅデータベースにテーブルｒａｗ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば処理はＳ１９０４に移行する。当該テーブルが存在しなければ、処理は、Ｓ１９０５に移行し、エラーとしてツリーデータ削除処理は終了する。
【０１１２】
Ｓ１９０４において、論理ツリー管理部１３４は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性（ＵＲＬの表すパスの、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓの次）を取得し、テーブルｒａｗ＿ｐｏｗから、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性をＲＯＷＫＥＹに持つレコードを削除する。
【０１１３】
ｉｄ属性のパターンがｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸに合致するときは、Ｓ１９０６において、論理ツリー管理部１３４は、ＨＢａｓｅデータベースにテーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば、処理はＳ１９０７に移行する。当該テーブルが存在しない場合には、処理はＳ１９０８に移行し、エラーとしてツリーデータ削除処理は終了する。
【０１１４】
Ｓ１９０７において、論理ツリー管理部１３４は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性（ＵＲＬの表すパスの、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅｓの次）を取得し、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗから、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅのｉｄ属性をＲＯＷＫＥＹに持つレコードを削除する。
【０１１５】
ｉｄ属性のパターンが前述のいずれにも合致しないときは、エラーとしてツリーデータ削除処理は終了する（Ｓ１９０９）。
【０１１６】
＜ツリーデータ群検索処理＞
図２０は、ツリーデータ群検索処理（Ｓ８０７）の詳細を説明するためのフローチャートである。
Ｓ２００１において、論理ツリー管理部１３４は、リクエストのＵＲＬから、ｃｏｎｔａｉｎｅｒリソースのｉｄ属性を取得する（ＵＲＬの表すパスの、ｃｏｎｔａｉｎｅｒｓの次）。
【０１１７】
Ｓ２００２において、論理ツリー管理部１３４は、取得したｉｄ属性のパターンについて判定する。
【０１１８】
ｉｄ属性のパターンがｒａｗ＿ｐｏｗ＿ｇｗＸ＿ｄｅｖＹに合致するときは、論理ツリー管理部１３４は、生データ群検索処理（Ｓ２００３）を実行する。
【０１１９】
ｉｄ属性のパターンがｖｉｅｗ＿ｐｏｗ＿ｇｗＸに合致するときは、論理ツリー管理部１３４は、ビューデータ群検索処理（Ｓ２００４）を実行する。
【０１２０】
ｉｄ属性のパターンがｓｔａｔｉｓｔｉｃ＿ｐｏｗ＿ｇｗＸに合致するときは、論理ツリー管理部１３４は、統計データ群検索処理（Ｓ２００５）を実行する。
【０１２１】
ｉｄ属性のパターンが前述のいずれにも合致しないときは、論理ツリー管理部１３４は、エラーとしてツリーデータ検索処理を終了する（Ｓ２００６）。
【０１２２】
＜生データ群検索処理＞
図２１は、生データ群検索処理（Ｓ２００３）の詳細を説明するためのフローチャートである。
Ｓ２１０１において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば、処理はＳ２１０２に移行する。当該テーブルが存在しなければ、エラーとして生データ群検索処理は終了する（Ｓ２１１１）。
【０１２３】
Ｓ２１０２において、論理ツリー管理部１３４は、リクエストのクエリパラメータから、ｃｒｅａｔｅｄＡｆｔｅｒとｃｒｅａｔｅｄＢｅｆｏｒｅの値があれば取得し、日付に変換する。
【０１２４】
Ｓ２１０３において、論理ツリー管理部１３４は、ｃｒｅａｔｅｄＡｆｔｅｒの値が存在するか否か判断する。ｃｒｅａｔｅｄＡｆｔｅｒの値が存在するときは、処理はＳ２１０４に移行し、存在しない場合には、処理はＳ２１０５に移行する。
【０１２５】
Ｓ２１０４において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最小値をｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒに設定する。
【０１２６】
Ｓ２１０５において、論理ツリー管理部１３４は、ｃｒｅａｔｅｄＢｅｆｏｒｅの値が存在するか否か判断する。ｃｒｅａｔｅｄＢｅｆｏｒｅの値が存在する場合には、処理はＳ２１０６に移行し、存在しない場合には、処理はＳ２１０７に移行する。
【０１２７】
Ｓ２１０６において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最大値をｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅに設定する。
【０１２８】
そして、Ｓ２１０７において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗのレコードで、ＲＯＷＫＥＹの値がｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒ以上ｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅ以下であるものを検索する。ただし、ｃｒｅａｔｅｄＡｆｔｅｒが存在しないときはｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒを検索条件に含めず、ｃｒｅａｔｅｄＢｅｆｏｒｅが存在しないときはｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅを検索条件に含めない。
【０１２９】
Ｓ２１０８において、論理ツリー管理部１３４は、Ｓ２１０７の検索の結果、該当するレコードが１件でもあるか否か判断する。１件でも検索結果がある場合は、処理はＳ２１０９に移行し、１件もない場合には、処理はＳ２１１０に移行する。
【０１３０】
Ｓ２１０９において、論理ツリー管理部１３４は、ヒットしたレコードの各々の内容を含むｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトのリストを返却する。
Ｓ２１１０において、論理ツリー管理部１３４は、空のリストを返却する。
【０１３１】
＜ビューデータ群検索処理＞
図２２は、ビューデータ群検索処理（Ｓ２００４）の詳細を説明するためのフローチャートである。
Ｓ２２０１では、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば、処理はＳ２２０２に移行する。当該テーブルが存在しなければ、エラーとしてビューデータ検索処理は終了する（Ｓ２２２０）。
【０１３２】
Ｓ２２０２において、論理ツリー管理部１３４は、リクエストのクエリパラメータから、ｃｒｅａｔｅｄＡｆｔｅｒとｃｒｅａｔｅｄＢｅｆｏｒｅの値があれば取得し、日付に変換する。
【０１３３】
Ｓ２２０３において、論理ツリー管理部１３４は、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトリストを空のリストに設定する。また、Ｓ２２０４において、論理ツリー管理部１３４は、レコードリストを空のリストに設定する。
【０１３４】
Ｓ２２０５において、論理ツリー管理部１３４は、論理ツリーの／ｓｃｌｓ／ｓｃｌ＿ｇｗＸ／ａｔｔａｃｈｅｄＤｅｖｉｃｅｓノードから、デバイスＩＤの一覧を取得する。このデバイスＩＤの一覧全体について以下の繰り返し処理１を行う。
すなわち、Ｓ２２０６において、論理ツリー管理部１３４は、デバイスＩＤ：ｄｅｖＹを取得し、Ｓ２２０７において、ｃｒｅａｔｅｄＡｆｔｅｒの値が存在するか判断する。当該値が存在する場合には、処理はＳ２２０８に移行し、存在しなければ、処理はＳ２２０９に移行する。
【０１３５】
Ｓ２２０８において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最小値をｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒに設定する。
【０１３６】
Ｓ２２０９において、論理ツリー管理部１３４は、ＣｒｅａｔｅｄＢｅｆｏｒｅの値が存在するか判断する。当該値が存在すれば、処理はＳ２２１０に移行し、存在しなければ、処理はＳ２２１１に移行する。
【０１３７】
Ｓ２２１０において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最大値をｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅに設定する。
【０１３８】
そして、Ｓ２２１１において、論理ツリー管理部１３４は、テーブルｒａｗ＿ｐｏｗのレコードで、ＲＯＷＫＥＹの値がｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒ以上ｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅ以下であるものを検索する。ただし、ｃｒｅａｔｅｄＡｆｔｅｒの値が存在しないときはｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＡｆｔｅｒを検索条件に含めず、ｃｒｅａｔｅｄＢｅｆｏｒｅの値が存在しないときはｇｗＸ＿ｄｅｖＹ＿ｃｒｅａｔｅｄＢｅｆｏｒｅを検索条件に含めない。
【０１３９】
Ｓ２２１２において、論理ツリー管理部１３４は、Ｓ２２１１の検索によって得られたレコード全件をレコードリストに追加する。以上、Ｓ２２０６〜Ｓ２２１２までの処理を繰り返し処理１とする。
【０１４０】
Ｓ２２１３において、論理ツリー管理部１３４は、繰り返し処理１によって得られたレコードリストをタイムスタンプ値で分類し、タイムスタンプ値と、前述のレコードリストのサブリストとのマッピングを作成する。この処理の入出力は、図２３に示される通りである。つまり、レコードリストの各レコードを、タイムスタンプ値毎にまとめて出力する。
【０１４１】
そして、タイムスタンプ値とレコードリストのサブリストのマッピングに対し、以下の繰り返し処理２（Ｓ２２１４〜Ｓ２２１８までの処理）を行う。
【０１４２】
すなわち、Ｓ２２１４において、論理ツリー管理部１３４は、タイムスタンプに対応するレコードリストのサブリストを取得する。このサブリストについて、以下の繰り返し処理３（Ｓ２２１５〜Ｓ２２１６までの処理）を行う。
【０１４３】
Ｓ２２１５において、論理ツリー管理部１３４は、サブリストのレコード１件に対し、そのデバイスＩＤと生データとを取得する。
【０１４４】
取得したデバイスＩＤと生データを用い、図４Ｂのフォーマットに従ってバイナリデータを組み立てる。
【０１４５】
Ｓ２２１７において、論理ツリー管理部１３４は、繰り返し処理３で組み立てたバイナリを基に、タイムスタンプに対するｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトを作成する。
【０１４６】
また、Ｓ２２１８において、論理ツリー管理部１３４は、作成したｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトを、ｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトリストに追加する（以上、繰り返し処理２）。
【０１４７】
Ｓ２２１９において、論理ツリー管理部１３４は、このようにして得られたｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトリストを返却する。
【０１４８】
＜統計データ群検索処理＞
図２４は、統計データ群検索処理（Ｓ２００５）の詳細を説明するためのフローチャートである。
Ｓ２４０１において、論理ツリー管理部１３４は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗが存在するかチェックする。当該テーブルが存在すれば、処理はＳ２４０２に移行する。当該テーブルが存在しなければ、エラーとして統計データ群検索処理は終了する（Ｓ２４１１）。
【０１４９】
Ｓ２４０２において、論理ツリー管理部１３４は、リクエストのクエリパラメータから、ｃｒｅａｔｅｄＡｆｔｅｒとｃｒｅａｔｅｄＢｅｆｏｒｅの値があれば取得し、日付に変換する。
【０１５０】
Ｓ２４０３において、論理ツリー管理部１３４は、ｃｒｅａｔｅｄＡｆｔｅｒの値が存在するか否か判断する。当該値が存在するときは、処理はＳ２４０４に移行し、存在しなければ、処理はＳ２４０５に移行する。
【０１５１】
Ｓ２４０４において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最小値をｇｗＸ＿ｃｒｅａｔｅｄＡｆｔｅｒに設定する。
【０１５２】
Ｓ２４０５において、論理ツリー管理部１３４は、ｃｒｅａｔｅｄＢｅｆｏｒｅの値が存在するか否か判断する。当該値が存在するときは、処理はＳ２４０６に移行し、存在しない場合には、処理はＳ２４０７に移行する。
【０１５３】
Ｓ２４０６において、論理ツリー管理部１３４は、検索対象のＲＯＷＫＥＹの最大値をｇｗＸ＿ｃｒｅａｔｅｄＢｅｆｏｒｅの値に設定する。
【０１５４】
そして、Ｓ２４０７において、論理ツリー管理部１３４は、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗのレコードで、ＲＯＷＫＥＹの値がｇｗＸ＿ｃｒｅａｔｅｄＡｆｔｅｒ以上ｇｗＸ＿ｃｒｅａｔｅｄＢｅｆｏｒｅ以下であるものを検索する。ただし、ｃｒｅａｔｅｄＡｆｔｅｒの値が存在しないときはｇｗＸ＿ｃｒｅａｔｅｄＡｆｔｅｒを検索条件に含めず、ｃｒｅａｔｅｄＢｅｆｏｒｅの値が存在しないときはｇｗＸ＿ｃｒｅａｔｅｄＢｅｆｏｒｅを検索条件に含めない。
【０１５５】
Ｓ２４０８において、論理ツリー管理部１３４は、該当するレコードがあるか否か判断する。該当するレコードが１件でもある場合は、処理はＳ２４０９に移行し、１件も存在しない場合には、処理はＳ２４１０に移行する。
【０１５６】
Ｓ２４０９において、論理ツリー管理部１３４は、ヒットしたレコードの各々の内容を含むｃｏｎｔｅｎｔＩｎｓｔａｎｃｅオブジェクトのリストを返却する。
Ｓ２４１０において、論理ツリー管理部１３４は、空のリストを返却する。
【０１５７】
＜統計処理部による処理＞
図２５は、統計処理部１６による処理の概要を説明するためのフローチャートである。統計処理部１６は、生データのテーブル名ｒａｗ＿ｐｏｗと、集計対象の日付を入力として、統計データ用のテーブルのレコードを出力とする処理を行う。
【０１５８】
まず、Ｓ２５０１において、統計処理部１６は、論理ツリーの／ｓｃｌｓノードから、ゲートウェイＩＤの一覧を取得する。
【０１５９】
Ｓ２５０２において、統計処理部１６は、レコードリストを空のリストに設定する。そして、取得したゲートウェイＩＤの一覧全体について繰り返し処理４（Ｓ２５０３及びＳ２５０４）が行われる。
【０１６０】
Ｓ２５０３において、統計処理部１６は、指定の生データテーブルｒａｗ_ｐｏｗから、ゲートウェイｇｗＸの生データであって指定した日付のもの（指定した日付一日分の生データ）を取得する。ここで、指定した日付のものというのは、生データのタイムスタンプが表す日付の時刻部分を切り捨てたものが指定した日付に一致するもののことを言う。
【０１６１】
そして、Ｓ２５０４において、統計処理部１６は、Ｓ２５０３で取得した生データ全件をレコードリストに追加する。
【０１６２】
Ｓ２５０５において、統計処理部１６は、このレコードリストを基に、＜ゲートウェイＩＤ，日付＞をキーとして測定値を値とするＫｅｙ-ＶａｌｕｅペアのリストＭを作成する（図２６参照）。なお、このリストの相異なる２つの要素には、キーが重複するようなものがあってもよい。
【０１６３】
Ｓ２５０６において、統計処理部１６は、統計処理済Ｋｅｙ−ＶａｌｕｅペアのマップＲを空のマップとして用意する。そして、前述のＫｅｙ-ＶａｌｕｅペアのリストＭについて以下の繰り返し処理５（Ｓ２５０７〜Ｓ２５１０までの処理）が行われる。
【０１６４】
すなわち、Ｓ２５０７において、統計処理部１６は、ＭからＫｅｙ-Ｖａｌｕｅペア＜＜ｇ，ｄ＞，ｓ＞を取得する。ここで、ｇはゲートウェイＩＤ、ｄは日付、ｓは測定値を表している。
【０１６５】
Ｓ２５０８において、統計処理部１６は、＜ｇ，ｄ＞がＲのエントリにあるか否か判断する。＜ｇ，ｄ＞がＲのエントリにある場合は、処理はＳ２５０９に移行し、ない場合には、処理はＳ２５１０に移行する。
【０１６６】
Ｓ２５０９において、統計処理部１６は、Ｒのキー＜ｇ，ｄ＞に対する値にｓを加算して得られる値を、Ｒのキー＜ｇ，ｄ＞に対する値に再設定する。
【０１６７】
Ｓ２５１０において、統計処理部１６は、Ｒにキー＜ｇ，ｄ＞、値ｓでエントリを追加する。
【０１６８】
続いて、繰り返し処理５によって得られた統計処理済Ｋｅｙ−ＶａｌｕｅペアのマップＲについて、以下の繰り返し処理６（Ｓ２５１１及びＳ２５１２）が行われる。
【０１６９】
すなわち、Ｓ２５１１において、統計処理部１６は、Ｒのエントリからキー＜ｋ，ｖ＞を取り出し、ｋをゲートウェイＩＤ、ｖをタイムスタンプとする。
【０１７０】
さらに、Ｓ２５１２において、統計処理部１６は、キー＜ｋ，ｖ＞に対するＲの値を取り出し、合計値とする。これらの値を基に、図２７の内容に従ってテーブルｓｔａｔｉｓｔｉｃ_ｐｏｗにレコードが作成される。
【０１７１】
なお、ここまでに述べた統計処理部での処理は、ＭａｐＲｅｄｕｃｅなどの分散処理アルゴリズムによって実現してもよい。
【０１７２】
＜Ｋｅｙ−ＶａｌｕｅペアリストＭの作成処理＞
図２６は、Ｓ２５０５におけるＫｅｙ−ＶａｌｕｅペアリストＭの作成処理の詳細について説明するためのフローチャートである。
【０１７３】
Ｓ２６０１及びＳ２６０２の処理は、Ｓ２５０３及びＳ２５０４で追加されたレコードリストの全データに対して繰り返し行われる。
【０１７４】
Ｓ２６０１において、統計処理部１６は、レコードのＲＯＷＫＥＹをｇｗＸ＿ｄｅｖＹ＿ｔｉｍｅｓｔａｍｐＺに設定し、ｇｗＸをゲートウェイＩＤに設定し、ｔｉｍｅｓｔａｍｐＺが表す日時から時刻部分を切り捨ててそれを日付に設定する。また、統計処理部１６は、レコードのｅ：ｃｔｔをＢＡＳＥ６４でコードしたバイナリ値から図４Ａのフォーマットに従って最後の６４ビットを取り出し、ｄｏｕｂｌｅ値として解釈したものを測定値として設定する。
【０１７５】
Ｓ２６０２において、統計処理部１６は、Ｋｅｙ−ＶａｌｕｅペアのリストＭに、ＫｅｙとしてゲートウェイＩＤ及び日付を、Ｖａｌｕｅとして測定値を追加する。
【０１７６】
＜テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗの内容＞
図２７は、統計データを格納するテーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗの作成ルール（図２７Ａ）及び当該テーブルの構成例（図２７Ｂ）を示す図である。なお、図２７Ａ及びＢは、図１１及び１３に対応するものである。
【０１７７】
図２７Ａに示されるルールによれば、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗには、項目として、ＲＯＷＫＥＹと、ｃｔｔ及びｃｔｐ（これらはカラムファミリｅに属する項目）と、ｇｗ（これはカラムファミリｋに属する項目）が作成される。図２７Ｂは、このルールに従って作成されたテーブル及びレコード内容の構成を示している。
【０１７８】
つまり、テーブルｓｔａｔｉｓｔｉｃ＿ｐｏｗには、ＲＯＷＫＥＹとしてゲートウェイＩＤ＿タイムスタンプが記述され、ｃｔｔには統計値が記述される。また、ｃｔｐにはコンテントタイプとしてａｐｐｌｉｃａｔｉｏｎ／ｏｃｔｅｔ−ｓｔｒｅａｍが記述される。さらに、ｇｗには対応するゲートウェイＩＤが記述される。
【０１７９】
＜総括＞
本発明によるサーバシステムでは、Ｍ２Ｍサーバが、閲覧用機器からの閲覧リクエストを受け付けると、生データ格納用データベース（データストア）から全てのデバイスの生データを取得し、所定のフォーマット（図４Ｂ）で構成されるビューデータを生成し、閲覧用機器に当該ビューデータを送信する。このように、デバイス単位でデータを取得するのではなく、一括してデバイスの生データをビューデータとして閲覧用機器に取得させるので、データ取得時（閲覧時）の負荷を軽減することが可能となる。
【０１８０】
また、Ｍ２Ｍサーバは、複数のゲートウェイ機器のそれぞれが管理する複数のデバイスのそれぞれと対応付けて（図３のようなツリー構造でデータを管理する）デバイスの生データ及び統計データをデータベース群に格納する。このように、ゲートウェイ機器及びそれが管理する各デバイスと対応付けてデータベース上にデータを格納するので、システムを効率的に運用することができるようになる。
【０１８１】
さらに、統計処理部は、Ｍ２Ｍサーバを介して（Ｍ２Ｍサーバを介さずに直接取得できる態様であっても良い）、所定時間単位（所定サイクル）で生データ格納用データベースから各ゲートウェイ機器が管理する各デバイスの生データを取得する。そして、統計処理部は、取得した生データに対して統計処理を実行して統計データを生成し、Ｍ２Ｍサーバを介して（Ｍ２Ｍを介さない態様もありうる）、統計データを統計データ格納用データベースに格納する。このようにすることにより、時間の経過によって生データが蓄積するにつれて自動的に統計データが生成されるので、システムを効率的に運用することができる。また、リクエストが発行されてから統計データを生成するという態様を採っていないので、システムの負荷を軽減することができる。
【０１８２】
本発明は、実施形態の機能を実現するソフトウェアのプログラムコードによっても実現できる。この場合、プログラムコードを記録した記憶媒体をシステム或は装置に提供し、そのシステム或は装置のコンピュータ（又はＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出す。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそれを記憶した記憶媒体は本発明を構成することになる。このようなプログラムコードを供給するための記憶媒体としては、例えば、フレキシブルディスク、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−Ｒ、磁気テープ、不揮発性のメモリカード、ＲＯＭなどが用いられる。
【０１８３】
また、プログラムコードの指示に基づき、コンピュータ上で稼動しているＯＳ（オペレーティングシステム）などが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。さらに、記憶媒体から読み出されたプログラムコードが、コンピュータ上のメモリに書きこまれた後、そのプログラムコードの指示に基づき、コンピュータのＣＰＵなどが実際の処理の一部又は全部を行い、その処理によって前述した実施の形態の機能が実現されるようにしてもよい。
【０１８４】
さらに、実施の形態の機能を実現するソフトウェアのプログラムコードを、ネットワークを介して配信することにより、それをシステム又は装置のハードディスクやメモリ等の記憶手段又はＣＤ−ＲＷ、ＣＤ−Ｒ等の記憶媒体に格納し、使用時にそのシステム又は装置のコンピュータ（又はＣＰＵやＭＰＵ）が当該記憶手段や当該記憶媒体に格納されたプログラムコードを読み出して実行するようにしても良い。
【０１８５】
最後に、ここで述べたプロセス及び技術は本質的に如何なる特定の装置に関連することはなく、コンポーネントの如何なる相応しい組み合わせによってでも実装できることを理解する必要がある。更に、汎用目的の多様なタイプのデバイスがここで記述した教授に従って使用可能である。ここで述べた方法のステップを実行するのに、専用の装置を構築するのが有益であることが判るかもしれない。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。本発明は、具体例に関連して記述したが、これらは、すべての観点に於いて限定の為ではなく説明の為である。本分野にスキルのある者には、本発明を実施するのに相応しいハードウェア、ソフトウェア、及びファームウエアの多数の組み合わせがあることが解るであろう。例えば、記述したソフトウェアは、アセンブラ、Ｃ／Ｃ＋＋、ｐｅｒｌ、Ｓｈｅｌｌ、ＰＨＰ、Ｊａｖａ（登録商標）等の広範囲のプログラム又はスクリプト言語で実装できる。
【０１８６】
さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。
【０１８７】
加えて、本技術分野の通常の知識を有する者には、本発明のその他の実装がここに開示された本発明の明細書及び実施形態の考察から明らかになる。記述された実施形態の多様な態様及び／又はコンポーネントは、データを管理する機能を有するコンピュータ化ストレージシステムに於いて、単独又は如何なる組み合わせでも使用することが出来る。明細書と具体例は典型的なものに過ぎず、本発明の範囲と精神は後続する請求範囲で示される。
【符号の説明】
【０１８８】
１０・・・サーバシステム
１１・・・デバイス群
１２・・・ゲートウェイ機器
１３・・・Ｍ２Ｍサーバ
１３１・・・リクエスト受信部
１３２・・・リクエスト解析部
１３３・・・データ管理部
１３４・・・論理ツリー管理部
１４・・・データストア（データベース群）
１４１・・・生データ用データベース
１４２・・・統計データ用データベース
１５・・・閲覧用機器
１５１・・・Ｍ２Ｍデータ閲覧アプリケーション
１６・・・統計処理部（統計処理装置）
【図１】
2014146123.tif 000003
【図２】
2014146123.tif 000004
【図３】
2014146123.tif 000005
【図４】
2014146123.tif 000006
【図５】
2014146123.tif 000007
【図６】
2014146123.tif 000008
【図７】
2014146123.tif 000009
【図８】
2014146123.tif 000010
【図９】
2014146123.tif 000011
【図１０】
2014146123.tif 000012
【図１１】
2014146123.tif 000013
【図１２】
2014146123.tif 000014
【図１３】
2014146123.tif 000015
【図１４】
2014146123.tif 000016
【図１５】
2014146123.tif 000017
【図１６】
2014146123.tif 000018
【図１７】
2014146123.tif 000019
【図１８】
2014146123.tif 000020
【図１９】
2014146123.tif 000021
【図２０】
2014146123.tif 000022
【図２１】
2014146123.tif 000023
【図２２】
2014146123.tif 000024
【図２３】
2014146123.tif 000025
【図２４】
2014146123.tif 000026
【図２５】
2014146123.tif 000027
【図２６】
2014146123.tif 000028
【図２７Ａ】
2014146123.tif 000029
【図２７Ｂ】
2014146123.tif 000030