JP5144225B2 - 情報検索装置、及び情報検索装置へのエントリ情報の登録方法 - Google Patents

Description

本発明は、Ｂｌｏｏｍｉｅｒフィルタ型の情報検索装に関し、特にＢｌｏｏｍｉｅｒフィルタと呼ばれる検索用のデータ構造の構築方法の改良に関する。

ネットワーク上を流れるパケットデータを他のネットワークに中継する機器であるルータは、ルーティングプロトコルに基づいて他のルータとの間で経路情報を相互に交換することによって経路情報を学習し、入力パケットに付与されたネットワーク層のアドレスを経路情報と照合することによって、入力パケットの転送先を決定する経路選択機能を有している。

インターネットに接続されるホスト数の増加していることに加え、最近の動画像ビデオ会議のような広帯域を要求するアプリケーションの普及によって、インターネットトラフィックが急激に増大している。これらの広帯域アプリケーションの十分な品質を確保するために、通信リンクはより高いデータレートへと高度化されつつある。しかし高速化されたリンクは、ルータによるＩＰ（Internet Protocol）パケットの転送処理速度が高速化されている場合にのみ、端末相互間におけるエンド・ツー・エンドの品質向上に寄与し得るものである。

ルータにおいて重大なボトルネックとなる処理は、経路選択のためのアドレス検索処理である。アドレス検索処理とは、例えば、ＩＰパケットヘッダから取得した３２ビット幅を持つＩＰｖ４アドレスを入力し、入力アドレスに対応する経路情報（転送先アドレス、転送先ネットワーク、転送先ポート等）を決定する処理である。なお、以下では、入力情報に対応する関連情報を検索する装置を情報検索装置と呼び、特に、アドレス検索、つまり、入力アドレスに対応する転送先経路の検索を行う装置をネットワークサーチエンジンと呼ぶ。

アドレス検索処理を高速化するネットワークサーチエンジンとして、Ｂｌｏｏｍｉｅｒフィルタと呼ばれるデータ構造に経路情報を格納し、当該データ構造に基づいてアドレス検索を実行するネットワークサーチエンジンが提案されている（非特許文献１を参照）。

Ｂｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン９の構成を図９に示す。図９において、ハッシュ演算部９１は、入力パケットのヘッダに含まれている宛先アドレスに対し、Ｋ個のハッシュ関数によるハッシュ演算を行ってＫ個のハッシュ値を出力する。インデックステーブル９２は、Ｋ個のハッシュ関数によって得られるハッシュ値によってアドレスされるメモリである。

論理演算部９３は、インデックステーブル９２に格納された値を読み出して排他的論理和演算を行う。フィルタリングテーブル９４及びリザルトテーブル９５は、論理演算部９３の演算結果によってアドレスされるメモリである。フィルタリングテーブル９４には、入力される宛先アドレスに対応する情報、具体的にはプリフィックス情報が格納される。リザルトテーブル９５には、経路情報が格納される。

比較部９６は、フィルタリングテーブル９４に格納された値と入力ヘッダに含まれている宛先アドレスとを比較し、これらのプリフィックスが一致する場合に、ｖａｌｉｄ信号を出力する。

ネットワークサーチエンジン９は、インデックステーブル９２、フィルタリングテーブル９４及びリザルトテーブル９５に対する書き込みを後述する方法によって行うことにより、入力された宛先アドレスに対応する経路情報を一定の短い時間で出力することを可能としている。

次に、インデックステーブル９２、フィルタリングテーブル９４及びリザルトテーブル９５に対する書き込みを行って、ネットワークサーチエンジン９をセットアップする方法を説明する前に、必要な用語の定義を行う。以下では、ネットワークサーチエンジン９に登録される入力アドレスと当該アドレスに対応する経路情報との対をエントリと呼ぶ。また、あるアドレスに対して演算されるＫ個のハッシュ値のうち、ネットワークサーチエンジン９に登録されたエントリの集合に含まれる他のエントリに対して演算されるハッシュ値と重複しないハッシュ値が存在する場合、この重複しないハッシュ値をシングルトンと呼ぶ。また、エントリに関する情報をインデックステーブル９２に格納する際には、後述するような演算処理を実行した後に書き込みを行うため、エントリに関する情報をインデックステーブル９２に格納することをエンコードすると表現する。

インデックステーブル９２は、登録エントリの集合に含まれる各エントリｔについて、エントリｔの入力アドレスから算出されるＫ個のハッシュ値のうちの１つによって指定されるテーブルメモリアドレスに、エントリｔの関連情報（例えば経路情報）を復元可能な形で書き込むことによってセットアップされる。ここで、テーブルメモリアドレスをτ（ｔ）とする。なお、エントリｔと異なる別のエントリｔ´の関連情報は、エントリｔと同じテーブルメモリアドレスτ（ｔ）に格納されることはない。つまり、エントリｔ´に対しては、ユニークなテーブルメモリアドレスτ（ｔ´）が確保される。登録エントリ集合に含まれる全てのエントリｔに対してτ（ｔ）を算出する手順の一例を以下に示す。

インデックステーブル９２は、エントリｔの入力アドレスが与えられた際に、テーブルメモリアドレスτ（ｔ）に書き込まれたエントリｔの関連情報が回復できるようにセットアップされる必要がある。Ｋ個のハッシュ関数のうちで、エントリｔの入力アドレスからハッシュ値、つまりテーブルメモリアドレスτ（ｔ）を算出するハッシュ関数の識別子をｈτ（ｔ）とする。τ(ｔ)はＫ個のハッシュ値のうちの１つではあるが、情報回復の過程ではｈτ(ｔ)は未知である。つまり、インデックステーブル９２のセットアップの過程においてｈτ（ｔ）が特定されるが、ｈτ（ｔ）それ自体はインデックステーブル９２等に保存されたり、アドレス検索の過程で参照されたりする情報ではない。

τ（ｔ）を算出するハッシュ関数の識別子ｈτ(ｔ)を知ることなく、アドレス検索の過程で関連情報を回復するためには、例えば、あるエントリｔの入力アドレスに対して得たＫ個のハッシュ値によって指定されるインデックステーブル９２の全ての場所に格納された情報を用いた単純なブール演算を行うことによって関連情報が得られるように、これらの場所に何らかの情報を書き込んでおくことが必要とされる。実際には、インデックステーブ９２のセットアップップ過程において、エントリｔに対するｈτ（ｔ）を特定した後に、以下の（１）式に示すエンコード値Ｖ（ｔ）をτ（ｔ）に書き込む。

（１）式において、"＾"は、排他的論理和演算を表している。Ｈ_ｉ（ｔ）は、エントリｔから算出されるｉ番目のハッシュ値を表している。Ｄ［Ｈ_ｉ（ｔ）］は、インデックステーブル９２のアドレスＨ_ｉ（ｔ）に格納された情報である。Ｋは、ハッシュ演算部９１に適用されるハッシュ関数の数である。Ｉ（ｔ）は、エントリｔに関連付けられた情報であり、インデックステーブルから回復したい情報である。また、上述したように、ｈτ（ｔ）は、Ｋ個のハッシュ関数のうちでτ（ｔ）を算出するハッシュ関数を示す識別子（番号）である。

Ｂｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン９が備えるインデックステーブル９２を、上述した手順でセットアップすることにより、エントリｔの入力アドレスが与えられた場合に、Ｋ個のハッシュ値によって指定される全ての場所に格納された情報に対する排他的論理和演算によって、所望の情報Ｉ（ｔ）を取り出すことができる。つまり、情報Ｉ（ｔ）を得るために以下の（２）式に示す演算を行う。

インデックステーブル９２のセットアップにおける他の重要な処理は、全ての登録エントリｔに対してユニークな、つまりシングルトンであるτ（ｔ）を決定することである。Ｂｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン９では、τ（ｔ）の決定に非特許文献１に詳細に開示されているアルゴリズムを用いる。以下に、当該アルゴリズムの概略を示す。

まず始めに、ネットワークサーチエンジン９に登録エントリ集合をセットアップする際に参照される登録エントリｔの順序Γを決定する。順序Γは、順序Γ中に含まれる各々のエントリｔが、自身より前に位置する全てのエントリに対して算出さていないハッシュ値を持つことを特徴する順序である。ひとたび順序Γが得られれば、順序Γに従った順番で（１）式によるエントリｔのエンコードを行っていけばよい。これが登録エントリｔの各々に対してシングルトンであるτ（ｔ）が与えられるための十分条件である。その理由は以下の通りである。

まず、順序Γで指定された最初のエントリｔ１は、Ｋ個のハッシュ値で指定されるＫ個のテーブルメモリアドレスのうちのどの位置にエンコードされても良い。エントリｔ１以前にエンコードされたエントリが存在しないためである。順序Γで２番目に位置するエントリｔ２は、順序Γの決定規則によれば、エントリｔ１とは共有しない少なくとも１つのハッシュ値を持っている。このため、エントリｔ２のエンコード時点においてエントリｔ１が既にエンコードされているが、エントリｔ２はエントリｔ１と共有していないハッシュ値によって指定される位置に、（２）式による情報Ｉ（ｔ２）の回復が保証された状態でエンコードされる。なお、１つのエントリをエンコードする際には、（１）式に示したエンコード値Ｖ（ｔ）によって、１つの格納場所のみを書き換えるのみであることに着目すれば、エントリｔ１に対応する情報Ｉ（ｔ１）の回復に必要な情報は、エントリｔ２のエンコードによって破壊されないことが判る。エントリｔ２のシングルトンτ（ｔ２）は、エントリｔ１に対するＫ個のハッシュ値に含まれていないためである。３番目以降のエントリに対しても、順序Γによって同様のことが保証される。

このような順序Γは、図１０に示す手順に従って決定することができる。登録エントリの集合９７の中からハッシュ値がシングルトンであるエントリｔ１を判定し、スタックメモリ（エントリスタック）９８の底にエレメントｔ１を格納して、ｔ１をエントリ集合９７から削除する（ステップＳ９０２及びＳ９０３）。後は、この処理を、エントリ集合９７が空になるまで、再帰的に繰り返せばよい（ステップＳ９０１）。最終的に得られるエントリスタック９８は、エントリ集合９７に含まれる全ての登録エレメントが順序Γで格納された状態となる。なお、図１０のステップＳ９０４及びＳ９０５は、上述した順序Γ決定後に実行するエンコード手順を示している。

なお、上記のステップＳ９０１〜Ｓ９０３の繰り返し処理において、最初のエントリｔ１については、Ｋ個のハッシュ値の全てがシングルトンになり得る。しかし、以降のエントリについて処理を繰り返すうちに、Ｋ個のハッシュ値の全てが、過去に処理済みのエントリのシングルトン群と衝突するエントリが発生する場合がある。この場合は、処理済みのエントリに対するシングルトンの記憶をクリアした上で、図１０の処理を繰り返し、最終的にエントリ集合９７に含まれる全てのエントリがエントリスタック９８に移動されることにより、順序Γを得ることができる。

上述したインデックステーブル９２のセットアップ手順において、インデックステーブル９２にエンコードする関連情報Ｉ（ｔ）を、リザルトテーブル９５に格納される経路情報を指定するためのテーブルメモリアドレスとすることによって、ネットワークサーチエンジン９によるアドレス検索が可能となる。これにより、ネットワークサーチエンジン９は、入力アドレスに対応する経路情報を決定するアドレス検索動作を一定のクロックサイクル数で行うことができる。

ところで、ハッシュ関数は、例えば３２ビット幅の入力アドレスを、実際の登録エントリ数を表すビット幅（例えば２０ビット）に圧縮している。このため、上述したセットアップ過程でのハッシュ値の衝突と同様の事象が、登録済みのエントリと未登録のエントリとの間でも発生し得る。これを、誤検出（false positive）と呼ぶ。このことは、インデックステーブル９２にエンコードされたエントリ集合に含まれていないエントリが検索された場合に、上記の式（２）による演算によって、一見したところでは妥当なＩ（ｔ）の値が得られる場合があることを意味し、未登録のエントリを示す入力アドレスに対して誤った経路情報を答えるという誤動作をもたらすことになる。

このような、誤検出（false positive）に伴うネットワークサーチエンジン９の誤動作を防止するために使用されるのが、フィルタリングテーブル９４である。フィルタリングテーブル９４には、リザルトテーブル９５に登録される経路情報に対応する入力アドレスが、論理演算部９３の出力Ｉ（ｔ）によって指定されるリザルトテーブル９５のテーブルメモリアドレスと同じアドレスに書き込まれている。誤検出（false positive）の判定は以下の手順により可能である。まず、入力アドレスに対応するリザルトテーブル９４のテーブルメモリアドレスが論理演算部９３の出力として得られたとき、比較部９６において、入力アドレスとフィルタリングテーブル９４に格納された値とが比較される。両者のプリフィックスが一致する場合は誤検出でないと判定でき、両者のプリフィックスが一致しない場合には誤検出（false positive）であることが判定できる、これにより、誤検出（false positive）と判定した入力パケットを経路情報が存在しないパケットとして廃棄するなど適切な処理を行うことができる。
B. Chazelle , J.Kilian, R.Rubinfeld, A. Tal、「The Bloomier Filter: An Efficient Data Structure for Static Support Lookup Tables」、ACM-SIAM Symposium on Discrete Algorithms (SODA) '04、2004年1月、p.30-39

上述したＢｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン９では、登録エントリの集合が与えられた場合に、エントリ集合に含まれるエントリに対する順序Γを決定し、順序Γに従って順番にエントリのエンコードを行うことにより、ネットワークサーチエンジン９のセットアップを行うこととしている。

しかしながら、ネットワークサーチエンジンの適用先であるルータは、一般に、ルーティングプロトコルに従って動的に経路情報を保守している。このため、ルータは、新たに得られたエントリを逐次的に登録できること、つまり、逐次的にインデックステーブル９２にエンコードできることが望ましい。したがって、順序Γを予め決定し、この順序Γに従ってエントリの登録を行わなければならない従来のエントリ登録処理は、機能的に不十分であるという問題がある。

なお、このような問題は、ネットワークサーチエンジンに限らず、Ｂｌｏｏｍｉｅｒフィルタ型の情報検索装置が有する共通の問題である。

本発明にかかる情報検索装置は、入力データと出力データを対応付ける複数のエントリ情報を保持し、入力された入力データに対応する出力データを前記複数のエントリ情報から検索して出力するＢｌｏｏｍｉｅｒフィルタ型の第１の検索処理部と、新たなエントリ情報の登録要求に応じて、前記第１の検索処理部に新たなエントリ情報を登録するエントリ登録部とを備える。さらに、前記第１の情報検索部は、入力データを用いてＫ個のハッシュ値を生成するハッシュ演算部と、前記ハッシュ演算部が生成するハッシュ値によってアドレスされ、前記エントリ情報の関連情報がエンコードされたエンコード値を格納するための複数の格納領域を有するインデックステーブルと、前記ハッシュ演算部が生成したハッシュ値によってアドレスされる格納領域に格納された前記エンコード値を用いて前記関連情報を復元する第１演算部と、前記第１演算部が復元した前記関連情報によってアドレスされ、前記複数の出力データを格納するための格納領域を有するリザルトテーブルとを備える。またさらに、前記エントリ登録部は、前記インデックステーブルの複数の格納領域の各々についての更新履歴を記録した履歴情報を格納する記憶部を有しており、前記エントリ登録部は、前記新たなエントリ情報に対する新たなエンコード値を格納するための前記インデックステーブルの格納領域を、前記履歴情報に基づいて決定するとともに、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新値を、前記履歴情報に基づいて生成し、前記新たなエンコード値及び前記エンコード値の更新値によって前記インデックステーブルを更新する。

このような構成によれば、インデックステーブルの更新履歴を記録した履歴情報を参照することによって、新たなエントリ情報のエンコード値を登録可能な前記インデックステーブルの格納領域を判定すること、新たなエントリ情報のエンコード値を登録する格納領域を指定するハッシュ値が過去のエントリ情報に対してシングルトンである否かを判定すること、及び、過去に登録済みのエントリ情報に対するエンコード値の更新値を生成することが可能となる。これによって、予め全てのエントリ情報のインデックステーブルへの登録順序を定め、これに従って登録を行う必要がなくなり、新たなエントリ情報のインデックステーブルへの登録を逐次的に行うことが可能となる。

一方、本発明にかかる情報検索装置へのエントリ情報の登録方法は、入力データと出力データを対応付ける複数のエントリ情報を保持し、入力された入力データに対応する出力データを前記複数のエントリ情報から検索して出力するＢｌｏｏｍｉｅｒフィルタ型の第１の検索処理部を備える情報検索装置に対して、新たなエントリ情報を登録する登録方法である、ここで、前記第１の情報検索部は、入力データを用いてＫ個のハッシュ値を生成するハッシュ演算部と、前記ハッシュ演算部が生成するハッシュ値によってアドレスされ、前記エントリ情報の関連情報をエンコードしたエンコード値を格納するための複数の格納領域を有するインデックステーブルとを備える。また、前記新たなエントリ情報の登録処理では、まず、前記新たなエントリ情報に対する新たなエンコード値を格納するための前記インデックステーブルの格納領域を、前記インデックステーブルの複数の格納領域の各々についての更新履歴を記録した履歴情報に基づいて決定する。次に、前記新たなエントリ情報に対する新たなエンコード値を生成する。さらに、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新値を、前記履歴情報に基づいて生成する。最後に、前記新たなエンコード値及び前記エンコード値の更新値によって前記インデックステーブルを更新する。

このような方法によれば、インデックステーブルの更新履歴を記録した履歴情報を参照することによって、新たなエントリ情報のエンコード値を登録可能な前記インデックステーブルの格納領域を判定すること、新たなエントリ情報のエンコード値を登録する格納領域を指定するハッシュ値が過去のエントリ情報に対してシングルトンである否かを判定すること、及び、過去に登録済みのエントリ情報に対するエンコード値の更新値を生成することが可能となる。これによって、予め全てのエントリ情報のインデックステーブルへの登録順序を定め、これに従って登録を行う必要がなくなり、新たなエントリ情報のインデックステーブルへの登録を逐次的に行うことが可能となる。

本発明により、新たなエントリの登録を逐次的に行うことが可能な、Ｂｌｏｏｍｉｅｒフィルタ型の情報検索装置を提供することができる。

以下では、本発明を適用した具体的な実施の形態について、図面を参照しながら詳細に説明する。各図面において、同一要素には同一の符号が付されており、説明の明確化のため、必要に応じて重複説明は省略する。なお、以下に示す実施の形態は、Ｂｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジンに対して本発明を適用したものである。

発明の実施の形態１．
本実施の形態にかかるＢｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン１の構成を図１に示す。図１において、ハッシュ演算部９１、インデックステーブル９２、論理演算部９３、フィルタリングテーブル９４、リザルトテーブル９５、及び、比較部９６は、上述した従来のネットワークサーチエンジン９が備える構成要素と同一である。

エントリ登録部１１は、新たなエントリをインデックステーブル９２にエンコードするとともに、フィルタリングテーブル９４に新たなエントリのプリフィックスを格納し、リザルトテーブルに転送情報、つまり転送先アドレスを格納する。リンクリスト配列１２は、インデックステーブル９２のソフトウェアイメージに対応するものであり、インデックステーブル９２の格納情報を保持している双方向リンクリストの配列である。

第２検索処理部１３は、ハッシュ演算部９１から比較部９６によって構成される第１検索処理部１０とは別に設けられ、入力パケットヘッダを入力し、入力パケットヘッダに含まれる宛先アドレスに対応する経路情報を決定するアドレス検索処理を実行する。第２検索処理部１３は、通常のＴＣＡＭ（Ternary Content Addressable Memory）又はこれをエミュレートするグルーロジックによって実現することができる。後述するように、本実施の形態のネットワークサーチエンジン１は、新たなエントリをインデックステーブル９２に逐次的に登録可能であるため、第２検索処理部１３の規模はハッシュ演算部９１から比較部９６で構成される第１の検索処理部１０に比べて十分に小さくすることが可能である。

次に、リンクリスト配列１２のデータ構造を図２乃至図４を用いて説明する。なお、以下では、ハッシュ演算部９１に適用されるハッシュ関数の数が３つ（Ｋ＝３）の場合について説明する。

図２は、リンクリスト配列１２の全体のデータ構造を示す概念図である。図２において、ｌｉｓｔ［ｉ]が１つの双方向リンクリストに対応する。ここで、ｉ＝０〜（Ｎ−１）である。１つのリンクリストｌｉｓｔ［ｉ]は、インデックステーブル９２の１つの情報格納領域、具体的には１つのエンコード値Ｖ（ｔ）を格納可能な領域に対応する。つまり、リンクリストｌｉｓｔ［ｉ］の総数Ｎは、インデックステーブル９２にエンコード可能なエントリの最大数に対応する。

１つのリンクリストｌｉｓｔ［ｉ]のリスト構造を図３に示す。以下では、ｌｉｓｔ［ｉ]を構成し、ポインタによって連結されるデータ単位をｕｎｉｔと呼ぶ。セットアップのためにインデックステーブル９２のテーブルメモリアドレスがアクセスされるたびに、対応するｌｉｓｔ［ｉ]に新たなｕｎｉｔが連結される。なお、リンクリストｌｉｓｔ［ｉ]は双方向リストであるため、各ｕｎｉｔは、ｐｒｅｖポインタ及びｎｅｘｔポインタの２つのポインタを有している。ｐｒｅｖポインタは、時間的に過去のアクセスされた際に生成されたｕｎｉｔを指すポインタである。また、ｎｅｘｔポインタは、時間的に後のアクセス時に生成されたｕｎｉｔを指すポインタである。図３において、ｕｎｉｔ１２１は、ｌｉｓｔ［ｉ］の先頭ユニットであり、ｕｎｉｔ１２１のｐｒｅｖポインタの値はNULLに初期設定される。

図４は、１つのｕｎｉｔのデータ部に格納される内容を示している。具体的には、ｄａｔａは、インデックステーブル９２に格納されるデータ値である。ｓｉｎｇｌｅｔｏｎ＿ｆｌａｇは、このｕｎｉｔに対応するインデックステーブル９２のアドレスがシングルトンとして選択された、つまり、あるエントリｔに対するτ（ｔ）として選択されたことを示すフラグである。ａｃｃｅｓｓ＿ｃｏｕｎｔは、このｕｎｉｔに対応するインデックステーブル９２のアドレスがアクセスされた回数を示す。ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ０及び１は、同じ登録エントリから、このｕｎｉｔを指すハッシュ関数を除く、他の２つのハッシュ関数（一般的にはｋ−１個のハッシュ関数）が算出したハッシュ値がそれぞれ格納される。

続いて、エントリ登録部１１が、インデックステーブル９２に新たなエントリをエンコードする際の処理手順を、図５乃至図８のフローチャートを用いて説明する。図５及び図６は、新たなエントリをエンコードする際の全体処理を示すフローチャートである。ステップＳ１０１では、リンクリスト配列１２を初期化する。具体的には、各リストに１つのｕｎｉｔを生成し、これらのｕｎｉｔのデータ部を、ｄａｔａ＝０、ｓｉｎｇｌｅｔｏｎ＿ｆｌａｇ＝ｆａｕｌｓｅ、ａｃｃｅｓｓ＿ｃｏｕｎｔ＝０、ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ０及び１＝任意のテーブルメモリアドレスに設定する。

ステップＳ１０２において、新たなエントリｔの登録要求があった場合、この登録要求から３つ（一般的にはＫ個）のハッシュ値Ｈ_０（ｔ）、Ｈ_１（ｔ）、及びＨ_２（ｔ）を算出する（ステップＳ１０３）。これらのハッシュ値をアドレスとしてリンクリスト配列１２にアクセスし、対応する３つのリストｌｉｓｔ［Ｈ_０（ｔ）］、ｌｉｓｔ［Ｈ_１（ｔ）］、及びｌｉｓｔ［Ｈ_２（ｔ）］の最後尾、つまり最新のアクセス時の状態が格納されたｕｎｉｔを読み出す（ステップＳ１０４）。そして、読み出した３つのｕｎｉｔから、以下に示す動作によって新しい３つのｕｎｉｔを作成する（ステップＳ１０５）。

具体的には、読み出したｕｎｉｔのｄａｔａ及びｓｉｎｇｌｅｔｏｎ＿ｆｌａｇを新たなｕｎｉｔにコピーする。また、新たなｕｎｉｔのａｃｃｅｓｓ＿ｃｏｕｎｔは、読み出したｕｎｉｔのａｃｃｅｓｓ＿ｃｏｕｎｔを１だけインクリメントした値とする。また、新たなｕｎｉｔのｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ０には、このｕｎｉｔを読み出したハッシュ関数の次の番号のハッシュ関数によって算出したハッシュ値、例えば、読み出したハッシュ関数がＨ_０であればハッシュ関数Ｈ_１によって算出したハッシュ値Ｈ_１（ｔ）を設定する。同様に、新たなｕｎｉｔのｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ１には、このｕｎｉｔを読み出したハッシュ関数の２つ後の番号のハッシュ関数によって算出したハッシュ値、例えば、読み出したハッシュ関数がＨ_０であればハッシュ関数Ｈ_２によって算出したハッシュ値Ｈ_２（ｔ）を設定する。なお、ここでは、ハッシュ関数の番号は、ハッシュ関数の総数Ｋ＝３の剰余系で循環するものとする。つまり、ハッシュ関数Ｈ_２の次の番号のハッシュ関数はＨ_０とする。

次に、作成した３つのｕｎｉｔのｓｉｎｇｌｅｔｏｎ＿ｆｌａｇを参照して、未使用状態（ｆａｌｓｅ）にあるｕｎｉｔを１つ選択する（ステップＳ１０６）。ステップＳ１０７では、選択したｕｎｉｔのｄａｔａに対して、他の２つのｕｎｉｔのｄａｔａ値と、登録エントリｔに関連付けてエンコードされる情報Ｉ（ｔ）とを用いて（１）式により算出したエンコード値Ｖ（ｔ）を設定する。また、併せて、選択したｕｎｉｔのｓｉｎｇｌｅｔｏｎ＿ｆｌａｇに、シングルトンとして使用済みであることを示す値ｔｒｕｅを設定する。

ステップＳ１０８では、以上の手順で作成した３つのｕｎｉｔを、３つのリストｌｉｓｔ［Ｈ_０（ｔ）］、ｌｉｓｔ［Ｈ_１（ｔ）］、及びｌｉｓｔ［Ｈ_２（ｔ）］の最後尾にそれぞれ連結する。

なお、上述したステップＳ１０６においてシングルトンとして選択したｕｎｉｔのａｃｃｅｓｓ＿ｃｏｕｎｔが１より大きい場合、このｕｎｉｔのｄａｔａ値が過去に読み出されたうえ、（１）式によるエンコード値の算出に用いられて、他のいずれかのリンクリストに連結されたｕｎｉｔのｄａｔａ値として書き込まれた履歴があることを示している（ステップＳ１０９）。この場合には、過去のアクセスでシングルトンとして選択されたｕｎｉｔのｄａｔａ値を、今回の更新によって書き換えたｕｎｉｔのｄａｔａ値の内容を反映した値に更新する必要がある。この更新処理は、図６に示すステップＳ１１０からＳ１１７のループ処理Ａによって行うことができる。

ステップＳ１１０からＳ１１７のループ処理Ａは、今回のアクセスでシングルトンとして選択したｕｎｉｔのｐｒｅｖポインタを順に辿りながらループ内の処理（ステップＳ１１１〜Ｓ１１６）を繰り返すものである。また、ｐｒｅｖポインタの値がＮＵＬＬでないことをループ条件としている。言い換えると、ループの終了条件は、ｐｒｅｖポインタの値＝ＮＵＬＬとなることである。ループ処理Ａ内では、相互再帰的に定義された関数ａｔ０及びａｔ１を繰り返し実行する。以下、ループ処理Ａの内容を詳細に説明する。

ステップＳ１１１では、後述する関数ａｔ０及びａｔ１のループ処理Ａ内での呼び出し回数を示す変数Ｎ_ｃａｌｌを０に初期化する。ステップＳ１１２では関数ａｔ０を実行する。関数ａｔ０の呼び出し時に与えられる引数は、ｐｒｅｖポインタの値、及び今回シングルトンとして選択したｕｎｉｔのｄａｔａ値、つまりステップＳ１０７で書き込んだＶ（ｔ）値である。

関数ａｔ０の処理内容を図７に示す。ステップＳ２０１では、関数の呼び出し回数を示す変数Ｎ_ｃａｌｌの値を１だけインクリメントする。ステップＳ２０２では、Ｎ_ｃａｌｌの値が所定の閾値より小さいか否か、つまり、ステップＳ１１２での関数ａｔ０の呼び出しに起因する関数ａｔ０及び後述する関数ａｔ１の再帰的な呼び出し回数が所定の回数に到達していないかを判定する。Ｎ_ｃａｌｌの値が所定の閾値より小さい場合、ステップＳ２０３において、引数として与えられたポインタによって指定されるｕｎｉｔのｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ０をローカル変数ｂに指定し、ローカルポインタ変数ＬＰをｌｉｓｔ［ｂ］とする。

ステップＳ２０４及びＳ２０５では、ポインタＬＰがＮＵＬＬでなく、かつ、ポインタＬＰによって指定されるｕｎｉｔのｓｉｎｇｌｅｔｏｎ＿ｆｌａｇが"ｔｒｕｅ"に設定されているかを判定する。当該判定が成立することは、過去のエントリ登録要求に対してこのｎｕｉｔがシングルトンに選択されており、今回の更新対象となったｕｎｉｔの値を用いてエンコードが行われていることを示している。このため、ステップＳ２０６では、ポインタＬＰによって指定されるｕｎｉｔのｄａｔａ値と、関数ａｔ０の引数として与えられている今回シングルトンとして選択したｕｎｉｔのｄａｔａ値との排他的論理和を演算し、演算した値によってポインタＬＰに指定されるｕｎｉｔのｄａｔａ値を更新する。

ステップＳ２０７では、ポインタＬＰによって指定されるｕｎｉｔのｐｒｅｖポインタがＮＵＬＬかどうかを判定する。ここで、ＬＰによって指定されるｕｎｉｔのｐｒｅｖポインタがＮＵＬＬでないことは、このｕｎｉｔのｄａｔａ値が過去に読み出されたうえ、（１）式によるエンコード値の算出に用いられて、他のいずれかのリンクリストに連結されたｕｎｉｔのｄａｔａ値として書き込まれた履歴があることを示している。つまり、さらに遡って、他のｕｎｉｔのｄａｔａ値を修正する必要があることを意味している。このため、ステップＳ２０８及びＳ２０９では、関数ａｔ０及び後述する関数ａｔ１を再帰的に呼び出して実行する。

なお、関数ａｔ０の終了条件は、（１）ステップＳ２０２でＮ_ｃａｌｌが閾値以上となること、（２）ステップＳ２０４でポインタＬＰがＮＵＬＬであると判定すること、（３）ステップＳ２０５でポインタＬＰによって指定されるｕｎｉｔのｓｉｎｇｌｅｔｏｎ＿ｆｌａｇが"ｆａｌｓｅ"であると判定すること、及び（４）ステップＳ２０７でポインタＬＰによって指定されるｕｎｉｔのｐｒｅｖポインタがＮＵＬＬとなること、のうちのいずれか１つが成立することである。

図６に戻って、ステップＳ１１３では、Ｎ_ｃａｌｌの値が所定の閾値より小さいか否かを判定する。ステップＳ１１４では、再び、関数ａｔ０及びａｔ１のループ処理Ａ内での呼び出し回数を示す変数Ｎ_ｃａｌｌを０に初期化する。ステップＳ１１５では、関数ａｔ１を実行する。関数ａｔ１の呼び出し時に与えられる引数は、ｐｒｅｖポインタの値、及び今回シングルトンとして選択したｕｎｉｔのｄａｔａ値、つまりステップＳ１０７で書き込んだＶ（ｔ）値である。関数ａｔ１の処理内容を図８に示す。

なお図７に示した関数ａｔ０の処理内容と、図８に示す関数ａｔ１の処理内容との相違点は、ステップＳ３０３において、引数として与えられたポインタによって指定されるｕｎｉｔのｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ１をローカル変数ｂに指定する点である。つまり、対象とするｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓが異なることを除いて、関数ａｔ０と関数ａｔ１との処理内容は共通している。このため、図８のステップＳ３０３を除くほかの処理に対しては、図７のフローチャートの対応する処理と同じ符号を付して、詳細な説明を省略する。

図６に戻って、ステップＳ１１６では、Ｎ_ｃａｌｌの値が所定の閾値より小さいか否かを判定する。このようなループ処理Ａを、今回のアクセスでシングルトンとして選択したｕｎｉｔのｐｒｅｖポインタを順に辿りながら、ｐｒｅｖポインタがＮＵＬＬとなるリストの先頭まで繰り返す。このような処理を行うことによって、ループ処理Ａの終了後に得られるリンクリスト配列１２は、最新のエントリ登録要求に基づいてシングルトンに選択したｕｎｉｔへの書き込みを、過去にエンコードされたエントリに対する書込み内容にまで遡って修正された状態となる。

ステップＳ１１８では、ループ処理Ａによって更新済みのリンクリスト配列１２の内容をインデックステーブル９２に転送し、インデックステーブル９２を更新する。

上述したように、本実施の形態にかかるＢｌｏｏｍｉｅｒフィルタ型のネットワークサーチエンジン１では、インデックステーブル９２のソフトウェアイメージであるリンクリスト配列１２を有している。また、リンクリスト配列１２を構成する双方向リンクリストの各々は、ハッシュ演算部９１が演算したハッシュ値によって指定されるインデックステーブル９２の格納領域に対応している。また、双方向リンクリストでは、エントリの登録要求に応じてセットアップ時にインデックステーブル９２の格納領域がアドレスされた履歴を保持している。さらに、新たなエントリの登録要求があった場合には、図５〜図８のフローチャートを用いて説明した手順によってリンクリスト配列１２を更新し、リンクリスト配列１２の更新結果をインデックステーブル９２に反映することとしている。

従来のネットワークサーチエンジン９では、登録エントリ集合が与えられた場合に、集合に含まれるエントリに対する順序Γを決定し、順序Γに従って順番にエントリのエンコードを行う必要があった。これに対して、本実施の形態のネットワークサーチエンジン１は、上述した構成及び処理を採用することによって、順序Γに拘束されることなく、登録要求の発生順序に応じて逐次的に新たなエントリを登録することが可能である。

以下では、本実施の形態のネットワークサーチエンジン１によって新たなエントリの逐次登録が可能となる理由を詳細に説明する。従来のネットワークサーチエンジン９では、いわゆる欲張り法のアルゴリズムに従って、後から登録されるエントリのエンコード値Ｖ（ｔ）の格納場所が、それより以前に登録されるエントリのＫ個のハッシュ値のいずれによっても指定されないように、つまり以前の登録エントリに対してシングルトンとなるように登録順序Γを決定している。

このような順序Γを決定することなく、登録要求のあったエントリを逐次登録するときの第１の問題は、過去の登録エントリに使用されていないエントリの格納場所（インデックステーブルメモリ）をどのように選択するかということである。本実施の形態では、過去に他のエントリの格納場所として選択されたか否かを示す識別情報、具体的にはｓｉｎｇｌｅｔｏｎ＿ｆｌａｇを保持し、これを参照することによって、過去のエントリのエンコード値Ｖ（ｔ）の格納場所と新たな登録エントリの格納場所が衝突しないことを保証している。これにより、上記の第１の問題を解決している。

また、順序Γによらずにエントリを逐次登録するときの第２の問題は、新たなエントリに対するＫ個のハッシュ値の中に、過去の登録エントリに対してシングルトンとなるハッシュ値が含まれることは保証されていない点である。つまり、新たなエントリのエンコード値Ｖ（ｔ）の格納場所として選択したハッシュ値がシングルトンでなければ、過去の登録エントリに遡って、インデックステーブル９２の格納値（エンコード値）の更新が必要となる点が問題である。

本実施の形態では、過去に登録されたエントリに対するＫ個のハッシュ値によって参照されたかどうかを示す識別情報、具体的にはａｃｃｅｓｓ＿ｃｏｕｎｔを保持し、これを参照することによって、新たなエントリに対するハッシュ値が過去のエントリに対してシングルトンである否かを判定することができる。さらに、過去のエントリに対するハッシュ値に基づいてあるメモリアドレスがアクセスされたときの他の（Ｋ−１）個のハッシュ値を、ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓとしてリンクリストの中に保持しいている。これにより、ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓに記録されたハッシュ値、つまりメモリアドレスの値を参照することにより、過去の登録エントリに遡って、エンコード値の更新を行うことができる。これにより、上記の第２の問題を解決している。

つまり、本発明は、インデックステーブルの登録場所ごとの更新履歴を記録した履歴情報を有している。履歴情報には、インデックステーブルの登録場所ごとの格納値（ｄａｔａ）、過去に他のエントリの格納場所として選択されたか否かを示す識別情報（ｓｉｎｇｌｅｔｏｎ＿ｆｌａｇ）、過去のエントリに対するハッシュ値によって参照されたかを示す識別情報（ａｃｃｅｓｓ＿ｃｏｕｎｔ）、及び、登録エントリに対するハッシュ値に基づいてある登録場所がアクセスされたときの他の（Ｋ−１）個のハッシュ値（ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ０／１／・・／（Ｋ−２））、が少なくとも含まれる。このような履歴情報をインデックステーブルの登録場所ごとに保持することによって、新たなエントリの逐次登録が可能となる。

なお、図６のフローチャートでは、ステップＳ１１３及びＳ１１６の判定、つまり、関数ａｔ０又はａｔ１が終了したときのこれらの関数の繰り返し実行回数が所定の閾値以上となっている場合には、登録対象のエントリｔを検索処理部１１２に登録することとしている（ステップＳ１１９）。

関数ａｔ０及びａｔ１の再帰呼び出し回数が大きくなると、登録処理を行う際の作業領域として使用されるメモリ量が大きくなる。登録処理によって浪費されるメモリ量が大きくなると、エントリ登録部１１において登録処理を実行するソフトウェアの暴走を招く原因となる。このため、本実施の形態では、関数ａｔ０及びａｔ１の呼び出し回数の最大数に制限を加え、所定の制限回数を超えて呼び出された場合には、それまでのリンクリスト配列１２の更新をキャンセルしたうえで、登録要求のあったエントリは別の検索処理部１１２に登録することとしている。

従来のネットワークサーチエンジン９では、順序Γを決定する手順において、ハッシュ値の衝突のためにシングルトンの記憶をクリアしたうえで順序Γの決定処理を繰り返す手順が何回発生するかが不確定であり、また、順序Γを決定する手順の終了が保証されていないという問題、つまりセットアップの収束性が保証されていないという問題があった。

これに対して、本実施の形態のネットワークサーチエンジン１は、関数ａｔ０及びａｔ１の呼び出し回数を制限することによって、新たなエントリ登録要求に基づくセットアップ処理の収束性を保証することができる。

なお、従来のネットワークサーチエンジン９に対して、ハッシュ演算部９１〜比較部９６によるアドレス検索機構に並行して別のアドレス検索機構を設けることとし、ハッシュ演算部９１〜比較部９６によるアドレス検索機構をセットアップした後に得られた新たなエントリは、別のアドレス検索機構に格納していき、新たなエントリの数が大きくなった時点で、上述したセットアップ手順を実行し、新たなエントリも含めて全てのエントリをインデックステーブル９２にエンコードすることが考えられている。しかしながら、この場合には、新たなエントリを全て別のアドレス検索機構に格納する必要があるため、別のアドレス検索機構の規模（エントリ数、アドレス検索速度）を十分大きくしておく必要があった。

これに対して、本実施の形態のネットワークサーチエンジン１が備える予備的な検索機構である第２検索処理部１３の規模は、ハッシュ演算部９１〜比較部９６によって実現される第１検索処理部１０に比べて十分小さい規模でよい。第２検索処理部１３に登録されるエントリは、インデックステーブル９２への登録に適さない特異なエントリのみであって、殆どのエントリはインデックステーブル９２へ登録されるためである。

以上の説明は、ハッシュ演算部９１に適用されるハッシュ関数の数Ｋ、言い換えると、１つのエントリに対して算出されるハッシュ値の数Ｋを３とした場合について行った。しかしながら、Ｋの値は任意の数を選択することが可能である。一般に、ハッシュ関数の数がＫである場合は、ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓの数が（Ｋ−１）個であるから、関数ａｔ０及びａｔ１の２つの関数の呼び出しに代えて、ｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓの値を変更した（Ｋ−１）個の関数を呼び出すこととすればよい。

その他の実施の形態．
発明の実施の形態１では、インデックステーブル９２のソフトウェアイメージを、双方向リンクリストの配列によって保持することとした。しかしながら、上述したエントリの登録処理を実行するためには、エントリの登録要求に応じてセットアップ時にインデックステーブル９２の格納領域がアドレスされた履歴、その時のｎｅｉｇｈｂｏｒ＿ａｄｄｒｅｓｓ、インデックステーブル９２の格納領域の格納値、及び、インデックステーブル９２の格納領域の各々（つまり、これらの格納領域を指定するハッシュ値）がシングトンとして選択されていることを示す識別情報を保持可能であればよい。このため、他の配列構造などによってインデックステーブル９２のソフトウェアイメージを保持してもよい。

また、発明の実施の形態１にかかるネットワークサーチエンジン１におけるインデックステーブル９２は、ハッシュ関数毎に分割したＫ個のメモリ群として構成することも可能である。このような構成であれば、Ｋ個のハッシュ値によってインデックステーブル９２を同時にアクセス可能であり、アドレス検索処理を高速化できる。なお、この場合には、リクリスト配列１２を構成するリンクリストを、ハッシュ関数番号とハッシュ値によって指定することとすればよい。

さらに、本発明は上述した実施の形態のみに限定されるものではなく、既に述べた本発明の要旨を逸脱しない範囲において種々の変更が可能であることは勿論である。

本発明にかかるＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンの構成図である。 本発明にかかるネットワークサーチエンジンが有するリンクリスト配列を示す図である。 リンクリスト配列を構成する双方向リンクリストを示す図である。 双方向リンクリストを構成するｕｎｉｔのデータ部に格納されるデータの構造を示す図である。 本発明にかかるＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンにおけるエントリ登録処理を示すフローチャートである。 本発明にかかるＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンにおける、エントリ登録処理を示すフローチャートである。 本発明にかかるＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンにおける、エントリ登録処理を示すフローチャートである。 本発明にかかるＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンにおける、エントリ登録処理を示すフローチャートである。 従来のＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンの構成図である。 従来のＢｌｏｏｍｉｅｒフィルタ型ネットワークサーチエンジンにおけるエントリ登録処理を示すフローチャートである。

符号の説明

１ ネットワークサーチエンジン
１０ 第１検索処理部
１１ エントリ登録部
１２ リンクリスト配列
１３ 第２検索処理部
９１ ハッシュ演算部
９２ インデックステーブル
９３ 論理演算部
９４ フィルタリングテーブル
９５ リザルトテーブル
９６ 比較部

Claims (10)

1. 入力データと出力データを対応付ける複数のエントリ情報を保持し、入力された入力データに対応する出力データを前記複数のエントリ情報から検索して出力するＢｌｏｏｍｉｅｒフィルタ型の第１の検索処理部と、
   新たなエントリ情報の登録要求に応じて、前記第１の検索処理部に新たなエントリ情報を登録するエントリ登録部とを備える情報検索装置であって、
   前記第１の情報検索部は、
   入力データを用いてＫ個のハッシュ値を生成するハッシュ演算部と、
   前記ハッシュ演算部が生成するハッシュ値によってアドレスされ、前記エントリ情報の関連情報がエンコードされたエンコード値を格納するための複数の格納領域を有するインデックステーブルと、
   前記ハッシュ演算部が生成したハッシュ値によってアドレスされる格納領域に格納された前記エンコード値を用いて前記関連情報を復元する第１演算部と、
   前記第１演算部が復元した前記関連情報によってアドレスされ、前記複数の出力データを格納するための格納領域を有するリザルトテーブルとを備え、
   前記エントリ登録部は、
   前記インデックステーブルの複数の格納領域の各々についての更新履歴を記録した履歴情報を格納する記憶部を有し、
   前記新たなエントリ情報に対する新たなエンコード値を格納するための前記インデックステーブルの格納領域を、前記履歴情報に基づいて決定するとともに、
   過去に登録済みの前記エントリ情報に対する前記エンコード値の更新値を、前記履歴情報に基づいて生成し、
   前記新たなエンコード値及び前記エンコード値の更新値によって前記インデックステーブルを更新する、情報検索装置。
2. 前記履歴情報は、
   前記インデックステーブルの格納領域ごとの格納値と、
   過去に登録済みの前記エントリ情報に対する前記エンコード値の格納場所として選択されたか否かを示す第１の識別情報と、
   過去に登録済みの前記エントリ情報に対する前記Ｋ個のハッシュ値によって参照されたかを示す第２の識別情報と、
   過去に登録済みの前記エントリ情報に対するハッシュ値に基づいて当該格納領域がアクセスされたときの他の（Ｋ−１）個のハッシュ値と、
   を含む請求項１に記載の情報検索装置。
3. 前記エントリ登録部は、前記第２の識別情報に基づいて、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新が必要であるか否かを判定する請求項２に記載の情報検索装置。
4. 前記履歴情報は、前記インデックステーブルの格納領域毎に定義されたリンクリストによって保持され、
   前記エントリ登録部は、前記新たなエントリ情報に対するハッシュ値によってアドレスされるリンクリストに、前記新たなエントリ情報に関する履歴を格納したユニットを連結することによって、前記履歴情報を更新する請求項１又は２に記載の情報検索装置。
5. 前記エントリ登録部による前記エンコード値の更新値の生成は、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新が必要であるか否かを判定する処理と、前記判定処理の結果に応じて前記エンコード値の更新値を生成する処理とを実行する関数プログラムを再帰的に実行することにより行う請求項１に記載の情報検索装置。
6. 前記第１の検索処理部と並列に設けられた第２の検索処理部をさらに備え、
   前記エントリ登録部は、前記エンコード値の更新値を生成する処理が所定の処理量で収束するか否かを判定し、所定の処理量で収束しない場合は、前記新たなエントリ情報を前記第２の検索処理部に登録する請求項１又は５に記載の情報検索装置。
7. 入力データと出力データを対応付ける複数のエントリ情報を保持し、入力された入力データに対応する出力データを前記複数のエントリ情報から検索して出力するＢｌｏｏｍｉｅｒフィルタ型の第１の検索処理部を備える情報検索装置に対して、新たなエントリ情報を登録する登録方法であって、
   前記第１の情報検索部は、
   入力データを用いてＫ個のハッシュ値を生成するハッシュ演算部と、
   前記ハッシュ演算部が生成するハッシュ値によってアドレスされ、前記エントリ情報の関連情報をエンコードしたエンコード値を格納するための複数の格納領域を有するインデックステーブルとを備えるものであり、
   前記新たなエントリ情報の登録は、
   前記情報検索装置が、前記新たなエントリ情報に対する新たなエンコード値を格納するための前記インデックステーブルの格納領域を、前記インデックステーブルの複数の格納領域の各々についての更新履歴を記録した履歴情報に基づいて決定し、
   前記情報検索装置が、前記新たなエントリ情報に対する新たなエンコード値を生成し、
   前記情報検索装置が、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新値を、前記履歴情報に基づいて生成し、
   前記情報検索装置が、前記新たなエンコード値及び前記エンコード値の更新値によって前記インデックステーブルを更新することにより行う、エントリ情報登録方法。
8. 前記履歴情報は、
   前記インデックステーブルの格納領域ごとの格納値と、
   過去に登録済みの前記エントリ情報に対する前記エンコード値の格納場所として選択されたか否かを示す第１の識別情報と、
   過去に登録済みの前記エントリ情報に対する前記Ｋ個のハッシュ値によって参照されたかを示す第２の識別情報と、
   過去に登録済みの前記エントリ情報に対するハッシュ値に基づいて当該格納領域がアクセスされたときの他の（Ｋ−１）個のハッシュ値と、
   を含む請求項７に記載のエントリ情報登録方法。
9. 前記情報検索装置が、前記エンコード値の更新値の生成の前に、前記第２の識別情報に基づいて、過去に登録済みの前記エントリ情報に対する前記エンコード値の更新が必要であるか否かを判定する請求項８に記載のエントリ情報登録方法。
10. 前記情報検索装置が、前記履歴情報を、前記インデックステーブルの格納領域毎に定義されたリンクリストによって保持し、
    前記情報検索装置が、前記新たなエントリ情報に対するハッシュ値によってアドレスされるリンクリストに、前記新たなエントリ情報に関する履歴を格納したユニットを連結することによって、前記履歴情報の更新を行う請求項７又は８に記載のエントリ情報登録方法。

Images