JP5948399B2 - 情報記録装置、方法およびプログラム - Google Patents

Description

この発明は、例えばセンサ情報を記録するために使用される情報記録装置、方法およびプログラムに関する。

従来、センサの計測データのような情報すなわちセンサ情報を扱う情報管理システムとして、uTupleSpace（非特許文献１および特許文献１）が知られている。uTupleSpaceの特徴の一つに、センサ情報をuTuple形式という、「キー＝値」の並びにより自由に表現できる点がある。データ値だけでなく検索式もuTuple形式で表現することができ、両者の間で検索が成立するか否かを判定するマッチング規則についても上記文献にて開示されている。なお、uTupleSpaceの用語では、データ値を示すuTupleをEvent Actual（ＥＡ）と呼び、また検索式を表すuTupleをEvent Formal （ＥＦ）と呼ぶ。

また、uTupleSpaceの他の特徴として、通常のデータベース管理システムのようなデータ値蓄積型の検索処理だけでなく、検索式待ち受け型の検索処理もサポートし、これらを区別なく扱える点がある。データ値蓄積型の検索処理は、計測されたデータ値を先に蓄積しておき、後から検索式を投入することで、マッチするデータ値を検索して検索式の投入元に返却する。一方、検索式待ち受け型の検索処理は、検索式を先に蓄積しておき、後からデータ値を登録することで、マッチするデータ値を検索式の蓄積元に即時に返却する。

この「区別なく扱える」という趣旨は、データ値蓄積型の検索処理と検索式待ち受け型の検索処理の両方を、単一のApplication Programming Interface（ＡＰＩ）で実行できるということだけにとどまらない。それに加え、一回の当該単一のＡＰＩの実行により、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを併せて実行できるという特徴的機能も含んでいる。例えば、検索式の中に「時刻が１０秒前のデータ値から１０秒後のデータ値を対象とする」という意味の情報を含めて、当該ＡＰＩを呼んだとする。この場合、時刻が１０秒前から０秒前、すなわち現在までの蓄積済みデータを対象としてデータ値蓄積型の検索処理を行い、さらに引き続いて時刻が０秒後すなわち現在から１０秒後までのデータを対象に１０秒間の検索式待ち受け状態に入り、現在から１０秒後までに新たに登録されたデータ値について、マッチしたデータ値をＡＰＩ呼び出し元に返却する動作を行う。

このように、両者の動きを単一のＡＰＩで区別なく扱えることにより、センサ情報を扱う情報管理システムでは実用上の利点がある。例えば、これら検索動作を行っているのと同時に、新たなセンサ値が次々と計測されデータベースに登録されている状況を想定する。もし、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とが区別なく扱えなかった場合には、アプリケーションはこれらの処理を順次呼び出す必要が生じるため、ちょうどこれらの処理の隙間にあたる時間に登録された新たな計測結果のデータ値は、アプリケーションが取りこぼしてしまうという問題が発生する。しかし、前記従来の技術によれば、両者が区別なく扱えるため、上記示したようなデータの取りこぼし問題を回避できるという利点が得られる。

また特許文献２には、上記データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱うための効率的な装置の構成が記載されている。特許文献２に記載された技術によれば、装置はデータ値を蓄積するデータ値用木構造と、検索式を蓄積する検索式用木構造を有する。これらの木構造は、木構造アルゴリズムを用いて索引を作成し、大量データを効率的に蓄積し検索することが可能である。これらの木構造を用いて、当該装置は、データ値の蓄積の際にデータ値用木構造に書き込みかつ検索式用木構造へ検索を行うとともに、検索式の蓄積の際に検索式用木構造に書き込みかつデータ値用木構造へ検索を行う。このようにすることで、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱うという特徴的機能を効率的に実現できる。

さらに特許文献３には、スマートフォンに代表される小型の携帯型装置で用いるため、比較的小さな計算量および使用メモリによって、センサ情報などのデータをチャンクを生成しつつ順次蓄積し、検索を行う情報記録方法および情報記録装置が記載されている。特許文献１および２に記載された技術は、主にネットワークサーバやクラウドで用い、大量のデータ値を蓄積し検索することを主眼とした技術であった。一方、特許文献３では、比較的少量のデータ値を対象とし、木構造を用いずデータ値を蓄積し、効率的に扱えるようにする手法が示されている。特に、マルチスレッド動作の際に、他のスレッドの動作を阻害することなく動作できる手法となっていることが特徴であり、計測情報が次々と到着するセンサ情報を扱う情報管理システムにおいては重要なポイントといえる。

また特許文献３では、アプリケーションに検索結果を返却する際に、アプリケーションから指定されたコールバック関数に対して複数回に分けて呼び出しを行うことにより、使用メモリを抑えつつ検索結果のデータ値を受け渡す方法が示されている。小型の携帯型装置では使用メモリの低減は重要であるため、アプリケーションから使いやすい形でコールバック関数を活用できるようにすることは重要なポイントといえる。

特開２０１２−００３４９０号公報 特開２０１３−２１８４９０号公報 特開２０１４−１６４３８２号公報

"Design and Implementation of New uTupleSpace Enabling Storage and Retrieval of Large Amount of Schema-less Sensor Data"、Takayuki Nakamura, Keiichiro Kashiwagi, Yutaka Arakawa, Motonori Nakamura、Second International Workshop on Enablers for Ubiquitous and Context-Aware Services on Sensor Networks (EUCASS 2011)、2011年7月

ところが特許文献３には、主にデータ値蓄積型の検索処理については詳細に記載されているが、検索式待ち受け型の検索処理や、この検索式待ち受け型の検索処理とデータ値蓄積型の検索処理を区別なく扱う手法については特段言及されていなかった。

また、特許文献３に記載された手法を基にデータ値蓄積型の検索処理を実現し、さらに、特許文献２に記載された手法を参考にして検索式待ち受け型の検索処理を実現しようとした場合、以下に述べるいくつかの課題を解決する必要があった。

解決すべき課題の一つ目は、アプリケーションから使いやすい形で、検索結果をコールバック関数で返却できるようにすることである。使いやすさを担保するためには、呼び出しの逐次性と、検索終了コールバックの確実性が重要となる。

呼び出しの逐次性とは、検索結果を複数回に分けてアプリケーションに返却する際に、アプリケーションが提示したコールバック関数を呼び出し、その関数からリターンするまで、次のコールバック関数が呼ばれないことを保証することである。この保証すべきコールバックには、検索結果のコールバックと、次に示す検索終了コールバックを含む。これにより、システム全体としてマルチスレッド動作している場合であっても、アプリケーションからは同時に１スレッドのみがコールバックで動作することになる。このため、単一スレッドでの呼び出しが行われているように扱うことができ、アプリケーションの記述を容易化することができる。従って、この呼び出しの逐次性を確保することが、解決すべき課題の一つ目のポイントであった。

また、検索終了コールバックの確実性とは、検索結果を複数回に分けてアプリケーションに返却した後、検索が完了したことをコールバックで１回だけアプリケーションに通知する動作を保証することである。これが０回あるいは２回以上であってはならず、また検索終了コールバックの後に検索結果のコールバックが行われてはならない。これにより、アプリケーションはコールバックされた検索結果を中間集計するために一時的なデータ構造を確保し、かつ当該データ構造を解放する契機として検索終了コールバックを用いることができるため、メモリリークやメモリ二重解放や浮きメモリ参照等のバグの回避が容易になる。従って、この検索終了コールバックの確実性を確保することも、解決すべき課題の一つ目のポイントであった。

解決すべき課題の二つ目は、検索式の削除操作を提供することである。検索式待ち受け型の検索処理を行っている際に、例えば検索の必要性がなくなった等の理由により、検索式を削除する操作をアプリケーションから行いたいという要望がある。その際、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱うには、データ値蓄積型の検索処理を行っている最中であっても、検索式の削除操作を行えるようにする必要がある。また、削除された検索式についても、例えばアプリケーションに対してデータ構造を解放する契機を与えるためには、検索終了コールバックを行う必要があり、その際に検索終了コールバックの確実性を確保する必要がある。

この発明は上記事情に着目してなされたもので、その目的とするところは、比較的少ない計算量およびメモリ容量により、データに対してデータ値蓄積型の検索処理と検索式待ち受け型の検索処理を区別なく扱えるようにすると共に、コールバックを逐次に行い検索終了コールバックを確実に行えるようにし、さらに検索式の削除操作を行えるようにする情報記録装置、方法およびプログラムを提供することにある。

この発明は上述した課題を解決するためになされたもので、以下にその概要を述べる。
すなわち、この発明の一様態による情報記録装置は、特許文献２と類似する手法を用いて、データ値を保持するデータ値用リポジトリと検索式を保持する検索式用リポジトリとを使用し、データ値の蓄積の際にデータ値用リポジトリに書き込みかつ検索式用リポジトリへ検索を行うと共に、検索式の蓄積の際に検索式用リポジトリに書き込みかつデータ値用リポジトリへ検索を行うことで、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱うという基本的手法を採用する。

さらに、この発明の一様態による情報記録装置は、データ値蓄積型の検索処理の処理中リスト情報を有し、データ値の蓄積の際および検索式の削除の際に、排他制御を行いつつ当該リストの操作を行うことで、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱いつつ検索式の削除を可能にする。

また、この発明の一様態による情報記録装置は、検索結果を通知し、検索式の時間経過に応じて検索終了を通知し、検索式の削除に応じて検索終了を通知し、さらに０回以上の検索結果の通知の後に１回の検索終了の通知を実行する制御手段を有することで、検索式の時間経過に応じて起動された検索終了あるいは検索式の削除に応じて起動された検索終了が、検索結果の通知と時間的に重ならずただ１回だけ行われることを保証可能にする。

さらに、この発明の一様態による情報記録装置は、データ値ならびに検索式としてuTuple形式を用いることによって、待ち受け検索の処理を高速にでき、スマートフォン等への適用を想定して比較的小さな計算量および使用メモリで動作することを可能にする。

より具体的には、以下のような態様とする。
すなわち、第１の態様は、データ値群を記録する情報記録装置において、データ値を保持するデータ値用リポジトリ、検索式を保持する検索式用リポジトリおよび蓄積検索処理中リスト情報を記憶する記憶部と、前記データ値を登録するためのデータ値登録処理手段、前記検索式を登録するための検索式登録処理手段、および前記検索式を削除するための検索式削除処理手段を備える処理部とを具備する。
そして、前記データ値登録処理手段により、前記データ値用リポジトリにデータ値を書き込む処理と、前記データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理と、前記検索式待ち受け型検索処理による検索結果を通知する処理を実行する。
また、前記検索式登録処理手段により、前記蓄積検索処理中リスト情報に、処理中の検索式を追加する処理と、前記検索式をもとに前記データ値用リポジトリからデータ値の集合を検索するデータ値蓄積型検索処理と、前記検索式群に関し排他制御を行う処理と、前記排他制御が行われている状態で、前記蓄積検索処理中リスト情報から該当する検索式を削除すると共に、前記データ値蓄積型検索処理から前記検索式待ち受け型検索処理への移行の可否を判定する処理と、前記移行が可能と判定された場合に、前記検索式用リポジトリに前記検索式を書き込む処理と、前記データ値蓄積型検索処理による検索結果を通知する処理を実行する。
さらに、前記検索式削除処理手段により、前記検索式群に関し排他制御を行う処理と、前記排他制御が行われている状態で、前記蓄積検索処理中リスト情報から削除対象の検索式を削除する処理と、前記検索式用リポジトリから削除対象の検索式を検索して、当該検索式を削除する処理と、前記削除対象とした検索式の削除に応じて検索が終了したことを通知する処理を実行するようにしたものである。

この発明の第２の態様は、データ値群を記録する情報記録装置において、検索式を保持する検索式用リポジトリを記憶する記憶部と、データ値を登録するためのデータ値登録処理手段、検索式を登録するための検索式登録処理手段、および時間経過に応じて処理を起動する計時手段を有する処理部とを具備する。
そして、前記データ値登録処理手段により、データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理と、前記検索式待ち受け型検索処理による検索式の検索結果を通知する処理を実行する。
また、前記検索式登録処理手段により、前記検索式用リポジトリに検索式を書き込む処理を実行する。
さらに、前記計時手段により、前記検索式用リポジトリから検索終了時刻が経過した検索式を検索して当該検索式を削除する処理と、前記検索終了時刻が経過した検索式に対する検索終了を通知する第１の検索終了通知処理とを実行する。
また、前記第１の検索終了通知処理では、０回以上の検索結果の通知の後に、１回の前記検索式に対する検索終了の通知を実行するようにしたものである。

この発明の第３の態様は、前記記憶部に、データ値を保持するデータ値用リポジトリをさらに設け、前記処理部には、検索式を削除する検索式削除処理手段をさらに設ける。そして、前記データ値登録処理手段により、前記データ値用リポジトリにデータ値を書き込む処理をさらに実行し、前記検索式登録処理手段により、前記検索式をもとに前記データ値用リポジトリからデータ値の集合を検索するデータ値蓄積型検索処理を実行する処理と、前記データ値蓄積型検索処理による検索結果を通知する処理をさらに実行し、前記検索式削除処理手段により、前記検索式用リポジトリから削除対象に合致する検索式を検索して当該検索式を削除する処理と、前記削除対象とした検索式の削除に応じて検索が終了したことを通知する第２の検索終了通知処理を実行するようにしたものである。

この発明の第４の態様は、前記第１及び第２の検索終了通知手段の少なくとも一方において、検索結果の通知中の処理の有無を保持する処理と、検索終了の通知済みの有無を保持する処理と、前記保持されている検索結果の通知中の処理の有無と前記保持されている検索終了の通知済みの有無に応じて通知中の処理の完了を待ち合わせる処理を実行するようにしたものである。

この発明の第５の態様は、前記情報記録装置が取り扱うデータ値および検索式として、キーと値との組あるいはキーと値範囲との組の並びを含むようにしたものである。

この発明の各態様によれば、比較的小さな計算量および使用メモリによって、データ値蓄積型の検索処理と検索式待ち受け型の検索処理を区別なく扱うことができる。また、データ値蓄積型の検索処理と検索式待ち受け型の検索処理とを区別なく扱いつつ検索式の削除操作を行うことができる。さらに、検索式の時間経過あるいは検索式の削除に応じて起動された検索終了が、検索結果の通知と時間的に重ならずただ１回だけ行われることを保証することができる。

すなわちこの発明によれば、比較的少ない計算量およびメモリ容量により、データに対してデータ値蓄積型の検索処理と検索式待ち受け型の検索処理を区別なく扱うことができ、かつコールバックを逐次に行い検索終了コールバックを確実に行うことができ、さらに検索式の削除操作を行うことができる情報記録装置、方法およびプログラムを提供することができる。

この発明の一実施形態に係る情報記録装置の機能構成を示すブロック図。 図１に示した装置で使用されるＥＡ用リポジトリの内容の一例を示す図。 図１に示した装置で使用されるＥＦ用リポジトリの内容の一例を示す図。 図１に示した装置で使用される蓄積検索処理中リストの内容の一例を示す図。 図１に示した装置によるＥＡ登録処理の手順と処理内容を示すフローチャート。 図１に示した装置によるＥＦ登録処理の手順と処理内容を示すフローチャート。 図１に示した装置によるＥＦ退役処理の手順と処理内容を示すフローチャート。 図１に示した装置によるＥＦ削除処理の手順と処理内容を示すフローチャート。 図５および図６に示したコールバックラッパーを用いた検索結果の返却処理の手順と処理内容を示すフローチャート。 図７及び図８に示したコールバックラッパーを用いた検索終了の返却処理の手順と処理内容を示すフローチャート。 新たに登録ＥＡの一例を示す図。 新たに登録ＥＦの一例を示す図。 検索式の削除条件の一例を示す図。

以下、図面を参照してこの発明に係わる実施形態を説明する。
［一実施形態］
（構成）
図１は、この発明の一実施形態に係る情報記録装置の機能構成を示すブロック図である。
情報記録装置は１００は、例えばスマートフォンやタブレット型端末等の携帯端末からなり、本実施形態に係るハードウェアとして、図示しないプロセッサ、メモリ、通信や入出力のための各種インタフェースおよびタッチパネル／ディスプレス１０５に加え、温度センサ１０３と、加速度センサ１０４を備えている。また情報記録装置は、本実施形態に係るソフトウェアとして、ライブラリ１０１と、アプリケーション１０２を備えている。ライブラリ１０１およびアプリケーション１０２は、いずれも上記メモリに格納されたプログラムを上記プロセッサに実行させることにより動作する。

ライブラリ１０１は、ＥＡ登録部１２１と、ＥＦ登録部１２２と、ＥＦ削除部１２３と、計時部１２４と、ＥＡ用リポジトリ１３１と、ＥＦ用リポジトリ１３２と、蓄積検索処理中リスト１３３とを有する。さらにライブラリ１０１は、上記ＥＦ用リポジトリ１３２および蓄積検索処理中リスト１３３に関するマルチスレッド動作を保護するためにＥＦ用ロック１３４を有している。上記ＥＦ削除部１２３は、待ち受け検索中断処理リスト１３５を持ち、また計時部１２４も待ち受け検索中断処理リスト１３６を持っている。

温度センサ１０３および加速度センサ１０４は、それぞれ温度の計測データおよび３軸加速度の計測データを出力するもので、大分類を“smphone”と呼称し、小分類をそれぞれ“temperature”および“accel”と呼称する。

上記情報記録装置１００は、例えば以下のように構築される。すなわち、先ずライブラリ１０１のプログラムは予め作成しておく。次に、アプリケーション１０２のプログラムを作成し、上記作成したライブラリ１０１のプログラムと共にコンパイルして、スマートフォン用の実行ファイルを生成する。そして、当該実行ファイルを、記録媒体あるいは通信回線を通じてスマートフォン用アプリとしてインストールする。この構築手法は、スマートフォン用のアプリケーション開発において一般的に行われているものである。

ちなみに、データベースの管理システムは、通常、サーバを別途準備するなどの大規模な構成とすることが多い。しかし、スマートフォン等携帯端末への適用を想定し、比較的少ない計算量およびメモリ容量で動作するデータベースの管理システムとしては、本実施形態のような構成を採用することが適切である。

図２はＥＡ用リポジトリ１３１の内容の一例を示すものである。ＥＡ用リポジトリ１３１は、ＥＡ、つまりデータ値の集合を保持する。本実施形態では、データ値はuTuple形式で表記する。すなわち、それぞれのデータ値は「キー＝値」の任意個数の並びにより構成されるデータ形式によって記述することとする。ここでは、行２０１〜行２０３からなる３個のデータ値が例示されている。例えば、行２０１のデータは、日時（date）が“2014年10月01日02時36分18秒”で、かつ大分類（subject）が“smphone”、小分類（type）が“temperature”、観測値（value）が“3.7（度）”であることを示す一つの観測データ値を表している。なお、簡単のため、以下では時刻表記に“2014-10-01 02:36:18”のような記載も用いることとする。

また同様に、例えば行２０２のデータは、日時が“2014-10-01 02:37:10”、大分類が“smphone”、小分類が“accel”、観測値（x, y, z）がそれぞれ（0.52, 0.23, 9.78）であることを示す一つの観測データ値を表している。

図３はＥＦ用リポジトリ１３２の内容の一例を示す。ＥＦ用リポジトリ１３２は、ＥＦ、つまり検索式の集合を保持する。本実施形態では、検索式はuTuple形式で表記する。ここに保持されているＥＦは、データ値蓄積型の検索処理が完了し、引き続いて検索式待ち受け型の検索処理に移行した結果として、現在待ち受け状態となっている検索式である。ここでは、行２１１〜行２１３からなる３つの検索式が待ち受け状態となっている様子を例示している。カラム２１５は待ち受け状態となっている検索式の内容を表し、カラム２１６は当該検索式に対応するコールバックラッパーのオブジェクトの中身を表す。

コールバックラッパーとは、０回以上の検索結果の通知の後に１回の検索終了の通知を実行する制御を行うためのオブジェクトであり、以下に詳細な実施方法を例示する。すなわち、コールバックラッパーは４つの値を保持している。これらの値は、左から順にコールバック関数、検索結果の通知中の処理を数えるためのカウンタ、検索終了通知済みフラグ、通知中の処理の完了を待ち合わせるための状態変数を表す。なお、状態変数とは一般的にマルチスレッドプログラミングにおいて状態変数あるいは condition variable として知られる機能であり、例えばC++言語においてはboostライブラリのconditionクラス、あるいはpthreadライブラリのcondition_variable機能を用いて容易に実現できる。

状態変数によって提供される基本的機能を用いれば、複数のスレッドあるいはタスクが当該状態変数を用いて待ち合わせを行うことができ、さらに別のスレッドあるいはタスクから、当該待ち合わせているスレッドあるいはタスクの中の１つを起動して再度走行状態とすることができる。

例えば、行２１１の検索式は、待ち受け状態になっている検索式が時刻（date）の範囲が“2014-10-01 00:00:00”から“2014-10-01 02:40:00”に含まれ、かつ大分類（subject）が“smphone”、小分類(type)が“temperature”、valueが“−10.0から10.0”という条件を全て満たすデータを検索するための検索式である。またこの検索式は、検索結果をアプリケーション１０２に返却する際に関数func1を呼び出し、現在func1の呼び出し中の数は“０”であり、現在func1に対して検索終了はまだ呼び出されておらず、もし当該呼び出しに対して待ち合わせを行う場合には状態変数cv1を用いるという内容も表している。さらに、行２１１に示される検索式による待ち受け中の検索は、時刻（date）の終値に“2014-10-01 02:40:00”と記載されているので、この検索は当該時刻になった時点で検索終了となる趣旨を表している。

なお検索式には、例えば行２１２に示すように値の範囲として「＋∞」と記述することができる。さらに、例えば行２１２にキー「x」やキー「y」が記載されていないように、検索条件の絞り込みに用いるキーのみを記述することもできる。

図４は、蓄積検索処理中リスト１３３の中身を示すものである。蓄積検索処理中リスト１３３は、ＥＦ、つまり検索式の集合を保持する。ここに保持されているＥＦは、データ値蓄積型の検索処理が完了しておらず現在処理中となっている検索式である。従って、ここに保持されているＥＦは、以下に述べる詳細手順に従って本実施形態に係る情報記録装置１００が動作することにより、現在処理中であるデータ値蓄積型の検索処理が完了した後は、引き続いて検索式待ち受け型の検索処理に移行し、ＥＦ用リポジトリ１３２に登録されることが予期されている。

この例では、蓄積検索処理中リスト１３３の中身は行２２１で示される検索式が１つだけ登録されている状態である。もし複数のデータ値蓄積型の検索処理が同時に処理中となっている場合には、本リストも複数の検索式が登録されている状態になりうる。

（動作）
次に、以上のように構成された装置の動作を説明する。
（１）ＥＡ登録処理
図５はＥＡ登録処理の手順と処理内容を示すフローチャートである。
アプリケーション１０２がライブラリ１０１のＥＡ登録関数を呼び出すと、ライブラリ１０１のＥＡ登録部１２１は以下のようにＥＡ登録処理を実行する。なお、上記呼び出し際にアプリケーション１０２は、データ値を引数としてＥＡ登録部１２１に渡す。

すなわち、ＥＡ登録関数が呼び出されるとＥＡ登録部１０２は、先ずステップＳ３０１において当該データ値をＥＡ用リポジトリ１３１に追加する。次にＥＡ登録部１２１は、ステップＳ３０２によりＥＦ用ロック１３４を確保したのち、ステップＳ３０３により当該データ値によりＥＦ用リポジトリ１３２を検索し、ステップＳ３０４でＥＦ用ロック１３４を解放する。ここで、「データ値によりＥＦ用リポジトリ１３２を検索する」とは、データ値とＥＦ用リポジトリ１３２が保持する各々の検索式とのマッチングを行い、合致する検索式の集合を得ることを意味する。この得られた検索式の集合は、上記データ値の登録によってヒットした待ち受け中の検索式に相当する。

本実施形態では、データ値および検索式はいずれもuTuple形式で表記するが、これらuTuple間のマッチング規則については、特許文献１あるいは特許文献２に詳しく記載されている。具体的には、検索式に含まれる各々のキーに対して、当該キーがデータ値にも含まれており、かつ当該キーに対応する検索式における値範囲と当該キーに対応するデータ値における値（または値範囲）との積集合が空集合ではないという判定基準が、検索式に含まれる全てのキーに対して成立するとき、データ値と検索式とが合致すると判定する。

このように、データ値ならびに検索式としてuTuple形式を用いることによって、データ値および検索式のマッチング処理を高速に行うことができ、これにより待ち受け検索の処理を軽量化できるという利点が得られる。このため、スマートフォン等のように、比較的少ない計算量およびメモリ容量で動作するデータベースの管理システムに適用すると、特に顕著な相乗効果を得ることができる。

上記ステップＳ３０３では、検索式と対応するコールバックラッパーとの組の並びが得られる。このため、ＥＡ登録部１２１は、ステップＳ３０５により各々のコールバックラッパーのカウンタを１増やした後、ステップＳ３０６により各々のコールバックラッパーを用いて該データ値を待ち受け検索における検索結果として返却する。なお、ステップＳ３０６における検束結果の返却処理は、後に詳しく説明する。
最後にＥＡ登録部１２１は、ライブラリの呼び出し元にリターンし、一連の処理を完了する。

（２）ＥＦ登録処理
図６はＥＦ登録処理の手順と処理内容を示すフローチャートである。
アプリケーション１０２がライブラリ１０１のＥＦ登録関数を呼び出すと、ライブラリ１０１のＥＦ登録部１２２は以下のようにＥＦ登録処理を開始する。なお、呼び出しに際し、アプリケーション１０１は検索式とコールバック関数を引数としてＥＦ登録部１２２に渡す。コールバック関数は、例えばC++言語であれば関数ポインタとして実現できる。

すなわち、コールバック関数が呼び出されるとＥＦ登録部１２２は、先ずステップＳ３５１において、上記アプリケーション１０１から渡された検索式を蓄積検索処理中リスト１３３に登録する。次にステップＳ３５２により、上記検索式によりＥＡ用リポジトリ１３１を検索する。この検索により得られたデータ値の集合は、データ値蓄積型の検索処理における検索結果に相当する。

次にＥＦ登録部１２２は、ステップＳ３５３によりＥＦ用ロック１３４を確保する。続いてＥＦ登録部１２２は、ステップＳ３５４により、蓄積検索処理中リスト１３３に対して、上記ステップＳ３５１において登録した検索式を削除する。ただし、このとき、既に該検索式が蓄積検索処理中リスト１３３に存在しなければ、該検索式の削除が既に要求されていたと判断する。そしてＥＦ登録部１２２は、該検索式の削除が既に要求されていた場合には、ステップＳ３５５によりデータ値蓄積型の検索処理から検索式待ち受け型の検索処理への移行が阻害されているか否かを判定する。そして、この判定の結果、移行が阻害されていれば、ステップＳ３５６によりＥＦ用ロック１３４を解放した後、ステップＳ３５７により上記コールバック関数に検索終了のコールバックを行う。

一方、データ値蓄積型の検索処理から検索式待ち受け型の検索処理への移行が阻害されていなかったとする。この場合ＥＦ登録部１２２は、ステップＳ３６０によりＥＦ用ロック１３４を解放した後、ステップＳ３６１においてコールバックラッパーのオブジェクトを作成する。このときコールバックラッパーには、上記コールバック関数と、値１のカウンタと、値“no”の検索終了通知済みフラグと、新たに確保した状態変数を含める。次にＥＦ登録部１２２は、ステップＳ３６２により上記検索式とコールバックラッパーをＥＦリポジトリ１３２に登録する。そして、ステップＳ３６３において、当該コールバックラッパーを用いて、上記ステップＳ３５２により得られた検索結果を返却する。なお、このステップＳ３６３による検索結果の返却手順は、後に詳しく述べる。
最後にＥＦ登録部１２２は、ライブラリの呼び出し元にリターンし、一連の処理を完了する。

（３）ＥＦ退役処理
図７はＥＦ退役処理の手順と処理内容を示すフローチャートである。
ＥＦ退役処理とは、待ち受け中の検索が時刻の終値になったために検索終了となるときの処理を指し示す。計時部１２４は、ＥＦ用リポジトリ１３２内の各検索式について、時刻の終値になると以下のようにＥＦ退役処理を実行する。例えば、図３に示したＥＦ用リポジトリ１３２を例にとると、行２１１で示される待ち受け中の検索は、時刻の終値に“2014-10-01 02:40:00”と記載されているので、計時部１２４は当該時刻になった時点でＥＦ退役処理を開始する。

すなわち、計時部１２４は先ずステップＳ３８１により、ＥＦ用ロック１３４を確保する。続いて計時部１２４は、ステップＳ３８２において、ＥＦ用リポジトリ１３２から時刻の終値が現在時刻と同値または現在時刻を過ぎているものを検索する。そして、対象となる行をＥＦ用リポジトリ１３２から削除し、当該行に記載されていたコールバックラッパーを計時部１２４内の待ち受け検索中断処理リスト１３６に登録する。登録が終了すると計時部１２４は、ステップＳ３８３により各コールバックラッパーのカウンタの値を“１”増やした後、ステップＳ３８４によりＥＦ用ロック１３４を解放する。

次に計時部１２４は、ステップＳ３８５において、待ち受け検索中断処理リスト１３６の各々のコールバックラッパーに対して、当該コールバックラッパーを用いて検索終了を返却する。なおステップＳ３８５による検索終了の返却処理は、後に詳しく述べる。

最後に計時部１２４は、ステップＳ３８６において待ち受け検索中断処理リスト１３６の内容を破棄する。特に、その中に含まれるコールバックラッパーも破棄する。そして、ＥＦ退役に係る一連の処理を終了する。

（４）ＥＦ削除処理
図８はＥＦ削除処理の手順と処理内容を示すフローチャートである。
アプリケーション１０２がライブラリ１０１のＥＦ削除関数を呼び出すと、ライブラリ１０１のＥＦ削除部１２３は以下のようにＥＦ削除処理を実行する。なお、呼び出しに際しアプリケーション１０２は、削除条件を表す検索式を引数としてＥＦ削除部１２３に渡す。

すなわち、ＥＦ削除関数が呼び出されるとＥＦ削除部１２３は、先ずステップＳ４０１によりＥＦ用ロック１３４を確保する。続いてＥＦ削除部１２３は、ステップＳ４０２において、上記削除条件を表す検索式により蓄積検索処理中リスト１３３を検索し、対象となる行を蓄積検索処理中リスト１３３から削除する。その際、本実施形態では、上記削除条件を表す検索式をＥＦと見なし、かつ蓄積検索処理中リスト１３３中の検索式をＥＡと見なして、既に示したＥＡとＥＦとのマッチング規則を適用することにより、検索が合致するか否かの判定を行うこととする。

次にＥＦ削除部１２３は、ステップＳ４０３において、上記削除条件を表す検索式によりＥＦ用リポジトリ１３１３２を検索し、削除対象となる行をＥＦ用リポジトリ１３２から削除する。そして、当該行に記載されていたコールバックラッパーをＥＦ削除部１２３内の待ち受け検索中断処理リスト１３５に登録する。この登録が終了するとＥＦ削除部１２３は、ステップＳ４０４により、各コールバックラッパーのカウンタの値を１増やす。そして、ステップＳ４０５によりＥＦ用ロック１３４を解放する。

次にＥＦ削除部１２３は、ステップＳ４０６において、待ち受け検索中断処理リスト１３５の各々のコールバックラッパーに対して、当該コールバックラッパーを用いて検索終了を返却する。なお、この検索終了を返却手順は後に詳しく述べる。

最後にＥＦ削除部１２３は、ステップＳ４０７において、待ち受け検索中断処理リスト１３５の内容を破棄する。特に、その中に含まれるコールバックラッパーも破棄する。そして、この破棄後にライブラリ１０１の呼び出し元にリターンし、一連の処理を完了する。

（５）コールバックラッパーを用いた検索結果の返却処理
前記ＥＡ登録処理およびＥＦ登録処理における、コールバックラッパーを用いた検索結果の返却処理はサブルーチンにより以下のように行われる。図９はその処理手順と処理内容を示すフローチャートである。

すなわち、サブルーチンが呼ばれると、ライブラリ１０１は返却処理を開始する。先ずステップＳ４５１により、当該コールバックラッパーの検索終了通知済みフラグが“検索終了通知済”か“否か”を判定し、まだ通知されていない場合（no）には、ステップＳ４５２により当該コールバックラッパーのコールバック関数を呼び出す。なお、コールバックラッパーの検索終了通知済みフラグが“検索終了通知済”（yes）であれば、ステップＳ４５２によるコールバック関数の呼び出しは省略する。

次にライブラリ１０１は、ステップＳ４５３において当該コールバックラッパーのカウンタの値を１減じ、カウンタ値が０に達したか否かをステップＳ４５４で判定する。そして、この判定の結果、カウンタ値が“０”に達していれば、ステップＳ４５５において、当該コールバックラッパーの状態変数の機能を用い、当該状態変数を用いて待ち合わせているタスクを起動させる。これに対しカウンタ値が“０”に達していなければ、ステップＳ４５５によるタスクの起動は行わずにサブルーチンの処理を終了する。

（６）コールバックラッパーを用いた検索終了の返却処理
前記ＥＦ退役処理およびＥＦ削除処理における、コールバックラッパーを用いた検索終了の返却処理はサブルーチンにより以下のように行われる。図１０はその処理手順と処理内容を示すフローチャートである。なお、ＥＦ削除処理において行われる検索式の削除に伴う検索終了通知を第１の検索終了通知、ＥＦ退役処理において行われる時間経過に応じた検索終了通知を第２の検索終了通知とそれぞれ定義する。

すなわち、サブルーチンが呼ばれると、ライブラリ１０１は返却処理を開始する。先ずステップＳ４７１により当該コールバックラッパーのカウンタの値を“１”減じ、その結果カウンタ値が“０”に達したか否かをステップＳ４７２で判定する。この判定の結果、カウンタ値が“０”に達していなければ（noであれば）、ステップＳ４７３により、当該コールバックラッパーの状態変数の機能を用い、当該タスクについて当該状態変数を用いて待ち合わせを行う。なお、カウンタ値が“０”に達していれば（yesであれば）、ステップＳ４７３による待ち合わせは省略する。

次にライブラリ１０１は、ステップＳ４７４において当該コールバックラッパーの検索終了通知済みフラグが“検索終了通知済”か“否か”を判定し、まだ通知されていない場合（no）には、ステップＳ４７７により当該コールバックラッパーのコールバック関数を呼び出す。そしてステップＳ４７８において、当該コールバックラッパーの検索終了通知済みフラグを“検索終了通知済”に設定し、サブルーチンの処理を終了する。

一方、上記コールバックラッパーの検索終了通知済みフラグが“検索終了通知済”（yes）だったとする。この場合ライブラリ１０１は、ステップＳ４７５により当該コールバックラッパーのカウンタ値を判定する。そして、カウンタ値が“０”に達していた場合には、ステップＳ４７６において、当該コールバックラッパーの状態変数の機能を用い、当該状態変数を用いて待ち合わせているタスクを起動し、サブルーチンの処理を終了する。

なお、既に述べたように、状態変数による待ち合わせ処理は、マルチスレッドプログラミングにおいて一般的に用いられる機能であり、既存のライブラリを用いて実現できる。

（動作の具体例とその効果）
（１）現在時刻が“2014-10-01 02:40:00”であり、新たにデータ値を登録する場合
いま、例えば図１１に示すデータ値（ＥＡ）を新たに登録するものとする。当該データ値（ＥＡ）は、図３に示した待ち受け中の検索式のうちの行２１１にほぼ合致するが、時刻の終値と同時刻であるため、処理タイミングによっては検索式の合致よりも検索式の退役のほうが先に起きる可能性もある。この場合、どちらであっても処理として矛盾は生じないが、アプリケーション１０２への検索結果のコールバックと検索終了のコールバックに関する呼び出しの逐次性や、検索終了コールバックの確実性について問題が生じ得る。

つまり、本実施形態によらず、すなわちコールバックラッパーを用いて図９および図１０に記載の手順を採らない実施においては、呼び出しの逐次性が担保されない。例えば、図１１に示したデータ値の登録が先だった場合、図３の行２１１に記載された検索式に関して検索結果のコールバック関数の呼び出しが行われている最中に、当該検索式の退役処理が実行され、検索終了のコールバック関数の呼び出しが同時に行われてしまい、呼び出しの逐次性が担保されない。

これに対し本実施形態では、図１０に示した検索結果の返却処理のステップＳ４５２においてコールバック関数の呼び出しが行われた際に、カウンタ値が０より大きな値となっている。このため、図１０に示す検索終了の返却処理において、ステップＳ４７２〜Ｓ４７３において待ち合わせが行われ、検索結果のコールバック関数の呼び出し（ステップＳ４５２）が完了した後にステップＳ４５５によって待ち合わせている処理が再開される。このため、ステップＳ４７７による検索終了のコールバック関数の呼び出しを、検索結果のコールバック関数の呼び出しに対して逐次化することができる。

同様に、従来の装置では、データ値の登録処理中に検索式の退役処理が並行して実行された場合、検索終了のコールバック関数の呼び出し後に検索結果のコールバック関数の呼び出しが生じ得るため、検索終了コールバックの確実性が担保されない。これに対し本実施形態では、コールバックラッパーの検索終了通知済みフラグを用いて、ステップＳ４５１により検索結果のコールバック関数を呼び出さないようにすることができる。

（２）新たに検索式を登録し、その直後に検索式の削除を行う場合
いま、例えば図１２に示すデータ値（ＥＦ）を新たに登録するものとする。当該検索式（ＥＦ）は、図２に示したデータ値の集合のうち、行２０１と行２０３に合致する例となっている。データ値蓄積型の検索処理によってこれらの行の検索を行った後、上記検索式（ＥＦ）は、検索式待ち受け型の検索処理に移行する。

図１３に検索式の削除条件の例を示す。当該削除条件は、図３に示した待ち受け中の検索式のうち、行２１１と行２１３に合致する例となっている。また、図４に示した蓄積検索処理中リストのうち、行２２１に合致する例となっている。さらに、図１２に示した検索式にも合致する例となっている。つまり、図１２に示した検索式を登録した後に、図１３に示した削除条件に従い削除を行うのであるから、ライブラリ１０１を呼び出すプログラマの視点からは、図１２に示した削除対象の検索式は削除された状態になっていることが期待されている。

ここで、検索式の削除は主に検索式待ち受け型の検索で待ち受け状態になっている検索式を削除するものであることを考えると、削除対象の検索式が検索式待ち受け型の検索処理に移行した後に削除条件の削除処理が行われた場合の挙動は、自然なものである。

一方、削除対象の検索式が検索式待ち受け型の検索処理に移行する前、すなわちデータ値蓄積型の検索処理を行っている最中に、削除条件の削除処理が行われた場合にも、本実施形態によれば削除処理を行うことができる。

具体的には、図６に示したＥＦ登録処理のステップＳ３５１によって登録された検索式（図１２）は、図８に示したＥＦ削除処理によりステップＳ４０２で削除される。このため、図６に示したＥＦ登録処理のステップＳ３５５による移行阻害判定で“yes”と判定されて、直ちにステップＳ３５７で検索終了コールバックが行われ、検索式待ち受け型の検索処理に移行することなく検索処理が完了する。

したがって、ライブラリ１０１を呼び出すプログラマの視点からは、削除対象の検索式に関してライブラリ１０１内部でデータ値蓄積型の検索処理を行っているか検索式待ち受け型の検索処理を行っているかにかかわらず、削除条件の削除処理によって検索式が検索式待ち受け型の検索処理をそれ以上行わず削除されることが担保される。このため、データ値蓄積型の検索処理と検索式待ち受け型の検索処理を区別なく扱うことができるという利点が得られる。

また、（２）の例では、図１３に示す削除条件によって複数の検索式が削除されることから、複数の検索終了コールバックが行われる。その際、検索終了コールバックに時間がかかる場合にも、本実施形態によれば正しく処理ができる利点について、併せて言及する。

ＥＦ削除処理においては、検索式待ち受け型の検索処理が行われている検索式に関して検索終了コールバックを行う際、ＥＦロック１３４を用いて排他制御を行っている区間ではコールバックそのものは実行せず、待ち受け検索中断処理リスト１３５への登録に処理を留めている。その後、ステップＳ４０５によりＥＦロック１３４を解放してから、ステップＳ４０６において検索終了のコールバックを実行する。ここで、コールバック関数はアプリケーション１０２が記述する処理であるため、短時間のうちに処理が戻されるという保証がない。しかし、上記処理手順を実行することにより、排他制御を行った結果として他のスレッドが並行動作できず性能が低下する時間を最小限に留めつつ、全てのコールバックを正しく実行することができるという利点が得られる。

（３）現在時刻が“2014-10-01 02:40:00”であり、新たに図１１に示したデータ値を登録し、かつ同時に図１３に示した削除条件に示す検索式の削除を行う場合
削除条件の削除対象のうち、図３の行２１１で示す検索式は“2014-10-01 02:40:00”に退役処理が行われる。このため本例は、データ値の登録による検索結果のコールバックと、検索式の削除による検索終了のコールバックと、検索式の退役による検索終了のコールバックとが競合する例となっている。以下ではいくつかの特徴的な競合タイミングについて、本実施形態がもたらす利点を説明する。

先ず、検索式の削除による検索終了のコールバックと検索式の退役による検索終了のコールバックの競合について例示する。従来の手法では、これらのコールバックが両方とも行われる場合があり得るため問題である。

これに対し本実施形態では、コールバックラッパーの検索終了通知済みフラグを用いて、図１０に示すようにステップＳ４７４により検索終了通知済みと判定することで、ステップＳ４７７による検索終了のコールバック関数の呼び出しが行われないようにすることができる。このため、検索終了コールバックの確実性、すなわち検索が完了したことをコールバックでちょうど１回だけアプリケーション１０２に通知する動作を保証することができる。

また、データ値の登録による検索結果のコールバックと検索式の退役による検索終了のコールバックとの競合に関しては、上記（１）で既に述べた。一方、本例に関連して、データ値の登録による検索結果のコールバックと検索式の削除による検索終了のコールバックとの競合に関しても、アプリケーションへの検索結果のコールバックと検索終了のコールバックに関する呼び出しの逐次性や、検索終了コールバックの確実性について、本実施形態を用いれば保証することができるという利点が得られる。

［他の実施形態］
前記実施形態ではデータ値および検索式をいずれもuTuple形式で表記する場合を例にとって説明した。しかしこれに限るものではなく、その他のデータ値や検索式の表現を取り扱ってもよい。例えば、一般的なリレーショナルデータベースのように、データ値を表形式で格納し、検索式をＳＱＬ文で記述するようにしてもよい。

さらに、前記実施形態においては、待ち受け検索の終了時刻は検索式に含めることとした。しかし、それに限らず、例えば検索式を何秒間保持するかを示す秒数情報を検索式以外の引数として渡すようにしてもよい。

また、前記実施形態では、検索結果のコールバックと検索終了のコールバックに同一のコールバック関数を用いることとした。しかし、それに限るものではなく、複数のコールバック関数を用いてもよい。また同様に、前記一実施形態では、ＥＦ削除したことに起因する検索終了と、ＥＦが時刻経過により退役したことに起因する検索終了とは、区別しないコールバックとした。しかし、それに限らず、アプリケーション１０２が検索終了理由を取得できるように、別の種類のコールバックとしてもよい。或いは、通信等のコールバック以外の手段によって、検索結果や検索終了を通知するようにしてもよい。

さらに、前記実施形態では、ＥＡ用リポジトリ１３１およびＥＦ用リポジトリ１３２は、表などの単純なデータ構造を用いる場合を例にとって説明した。このようなデータ構造において、検索処理は上から順に照合していくことで実現できる。しかし、本発明はこれに限るものではなく、木構造のように検索処理を高速に行える他のデータ構造を用いてもよい。あるいは、特許文献３に開示されている、データ値を複数のテキストファイルに分割して保存する手法を用いてもよい。

また、この発明に係る情報記録装置は、扱う対象となるデータ値として主にセンサ情報を想定している。センサ情報とは温度や加速度に限らず、様々な情報がその対象となるものである。一例を挙げると、湿度、電流あるいは電圧値、流体の流量、物質の濃度、明度、騒音、位置、速度などの、各種センサデバイスが計測した値を取り扱うことができる。またセンサに限らず、例えばＷｅｂやインターネットを経由して取得した情報を取り扱ってもよい。さらに、それら値に加えて、センサの特性や状態、計測日時等を示すメタデータを含む情報を取り扱ってもよい。

さらに、本発明の情報記録装置で使用するプログラムを記録媒体に記録することも、またネットワークを通して提供することも可能である。要するにこの発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態に亘る構成要素を適宜組み合せてもよい。

１００…情報記録装置、１０１…ライブラリ、１０２…アプリケーション、１０３…温度センサ、１０４…加速度センサ、１０５…タッチパネル／ディスプレイ、１２１…ＥＡ登録部、１２２…ＥＦ登録部、１２３…ＥＦ削除部、１２４…計時部、１３１…ＥＡ用リポジトリ、１３２…ＥＦ用リポジトリ、１３３…蓄積検索処理中リスト、１３４…ＥＦ用ロック、１３５，１３６…待ち受け検索中断処理リスト。

Claims (8)

1. データ値群を記録する情報記録装置であって、
   データ値を保持するデータ値用リポジトリ、検索式を保持する検索式用リポジトリおよび蓄積検索処理中リスト情報を記憶する記憶部と、
   前記データ値を登録するためのデータ値登録処理手段、前記検索式を登録するための検索式登録処理手段、および前記検索式を削除するための検索式削除処理手段を備える処理部と
   を具備し、
   前記データ値登録処理手段は、
   前記データ値用リポジトリにデータ値を書き込む手段と、
   前記データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理を実行する手段と、
   前記検索式待ち受け型検索処理による検索結果を通知する手段と
   を有し、
   前記検索式登録処理手段は、
   前記蓄積検索処理中リスト情報に、処理中の検索式を追加する手段と、
   前記検索式をもとに前記データ値用リポジトリからデータ値の集合を検索するデータ値蓄積型検索処理を実行する手段と、
   前記検索式群に関し排他制御を行う手段と、
   前記排他制御が行われている状態で、前記蓄積検索処理中リスト情報から該当する検索式を削除すると共に、前記データ値蓄積型検索処理から前記検索式待ち受け型検索処理への移行の可否を判定する手段と、
   前記移行が可能と判定された場合に、前記検索式用リポジトリに前記検索式を書き込む手段と、
   前記データ値蓄積型検索処理による検索結果を通知する手段と
   を有し、
   前記検索式削除処理手段は、
   前記検索式に関し排他制御を行う手段と、
   前記排他制御が行われている状態で、前記蓄積検索処理中リスト情報から削除対象の検索式を削除する手段と、
   前記検索式用リポジトリから削除対象の検索式を検索して、当該検索式を削除する手段と、
   前記削除対象とした検索式の削除に応じて検索が終了したことを通知する手段と
   を有する
   ことを特徴とする情報記録装置。
2. データ値群を記録する情報記録装置であって、
   検索式を保持する検索式用リポジトリを記憶する記憶部と、
   データ値を登録するためのデータ値登録処理手段、検索式を登録するための検索式登録処理手段、および時間経過に応じて処理を起動する計時手段を有する処理部と
   を具備し、
   前記データ値登録処理手段は、
   データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理を実行する手段と、
   前記検索式待ち受け型検索処理による検索式の検索結果を通知する手段と
   を有し、
   前記検索式登録処理手段は、
   前記検索式用リポジトリに検索式を書き込む手段を有し、
   前記計時手段は、
   前記検索式用リポジトリから検索終了時刻が経過した検索式を検索して、当該検索式を削除する手段と、
   前記検索終了時刻が経過した検索式に対する検索終了を通知する第１の検索終了通知手段と
   を有し、
   前記第１の検索終了通知手段は、０回以上の検索結果の通知の後に、１回の前記検索式に対する検索終了の通知を実行することを特徴とする情報記録装置。
3. 前記記憶部は、データ値を保持するデータ値用リポジトリをさらに有し、
   前記処理部は、検索式を削除する検索式削除処理手段をさらに有し、
   前記データ値登録処理手段は、
   前記データ値用リポジトリにデータ値を書き込む手段をさらに有し、
   前記検索式登録処理手段は、
   前記検索式をもとに前記データ値用リポジトリからデータ値の集合を検索するデータ値蓄積型検索処理を実行する手段と、
   前記データ値蓄積型検索処理による検索結果を通知する手段と
   をさらに有し、
   前記検索式削除処理手段は、
   前記検索式用リポジトリから削除対象に合致する検索式を検索して、当該検索式を削除する手段と、
   前記削除対象とした検索式の削除に応じて検索が終了したことを通知する第２の検索終了通知手段と
   を有することを特徴とする請求項２に記載の情報記録装置。
4. 前記第１及び第２の検索終了通知手段の少なくとも一方は、
   検索結果の通知中の処理の有無を保持する手段と、
   検索終了の通知済みの有無を保持する手段と、
   前記保持されている検索結果の通知中の処理の有無と、前記保持されている検索終了の通知済みの有無に応じて、通知中の処理の完了を待ち合わせる手段と
   を有することを特徴とする請求項２または３に記載の情報記録装置。
5. 前記情報記録装置が取り扱うデータ値および検索式として、キーと値との組あるいはキーと値範囲との組の並びを含むことを特徴とする請求項１乃至４のいずれかに記載の情報記録装置。
6. データ値を保持するデータ値用リポジトリ、検索式を保持する検索式用リポジトリ、および蓄積検索処理中リスト情報を記憶する記憶部と、前記データ値を登録するためのデータ値登録処理手段、前記検索式を登録するための検索式登録処理手段、および前記検索式を削除するための検索式削除処理手段を備える処理部とを具備する情報記録装置が実行する情報記録方法であって、
   前記データ値登録処理手段により、
   前記データ値用リポジトリにデータ値を書き込む過程と、
   前記データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理を実行する過程と、
   前記検索式待ち受け型検索処理による検索結果を通知する過程と
   を実行し、
   前記検索式登録処理手段により、
   前記蓄積検索処理中リスト情報に、処理中の検索式を追加する過程と、
   前記検索式をもとに前記データ値用リポジトリからデータ値の集合を検索するデータ値蓄積型検索処理を実行する過程と、
   前記検索式群に関し排他制御を行う過程と、
   前記排他制御が行われている状態で、前記蓄積検索処理中リスト情報から該当する検索式を削除すると共に、前記データ値蓄積型検索処理から前記検索式待ち受け型検索処理への移行の可否を判定する過程と、
   前記移行が可能と判定された場合に、前記検索式用リポジトリに前記検索式を書き込む過程と、
   前記データ値蓄積型検索処理による検索結果を通知する過程と
   を実行し、
   前記検索式削除処理手段により、
   検索式に関する排他制御を行う過程と、
   前記排他制御行われている状態で、前記蓄積検索処理中リスト情報から削除対象の検索式を削除する過程と、
   前記検索式用リポジトリから削除対象の検索式を検索して、当該検索式を削除する過程と、
   前記削除対象とした検索式の削除に応じて検索が終了したことを通知する過程と
   を実行する
   ことを特徴とする情報記録方法。
7. 検索式を保持する検索式用リポジトリを記憶する記憶部と、データ値を登録するためのデータ値登録処理手段、検索式を登録するための検索式登録処理手段、および時間経過に応じて処理を起動する計時手段を有する処理部とを具備する情報記録装置が実行する情報記録実行方法であって、
   前記データ値登録処理手段により、
   データ値をもとに合致する検索式を前記検索式用リポジトリから検索する検索式待ち受け型検索処理を実行する過程と、
   前記検索式待ち受け型検索処理による検索式の検索結果を通知する過程と
   を実行し、
   前記検索式登録処理手段により、
   前記検索式用リポジトリに検索式を書き込む過程を実行し、
   前記計時手段により、
   前記検索式用リポジトリから検索終了時刻が経過した検索式を検索して、当該検索式を削除する過程と、
   前記検索終了時刻が経過した検索式に対する検索終了を通知する検索終了通知過程と
   を実行し、
   さらに前記検索終了通知過程は、０回以上の検索結果の通知の後に、１回の前記検索式に対する検索終了の通知を実行することを特徴とする情報記録方法。
8. 請求項１乃至５のいずれかに記載の情報記録装置が有する各手段による処理を、当該情報記録装置の処理部が具備するプロセッサに実行させるプログラム。

Images