"情報更新装置であって、予め定められた読み取り先から定義式を読み取る定義式読み取り機能を有し、該定義式には検索式と対象物同定情報と更新対象表情報とを少なくとも含み、さらに該情報更新装置は、該検索式をセンサ情報DBへ登録する検索式登録機能と、該更新対象表に対して該対象物同定情報で識別される対象行の更新操作をRDBMSRelationalDataBaseManagementSystemに発行する情報更新機能と、を有することを特徴とする情報更新装置。請求項1に記載の情報更新装置であって、該センサ情報DBが扱うそれぞれのセンサ情報はキーと値からなる組の複数個の並びを少なくとも含み、該定義式にはさらに該キー名とRDBにおけるカラム名との対応を示すカラム対応情報を少なくとも含み、該情報更新機能はRDBMSに発行する該更新操作において該カラム対応情報に含まれる対応関係に基づいて該キー名を該カラム名に変換することを特徴とする情報更新装置。請求項1ないし2に記載の情報更新装置であって、該定義式にはさらに更新するカラムを限定する更新限定情報を少なくとも含み、該情報更新機能はRDBMSに発行する情報更新操作に対して該更新限定情報に含まれるカラムのみへの更新を該更新操作において指示することを特徴とする情報更新装置。請求項1ないし3のいずれかに記載の情報更新装置であって、該情報更新装置はさらに巻き戻し機能を有し、該巻き戻し機能は、指定された処理開始時から現在までのセンサ情報をセンサ情報DBに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をRDBMSに発行する、ことを特徴とする情報更新装置。情報更新方法であって、予め定められた読み取り先から定義式を読み取る定義式読み取り手順を有し、該定義式には検索式と対象物同定情報と更新対象表情報とを少なくとも含み、該定義式読み取り手順の後に、該検索式をセンサ情報DBへ登録する検索式登録手順と、該検索式登録手順の後に、該更新対象表に対して該対象物同定情報で識別される対象行の更新操作をRDBMSに発行する情報更新手順と、を有することを特徴とする情報更新方法。請求項5に記載の情報更新方法であって、該センサ情報DBが扱うそれぞれのセンサ情報はキーと値からなる組の複数個の並びを少なくとも含み、該定義式にはさらに該キー名とRDBにおけるカラム名との対応を示すカラム対応情報を少なくとも含み、該情報更新手順において、RDBMSに発行する該更新操作において該カラム対応情報に含まれる対応関係に基づいて該キー名を該カラム名に変換することを特徴とする情報更新方法。請求項5ないし6に記載の情報更新方法であって、該定義式にはさらに更新するカラムを限定する更新限定情報を少なくとも含み、該情報更新手順において、RDBMSに発行する情報更新操作に対して該更新限定情報に含まれるカラムのみへの更新を該更新操作において指示することを特徴とする情報更新方法。請求項5ないし7のいずれかに記載の情報更新方法であって、前記定義式読み取り手順と前記検索式登録手順の間、前記検索式登録手順と同時、又は前記検索式登録手順と前記情報更新手順の間に、さらに巻き戻し手順を有し、該巻き戻し手順において、指定された処理開始時から現在までのセンサ情報をセンサ情報DBに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をRDBMSに発行する、ことを特徴とする情報更新方法。請求項5ないし8のいずれかに記載の情報更新方法の前記定義式読み取り手順、前記検索式登録手順及び前記情報更新手順、或いは前記定義式読み取り手順、前記検索式登録手順、前記情報更新手順及び前記巻き戻し手順を、コンピュータに実行させるためのプログラム。非特許文献2では、アプリケーション開発に必要とされる、高い汎用性を持つAPIは理論的に提案されていたが、その実行効率については触れられていなかった。具体的には、uTupleSpaceを待ち受けモードで利用し、独自に別途RDB等を用いて最新状態を管理することにより構成されたプログラムが有する高い実行効率と、同程度に十分高い実行効率を得つつ該高い汎用性を提供できるようなAPIの実現方式については、触れられていないという問題があった。該APIの実現方式の一つとして、該式をその式の意味どおりにプログラムとして実装することが考えられる。しかしその場合には、すなわち、情報取得操作のたびにセンサ情報DBが保持する全センサ情報を一度走査しなおして、式の条件に合致する結果を得る処理を行うこととなる。そのため、この実現方式の実行効率はきわめて低くとどまってしまうという問題があった。一方、uTupleSpaceを待ち受けモードで利用し、独自に別途RDB等を用いて最新状態を管理することにより構成されたプログラムを用いることで、上に述べたアプリケーション開発に必要とされる機能を提供する方法が考えられる。しかしこの方法においては、上に述べたように、当該プログラムが取り扱う情報が予め分かっているのでなければ適用できない。従って、別の種類のアプリケーション開発を行う際には、当該プログラムを再度作り直しする必要が生じ、開発効率の著しい低下を招くという問題があった。本発明の目的は、以上述べた事情に鑑み、履歴型のセンサ情報DBに対して、スキーマレスマッチング方式に適合する高い汎用性を有し、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を提供することにある。上記目的を達成するために、本願発明の情報更新装置及び情報更新方法は、スキーマレススイッチング方式に適合した履歴型のセンサ情報DBを対象とし、uTupleSpaceを待ち受けモードで利用し、別途RDBを用いることによって各々センサの最新情報を取得する装置において、RDBにセンサ情報を取得する際の動作をDefinition3の理論式に基づいた定義ファイルによりカスタマイズする。具体的には、本願発明の情報更新装置は、予め定められた読み取り先から定義式を読み取る定義式読み取り機能を有し、該定義式には検索式と対象物同定情報と更新対象表情報とを少なくとも含み、さらに該情報更新装置は、該検索式をセンサ情報DBへ登録する検索式登録機能と、該更新対象表に対して該対象物同定情報で識別される対象行の更新操作をRDBMSRelationalDataBaseManagementSystemに発行する情報更新機能と、を有する。本願発明の情報更新装置では、該センサ情報DBが扱うそれぞれのセンサ情報はキーと値からなる組の複数個の並びを少なくとも含み、該定義式にはさらに該キー名とRDBにおけるカラム名との対応を示すカラム対応情報を少なくとも含み、該情報更新機能はRDBMSに発行する該更新操作において該カラム対応情報に含まれる対応関係に基づいて該キー名を該カラム名に変換してもよい。本願発明の情報更新装置では、該定義式にはさらに更新するカラムを限定する更新限定情報を少なくとも含み、該情報更新機能はRDBMSに発行する情報更新操作に対して該更新限定情報に含まれるカラムのみへの更新を該更新操作において指示してもよい。本願発明の情報更新装置では、該情報更新装置はさらに巻き戻し機能を有し、該巻き戻し機能は、指定された処理開始時から現在までのセンサ情報をセンサ情報DBに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をRDBMSに発行してもよい。具体的には、本願発明の情報更新方法は、予め定められた読み取り先から定義式を読み取る定義式読み取り手順を有し、該定義式には検索式と対象物同定情報と更新対象表情報とを少なくとも含み、該定義式読み取り手順の後に、該検索式をセンサ情報DBへ登録する検索式登録手順と、該検索式登録手順の後に、該更新対象表に対して該対象物同定情報で識別される対象行の更新操作をRDBMSに発行する情報更新手順と、を有する。本願発明の情報更新方法では、該センサ情報DBが扱うそれぞれのセンサ情報はキーと値からなる組の複数個の並びを少なくとも含み、該定義式にはさらに該キー名とRDBにおけるカラム名との対応を示すカラム対応情報を少なくとも含み、該情報更新手順において、RDBMSに発行する該更新操作において該カラム対応情報に含まれる対応関係に基づいて該キー名を該カラム名に変換してもよい。本願発明の情報更新方法では、該定義式にはさらに更新するカラムを限定する更新限定情報を少なくとも含み、該情報更新手順にいて、RDBMSに発行する情報更新操作に対して該更新限定情報に含まれるカラムのみへの更新を該更新操作において指示してもよい。本願発明の情報更新方法では、さらに巻き戻し手順を有し、該巻き戻し手順において、指定された処理開始時から現在までのセンサ情報をセンサ情報DBに問い合わせ、該問い合わせの結果得られたセンサ情報について、前記更新対象表に対して前記対象物同定情報で識別される対象行の更新操作をRDBMSに発行してもよい。ここで、巻き戻し手順は、前記定義式読み取り手順と前記検索式登録手順の間、前記検索式登録手順と同時、又は前記検索式登録手順と前記情報更新手順の間に、実行する。本願発明のプログラムは、本願発明の情報更新方法の前記定義式読み取り手順、前記検索式登録手順及び前記情報更新手順、或いは、前記定義式読み取り手順、前記検索式登録手順、前記情報更新手順及び前記巻き戻し手順を、コンピュータに実行させるためのプログラムである。なお、上記各発明は、可能な限り組み合わせることができる。本発明によれば、履歴型のセンサ情報DBに対して、スキーマレスマッチング方式に適合する高い汎用性を有し、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を実現することができる。添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施の例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。まず、基本的なアイデアについてその概要を述べる。本発明の基本的なアイデアは、上記uTupleSpaceを待ち受けモードで利用し、独自に別途RDB等を用いて最新状態を管理するプログラムについて、その動作を非特許文献2の該Definition3の理論式に基づいて、定義ファイルによりカスタマイズ可能とすることにある。一般に、固定的な機能のプログラムの挙動を、定義ファイルによりカスタマイズ可能にすれば、その分だけ汎用性が高まることは当然である。ただし、そのカスタマイズ可能な箇所が場当たり的に設計されたものである限り、汎用性も場当たり的にしか向上せず、スキーマレスマッチング方式が有する高い汎用性に釣り合うものとは到底なり得ない。本発明では、高い汎用性が提唱されている該理論式を、該カスタマイズ可能な箇所を設計する際の基礎とすることにより、高い汎用性を得るものである。さらに本実施の形態においては、該理論式において理論的APIが要求する3つの引数A,R,Fについて、それらすべてをそのまま該プログラムのカスタマイズ可能箇所とするのではなく、該プログラムを含めた上記のWebアプリケーション全体の構造を踏まえて、3つの引数A,R,Fの機能をちりばめて配置することとする。本実施の形態における具体的な機能配置については以下で示す。これにより、該プログラムのカスタマイズ可能箇所を過剰に増やすことを避けることができ、該プログラムの規模の縮小につながり、該プログラムの開発期間や維持費用等を削減することができる。さらに本発明では、該プログラムが起動している間に得られたセンサ情報しか処理対象とならず、それ以外の期間の情報はアプリケーションからのセンサ情報取得対象から漏れてしまい、汎用性が損なわれるという問題に対処するため、該プログラムに過去のセンサ情報を巻き戻して処理対象とする機能を具備することとする。これにより、上記対象漏れの問題を回避することが可能となる。本実施の形態では、以上の基本的な考え方に基づいた装置の構成法を以下に示す。これにより、上記述べた公知の2つの方式を単に組み合わせたものに留まらない、顕著な効果を奏するものである。第1図は、本実施の形態におけるシステム全体の構成を示す。ネットワーク105にWebサーバ装置101、情報更新装置102、RDBMS103、uTupleSpace104、およびセンサ106が接続される。これらのネットワーク接続された各装置は通信機能を有するが、本実施形態においては当該通信機能の詳細は省略する。本実施形態に係る情報更新装置102は、定義式読み取り機能と、検索式登録機能と、情報更新機能と、巻き戻し機能と、を備える。本実施形態に係る情報更新方法は、定義式読み取り手順と、検索式登録手順と、情報更新手順と、を順に有する。また、情報更新装置102が読み込む定義ファイル107を予め定められた読み取り先に配置する。ここで、予め定められた読み取り先は限定しない。予め定められた読み取り先は、例えば、外部からアクセス可能な情報更新装置102の任意のフォルダであってもよいし、情報更新装置102からアクセス可能な任意のサーバであってもよいし、レジストリデータベースなどの任意のデータベースであってもよい。本実施形態では定義式が定義ファイル107である場合について説明するが、予め定められた読み取り先が任意のデータベースの場合は定義式は当該任意のデータベースに格納されている行や値とすることも可能である。Webサーバ装置101は、Webブラウザからの要求を受け取り、RDBMS103とのデータのやりとりを行いつつ、HTMLの生成処理を行って、Webブラウザに返却する。このようなシステムは広く製造されており、例えばRubyonRailsのようなWebフレームワーク技術を用いるなどして、当業者にとって容易に実現できる。センサ106は識別子としてAを持ち、温度と湿度のセンサを具備する。第2図は、uTupleSpace104に格納されているセンサ情報221を示す。uTupleSpaceでの個々のセンサ情報は本図が示すようにキー=値からなる組の並びで表され、それが時系列に沿って蓄積される。uTupleSpaceの用語では、これら個々のセンサ情報をEAと呼ぶ。図中、例えば222の行は、Aという識別子のセンサ106からの情報で、検針日時が2010年12月24日14時0分、登録日時が2010年12月24日14時3分、データタイプはセンサ、メッセージ種類は複合ハイブリッド、値1すなわち温度は21.3度、値2すなわち湿度は60であることを示している。検針日時と登録日時に数分のずれがあるのは、無線ネットワーク等を介したサーバへの通信遅延が発生していた様子を示す。また例えば223の行は、Aという識別子のセンサからの情報で、検針日時が2010年12月24日16時10分、登録日時が2010年12月24日16時13分、データタイプはセンサ、メッセージ種類は温度のみ、値1すなわち温度は21.8度であることを示している。この例では、16時台にはセンサ106の何らかの不調により、16時0分には温度センサが機能せず湿度の情報のみがまずuTupleSpace104へと格納され、その10分後に再計測を行って、今度は温度の情報のみがuTupleSpace104へと格納された様子を示す。このように温度と湿度が揃って登録されていない場合、例えば温度と湿度の相関を分析するようなアプリケーションにとっては、16時台のデータは分析には不向きであり無視すべきであることが想定される。第3図は、RDBMS103が保持するテーブルを示す。該RDBMSは表current_sensors231を保持する。表current_sensors231は、カラムaddress、sensor_date、temperature、およびhumidityで示されるデータを格納する。以下、本システムの動作を順を追って説明する。まず、システム起動時の動作を示す。システム起動時に、定義式読み取り手順を行う。定義式読み取り手順では、例えば、情報更新装置102は、定義式読み取り機能を用いて定義ファイル107を読み込む。第4図は、情報更新装置102が起動時に読み込む定義ファイル107を示す。最初の行query1は、一続きの定義ブロックまとまりを宣言開始することを示す。本実施の形態においては、情報更新装置102の動作をただ一つだけ、定義ファイル107によって定義する例を示す。本発明の範囲はこれに限るものではなく、定義ファイル107内に複数の定義ブロックを列挙することとし、情報更新装置102は複数の定義ブロックで規定される複数の動作について、それらを同時並行的に行うこととしてもよい。定義ファイル107の2行目EF:は、待ち受け検索式を示す。定義ファイル107の3行目IDENT:は、対象物同定情報を示す。定義ファイル107の4行目TABLE:は、更新対象表情報を示す。定義ファイル107の5行目COLMAP:は、カラム対応情報を示す。定義ファイル107の6行目UPDATE:は、更新限定情報を示す。これらの情報の使用方法は、以下に順を追って示す。第5図は、情報更新装置102が起動時に登録する待ち受け検索式を示す。システムが起動する際、定義式読み取り手順の後の検索式登録手順において、情報更新装置102は251で示されるEFを、待ち受け検索式としてuTupleSpace104に登録する。ここで現在日時の部分には、登録処理を行った時点での日時を数値として埋め込む。またその他の部分は、定義ファイル107の待ち受け検索式定義に記載された内容を用いる。式251は、キーmsg_kindを含み、かつその値がhybridであり、かつ、キーtypeを含み、かつその値がsensorであり、かつ、キーdateを含み、かつその値が現在日時と同じかそれ以降であるような条件に合致するEAを検索することを意味する。uTupleSpace104は、EF251を受け取ると、以降、待ち受け状態に入る。次に、新たなセンサ情報が発生した場合の動作を示す。第6図は、センサ106がuTupleSpace104に追加登録するEA261を示す。この例は、Aという識別子を持つセンサ106が、2010年12月24日18時0分の検針日時に、データタイプがセンサで、メッセージ種類は複合ハイブリッド、値1すなわち温度は22.2度、値2すなわち湿度は65であり、それがサーバに2010年12月24日18時3分に登録されたことを示している。センサ情報はEAとしてuTupleSpace104に登録される。uTupleSpace104は内部に保持するセンサ情報の一覧に当該EAを追記するとともに、待ち受けているEFの中で条件に合致するものがないかを調べ、合致しているものがあれば、当該EAをEFの登録元へと送信する。本例であれば、EA261はEF251に合致しているため、EA261が情報更新装置102へと送信される。第7図は、情報更新装置102の情報更新手順を示す。EA261をuTupleSpace104から受け取ると手順271、まず、該EAの中からセンサを同定する情報を抽出する手順272。本実施の形態においては、定義ファイル107の対象物同定情報にaddressと記載されているので、EA261のキーaddressに対応する値Aを抽出する。次に、EA261のキー名を、RDBのカラム名へと変換する手順273。本実施の形態においては、定義ファイル107のカラム対応情報にtemperature=value01,humidity=value02と記載されているので、キーvalue01はカラム名temperatureと読み替え、また、キーvalue02はカラム名humidityと読み替える。なお、該カラム対応情報に記載されていないキー、EA261の例ではaddress、date、msg_kind、sensor_date、およびtypeについては、キー名をそのままカラム名として利用する。次に、RDBに更新しようとするカラムのデータのみを抽出する手順274。本実施の形態においては、定義ファイル107の更新限定情報にsensor_date,temperature,humidityと記載されているので、カラム名sensor_dateとそれに対応する値201012241800、カラム名temperatureとそのカラムの変換前のキーvalue01に対応する値22.2、カラム名humidityとそのカラムの変換前のキーvalue02に対応する値65の3つのデータを抽出する。次に、データベースの更新操作を行うためのSQL文を生成する手順275。本実施の形態においては、定義ファイル107の更新対象表情報にcurrent_sensorsと記載されているので、更新先のテーブル名はcurrent_sensorsとして、上記対象物同定情報に従った行を更新対象とし、上記抽出されたデータの書き換えを行うSQL文の生成を行う。第8図は、生成されたSQL文の例281を示す。なお、本例では理解容易性のために日本語疑似プログラム言語での説明記述とした。これを本来の英字表記のSQL文に読み替えることは、当業者にとって容易である。最後に、該SQL文をRDBMS103に発行することで、データベースの更新操作を行う手順276。以上で情報更新手順を終了する。第9図は、EA261に従って情報更新装置102が情報更新した結果の、RDBMS103が保持するテーブルを示す。行292が、情報更新されたレコードを示している。以上述べた手順により更新されたRDBの表current_sensors291は、Webサーバ装置101で容易に読み出して、WebブラウザへのHTML作成にデータを活用することができる。例えばRubyonRailsのようなWebフレームワーク技術を用いると、RDBMSへのSQLによる問い合わせを容易に記述できるので、Webサーバ装置101内のプログラムは容易に作成することができる。なお、情報更新装置102は上記に加え、起動時のオプション指定により、処理開始時の指定を受け付ける巻き戻し機能を持つ。処理開始時は、処理を開始する時点であり、例えば日時又は時刻である。以下、巻き戻し機能を用いた巻き戻し手順について説明する。この処理開始時が指定されると、情報更新装置102は、起動時にuTupleSpace104に登録するEF251の現在日時の部分に、代わりに該指定された処理開始時を埋め込む。これにより、指定された処理開始時から現在までのEAをuTupleSpace104に問い合わせる。ここで、処理開始時は、情報更新装置102に予め指定されていてもよいし、情報更新装置102の起動時に取得してもよい。情報更新装置102の起動時に取得する場合は、例えば、処理開始時を引数として読み込むプログラムを実行する。uTupleSpace104は、EFのdateキーとして現在以前の処理開始時が指定されたEFを受け取ると、その処理開始時以降現在までのdateを持つEAであって該EFに合致するEAを全て返却した後、新たなEAの待ち受けに入るという動作を行う。これにより、情報更新装置102は、該情報更新装置を起動していなかった間のEAについても後から巻き戻して受け取ることができるので、前述の情報更新機能において説明した第7図に示した手順271~手順276までの処理手順を該EAにも適用でき、そのような期間のセンサ情報も処理対象とすることが可能となる。以上で巻き戻し手順を終了する。なお、巻き戻し手順を実行するタイミングは任意である。例えば、定義式読み取り手順の後に巻き戻し手順を開始し、検索式登録手順の後に巻き戻し手順を終了してもよい。以上で示した本実施の形態において、各センサ個体に対してそのセンサからの最新状態を効率よく取得できる機能を、スキーマレスマッチング方式に適合する高い汎用性を持ちつつ実現するために、非特許文献2で示されるAPIDefinition3の3つの引数A、R、およびFが、どのように配置されているかを以下に示す。該APIの引数のうち、Fは対象物同定関数であることが該文献に示されている。上記示したように、本実施の形態において、対象物同定は対象物同定情報すなわち定義ファイル107内のIDENT:で示されるキーの値を使ってなされる。つまり、引数Fは、相当する情報を定義ファイル107に記載する。該APIの引数のうち、Aは検索条件、またRは検索対象であることが非特許文献2に示されている。この2つの引数は、検索範囲を絞るという意味では類似の機能を有するが、Definition3の式定義から、Rはセンサ情報DB内の全データに対して、最新状態算出の前処理として検索操作を行うことが読み取れる。上記示したように、本実施の形態において、最新状態算出の前処理としての検索操作は待ち受け検索式すなわち定義ファイル107内のEF:で示される検索式の値を使ってなされる。つまり、引数Rは、相当する情報を定義ファイル107に記載する。該APIの引数のうち、Aは、最新状態算出後に、目的とするデータをふるいにかける検索操作であることがDefinition3の式定義から読み取れる。上記示したように、本実施の形態において、最新状態算出の結果は直接、RDBのテーブルの書き換えとして全て反映される。つまり、最新状態算出後のふるい操作に相当する処理は、そのテーブルを読み出すプログラム部分、すなわち上記例では例えばWebサーバ装置101内のプログラムで例えばRubyonRailsを用いてRDBMS103へのSQLによる問い合わせを行う部分で記述することができる。つまり、引数Aは、相当する情報をWebサーバ装置101内のプログラムとして記述する。以上示したように、本実施の形態では、非特許文献2で示されるAPIDefinition3に沿いつつ、その3つの引数A、R、およびFを定義ファイル107ならびにWebサーバ装置101内のプログラムとしてちりばめて配置する。これにより、情報更新装置102のカスタマイズ可能箇所を過剰に増やすことを避けることができ、該装置を動作させるプログラムの規模の縮小につながり、該プログラムの開発期間や維持費用等を削減することができる。参考のために、該APIの3つの引数のうち、検索範囲を絞る引数A及びRが、単一の引数ではなく2つの引数として指定できることによる効果を、具体例を用いて以下に説明する。ここでは、第2図のセンサ情報221に対して、第6図のEA261が追加された場合を例として取り上げる。ここではアプリケーションの仮定として、湿度が40~60の範囲にあるセンサの一覧を表示するものとする。この場合、address=Cなるセンサは最新の情報でvalue02=40であるから、条件に適合する。一方、address=Bなるセンサは最新の情報でvalue02=35であるから、条件に適合せず、該アプリケーションの表示対象から外れる。そしてaddress=Aなるセンサは、msg_kind=humionlyの情報も含めるとすれば、第2図の状態では最新の情報でvalue02=50であるから、条件に適合する。しかし、EA261が追加された段階で、最新の情報でvalue02=65となるので、条件に適合せず、該アプリケーションの表示対象から外れる。上記動作を実現しようとした際、まず、検索範囲を絞る引数としてAが指定できず、Rのみ指定可能だったと仮定する。ここで、Rの検索条件に、湿度=40~60を意味するキーワードを含めたとする。既に説明したように、該条件がEFとしてuTupleSpace104に登録される。すると、EA261が追加される前の段階では、RDBMS103の表current_sensorsには、上記例ではmsg_kind=humionlyも含める前提での議論であるため、address=Aの行のhumidityは50が最新の値として保持されているはずである。このとき、EA261がセンサ106より登録されたとする。該EAは、湿度が65という値を持つため、該EFには合致しないので、情報更新装置102に送信されることがない。このため情報更新装置102は、RDBMS103の表current_sensorsを書き換えることができず、該表のaddress=Aの行は古い情報のまま維持されることとなる。従って、該アプリケーションが情報表示のためにRDBMS103の表current_sensorsを読み出した際、古い情報のまま読み出されるため、あたかも該センサは未だ湿度が50であるかのような誤った情報が表示されてしまうこととなる。以上述べたように、検索範囲を絞る引数としてAが指定できず、Rのみ指定可能だったと仮定すると、アプリケーションで必要となる機能を実現できない。一方、上記動作を実現しようとした際、検索範囲を絞る引数としてRが指定できず、Aのみ指定可能だったと仮定する。この場合、Rが指定できないとは、情報更新装置102が登録するEFに対して条件を絞る記載ができないということを意味しているので、uTupleSpace104に登録されたあらゆるEAが全て情報更新装置102へと送信されることとなる。uTupleSpace104には、本アプリケーションで着目するセンサの情報のみならず、多様なセンサを接続し情報を蓄積していくため、それら多様なセンサの情報を全て情報更新装置102が受け取ることとなり、処理負荷が膨大なものとなる。これらの場合とは異なり、本実施の形態においては、検索範囲を絞る引数としてAとRをそれぞれ別に指定可能であるため、上記述べた問題が解決でき、アプリケーションで必要となる機能を実現しつつ処理負荷を低減できるという効果が得られる。なお、本実施の形態では、センサ情報DBとしてuTupleSpaceを用いることとした。本発明の範囲はこれに限定されるものではなく、情報の履歴を蓄積しておき後で取得する機能を提供するその他のストレージ装置あるいはDB装置を用いて該センサ情報DBを構成してもよい。また、本実施の形態における情報更新装置の各機能は、センサ情報DBがuTupleSpaceである場合についての一例であり、本実施の形態の機能に限定されるものではない。すなわち、本発明の情報更新装置は、センサ情報DBの仕様に応じて各機能を実行する。例えば、巻き戻し機能のセンサ情報の問い合わせの説明において、検索式登録機能で用いたEFの現在日時を処理開始時に書き換えたが、これに限定されない。蓄積されているセンサ情報を問い合わせるAPIと、未来のセンサ情報の通知の受け取りを依頼するAPIとを別途個別に提供するセンサ情報DBであれば、巻き戻し機能において検索式登録機能とは異なるAPIを用いる。この場合、この2つのAPIを順次または同時に呼び出し、巻き戻し手順において過去のセンサ情報を問い合わせる手順を行い、当該手順と同時又は当該手順の後に、未来のセンサ情報を受け取るための検索式登録手順を行ってもよい。また、本発明のいうセンサ情報とは、センサデバイスが計測した値に限るものではなく、上記センサ情報DBが扱う情報であればよい。特に、センサの特性や状態を示すメタデータや、あるいはセンサ以外の例えばWebやインターネットを経由して取得した情報であってもよい。また、本実施の形態では、WebブラウザからアクセスされるWebサーバ機能の実現例を示した。本発明の範囲はこれに限定されるものではなく、上記センサ情報を読み書きするアプリケーションの開発に広汎に適用できる。本発明の情報更新装置は、コンピュータとプログラムによっても実現でき、プログラムを記録媒体に記録することも、ネットワークを通して提供することも可能である。"