(57)【特許請求の範囲】
【請求項１】
情報更新装置であって、
予め定められた読み取り先から、検索式と対象物同定情報と更新対象表の情報とカラム対応情報を少なくとも含む定義式を読み取る定義式読み取り機能と、
それぞれキー名と値からなる組の複数個の並びを少なくとも含むセンサ情報が登録され、該センサ情報が登録されている検索式に合致した場合に、該合致したセンサ情報を当該検索式の登録元へ送信するセンサ情報ＤＢに対し、前記定義式に含まれる検索式を登録する検索式登録機能と、
前記センサ情報ＤＢから前記センサ情報を受信すると、該センサ情報の中から前記定義式に含まれる対象物同定情報に一致するキー名に対応する値を抽出し、前記定義式に含まれるカラム対応情報に基づいて前記対象物同定情報に一致するキー名を前記定義式に含まれる前記更新対象表におけるカラム名に変換し、前記更新対象表におけるカラム名で識別される対象行を、抽出した値で更新する更新操作をＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に発行する情報更新機能と、
を有する
ことを特徴とする情報更新装置。
【請求項２】
請求項１に記載の情報更新装置であって、
前記定義式は、さらに更新するカラムを限定する更新限定情報を少なくとも含み、
前記情報更新機能は、ＲＤＢＭＳに発行する前記更新操作において、前記更新限定情報に含まれるカラムのみへの更新を指示する
ことを特徴とする情報更新装置。
【請求項３】
請求項１または２に記載の情報更新装置であって、
指定された処理開始時から現在までのセンサ情報を前記センサ情報ＤＢに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をＲＤＢＭＳに発行する巻き戻し機能をさらに有する
ことを特徴とする情報更新装置。
【請求項４】
情報更新方法であって、
予め定められた読み取り先から、検索式と対象物同定情報と更新対象表の情報とカラム対応情報を少なくとも含む定義式を読み取る定義式読み取り手順と、
該定義式読み取り手順の後に、それぞれキー名と値からなる組の複数個の並びを少なくとも含むセンサ情報が登録され、該センサ情報が登録されている検索式に合致した場合に、該合致したセンサ情報を当該検索式の登録元へ送信するセンサ情報ＤＢに対し、前記定義式に含まれる検索式を登録する検索式登録手順と、
該検索式登録手順の後に、前記センサ情報ＤＢから前記センサ情報を受信すると、該センサ情報の中から前記定義式に含まれる対象物同定情報に一致するキー名に対応する値を抽出し、前記定義式に含まれるカラム対応情報に基づいて前記対象物同定情報に一致するキー名を前記定義式に含まれる前記更新対象表におけるカラム名に変換し、前記更新対象表におけるカラム名で識別される対象行を、抽出した値で更新する更新操作をＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に発行する情報更新手順と、
を有することを特徴とする情報更新方法。
【請求項５】
請求項４に記載の情報更新方法であって、
前記定義式は、さらに更新するカラムを限定する更新限定情報を少なくとも含み、
前記情報更新手順では、ＲＤＢＭＳに発行する前記更新操作において、前記更新限定情報に含まれるカラムのみへの更新を指示する
ことを特徴とする情報更新方法。
【請求項６】
請求項４または５に記載の情報更新方法であって、
前記定義式読み取り手順と前記検索式登録手順の間、又は前記検索式登録手順と同時、又は前記検索式登録手順と前記情報更新手順の間に、
指定された処理開始時から現在までのセンサ情報を前記センサ情報ＤＢに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をＲＤＢＭＳに発行する巻き戻し手順をさらに有する
ことを特徴とする情報更新方法。
【請求項７】
請求項４ないし６のいずれか１項に記載の情報更新方法の前記定義式読み取り手順、前記検索式登録手順及び前記情報更新手順、或いは前記定義式読み取り手順、前記検索式登録手順、前記情報更新手順及び前記巻き戻し手順を、
コンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、センサ情報データベースの情報をリレーショナルデータベースに反映させる情報更新装置に関する。
【背景技術】
【０００２】
従来、Ｗｅｂブラウザから用いるアプリケーション（Ｗｅｂアプリケーション）を効率よく開発するための技術として、Ｗｅｂフレームワークと呼ばれる技術があった。このようなＷｅｂフレームワークの例として、Ｒｕｂｙ  ｏｎ  Ｒａｉｌｓがある。Ｒｕｂｙ  ｏｎ  Ｒａｉｌｓは、Ｗｅｂアプリケーション開発の効率を飛躍的に高めた技術として、その評価が高い。Ｗｅｂフレームワークにより、ＲＤＢ（Ｒｅｌａｔｉｏｎａｌ  Ｄａｔａｂａｓｅ）への読み書きを行いつつＷｅｂページを動的に生成するＷｅｂアプリケーションを効率的に開発することが可能である。
【０００３】
一方、多様なセンサやアクチュエータを身の回りに配置して動作させるユビキタスコンピューティング分野においては、センサからの情報を履歴として蓄え後から検索取得する機能を提供する、センサ情報ＤＢが研究されている。このようなセンサ情報ＤＢ（Ｄａｔａｂａｓｅ）の例として、ｕＴｕｐｌｅＳｐａｃｅ（非特許文献１）がある。ｕＴｕｐｌｅＳｐａｃｅにおいては、個々のセンサ情報をＥＡ、検索式をＥＦと呼称している。ｕＴｕｐｌｅＳｐａｃｅの技術的特徴の一つに、ＥＡの履歴を後からＥＦにより検索する機能と、ＥＦを事前に登録しておき新たなＥＡが蓄積されると該ＥＡの新着通知をＥＦ登録元が受け取る機能とを、統合していることが挙げられる。
【０００４】
また、ｕＴｕｐｌｅＳｐａｃｅの技術的特徴の一つに、様々な種類のセンサ情報を一元的に格納して横通しで検索できる、スキーマレスマッチング方式がある。該方式では、個々のセンサ情報を、「キー名＝値，キー名＝値，……」のようなＫｅｙ−Ｖａｌｕｅペアの並びとして表現する。このキー名はデータ登録者が自由に設定することができ、必ずしも各センサ情報で厳密に一律化しなくてよい。検索の際にはこれらのキー名から任意個のキーについて、その値の範囲を検索条件として指定することができる。このため、センサ情報ＤＢとしての汎用性が高いという利点がある。
【０００５】
このような履歴型のセンサ情報ＤＢに対して、該ＤＢへのセンサ情報の読み書きを行いつつＷｅｂページを動的に生成するＷｅｂアプリケーションを開発する際の問題点が、非特許文献２で指摘されている。該文献によると、Ｗｅｂアプリケーションを開発する際には、センサ情報を履歴として検索できるだけでは不十分で、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を提供する必要がある。
【０００６】
このような機能の初歩的な実現方法は、非特許文献２に開示されている。すなわち、「ｕＴｕｐｌｅＳｐａｃｅを待ち受けモードで利用し、独自に別途ＲＤＢ等を用いて最新状態を管理」することにより、このようなプログラムを構成することができる。その実施にあたっては、当該プログラムが取り扱う情報が予め分かっているのであれば、ｕＴｕｐｌｅＳｐａｃｅから待ち受けて取得したＥＡから、その予め分かっている情報を読み取って、予め分かっているＲＤＢテーブルの予め分かっているカラムを更新するＳＱＬ文を発行するプログラムを作成する。また、このようにして構成された該プログラムは、十分高い実行効率で動作する。
【０００７】
非特許文献２では、このように「当該プログラムが取り扱う情報が予め分かって」いない場合に、どのようなＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を提供するセンサ情報ＤＢを提供すれば、該Ｗｅｂアプリケーションが容易に開発できるようになるかが示されている。それによると、下記ＡＰＩ「Ｄｅｆｉｎｉｔｉｏｎ  ３」があれば、当該プログラムが取り扱う情報が予め分かっていない場合でも、スキーマレスマッチング方式によってセンサ情報ＤＢにもたらされる汎用性の高さという利点を保持しつつ、必要となる情報取得機能が充足できることが開示されている。
【０００８】
Ｄｅｆｉｎｉｔｉｏｎ  ３「現時点における個々の対象物の最新状態」を取得する関数Ｎについて、全ｕＴｕｐｌｅ空間をＷとし、検索条件Ａ⊂Ｗ、検索対象Ｒ⊂Ｗ、およびＳを定義域とする対象物同定関数Ｆを与え、蓄積中の全ｕＴｕｐｌｅ集合Ｕ⊂Ｗに対しＳ⊃（Ｒ∩Ｕ）を満たすとき、
Ｎｕ（Ａ，Ｒ，Ｆ）＝｛ｖｉ｝∩Ａ；ｗｈｅｒｅ
∃ｉ∈Ｉ  ｖｉ＝ｎｅｗｅｓｔ（｛ｂ∈Ｒ∩Ｕ｜Ｆ（ｂ）＝ｉ｝）
のように定義する。これにより、対象物の最新状態について理論的定義を与えることができる。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】「大量スキーマレスデータの蓄積・検索を実現する新しいｕＴｕｐｌｅＳｐａｃｅの設計と実装」、柏木啓一郎ほか著、マルチメディア，分散，協調とモバイル（ＤＩＣＯＭＯ２０１０）シンポジウム、２０１０年７月
【非特許文献２】「センサ情報の履歴型蓄積における最新状態」、中村隆幸ほか著、電子情報通信学会ソサイエティ大会、２００９年９月
【発明の概要】
【発明が解決しようとする課題】
【００１０】
非特許文献２  では、アプリケーション開発に必要とされる、高い汎用性を持つＡＰＩは理論的に提案されていたが、その実行効率については触れられていなかった。具体的には、「ｕＴｕｐｌｅＳｐａｃｅを待ち受けモードで利用し、独自に別途ＲＤＢ等を用いて最新状態を管理」することにより構成されたプログラムが有する高い実行効率と、同程度に十分高い実行効率を得つつ該高い汎用性を提供できるようなＡＰＩの実現方式については、触れられていないという問題があった。
【００１１】
該ＡＰＩの実現方式の一つとして、該式をその式の意味どおりにプログラムとして実装することが考えられる。しかしその場合には、すなわち、情報取得操作のたびにセンサ情報ＤＢが保持する全センサ情報を一度走査しなおして、式の条件に合致する結果を得る処理を行うこととなる。そのため、この実現方式の実行効率はきわめて低くとどまってしまうという問題があった。
【００１２】
一方、「ｕＴｕｐｌｅＳｐａｃｅを待ち受けモードで利用し、独自に別途ＲＤＢ等を用いて最新状態を管理」することにより構成されたプログラムを用いることで、上に述べたアプリケーション開発に必要とされる機能を提供する方法が考えられる。しかしこの方法においては、上に述べたように、当該プログラムが取り扱う情報が予め分かっているのでなければ適用できない。従って、別の種類のアプリケーション開発を行う際には、当該プログラムを再度作り直しする必要が生じ、開発効率の著しい低下を招くという問題があった。
【００１３】
本発明の目的は、以上述べた事情に鑑み、履歴型のセンサ情報ＤＢに対して、スキーマレスマッチング方式に適合する高い汎用性を有し、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を提供することにある。
【課題を解決するための手段】
【００１４】
上記目的を達成するために、本願発明の情報更新装置及び情報更新方法は、スキーマレススイッチング方式に適合した履歴型のセンサ情報ＤＢを対象とし、ｕＴｕｐｌｅＳｐａｃｅを待ち受けモードで利用し、別途ＲＤＢを用いることによって各々センサの最新情報を取得する装置において、ＲＤＢにセンサ情報を取得する際の動作を「Ｄｅｆｉｎｉｔｉｏｎ３」の理論式に基づいた定義ファイルによりカスタマイズする。
【００１５】
具体的には、本願発明の情報更新装置は、情報更新装置であって、予め定められた読み取り先から、検索式と対象物同定情報と更新対象表の情報とカラム対応情報を少なくとも含む定義式を読み取る定義式読み取り機能と、それぞれキー名と値からなる組の複数個の並びを少なくとも含むセンサ情報が登録され、該センサ情報が登録されている検索式に合致した場合に、該合致したセンサ情報を当該検索式の登録元へ送信するセンサ情報ＤＢに対し、前記定義式に含まれる検索式を登録する検索式登録機能と、前記センサ情報ＤＢから前記センサ情報を受信すると、該センサ情報の中から前記定義式に含まれる対象物同定情報に一致するキー名に対応する値を抽出し、前記定義式に含まれるカラム対応情報に基づいて前記対象物同定情報に一致するキー名を前記定義式に含まれる前記更新対象表におけるカラム名に変換し、前記更新対象表におけるカラム名で識別される対象行を、抽出した値で更新する更新操作をＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に発行する情報更新機能と、
を有する。
【００１７】
本願発明の情報更新装置では、前記定義式は、さらに更新するカラムを限定する更新限定情報を少なくとも含み、前記情報更新機能は、ＲＤＢＭＳに発行する前記更新操作において、前記更新限定情報に含まれるカラムのみへの更新を指示してもよい。
【００１８】
本願発明の情報更新装置では、指定された処理開始時から現在までのセンサ情報を前記センサ情報ＤＢに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をＲＤＢＭＳに発行する巻き戻し機能をさらに有してもよい。
【００１９】
具体的には、本願発明の情報更新方法は、情報更新方法であって、予め定められた読み取り先から、検索式と対象物同定情報と更新対象表の情報とカラム対応情報を少なくとも含む定義式を読み取る定義式読み取り手順と、該定義式読み取り手順の後に、それぞれキー名と値からなる組の複数個の並びを少なくとも含むセンサ情報が登録され、該センサ情報が登録されている検索式に合致した場合に、該合致したセンサ情報を当該検索式の登録元へ送信するセンサ情報ＤＢに対し、前記定義式に含まれる検索式を登録する検索式登録手順と、該検索式登録手順の後に、前記センサ情報ＤＢから前記センサ情報を受信すると、該センサ情報の中から前記定義式に含まれる対象物同定情報に一致するキー名に対応する値を抽出し、前記定義式に含まれるカラム対応情報に基づいて前記対象物同定情報に一致するキー名を前記定義式に含まれる前記更新対象表におけるカラム名に変換し、前記更新対象表におけるカラム名で識別される対象行を、抽出した値で更新する更新操作をＲＤＢＭＳ（Ｒｅｌａｔｉｏｎａｌ ＤａｔａＢａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）に発行する情報更新手順と、を有する。
【００２１】
本願発明の情報更新方法では、前記定義式は、さらに更新するカラムを限定する更新限定情報を少なくとも含み、前記情報更新手順では、ＲＤＢＭＳに発行する前記更新操作において、前記更新限定情報に含まれるカラムのみへの更新を指示してもよい。
【００２２】
本願発明の情報更新方法では、前記定義式読み取り手順と前記検索式登録手順の間、又は前記検索式登録手順と同時、又は前記検索式登録手順と前記情報更新手順の間に、指定された処理開始時から現在までのセンサ情報を前記センサ情報ＤＢに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をＲＤＢＭＳに発行する巻き戻し手順をさらに有してもよい。
【００２３】
本願発明のプログラムは、本願発明の情報更新方法の前記定義式読み取り手順、前記検索式登録手順及び前記情報更新手順、或いは、前記定義式読み取り手順、前記検索式登録手順、前記情報更新手順及び前記巻き戻し手順を、コンピュータに実行させるためのプログラムである。
【００２４】
なお、上記各発明は、可能な限り組み合わせることができる。
【発明の効果】
【００２５】
本発明によれば、履歴型のセンサ情報ＤＢに対して、スキーマレスマッチング方式に適合する高い汎用性を有し、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を実現することができる。
【図面の簡単な説明】
【００２６】
【図１】本実施の形態におけるシステム全体の構成を示す。
【図２】ｕＴｕｐｌｅＳｐａｃｅ（１０４）に格納されているセンサ情報（２２１）を示す。
【図３】ＲＤＢＭＳ（１０３）が保持するテーブルを示す。
【図４】情報更新装置（１０２）が起動時に読み込む定義ファイル（１０７）を示す。
【図５】情報更新装置（１０２）が起動時に登録する待ち受け検索式を示す。
【図６】センサ（１０６）がｕＴｕｐｌｅＳｐａｃｅ（１０４）に追加登録するセンサ情報（２６１）を示す。
【図７】情報更新装置（１０２）の情報更新処理手順を示す。
【図８】生成されたＳＱＬ文の例（２８１）を示す。
【図９】センサ情報（２６１）に従って情報更新装置（１０２）が情報更新した結果の、ＲＤＢＭＳ（１０３）が保持するテーブルを示す。
【発明を実施するための形態】
【００２７】
添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。
【００２８】
まず、基本的なアイデアについてその概要を述べる。
本発明の基本的なアイデアは、上記「ｕＴｕｐｌｅＳｐａｃｅを待ち受けモードで利用し、独自に別途ＲＤＢ等を用いて最新状態を管理」するプログラムについて、その動作を非特許文献２の該「Ｄｅｆｉｎｉｔｉｏｎ  ３」の理論式に基づいて、定義ファイルによりカスタマイズ可能とすることにある。
【００２９】
一般に、固定的な機能のプログラムの挙動を、定義ファイルによりカスタマイズ可能にすれば、その分だけ汎用性が高まることは当然である。ただし、そのカスタマイズ可能な箇所が場当たり的に設計されたものである限り、汎用性も場当たり的にしか向上せず、スキーマレスマッチング方式が有する高い汎用性に釣り合うものとは到底なり得ない。本発明では、高い汎用性が提唱されている該理論式を、該カスタマイズ可能な箇所を設計する際の基礎とすることにより、高い汎用性を得るものである。
【００３０】
さらに本実施の形態においては、該理論式において理論的ＡＰＩが要求する３つの引数Ａ，Ｒ，Ｆについて、それらすべてをそのまま該プログラムのカスタマイズ可能箇所とするのではなく、該プログラムを含めた上記のＷｅｂアプリケーション全体の構造を踏まえて、３つの引数Ａ，Ｒ，Ｆの機能をちりばめて配置することとする。本実施の形態における具体的な機能配置については以下で示す。これにより、該プログラムのカスタマイズ可能箇所を過剰に増やすことを避けることができ、該プログラムの規模の縮小につながり、該プログラムの開発期間や維持費用等を削減することができる。
【００３１】
さらに本発明では、該プログラムが起動している間に得られたセンサ情報しか処理対象とならず、それ以外の期間の情報はアプリケーションからのセンサ情報取得対象から漏れてしまい、汎用性が損なわれるという問題に対処するため、該プログラムに過去のセンサ情報を巻き戻して処理対象とする機能を具備することとする。これにより、上記対象漏れの問題を回避することが可能となる。
【００３２】
本実施の形態では、以上の基本的な考え方に基づいた装置の構成法を以下に示す。これにより、上記述べた公知の２つの方式を単に組み合わせたものに留まらない、顕著な効果を奏するものである。
【００３３】
第１図は、本実施の形態におけるシステム全体の構成を示す。ネットワーク（１０５）にＷｅｂサーバ装置（１０１）、情報更新装置（１０２）、ＲＤＢＭＳ（１０３）、ｕＴｕｐｌｅＳｐａｃｅ（１０４）、およびセンサ（１０６）が接続される。これらのネットワーク接続された各装置は通信機能を有するが、本実施形態においては当該通信機能の詳細は省略する。
【００３４】
本実施形態に係る情報更新装置（１０２）は、定義式読み取り機能と、検索式登録機能と、情報更新機能と、巻き戻し機能と、を備える。本実施形態に係る情報更新方法は、定義式読み取り手順と、検索式登録手順と、情報更新手順と、を順に有する。
【００３５】
また、情報更新装置（１０２）が読み込む定義ファイル（１０７）を予め定められた読み取り先に配置する。ここで、予め定められた読み取り先は限定しない。予め定められた読み取り先は、例えば、外部からアクセス可能な情報更新装置（１０２）の任意のフォルダであってもよいし、情報更新装置（１０２）からアクセス可能な任意のサーバであってもよいし、レジストリデータベースなどの任意のデータベースであってもよい。本実施形態では定義式が定義ファイル（１０７）である場合について説明するが、予め定められた読み取り先が任意のデータベースの場合は定義式は当該任意のデータベースに格納されている行や値とすることも可能である。
【００３６】
Ｗｅｂサーバ装置（１０１）は、Ｗｅｂブラウザからの要求を受け取り、ＲＤＢＭＳ（１０３）とのデータのやりとりを行いつつ、ＨＴＭＬの生成処理を行って、Ｗｅｂブラウザに返却する。このようなシステムは広く製造されており、例えばＲｕｂｙ  ｏｎ  ＲａｉｌｓのようなＷｅｂフレームワーク技術を用いるなどして、当業者にとって容易に実現できる。
【００３７】
センサ（１０６）は識別子として「Ａ」を持ち、温度と湿度のセンサを具備する。
【００３８】
第２図は、ｕＴｕｐｌｅＳｐａｃｅ（１０４）に格納されているセンサ情報（２２１）を示す。ｕＴｕｐｌｅＳｐａｃｅでの個々のセンサ情報は本図が示すように「キー＝値」からなる組の並びで表され、それが時系列に沿って蓄積される。ｕＴｕｐｌｅＳｐａｃｅの用語では、これら個々のセンサ情報をＥＡと呼ぶ。
【００３９】
図中、例えば２２２の行は、Ａという識別子のセンサ（１０６）からの情報で、検針日時が２０１０年１２月２４日１４時０分、登録日時が２０１０年１２月２４日１４時３分、データタイプはセンサ、メッセージ種類は複合（ハイブリッド）、値１すなわち温度は２１．３度、値２すなわち湿度は６０％であることを示している。検針日時と登録日時に数分のずれがあるのは、無線ネットワーク等を介したサーバへの通信遅延が発生していた様子を示す。
【００４０】
また例えば２２３の行は、Ａという識別子のセンサからの情報で、検針日時が２０１０年１２月２４日１６時１０分、登録日時が２０１０年１２月２４日１６時１３分、データタイプはセンサ、メッセージ種類は温度のみ、値１すなわち温度は２１．８度であることを示している。この例では、１６時台にはセンサ（１０６）の何らかの不調により、１６時０分には温度センサが機能せず湿度の情報のみがまずｕＴｕｐｌｅＳｐａｃｅ（１０４）へと格納され、その１０分後に再計測を行って、今度は温度の情報のみがｕＴｕｐｌｅＳｐａｃｅ（１０４）へと格納された様子を示す。このように温度と湿度が揃って登録されていない場合、例えば温度と湿度の相関を分析するようなアプリケーションにとっては、１６時台のデータは分析には不向きであり無視すべきであることが想定される。
【００４１】
第３図は、ＲＤＢＭＳ（１０３）が保持するテーブルを示す。該ＲＤＢＭＳは表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」（２３１）を保持する。表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」（２３１）は、カラム「ａｄｄｒｅｓｓ」、「ｓｅｎｓｏｒ＿ｄａｔｅ」、「ｔｅｍｐｅｒａｔｕｒｅ」、および「ｈｕｍｉｄｉｔｙ」で示されるデータを格納する。
【００４２】
以下、本システムの動作を順を追って説明する。
まず、システム起動時の動作を示す。システム起動時に、定義式読み取り手順を行う。定義式読み取り手順では、例えば、情報更新装置（１０２）は、定義式読み取り機能を用いて定義ファイル（１０７）を読み込む。
【００４３】
第４図は、情報更新装置（１０２）が起動時に読み込む定義ファイル（１０７）を示す。最初の行「ｑｕｅｒｙ１」は、一続きの定義ブロック（まとまり）を宣言開始することを示す。本実施の形態においては、情報更新装置（１０２）の動作をただ一つだけ、定義ファイル（１０７）によって定義する例を示す。本発明の範囲はこれに限るものではなく、定義ファイル（１０７）内に複数の定義ブロックを列挙することとし、情報更新装置（１０２）は複数の定義ブロックで規定される複数の動作について、それらを同時並行的に行うこととしてもよい。
【００４４】
定義ファイル（１０７）の２行目「ＥＦ：」は、待ち受け検索式を示す。
定義ファイル（１０７）の３行目「ＩＤＥＮＴ：」は、対象物同定情報を示す。
定義ファイル（１０７）の４行目「ＴＡＢＬＥ：」は、更新対象表情報を示す。
定義ファイル（１０７）の５行目「ＣＯＬＭＡＰ：」は、カラム対応情報を示す。
定義ファイル（１０７）の６行目「ＵＰＤＡＴＥ：」は、更新限定情報を示す。
これらの情報の使用方法は、以下に順を追って示す。
【００４５】
第５図は、情報更新装置（１０２）が起動時に登録する待ち受け検索式を示す。システムが起動する際、定義式読み取り手順の後の検索式登録手順において、情報更新装置（１０２）は２５１で示されるＥＦを、待ち受け検索式としてｕＴｕｐｌｅＳｐａｃｅ（１０４）に登録する。ここで（現在日時）の部分には、登録処理を行った時点での日時を数値として埋め込む。またその他の部分は、定義ファイル（１０７）の待ち受け検索式定義に記載された内容を用いる。式２５１は、キー「ｍｓｇ＿ｋｉｎｄ」を含み、かつその値が「ｈｙｂｒｉｄ」であり、かつ、キー「ｔｙｐｅ」を含み、かつその値が「ｓｅｎｓｏｒ」であり、かつ、キー「ｄａｔｅ」を含み、かつその値が「（現在日時）」と同じかそれ以降であるような条件に合致するＥＡを検索することを意味する。ｕＴｕｐｌｅＳｐａｃｅ（１０４）は、ＥＦ（２５１）を受け取ると、以降、待ち受け状態に入る。
【００４６】
次に、新たなセンサ情報が発生した場合の動作を示す。
第６図は、センサ（１０６）がｕＴｕｐｌｅＳｐａｃｅ（１０４）に追加登録するＥＡ（２６１）を示す。この例は、Ａという識別子を持つセンサ（１０６）が、２０１０年１２月２４日１８時０分の検針日時に、データタイプがセンサで、メッセージ種類は複合（ハイブリッド）、値１すなわち温度は２２．２度、値２すなわち湿度は６５％であり、それがサーバに２０１０年１２月２４日１８時３分に登録されたことを示している。センサ情報はＥＡとしてｕＴｕｐｌｅＳｐａｃｅ（１０４）に登録される。
【００４７】
ｕＴｕｐｌｅＳｐａｃｅ（１０４）は内部に保持するセンサ情報の一覧に当該ＥＡを追記するとともに、待ち受けているＥＦの中で条件に合致するものがないかを調べ、合致しているものがあれば、当該ＥＡをＥＦの登録元へと送信する。本例であれば、ＥＡ（２６１）はＥＦ（２５１）に合致しているため、ＥＡ（２６１）が情報更新装置（１０２）へと送信される。
【００４８】
第７図は、情報更新装置（１０２）の情報更新手順を示す。ＥＡ（２６１）をｕＴｕｐｌｅＳｐａｃｅ（１０４）から受け取ると（手順２７１）、まず、該ＥＡの中からセンサを同定する情報を抽出する（手順２７２）。本実施の形態においては、定義ファイル（１０７）の対象物同定情報に「ａｄｄｒｅｓｓ」と記載されているので、ＥＡ（２６１）のキー「ａｄｄｒｅｓｓ」に対応する値「Ａ」を抽出する。
【００４９】
次に、ＥＡ（２６１）のキー名を、ＲＤＢのカラム名へと変換する（手順２７３）。本実施の形態においては、定義ファイル（１０７）のカラム対応情報に「ｔｅｍｐｅｒａｔｕｒｅ＝ｖａｌｕｅ０１，ｈｕｍｉｄｉｔｙ＝ｖａｌｕｅ０２」と記載されているので、キー「ｖａｌｕｅ０１」はカラム名「ｔｅｍｐｅｒａｔｕｒｅ」と読み替え、また、キー「ｖａｌｕｅ０２」はカラム名「ｈｕｍｉｄｉｔｙ」と読み替える。なお、該カラム対応情報に記載されていないキー、ＥＡ（２６１）の例ではａｄｄｒｅｓｓ、ｄａｔｅ、ｍｓｇ＿ｋｉｎｄ、ｓｅｎｓｏｒ＿ｄａｔｅ、およびｔｙｐｅについては、キー名をそのままカラム名として利用する。
【００５０】
次に、ＲＤＢに更新しようとするカラムのデータのみを抽出する（手順２７４）。本実施の形態においては、定義ファイル（１０７）の更新限定情報に「ｓｅｎｓｏｒ＿ｄａｔｅ，ｔｅｍｐｅｒａｔｕｒｅ，ｈｕｍｉｄｉｔｙ」と記載されているので、カラム名「ｓｅｎｓｏｒ＿ｄａｔｅ」とそれに対応する値「２０１０１２２４１８００」、カラム名「ｔｅｍｐｅｒａｔｕｒｅ」とそのカラムの変換前のキー「ｖａｌｕｅ０１」に対応する値「２２．２」、カラム名「ｈｕｍｉｄｉｔｙ」とそのカラムの変換前のキー「ｖａｌｕｅ０２」に対応する値「６５」の３つのデータを抽出する。
【００５１】
次に、データベースの更新操作を行うためのＳＱＬ文を生成する（手順２７５）。本実施の形態においては、定義ファイル（１０７）の更新対象表情報に「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」と記載されているので、更新先のテーブル名はｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓとして、上記対象物同定情報に従った行を更新対象とし、上記抽出されたデータの書き換えを行うＳＱＬ文の生成を行う。
【００５２】
第８図は、生成されたＳＱＬ文の例（２８１）を示す。なお、本例では理解容易性のために日本語（疑似プログラム言語）での説明記述とした。これを本来の英字表記のＳＱＬ文に読み替えることは、当業者にとって容易である。
【００５３】
最後に、該ＳＱＬ文をＲＤＢＭＳ（１０３）に発行することで、データベースの更新操作を行う（手順２７６）。
以上で情報更新手順を終了する。
【００５４】
第９図は、ＥＡ（２６１）に従って情報更新装置（１０２）が情報更新した結果の、ＲＤＢＭＳ（１０３）が保持するテーブルを示す。行２９２が、情報更新されたレコードを示している。
【００５５】
以上述べた手順により更新されたＲＤＢの表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」（２９１）は、Ｗｅｂサーバ装置（１０１）で容易に読み出して、ＷｅｂブラウザへのＨＴＭＬ作成にデータを活用することができる。例えばＲｕｂｙ  ｏｎ  ＲａｉｌｓのようなＷｅｂフレームワーク技術を用いると、ＲＤＢＭＳへのＳＱＬによる問い合わせを容易に記述できるので、Ｗｅｂサーバ装置（１０１）内のプログラムは容易に作成することができる。
【００５６】
なお、情報更新装置（１０２）は上記に加え、起動時のオプション指定により、処理開始時の指定を受け付ける巻き戻し機能を持つ。処理開始時は、処理を開始する時点であり、例えば日時又は時刻である。以下、巻き戻し機能を用いた巻き戻し手順について説明する。
【００５７】
この処理開始時が指定されると、情報更新装置（１０２）は、起動時にｕＴｕｐｌｅＳｐａｃｅ（１０４）に登録するＥＦ（２５１）の「（現在日時）」の部分に、代わりに該指定された処理開始時を埋め込む。これにより、指定された処理開始時から現在までのＥＡをｕＴｕｐｌｅＳｐａｃｅ（１０４）に問い合わせる。ここで、処理開始時は、情報更新装置（１０２）に予め指定されていてもよいし、情報更新装置（１０２）の起動時に取得してもよい。情報更新装置（１０２）の起動時に取得する場合は、例えば、処理開始時を引数として読み込むプログラムを実行する。
【００５８】
ｕＴｕｐｌｅＳｐａｃｅ（１０４）は、ＥＦのｄａｔｅキーとして現在以前の処理開始時が指定されたＥＦを受け取ると、その処理開始時以降現在までのｄａｔｅを持つＥＡであって該ＥＦに合致するＥＡを全て返却した後、新たなＥＡの待ち受けに入るという動作を行う。これにより、情報更新装置（１０２）は、該情報更新装置を起動していなかった間のＥＡについても後から巻き戻して受け取ることができるので、前述の情報更新機能において説明した第７図に示した手順２７１〜手順２７６までの処理手順を該ＥＡにも適用でき、そのような期間のセンサ情報も処理対象とすることが可能となる。
【００５９】
以上で巻き戻し手順を終了する。
なお、巻き戻し手順を実行するタイミングは任意である。例えば、定義式読み取り手順の後に巻き戻し手順を開始し、検索式登録手順の後に巻き戻し手順を終了してもよい。
【００６０】
以上で示した本実施の形態において、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を、スキーマレスマッチング方式に適合する高い汎用性を持ちつつ実現するために、非特許文献２で示されるＡＰＩ「Ｄｅｆｉｎｉｔｉｏｎ  ３」の３つの引数Ａ、Ｒ、およびＦが、どのように配置されているかを以下に示す。
【００６１】
該ＡＰＩの引数のうち、Ｆは対象物同定関数であることが該文献に示されている。上記示したように、本実施の形態において、対象物同定は対象物同定情報すなわち定義ファイル（１０７）内の「ＩＤＥＮＴ：」で示されるキーの値を使ってなされる。つまり、引数Ｆは、相当する情報を定義ファイル（１０７）に記載する。
【００６２】
該ＡＰＩの引数のうち、Ａは検索条件、またＲは検索対象であることが非特許文献２に示されている。この２つの引数は、検索範囲を絞るという意味では類似の機能を有するが、Ｄｅｆｉｎｉｔｉｏｎ  ３の式定義から、Ｒはセンサ情報ＤＢ内の全データに対して、最新状態算出の前処理として検索操作を行うことが読み取れる。
【００６３】
上記示したように、本実施の形態において、最新状態算出の前処理としての検索操作は待ち受け検索式すなわち定義ファイル（１０７）内の「ＥＦ：」で示される検索式の値を使ってなされる。つまり、引数Ｒは、相当する情報を定義ファイル（１０７）に記載する。
【００６４】
該ＡＰＩの引数のうち、Ａは、最新状態算出後に、目的とするデータをふるいにかける検索操作であることがＤｅｆｉｎｉｔｉｏｎ  ３の式定義から読み取れる。上記示したように、本実施の形態において、最新状態算出の結果は直接、ＲＤＢのテーブルの書き換えとして全て反映される。
【００６５】
つまり、最新状態算出後のふるい操作に相当する処理は、そのテーブルを読み出すプログラム部分、すなわち上記例では例えばＷｅｂサーバ装置（１０１）内のプログラムで例えばＲｕｂｙ  ｏｎ  Ｒａｉｌｓを用いてＲＤＢＭＳ（１０３）へのＳＱＬによる問い合わせを行う部分で記述することができる。つまり、引数Ａは、相当する情報をＷｅｂサーバ装置（１０１）内のプログラムとして記述する。
【００６６】
以上示したように、本実施の形態では、非特許文献２で示されるＡＰＩ「Ｄｅｆｉｎｉｔｉｏｎ  ３」に沿いつつ、その３つの引数Ａ、Ｒ、およびＦを定義ファイル（１０７）ならびにＷｅｂサーバ装置（１０１）内のプログラムとしてちりばめて配置する。これにより、情報更新装置（１０２）のカスタマイズ可能箇所を過剰に増やすことを避けることができ、該装置を動作させるプログラムの規模の縮小につながり、該プログラムの開発期間や維持費用等を削減することができる。
【００６７】
参考のために、該ＡＰＩの３つの引数のうち、検索範囲を絞る引数Ａ及びＲが、単一の引数ではなく２つの引数として指定できることによる効果を、具体例を用いて以下に説明する。ここでは、第２図のセンサ情報（２２１）に対して、第６図のＥＡ（２６１）が追加された場合を例として取り上げる。
【００６８】
ここではアプリケーションの仮定として、湿度が４０％〜６０％の範囲にあるセンサの一覧を表示するものとする。この場合、ａｄｄｒｅｓｓ＝Ｃなるセンサは最新の情報でｖａｌｕｅ０２＝４０であるから、条件に適合する。一方、ａｄｄｒｅｓｓ＝Ｂなるセンサは最新の情報でｖａｌｕｅ０２＝３５であるから、条件に適合せず、該アプリケーションの表示対象から外れる。
【００６９】
そしてａｄｄｒｅｓｓ＝Ａなるセンサは、ｍｓｇ＿ｋｉｎｄ＝ｈｕｍｉｏｎｌｙの情報も含めるとすれば、第２図の状態では最新の情報でｖａｌｕｅ０２＝５０であるから、条件に適合する。しかし、ＥＡ（２６１）が追加された段階で、最新の情報でｖａｌｕｅ０２＝６５となるので、条件に適合せず、該アプリケーションの表示対象から外れる。
【００７０】
上記動作を実現しようとした際、まず、検索範囲を絞る引数としてＡが指定できず、Ｒのみ指定可能だったと仮定する。ここで、Ｒの検索条件に、湿度＝４０％〜６０％を意味するキーワードを含めたとする。
【００７１】
既に説明したように、該条件がＥＦとしてｕＴｕｐｌｅＳｐａｃｅ（１０４）に登録される。すると、ＥＡ（２６１）が追加される前の段階では、ＲＤＢＭＳ（１０３）の表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」には、上記例ではｍｓｇ＿ｋｉｎｄ＝ｈｕｍｉｏｎｌｙも含める前提での議論であるため、ａｄｄｒｅｓｓ＝Ａの行のｈｕｍｉｄｉｔｙは５０が最新の値として保持されているはずである。
【００７２】
このとき、ＥＡ（２６１）がセンサ（１０６）より登録されたとする。該ＥＡは、湿度が６５％という値を持つため、該ＥＦには合致しないので、情報更新装置（１０２）に送信されることがない。このため情報更新装置（１０２）は、ＲＤＢＭＳ（１０３）の表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」を書き換えることができず、該表のａｄｄｒｅｓｓ＝Ａの行は古い情報のまま維持されることとなる。
【００７３】
従って、該アプリケーションが情報表示のためにＲＤＢＭＳ（１０３）の表「ｃｕｒｒｅｎｔ＿ｓｅｎｓｏｒｓ」を読み出した際、古い情報のまま読み出されるため、あたかも該センサは未だ湿度が５０％であるかのような誤った情報が表示されてしまうこととなる。以上述べたように、検索範囲を絞る引数としてＡが指定できず、Ｒのみ指定可能だったと仮定すると、アプリケーションで必要となる機能を実現できない。
【００７４】
一方、上記動作を実現しようとした際、検索範囲を絞る引数としてＲが指定できず、Ａのみ指定可能だったと仮定する。この場合、Ｒが指定できないとは、情報更新装置（１０２）が登録するＥＦに対して条件を絞る記載ができないということを意味しているので、ｕＴｕｐｌｅＳｐａｃｅ（１０４）に登録されたあらゆるＥＡが全て情報更新装置（１０２）へと送信されることとなる。ｕＴｕｐｌｅＳｐａｃｅ（１０４）には、本アプリケーションで着目するセンサの情報のみならず、多様なセンサを接続し情報を蓄積していくため、それら多様なセンサの情報を全て情報更新装置（１０２）が受け取ることとなり、処理負荷が膨大なものとなる。
【００７５】
これらの場合とは異なり、本実施の形態においては、検索範囲を絞る引数としてＡとＲをそれぞれ別に指定可能であるため、上記述べた問題が解決でき、アプリケーションで必要となる機能を実現しつつ処理負荷を低減できるという効果が得られる。
【００７６】
なお、本実施の形態では、センサ情報ＤＢとしてｕＴｕｐｌｅＳｐａｃｅを用いることとした。本発明の範囲はこれに限定されるものではなく、情報の履歴を蓄積しておき後で取得する機能を提供するその他のストレージ装置あるいはＤＢ装置を用いて該センサ情報ＤＢを構成してもよい。
【００７７】
また、本実施の形態における情報更新装置の各機能は、センサ情報ＤＢがｕＴｕｐｌｅＳｐａｃｅである場合についての一例であり、本実施の形態の機能に限定されるものではない。すなわち、本発明の情報更新装置は、センサ情報ＤＢの仕様に応じて各機能を実行する。例えば、巻き戻し機能のセンサ情報の問い合わせの説明において、検索式登録機能で用いたＥＦの現在日時を処理開始時に書き換えたが、これに限定されない。蓄積されているセンサ情報を問い合わせるＡＰＩと、未来のセンサ情報の通知の受け取りを依頼するＡＰＩとを別途個別に提供するセンサ情報ＤＢであれば、巻き戻し機能において検索式登録機能とは異なるＡＰＩを用いる。この場合、この２つのＡＰＩを順次または同時に呼び出し、巻き戻し手順において過去のセンサ情報を問い合わせる手順を行い、当該手順と同時又は当該手順の後に、未来のセンサ情報を受け取るための検索式登録手順を行ってもよい。
【００７８】
また、本発明のいうセンサ情報とは、センサデバイスが計測した値に限るものではなく、上記センサ情報ＤＢが扱う情報であればよい。特に、センサの特性や状態を示すメタデータや、あるいはセンサ以外の例えばＷｅｂやインターネットを経由して取得した情報であってもよい。
【００７９】
また、本実施の形態では、ＷｅｂブラウザからアクセスされるＷｅｂサーバ機能の実現例を示した。本発明の範囲はこれに限定されるものではなく、上記センサ情報を読み書きするアプリケーションの開発に広汎に適用できる。
【００８０】
本発明の情報更新装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。
【産業上の利用可能性】
【００８１】
本発明は、情報通信産業に利用することができる。
【符号の説明】
【００８２】
１０１：Ｗｅｂサーバ装置
１０２：情報更新装置
１０３：ＲＤＢＭＳ
１０４：ｕＴｕｐｌｅＳｐａｃｅ
１０５：ネットワーク
１０６：センサ
１０７：定義ファイル
【図１】
0005554731.tif 000002
【図２】
0005554731.tif 000003
【図３】
0005554731.tif 000004
【図４】
0005554731.tif 000005
【図５】
0005554731.tif 000006
【図６】
0005554731.tif 000007
【図７】
0005554731.tif 000008
【図８】
0005554731.tif 000009
【図９】
0005554731.tif 000010