JP5142705B2 - 画像検索装置 - Google Patents

画像検索装置 Download PDF

Info

Publication number
JP5142705B2
JP5142705B2 JP2007341547A JP2007341547A JP5142705B2 JP 5142705 B2 JP5142705 B2 JP 5142705B2 JP 2007341547 A JP2007341547 A JP 2007341547A JP 2007341547 A JP2007341547 A JP 2007341547A JP 5142705 B2 JP5142705 B2 JP 5142705B2
Authority
JP
Japan
Prior art keywords
key
image
feature
management table
index
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2007341547A
Other languages
English (en)
Other versions
JP2009163466A (ja
Inventor
卓 反橋
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sharp Corp
Original Assignee
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sharp Corp filed Critical Sharp Corp
Priority to JP2007341547A priority Critical patent/JP5142705B2/ja
Publication of JP2009163466A publication Critical patent/JP2009163466A/ja
Application granted granted Critical
Publication of JP5142705B2 publication Critical patent/JP5142705B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Processing Or Creating Images (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

本発明は、指定された画像に類似する画像を検索する画像検索装置に関する。
検索作業者が指定した画像に類似している画像を、例えばファイルサーバに蓄積された複数枚の画像の中から検索するために、各画像を複数の閉じた図形に分割し、分割した図形夫々の重心点を利用する手法が考えられている。
この手法では、図形の重心点の近傍に存在する複数個の点（例えば６個の点。以下、この点を近傍点という）を適宜に抽出し、抽出した６個の近傍点の内から２個の近傍点を選び出す１５種類の組合せ（∵6Ｃ2 ＝１５)について、重心点から２個の近傍点夫々までの距離の比を数列とした量が、この図形の特徴を数値的に示す特徴量として用いられる。この特徴量は相似不変量であるため、図形（延いては画像）の相似変換に耐性がある。同様にして、全ての図形夫々について特徴量が算出され、算出された全ての図形の特徴量が、画像の特徴量として用いられる。
画像を検索する画像検索装置は、検索作業者が指定した指定画像の特徴量と、ファイルサーバに蓄積された複数枚の蓄積画像夫々の特徴量とを比較し、指定画像の特徴量に一致する特徴量を多数有する蓄積画像が、指定画像に類似する類似画像（例えば同一の原稿を元にした画像、又は部分的に同一の形状を含む画像等）であると判断し、この類似画像を表示する。即ち、画像検索装置は、画像の特徴量を用いたマッチングによる検索結果を出力する。
ところで、この手法では、抽出された複数個の近傍点の何れかが、光学機器又は画像の汚れ等に起因するノイズである可能性がある。このようなノイズに対する耐性を強くするために、抽出すべき近傍点の個数を増加させ（例えば７個に増加させ）、７個の近傍点の内の１個をノイズであると仮定した残り６個の近傍点の組合せ７種類について夫々図形の特徴量を算出することによって、画像の特徴量を７倍冗長にする手法が考えられている。
以上のようにして算出される画像の特徴量は、１枚の画像当たり７千個を超えることがあり、各特徴量は２０バイト程度のデータ長を有する。このため、画像を検索する際に、データ長が長い特徴量同士の比較を多数回実行する必要があり、検索速度が遅くなる傾向がある。
従来、ハッシュ法を用いて特徴量同士の比較回数を減らすことによって、検索速度を高速化する手法が行われている。この手法では、例えば指定画像及び蓄積画像夫々の各特徴量をハッシュ関数によってハッシュ値（即ち所定のデータ長を有する整数）に射影し、指定画像の特徴量と比較すべき蓄積画像の特徴量を、指定画像のハッシュ値と同一のハッシュ値を有する特徴量のみに絞込んでから、特徴量を用いたマッチングが行なわれる。
ところが、この手法では、検索の際、蓄積画像の特徴量についてハッシュ値毎にリスト形式のデータ構造を生成する必要があり、一般にはこのデータ構造はＲＡＭに一時的に記憶される。従って、この手法は、蓄積画像の枚数が少ない場合には実用的であるが、多数枚の蓄積画像（たとえば１０万枚）に対して検索を行なう場合には適さない。何故ならば、１０万枚の蓄積画像のデータ構造を記憶するためには、管理用の情報を無視して少なく見積もっても、１０万枚×７千個×２０バイト＝１４ギガバイトの記憶容量を有するＲＡＭが必要になるからである。また、このデータ構造を、ＲＡＭの代わりに例えばハードディスクのような二次記憶装置に一時的に記憶させると、データの読み書きに時間が掛かり、検索速度が遅くなる。
１０万枚の蓄積画像に関する１０万枚×７千個＝７億個の特徴量を取り扱うための手法として、リレーショナル・データベースを用いる手法が存在する。
この手法を用いる場合、１０万枚の蓄積画像を識別すべく、例えば４バイトのデータ長を有する整数が識別情報（以下、画像ＩＤという）として各蓄積画像に付与され、この画像ＩＤと、２０バイトのデータ長を有する数列（以下、２０バイト数列という）で表される特徴量とが関連付けられて画像を管理する画像管理テーブルに登録される。
画像管理テーブルの各レコードには、２つのフィールド（具体的には、画像ＩＤを格納するＩＤフィールドと特徴量を格納する特徴量フィールドと）が関連付けて設けられている。このため、１枚の蓄積画像につき７千件のレコードが登録され、１０万枚の蓄積画像を登録すると、画像管理テーブルには７億件のレコードが登録されることになる。
このような画像管理テーブルを用いて蓄積画像の中から指定画像の類似画像を探し出す場合、指定画像の７千個の特徴量の内の１個が選択され、選択された特徴量に等しい特徴量に関連付けられている画像ＩＤが７億件のレコードの中から１又は複数特定され、特定された画像ＩＤに関連付けて投票される。ここで、投票とは、蓄積画像が指定画像に類似している度合いを数値的に示す類似度を１度数インクリメントすることである。以下では、この類似度を投票数という。このような手順が、指定画像の全ての特徴量について、７千回繰り返される。
指定画像に類似している蓄積画像の画像ＩＤの投票数は、指定画像に類似していない蓄積画像の画像ＩＤに対する投票数より多くなるため、最も投票数が多い画像ＩＤを有する蓄積画像が、指定画像に最も類似している類似画像であると判断される。
従来、蓄積画像と蓄積画像の特徴量とを関連付けて管理しておき、指定画像に類似した類似画像を容易に得るために、指定画像の特徴量に検索の曖昧度を設定して、曖昧度が設定された特徴量に対応する特徴量に関連付けられている画像ＩＤを特定し、特定された画像ＩＤに投票することによって類似画像を探し出す画像検索装置が提案されている（特許文献１参照）。
特開平１１−３０６２０１号公報
ところが、指定画像の２０バイト数列の特徴量と、７億件のレコードに格納されている２０バイト数列の特徴量とを比較して、一致する特徴量を特定し、画像ＩＤに投票する処理には、数ミリ秒〜数十ミリ秒の演算時間が必要とされ、この処理を７千回実行することによって、数秒〜数分という長い演算時間が必要とされ、この結果、画像の検索のための検索時間が長くなるという不都合がある。
しかしながら、検索時間を短縮するためには、演算能力が非常に高い演算部、及び記憶容量が大きい一次記憶装置等の高価な計算資源を用いる必要があるため、十分なコストパフォーマンスが得られないという問題がある。
特許文献１には、検索時間を短縮するために事前検索を実行して、指定画像と比較すべき蓄積画像の枚数を限定する手法が開示されているが、データ長が長い特徴量同士の比較を多数回実行することには代わりがないため、大幅な時間短縮は望めないと考えられる。
本発明は斯かる事情に鑑みてなされたものであり、その主たる目的は、画像の識別情報と特徴量とを、特徴量よりも情報量が少ないインデックスキーを介して関連付け、特徴量同士を比較する代わりにインデックスキー同士を比較する構成とすることにより、安価な計算資源を用いても、検索時間を短縮することができる画像検索装置を提供することにある。
本発明に係る画像検索装置は、指定された画像に類似する画像を、リレーショナル・データベースを用いて検索する検索手段を備える画像検索装置において、前記リレーショナル・データベースは、画像を蓄積する蓄積部に蓄積されている画像、及び該画像を識別する識別情報が関連付けられている蓄積管理テーブルと、画像の特徴を数値的に示す特徴量、及び該特徴量よりも情報量が少ないインデックスキーが関連付けられているキー管理テーブルと、識別情報、及び該識別情報を有する画像の特徴量に対応するインデックスキーが関連付けられている特徴管理テーブルとを有し、前記検索手段は、前記指定された画像の特徴量に対応するインデックスキーと、前記蓄積部に蓄積されている画像の特徴量に対応するインデックスキーとを用いて、前記指定された画像に類似する画像を検索するようにしてあり、前記蓄積管理テーブル、前記キー管理テーブル、及び／又は前記特徴管理テーブルを参照して、前記指定された画像の特徴量に対応するインデックスキーを探し出す特徴キー探索手段と、前記特徴管理テーブルを参照して、前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、前記指定された画像と前記蓄積部に蓄積されている画像との類似度を算出する類似度算出手段と、該類似度算出手段が算出した類似度の高低に基づいて、前記指定された画像に類似する画像の識別情報を選択する画像選択手段と、前記蓄積管理テーブルを参照して、前記画像選択手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を検索結果として、前記検索手段による検索結果を表示する表示部へ出力する結果出力手段とを有し、前記リレーショナル・データベースに画像を登録する画像登録手段を更に備え、該画像登録手段は、前記リレーショナル・データベースに登録すべき画像を前記蓄積部に蓄積させる蓄積制御手段と、前記画像に基づいて、該画像の特徴量を算出する特徴算出手段と、前記画像に対して識別情報を発行する情報発行手段と、該情報発行手段が発行した識別情報、及び前記蓄積制御手段が前記蓄積部に蓄積した画像を関連付けて前記蓄積管理テーブルに登録する蓄積管理登録手段と、前記キー管理テーブルを参照し、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されているか否かを判定する登録判定手段と、該登録判定手段が否と判定した場合、前記特徴量に対し、該特徴量よりも情報量が少ないインデックスキーを発行するキー発行手段と、該キー発行手段が発行したインデックスキー、及び前記特徴量を関連付けて前記キー管理テーブルに登録するキー管理登録手段と、前記識別情報、及び前記特徴量に関連付けて前記キー管理テーブルに登録されているインデックスキーを関連付けて前記特徴管理テーブルに登録する特徴管理登録手段とを有し、前記特徴管理テーブルの各レコードには、識別情報を格納する識別情報フィールドと、互いに異なるフィールド値が付与されており、夫々インデックスキーを格納するＭ（Ｍは２以上の自然数）個のキーフィールドとが関連付けて設けてあり、前記特徴管理登録手段は、インデックスキーをフィールド値に対応させるハッシュ関数、及び前記特徴管理テーブルに登録すべきインデックスキーに基づいて算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、前記インデックスキーを格納する手段と、互いにハッシュ値が等しい前記インデックスキーが複数存在する場合は、前記インデックスキー夫々を、異なるレコードのキーフィールドに格納する手段と、インデックスキーが格納されているキーフィールド及び格納されていないキーフィールドを有するレコードに関し、インデックスキーが格納されていないキーフィールドに、インデックスキーが格納されていないことを示すキー未格納情報を格納する手段とを有し、前記類似度算出手段は、前記ハッシュ関数、及び前記特徴キー探索手段が探し出したインデックスキーに基づいて算出されたハッシュ値に基づいて、前記特徴管理テーブルの前記ハッシュ値に等しいフィールド値が付与されているキーフィールドを特定する手段と、該手段が特定したキーフィールドに格納されているインデックスキーの内の前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて類似度を算出する手段とを有することを特徴とする。
本発明に係る画像検索装置は、各インデックスキーは、少なくとも前記類似度算出手段として機能する演算部が１つの命令で演算可能なデータ長を有することを特徴とする。
本発明に係る画像検索装置は、少なくともキー管理テーブル及び特徴管理テーブルの組が複数設けられており、一の組のキー管理テーブル及び特徴管理テーブルを用いて、前記特徴キー探索手段がインデックスキーを探索し、前記類似度算出手段が類似度を算出するようにしてあり、前記検索手段は、前記一の組のキー管理テーブルを参照して、前記指定された画像の特徴量に対応するインデックスキーに基づいて前記指定された画像の特徴量を探し出す手段を更に有し、該手段が探し出した前記指定された画像の特徴量、及び他の組のキー管理テーブル及び特徴管理テーブルを用いて、前記特徴キー探索手段がインデックスキーを探索し、前記類似度算出手段が類似度を算出するようにしてあることを特徴とする。
本発明に係る画像検索装置は、各レコードのキーフィールドに付与されるフィールド値として、“０”以上“Ｍ−１”以下の整数を用いるようにしてあり、各インデックスキーは、整数を用いてなり、前記特徴管理登録手段は、インデックスキーをＭで除算した場合の剰余を求める前記ハッシュ関数、及び前記特徴管理テーブルに登録すべきインデックスキーに基づいて算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、前記インデックスキーをＭで除算した場合の商を格納するようにしてあることを特徴とする。
本発明に係る画像検索装置は、前記特徴管理登録手段は、前記登録判定手段が登録されていると判定した場合、登録されているインデックスキーを優先的にキーフィールドに格納するようにしてあり、前記キー発行手段は、前記特徴管理登録手段が前記インデックスキーを格納した後で、インデックスキーが未格納であるキーフィールドのフィールド値に等しいハッシュ値を有するインデックスキーの内、該インデックスキーに関連付けて前記キー管理テーブルに特徴量が登録されていないインデックスキーを発行するようにしてあることを特徴とする。
本発明に係る画像検索装置は、インデックスキー並びに特徴量及び識別情報を新規登録すべきキー管理テーブル及び特徴管理テーブルの組と、新規登録が終了しているキー管理テーブル及び特徴管理テーブルの組とが設けられており、前記キー発行手段は、前記新規登録が終了しているキー管理テーブルを参照し、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが登録されているか否かを判定する手段と、該手段が登録されていると判定した場合、登録されているインデックスキーのハッシュ値に等しいハッシュ値を有するインデックスキーを発行する手段とを有し、前記画像登録手段は、前記新規登録すべきキー管理テーブル及び特徴管理テーブルに対する新規登録が終了した後で、前記新規登録すべきキー管理テーブルに登録されている特徴量に一致する特徴量が、前記新規登録が終了しているキー管理テーブルに登録されているか否かを判定する第１手段と、該第１手段が登録されていると判定した場合、前記新規登録すべきキー管理テーブルに登録されているインデックスキーを、前記特徴量に関連付けて前記新規登録が終了しているキー管理テーブルに登録されているインデックスキーに対応付ける第２手段と、前記第１手段が否と判定した場合、登録されていないと判定された特徴量に関連付けて前記新規登録すべきキー管理テーブルに登録されているインデックスキーのハッシュ値に等しいハッシュ値を有し、しかも、前記新規登録が終了しているキー管理テーブルにて特徴量に関連付けられていないインデックスキーを発行する第３手段と、該第３手段が発行したインデックスキー、及び前記特徴量を関連付けて前記新規登録が終了しているキー管理テーブルに登録する第４手段と、前記新規登録すべきキー管理テーブルに登録されているインデックスキーを、前記第３手段が発行したインデックスキーに対応付ける第５手段と、前記新規登録すべき特徴管理テーブルに登録されている識別情報及びインデックスキーを、該インデックスキーを前記第２手段及び／又は第５手段によって対応付けられているインデックスキーに変換して、前記新規登録が終了しているキー管理テーブル及び特徴管理テーブルに登録する第６手段とを更に有することを特徴とする。
本発明に係る画像検索装置は、前記キー管理テーブルは、画像の特徴量又は画像に付属する付属情報と、少なくとも前記特徴量よりも情報量が少ないインデックスキーとが関連付けられるようにしてあり、前記検索手段は、前記蓄積管理テーブル、前記キー管理テーブル、及び／又は前記特徴管理テーブルを参照して、指定された付属情報に対応するインデックスキーを探し出す情報キー探索手段と、前記特徴管理テーブルを参照して、前記情報キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、付属情報が一致していることを示す一致情報を付与する情報付与手段とを更に有し、前記結果出力手段は、前記蓄積管理テーブルを参照して、前記画像選択手段が選択した識別情報の内、前記情報付与手段が一致情報を付与した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得するようにしてあり、前記画像登録手段は、前記キー管理テーブルを参照し、前記リレーショナル・データベースに登録すべき画像の付属情報に関連付けてインデックスキーが既に登録されているか否かを判定する第２の登録判定手段と、該第２の登録判定手段が否と判定した場合、前記付属情報に対してインデックスキーを発行する第２のキー発行手段と、該キー発行手段が発行したインデックスキー、及び前記付属情報を関連付けて前記キー管理テーブルに登録する第２のキー管理登録手段と、前記情報発行手段が発行した識別情報、及び前記付属情報に関連付けて前記キー管理テーブルに登録されているインデックスキーを関連付けて前記特徴管理テーブルに登録する第２の特徴管理登録手段とを更に有することを特徴とする。
本発明に係る画像検索装置は、互いに通信可能な複数の計算機を用いてなり、各計算機は、前記蓄積部、前記リレーショナル・データベースが有する各種管理テーブル、前記検索手段が有する各手段、前記表示部、前記画像登録手段が有する各手段の内の１つ以上を備えることを特徴とする。
本発明に係る画像検索装置は、前記キー管理テーブルには、関連付けられているインデックスキー及び特徴量に更に関連付けて、該特徴量を有する画像の枚数を示す枚数情報が登録されるようにしてあり、前記キー管理登録手段は、インデックスキー及び特徴量を関連付けて前記キー管理テーブルに登録する際に、前記枚数情報を登録するようにしてあり、前記類似度算出手段は、前記特徴キー探索手段が探し出したインデックスキーの内、前記キー管理テーブルにて前記インデックスキーに一致するインデックスキーに関連付けられている枚数情報が示す枚数が所定枚数以上であり、且つ、前記枚数が最も少ないインデックスキーから枚数の少なさの順にインデックスキーを特定する手段と、前記特徴管理テーブルを参照して、前記手段が特定したインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて類似度を算出する手段とを有し、前記画像登録手段は、前記登録判定手段が、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されていると判定した場合、登録されているインデックスキーに関連付けられている枚数情報を増加させる枚数計数手段を更に有することを特徴とする。
本発明に係る画像検索装置は、前記画像選択手段は、暫定的に、前記類似度算出手段が算出した類似度が所定類似度以上に達した識別画像を選択する第１の手段と、最終的に、前記類似度算出手段が算出した類似度が最も高い識別画像から類似度の高さの順に識別画像を選択する第２の手段とを有し、前記結果出力手段は、前記第１の手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を暫定的な検索結果として前記表示部へ出力する手段と、前記第２の手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を最終的な検索結果として前記表示部へ出力する手段とを有することを特徴とする。
本発明に係る画像検索装置は、前記リレーショナル・データベースから画像の登録を抹消する際、少なくとも前記特徴管理テーブルについて、登録を抹消すべき画像の識別情報に対し、無効を意味する無効情報を付与する無効付与手段を更に備え、前記類似度算出手段は、前記無効情報が付与されている識別情報を除く識別情報の中から、前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定するようにしてあることを特徴とする。
本発明にあっては、検索手段を備える。検索手段は、各種管理テーブルを有するリレーショナル・データベースを用いて、検索作業者によって指定された画像（以下、指定画像という）に類似する画像を検索する。
蓄積部には、画像が蓄積されている。以下では、蓄積部に蓄積されている画像を蓄積画像といい、検索手段は、蓄積画像の中から指定画像に類似する蓄積画像（以下、類似画像という）を検索する。
蓄積管理テーブルにおいては、蓄積画像と、蓄積画像を識別する識別情報とが関連付けられている。
キー管理テーブルにおいては、蓄積画像の特徴を数値的に示す特徴量と、特徴量の索引項目としてのインデックスキーとが関連付けられており、インデックスキーは、蓄積画像の特徴量よりも情報量が少ない。
特徴管理テーブルでは、識別情報と、この識別情報が付与された蓄積画像の特徴量に対応するインデックスキーとが関連付けられている。
つまり、本発明の画像検索装置が用いるリレーショナル・データベースでは、蓄積画像と特徴量とを、識別情報及びインデックスキーを介在して関連付けている。
ここで、「Ａ−Ｂ」という表記を、ＡとＢとの関連付けを意味するものとして用いると、本発明のデータベースでは、「蓄積画像−特徴量」が、「蓄積画像−識別情報」、「識別情報−インデックスキー」及び「インデックスキー−特徴量」の３つに分けて記憶される。一方、従来の画像検索装置が用いるリレーショナル・データベースでは、「蓄積画像−特徴量」が、通常、「蓄積画像−識別情報」及び「識別情報−特徴量」の２つに分けて記憶されるため、見かけ上、本発明のリレーショナル・データベースに必要とされる記憶容量は１．５倍に増加する。
しかしながら、一般には、異なる蓄積画像同士が共通する特徴を有していることが多い。このため、従来のリレーショナル・データベースは、同一の特徴量を繰り返し記憶する必要があるが、本発明のリレーショナル・データベースは、同一のインデックスキーを繰り返し記憶すればよい。従って、蓄積画像の枚数が多くなるほど、従来のリレーショナル・データベースに必要とされる記憶容量と本発明のリレーショナル・データベースに必要とされる記憶容量との差は小さくなる。つまり、本発明のリレーショナル・データベースを導入しても、画像検索装置が備える記憶装置に必要な記憶容量を大幅に増大させる必要はなく、蓄積画像の枚数、種類等によっては、必要な記憶容量が減少することさえ期待される。このように、本発明の画像検索装置は、特に蓄積画像の枚数が多い場合に適している。
検索手段は、指定画像の特徴量に対応するインデックスキーと、蓄積画像の特徴量に対応するインデックスキーとを用いて類似画像を検索する。即ち、検索手段は、情報量が多い特徴量ではなく、情報量が少ないインデックスキー用いて画像を検索する。この結果、検索時間が短縮される。
本発明にあっては、検索手段は、特徴キー探索手段と類似度算出手段と画像選択手段と結果出力手段とを有する。
特徴キー探索手段は、蓄積管理テーブル、キー管理テーブル及び／又は特徴管理テーブルを参照して、指定画像の特徴量に対応するインデックスキーを探し出す。
類似度算出手段は、特徴管理テーブルを参照して、特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定する。つまり類似度算出手段は、指定画像の特徴量に一致する蓄積画像の特徴量を求めることなく、指定画像の特徴量のインデックスキーに一致する蓄積画像の特徴量のインデックスキーを求める。換言すれば、類似度算出手段は、情報量が多い特徴量同士を比較することなく、情報量が少ないインデックスキー同士を比較する。更に類似度算出手段は、求めたインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、指定画像と蓄積画像との類似度を算出する。例えば類似度には初期値が設定され、インデックスキー同士が一致した回数に応じて、類似度の値が、画像同士が類似していることを示す方向に変更される。
インデックスキー同士を比較する際に類似度算出手段が参照すべきテーブルは少ない。何故ならば、類似度算出手段は「識別情報−インデックスキー」の特徴管理テーブルを参照すればよく、「蓄積画像−識別情報」の蓄積管理テーブルと「インデックスキー−特徴量」のキー管理テーブルとを参照する必要はないからである。また、リレーショナル・データベースでは、類似度算出手段によるインデックスキーの比較、識別情報の特定及び類似度の算出は、１つのクエリで実行可能である。
以上の結果、画像を検索するために高い演算能力及び長い演算時間を必要としない。
画像選択手段は、類似度算出手段が算出した類似度の高低（即ち投票数の多寡）に基づいて、類似画像の識別情報を選択する。
結果出力手段は、蓄積管理テーブルを参照して、画像選択手段が選択した識別情報に一致する識別情報に関連付けられている蓄積画像を蓄積部から取得して、取得した蓄積画像を検索結果（即ち類似画像）として表示部へ出力する。
表示部は、結果出力手段から入力された検出結果（即ち検索手段による検索結果）を表示する。検索作業者は、表示部に表示された類似画像を視認して、この類似画像が所望の画像であるか否かを判断する。
本発明にあっては、演算部が１つの命令で演算可能な短いデータ長を有するインデックスキーを用いる。この演算部は、少なくとも、特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定する類似度算出手段として機能する。
このようなインデックスキーを用いる場合、１つの命令では演算不可能な長いデータ長を有するインデックスキーを用いる場合に比べて、インデックスキー同士の比較に要する演算部のサイクル・タイムを短縮することができる。従って、検索時間を更に短縮することができる。
本発明にあっては、少なくともキー管理テーブル及び特徴管理テーブルの組が複数設けられている。例えば一のキー管理テーブル及び特徴管理テーブルの組と、他のキー管理テーブル及び特徴管理テーブルの組とが設けられている。
何故ならば、一般に、キー管理テーブル及び／又は特徴管理テーブルには、各種データを登録可能な上限が存在するため、現在使用されているキー管理テーブル及び／又は特徴管理テーブルが登録の上限に達する直前に、このキー管理テーブル及び特徴管理テーブルを旧い各種管理テーブルとして、新しい各種管理テーブルが生成されるからである。あるいは、一ヶ月毎、半期毎等に、現在使用されているキー管理テーブル及び特徴管理テーブルを旧い各種管理テーブルとして、新しい各種管理テーブルが生成されるからである。
従って、例えば検索作業者によって与えられた指定画像の識別情報と、一の組のキー管理テーブル及び特徴管理テーブルとを用いて、特徴キー探索手段がインデックスキーを探索し、類似度算出手段が類似度を算出する。
また、一の組のキー管理テーブルを参照して、指定画像の特徴量に対応するインデックスキーに基づいて指定画像の特徴量を探し出し、このようにして探し出した指定画像の特徴量と、他の組のキー管理テーブル及び特徴管理テーブルとを用いて、特徴キー探索手段がインデックスキーを探索し、類似度算出手段が類似度を算出する。
最終的に、画像選択手段が識別情報を選択する。
つまり検索手段は、一のキー管理テーブル及び特徴管理テーブル（例えば新しい各種管理テーブル）の組を用いて画像を検索し、インデックスキーと特徴量とを変換及び再変換してから、他のキー管理テーブル及び特徴管理テーブル（この場合は旧い各種管理テーブル）の組を用いて、画像を検索する。このように、検索手段は、２組のキー管理テーブル及び特徴管理テーブル（即ち旧い各種管理テーブルと新しい各種管理テーブルと）にまたがって、画像を検索することができる。同様にして、３組以上のキー管理テーブル及び特徴管理テーブルにまたがって、画像を検索することもできる。
本発明にあっては、リレーショナル・データベースに画像を登録する画像登録手段を更に備え、画像登録手段は、蓄積制御手段と、特徴算出手段と、情報発行手段と、蓄積管理登録手段と、登録判定手段と、キー発行手段と、キー管理登録手段と、特徴管理登録手段とを有する。
まず、蓄積制御手段は、リレーショナル・データベースに登録すべき画像を蓄積部に蓄積させ、特徴算出手段は、リレーショナル・データベースに登録すべき画像（即ち蓄積画像）の特徴量を算出し、情報発行手段は、蓄積画像に対して識別情報を発行する。
次に、蓄積管理登録手段は、情報発行手段が発行した識別情報と蓄積制御手段が蓄積部に蓄積した蓄積画像とを関連付けて蓄積管理テーブルに登録する。
また、登録判定手段は、キー管理テーブルを参照して、特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されているか否かを判定する。登録判定手段が否（即ち同一の特徴量が登録されていない）と判定した場合、キー発行手段は、特徴算出手段が算出した特徴量に対してインデックスキーを発行し、キー管理登録手段は、キー発行手段が発行したインデックスキーと、特徴算出手段が算出した特徴量とを関連付けてキー管理テーブルに登録する。ここで、キー発行手段が発行するインデックスキーは、特徴算出手段が算出した特徴量よりも情報量が少ない。
更に、特徴管理登録手段は、情報発行手段が発行した識別情報と、特徴算出手段が算出した特徴量に関連付けてキー管理テーブルに登録されているインデックスキーとを関連付けて特徴管理テーブルに登録する。更に詳細には、特徴管理登録手段は、登録判定手段が登録されていると判定した場合は、情報発行手段が発行した識別情報と、既に登録されているインデックスキーとを関連付けて特徴管理テーブルに登録する。一方、登録判定手段が否と判定した場合は、特徴管理登録手段は、情報発行手段が発行した識別情報と、新たにキー発行手段が発行してキー管理登録手段が登録したインデックスキーとを関連付けて特徴管理テーブルに登録する。
以上のようにして画像登録手段は、蓄積画像を蓄積し、特徴量の算出と識別情報の発行とを行なし、同一の特徴量を重複して登録してしまう無駄を避けつつ、各種管理テーブルに各種データを登録することができる。
本発明にあっては、特徴管理テーブルの各レコードに、識別情報を格納する識別情報フィールドと、インデックスキーを格納するキーフィールドとが関連付けて設けてある。ただし、識別情報フィールド１個に対してキーフィールドはＭ（Ｍは２以上の自然数）個が関連付けられており、各キーフィールドには、互いに異なるフィールド値が付与されている。
画像登録の際、特徴管理登録手段は、特徴管理テーブルに登録すべきインデックスキーをキーフィールドに格納する場合に、インデックスキーをフィールド値に対応させるハッシュ関数と、登録すべきインデックスキー（以下、登録インデックスキーという）とに基づいてハッシュ値を算出し、算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、登録インデックスキーを格納する。
ただし、互いにハッシュ値が等しい登録インデックスキーが複数存在する場合は、特徴管理登録手段は、登録インデックスキー夫々を、異なるレコードのキーフィールドに格納する。このとき、これらのキーフィールドには、当然、同一のフィールド値が付与されている。
また、一つのレコードに、インデックスキーが格納されているキーフィールドとインデックスキーが格納されていないキーフィールド（以下、空きキーフィールドという）とが存在する場合、特徴管理登録手段は、空きキーフィールドに、インデックスキーが格納されていないことを示すキー未格納情報を格納する。このため、何も格納されていないキーフィールドを有するレコードによってリレーショナル・データベースにエラーが生じることが防止される。
このようにして特徴管理登録手段は、特徴管理テーブルに設けるレコードの件数を低減することができる。このため、レコードの件数が少ない特徴管理テーブルに新たなレコードを挿入するための演算時間を短縮することができ、画像の登録のための登録時間を短縮することができる。
一般に、１枚の蓄積画像の全ての特徴量夫々に関連付けられているインデックスキーのハッシュ値が互いに等しい可能性は低いため、一つのレコードに各１個の識別情報とインデックスキーとが格納される無駄は自然と避けられる。
仮に、一つのレコードに各１個の識別情報フィールドとキーフィールドとが設けられている場合、レコードの件数が多くなるため、このような特徴管理テーブルに新たなレコードを挿入する演算時間は長くなり、画像の登録のための登録時間が長くなる。
画像検索の際、類似度算出手段は、特徴管理登録手段が用いるハッシュ関数と、特徴キー探索手段が探し出したインデックスキーとに基づいてハッシュ値を算出し、算出されたハッシュ値に基づいて特徴管理テーブルのキーフィールドを特定する。ここで特定されるキーフィールドは、算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドである。
次に、類似度算出手段は、ハッシュ値に基づいて特定したキーフィールドに格納されているインデックスキーの内から、特徴キー探索手段が探し出したインデックスキーに等しいインデックスキーを特定し、特定したインデックスキーに関連付けられている識別情報を所要の識別情報として特定し、特定した識別情報に関連付けて類似度を算出する。
つまり、類似度算出手段は、インデックスキー同士の比較を行なう前に、特徴キー探索手段が探し出したインデックスキーのハッシュ値に基づいて、このインデックスキーと比較すべきインデックスキーの絞込みを行なうことができる。この結果、特徴キー探索手段が探し出したインデックスキーと特徴管理テーブルに登録されている全てのインデックスキーとを比較する場合と比べて、検索時間を短縮することができる。
本発明にあっては、特徴管理テーブルの各レコードに、識別情報フィールドと、整数を用いてなるインデックスキーを夫々格納するＭ個のキーフィールドとが関連付けて設けてある。ただし、各キーフィールドには、互いに異なるフィールド値として、“０”以上“Ｍ−１”以下の整数が付与されている。
特徴管理登録手段は、Ｍでインデックスキーを除算した場合の剰余を求めるハッシュ関数を用いる。このハッシュ関数は、類似度算出手段が用いるハッシュ関数と同じものである。
特徴管理登録手段は、このハッシュ関数と登録インデックスキーとに基づいてハッシュ値を算出し、算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、Ｍで登録インデックスキーを除算した場合の商を格納する。この場合の剰余は、キーフィールドのフィールド値に等しい。また、キーフィールドに格納される値の桁数は、インデックスキーの桁数より少ない。
従って、キーフィールドにインデックスキーを格納せずとも、キーフィールドに格納されている値と、キーフィールドに付与されているフィールド値とを用いて、インデックスキーを容易に求めることができる。しかも、キーフィールドに格納すべきデータの情報量を低減することができる。
本発明にあっては、画像登録の際に、登録判定手段が登録されていると判定した場合、特徴管理登録手段は、既にキー管理テーブルに登録されているインデックスキーを優先的にキーフィールドに格納する。このとき、一つのレコードの全てのキーフィールドに夫々インデックスキーが格納されるか、又は、インデックスキーが格納されているキーフィールドと空きキーフィールドとが一つのレコードに生じる。
特徴管理登録手段が、既にキー管理テーブルに登録されているインデックスキーを空きキーフィールドに格納した後で、キー発行手段は、インデックスキーが未格納であるキーフィールド（即ち空きキーフィールド）のフィールド値に等しいハッシュ値を求め、求めたハッシュ値を有するインデックスキーを発行する。ただし、ここで発行すべきインデックスキーは、このインデックスキーに関連付けてキー管理テーブルに特徴量が登録されていないインデックスキーである。この結果、キー発行手段が発行したインデックスキーは、新たなレコード（即ちインデックスキーが全く格納されていないレコード）の空きキーフィールドではなく、既にインデックスキーが格納されているレコードの空きキーフィールドに格納される。
従って、一つのレコードに生じる空きキーフィールドの個数を最低限の個数に抑制することができる。このため、空きキーフィールドが多いレコードが生じてレコードの件数が無駄に増加することを防止することができる。この結果、特徴管理テーブルを設けるための記憶容量を低減することができ、特徴管理テーブルに新たなレコードを挿入する演算時間を短縮することができる。
本発明にあっては、インデックスキー及び特徴量を新規登録すべきキー管理テーブル、並びにインデックスキー及び識別情報を新規登録すべき特徴管理テーブルの組と、新規登録が終了しているキー管理テーブル及び特徴管理テーブルの組とが設けられている。
例えば一ヶ月毎、半期毎等に、現在使用されているキー管理テーブル及び特徴管理テーブルを、新規登録が終了している各種管理テーブル（以下、旧い各種管理テーブルという）とし、次に新規登録すべき各種管理テーブル（以下、新しい各種管理テーブルという）を生成する場合、旧い各種管理テーブルは、まだ登録の上限に達していないことがある。このような各種管理テーブルを用いて画像を検索する場合、多数のキー管理テーブル及び特徴管理テーブルの組にまたがって画像を検索しなければならず、効率が悪い。このため、例えば旧い各種管理テーブルと、更に旧い各種管理テーブルとをマージ（即ち併合）して、各種管理テーブルの組の個数を減らすことが望ましい。
ただし、新しい各種管理テーブルと旧い各種管理テーブルとには、互いに異なるインデックスキーに関連付けて、同一の特徴量が重複して登録されていることがあるため、マージの際には、重複分を削除する必要がある。
このために、画像登録の際、キー発行手段は、旧いキー管理テーブルを参照し、特徴算出手段が算出した特徴量に関連付けてインデックスキーが登録されているか否かを判定し、登録されていると判定した場合、登録されているインデックスキーのハッシュ値に等しいハッシュ値を有するインデックスキーを発行する。
この後、キー管理登録手段は、旧いキー管理テーブルに登録されているインデックスキーのハッシュ値に等しいハッシュ値を有するインデックスキーと、特徴算出手段が算出した特徴量とを関連付けて、新しいキー管理テーブルに登録する。また、特徴管理登録手段は、情報発行手段が発行した識別情報と、旧いキー管理テーブルに登録されているインデックスキーのハッシュ値に等しいハッシュ値を有するインデックスキーとを関連付けて特徴管理テーブルに登録する。
新規登録すべきキー管理テーブル及び特徴管理テーブルに対するインデックスキーの新規登録が終了した後で、即ち新しい各種管理テーブルの新規登録が終了した後で、新規登録が終了した新しい各種管理テーブルは、既に新規登録が終了している旧い各種管理テーブルにマージされる。
このために、画像登録手段は、新規登録が終了した新しいキー管理テーブルに登録されている特徴量に一致する特徴量が、既に新規登録が終了している旧いキー管理テーブルに登録されているか否かを判定する。この特徴量が登録されている場合とは、新規登録が終了した新しいキー管理テーブルと既に新規登録が終了している旧いキー管理テーブルとで重複する特徴量が存在する場合であり、この特徴量に夫々関連付けて新しいキー管理テーブルに登録されているインデックスキー（以下、新インデックスキーという）と旧いキー管理テーブルに登録されているインデックスキー（以下、旧インデックスキーという）とは、互いにハッシュ値が等しい。
従って、重複する特徴量が登録されていると判定した場合、画像登録手段は、新インデックスキーを、旧インデックスキーに対応付ける。更に画像登録手段は、新規登録が終了した新しい特徴管理テーブルに登録されている識別情報及び新インデックスキーを、新インデックスキーをこの新インデックスキーに対応付けられている旧インデックスキーを変換して、既に新規登録が終了している旧い各種管理テーブルに登録する。
以上の結果、既に新規登録が終了している旧い各種管理テーブルに、重複する特徴量が登録されることを防止することができる。
しかも、新インデックスキーと旧インデックスキーとはハッシュ値が等しいため、既に新規登録が終了している旧い特徴管理テーブルにおいて、旧インデックスキーに変換された新インデックスキーを、新規登録が終了した新しい特徴管理テーブルにおいて新インデックスキーが格納されていたキーフィールドのフィールド値に等しいフィールド値を有するキーフィールドに格納することができる。この結果、新旧のインデックスキーの変換によって、各レコード内で、インデックスキーを格納すべきキーフィールドが変化することが防止され、各種管理テーブルを簡易且つ正確にマージすることができる。
重複する特徴量が登録されていないと判定した場合、画像登録手段は、重複していない特徴量に対し、旧いキー管理テーブルにて特徴量に関連付けられていない（即ち未使用の）旧インデックスキーを発行する。ただし、ここで発行すべき旧インデックスキーは、重複する特徴量が登録されていない特徴量に関連付けて新しいキー管理テーブルに登録されている新インデックスキーのハッシュ値に等しいハッシュ値を有する。つまり、重複する特徴量が登録されていない場合でも、新インデックスキー及び旧インデックスキー夫々のハッシュ値が互いに等しくなる。
画像登録手段は、発行した旧インデックスキーと、重複していない特徴量とを関連付けて、既に新規登録が終了している旧いキー管理テーブルに登録する。また、画像登録手段は、重複していない特徴量に関連付けられている新インデックスキーを、発行した旧インデックスキーに対応付ける。
更に画像登録手段は、新規登録が終了した新しい特徴管理テーブルに登録されている識別情報及び新インデックスキーを、新インデックスキーをこの新インデックスキーに対応付けられている旧インデックスキーを変換して、既に新規登録が終了している旧い各種管理テーブルに登録する。
以上の結果、既に新規登録が終了している旧い各種管理テーブルに、重複していない特徴量を登録することができる。
本発明にあっては、特徴量に基づいて探し出した類似画像を、付属情報によって更に絞込む。
このために、検索手段は、情報キー探索手段及び情報付与手段を更に有し、画像登録手段は、第２の登録判定手段、第２のキー発行手段、第２のキー管理登録手段及び第２の特徴管理登録手段を更に有する
キー管理テーブルでは、特徴量又は画像に付属する付属情報と、インデックスキーとが関連付けられる。ここで、付属情報とは、蓄積画像を作成した作者の名前、作成年月日等を示す情報である。
画像登録の際、画像登録手段の第２の登録判定手段、第２のキー発行手段、第２のキー管理登録手段及び第２の特徴管理登録手段は、リレーショナル・データベースに画像の特徴量を登録する場合と略同様にして、リレーショナル・データベースに、登録すべき画像の付属情報を登録する。
具体的には、第２の登録判定手段は、キー管理テーブルを参照し、リレーショナル・データベースに登録すべき画像の付属情報（以下、登録付属情報という）に関連付けてインデックスキーが既に登録されているか否かを判定する。
第２の登録判定手段が否（即ち登録付属情報がまだ登録されていない）と判定した場合、第２のキー発行手段は、登録付属情報に対してインデックスキーを発行する。第２のキー管理登録手段は、第２のキー発行手段が発行したインデックスキーと、登録付属情報とを関連付けてキー管理テーブルに登録する。
第２の特徴管理登録手段は、情報発行手段が発行した識別情報と、登録付属情報に関連付けてキー管理テーブルに登録されているインデックスキーとを関連付けて特徴管理テーブルに登録する。更に詳細には、第２の特徴管理登録手段は、第２の登録判定手段が登録されていると判定した場合は、情報発行手段が発行した識別情報と、既に登録されているインデックスキーとを関連付けて特徴管理テーブルに登録する。一方、第２の登録判定手段が否と判定した場合は、第２の特徴管理登録手段は、情報発行手段が発行した識別情報と、新たに第２のキー発行手段が発行して第２のキー管理登録手段が登録したインデックスキーとを関連付けて特徴管理テーブルに登録する。
画像検索の際、検索手段の情報キー探索手段は、蓄積管理テーブル、キー管理テーブル、及び／又は特徴管理テーブルを参照して、検索作業者によって指定された付属情報（以下、指定付属情報という）に対応するインデックスキーを探し出す。情報付与手段は、特徴管理テーブルを参照して、情報キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、付属情報が指定付属情報に一致していることを示す一致情報を付与する。
結果出力手段は、蓄積管理テーブルを参照して、画像選択手段が選択した識別情報（即ち指定画像の類似画像の識別情報）の内、情報付与手段が一致情報を付与した識別情報に一致する識別情報に関連付けられている蓄積画像を蓄積部から取得する。この結果、結果出力手段は、指定付属情報に一致する付属情報が付属している類似画像を蓄積部から取得する。
以上のように、付属情報は特徴量と同様にキー管理テーブルに登録されているため、付属情報を登録するためのテーブルを別途準備する必要がない。また、特徴量のインデックスキーの比較によって類似画像を探し出す処理と同様にして、付属情報のインデックスキーの比較によって、特徴量に基づく検索の結果を更に絞込む処理を実行することができる。
本発明にあっては、夫々が蓄積部、リレーショナル・データベースが有する各種管理テーブル、検索手段が有する各手段、表示部、画像登録手段が有する各手段の内の１つ以上を備える互いに通信可能な複数の計算機を用いて、画像検索装置が構成されている。例えば蓄積画像を管理すべく蓄積部を備える計算機と、各種管理テーブルを備える計算機と、検索作業者が検索作業に使用すべく検索手段が有する各手段及び表示部を備える計算機と、登録作業者が登録作業に使用すべく画像登録手段が有する各手段を備える計算機とを用いて、画像検索装置が構成される。
これらの複数台の計算機は、互いに通信することによって、１台の画像検索装置として機能することができるため、１台の計算機に演算負荷が集中することを抑制することができる。また、独立性が高い処理（例えば画像を検索する処理と画像を登録する処理と）を別個の計算機で並行して実行することができるため、画像検索装置全体の画像検索効率、画像登録効率、画像管理効率等を向上させることができる。
本発明にあっては、画像登録手段が枚数計数手段を更に有する。
画像登録手段のキー管理登録手段は、特徴量とインデックスキーとを関連付けてキー管理テーブルに登録する際に、この特徴量とインデックスキーとに更に関連付けて、枚数情報を登録する。また、枚数計数手段は、特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されていると判定した場合、登録されているインデックスキーに関連付けられている枚数情報を増加させる。
枚数情報とは、この枚数情報が関連付けられている特徴量を有する蓄積画像の枚数を示す情報である。つまり、枚数情報が示す枚数は１枚以上であり、枚数情報が示す枚数が１枚である場合、この枚数情報に関連付けられている特徴量を有する蓄積画像が１枚しかないことがわかる。また、枚数情報が示す枚数が多ければ多いほど、この枚数情報に関連付けられている特徴量が、多数枚の蓄積画像に共通の普遍的な特徴量であることがわかる。
多数枚の蓄積画像に共通の普遍的な特徴量は、蓄積画像同士を識別する役には立ち難い。逆に、少数枚の蓄積画像に共通の特徴量は、蓄積画像同士を識別する場合に有用である。
ただし、検索作業者が、指定画像として蓄積画像の中から画像を指定した場合、指定画像の特徴量の内、１枚を示す枚数情報に関連付けられている特徴量は、指定画像のみが有する特徴量であるため、指定画像の類似画像を探し出す役には立たない。このため、指定画像の特徴量のインデックスキーの内、キー管理テーブルで２枚以上を示す枚数情報に関連付けられている特徴量のインデックスキーを、インデックスキー同士の比較に用いる必要がある。
一方、検索作業者が、蓄積画像ではない指定画像を指定した場合、指定画像の特徴量の内、キー管理テーブルで１枚以上を示す枚数情報に関連付けられている特徴量に関連付けられているインデックスキーをインデックスキー同士の比較に用いる必要がある。
従って、類似度算出手段は、キー管理テーブルを参照し、特徴キー探索手段が探し出したインデックスキーの内、このインデックスキーに関連付けられている枚数情報が示す枚数が所定枚数以上であり、且つ、この枚数情報が示す枚数が最も少ないインデックスキーから、枚数の少なさの順にインデックスキーを特定する。次に、類似度算出手段は、特徴管理テーブルを参照して、特定したインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて類似度を算出する。
以上の結果、効率よく画像を検索することができる。
本発明にあっては、画像選択手段は、類似度算出手段が算出した類似度が所定類似度以上に達した識別画像（即ち、蓄積画像の内で、指定画像に比較的類似している蓄積画像）を暫定的に選択し、結果出力手段は、画像選択手段が選択した識別情報に一致する識別情報に関連付けられている画像を蓄積部から取得して、取得した画像を暫定的な検索結果として表示部へ出力する。この結果、暫定的な検索結果（即ち類似画像の候補）が表示部に表示される。
また、画像選択手段は、最終的に、類似度算出手段が算出した類似度が最も高い識別画像（即ち、蓄積画像の内で、指定画像に最も類似している蓄積画像）から類似度の高さの順に識別画像を選択し、結果出力手段は、画像選択手段が選択した識別情報に一致する識別情報に関連付けられている画像を蓄積部から取得して、取得した画像を最終的な検索結果として表示部へ出力する。この結果、最終的な検索結果（即ち類似画像そのもの）が表示部に表示される。
つまり、指定画像の類似画像が表示部に表示されるまで、検索作業者が長時間待たされることがなく、類似画像の候補の中に検索作業者が所望する画像が存在する場合はこの時点で画像の検索を打ち切ることもできるため、検索作業者の利便性を向上させることができ、また、検索の効率を向上させることができる。
本発明にあっては、無効付与手段を更に備える。
リレーショナル・データベースから画像の登録を抹消する場合は、蓄積部に蓄積されている蓄積画像と、この蓄積画像の識別情報を削除する必要がある。また、蓄積部から削除された蓄積画像のみが有する特徴量及びこの特徴量のインデックスキーを削除する必要があるが、これらの削除には長時間を要する。
このために無効付与手段は、リレーショナル・データベースから画像の登録を抹消する際、少なくとも特徴管理テーブルについて、登録を抹消すべき画像の識別情報に対し、無効を意味する無効情報を付与する。
以下では、無効情報が付与されている識別情報（即ち登録が抹消された画像の識別情報）を抹消識別情報という。
類似度算出手段は、抹消識別情報を除く識別情報の中から、特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定する。この場合、類似度算出手段は、抹消識別情報に関連付けられているインデックスキーと特徴キー探索手段が探し出したインデックスキーとを比較することがないため、抹消識別情報に関連付けられて類似度が算出されることはない。
つまり、識別情報に無効情報を付与するだけで、蓄積部から削除された蓄積画像、及び蓄積部から削除された蓄積画像のみに関わるインデックスキーが画像検索の際に利用されないようにすることができ、検索の効率を向上させることができる。
また、無効情報を削除することによって、画像の登録抹消を容易に取り消すことができる。更に、例えば画像の検索、登録等が実行されない夜間、休日等に、抹消識別情報、抹消識別情報を有する蓄積画像、及びこの蓄積画像のみに関わるインデックスキーを、まとめて削除することができるため、画像の登録抹消を実行することによってリレーショナル・データベースがロックされ、画像の検索、登録等が実行できなくなることを防止することができる。
本発明の画像検索装置による場合、多数枚の蓄積画像の識別情報と特徴量とを、特徴量よりも情報量が少ないインデックスキーを介して関連付け、特徴量同士を比較する代わりにインデックスキー同士を比較するため、記憶容量が多い記憶装置を備える必要がなく、また、演算能力が高い演算部を備えずとも、画像の検索のための検索時間を短縮することができる。つまり、本発明の画像検索装置は、安価な計算資源を用いて、多数枚の蓄積画像の中から指定画像の類似画像を検索する場合に好適である。
以下、本発明を、その実施の形態を示す図面に基づいて詳述する。
実施の形態 １．
図１は、本発明の実施の形態１に係る画像検索装置の全体的な構成を示す模式図である。
図中１は画像検索装置であり、画像検索装置１は、夫々計算機を用いてなる蓄積ＤＢサーバ２、検索ＤＢサーバ３、特徴抽出サーバ４、検索実行サーバ５、入力側端末機６、及び出力側端末機７、並びにＬＡＮ８を備える。ここで、ＤＢとはデータベースの略であり、ＬＡＮとはローカル・エリア・ネットワークの略である。
本実施の形態においては、各種サーバ２，３，４，５夫々は各１台のサーバマシンを用いてなる。また、入力側端末機６は、通信線６ａを介してスキャナ６７が接続された１台のパーソナルコンピュータを用いてなる。更にまた、出力側端末機７は１台のパーソナルコンピュータを用いてなる。各種端末機６，７は、液晶ディスプレイである表示部６３，７３と、マウス及びキーボード等を用いてなる操作部６４，７４とを備える
各種サーバ２，３，４，５及び各種端末機６，７は夫々ＬＡＮ８に接続されており、ＬＡＮ８を介して互いに通信可能にしてある。各計算機は、後述するように、蓄積部９０、各種管理テーブル、検索手段が有する各手段、表示部６３、画像登録手段が有する各手段の内の１つ以上を備える。
図中の白抜矢符は画像を登録する際の各種データの主要な流れを示し、矢符は画像を検索する際の各種データの主要な流れを示している。
なお、画像検索装置１の全体的な構成は、図１に示す構成に限定されるものではない。例えば、各種端末機６，７が夫々複数台、ＬＡＮ８に接続されていてもよく、また、入力側端末機として、スキャナ機能、コピー機能、ファクシミリ機能等を有する複合機、又はスキャナがＬＡＮ８に接続されていてもよい。更に、入力側端末機及び蓄積ＤＢサーバの両方の機能を有する複合機がＬＡＮ８に接続されていてもよい。
図２〜図４は、各種サーバ２，３，４，５及び各種端末機６，７夫々の構成を示すブロック図であり、図２は蓄積ＤＢサーバ２及び検索ＤＢサーバ３、図３は特徴抽出サーバ４及び入力側端末機６、図４は検索実行サーバ５及び出力側端末機７を夫々示している。
蓄積ＤＢサーバ２は、蓄積ＤＢサーバ２の制御中枢であるＣＰＵ２０と、制御プログラム及びデータ等が記憶されているＲＯＭ２１と、一次記憶装置として用いられるＲＡＭ２２と、二次記憶装置として用いられるＨＤＤ２３と、ＬＡＮ８に接続するためのＩ／Ｆ（インタフェース）２４とを備える。
同様に、検索ＤＢサーバ３は、ＣＰＵ３０とＲＯＭ３１とＲＡＭ３２とＨＤＤ３３とＩ／Ｆ３４とを備え、特徴抽出サーバ４は、ＣＰＵ４０とＲＯＭ４１とＲＡＭ４２とＨＤＤ４３とＩ／Ｆ４４とを備え、検索実行サーバ５は、ＣＰＵ５０とＲＯＭ５１とＲＡＭ５２とＨＤＤ５３とＩ／Ｆ５４とを備える。
入力側端末機６は、入力側端末機６の制御中枢であるＣＰＵ６０と、制御プログラム及びデータ等が記憶されているＲＯＭ６１と、一次記憶装置として用いられるＲＡＭ６２と、表示部６３と操作部６４と、二次記憶装置として用いられるＨＤＤ６５と、ＬＡＮ８に接続するためのＩ／Ｆ６６と、原稿から画像を読み取るスキャナ６７と、通信線６ａとを備える。
同様に、出力側端末機７は、ＣＰＵ７０とＲＯＭ７１とＲＡＭ７２と表示部７３と操作部７４とＨＤＤ７５とＩ／Ｆ７６とを備える。
入力側端末機６は、画像検索装置１に画像を登録する登録作業者が使用し、出力側端末機７は、画像検索装置１で画像を検索する検索作業者が使用する。
蓄積ＤＢサーバ２のＨＤＤ２３の記憶領域の一部には蓄積部９０が設けられている。蓄積部９０は、画像が蓄積されるフォルダである。また、ＨＤＤ２３の記憶領域の他の一部には蓄積管理テーブル９１が記憶されている。蓄積管理テーブル９１は、リレーショナル・データベースで用いられるファイルである。なお、蓄積部９０と蓄積管理テーブル９１とは別個のＨＤＤに設けられていてもよい。
同様に、検索ＤＢサーバ３のＨＤＤ３３の記憶領域の一部には、Ｎ個のキー管理テーブル９２１，９２２，…，９２ｎ，…，９２Ｎが記憶されている（ただし、Ｎ，ｎはＮ≧ｎの自然数）。また、ＨＤＤ３３の記憶領域の他の一部には、Ｎ個の特徴管理テーブル９３１，９３２，…，９３ｎ，…，９３Ｎが記憶されている。
ＨＤＤ３３の記憶領域の更に他の一部には、情報管理テーブル９４が記憶されている。情報管理テーブル９４は、各Ｎ個のキー管理テーブル９２１，９２２，…，９２Ｎ及び特徴管理テーブル９３１，９３２，…，９３Ｎを管理するためのテーブルであり、キー管理テーブル９２１，…，９２Ｎ及び特徴管理テーブル９３１，…，９３Ｎ夫々に関する情報（例えばキー管理テーブル９２１，…，９２Ｎ及び特徴管理テーブル９３１，…，９３Ｎ夫々のファイル名、作成年月日等）が登録されている。以下では、情報管理テーブル９４に登録される情報をテーブル情報という。
キー管理テーブル９２１，…，９２Ｎ、特徴管理テーブル９３１，…，９３Ｎ、及び情報管理テーブル９４夫々は、リレーショナル・データベースで用いられるファイルである。なお、各種管理テーブルは別個のＨＤＤに設けられていてもよい。
以下では、まずＨＤＤ３３に各１個のキー管理テーブル９２と特徴管理テーブル９３とが記憶されている場合を説明し、次に各複数個のキー管理テーブル９２１，…，９２Ｎと特徴管理テーブル９３１，…，９３Ｎとが記憶されている場合を説明する。
また、画像検索装置１に画像を登録する手順を先に説明し、次いで、画像検索装置１で画像を検索する手順を説明する。
図５は、入力側端末機６で実行される画像読込処理、蓄積ＤＢサーバ２で実行される蓄積側受信処理、及び特徴抽出サーバ４で実行される抽出側受信処理夫々の手順を示すフローチャートである。
まず、入力側端末機６で実行される画像読込処理について説明する。
入力側端末機６のＣＰＵ６０は、表示部６３を制御して、登録作業者に画像を登録させるための画面を表示させて、画像検索装置１に登録すべき画像を読み込むための読込指示を受け付ける（Ｓ１１）。ここで、登録作業者は、スキャナ６７に原稿をセットし、表示部６３を視認しながら操作部６４を操作して、原稿画像の読込指示を入力する。
読込指示を受け付けたＣＰＵ６０は、スキャナ６７を制御して原稿の画像を読み込み（Ｓ１２）、読み込んだ画像をＨＤＤ６５に記憶させる（Ｓ１３）。ここでＨＤＤ６５に記憶される画像は、画像を示すデータのファイルである。なお、スキャナ６７で読み込んだ画像に限定されず、入力側端末機６で作成された画像、外部から受信した画像等が登録される構成でもよい。
次にＣＰＵ６０は、表示部６３を制御して、登録作業者に付属情報を入力させるための画面を表示させて、付属情報を受け付ける（Ｓ１４）。登録作業者は、表示部６３に表示された画面を視認しながら、操作部６４を操作して付属情報を入力する。
付属情報とは、登録すべき画像に付属する情報であり、例えば画像を作成した作者の名前又はユーザＩＤ、作者の所属部署、作成年月日、画像を登録する登録年月日、ファイル名、サイズ、保存形式、及び／又は圧縮形式等、画像検索の際に、特徴量に基づく検索の結果を更に絞込むために用いられる情報である。ただし、作成年月日、サイズ等のファイル属性、又は登録年月日等、ＣＰＵ６０がファイル又は入力側端末機６が備える図示しないタイマ等から取得可能な情報を付属情報として用いる場合、付属情報を登録作業者に入力させる必要はない。また、ファイル名はＣＰＵ６０が適宜に生成してもよい。
なお、入力側端末機６が複合機である場合、付属情報としてジョブ種別及び／又はログ情報を用いてもよい。ジョブ種別とは、登録すべき画像に関して複合機で実行されたジョブの種別であり、登録すべき画像が、原稿画像を複写するために読み込んだ画像であるか（「コピー」）、単に読み込んだ画像であるか（「スキャン」）、プリントアウトするために外部から受信した画像であるか（「プリント」）、ファクシミリ通信で送受信した画像であるか（「ＦＡＸ送信」又は「ＦＡＸ受信」）等を示す。ログ情報とは、複合機を使用した使用者の操作履歴を示す情報であり、ログ記録と画像とを関連付けて記録することによって、使用者の使用状況を管理するためのものである。このような複合機を入力側端末機６として用いる場合は、使用者が自発的に入力側端末機６を操作しなくても、自動的に画像が登録される構成であってもよい。
Ｓ１４の処理完了後、ＣＰＵ６０は、Ｓ１３で記憶させた画像をＨＤＤ６５から読み出して、読み出した画像とＳ１４で受け付けた付属情報とを関連付けて、特徴抽出サーバ４へ送信し（Ｓ１５）、更に、読み出した画像を蓄積ＤＢサーバ２へ送信して（Ｓ１６）、画像読込処理を終了する。
複数枚の画像を登録する場合は、Ｓ１１〜Ｓ１６の処理が繰り返し実行される。なお、Ｓ１５及びＳ１６で複数枚の画像が送信される構成でもよい。ただしこの場合、例えばＣＰＵ６０が各画像に連番を振り、この連番と共に画像を送信することによって、後述するように蓄積ＤＢサーバ２及び特徴抽出サーバ４夫々で発行される画像ＩＤに齟齬が生じないようにするか、又は、入力側端末機６で画像ＩＤを発行して、発行した画像ＩＤと共に画像を送信する。
次に、蓄積ＤＢサーバ２で実行される蓄積側受信処理について説明する。
蓄積ＤＢサーバ２のＣＰＵ２０は、入力側端末機６から画像を受信したか否かを判定し（Ｓ１８）、受信していない場合は（Ｓ１８でＮＯ）、Ｓ１８の処理を繰り返し実行する。入力側端末機６から画像を受信した場合（Ｓ１８でＹＥＳ）、ＣＰＵ２０は、蓄積実行処理を行なうサブルーチン（図６参照）を呼び出し、実行する（Ｓ１９）。
Ｓ１９の処理完了後、ＣＰＵ２０はＳ１８へ処理を戻す。
最後に、特徴抽出サーバ４で実行される抽出側受信処理について説明する。
特徴抽出サーバ４のＣＰＵ４０は、入力側端末機６から画像及び付属情報を受信したか否かを判定し（Ｓ２０）、受信していない場合は（Ｓ２０でＮＯ）、Ｓ２０の処理を繰り返し実行する。画像及び付属情報を受信した場合（Ｓ２０でＹＥＳ）、ＣＰＵ４０は、特徴抽出処理を行なうサブルーチン（図７参照）を呼び出し、実行する（Ｓ２１）。
Ｓ２１の処理完了後、ＣＰＵ４０はＳ２０へ処理を戻す。Ｓ２０で受信した画像及び付属情報は、ＨＤＤ４３に記憶させてもよいが、Ｓ２１の処理完了後に削除することが望ましい。
図６は、蓄積側受信処理で呼び出される蓄積実行処理手順のサブルーチンを示すフローチャートである。
蓄積ＤＢサーバ２のＣＰＵ２０は、Ｓ１８で受信した画像を蓄積部９０に蓄積させる（Ｓ３１）。つまりＳ３１におけるＣＰＵ２０は、蓄積制御手段として機能する。Ｓ３１の処理を実行する前に、ファイル名が等しい画像が既に蓄積されている場合は、誤って上書きしないように、例えば蓄積部９０に設けた別個のサブ・フォルダに蓄積する。
Ｓ３１の処理完了後、ＣＰＵ２０は、Ｓ３１の処理で蓄積部９０に蓄積させた画像に対して、画像を識別する識別情報としての画像ＩＤを発行する（Ｓ３２）。つまりＳ３２におけるＣＰＵ２０は、情報発行手段として機能する。
本実施の形態において、Ｓ３２の処理で発行される画像ＩＤは４バイトのデータ長を有する整数（以下、４バイト整数という）であり、連番で１６進数表記の『０ｘ０００００００１』から順に採番されて、画像の受信順に付与される。ただし、『０ｘ００００００００』は用いられない。このため、『０ｘ００００００００』は、例えば画像ＩＤが付与されない画像を示す情報として用いることができる。以上のような画像ＩＤは、各演算部（即ちＣＰＵ２０，３０，４０，５０，６０，７０夫々）が１つの命令で演算可能なデータ長を有するため、１つの命令では演算不可能な長いデータ長を有する画像ＩＤを用いる場合に比べて、演算時間が短縮される。以下では、本明細書では、１６進数表記の数値を『』で示す。
Ｓ３２の処理完了後、ＣＰＵ２０は、Ｓ３２で発行した画像ＩＤと、Ｓ３１で蓄積部９０に蓄積した画像とを関連付けて、蓄積管理テーブル９１に登録する（Ｓ３３）。つまり、Ｓ３３におけるＣＰＵ２０は、蓄積管理登録手段として機能する。
蓄積管理テーブル９１には、１件のレコードにつき、１個のＩＤフィールドと１個の蓄積画像フィールドとが関連付けて設けられている。ＣＰＵ２０は、Ｓ３２で発行した画像ＩＤをＩＤフィールドに格納し、Ｓ３１で蓄積部９０に蓄積した画像のアドレス及びファイル名を蓄積画像フィールドに格納してなるレコードを生成し、生成したレコードを蓄積管理テーブル９１に挿入する。
蓄積管理テーブル９１における主キーは画像ＩＤである。また、画像ＩＤが４バイト整数であるため、１個の蓄積管理テーブル９１には、約２32枚の画像を登録することができる。
Ｓ３３の処理完了後、ＣＰＵ２０は、処理を蓄積側受信処理のルーチンへ戻す。
なお、例えば２台の入力側端末機６が存在する場合、Ｓ３２の処理を実行する際に、一方の入力側端末機６から受信した画像には『０ｘ０００００００１』から順に採番し、他方の入力側端末機６から受信した画像には『０ｘ８００００００１』から順に採番することによって、画像ＩＤに齟齬が生じること防止することができる。
以下では、蓄積部９０に蓄積されている画像を蓄積画像という。
図７は、抽出側受信処理で呼び出される特徴抽出処理手順のサブルーチン、及び検索ＤＢサーバ３で実行される登録側受信処理夫々の手順を示すフローチャートである。
まず、特徴抽出サーバ４で実行される特徴抽出処理について説明する。
特徴抽出サーバ４のＣＰＵ４０は、Ｓ２０で受信した画像に対して画像ＩＤを発行する（Ｓ４１）。つまりＳ４１におけるＣＰＵ４０は、情報発行手段として機能する。Ｓ２０で受信した画像とは、Ｓ３１で蓄積部９０に蓄積される蓄積画像に等しく、Ｓ４１の処理で発行されるＩＤは、Ｓ３２の処理で発行される画像ＩＤに等しい。
更に、ＣＰＵ４０は、Ｓ２０で受信した画像に基づいて、この画像の特徴を数値的に示す特徴量を抽出する（Ｓ４２）。つまり、Ｓ４２におけるＣＰＵ４０は、特徴算出手段として機能する。
本実施の形態においては、Ｓ４２の処理を実行することによって１枚の画像当たり約７千個の特徴量が抽出され、抽出される各特徴量は２０バイト数列（即ち２０バイトのデータ長を有する数列）である。ここで、特徴量のデータ長は、各計算機（即ち各種サーバ２，３，４，５及び各種端末機６，７夫々）が備える図示しないレジスタのレジスタ長を超えている。つまり、このような特徴量は、各演算部が１つの命令では演算不可能な長いデータ長を有する。Ｓ４２の処理で抽出すべき特徴量は、画像を複数の閉じた図形に分割し、分割した図形夫々の重心点を利用して算出される２点間の距離の比に基づくものであるが、これに限らず、輝度分布、エッジ強度等を用いた特徴量でもよい。
Ｓ４２の処理完了後、ＣＰＵ４０は、Ｓ４１で発行した画像ＩＤと、Ｓ４２で抽出した約７千個の特徴量と、Ｓ２０で受信した付属情報とを関連付けて、検索ＤＢサーバ３へ送信し（Ｓ４３）、処理を抽出側受信処理のルーチンへ戻す。
次に、検索ＤＢサーバ３で実行される登録側受信処理について説明する。
検索ＤＢサーバ３のＣＰＵ３０は、特徴抽出サーバ４から画像ＩＤ、特徴量及び付属情報を受信したか否かを判定し（Ｓ４４）、受信していない場合は（Ｓ４４でＮＯ）、Ｓ４４の処理を繰り返し実行する。画像ＩＤ、特徴量及び付属情報を受信した場合（Ｓ４４でＹＥＳ）、受信した画像ＩＤ、特徴量及び付属情報をＨＤＤ３３に一時的に記憶させてから、テーブル管理処理を行なうサブルーチン（図８参照）を呼び出し、実行する（Ｓ４５）。
Ｓ４５の処理完了後、ＣＰＵ３０はＳ４４へ処理を戻す。
図８は、登録側受信処理で呼び出されるテーブル管理処理手順のサブルーチンを示すフローチャートであり、図９〜図１１は、テーブル管理処理で呼び出される登録実行処理手順のサブルーチンを示すフローチャートである。また、図１２は、登録実行処理で呼び出される特徴管理格納処理手順のサブルーチンを示すフローチャートであり、図１３は、登録実行処理で呼び出されるキー管理格納処理手順のサブルーチンを示すフローチャートである。
本発明の最も大きな特徴は、検索作業者が指定した指定画像に類似する類似画像を探し出すために、２０バイト数列である特徴量同士を比較する処理ではなく、特徴量よりも情報量が少ないインデックスキー同士を比較する処理を実行することである。この結果、検索時間が短縮される。
このために、画像ＩＤと特徴量との対応関係を、画像ＩＤとインデックスキーとの対応関係、及び、インデックスキーと特徴量との対応関係に分割しておく必要がある。
従って、登録実行処理においては、登録側受信処理のＳ４４で受信した特徴量及び付属情報夫々に対してインデックスキーが発行されて、発行されたインデックスキーと特徴量又は付属情報とが関連付けられてキー管理テーブル９２に登録される。また、登録側受信処理のＳ４４で受信した画像ＩＤと、キー管理テーブル９２に登録されているインデックスキーとが関連付けられて特徴管理テーブル９３に登録される。
以下では、まず、特徴量のみを登録する場合について説明し、次に、特徴量及び付属情報の両方を登録する場合について説明する。
キー管理テーブル９２では、１件のレコードにつき、１個のキーフィールドと１個の特徴量フィールドとが関連付けて設けられている。キーフィールドには、１個のインデックスキーが格納され、特徴量フィールドには、１個の特徴量又は付属情報が格納される。
キー管理テーブル９２における主キーはインデックスキーである。
本実施の形態におけるインデックスキーは４バイト整数であり、原則として連番で『０ｘ０００００００１』から順に採番される。また、本実施の形態では、『０ｘ００００００００』は、キーフィールドにインデックスキーが格納されていないことを示すキー未格納情報として用いられる。つまり、インデックスキーが格納されているキーフィールドには、『０ｘ０００００００１』以上の４バイト整数が格納されており、インデックスキーが格納されていないキーフィールドには、『０ｘ００００００００』が格納されている。
このようなインデックスキー及びキー未格納情報夫々のデータ長は、各計算機のレジスタ長以下である。換言すれば、インデックスキー及びキー未格納情報は、各演算部が１つの命令で演算可能なデータ長を夫々有する。このため、１つの命令では演算不可能な長いデータ長を有するインデックスキーを用いる場合に比べて、演算時間が短縮される。
また、検索精度を向上させるために、２０バイト数列よりも更にデータ長が長い特徴量が登録される画像検索装置を構成しても、インデックスキーのデータ長が同じ４バイト整数であれば、この画像検索装置の検索時間と画像検索装置１の検索時間とは、ほとんど変わらない。つまり、検索時間を大幅に増大させることなく、検索精度を向上させることが容易である。
インデックスキーが４バイト整数であるため、１個のキー管理テーブル９２には、約２32個の特徴量及び付属情報を登録することができる。
キー管理テーブル９２の容量を節約し、また、検索の手間を省くために、同一の特徴量又は付属情報には異なるインデックスキーが発行されないようにする必要がある。従って、インデックスキーの発行前には、登録すべき特徴量又は付属情報に一致する特徴量がキー管理テーブル９２に登録されていないことが予め確認される。
特徴管理テーブル９３では、１件のレコードにつき、１個のＩＤフィールドとＭ個のキーフィールドとが関連付けて設けられている。特徴管理テーブル９３における主キーは画像ＩＤである。本実施の形態においては、Ｍ＝１６である。
１６個のキーフィールドには、４ビットのデータ長を有する整数を用いてなる相異なるフィールド値『０ｘ０』，『０ｘ１』，…，『０ｘＦ』が夫々付与されている。
仮に、特徴管理テーブル９３の各レコードに、１個のＩＤフィールドと１個の特徴量フィールドとが関連付けて設けられる場合、特徴管理テーブル９３に登録されるレコード件数は、「蓄積画像の枚数」×「蓄積画像の特徴量の個数（約７千個）」件になる。一般に、リレーショナル・データベースでは、テーブルに登録されているレコード件数が多いほど、新たなレコードをテーブルに登録する処理の演算時間は長くなる。
登録処理の演算時間を短縮すべく、本実施の形態では特徴管理テーブル９３の各レコードに複数個の特徴量フィールドが設けられている。
以上のようにして、画像ＩＤと特徴量とを、インデックスキーを介して間接的に対応付ける画像検索装置１においては、仮に、画像ＩＤと４バイト整数であるインデックスキーとが一対一対応で特徴管理テーブル９３に登録されるとしても、画像ＩＤと特徴量とを直接的に対応付ける従来の画像検索装置の画像管理テーブル（即ち、画像ＩＤと２０バイト数列である特徴量とが一対一対応で登録される画像管理テーブル）に比べれば、特徴管理テーブル９３のデータ量は少ない。データ量の減少量は、画像検索装置１及び従来の画像検索装置夫々に登録される画像の枚数、及び／又は、画像１枚当たりの特徴量の個数が多ければ多いほど顕著になる。
また、指定画像の類似画像を蓄積画像の中から探し出すために、特徴量を用いたマッチングは、従来の画像検索装置においては、データ量が多い画像管理テーブルを参照して、データ長が長い特長量同士を比較することによって実行される。一方、画像検索装置１においては、データ量が少ない特徴管理テーブル９３を参照して、データ長が短いインデックスキー同士を比較することによって実行される。しかも、指定画像の約７千個の特徴量夫々について、各蓄積画像の７千個の特徴量とのマッチングを行なう必要があるため、蓄積画像の枚数が多ければ多いほど、検索時間は大幅に短縮される。同様に、指定画像及び／又は各蓄積画像夫々の特徴量が多ければ多いほど、検索時間は大幅に短縮される。
ところで、同一の原稿から読込まれた画像同士、又は、同一の部分画像を含む画像同士では、各７千個の特徴量の内、互いに一致する特徴量が少なくない。このため、例えば１０万枚の画像の各７千個の特徴量に対し、１０万×７千＝７億個のインデックスキーが発行されることはなく、７億個未満、場合によっては半分以下の個数のインデックスキーが発行される。従って、キー管理テーブル９２のデータ量は、従来の画像検索装置の画像管理テーブルのデータ量よりも少なくなる。
以上のことから、キー管理テーブル９２及び特徴管理テーブル９３のデータ量の合計は、従来の画像検索装置の画像管理テーブルのデータ量よりも大幅に増大することはなく、蓄積画像の枚数及び内容等によっては、むしろ減少する可能性もある。
ここで、キー管理テーブル９２及び特徴管理テーブル９３夫々に対する最も単純な登録手順を説明する。
例えば、『０ｘ０００００００１』という第１の画像ＩＤに関連付けられて、『０ｘ１１２２３３４４５５６６７７８８９９００１１２２３３４４５５６６７７８８９９００』という第１の特徴量と、『０ｘ００１１２２３３４４５５６６７７８８９９９９８８７７６６５５４４３３２２１１００』という第２の特徴量とが、この順で与えられた場合、『０ｘ０００００００１』という第１のインデックスキーと、『０ｘ０００００００２』という第２のインデックスキーとが、この順で発行される。
このとき、キーフィールドに第１のインデックスキーを格納し、特徴量フィールドに第１の特徴量を格納してあるレコードと、キーフィールドに第２のインデックスキーを格納し、特徴量フィールドに第２の特徴量を格納してあるレコードとが、キー管理テーブル９２に挿入される。
また、ＩＤフィールドに第１の画像ＩＤを格納し、フィールド値『０ｘ０』のキーフィールドに第１のインデックスキーを格納し、フィールド値『０ｘ１』のキーフィールドに第２のインデックスキーを格納し、フィールド値『０ｘ２』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが、特徴管理テーブル９３に挿入される。
次に、『０ｘ０００００００２』という第２の画像ＩＤに関連付けられて、『０ｘ１１２２３３４４５５６６７７８８９９００１１２２３３４４５５６６７７８８９９０１』という第３の特徴量と、『０ｘ００１１２２３３４４５５６６７７８８９９９９８８７７６６５５４４３３２２１１００』という第４の特徴量とが、この順で与えられた場合、与えられた第４の特徴量は、第２の特徴量に等しい。即ち、第４の特徴量は既にキー管理テーブル９２に登録されている特徴量である。このため、第３の特徴量に対して、『０ｘ０００００００３』という第３のインデックスキーが発行され、第４の特徴量には、キー管理テーブル９２を参照して第２のインデックスキーが関連付けられる。
このとき、キーフィールドに第３のインデックスキーを格納し、特徴量フィールドに第３の特徴量を格納してあるレコードが、キー管理テーブル９２に挿入される。一方、第４の特徴量が格納されたレコードがキー管理テーブル９２に挿入されることはない。
また、ＩＤフィールドに第２の画像ＩＤを格納し、フィールド値『０ｘ０』のキーフィールドに第２のインデックスキーを格納し、フィールド値『０ｘ１』のキーフィールドに第３のインデックスキーを格納し、フィールド値『０ｘ２』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが、特徴管理テーブル９３に挿入される。
各レコードにはキーフィールドが１６個設けられているが、１枚の蓄積画像の特徴量の個数が“１６”の倍数であるとは限らない。しかしながら、以上のような例では、キーフィールドに対してインデックスキーをフィールド値の順に単純に格納したため、キー未格納情報が格納されたキーフィールド（即ち空きキーフィールド）の発生数は最小限に抑えられる。従って、特徴管理テーブル９３のレコード件数は最小限（具体的には、特徴管理テーブル９３に登録されているインデックスキーの個数の約１／１６の件数）になる。
ただし、このような特徴管理テーブル９３を用いて効率的な画像検索を行なうことはできない。このため、インデックスキー夫々をフィールド値に対応させ、対応するフィールド値が付与されているキーフィールドにインデックスキーを格納する（以下、キーフィールドを埋めるという）ことによって、特徴管理テーブル９３のレコード件数を減少させつつ、検索効率を向上させることが図られる。
各インデックスキーをフィールド値に対応させるために、ハッシュ関数が用いられる。
本実施の形態におけるハッシュ関数は、インデックスキーを“１６”（即ちレコード１件当たりのキーフィールドの個数Ｍ）で除算した剰余を求める関数である。つまり、“フィールド値”＝“ハッシュ値”＝“インデックスキー”％“Ｍ”である。
このようなハッシュ関数とインデックスキーとに基づいて算出されるハッシュ値は、４バイト整数であるインデックスキーの最下位ニブル（即ち下位４ビット整数）に等しい。つまり、本実施の形態のハッシュ関数を用いたハッシュ値の算出処理は、インデックスキーの最下位ニブルを求める処理（即ち、インデックスキーと『０ｘＦ』とのアンド演算を実行する処理）である。
従って、ハッシュ値の算出処理、及びハッシュ値に等しいフィールド値が付与されているキーフィールドにインデックスキーを格納する処理は、画像登録時の演算時間を大幅に増大させることはない。
特徴管理テーブル９３に、画像ＩＤと、この画像ＩＤに関連付けられる７千個のインデックスキーとを登録する場合は、１件のレコードの１６個のキーフィールドを可能な限り埋めて、空きキーフィールドを作らないようにし、同一のハッシュ値を有するインデックスキーが複数個存在するときに、２件目、３件目のレコードを生成することが望ましい。
具体的には、例えばＩＤフィールドに第１の画像ＩＤを格納し、フィールド値『０ｘ１』のキーフィールドに、ハッシュ値『０ｘ１』の第１のインデックスキーを格納し、フィールド値『０ｘ２』のキーフィールドにハッシュ値『０ｘ２』の第２のインデックスキーを格納し、フィールド値『０ｘ０』及び『０ｘ３』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが、特徴管理テーブル９３に挿入される。
また、『０ｘ０００００００３』という第３の画像ＩＤに、ハッシュ値『０ｘ３』の第３のインデックスキーと、『０ｘ００００００１３』というハッシュ値『０ｘ３』の第１３のインデックスキーとが関連付けられた場合、まず、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドに第３のインデックスキーを格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが、特徴管理テーブル９３に挿入される。更に、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドに第１３のインデックスキーを格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードとが、特徴管理テーブル９３に挿入される。
図１４は、本発明の実施の形態１に係る画像検索装置の特徴管理テーブル９３を説明する模式図である。図に示すように、特徴管理テーブル９３には、ＩＤフィールドと、フィールド値『０ｘ０』〜『０ｘＦ』のキーフィールドとが関連付けられているレコードが設けられている。ただし、図中のインデックスキーは下４桁のみが記載されており、キー未格納情報として「未」が記載されている。
図１４に示す特徴管理テーブル９３には、前述の第１〜第３の画像ＩＤに係るインデックスキーと、第４の画像ＩＤに係るインデックスキーとが記載されている。
第４の画像ＩＤには、ハッシュ値『０ｘ０』のインデックスキーと、第１〜第３のインデックスキーと、ハッシュ値『０ｘ４』〜『０ｘＦ』のインデックスキーとが関連付けられている。
図１５は、インデックスキーを介したマッチングを説明する模式図である。図１５には、画像ＩＤと、マッチング結果である投票数とが一対一対応で関連付けられている結果テーブル９５が示されている。ここで、投票数とは、当該画像ＩＤを有する蓄積画像が指定画像に類似している度合いを数値的に示す類似度であり、投票数が多いほど、類似度が高い（即ち画像同士が類似している）。図１５では、投票数の初期値は“０”である。
結果テーブル９５は、画像検索の際に、検索実行サーバ５のＣＰＵ５０が生成してＲＡＭ５２に一時的に記憶させる。
検索作業者が、指定画像の画像ＩＤとして第１の画像ＩＤを指定した場合、結果テーブル９５には、第２〜第４の画像ＩＤ夫々について、各画像ＩＤが格納されたＩＤフィールドと、投票数“０”が格納された投票数フィールドとが関連付けられているレコードが設けられる。
インデックスキーを介したマッチングを実行する場合、図１４に示すような特徴管理テーブル９３が参照され、第１の画像ＩＤに関連付けられているインデックスキーの内、まず、第１のインデックスキーが選択され、選択された第１のインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤ（この場合、第４の画像ＩＤ）が特定され、結果テーブル９５にて、特定された画像ＩＤの投票数が“１”インクリメントされる（図１５（ａ））。第１のインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤが存在しない場合は、当然、投票数のインクリメントは行なわれない。
ここで、第１のインデックスキーに一致するインデックスキーを探し出すために、フィールド値『０ｘ１』が付与されているキーフィールドが注目され、このキーフィールドに格納されているインデックスキー（及びキー未格納情報）と第１のインデックスキーとが比較される。
一方、フィールド値『０ｘ１』以外のフィールド値が付与されているキーフィールドは注目されない。何故ならば、第１のインデックスキーは最下位ニブルが『０ｘ１』であり、フィールド値『０ｘ１』以外のフィールド値が付与されているキーフィールドには、最下位ニブルが『０ｘ１』であるインデックスキーは格納されていないことが自明だからである。
つまり、指定画像に係る各インデックスキーは、単純計算で、特徴管理テーブル９３に登録されているインデックスキーの内の１／１６の個数のインデックスキーと比較される。この結果、登録されている全てのインデックスキーと比較する場合と比べて、演算時間が大幅に減少する。
実際には、１個の画像ＩＤに、互いにハッシュ値が等しいインデックスキーが多数個関連付けられ、この結果、レコード１件当たりの空きキーフィールドの個数が増加するため、比較対象（即ち特徴管理テーブル９３に登録されているレコード件数）は１／１６にはならない。しかしながら、１個の画像ＩＤに関連付けられている約７０００個のインデックスキー夫々のハッシュ値が、全て一致する確率は非常に低いため、一般には、比較対象が１／１０程度に減少することが期待できる。なお、各レコードに２５６個のキーフィールドを設けて、インデックスキーの下位８ビットをハッシュ値として用いる場合は、比較対象が１／１００程度に減少することが期待できる。
第１のインデックスキーについてマッチングを行なった後、特徴管理テーブル９３にて、第１の画像ＩＤに関連付けられている第２のインデックスキーが選択され、選択された第２のインデックスキーと、フィールド値『０ｘ２』が付与されているキーフィールドに格納されているインデックスキー（及びキー未格納情報）とが比較されて、第２のインデックスキーに一致するインデックスキーが探し出され、探し出されたインデックスキーに関連付けられている画像ＩＤ（この場合、第２及び第４の画像ＩＤ）が特定され、結果テーブル９５にて、特定された画像ＩＤの投票数が“１”インクリメントされる（図１５（ｂ））。第２のインデックスキーに一致するインデックスキーが存在しない場合、当然、画像ＩＤの特定及び投票数のインクリメントは実行されない。
つまり、インデックスキーを介したマッチング処理は、インデックスキーのハッシュ値に基づいて、注目すべきキーフィールドが決定される第１の処理と、決定されたキーフィールドに対して、インデックスキー同士が比較される第２の処理と、一致したインデックスキーに関連付けられている画像ＩＤに対して、投票数がインクリメントされる第３の処理とを有している。この内、第１の処理は、インデックスキーと『０ｘＦ』とのアンド演算を実行する容易な処理であり、第２及び第３の処理は、リレーショナル・データベースでは、例えば１つのＳＱＬ（Structured Query Language ）文によって実行することが可能な処理である。
第２のインデックスキーについてマッチングを行なった後、まだマッチングを終えていないインデックスキーが第１の画像ＩＤに関連付けられているならば、このインデックスキーについてのマッチングが行なわれる。
マッチングの結果として図１５（ｂ）に示すような投票数が得られた場合、第４の画像ＩＤに係る投票数が最も多いため、第４の画像ＩＤを有する蓄積画像が、指定画像の類似画像として蓄積部９０から取得され、取得された類似画像が、出力側端末機７の表示部７３に表示される。又は、投票数が多い順に適宜の枚数の類似画像が取得されて表示部７３に表示される。ただし、画像ＩＤに係る投票数が所定の最低投票数を下回る場合、この画像ＩＤに係る蓄積画像は取得されず、投票数が所定の最低投票数以上である画像ＩＤが存在しない場合は、類似画像が存在しないことを示すテキスト、アイコン等が表示部７３に表示される。
ここで、特徴管理テーブル９３のレコード件数を可及的低減する手法を説明する。
図１６は、本発明の実施の形態１に係る画像検索装置のキー管理テーブル９１を説明する模式図である。図に示すように、キー管理テーブル９２には、キーフィールドと特徴量フィールドとが関連付けられているレコードが設けられている。ただし、図中のインデックスキーは下４桁が記載されており、特徴量は途中が省略されている。
ここでは、特徴管理テーブル９３に、第１及び第２の画像ＩＤ夫々とインデックスキーとが既に登録されており、図１６（ａ）に示すように、キー管理テーブル９２に、インデックスキー『０ｘ０００００００１』〜『０ｘ００００００１２』夫々に関連付けて特徴量が既に登録されており、この後、キー管理テーブル９２及び特徴管理テーブル９３に、第３の画像ＩＤと特徴量とを、インデックスキーを介して登録する場合を例示する。
第３の画像ＩＤに関連付けられて、『０ｘ１１２２３３４４５５６６７７８８９９００１１２２３３４４５５６６７７８８９９０１』という一の特徴量と、『０ｘ２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２』という他の特徴量とが与えられた場合、一の特徴量は、『０ｘ０００００００３』に関連付けられて、既にキー管理テーブル９２に登録されている。一方、他の特徴量は、キー管理テーブル９２に登録されていない。以下では、既にキー管理テーブル９２に登録されている特徴量を既登録特徴量といい、まだキー管理テーブル９２に登録されていない特徴量を未登録特徴量という。
仮に、インデックスキーを無条件に連番で発行する場合、未登録特徴量には、インデックスキー『０ｘ００００００１３』が発行される。このため、既登録特徴量のインデックスキーのハッシュ値と未登録特徴量のインデックスキーのハッシュ値とは互いに等しい『０ｘ３』になる。この結果、図１４に示すように、第３の画像ＩＤに関連付けて２個のインデックスキーを特徴管理テーブル９３に登録するために、２件のレコードが必要になる。
このようにインデックスキーを無条件に連番で発行していても、１個の画像ＩＤに関連付けられるインデックスキーのハッシュ値は、自然にバラける傾向にある。従って、１個の画像ＩＤに関連付けられる約７０００個のインデックスキーを登録するために、約７０００件のレコードが必要になることはなく、７００件程度のレコード件数になることが期待できる。
しかしながら、更に積極的にレコード件数を低減するためには、次のような手順でインデックスキーを発行することが望ましい。
既登録特徴量については、既にインデックスキーが存在するため、まず、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドにインデックスキー『０ｘ０００００００３』を格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが設けられる。このようなレコードは、検索ＤＢサーバのＣＰＵ３０によって生成され、ＲＡＭ３２に一時的に記憶される。
次に、キー管理テーブル９２を参照し、『０ｘ００００００１３』以上のインデックスキーであって、当該インデックスキーのハッシュ値が、ＲＡＭ３２に記憶されているレコードの空きキーフィールドのフィールド値に等しく、しかも、最小値であるインデックスキーが求められる。
この場合、空きキーフィールドに格納可能なインデックスキーは、ハッシュ値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』を有するインデックスキーであり、インデックスキー『０ｘ００００００２０』〜『０ｘ００００００２２』及び『０ｘ００００００１４』〜『０ｘ００００００１Ｆ』が該当する。これらのインデックスキーの内、最小値は『０ｘ００００００１４』である。このため、未登録特徴量に対して、インデックスキー『０ｘ００００００１４』が発行される。
次いで、インデックスキー『０ｘ００００００１４』と未登録特徴量『０ｘ２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２２』とが関連付けられて、キー管理テーブル９２に登録される。この場合、キーフィールドにインデックスキー『０ｘ００００００１４』を格納し、特徴量フィールドに未登録特徴量が格納してあるレコードがキー管理テーブル９２に挿入されるが、このレコードを挿入する前に、キーフィールドにインデックスキー『０ｘ００００００１３』を格納し、特徴量フィールドに、特徴量が格納されていないことを示す特徴未格納情報が格納してあるレコード（以下、空きキー管理レコードという）がキー管理テーブル９２に挿入される（図１６（ｂ））。
画像の特徴量が“０”になることはないため、特徴未格納情報としては、２０バイト数列『０ｘ００００００００００００００００００００００００００００００００００００００００』が用いられる。
最後に、ＲＡＭ３２に一時的に記憶されているレコードが、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドにインデックスキー『０ｘ０００００００３』を格納し、フィールド値『０ｘ４』のキーフィールドにインデックスキー『０ｘ００００００１４』を格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ５』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードに更新され、更新されたレコードが、特徴管理テーブル９３に挿入される。
以上の結果、図示はしないが、第３の画像ＩＤに関連付けて２個のインデックスキーを特徴管理テーブル９３に登録するためのレコード件数が、１件に低減される。
キー管理テーブル９２にて特徴未格納情報に関連付けられているインデックスキー『０ｘ００００００１３』（即ち空きキー管理レコードに格納されているインデックスキー）は、新たな未登録特徴量をキー管理テーブル９２に登録する場合に利用されるため、無駄なインデックスキーは生じない。
以上のように、特徴量に関連付けて既にインデックスキーが登録されているか否かが判定され、判定結果に基づき、登録されているインデックスキーを優先的にキーフィールドに格納したレコードが生成される。このようなレコードが生成された後、生成されたレコードの空きキーフィールドのフィールド値に等しいハッシュ値を有し、しかも、キー管理テーブル９２に特徴量が登録されていないインデックスキーが、まだインデックスキーが登録されていない特徴量に対して発行される。この結果、インデックスキーを無条件に連番で発行する場合に比べて、特徴管理テーブル９３のレコード件数が効率よく低減される。
ただし、既にキー管理テーブル９２に登録されているインデックスキーと、新たに登録すべきインデックスキーとが連番ではない場合、これらの２個のインデックスキーの中間のインデックスキーと特徴未格納情報とを関連付けて、キー管理テーブル９２に登録（即ち空きキー管理レコードを挿入）する必要がある。新たな未登録特徴量に対してインデックスキーを発行する場合は、特徴未格納情報が関連付けられているインデックスキーが優先的に採用される。
次に、特徴管理テーブル９３のデータ量を更に低減する手法を説明する。
図１４に示すように、各キーフィールドに格納されているインデックスキーの最下位ニブルと、各キーフィールドに付与されているフィールド値とは一致している。つまり、各キーフィールドに格納されているインデックスキーの最下位ニブルは冗長な情報である。
この冗長な情報を削除して特徴管理テーブル９３のデータ量を更に低減するためには、各キーフィールドに、４バイト整数であるインデックスキーの上位２８ビット整数を格納すればよい。このとき、キーフィールドに格納されている２８ビット整数と、このキーフィールドのフィールド値とに基づいて、インデックスキーは容易に求められる。
換言すれば、キーフィールドに格納すべき格納値は、インデックスキーを“１６”（即ちレコード１件当たりのキーフィールドの個数）で除算した商である。つまり、“キーフィールドの格納値”＝“インデックスキー”÷“Ｍ”である。このような格納値を求める処理は、インデックスキーを４ビットだけ右シフトした値を求める簡易な処理である。
例えば、第３の画像ＩＤに、第３のインデックスキー『０ｘ０００００００３』と、第１３のインデックスキー『０ｘ００００００１３』とが関連付けられた場合、まず、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドに第３のインデックスキーに係る格納値『０ｘ０００００００』を格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードが、特徴管理テーブル９３に挿入される。更に、ＩＤフィールドに第３の画像ＩＤを格納し、フィールド値『０ｘ３』のキーフィールドに第１３のインデックスキーに係る格納値『０ｘ００００００１』を格納し、フィールド値『０ｘ０』〜『０ｘ２』及び『０ｘ４』〜『０ｘＦ』のキーフィールドにキー未格納情報を格納してあるレコードとが、特徴管理テーブル９３に挿入される。
インデックスキーを介したマッチングの際には、格納値同士を比較すればよく、格納値及びフィールド値に基づいてインデックスキーを求める必要はない。
なお、各レコードに２５６個のキーフィールドを設けて、インデックスキーの下位８ビットをハッシュ値として用いる場合は、インデックスキーの格納値として、インデックスキーを８ビットだけ右シフトした値が用いられる。この結果、格納値のデータ長はインデックスキーのデータ長よりも１バイト短縮されるため、特徴管理テーブル９３のデータ量は更に低減される。
ところで、特徴管理テーブル９３において、１個の画像ＩＤに１６個のインデックスキーが関連付けられるため、画像ＩＤとインデックスキーとを一対一対応で関連付ける場合に比べて、インデックスキーを管理するための管理情報はデータ量が増大するが、管理情報以外の特徴管理テーブル９３のデータ量は、前述のように減少するため、管理情報によるデータ量増大分が特徴管理テーブル９３のデータ量を大幅に増大させることはない。
次に、特徴量及び付属情報の両方を登録する場合について説明する。
本実施の形態では、キー管理テーブル９２に、特徴量又は付属情報とインデックスキーとが関連付けて登録されるようにしてあり、特徴管理テーブル９３に、画像ＩＤと、特徴量又は付属情報のインデックスキーとが関連付けて登録されるようにしてある。
付属情報は、特徴量に基づく検索の結果を更に絞込むために用いられる。つまり、類似画像を求めるために、指定画像の特徴量と付属情報とのＡＮＤ検索が実行される。
仮に、キー管理テーブル９２及び特徴管理テーブル９３夫々に、特徴量のインデックスキーのみが登録される場合、付属情報とインデックスキーとが関連付けて登録される付属情報用のキー管理テーブル、及び、画像ＩＤと付属情報のインデックスキーとが関連付けて登録される付属情報管理テーブルを、キー管理テーブル９２及び特徴管理テーブル９３とは別個に夫々設ける必要がある。
この場合、リレーショナル・データベースでは、特徴管理テーブル９３を用いたマッチング処理を行なった後、マッチング処理によって生成された結果テーブル９５と付属情報管理テーブルとを結合してなるテーブルを用いて、特徴量に基づく検索結果の付属情報による絞込み処理を実行しなければならない。この結果、検索時間が増大し、また、ＲＡＭ５２に一時的に記憶されるテーブルのデータ量が増大するという問題がある。
しかしながら、マッチング処理に伴って絞込み処理を実行する場合は、検索時間の増大、及び、ＲＡＭ５２に一時的に記憶されるデータ量の増大を、夫々抑制することが可能になる。
ここでは、画像を作成した作者の名前（以下、ユーザ名という）を付属情報としてキー管理テーブル９２に登録し、また、付属情報のインデックスキーを特徴管理テーブル９３に登録し、更に、特徴量のインデックスキーを介したマッチングを行なって、特徴量に基づく検索結果をユーザ名で絞込む場合について例示する。
付属情報であるユーザ名は、２０バイトのデータ長を有する文字列（以下、２０バイト文字列という）として表される。
また、２０バイト数列である特徴量と２０バイト文字列である付属情報とを区別するために、キー管理テーブル９２に登録される特徴量及び付属情報夫々には、特徴量であるか付属情報であるかを区別するための情報が、特徴量及び付属情報夫々の先頭に付加される。以下では、この情報を先頭情報という。
具体的には、特徴量の先頭１バイトに、特徴量であることを示す先頭情報『００』が付加され、ユーザ名の先頭１バイトには、付属情報であることを示す先頭情報『０１』が付加される。
このようにして、２１バイトのデータ長を有する特徴量及び付属情報夫々は、前述したような２０バイト数列である特徴量をキー管理テーブル９２に登録する手順と同様の手順で、インデックスキーに関連付けられてキー管理テーブル９２に登録される。また、特徴量及び付属情報夫々のインデックスキーは、画像ＩＤに関連付けられて、特徴管理テーブル９３に登録される。
なお、例えば付属情報として作成年月日を用いる場合、作成時点（例えば２００７年１２月１日１４時４１分）とインデックスキーとを一対一対応で関連付けてもよいが、作成時点が含まれる期間（例えば２００７年１２月、２００７年下半期等）とインデックスキーとを関連付けてもよい。
また、付属情報としてユーザ名と作成年月日とを用いる場合、ユーザ名であることを示す先頭情報と、作成年月日であることを示す先頭情報とを異ならせてもよい。
検索作業者は指定画像を指定し、また、付属情報を指定する。
本実施の形態においては、検索作業者は、蓄積部９０に蓄積されている蓄積画像を指定画像として指定する。この場合、まず、蓄積管理テーブル９１が参照されて、指定画像として指定された蓄積画像に関連付けられている画像ＩＤが特定される。ここで特定された画像ＩＤが、検索作業者が指定した指定画像の画像ＩＤである。
画像ＩＤが特定された後、特定された画像ＩＤを除く蓄積画像の画像ＩＤ夫々について、各画像ＩＤが格納されたＩＤフィールドと、投票数“０”が格納された投票数フィールドと、付属情報が一致していることを示す一致情報、及び付属情報が一致していないことを示す不一致情報の何れか一方を格納する一致／不一致フィールドとが関連付けられているレコードが設けられる。
次に、特徴管理テーブル９３が参照され、特定された画像ＩＤに関連付けられているインデックスキーが特定される。ここで特定されたインデックスキーが、検索作業者が指定した指定画像の特徴量のインデックスキー、及び指定画像の付属情報のインデックスキーである。付属情報による絞込みを行なう場合、指定画像の付属情報のインデックスキーを用いてもよく、指定画像の付属情報とは無関係に、検索作業者が直接的に指定した付属情報のインデックスキーを用いてもよいが、以下では、指定画像の付属情報のインデックスキーを用いる場合を説明する。
インデックスキーが特定された後、キー管理テーブル９２が参照され、特定されたインデックスキーの内、特徴量のインデックスキーを用いたマッチング処理が実行される。即ち、特徴量のインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤが特定され、結果テーブル９５にて、特定された画像ＩＤの投票数がインクリメントされる。
図１７は、付属情報による絞込みを行なう場合に生成される結果テーブル９５を説明する模式図である。図に示すように、結果テーブル９５には、ＩＤフィールドと、投票数フィールドと、一致／不一致フィールドとが関連付けられているレコードが設けられている。ただし、図中の画像ＩＤは下４桁が記載されている。
図１７には、マッチングによって、画像ＩＤ『０ｘ０００００００１』（以下、第１の画像ＩＤという）に関連付けて投票数“２０００”という結果が得られ、画像ＩＤ『０ｘ０００００００２』（以下、第２の画像ＩＤという）に関連付けて投票数“３０００”という結果が得られた場合が例示されている。
仮に、付属情報による絞込み処理を実行しない場合は、第２の画像ＩＤを有する蓄積画像が、第１の画像ＩＤを有する蓄積画像よりも優先的に、指定画像の類似画像として出力側端末機７の表示部７３に表示される。
付属情報による絞込みを実行する場合、特徴管理テーブル９３が参照され、特徴量のインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤを特定する手順と同様の手順で、付属情報のインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤが特定され、結果テーブル９５にて、特定された画像ＩＤに関連付けて、一致情報（図１７中「○」）が付与される。一方、付属情報のインデックスキーに一致しないインデックスキーに関連付けられている画像ＩＤには、不一致情報（図１７中「×」）が付与される。
図１７には、絞込みによって、第１の画像ＩＤに関連付けて一致情報が付与され、第２の画像ＩＤに関連付けて不一致情報が付与された場合が例示されている。
以上の結果、付属情報が一致する第１の画像ＩＤを有する蓄積画像が、指定画像の類似画像として蓄積部９０から取得されて、出力側端末機７の表示部７３に表示される。一方、付属情報が一致しない第２の画像ＩＤを有する蓄積画像は、蓄積部９０から取得されることはない。
複数の付属情報（例えばユーザＩＤ、作成年月日及びサイズ）が指定された場合、指定された複数の付属情報夫々について付属情報の一致／不一致が判定される。ＡＮＤ検索（又はＯＲ検索）を行なう場合、全ての付属情報（又は何れか一つの付属情報）が一致する蓄積画像は、類似画像としての表示部７３に表示され、何れか一つの付属情報（又は全ての付属情報）が一致しない蓄積画像は、蓄積部９０から取得されることはない。
ところで、検索作業者が付属情報を直接的に指定する場合、指定された付属情報には、先頭情報『０１』が付加され、この付属情報に一致する付属情報がキー管理テーブル９２に登録されているか否かが判定される。
指定された付属情報がキー管理テーブル９２に登録されていない場合、検索作業者が指定した付属情報が付属する蓄積画像が蓄積部９０に蓄積されていないため、出力側端末機７の表示部７３に、類似画像が存在しないことを示すテキスト、アイコン等が表示される。
指定された付属情報がキー管理テーブル９２に登録されている場合は、指定された付属情報に関連付けられているインデックスキーが特定される。
本実施の形態のように、指定画像として蓄積画像を用いる場合は、検索作業者は、蓄積画像そのものか、又は蓄積画像の画像ＩＤを画像検索装置１に与えればよい。
一方、検索作業者が蓄積画像以外の画像を指定画像として指定する場合は、指定画像の特徴量が抽出され、抽出された特徴量に、特徴量であることを示す情報『００』を付加した上で、この特徴量に一致する特徴量がキー管理テーブル９２に登録されているか否かが判定され、既にキー管理テーブル９２に登録されている特徴量に関連付けられているインデックスキーが特定される。抽出された特徴量の内、まだキー管理テーブル９２に登録されていない特徴量は無視される。何故ならこの特徴量を有する蓄積画像が蓄積部９０に蓄積されていないことが自明だからである。
ところで、蓄積管理テーブル９１には約２32枚の画像を登録することが可能であるが、約２32枚の画像の特徴量及び付属情報の合計数は約２32個を遥かに超過する。このため、複数個のキー管理テーブル９２１，…，９２Ｎと、これら夫々に対応する複数個の特徴管理テーブル９３１，…，９３Ｎとの組が設けられる。以下では、付属情報に係る説明は適宜に省略する。
ｎ個目のキー管理テーブル９２ｎのレコード件数が約２32件に達して（又は約２32件に近づいて）、キー管理テーブル９２ｎに新たな特徴量及びインデックスキーを登録することができなくなった場合（以下、満杯になった場合という）、満杯になったキー管理テーブル９２ｎと、このキー管理テーブル９２ｎに対応する特徴管理テーブル９３ｎとの組を、新規登録が終了している各種管理テーブルとするテーブル情報が情報管理テーブル９４に登録される。
また、ｎ＋１個目のキー管理テーブル９２ｎ＋１と、このキー管理テーブル９２ｎ＋１に対応する特徴管理テーブル９３ｎ＋１との組が新たに設けられ、これらの各種管理テーブルを、新規登録すべき各種管理テーブルとするテーブル情報が情報管理テーブル９４に登録される。
以下では、インデックスキーを新規登録すべきキー管理テーブル及び特徴管理テーブルの組を現行の各種管理テーブルの組といい、新規登録が終了しているキー管理テーブル及び特徴管理テーブルの組を先代の各種管理テーブルの組という。
また、以下では、先代の各種管理テーブルとして１個目のキー管理テーブル９２１及び特徴管理テーブル９３１の組と２個目のキー管理テーブル９２２及び特徴管理テーブル９３２の組とを例示し、現行の各種管理テーブルとして３個目のキー管理テーブル９２３及び特徴管理テーブル９３３の組を例示する。キー管理テーブル９２１，９２２，９２３（及び特徴管理テーブル９３１，９３２，９３３）は、この順に生成されるものとする。
検索作業者によって、蓄積画像である指定画像が指定された場合、結果テーブル９５には、キー管理テーブル９２１〜９２３に登録されている指定画像の画像ＩＤ以外の画像ＩＤ夫々が格納されたＩＤフィールドと、投票数“０”が格納された投票数フィールドとが関連付けられているレコードが設けられる。
また、指定された指定画像の画像ＩＤが特徴管理テーブル９３３に登録されているか否かを判定し、登録されていない場合は、特徴管理テーブル９３２に登録されているか否かを判定し、更に登録されていない場合は、特徴管理テーブル９３１に登録されているか否かを判定して、指定画像の画像ＩＤに関連付けられているインデックスキーが特定される。
更にまた、特定されたインデックスキーについて、まず、指定された指定画像の画像ＩＤが登録されている特徴管理テーブル（例えば、特徴管理テーブル９３２）に関してマッチング処理が実行される。即ち、特徴管理テーブル９３２が参照され、特定されたインデックスキーに一致するインデックスキーに関連付けられている画像ＩＤが特定され、結果テーブル９５にて、特定された画像ＩＤの投票数がインクリメントされる。
特徴管理テーブル９３２に関するマッチング処理が終了した後、キー管理テーブル９２２が参照され、指定画像に係るインデックスキーに関連付けられている特徴量が探し出される。
次に、指定された指定画像の画像ＩＤが登録されていない特徴管理テーブル（例えば、特徴管理テーブル９３３）に対応するキー管理テーブル９２３が参照されて、探し出された特徴量に関連付けられているインデックスキーが特定され、特定されたインデックスキーについて、特徴管理テーブル９３３に関してマッチング処理が実行される。
最後に、指定された指定画像の画像ＩＤが登録されていない他の特徴管理テーブル（この場合、特徴管理テーブル９３１）に対応するキー管理テーブル９２１が参照されて、探し出された特徴量に関連付けられているインデックスキーが特定され、特定されたインデックスキーについて、特徴管理テーブル９３１に関してマッチング処理が実行される。
つまり、一の特徴管理テーブルにてマッチングを行なった後で、一のキー管理テーブルに登録されているインデックスキーを一旦特徴量に戻し、他のキー管理テーブルに登録されているインデックスキーに再変換してから他の特徴管理テーブルにてマッチングを行なう手順が繰り返される。このことによって、複数個の特徴管理テーブル９３１〜９３Ｎに亘ってマッチング処理が実行され、マッチングの結果である投票数の多寡に応じて、指定画像の類似画像が取得されて表示される。
なお、一のキー管理テーブルに登録されているインデックスキーを一旦特徴量に戻す処理、及び／又は、戻した特徴量を他のキー管理テーブルに登録されているインデックスキーに再変換する処理は、一の特徴管理テーブルにてマッチングを行なう前に予め実行しておいて、一のキー管理テーブルに登録されているインデックスキーとは別個に、戻した特徴量及び／又は再変換したインデックスキーを記憶しておいてもよい。
また、ｎ個目のキー管理テーブル９２ｎが満杯になってから、ｎ個目のキー管理テーブル９２ｎ及び特徴管理テーブル９３ｎの組を先代の各種管理テーブルとし、更にｎ＋１個目のキー管理テーブル９２ｎ＋１及び特徴管理テーブル９３ｎ＋１の組を現行の各種管理テーブルとして新たに生成する（以下、世代交代するという）構成のみならず、所定の期間毎（例えば１ヶ月毎、四半期毎、半年毎等）に世代交代する構成でもよい。
キー管理テーブル９２１〜９２Ｎ及び特徴管理テーブル９３１〜９３Ｎの組の個数が増加するに従い、Ｎ個の特徴管理テーブル９３１〜９３Ｎに亘るマッチングは長時間を要するようになる。しかしながら、古い蓄積画像は検索作業者が所望する画像である可能性が低い。
このため、古い蓄積画像（例えば蓄積されてから所定の年数が経過した蓄積画像）の画像ＩＤ及び特徴量が登録されているキー管理テーブル９２１〜９２ｎ及び特徴管理テーブル９３１〜９３ｎの組は画像の検索に用いず、キー管理テーブル９２ｎ＋１〜９２Ｎ及び特徴管理テーブル９３ｎ＋１〜９３Ｎの組を画像の検索に用いることが考えられる。この場合、キー管理テーブル９２１〜９２ｎ及び特徴管理テーブル９３１〜９３ｎの組と、これらの各種管理テーブルに関連付けて情報管理テーブル９４に登録されているテーブル情報とは、ＨＤＤ３３から、ＨＤＤ３３よりも大容量且つ読み書きの速度が遅い他の二次記憶装置へ移動させてもよい。
また、最も新しいキー管理テーブル及び特徴管理テーブルの組のみが画像の検索に用いられる構成でもよく、検索作業者が日付の範囲を指定し、指定された日付の範囲以内に生成されたキー管理テーブル及び特徴管理テーブルの組が画像の検索に用いられる構成でもよい。
以上のような場合、画像の検索に用いるべき各種管理テーブルが限定されるため、全ての各種管理テーブルを画像の検索に用いる場合と比べて、検索時間が短縮される。
なお、各種管理テーブルを他の二次記憶装置へ移動させる場合は、対応する蓄積画像及び蓄積管理テーブル９１の登録内容をＨＤＤ２３から他の二次記憶装置へ移動させることが望ましい。また、これらの各種管理テーブル及び蓄積画像は、圧縮してから他の二次記憶装置に記憶させてもよい。
ところで、ｎ個目のキー管理テーブル９２ｎが満杯になってから新たにｎ＋１個目のキー管理テーブル９２ｎ＋１及び特徴管理テーブル９３ｎ＋１の組を生成する場合は、ｎ＋１個目のキー管理テーブル９２ｎ＋１に登録すべき特徴量が既にキー管理テーブル９２ｎ以前のキー管理テーブルに登録されているか否かに関わらず、『０ｘ０００００００１』から順に連番で採番されたインデックスキーを発行することが最も簡単である。
しかしながら、例えば所定の期間毎に、ｎ個目のキー管理テーブル９２ｎ及び特徴管理テーブル９３ｎの組を先代の各種管理テーブルとして、新たにｎ＋１個目のキー管理テーブル９２ｎ＋１及び特徴管理テーブル９３ｎ＋１の組を生成する場合は、キー管理テーブル９２ｎが満杯になっていないことがある。
例えば新年度開始日にキー管理テーブル９２１及び特徴管理テーブル９３１の組を先代の各種管理テーブルとして、新たにキー管理テーブル９２２及び特徴管理テーブル９３２の組が生成され、翌年の新年度開始日にキー管理テーブル９２２及び特徴管理テーブル９３２の組を先代の各種管理テーブルとして、新たにキー管理テーブル９２３及び特徴管理テーブル９３３の組が生成されたとする。
この場合、キー管理テーブル９２１が満杯になっていなければ、キー管理テーブル９２１にキー管理テーブル９２２をマージ（即ち併合）し、特徴管理テーブル９３１に特徴管理テーブル９３２をマージすることが可能である。
以下では、１個目のキー管理テーブル９２１に２個目のキー管理テーブル９２２をマージしてなるキー管理テーブルをキー併合テーブル９２０といい、１個目の特徴管理テーブル９３１に２個目の特徴管理テーブル９３２をマージしてなる特徴管理テーブルを特徴併合テーブル９３０という。
キー管理テーブル９２１，９２２の両方に重複して登録されている特徴量（即ち、同一の特徴量でありながらキー管理テーブル９２１，９２２にて異なるインデックスキーに関連付けられてる特徴量）は、マージによって１個のインデックスキーに関連付けられるため、キー併合テーブル９２０のデータ量は、キー管理テーブル９２１，９２２のデータ量の合計よりも減少する。
また、画像を検索する際は、特徴管理テーブル９３１及び特徴管理テーブル９３２の両方に亘ってマッチングを実行せずに、１個の特徴併合テーブル９３０を用いてマッチングを実行することができる。従って、インデックスキーを特徴量に戻してから再変換する処理が不要になり、検索時間が短縮される。
マージを行なう場合、キー管理テーブル９２１に登録されている特徴量とこの特徴量のインデックスキーとは、インデックスキーを変更することなくキー併合テーブル９２０に登録される。同様に、特徴管理テーブル９３１に登録されている画像ＩＤと、この画像ＩＤに関連付けられているインデックスキーとは、インデックスキーを変更することなく特徴併合テーブル９３０に登録される。
また、新しいキー管理テーブル９２２に登録されていて古いキー管理テーブル９２１に登録されていない特徴量については、この特徴量に対し、キー管理テーブル９２１にてまだ特徴量に関連付けられていない（即ち使用されていない）インデックスキー（以下、旧インデックスキーという）が発行され、発行された旧インデックスキーと特徴量とが関連付けられて、キー併合テーブル９２０に登録される。ただし、ここで発行される旧インデックスキーは、この特徴量に関連付けて新しいキー管理テーブル９２２に登録されているインデックスキー（以下、新インデックスキーという）と同じハッシュ値を有していなければならない。
この後、特徴管理テーブル９３２に登録されている画像ＩＤと、この画像ＩＤに関連付けられている新インデックスキーに対応する旧インデックスキーとが、特徴併合テーブル９３０に登録される。新旧のインデックスキーはハッシュ値が等しいため、特徴併合テーブル９３０においても、旧インデックスキーが格納されるキーフィールドのフィールド値は、新インデックスキーが格納されていたキーフィールドのフィールド値に等しい。
新インデックスキーから旧インデックスキーへの変換処理としては、キー管理テーブル９２１にて使用されているインデックスキーの最大値よりも大きく、且つ、ハッシュ値が『０ｘ０』である値ｍを新インデックスキーに加算する処理が最も簡単である。
一方、キー管理テーブル９２１，９２２の両方に登録されている特徴量については、この特徴量に対して改めてインデックスキーを発行する必要はない。
しかしながら、同一の特徴量に対してキー管理テーブル９２１にて関連付けられている旧インデックスキーとキー管理テーブル９２２にて関連付けられている新インデックスキーとは異なる。このため、特徴管理テーブル９３２に登録されている画像ＩＤと、この画像ＩＤに関連付けられている新インデックスキーに対応する旧インデックスキーとを、特徴併合テーブル９３０に登録する必要がある。
新旧のインデックスキー夫々が有するハッシュ値が等しい場合、特徴管理テーブル９３１において旧インデックスキーが格納されているキーフィールドのフィールド値と、特徴管理テーブル９３２において新インデックスキーが格納されているキーフィールドのフィールド値とは等しい。このため、特徴管理テーブル９３２の各レコードについて、新インデックスキーを旧インデックスキーに変換したレコードを特徴併合テーブル９３０に単純に挿入することが可能である。
ところが、第１及び第２のインデックスキー夫々が有するハッシュ値が異なる場合、特徴管理テーブル９３１において旧インデックスキーが格納されているキーフィールドのフィールド値と、特徴管理テーブル９３２において新インデックスキーが格納されているキーフィールドのフィールド値とが異なるため、レコードの単純な挿入が不可能である。従って、インデックスキーを格納すべきキーフィールドを逐一変更していく必要があり、正確なマージが困難であるという問題がある。
この問題を解決するために、画像の登録の際、キー管理テーブル９２１に既に登録されている特徴量と同じ特徴量をキー管理テーブル９２２に登録する場合に、発行するインデックスキーを工夫しておく必要がある。具体的には、キー管理テーブル９２１に既に登録されている特徴量のインデックスキーと同じハッシュ値を有し、且つ、キー管理テーブル９２２にて未使用のインデックスキーが発行され、発行されたインデックスキーと、この特徴量とが関連付けられて、キー管理テーブル９２２に登録される。
キー併合テーブル９２０及び特徴併合テーブル９３０には、更に３個目のキー管理テーブル９２３及び特徴管理テーブル９３３が夫々マージされてもよく、３個目のキー管理テーブル９２３及び特徴管理テーブル９３３に４個目のキー管理テーブル９２４及び特徴管理テーブル９３４が夫々マージされてなる２個目のキー併合テーブル９２０及び特徴併合テーブル９３０が新たに生成されてもよい。
ｎ＋１個の各種管理テーブルをマージする場合は、画像の登録の際、キー管理テーブル９２１〜９２ｎに既に登録されている特徴量と同じ特徴量をキー管理テーブル９２ｎ＋１に登録する場合に、発行するインデックスキーを工夫しておく必要がある。具体的には、キー管理テーブル９２１〜９２ｎに既に登録されている特徴量のインデックスキーと同じハッシュ値を有し、且つ、キー管理テーブル９２ｎ＋１にて未使用のインデックスキーが発行され、発行されたインデックスキーと、この特徴量とが関連付けられて、キー管理テーブル９２ｎ＋１に登録される。
キー管理テーブル９２１，９２２及び特徴管理テーブル９３１，９３２が夫々マージされてキー併合テーブル９２０及び特徴併合テーブル９３０が生成された後、キー管理テーブル９２１，９２２及び特徴管理テーブル９３１，９３２は削除され、また、各種管理テーブルのマージ及び削除に応じて、情報管理テーブル９４に登録されているテーブル情報が適切に更新される。
生成されたキー併合テーブル９２０及び特徴併合テーブル９３０が他の二次記憶装置へ移動された場合、これらに対応して情報管理テーブル９４に登録されているテーブル情報も他の二次記憶装置へ移動される。更に、特徴併合テーブル９３０に登録されている画像ＩＤを有する蓄積画像と蓄積管理テーブル９１の登録内容とが他の二次記憶装置へ移動される。
なお、テーブルのマージは、画像の登録又は検索が実行されない時間（例えば夜間、休日等）に実行されることが望ましい。
また、キー管理テーブル９２１にキー管理テーブル９２２に登録されているレコードを全てマージすることができない場合は、キー管理テーブル９２１，９２２の両方に登録されている特徴量を格納しているレコードを優先的にマージすることが望ましい。
更に、マージされたキー管理テーブルにて、同一の特徴量に異なる複数個のインデックスキーが関連付けられており、しかも、複数個のインデックスキーを同一のインデックスキーに変換することが困難である場合は、例えばマッチングの際に、１個の特徴量に対して複数個のインデックスキー全てを特定する必要がある。
次に、図８〜図１３に示す各種処理について説明する。
現行のキー管理テーブルが満杯である場合、現行のキー管理テーブルには特徴量及びインデックスキーを登録することができないので、キー管理テーブル及び特徴管理テーブルの組を世代交代する必要がある。具体的には、登録側受信処理のＳ４４の処理で受信した特徴量の個数が、現行のキー管理テーブルに挿入可能なレコードの残り件数を超過している場合、現行のキー管理テーブルが満杯であると判定される。
また、所定の期間ごとに世代交代をする場合、付属情報として用いられている作成年月日、登録年月日等、又は、検索ＤＢサーバ３が備える図示しないタイマが計時した年月日等が、世代交代すべき所定のタイミングを過ぎている（例えば毎月１日に世代交代するならば、現行の各種管理テーブルの組が作成された月の翌月１日以降である）ときは、キー管理テーブル及び特徴管理テーブルの組を世代交代する必要がある。
図８に示すテーブル管理処理においては、検索ＤＢサーバ３のＣＰＵ３０は、キー管理テーブル及び特徴管理テーブルの組を世代交代するか否かを判定する（Ｓ５１）。
世代交代をする場合（Ｓ５１でＹＥＳ）、ＣＰＵ３０は、現行の各種管理テーブルの組（例えばキー管理テーブル９２２及び特徴管理テーブル９３２の組）が先代の管理テーブルの組となるよう情報管理テーブル９４に登録されているテーブル情報を更新する（Ｓ５２）
次いで、ＣＰＵ３０は新たな各種管理テーブルの組（この場合、キー管理テーブル９２３及び特徴管理テーブル９３３の組）を生成し（Ｓ５３）、新たな各種管理テーブルの組が現行の管理テーブルの組となるよう情報管理テーブル９４にテーブル情報を登録する（Ｓ５４）
Ｓ５４の処理完了後、又は世代交代をしない場合（Ｓ５１でＮＯ）、ＣＰＵ３０は、現行の各種管理テーブルの組を対象に登録実行処理を行なうサブルーチン（図９〜図１１参照）を呼び出し、実行する（Ｓ５５）。
Ｓ５５の処理完了後、ＣＰＵ３０は処理を登録側受信処理のルーチンへ戻す。
以下では、現行の各種管理テーブルの組として、キー管理テーブル９２３及び特徴管理テーブル９３３の組を例示し、先代の各種管理テーブルの組として、キー管理テーブル９２１，９２２及び特徴管理テーブル９３１，９３２の組を例示する。
図９〜図１１に示す登録実行処理においては、検索ＤＢサーバ３のＣＰＵ３０は、登録側受信処理のＳ４４で受信した特徴量と付属情報とに、夫々先頭情報『００』と先頭情報『０１』とを付加し（Ｓ６１）、処理をＳ６２へ移す。
ＣＰＵ３０は、先頭情報が付加された特徴量（又は付属情報）の内の１つを適宜に選択し（Ｓ６２）、選択した特徴量（又は付属情報）が、現行のキー管理テーブル９２３に既に登録されているか否かを判定する（Ｓ６３）。このためにＣＰＵ３０は、現行のキー管理テーブル９２３の特徴量フィールドを検索して、Ｓ６２の処理で選択した特徴量（又は付属情報）に一致する特徴量（又は付属情報）が存在するか否かを判定する。
Ｓ６２の処理で選択した特徴量（又は付属情報）が現行のキー管理テーブル９２３に既に登録されている場合（Ｓ６３でＹＥＳ）、Ｓ６２の処理で選択した特徴量（又は付属情報）を、既登録の特徴量（又は付属情報）として記憶し（Ｓ６４）、まだ登録されていない場合（Ｓ６３でＮＯ）、未登録の特徴量（又は付属情報）として記憶する（Ｓ６５）。
Ｓ６４又はＳ６５の処理完了後、ＣＰＵ３０は、Ｓ４４で受信した特徴量及び付属情報が全てＳ６２の処理で選択されたか否かを判定し（Ｓ６６）、まだ選択されていない特徴量又は付属情報が存在する場合は（Ｓ６６でＮＯ）、処理をＳ６２へ戻す。
Ｓ４４で受信した特徴量及び付属情報が全てＳ６２の処理で選択された場合（Ｓ６６でＹＥＳ）、Ｓ４４で受信した特徴量及び付属情報が全て既登録及び未登録の何れか一つに分類されたため、ＣＰＵ３０は処理をＳ６７へ移す。
ＣＰＵ３０は、Ｓ４４で受信した画像ＩＤを格納した１個のＩＤフィールドと、キー未格納情報を夫々格納したＭ個（本実施の形態では１６個）のキーフィールドとが関連付けられている１件のレコード（以下、特徴管理レコードという）を生成して（Ｓ６７）、ＲＡＭ３２に一時的に記憶させる。
Ｓ６７の処理完了後、ＣＰＵ３０は、Ｓ６４の処理で既登録に分類された特徴量及び付属情報を処理対象にして、特徴管理格納処理を行なうサブルーチン（図１２参照）を呼び出し、実行する（Ｓ６８）。
Ｓ６８の処理完了後、ＣＰＵ３０はＳ８１へ処理を戻す。
図１２に示す特徴管理格納処理においては、検索ＤＢサーバ３のＣＰＵ３０は、処理対象である特徴量（又は付属情報）の内の１つを適宜に選択し（Ｓ７１）、現行のキー管理テーブル９２３を参照して、Ｓ７１で選択した特徴量（又は付属情報）に一致する特徴量（又は付属情報）に関連付けられているインデックスキーを特定し（Ｓ７２）、特定したインデックスキーのハッシュ値を算出する（Ｓ７３）。
次に、ＣＰＵ３０は、Ｓ７３で算出したハッシュ値に等しいフィールド値が付与されている空きキーフィールドが、ＲＡＭ３２に記憶されている特徴管理レコードに存在するか否かを判定し（Ｓ７４）、存在しない場合は（Ｓ７４でＮＯ）、新たな特徴管理レコードを生成して（Ｓ７５）、ＲＡＭ３２に一時的に記憶させる。
Ｓ７５の処理完了後、又は、Ｓ７３で算出したハッシュ値に等しいフィールド値が付与されている空きキーフィールドが、ＲＡＭ３２に記憶されている特徴管理レコードに存在する場合（Ｓ７４でＹＥＳ）、ＣＰＵ３０は、Ｓ７３で算出したハッシュ値に等しいフィールド値が付与されている空きキーフィールドに、Ｓ７２で特定したインデックスキーを格納する（Ｓ７６）。ただし、Ｓ７３で算出したハッシュ値に等しいフィールド値が付与されている空きキーフィールドが、ＲＡＭ３２に記憶されている複数の特徴管理レコードに存在する場合、ＣＰＵ３０は、既に埋まっているキーフィールドの個数が最も多い特徴管理レコードに、Ｓ７２で特定したインデックスキーを格納する。
Ｓ７６の処理完了後、ＣＰＵ３０は、処理対象である特徴量及び付属情報が全てＳ７１で選択されたか否かを判定し（Ｓ７７）、まだ選択されていない特徴量又は付属情報が存在する場合は（Ｓ７７でＮＯ）、処理をＳ７１へ戻す。
処理対象である特徴量及び付属情報が全てＳ７１で選択された場合（Ｓ７７でＹＥＳ）、これらの特徴量及び付属情報夫々のインデックスキーが全て特徴管理レコードに格納されたため、ＣＰＵ３０は、処理を登録実行処理のルーチンへ戻す。
Ｓ６８で呼び出した特徴管理格納処理の処理完了後、検索ＤＢサーバ３のＣＰＵ３０は、図９に示すように、Ｓ６５の処理で未登録に分類された特徴量及び付属情報が存在するか否かを判定し（Ｓ８１）、存在する場合（Ｓ８１でＹＥＳ）、情報管理テーブル９４を参照して、先代の各種管理テーブルの組が存在するか否かを判定する（Ｓ８２）。
先代の各種管理テーブルの組が存在する場合（Ｓ８２でＹＥＳ）、ＣＰＵ３０は、図１０に示すように、Ｓ６５の処理で未登録に分類された特徴量（又は付属情報）の内の１つを適宜に選択し（Ｓ８３）、選択した特徴量（又は付属情報）が、先代のキー管理テーブル９２１，９２２に既に登録されているか否かを判定する（Ｓ８４）。このためにＣＰＵ３０は、先代のキー管理テーブル９２１，９２２夫々の特徴量フィールドを検索して、Ｓ８３で選択した特徴量（又は付属情報）に一致する特徴量（又は付属情報）が存在するか否かを判定する。
Ｓ８３で選択した特徴量（又は付属情報）が先代のキー管理テーブル９２１，９２２に既に登録されている場合（Ｓ８４でＹＥＳ）、登録されている特徴量（又は付属情報）に関連付けられているインデックスキーのハッシュ値を算出し（Ｓ８５）、Ｓ８３で選択した特徴量（又は付属情報）を既登録の特徴量（又は付属情報）として、Ｓ８５で算出したハッシュ値に対応付けてＲＡＭ３２に一時的に記憶させ（Ｓ８６）、処理をＳ８７へ移す。
Ｓ８３で選択した特徴量（又は付属情報）が先代のキー管理テーブル９２１，９２２にまだ登録されていない場合（Ｓ８４でＮＯ）、ＣＰＵ３０は処理をＳ８７へ移す。この場合、Ｓ８３で選択した特徴量（又は付属情報）は未登録の特徴量のままである。
Ｓ８４でＮＯの場合、又はＳ８６の処理完了後、ＣＰＵ３０は、Ｓ６５の処理で未登録に分類された特徴量及び付属情報が全てＳ８３で選択されたか否かを判定し（Ｓ８７）、まだ選択されていない特徴量又は付属情報が存在する場合は（Ｓ８７でＮＯ）、処理をＳ８３へ戻す。
Ｓ６５の処理で未登録に分類された特徴量及び付属情報が全てＳ８３で選択された場合（Ｓ８７でＹＥＳ）、ＣＰＵ３０は、Ｓ８６の処理で既登録に分類された特徴量及び付属情報と、これらの特徴量及び付属情報夫々に関連付けられているハッシュ値（即ちＳ８５で算出したハッシュ値）とを処理対象にして、キー管理格納処理を行なうサブルーチン（図１３参照）を呼び出し、実行する（Ｓ８８）。
Ｓ６８の処理完了後、ＣＰＵ３０はＳ１１１へ処理を戻す。
図１３に示すキー管理格納処理においては、検索ＤＢサーバ３のＣＰＵ３０は、処理対象である特徴量（又は付属情報）の内の１つを適宜に選択し（Ｓ９１）、現行のキー管理テーブル９２３を参照して、選択した特徴量（又は付属情報）に対応付けられているハッシュ値に等しいインデックスキーが格納されている空きキー管理レコードが存在するか否かを判定する（Ｓ９２）。
このような空きキー管理レコードが存在しない場合（Ｓ９２でＮＯ）、ＣＰＵ３０は、Ｓ９１で選択した特徴量（又は付属情報）に対応付けられているハッシュ値に等しいハッシュ値を有し、且つ、現行のキー管理テーブル９２３でまだ使用されていないインデックスキーを発行する（Ｓ９３）。
Ｓ９３の処理完了後、ＣＰＵ３０は、現行のキー管理テーブル９２３で既に使用されているインデックスキーの最大値とＳ９３で発行したインデックスキーとが連番であるか否かを判定し（Ｓ９４）、連番ではない場合（Ｓ９４でＮＯ）、現行のキー管理テーブル９２３で既に使用されているインデックスキーの最大値とＳ９３で発行したインデックスキーとの中間のインデックスキーを、空きキー管理レコードに格納するためのインデックスキーとして発行する（Ｓ９５）。
Ｓ９５の処理完了後、ＣＰＵ３０は、Ｓ９５で発行したインデックスキーと特徴未格納情報とが格納されている空きキー管理レコードを現行のキー管理テーブル９２３に挿入する（Ｓ９６）。
Ｓ９６の処理完了後、又は、現行のキー管理テーブル９２３で既に使用されているインデックスキーの最大値とＳ９３で発行したインデックスキーとが連番である場合（Ｓ９４でＹＥＳ）、ＣＰＵ３０は、Ｓ９３で発行したインデックスキーとＳ９１で選択された特徴量（又は付属情報）とが格納されているレコード（以下、キー管理レコードという）を現行のキー管理テーブル９２３に挿入して（Ｓ９７）、処理をＳ９９へ移す。
Ｓ９１で選択した特徴量（又は付属情報）に対応付けられているハッシュ値に等しいインデックスキーが格納されている空きキー管理レコードが存在する場合（Ｓ９２でＹＥＳ）、ＣＰＵ３０は、Ｓ９２で存在すると判定された空きキー管理レコードの内、最も小さいインデックスキーが格納されている空きキー管理レコードを、このインデックスキーとＳ９１で選択された特徴量（又は付属情報）とが格納されているキー管理レコードに更新して（Ｓ９８）、処理をＳ９９へ移す。
Ｓ９７又はＳ９８の処理完了後、ＣＰＵ３０は、処理対象である特徴量及び付属情報が全てＳ９１で選択されたか否かを判定し（Ｓ９９）、まだ選択されていない特徴量又は付属情報が存在する場合は（Ｓ９９でＮＯ）、処理をＳ９１へ戻す。
処理対象である特徴量及び付属情報が全てＳ９１で選択された場合（Ｓ９９でＹＥＳ）、ＣＰＵ３０は、処理を登録実行処理のルーチンへ戻す。
Ｓ８８で呼び出したキー管理格納処理の処理完了後、図１０に示すように、検索ＤＢサーバ３のＣＰＵ３０は、Ｓ８６の処理で既登録に分類された特徴量及び付属情報を処理対象にして、特徴管理格納処理を行なうサブルーチン（図１２参照）を呼び出し、実行する（Ｓ１１１）。Ｓ１１１で呼び出した特徴管理格納処理の実行手順は、処理対象となる特徴量及び付属情報が異なる以外は、Ｓ６８で呼び出した特徴管理格納処理の実行手順と同様である。
Ｓ１１１の処理完了後、ＣＰＵ３０は、Ｓ８６の処理完了後にも未登録に分類されている特徴量及び付属情報が存在するか否かを判定し（Ｓ１１２）、存在する場合（Ｓ１１２でＹＥＳ）、処理をＳ１１３へ移す。
ＣＰＵ３０は、図１１に示すように、Ｓ８６の処理完了後にも未登録に分類されている特徴量（又は付属情報）の内の１つを適宜に選択し（Ｓ１１３）、ＲＡＭ３２に記憶されている特徴管理レコードに空きキーフィールドが存在するか否かを判定する（Ｓ１１４）。空きキーフィールドが存在する場合（Ｓ１１４でＹＥＳ）、空きキーフィールドのフィールド値をハッシュ値として決定し（Ｓ１１５）、Ｓ１１３で選択した特徴量（又は付属情報）を既登録の特徴量（又は付属情報）として、Ｓ１１５で算出したハッシュ値に対応付けてＲＡＭ３２に一時的に記憶させ（Ｓ１１６）、処理をＳ１１７へ移す。
ＲＡＭ３２に記憶されている特徴管理レコードに空きキーフィールドが存在しない場合（Ｓ１１４でＮＯ）、ＣＰＵ３０は処理をＳ１１７へ移す。この場合、Ｓ１１３で選択した特徴量（又は付属情報）は未登録の特徴量のままである。
Ｓ１１６の処理完了後、又は、Ｓ１１４でＮＯの場合、ＣＰＵ３０は、Ｓ８６の処理完了後にも未登録に分類されている特徴量及び付属情報が全てＳ１１３で選択されたか否かを判定し（Ｓ１１７）、まだ選択されていない特徴量又は付属情報が存在する場合は（Ｓ１１７でＮＯ）、処理をＳ１１３へ戻す。
Ｓ８６の処理完了後にも未登録に分類されている特徴量及び付属情報が全てＳ１１３で選択された場合（Ｓ１１７でＹＥＳ）、ＣＰＵ３０は、Ｓ１１６の処理で既登録に分類された特徴量及び付属情報と、この特徴量及び付属情報に対応付けてＳ１１５で決定されたハッシュ値とを処理対象にして、キー管理格納処理を行なうサブルーチン（図１３参照）を呼び出し、実行する（Ｓ１１８）。Ｓ１１８で呼び出したキー管理格納処理の実行手順は、処理対象となる特徴量及び付属情報とハッシュ値とが異なる以外は、Ｓ８８で呼び出したキー管理格納処理の実行手順と同様である。
Ｓ１１８で呼び出したキー管理格納処理の処理完了後、ＣＰＵ３０は、Ｓ１１６の処理で既登録に分類された特徴量及び付属情報を処理対象にして、特徴管理格納処理を行なうサブルーチン（図１２参照）を呼び出し、実行する（Ｓ１１９）。Ｓ１１９で呼び出した特徴管理格納処理の実行手順は、処理対象となる特徴量及び付属情報が異なる以外は、Ｓ６８又はＳ１１１で呼び出した特徴管理格納処理の実行手順と同様である。
Ｓ１１９の処理完了後、ＣＰＵ３０は、Ｓ１１６の処理完了後にも未登録に分類されている特徴量及び付属情報が存在するか否かを判定し（Ｓ１２０）、存在する場合（Ｓ１２０でＹＥＳ）、残った全ての未登録の特徴量及び付属情報夫々について、適切なハッシュ値を決定し（Ｓ１２１）、処理をＳ１２２へ移す。Ｓ１２１で決定されるハッシュ値は、例えば、現行のキー管理テーブル９２３で既に使用されているインデックスキーの最大値より大きい連番のハッシュ値である。
ＣＰＵ３０は、Ｓ１１６の処理完了後にも未登録に分類されている特徴量及び付属情報とＳ１２１で決定したハッシュ値とを処理対象にして、キー管理格納処理を行なうサブルーチン（図１３参照）を呼び出し、実行する（Ｓ１２２）。Ｓ１２２で呼び出したキー管理格納処理の実行手順は、処理対象となる特徴量及び付属情報とハッシュ値とが異なる以外は、Ｓ８８又はＳ１１８で呼び出したキー管理格納処理の実行手順と同様である。
Ｓ１２２で呼び出したキー管理格納処理の処理完了後、ＣＰＵ３０は、Ｓ１１６の処理完了後にも未登録に分類されている特徴量及び付属情報を処理対象にして、特徴管理格納処理を行なうサブルーチン（図１２参照）を呼び出し、実行する（Ｓ１２３）。Ｓ１２３で呼び出した特徴管理格納処理の実行手順は、処理対象となる特徴量及び付属情報が異なる以外は、Ｓ６８、Ｓ１１１又はＳ１１９で呼び出した特徴管理格納処理の実行手順と同様である。
Ｓ１２３で呼び出した特徴管理格納処理の処理完了後、ＣＰＵ３０は、ＲＡＭ３２に記憶されている特徴管理レコードを、全て現行の特徴管理テーブル９３３に挿入し（Ｓ１２４）、処理をテーブル管理処理のルーチンへ戻す。
ところで、現行の各種管理テーブルの組が１個目のキー管理テーブル９２１及び特徴管理テーブル９３１の組である場合は、図９に示すように、先代の各種管理テーブルの組が存在しないため（Ｓ８２でＮＯ）、ＣＰＵ３０は処理をＳ１１３へ移す。
また、Ｓ６５の処理で未登録に分類された特徴量及び付属情報が存在しない場合（Ｓ８１でＮＯ）、全ての特徴量及び付属情報夫々のインデックスキーが全て特徴管理レコードに格納されたため、処理をＳ１２４へ移す。
更にまた、図１０に示すように、Ｓ８６の処理で全ての特徴量及び付属情報が既登録に分類されており、未登録に分類されている特徴量及び付属情報が存在しない場合（Ｓ１１２でＮＯ）、全ての特徴量及び付属情報夫々のインデックスキーが全て特徴管理レコードに格納されたため、処理をＳ１２４へ移す。
また、図１１に示すように、Ｓ１１６の処理完了後、未登録に分類されている特徴量及び付属情報が存在しない場合（Ｓ１２０でＮＯ）、全ての特徴量及び付属情報夫々のインデックスキーが全て特徴管理レコードに格納されたため、処理をＳ１２４へ移す。
このような登録実行処理におけるＣＰＵ３０は、登録判定手段、キー発行手段、キー管理登録手段、特徴管理登録手段、第２の登録判定手段、第２のキー発行手段、第２のキー管理登録手段、及び第２の特徴管理登録手段として機能する。
以上のような各処理を実行することによって、画像検索装置１に画像が登録される。つまり、蓄積側受信処理及び蓄積実行処理を実行するＣＰＵ２０、登録側受信処理、テーブル管理処理、登録実行処理、特徴管理格納処理及びキー管理登録処理を実行するＣＰＵ３０、抽出側受信処理及び特徴抽出処理を実行するＣＰＵ４０、並びに画像読込処理を実行するＣＰＵ６０は、画像登録手段として機能する。
図１８及び図１９は、検索ＤＢサーバ３で実行される併合実行処理の手順を示すフローチャートである。以下では、ｎ個の先代のキー管理テーブル９２１〜９２ｎ及び特徴管理テーブル９３１〜９３ｎの中から、マージすべきＫ（２≦Ｋ≦ｎの自然数）個の先代のキー管理テーブル９２１〜９２Ｋ及び特徴管理テーブル９３１〜９３Ｋを登録作業者が指定する場合を例示する。なお、マージすべきＫ個の先代の各種管理テーブルを、例えば先代のｎ個の先代の各種管理テーブル夫々の作成年月日に基づいてＣＰＵ３０が決定する構成でもよい。
ＣＰＵ３０は、マージすべき先代の各種管理テーブルの範囲を受け付ける（Ｓ１３１）。この場合、ＣＰＵ３０は、例えば入力側端末機６に、情報管理テーブル９４に記憶してあるテーブル情報を送信し、入力側端末機６では、受信したテーブル情報に基づいて、マージすべき先代の各種管理テーブルの範囲を登録作業者に入力させるための画面を表示させる。登録作業者は、表示部６３に表示された画面を視認しながら、マージすべき範囲（例えばマージすべき各種管理テーブルのファイル名、作成日時等）を入力する。入力側端末機６は、入力された範囲を示す情報を検索ＤＢサーバへ送信する。ＣＰＵ３０は、受信した情報に基づいて、マージすべき各種管理テーブルの個数Ｋを決定する。
Ｓ１３１の処理完了後、ＣＰＵ３０は変数ｋに“１”を代入し（Ｓ１３２）、１個目のキー管理テーブル９２１及び特徴管理テーブル９３１を複写してキー併合テーブル９２０及び特徴併合テーブル９３０を生成して（Ｓ１３３）、処理をＳ１３４へ移す。
ＣＰＵ３０は、変数ｋを“１”インクリメントして（Ｓ１３４）、後述するＳ１３８及びＳ１４１で変換前後のインデックスキーを対応付けるための対応テーブル９６を生成してＲＡＭ３２に一時的に記憶させる（Ｓ１３５）。次いでＣＰＵ３０は、ｋ個目のキー管理テーブル９２ｋにて、１件のキー管理レコードを適宜に選択し（Ｓ１３６）、選択したキー管理レコードに格納されている特徴量（以下、選択特徴量という）に一致する特徴量が、キー併合テーブル９２０に登録されているか否かを判定する（Ｓ１３７）。
選択特徴量に一致する特徴量がキー併合テーブル９２０に登録されている場合（Ｓ１３７でＹＥＳ）、ＣＰＵ３０は、Ｓ１３６で選択したキー管理レコードに格納されているインデックスキー（以下、選択インデックスキーという）を、選択特徴量に一致する特徴量に関連付けてキー併合テーブル９２０に登録されているインデックスキーに対応付けて（Ｓ１３８）、対応テーブル９６に登録し、処理をＳ１４２へ移す。このインデックスキーは、後述するＳ１４３にて選択インデックスキーを変換すべきインデックスキーであるため、以下、変換インデックスキーという。
選択特徴量に一致する特徴量がキー併合テーブル９２０に登録されていない場合（Ｓ１３７でＮＯ）、ＣＰＵ３０は、選択インデックスキーのハッシュ値に等しいハッシュ値を有し、しかも、キー併合テーブル９２０にて特徴量に関連付けられていない（即ち未使用の）インデックスキーを発行する（Ｓ１３９）。Ｓ１３９で発行されるインデックスキーとしては、キー併合テーブル９２０にて空きキー管理レコードに格納されているインデックスキーを優先的に用いることが望ましい。また、Ｓ１３９で発行したインデックスキーは、後述するＳ１４３にて選択インデックスキーを変換すべきインデックスキーであるため、以下、変換インデックスキーという。
Ｓ１３９の処理完了後、ＣＰＵ３０は、Ｓ１３９で発行した変換インデックスキーと選択特徴量とを関連付けて、キー併合テーブル９２０に登録し（Ｓ１４０）、選択インデックスキーとＳ１３９で発行した変換インデックスキーに対応付けて（Ｓ１４１）、対応テーブル９６に登録する。
Ｓ１３８又はＳ１４１の処理完了後、ＣＰＵ３０は、ｋ個目のキー管理テーブル９２ｋに設けられている全てのキー管理レコードがＳ１３６にて選択されたか否かを判定し（Ｓ１４２）、まだ選択されていないキー管理レコードが存在する場合は（Ｓ１４２でＮＯ）、処理をＳ１３６へ戻す。
ｋ個目のキー管理テーブル９２ｋに設けられている全てのキー管理レコードがＳ１３６にて選択された場合（Ｓ１４２でＹＥＳ）、ＣＰＵ３０は、ｋ個目の特徴管理テーブル９３ｋにて、各特徴管理レコードに格納されているインデックスキーを、対応テーブル９６を参照して、変換インデックスキーに変換する（Ｓ１４３）。この結果、ｋ個目の特徴管理テーブル９３ｋに登録されている各インデックスキーは、キー併合テーブル９２０に登録されているインデックスキーの何れかに一致する。
Ｓ１４３の処理完了後、ＣＰＵ３０は、ｋ個目の特徴管理テーブル９３ｋに設けられている全ての特徴管理レコードを、特徴併合テーブル９３０に挿入する（Ｓ１４４）。
次いでＣＰＵ３０は、変数ｋが個数Ｋ以上であるか否かを判定し（Ｓ１４５）、ｋ＜Ｋである場合は（Ｓ１４５でＮＯ）、処理をＳ１３４へ移す。
Ｓ１３４〜Ｓ１４５の処理を繰り返すことによって、ｋ個目のキー管理テーブル９２ｋ及び特徴管理テーブル９３ｋは、１個目〜ｋ−１個目のキー管理テーブル１〜９２ｋ−１及び特徴管理テーブル１〜９３ｋ−１がマージされているキー併合テーブル９２０及び特徴併合テーブル９３０にマージされる。
ｋ≧Ｋである場合（Ｓ１４５でＹＥＳ）、ＣＰＵ３０は、Ｋ個の各種管理テーブルをＨＤＤ３３から削除し（Ｓ１４６）、情報管理テーブル９４にて、１個目〜Ｎ個目のキー管理テーブル１〜９２Ｎ及び特徴管理テーブル１〜９３Ｎに関するテーブル情報を更新して（Ｓ１４７）、併合実行処理を終了する。
Ｓ１４７の処理で更新されたテーブル情報には、例えば１個目〜Ｋ個目の各種管理テーブルがキー併合テーブル９２０及び特徴併合テーブル９３０にまとめられていることを示す情報が含まれ、また、Ｋ＋１個目〜Ｎ個目の各種管理テーブルを、新たな１個目〜Ｎ−Ｋ個目の各種管理テーブルとする情報が含まれる。
以上のようにして生成されたキー併合テーブル９２０及び特徴併合テーブル９３０は、他の二次記憶装置にてアーカイブされ、ＨＤＤ３３からは削除されるが、図示は省略する。また、これらの各種併合テーブル９２０，９３０がＨＤＤ３３に残されて画像の検索の際に使用される構成でもよい。
また、各種併合テーブル９２０，９３０のアーカイブに伴い、図示はしないが、情報管理テーブル９４に登録されているテーブル情報、蓄積部９０に蓄積されている蓄積画像、及びＨＤＤ２３に記憶されている蓄積管理テーブル９１の登録内容が他の二次記憶装置にてアーカイブされ、元のデータは削除される。
併合実行処理におけるＣＰＵ３０は、画像登録手段の第１手段〜第６手段として機能し、このような併合実行処理を実行することによって、画像検索装置１に登録されている蓄積画像が効率よく管理される。
次に、画像検索装置１で画像を検索する手順を説明する。
図２０は、出力側端末機７で実行される画像表示処理（前半部分）及び蓄積ＤＢサーバ２で実行される蓄積画像送信処理夫々の手順を示すフローチャートであり、図２１は、出力側端末機７で実行される画像表示処理（後半部分）、検索実行サーバ５で実行される結果送信処理、及び蓄積ＤＢサーバ２で実行される類似画像送信処理夫々の手順を示すフローチャートである。
図２０に示すように、画像表示処理を実行する出力側端末機７のＣＰＵ７０は、表示部７３を制御して、検索作業者に画像を検索させるための画面を表示させて、画像検索装置１で画像を検索するための検索指示を受け付ける（Ｓ１５１）。検索作業者は、表示部７３を視認しながら操作部７４を操作して、検索指示を入力する。
検索指示を受け付けたＣＰＵ７０は、蓄積画像リストを要求するリスト要求を蓄積ＤＢサーバ２へ送信し（Ｓ１５２）、蓄積ＤＢサーバ２から蓄積画像リストを受信したか否かを判定して（Ｓ１５３）、まだ受信していない場合（Ｓ１５３でＮＯ）、Ｓ１５３の処理を繰り返し実行する。
蓄積画像送信処理を実行する蓄積ＤＢサーバ２のＣＰＵ２０は、出力側端末機７からリスト要求を受信したか否かを判定し（Ｓ１５４）、まだ受信していない場合（Ｓ１５４でＮＯ）、Ｓ１５４の処理を繰り返し実行する。
出力側端末機７からリスト要求を受信した場合（Ｓ１５４でＹＥＳ）、ＣＰＵ２０は、蓄積画像リストを生成して出力側端末機７へ送信し（Ｓ１５５）、処理をＳ１５４へ戻す。
ここで、蓄積画像リストは、蓄積管理テーブル９１を参照して生成され、例えば蓄積画像のファイル名と画像ＩＤとが関連付けられたリストである。なお、蓄積画像リストには画像ＩＤのみが含まれていてもよく、蓄積画像のファイル名の他に、作成年月日、サイズ等が含まれていてもよく、更に、蓄積画像のサムネイルが含まれていてもよい。
なお、画像の登録の際に、蓄積画像を作成した作者の名前、画像検索装置１に登録された登録年月日等の付属情報を蓄積管理テーブル９１に登録し、これらの付属情報を蓄積画像リストに含ませてもよい。
画像表示処理を実行する出力側端末機７のＣＰＵ７０は、蓄積ＤＢサーバ２から蓄積画像リストを受信した場合（Ｓ１５３でＹＥＳ）、受信した蓄積画像リストに基づき、検索作業者に指定画像及び付属情報を指定させるための蓄積画像リストを表示部７３に表示させる（Ｓ１５６）。なお、表示部７３に表示される蓄積画像リストの内容は、ファイル名、作成年月日、ユーザ名、登録年月日等の昇順／降順に並べ替え可能であるようにしてあることが望ましい。
検索作業者は、表示部７３を視認しながら操作部７４を操作して、蓄積部９０に蓄積されている蓄積画像の中から、１枚の蓄積画像を指定画像として指定する。また、検索作業者は、必要に応じて付属情報を指定するが、付属情報を指定しなくてもよい。更に、指定情報は、検索作業者が操作部７４から直接的に入力した付属情報を指定してもよく、指定画像の付属情報を指定してもよい。更にまた、複数個又は複数種類の付属情報を指定してもよく、複数指定する場合はＡＮＤ検索を行なうかＯＲ検索を行なうか等も指定する必要がある。
以下では、検索作業者が操作部７４から直接的に入力した１個のユーザ名を付属情報として指定した場合を例示する。
Ｓ１５６の処理完了後、ＣＰＵ７０は、指定画像及び付属情報が指定されたか否かを判定し（Ｓ１５７）、指定されていない場合（Ｓ１５７でＮＯ）、Ｓ１５７の処理を繰り返し実行する。
指定画像及び付属情報が指定された場合（Ｓ１５７でＹＥＳ）、ＣＰＵ７０は、図２１に示すように、指定された蓄積画像に関連付けられている画像ＩＤと指定された付属情報とを検索実行サーバ５へ送信する（Ｓ１５８）。
Ｓ１５８の処理完了後、ＣＰＵ７０は、検索実行サーバ５から検索結果情報を受信したか否かを判定して（Ｓ１５９）、まだ受信していない場合（Ｓ１５９でＮＯ）、Ｓ１５９の処理を繰り返し実行する。
結果送信処理を実行する検索実行サーバ５のＣＰＵ５０は、出力側端末機７から画像ＩＤ及び付属情報を受信したか否かを判定して（Ｓ１６０）、まだ受信していない場合（Ｓ１６０でＮＯ）、Ｓ１６０の処理を繰り返し実行する。
出力側端末機７から画像ＩＤ及び付属情報を受信した場合（Ｓ１６０でＹＥＳ）、ＣＰＵ５０は、受信した画像ＩＤ及び付属情報をＲＡＭ５２に一時的に記憶させてから、画像検索処理を行なうサブルーチン（図２２〜図２３参照）を呼び出し、実行する（Ｓ１６１）。
Ｓ１６１の処理完了後、ＣＰＵ２０は、Ｓ１６１で呼び出した画像検索処理によって得られた検索結果情報を出力側端末機７へ送信し（Ｓ１６２）、処理をＳ１６０へ戻す。
画像検索処理を実行することによって、指定画像の類似画像が存在することがわかった場合、検索結果情報には、投票数の多寡に関連付けて、類似画像の画像ＩＤが含まれている。一方、類似画像が存在しないことがわかった場合、検索結果情報には、類似画像の画像ＩＤは含まれていない。
画像表示処理を実行する出力側端末機７のＣＰＵ７０は、検索実行サーバ５から検索結果情報を受信した場合（Ｓ１５９でＹＥＳ）、ＣＰＵ７０は、受信した検索結果情報に類似画像の画像ＩＤが含まれている（即ち類似画像が存在する）か否かを判定する（Ｓ１６３）。
Ｓ１５９で受信した検索結果情報に類似画像の画像ＩＤが含まれていない場合（Ｓ１６３でＮＯ）、ＣＰＵ７０は、検索作業者が指定した指定画像に類似する類似画像が蓄積部９０には蓄積されていないという結果を示す画面を表示部７３に表示させ（Ｓ１６４）、画像表示処理を終了する。検索作業者は、Ｓ１６４の処理で表示部７３に表示された画面を視認して、検索作業を打ち切るか、又は他の蓄積画像を指定画像に指定するか等を判断し、他の蓄積画像を指定画像に指定する場合は、再び出力側端末機７に検索指示を入力する。
Ｓ１５９で受信した検索結果情報に類似画像の画像ＩＤが含まれている場合（Ｓ１６３でＹＥＳ）、類似画像である蓄積画像を取得すべく、ＣＰＵ７０は、検索結果情報に含まれている画像ＩＤを蓄積ＤＢサーバ２へ送信し（Ｓ１６５）、蓄積ＤＢサーバ２から蓄積画像を受信したか否かを判定して（Ｓ１６６）、まだ受信していない場合は（Ｓ１６６でＮＯ）、Ｓ１６６の処理を繰り返し実行する。
類似画像送信処理を実行する蓄積ＤＢサーバ２のＣＰＵ２０は、出力側端末機７から画像ＩＤを受信したか否かを判定して（Ｓ１６７）、まだ受信していない場合は（Ｓ１６７でＮＯ）、Ｓ１６７の処理を繰り返し実行する。
出力側端末機７から画像ＩＤを受信した場合（Ｓ１６７でＹＥＳ）、ＣＰＵ２０は、蓄積管理テーブル９１を参照して、Ｓ１６７で受信した画像ＩＤを有する蓄積画像を読み出し、出力側端末機７へ送信して（Ｓ１６８）、処理をＳ１６７へ戻す。
画像表示処理を実行する出力側端末機７のＣＰＵ７０は、蓄積ＤＢサーバ２から蓄積画像を受信（即ち取得）した場合（Ｓ１６６でＹＥＳ）、受信した蓄積画像を、指定画像の類似画像として、投票数が多い順に並べて表示部７３に表示させ（Ｓ１６９）、画像表示処理を終了する。検索作業者は、Ｓ１６９の処理で表示部７３に表示された指定画像を視認して、所望する画像が存在するか否か、存在しない場合は他の蓄積画像を指定画像に指定するか否か等を判断する。所望する画像が類似画像の中に存在する場合、検索作業者はこの類似画像を取得し、他の蓄積画像を指定画像に指定する場合は、再び出力側端末機７に検索指示を入力する。
なお、投票数が多い順に類似画像を並べるのみならず、類似度が少ない順、ファイル名、作成年月日、ユーザ名、登録年月日等の昇順／降順に並べ替え可能であるようにしてもよい。
図２２は、結果送信処理で呼び出される画像検索処理手順のサブルーチンの前半部分及び検索ＤＢサーバ３で実行されるＤＢ側送信処理の手順を示すフローチャートである。また、図２３は、画像検索処理手順のサブルーチンの後半部分を示すフローチャートである。
図２２に示すように、検索実行サーバ５のＣＰＵ５０は、各種管理テーブルを要求するテーブル要求を検索ＤＢサーバ３へ送信し（Ｓ１８１）、検索ＤＢサーバ３から各種管理テーブルを受信したか否かを判定して（Ｓ１８２）、まだ受信していない場合（Ｓ１８２でＮＯ）、Ｓ１８２の処理を繰り返し実行する。
ＤＢ側送信処理を実行する検索ＤＢサーバ３のＣＰＵ３０は、検索実行サーバ５からテーブル要求を受信したか否かを判定し（Ｓ１８３）、まだ受信していない場合（Ｓ１８３でＮＯ）、Ｓ１８３の処理を繰り返し実行する。
検索実行サーバ５からテーブル要求を受信した場合（Ｓ１８３でＹＥＳ）、ＣＰＵ３０は、１個目〜Ｎ個目のキー管理テーブル９２１〜９２Ｎ及び特徴管理テーブル９３１〜９３Ｎと情報管理テーブル９４とを読み出して検索実行サーバ５へ送信し（Ｓ１８４）、処理をＳ１８３へ戻す。
検索ＤＢサーバ３から各種管理テーブルを受信した場合（Ｓ１８２でＹＥＳ）、検索実行サーバ５のＣＰＵ５０は、受信した各種管理テーブルをＨＤＤ５３に記憶させる。
次いで、ＣＰＵ５０は、結果送信処理のＳ１６０で受信した付属情報に、先頭情報『０１』を付加する（Ｓ１８５）。Ｓ１８５で先頭情報『０１』を付加した付属情報とは、検索作業者が指定した付属情報に、先頭情報を付加したものである。以下では、この付属情報を指定付属情報という。
更にＣＰＵ５０は、Ｓ１８２で受信した１個目〜Ｎ個目のキー管理テーブル９２１〜９２Ｎの特徴量フィールドを検索して、指定付属情報に一致する付属情報が存在するか否かを判定する（Ｓ１８６）。
指定付属情報に一致する付属情報が存在しない場合（Ｓ１８６でＮＯ）、検索作業者が指定したユーザ名を有する作者が作成した画像は蓄積部９０には１枚も蓄積されていない。即ち、このような付属情報が付属する類似画像は、検索するまでもなく存在しないことがわかる。従って、ＣＰＵ５０は、類似画像が存在しないことを示す検索結果情報（即ち類似画像の画像ＩＤが含まれていない検索結果情報）を生成し（Ｓ１８７）、処理を結果送信処理のルーチンへ戻す。ここで生成された検索結果情報は、Ｓ１６２の処理で出力側端末機７へ送信される。
指定付属情報に一致する付属情報が存在する場合（Ｓ１８６でＹＥＳ）、Ｓ１８７の処理完了後、ＣＰＵ５０は、Ｓ１８２で受信した１個目〜Ｎ個目の特徴管理テーブル９３１〜９３ＮのＩＤフィールドを検索して、Ｓ１６０で受信した画像ＩＤ（以下、指定画像ＩＤという）に一致する画像ＩＤが登録されているＪ（Ｊは１≦Ｊ≦Ｎの自然数）個目の特徴管理テーブル９３Ｊを特定し（Ｓ１８８）、特定された特徴管理テーブル９３Ｊに登録されている指定画像ＩＤに関連付けられているインデックスキーを特定する（Ｓ１８９）。
次に、ＣＰＵ５０は、Ｓ１８８で特定された特徴管理テーブル９３Ｊに対応するＪ個目のキー管理テーブル９２Ｊを参照し、Ｓ１８９で特定されたインデックスキーの内、先頭情報が『００』であるインデックスキー、即ち特徴量のインデックスキー（以下、指定特徴キーという）を特定する（Ｓ１９０）。Ｓ１９０の処理を実行することによって、Ｓ１８９で特定されたインデックスキーの内、先頭情報が『０１』であるインデックスキー、即ち指定画像ＩＤを有する蓄積画像に付属する付属情報のインデックスキーが、誤って検索に用いられることが防止される。
更にＣＰＵ５０は、キー管理テーブル９２Ｊを参照して、指定特徴キーに関連付けられている特徴量を指定特徴量として区別しておく（Ｓ１９１）。指定特徴量は、後述するＳ２０１の処理で利用される。
Ｓ１９１の処理完了後、ＣＰＵ５０は、図２３に示すように、結果テーブル９５を生成する（Ｓ１９２）。ここで生成される結果テーブル９５には、指定画像ＩＤを除いて、特徴管理テーブル９３１〜９３Ｎに登録されている全ての画像ＩＤ夫々について、各画像ＩＤが格納されたＩＤフィールドと、投票数“０”が格納された投票数フィールドと、不一致情報が格納された一致／不一致フィールドとが関連付けられているレコードが設けられる。投票数フィールドに格納されている投票数は、後述するマッチング実行処理で増加する可能性があり（図２４参照）、一致／不一致フィールドに格納されている不一致情報は、後述する画像絞込処理で一致情報に変更される可能性がある（図２５参照）。
Ｓ１９２の処理完了後、ＣＰＵ５０は、キー管理テーブル９２Ｊの特徴量フィールドを検索して、指定付属情報に一致する付属情報が存在するか否かを判定し（Ｓ１９３）、存在しない場合は（Ｓ１９３でＮＯ）、処理を後述するＳ１９７へ移す。
指定付属情報に一致する付属情報がキー管理テーブル９２Ｊに登録されている場合（Ｓ１９３でＹＥＳ）、ＣＰＵ５０は、指定付属情報に一致する付属情報に関連付けられているインデックスキー（以下、指定付属キーという）を特定する（Ｓ１９４）。
次に、ＣＰＵ５０は、Ｓ１９０で特定した指定特徴キーとＪ個目の特徴管理テーブル９３Ｊとを処理対象にして、マッチング実行処理を行なうサブルーチン（図２４参照）を呼び出し、実行する（Ｓ１９５）。次いで、ＣＰＵ５０は、Ｓ１９４で特定した指定付属キーとＪ個目の特徴管理テーブル９３Ｊとを処理対象にして、画像絞込処理を行なうサブルーチン（図２５参照）を呼び出し、実行する（Ｓ１９６）。
Ｓ１９５及びＳ１９６の処理が実行されることによって、図１７に示すような結果テーブル９５が得られる。
Ｓ１９６の処理完了後、ＣＰＵ５０は、変数ｊに“１”を代入し（Ｓ１９７）、処理をＳ１９８へ移す。
ＣＰＵ５０は、変数ｊがＳ１８８で特定されたＪ個目の“Ｊ”に等しいか否かを判定し（Ｓ１９８）、ｊ＝Ｊである場合（Ｓ１９８でＹＥＳ）、Ｊ個目の特徴管理テーブル９３ＪについてはＳ１９５及びＳ１９６で処理が完了しているため、変数ｊを“１”インクリメントし（Ｓ１９９）、Ｓ１９９の処理完了後、又は変数ｊ≠Ｊである場合（Ｓ１９８でＮＯ）、変数ｊがＳ１８２で受信したＮ個目の“Ｎ”より大きいか否かを判定する（Ｓ２００）。
ｊ≦Ｎである場合（Ｓ２００でＮＯ）、ＣＰＵ５０は、ｊ個目のキー管理テーブル９２ｊを参照して、Ｓ１９１で区別しておいた指定特徴量に一致する特徴量に関連付けられているインデックスキー（以下、指定特徴キーという）と、指定付属情報に一致する付属情報に関連付けられているインデックスキー（以下、指定付属キーという）とを夫々を特定する（Ｓ２０１）。ただし、指定特徴量に一致する特徴量が１個も存在しないか、又は、指定付属情報に一致する付属情報が存在しない場合、指定特徴キー又は指定付属キーを特定することができないため（Ｓ２０２でＹＥＳ）、ＣＰＵ５０は、処理をＳ２０５へ移す。
指定特徴キー及び指定付属キー夫々を特定することができた場合（Ｓ２０２でＮＯ）、ＣＰＵ５０は、Ｓ２０１で特定した指定特徴キーとｊ個目の特徴管理テーブル９３ｊとを処理対象にして、マッチング実行処理を行なうサブルーチン（図２４参照）を呼び出し、実行する（Ｓ２０３）。次いで、ＣＰＵ５０は、Ｓ２０１で特定した指定付属キーとｊ個目の特徴管理テーブル９３ｊとを処理対象にして、画像絞込処理を行なうサブルーチン（図２５参照）を呼び出し、実行する（Ｓ２０４）。Ｓ２０３及びＳ２０４の処理が実行されることによって、結果テーブル９５の登録内容が変化する（又は変化せずに維持される）。
Ｓ２０４の処理完了後、ＣＰＵ５０は、変数ｊを“１”インクリメントし（Ｓ２０５）、処理をＳ１９８へ移す。
ｊ＞Ｎである場合（Ｓ２００でＹＥＳ）、１個目〜Ｎ個目の特徴管理テーブル９３１〜９３Ｎについてのマッチング実行処理及び画像絞込処理夫々が完了したため、ＣＰＵ５０は、結果テーブル９５の登録内容に基づいて検索結果情報を生成し（Ｓ２０６）、処理を結果送信処理のルーチンへ戻す。ここで生成された検索結果情報は、Ｓ１６２の処理で出力側端末機７へ送信される。
結果テーブル９５の登録内容に基づき、指定画像の類似画像が存在することがわかった場合、ＣＰＵ５０は、所定の最低投票数以上の投票数と一致情報とに関連付けられている画像ＩＤの中から、投票数が多い順に所定個以内の個数の画像ＩＤを選択し、選択した画像ＩＤが含まれている検索結果情報を生成する。この検索結果情報には、画像ＩＤに関連付けて、この画像ＩＤに対する投票数の多寡を示す情報が含まれている。
一方、類似画像が存在しないことがわかった（即ち、各画像ＩＤに関連付けられている投票数が、所定の最低投票数未満であるか、又は各画像ＩＤが不一致情報に関連付けられている）場合、ＣＰＵは、類似画像の画像ＩＤが含まれていない検索結果情報を生成する。
なお、本実施の形態では、検索ＤＢサーバ３が保管している各種管理テーブルを全て検索実行サーバ５にコピーするようにしてあるが、各種管理テーブルの当面必要な一部のみを検索実行サーバ５から適宜のタイミングで読み出す構成でもよい。
図２４及び図２５は、画像検索処理で呼び出されるマッチング実行処理手順及び画像絞込処理手順夫々のサブルーチンを示すフローチャートである。
まず、検索実行サーバ５で実行されるマッチング実行処理について説明する。（図２４）
ＣＰＵ５０は、処理対象である指定特徴キーの内、１個の指定特徴キーを適宜に選択し（Ｓ２１１）、選択した指定特徴キーのハッシュ値を算出し（Ｓ２１２）、Ｊ個目の特徴管理テーブル９３Ｊ（又はｊ個目の特徴管理テーブル９３ｊ）に関し、Ｓ２１２で算出したハッシュ値に等しいフィールド値が付与されているキーフィールドを特定する（Ｓ２１３）。
次いで、ＣＰＵ５０は、Ｓ２１３で特定したキーフィールドを検索して、Ｓ２１１で選択した指定特徴キーに一致するインデックスキーに関連付けられている画像ＩＤに投票する（Ｓ２１４）。即ち、ＣＰＵ５０は、指定特徴キーに一致するインデックスキーに関連付けられている画像ＩＤを特定し、結果テーブル９５にて、特定した画像ＩＤの投票数を“１”インクリメントする。一方、ＣＰＵ５０は、指定特徴キーに一致しないインデックスキーに関連付けられている画像ＩＤに係る投票数を変更しない。
Ｓ２１４の処理完了後、ＣＰＵ５０は、処理対象である指定特徴キーが全てＳ２１１で選択されたか否かを判定し（Ｓ２１５）、まだ選択されていない指定特徴キーが存在する場合は（Ｓ２１５でＮＯ）、処理をＳ２１１へ戻す。
指定特徴キーが全てＳ２１１で選択された場合（Ｓ２１５でＹＥＳ）、ＣＰＵ５０は、処理を画像検索処理のルーチンへ戻す。
次に、検索実行サーバ５で実行される画像絞込処理について説明する（図２５）。
ＣＰＵ５０は、処理対象である指定付属キーのハッシュ値を算出し（Ｓ２２１）、Ｊ個目の特徴管理テーブル９３Ｊ（又はｊ個目の特徴管理テーブル９３ｊ）に関し、Ｓ２２１で算出したハッシュ値に等しいフィールド値が付与されているキーフィールドを特定する（Ｓ２２２）。
次いで、ＣＰＵ５０は、Ｓ２２２で特定したキーフィールドを検索して、処理対象である指定付属キーに一致するインデックスキーに関連付けられている一致情報を付与することによって、付属情報の一致／不一致を判別する（Ｓ２２３）。即ち、ＣＰＵ５０は、指定付属キーに一致するインデックスキーに関連付けられている画像ＩＤを特定し、結果テーブル９５にて、特定した画像ＩＤに係る不一致情報を一致情報に変更する。一方、ＣＰＵ５０は、指定付属キーに一致しないインデックスキーに関連付けられている画像ＩＤに係る不一致情報は一致情報に変更しない。
Ｓ２２３の処理完了後、ＣＰＵ５０は、処理を画像検索処理のルーチンへ戻す。
このような画像検索処理におけるＣＰＵ５０は、特徴キー探索手段、画像選択手段、及び情報キー探索手段として機能する。また、マッチング実行処理におけるＣＰＵ５０は、類似度算出手段として機能し、画像絞込処理におけるＣＰＵ５０は、情報付与手段として機能する。
以上のような各処理を実行することによって、画像検索装置１で画像が検索される。つまり、蓄積画像送信処理及び類似画像送信処理を実行するＣＰＵ２０、結果送信処理を実行するＣＰＵ５０、画像表示処理を実行するＣＰＵ７０は、検索手段（特に結果出力手段）として機能し、Ｓ１６４又はＳ１６９の処理の結果として、表示部７３は検索手段による検索結果を表示する表示部として機能する。
以上のような画像検索装置１は、主として登録の際に使用される計算機と、主として検索の際に使用される計算機とを個別に備えており、特に演算負荷が大きい特徴量の抽出処理とインデックスキーを介した特徴量のマッチング処理とを特徴抽出サーバ４と検索実行サーバ５とに分けてある。このため、１個の演算部に演算負荷が集中することを防止することができる。また、例えば登録作業者による入力側端末機６を用いた画像の登録に併行して、検索作業者による出力側端末機７を用いた画像の検索を実行することができる。
なお、例えば画像検索装置１が蓄積ＤＢサーバ２を備えず、外部の蓄積ＤＢサーバに蓄積されている蓄積画像の中から類似画像を検索する構成にしてもよい。又は、画像検索装置１がリレーショナル・データベースを備えず、外部のリレーショナル・データベースを参照して類似画像を検索する構成にしてもよい。あるいは、出力側端末機７を備えず、検索実行サーバ５から外部の出力側端末機へ検索結果情報を出力する構成にしてもよい。
実施の形態 ２．
図２６は、本発明の実施の形態２に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。
本実施の形態の登録実行処理は、実施の形態１と同様に、検索ＤＢサーバ３で実行されるテーブル管理処理（図８参照）で呼び出される。図２６に示す登録実行処理のＳ２３１〜Ｓ２３４の処理、Ｓ２３６〜Ｓ２３９の処理、並びにＳ２４１及びＳ２４２の処理は、図９に示す実施の形態１の登録実行処理のＳ６１〜Ｓ６４の処理、Ｓ６５〜Ｓ６８の処理、並びにＳ８１及びＳ８２の処理と同様であるため、説明を省略する。また、Ｓ２４１及びＳ２４２よりも後の処理は、図１０〜図１１に示す実施の形態１の登録実行処理の各処理と同様であるため、図示及び説明を省略する。
また、図２７は、登録実行処理で呼び出されるキー管理格納処理手順のサブルーチンを示すフローチャートである。本実施の形態のキー管理格納処理の各処理は、図１３に示す実施の形態１のキー管理格納処理の各処理と略同様であるが、本実施の形態のＳ２５６〜Ｓ２５８の処理は、実施の形態１のＳ９６〜Ｓ９８の処理と少し異なる。
図２８は、本発明の実施の形態２に係る画像検索装置のキー管理テーブルを説明する模式図である。
図１６に示すように、実施の形態１のキー管理テーブル９２１〜９２Ｎ夫々には、各レコードにつき、各１個のキーフィールドと特徴量フィールドとが関連付けて設けられている。
一方、図２８に示すように、本実施の形態のキー管理テーブル９２１〜９２Ｎ夫々には、各レコードにつき、各１個のキーフィールドと特徴量フィールドと枚数フィールドとが関連付けて設けられている。この枚数フィールドには、特徴量フィールドに格納されている特徴量（又は付属情報）を有する蓄積画像の枚数を示す１個の枚数情報が格納される。
図２７に示すように、キー管理格納処理を実行する検索ＤＢサーバ３のＣＰＵ３０は、Ｓ２５５の処理完了後、Ｓ２５５で発行したインデックスキーと特徴未格納情報と“０”を示す枚数情報とが格納されている空きキー管理レコードを現行のキー管理テーブル９２３に挿入する（Ｓ２５６）。
Ｓ２５６の処理完了後、又は、現行のキー管理テーブル９２３で既に使用されているインデックスキーの最大値とＳ２５３で発行したインデックスキーとが連番である場合（Ｓ２５４でＹＥＳ）、ＣＰＵ３０は、Ｓ２５３で発行したインデックスキーとＳ２５１で選択された特徴量（又は付属情報）と“１”を示す枚数情報とが格納されているキー管理レコードを現行のキー管理テーブル９２３に挿入して（Ｓ２５７）、処理をＳ２５９へ移す。
Ｓ２５１で選択した特徴量（又は付属情報）に対応付けられているハッシュ値に等しいインデックスキーが格納されている空きキー管理レコードが存在する場合（Ｓ２５２でＹＥＳ）、ＣＰＵ３０は、Ｓ２５２で存在すると判定された空きキー管理レコードの内、最も小さいインデックスキーが格納されている空きキー管理レコードを、このインデックスキーとＳ２５１で選択された特徴量（又は付属情報）とが格納されているキー管理レコードに更新し、更に、枚数情報“０”を枚数情報“１”に更新して（Ｓ２５８）、処理をＳ２５９へ移す。
Ｓ２５７及びＳ２５８の処理は、新たな特徴量（又は付属情報）を現行のキー管理テーブル９２３に登録する処理であり、この新たな特徴量（又は付属情報）を有する蓄積画像は１枚である。従って、インデックスキー及び特徴量（又は付属情報）を関連付けて現行のキー管理テーブル９２３に登録する際に、枚数情報“１”が登録される。
図２６に示すように、登録実行処理を実行する検索ＤＢサーバ３のＣＰＵ３０は、Ｓ２３２で選択した特徴量（又は付属情報）が現行のキー管理テーブル９２３に既に登録されている場合（Ｓ２３３でＹＥＳ）、Ｓ２３２で選択した特徴量（又は付属情報）を、既登録の特徴量（又は付属情報）として記憶し（Ｓ２３４）、更に、この特徴量に関連付けてキー管理テーブル９２３に登録されている枚数情報を“１”インクリメントする（Ｓ２３５）。Ｓ２３５におけるＣＰＵ３０は、枚数計数手段として機能する。
以上の結果、図２８に示すように、キー管理テーブル９２１〜９２Ｎ夫々に、インデックスキーと特徴量（又は付属情報）と、この特徴量（又は付属情報）を有する蓄積画像の枚数を示す枚数情報とが登録される。例えば、第１のインデックスキーと第１の特徴量と及び枚数情報“５００”とが登録され、第２又は第３のインデックスキーと第２又は第３の特徴量と枚数情報“２００”又は“１”とが登録され、第４のインデックスキーと特徴未格納情報と枚数情報“０”とが登録される。
このようなキー管理テーブル９２１〜９２Ｎをマージする場合、重複する特徴量（又は付属情報）に関連付けられている枚数情報は、単純に加算される。
枚数情報が示す蓄積画像の枚数が１枚である第３の特徴量は、１枚の蓄積画像のみが有する特徴量である。このため、蓄積画像の内の１枚を指定画像として用いる本実施の形態においては、第３のインデックスキーを用いてマッチングを行なっても無駄である。従って、枚数情報“１”に関連付けられているインデックスキーを省いてマッチングを行なうことにより、検索時間が短縮される。なお、蓄積画像以外の指定画像を用いる場合は、枚数情報“１”に関連付けられているインデックスキーも用いてマッチングを行なう必要がある。
枚数情報が示す蓄積画像の枚数が多い第１の特徴量は、多数枚（具体的には５千枚）の蓄積画像が共有する特徴量である。つまり、第１のインデックスキーを用いてマッチングを行なった場合に、５千個の画像ＩＤに関連付けられている投票数がインクリメントされる。一方、枚数情報が示す蓄積画像の枚数が少ない第２の特徴量は、少数枚（具体的には２百枚）の蓄積画像が共有する特徴量である。つまり、第２のインデックスキーを用いてマッチングを行なった場合に、２百個の画像ＩＤに関連付けられている投票数がインクリメントされる。
即ち、多くの枚数を示す枚数情報に関連付けられているインデックスキーは、少ない枚数を示す枚数情報に関連付けられているインデックスキーよりも、蓄積画像を識別する能力が低い。
ところで、実施の形態１では、出力側端末機７を用いて検索作業者が指定画像を指定してから、表示部７３に検索結果が表示されるまで、検索作業者が長時間待たされることがある。
一方、本実施の形態では、検索作業者が指定画像を指定してから、表示部７３に最終的な検索結果が表示されるまでの間に、暫定的な検索結果（以下、暫定検索結果という）が表示部７３に表示される。この場合、検索作業者を長時間待たせ続けることがなくなり、暫定検索結果として表示された蓄積画像の中に検索作業者が所望する画像が存在した場合には、検索作業者が手動で検索を中断することも可能になる。
本実施の形態の図示しない画像検索処理は、実施の形態１と同様に、検索実行サーバ５で実行される（図２２〜図２３参照）。検索実行サーバ５のＣＰＵ５０は、図２３に示す画像検索処理のＳ２０６の処理を実行することによって、結果テーブル９５の登録内容に基づいて、最終的な検索結果を示す検索結果情報を生成する。ＣＰＵ５０は、実施の形態１と同様に、所定の最低投票数以上の投票数と一致情報とに関連付けられている画像ＩＤの中から、投票数が多い順に所定個以内の個数の画像ＩＤを選択する。
このため、１個目〜Ｎ個目の特徴管理テーブル９３１〜９３Ｎについてのマッチング実行処理及び画像絞込処理夫々が完了する前（即ち図２３に示す画像検索処理のＳ２００の処理で、ＣＰＵ５０がＹＥＳと判定する前）であっても、画像ＩＤに対して最低投票数以上の投票数が関連付けられているならば、この画像ＩＤは類似画像の画像ＩＤとして選択される可能性があることがわかる。
つまり、最低投票数以上の投票数が関連付けられている画像ＩＤを有する蓄積画像は類似画像の候補であり、検索作業者が所望する画像である可能性が少なからずある。従って、最低投票数以上の投票数が関連付けられている画像ＩＤを有する蓄積画像を、暫定的な検出結果として表示部７３に表示させることによって、検索作業者の利便性が向上される。
このとき、枚数情報が示す枚数が所定枚数（本実施の形態では２枚）以上であり、且つ、枚数が少ない順にインデックスキーを選択してマッチング処理を行なえば、最終的な投票数が多くなる可能性が高い画像ＩＤに対して、短時間で、最低投票数以上の投票が行なわれる。この結果、早くから最低投票数以上の投票数が関連付けられている画像ＩＤを有する蓄積画像は、マッチング実行処理の完了を待たずとも、他の蓄積画像に比べて指定画像に類似している可能性が高い。
図２９は、検索実行サーバ５で実行されるマッチング実行処理手順のサブルーチン、及び実施の形態１と同様に出力側端末機７で実行される画像表示処理（一部分）の手順を示すフローチャートであり、図３０は、画像表示処理（他の一部分）、及び実施の形態１と同様に蓄積ＤＢサーバ２で実行される類似画像送信処理夫々の手順を示すフローチャートである。
図３１は、結果テーブル９５を説明する模式図である。
本実施の形態のマッチング実行処理は、図２４に示す実施の形態１のマッチング実行処理に相当し、実施の形態１と同様に画像検索処理（図２２〜図２３参照）で呼び出される。マッチング実行処理のＳ２７３〜Ｓ２７５の処理は、図２４に示すＳ２１２〜Ｓ２１４の処理と同様である。
また、本実施の形態の画像表示処理は、実施の形態１の画像表示処理（図２０〜図２１参照）に相当する。ただし、Ｓ２９１の処理より前の処理は、図２０に示す各処理と同様であるため、図示及び説明を省略する。また、Ｓ２９１及びＳ２９３の処理は図２１に示すＳ１５８及びＳ１５９の処理と同様であるため、説明を省略する。
更に、本実施の形態の画像表示処理及び類似画像送信処理のＳ２９４〜Ｓ３００の処理は、図２１に示すＳ１６３〜Ｓ１６９の処理と同様であるため、説明を省略する。
検索実行サーバ５のＣＰＵ５０は、図示はしないが、図２３に示すＳ１９２の処理を実行することによって、結果テーブル９５を生成する。ただし、ここで生成される結果テーブル９５には、実施の形態１の結果テーブル９５とは異なり、指定画像ＩＤを除いて、特徴管理テーブル９３１〜９３Ｎに登録されている全ての画像ＩＤ夫々について、各画像ＩＤが格納されたＩＤフィールドと、投票数“０”が格納された投票数フィールドと、不一致情報が格納された一致／不一致フィールドと、暫定検索結果をまだ送信していないことを示す未送信情報が格納された暫定結果フィールドとが関連付けられているレコードが設けられる（図３１参照）。
投票数フィールドに格納されている投票数は、実施の形態１と同様にマッチング実行処理で増加する可能性があり、暫定結果フィールドに格納されている未送信情報は、後述するマッチング実行処理で、暫定検索結果が送信済みであることを示す送信済情報に変更される可能性がある。また、一致／不一致フィールドに格納されている不一致情報は、実施の形態１と同様に、図示しない画像絞込処理で一致情報に変更される可能性がある。
図２９に示すように、マッチング実行処理を実行する検索実行サーバ５のＣＰＵ５０は、Ｓ１９０又は又はＳ２０１の処理で特定した処理対象である指定特徴キーの内、Ｓ２７２以降の処理で使用しない指定特徴キーを排除する（Ｓ２７１）。このためにＣＰＵ５０は、Ｊ個目のキー管理テーブル９２Ｊ又はｊ個目のキー管理テーブル９２ｊを参照して、“１”を示す枚数情報に関連付けられているインデックスキーに一致する指定特徴キーをＲＡＭ５２から削除するか、又はこの指定特徴キーに対して適宜のフラグをセットして、後述するＳ２７２の処理で選択されないようにする。
Ｓ２７１の処理完了後、ＣＰＵ５０は、Ｊ個目のキー管理テーブル９２Ｊ又はｊ個目のキー管理テーブル９２ｊを参照して、“２”以上の枚数情報に関連付けられているインデックスキーの内、枚数情報が示す枚数が最も少ないインデックスキーに一致する指定特徴キーを選択し（Ｓ２７２）、選択した指定特徴キーに対して、Ｓ２７３〜Ｓ２７５の処理を実行する。
Ｓ２７５の処理完了後、ＣＰＵ５０は結果テーブル９５を参照し、投票数が最低投票数以上である画像ＩＤが存在するか否かを判定し（Ｓ２７６）、この画像ＩＤが存在する場合は（Ｓ２７６でＹＥＳ）、この画像ＩＤに関連付けて一致情報が登録されているか否かを判定し（Ｓ２７７）、一致情報が登録されている場合は（Ｓ２７７でＹＥＳ）、この画像ＩＤに関連付けて未送信情報が登録されているか否かを判定する（Ｓ２７８）。
未送信情報が関連付けられている場合（Ｓ２７８でＹＥＳ）、ＣＰＵ５０は、この画像ＩＤを含む暫定検索結果を出力側端末機７へ送信し（Ｓ２７９）、結果テーブル９５にて、この画像ＩＤに関連付けられている未送信情報を送信済情報に更新する（Ｓ２８０）。
Ｓ２８０の処理完了後、ＣＰＵ５０は、Ｓ２７１の処理で排除されなかった指定特徴キーが全てＳ２７２で選択されたか否かを判定し（Ｓ２８１）、まだ選択されていない指定特徴キーが存在する場合は（Ｓ２８１でＮＯ）、処理をＳ２７２へ戻す。この場合、ＣＰＵ５０は、“２”以上の枚数情報に関連付けられており、且つ、まだ選択されていないインデックスキーの内、枚数情報が示す枚数が最も少ないインデックスキーに一致する指定特徴キーを選択する。
指定特徴キーが全てＳ２７２で選択された場合（Ｓ２８１でＹＥＳ）、ＣＰＵ５０は、処理を画像検索処理のルーチンへ戻す。
投票数が最低投票数未満である画像ＩＤしか存在しない場合（Ｓ２７６でＮＯ）、又は、投票数が最低投票数以上である画像ＩＤに関連付けて不一致情報が登録されている場合（Ｓ２７７でＮＯ）、あるいは、投票数が最低投票数以上であり、且つ、一致情報に関連付けられている画像ＩＤに関連付けて送信済情報が登録されている場合（Ｓ２７８でＮＯ）、ＣＰＵ５０はＳ２７９及びＳ２８０の処理を実行せずにＳ２８１の処理を実行する。
最低投票数が“１０００”である場合、図３１に示す結果テーブル９５においては、投票数が“１０００”であり、一致情報及び未送信情報に関連付けられている第２の画像ＩＤが暫定検索結果に含まれる。一方、投票数が“９９９”である第１の画像ＩＤ、不一致情報に関連付けられている第３の画像ＩＤ、及び送信済情報に関連付けられている第４の画像ＩＤは、暫定検索結果には含まれない。
暫定検索結果の送信後、第２の画像ＩＤには送信済情報が関連付けられるため、今後、第２の画像ＩＤが暫定検索結果に含まれることはないが、第１の画像ＩＤは投票数が増加することによって、また、第３の画像ＩＤは不一致情報が一致情報に更新されることによって、暫定検索結果に含まれることになる。
画像表示処理を実行する出力側端末機７のＣＰＵ７０は、Ｓ２９１の処理の完了後、検索実行サーバ５から暫定検索結果を受信したか否かを判定して（Ｓ２９２）、まだ受信していない場合（Ｓ２９２でＮＯ）、検索実行サーバ５から検索結果情報を受信したか否かを判定して（Ｓ２９３）、まだ受信していない場合（Ｓ２９３でＮＯ）、処理をＳ２９２へ戻す。
検索実行サーバ５から暫定検索結果を受信した場合（Ｓ２９２でＹＥＳ）、ＣＰＵ５０は、図３０に示すように、受信した暫定検索結果に含まれている画像ＩＤを蓄積ＤＢサーバ２へ送信し（Ｓ３１１）、蓄積ＤＢサーバ２から蓄積画像を受信したか否かを判定して（Ｓ３１２）、まだ受信していない場合は（Ｓ３１２でＮＯ）、Ｓ３１２の処理を繰り返し実行する。
蓄積ＤＢサーバ２から蓄積画像を受信した場合（Ｓ３１２でＹＥＳ）、ＣＰＵ７０は、受信した蓄積画像を、指定画像の暫定的な類似画像として、表示部７３に表示させ（Ｓ３１３）、処理を図２９に示すＳ２９２へ戻す。
最低投票数が“１０００”である場合、図３１に示す結果テーブル９５においては、第２の画像ＩＤを有する蓄積画像が、指定画像の暫定的な類似画像として表示部７３に表示される。
その他、実施の形態１に対応する部分には同一符号を付してそれらの説明を省略する。
実施の形態 ３．
図３２は、本発明の実施の形態３に係る画像検索装置で実行される登録抹消処理（前半部分）及び蓄積画像送信処理夫々の手順を示すフローチャートである。登録抹消処理は入力側端末機６で実行され、本実施の形態の蓄積画像送信処理は、実施の形態１，２と同様に蓄積ＤＢサーバ２で実行される。図３２に示すＳ３２４及びＳ３２５の処理は、図２０に示すＳ１５４及びＳ１５５の処理と同様であるため、説明を省略する。
図３３は、入力側端末機６で実行される登録抹消処理（後半部分）、蓄積ＤＢサーバ２で実行される画像削除処理、及び実施の形態２と同様に検索ＤＢサーバ３で実行される登録無効化処理夫々の手順を示すフローチャートである。
画像検索装置１において、画像の登録を抹消する場合、蓄積部９０に蓄積されている蓄積画像を削除し、また、この蓄積画像の画像ＩＤに関連している各種のデータを各種管理テーブルから削除する必要がある。
しかしながら、登録されているデータの整合性を各種管理テーブル間で保ちつつ各種管理テーブルからデータを削除する処理は煩雑であり、長時間を要するという問題がある。また、画像の登録と画像の登録抹消とが同時的に発生すると、各種ＤＢサーバ２，３のＣＰＵ２０，３０に演算負荷が集中し、しかも、各種管理テーブルを更新するために各種管理テーブルを互いに長時間ロックし合うという問題がある。
これらの問題を解決するためには、例えば登録を抹消すべき蓄積画像を予め指定しておき、画像の登録又は検索が実行されない夜間、休日等に登録の抹消を実行することが考えられる。ただし、登録を抹消すべき蓄積画像が指定されてから登録が抹消されるまでの間に、この蓄積画像が誤って類似画像として選択される不都合を防止する必要がある。
図３４は、本発明の実施の形態３に係る画像検索装置の特徴管理テーブルを説明する模式図である。
図１４に示す実施の形態１の特徴管理テーブル９３とは異なり、本実施の形態における特徴管理テーブル９３１〜９３Ｎ夫々の各レコードには、各１個のＩＤフィールド、及び有効／無効フィールドと、Ｍ個のキーフィールドとが関連付けて設けられている。図中のインデックスキーは下４桁が記載されており、キー未格納情報として「未」が記載されている。
有効／無効フィールドには、ＩＤフィールドに格納されている画像ＩＤが有効であることを示す有効情報（図中「○」）又は無効であることを示す無効情報（図中「×」）が格納される。
本実施の形態の図示しない登録側受信処理、登録実行処理及び特徴管理格納処理は、実施の形態１の図７に示す登録側受信処理、図９〜図１１に示す登録実行処理及び図１２に示す特徴管理格納処理と略同様であるが、図９に示すＳ６７の処理及び図１２に示すＳ７５の処理に夫々相当する処理が異なる。これらの処理において、検索ＤＢサーバ３のＣＰＵ３０は、図７に示す登録側受信処理のＳ４４の処理で受信した画像ＩＤを格納した１個のＩＤフィールドと、有効情報を格納した有効／無効フィールドと、キー未格納情報を夫々格納したＭ個（本実施の形態では１６個）のキーフィールドとが関連付けられている１件の特徴管理レコードを生成する。この結果、画像を登録する際には、画像ＩＤに関連付けて有効情報が特徴管理テーブル９３１〜９３Ｎに登録される。
図３２に示すように、登録抹消処理を実行する入力側端末機６のＣＰＵ６０は、表示部６３を制御して、登録作業者に画像を検索させるための画面を表示させて、画像検索装置１に登録されている画像を抹消するための登録抹消指示を受け付ける（Ｓ３２１）。登録作業者は、表示部６３を視認しながら操作部６４を操作して、登録抹消指示を入力する。
登録抹消指示を受け付けたＣＰＵ６０は、蓄積画像リストを要求するリスト要求を蓄積ＤＢサーバ２へ送信し（Ｓ３２２）、蓄積ＤＢサーバ２から蓄積画像リストを受信したか否かを判定して（Ｓ３２３）、まだ受信していない場合（Ｓ３２３でＮＯ）、Ｓ３２３の処理を繰り返し実行する。
蓄積ＤＢサーバ２から蓄積画像リストを受信した場合（Ｓ３２３でＹＥＳ）、ＣＰＵ６０は、受信した蓄積画像リストに基づき、登録作業者に登録を抹消すべき蓄積画像（以下、抹消画像という）を指定させるための蓄積画像リストを表示部６３に表示させる（Ｓ３２６）。
登録作業者は、表示部６３を視認しながら操作部６４を操作して、蓄積部９０に蓄積されている蓄積画像の中から、１枚又は複数枚の蓄積画像を抹消画像として指定する。
Ｓ３２６の処理完了後、ＣＰＵ６０は、抹消画像が指定されたか否かを判定し（Ｓ３２７）、指定されていない場合（Ｓ３２７でＮＯ）、Ｓ３２７の処理を繰り返し実行する。
抹消画像が指定された場合（Ｓ３２７でＹＥＳ）、ＣＰＵ６０は、図３３に示すように、指定された抹消画像に関連付けられている画像ＩＤと登録の抹消を指示する抹消指示とを、蓄積ＤＢサーバ３及び検索ＤＢサーバ３夫々へ送信し（Ｓ３２８）、登録抹消処理を終了する。
画像削除処理を実行する蓄積ＤＢサーバ２のＣＰＵ２０は、入力側端末機６から画像ＩＤ及び抹消指示を受信したか否かを判定して（Ｓ３２９）、まだ受信していない場合は（Ｓ３２９でＮＯ）、Ｓ３２９の処理を繰り返し実行する。
入力側端末機６から画像ＩＤ及び抹消指示を受信した場合（Ｓ３２９でＹＥＳ）、ＣＰＵ２０は、蓄積管理テーブル９１を参照して、Ｓ３２９で受信した画像ＩＤを有する蓄積画像を削除し（Ｓ３３０）、Ｓ３２９で受信した画像ＩＤに関連付けて蓄積管理テーブル９１に登録されている蓄積画像のアドレス及びファイル名を、無効な値（例えば“０”）に更新して（Ｓ３３１）、処理をＳ３２９へ戻す。
Ｓ３３０及びＳ３３１の処理は短時間で容易に実行可能であり、ＣＰＵ２０に掛かる負荷は軽い。なお、Ｓ３３０及びＳ３３１の処理の代わりに、Ｓ３２９で受信した画像ＩＤに関連付けて無効情報を登録し、Ｓ３３０及びＳ３３１の処理は夜間、休日等に実行する構成でもよい。
蓄積管理テーブル９１において無効な値に関連付けられている画像ＩＤは、欠番にしてもよく、後に再利用してもよいが、再利用する場合は、蓄積ＤＢサーバ２と特徴抽出サーバ４とで夫々発行される画像ＩＤに齟齬が生じないようにする必要がある（例えば蓄積ＤＢサーバ２と特徴抽出サーバ４とで夫々画像ＩＤを発行する代わりに、画像ＩＤ発行用のサーバを別途設けて、ここで画像ＩＤを管理する）。
図３３に示す登録無効化処理を実行する検索ＤＢサーバ３のＣＰＵ３０は、入力側端末機６から画像ＩＤ及び抹消指示を受信したか否かを判定して（Ｓ３３２）、まだ受信していない場合は（Ｓ３３２でＮＯ）、Ｓ３３２の処理を繰り返し実行する。
入力側端末機６から画像ＩＤ及び抹消指示を受信した場合（Ｓ３３２でＹＥＳ）、ＣＰＵ２０は、特徴管理テーブル９３１〜９３Ｎを夫々参照して、Ｓ３３２で受信した画像ＩＤに無効情報を付与して（Ｓ３３３）、処理をＳ３２９へ戻す。Ｓ３３１におけるＣＰＵ２０は無効付与手段として機能し、Ｓ３３２で受信した画像ＩＤに関連付けて特徴管理テーブル９３１〜９３Ｎの何れかに登録されている有効情報を無効情報に更新する。
Ｓ３３３の処理は短時間で容易に実行可能であり、しかも、キー管理テーブル９２１〜９２Ｎを更新する必要はないため、ＣＰＵ３０に掛かる負荷は軽く、各種管理テーブルがロックされる時間は短いか、そもそもロックされない。
次に、画像の検索時の手順について説明する。
図３５は、検索ＤＢサーバ３で実行されるＤＢ側送信処理の手順を示すフローチャートである。
本実施の形態のＤＢ側送信処理は、図２２に示す実施の形態１のＤＢ側送信処理に相当し、Ｓ３４１及びＳ３４３の処理は、図２２に示すＳ１８３及びＳ１８４の処理と略同様である。
検索実行サーバ５からテーブル要求を受信した場合（Ｓ３４１でＹＥＳ）、検索ＤＢサーバ３のＣＰＵ３０は、１個目〜Ｎ個目の特徴管理テーブル９３１〜９３Ｎから無効情報が格納されているレコードを一時的に排除してなる特徴管理テーブル９３１〜９３Ｎを生成し（Ｓ３４２）、生成した特徴管理テーブル９３１〜９３Ｎと、１個目〜Ｎ個目のキー管理テーブル９２１〜９２Ｎと情報管理テーブル９４とを読み出して検索実行サーバ５へ送信し（Ｓ３４３）、処理をＳ３４１へ戻す。
この結果、検索実行サーバ５では、無効情報に関連付けられている画像ＩＤが投票の対象になることはない。なお、無効情報が格納されているレコードを検索実行サーバ５のＣＰＵ５０が排除する構成でもよい。
最後に、特徴管理テーブル９３１〜９３Ｎにおいて無効情報が格納されているレコードの処分について説明する（不図示）。
まず、特徴管理テーブル９３１〜９３Ｎにおいて無効情報に関連付けられているインデックスキーに一致するインデックスキーをキー管理テーブル９２１〜９２Ｎにて特定し、特定されたインデックスキーに関連付けられている枚数情報を“１”デクリメントする。この結果として枚数情報が“０”に達したインデックスキーに関連付けられている特徴量は、既に削除された蓄積画像のみが有していた特徴量であるため、この特徴量を特徴未格納情報に変更する。
このようにして特徴未格納情報に関連付けられたインデックスキーは、例えば図１３に示すキー管理格納処理のＳ９８の処理で再利用される。また、画像の登録を抹消することによって生じた未使用のインデックスキーを、キー管理テーブル９２１〜９２Ｎ以外のテーブルで管理する必要がないため、各種管理テーブル間に矛盾が生じ難い。
なお、特徴管理テーブル９３１〜９３Ｎに枚数情報が登録されていない場合（例えば実施の形態１の場合）であっても、無効情報に関連付けられているインデックスキーに一致するインデックスキーが、有効情報が格納されているレコードに格納されているか否かを判定し、格納されていないときに、キー管理テーブル９２１〜９２Ｎを更新してこのインデックスキーを再利用可能にすればよい。
キー管理テーブル９２１〜９２Ｎの更新完了後、特徴管理テーブル９３１〜９３Ｎにおいて無効情報が格納されているレコードを完全に削除する。
その他、実施の形態１，２に対応する部分には同一符号を付してそれらの説明を省略する。
本発明の実施の形態１に係る画像検索装置の全体的な構成を示す模式図である。 本発明の実施の形態１に係る画像検索装置が備える蓄積ＤＢサーバ及び検索ＤＢサーバ夫々の構成を示すブロック図である。 本発明の実施の形態１に係る画像検索装置が備える特徴抽出サーバ及び入力側端末機夫々の構成を示すブロック図である。 本発明の実施の形態１に係る画像検索装置が備える検索実行サーバ及び出力側端末機夫々の構成を示すブロック図である。 本発明の実施の形態１に係る画像検索装置で実行される画像読込処理、蓄積側受信処理及び抽出側受信処理夫々の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される蓄積実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される特徴抽出処理手順のサブルーチン及び登録側受信処理の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行されるテーブル管理処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される特徴管理格納処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行されるキー管理格納処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置の特徴管理テーブルを説明する模式図である。 本発明の実施の形態１に係る画像検索装置で実行されるマッチングを説明する模式図である。 本発明の実施の形態１に係る画像検索装置のキー管理テーブルを説明する模式図である。 本発明の実施の形態１に係る画像検索装置の結果テーブルを説明する模式図である。 本発明の実施の形態１に係る画像検索装置で実行される併合実行処理の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される併合実行処理の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される画像表示処理及び蓄積画像送信処理夫々の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される画像表示処理、結果送信処理及び類似画像送信処理夫々の手順を示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される画像検索処理手順のサブルーチン及びＤＢ側送信処理の手順を示すフローチャートである 本発明の実施の形態１に係る画像検索装置で実行される画像検索処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行されるマッチング実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態１に係る画像検索装置で実行される画像絞込処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態２に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態２に係る画像検索装置で実行される登録実行処理手順のサブルーチンを示すフローチャートである。 本発明の実施の形態２に係る画像検索装置のキー管理テーブルを説明する模式図である。 本発明の実施の形態２に係る画像検索装置で実行されるマッチング実行処理手順のサブルーチン及び画像表示処理の手順を示すフローチャートである。 本発明の実施の形態２に係る画像検索装置で実行される画像表示処理及び蓄積画像送信処理夫々の手順を示すフローチャートである。る。 本発明の実施の形態２に係る画像検索装置の結果テーブルを説明する模式図である。 本発明の実施の形態３に係る画像検索装置で実行される登録抹消処理及び蓄積画像送信処理夫々の手順を示すフローチャートである。 本発明の実施の形態３に係る画像検索装置で実行される登録抹消処理、画像削除処理及び登録無効化処理夫々の手順を示すフローチャートである。 本発明の実施の形態３に係る画像検索装置の特徴管理テーブルを説明する模式図である。 本発明の実施の形態３に係る画像検索装置で実行されるＤＢ側送信処理の手順を示すフローチャートである
符号の説明
１ 画像検索装置
２ 蓄積ＤＢサーバ（計算機）
２０，３０，４０，５０，６０，７０ ＣＰＵ（演算部）
３ 検索ＤＢサーバ（計算機）
４ 特徴抽出サーバ（計算機）
５ 検索実行サーバ（計算機）
６ 入力側端末機（計算機）
７ 出力側端末機（計算機）
７３ 表示部
９０ 蓄積部
９１ 蓄積管理テーブル（リレーショナル・データベース）
９２，９２１，…，９２Ｎ キー管理テーブル（リレーショナル・データベース）
９３，９３１，…，９３Ｎ 特徴管理テーブル（リレーショナル・データベース）

Claims (11)

  1. 指定された画像に類似する画像を、リレーショナル・データベースを用いて検索する検索手段を備える画像検索装置において、
    前記リレーショナル・データベースは、
    画像を蓄積する蓄積部に蓄積されている画像、及び該画像を識別する識別情報が関連付けられている蓄積管理テーブルと、
    画像の特徴を数値的に示す特徴量、及び該特徴量よりも情報量が少ないインデックスキーが関連付けられているキー管理テーブルと、
    識別情報、及び該識別情報を有する画像の特徴量に対応するインデックスキーが関連付けられている特徴管理テーブルと
    を有し、
    前記検索手段は、
    前記指定された画像の特徴量に対応するインデックスキーと、前記蓄積部に蓄積されている画像の特徴量に対応するインデックスキーとを用いて、前記指定された画像に類似する画像を検索するようにしてあり、
    前記蓄積管理テーブル、前記キー管理テーブル、及び／又は前記特徴管理テーブルを参照して、前記指定された画像の特徴量に対応するインデックスキーを探し出す特徴キー探索手段と、
    前記特徴管理テーブルを参照して、前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、前記指定された画像と前記蓄積部に蓄積されている画像との類似度を算出する類似度算出手段と、
    該類似度算出手段が算出した類似度の高低に基づいて、前記指定された画像に類似する画像の識別情報を選択する画像選択手段と、
    前記蓄積管理テーブルを参照して、前記画像選択手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を検索結果として、前記検索手段による検索結果を表示する表示部へ出力する結果出力手段と
    を有し、
    前記リレーショナル・データベースに画像を登録する画像登録手段を更に備え、
    該画像登録手段は、
    前記リレーショナル・データベースに登録すべき画像を前記蓄積部に蓄積させる蓄積制御手段と、
    前記画像に基づいて、該画像の特徴量を算出する特徴算出手段と、
    前記画像に対して識別情報を発行する情報発行手段と、
    該情報発行手段が発行した識別情報、及び前記蓄積制御手段が前記蓄積部に蓄積した画像を関連付けて前記蓄積管理テーブルに登録する蓄積管理登録手段と、
    前記キー管理テーブルを参照し、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されているか否かを判定する登録判定手段と、
    該登録判定手段が否と判定した場合、前記特徴量に対し、該特徴量よりも情報量が少ないインデックスキーを発行するキー発行手段と、
    該キー発行手段が発行したインデックスキー、及び前記特徴量を関連付けて前記キー管理テーブルに登録するキー管理登録手段と、
    前記識別情報、及び前記特徴量に関連付けて前記キー管理テーブルに登録されているインデックスキーを関連付けて前記特徴管理テーブルに登録する特徴管理登録手段と
    を有し、
    前記特徴管理テーブルの各レコードには、識別情報を格納する識別情報フィールドと、互いに異なるフィールド値が付与されており、夫々インデックスキーを格納するＭ（Ｍは２以上の自然数）個のキーフィールドとが関連付けて設けてあり、
    前記特徴管理登録手段は、
    インデックスキーをフィールド値に対応させるハッシュ関数、及び前記特徴管理テーブルに登録すべきインデックスキーに基づいて算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、前記インデックスキーを格納する手段と、
    互いにハッシュ値が等しい前記インデックスキーが複数存在する場合は、前記インデックスキー夫々を、異なるレコードのキーフィールドに格納する手段と、
    インデックスキーが格納されているキーフィールド及び格納されていないキーフィールドを有するレコードに関し、インデックスキーが格納されていないキーフィールドに、インデックスキーが格納されていないことを示すキー未格納情報を格納する手段と
    を有し、
    前記類似度算出手段は、
    前記ハッシュ関数、及び前記特徴キー探索手段が探し出したインデックスキーに基づいて算出されたハッシュ値に基づいて、前記特徴管理テーブルの前記ハッシュ値に等しいフィールド値が付与されているキーフィールドを特定する手段と、
    該手段が特定したキーフィールドに格納されているインデックスキーの内の前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて類似度を算出する手段と
    を有することを特徴とする画像検索装置。
  2. 各インデックスキーは、少なくとも前記類似度算出手段として機能する演算部が１つの命令で演算可能なデータ長を有することを特徴とする請求項１に記載の画像検索装置。
  3. 少なくともキー管理テーブル及び特徴管理テーブルの組が複数設けられており、
    一の組のキー管理テーブル及び特徴管理テーブルを用いて、前記特徴キー探索手段がインデックスキーを探索し、前記類似度算出手段が類似度を算出するようにしてあり、
    前記検索手段は、前記一の組のキー管理テーブルを参照して、前記指定された画像の特徴量に対応するインデックスキーに基づいて前記指定された画像の特徴量を探し出す手段を更に有し、
    該手段が探し出した前記指定された画像の特徴量、及び他の組のキー管理テーブル及び特徴管理テーブルを用いて、前記特徴キー探索手段がインデックスキーを探索し、前記類似度算出手段が類似度を算出するようにしてあることを特徴とする請求項１又は２に記載の画像検索装置。
  4. 各レコードのキーフィールドに付与されるフィールド値として、“０”以上“Ｍ−１”以下の整数を用いるようにしてあり、
    各インデックスキーは、整数を用いてなり、
    前記特徴管理登録手段は、インデックスキーをＭで除算した場合の剰余を求める前記ハッシュ関数、及び前記特徴管理テーブルに登録すべきインデックスキーに基づいて算出されたハッシュ値に等しいフィールド値が付与されているキーフィールドに、前記インデックスキーをＭで除算した場合の商を格納するようにしてあることを特徴とする請求項１から３の何れかひとつに記載の画像検索装置。
  5. 前記特徴管理登録手段は、前記登録判定手段が登録されていると判定した場合、登録されているインデックスキーを優先的にキーフィールドに格納するようにしてあり、
    前記キー発行手段は、前記特徴管理登録手段が前記インデックスキーを格納した後で、インデックスキーが未格納であるキーフィールドのフィールド値に等しいハッシュ値を有するインデックスキーの内、該インデックスキーに関連付けて前記キー管理テーブルに特徴量が登録されていないインデックスキーを発行するようにしてあることを特徴とする請求項１から４の何れかひとつに記載の画像検索装置。
  6. インデックスキー並びに特徴量及び識別情報を新規登録すべきキー管理テーブル及び特徴管理テーブルの組と、新規登録が終了しているキー管理テーブル及び特徴管理テーブルの組とが設けられており、
    前記キー発行手段は、
    前記新規登録が終了しているキー管理テーブルを参照し、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが登録されているか否かを判定する手段と、
    該手段が登録されていると判定した場合、登録されているインデックスキーのハッシュ値に等しいハッシュ値を有するインデックスキーを発行する手段と
    を有し、
    前記画像登録手段は、
    前記新規登録すべきキー管理テーブル及び特徴管理テーブルに対する新規登録が終了した後で、前記新規登録すべきキー管理テーブルに登録されている特徴量に一致する特徴量が、前記新規登録が終了しているキー管理テーブルに登録されているか否かを判定する第１手段と、
    該第１手段が登録されていると判定した場合、前記新規登録すべきキー管理テーブルに登録されているインデックスキーを、前記特徴量に関連付けて前記新規登録が終了しているキー管理テーブルに登録されているインデックスキーに対応付ける第２手段と、
    前記第１手段が否と判定した場合、登録されていないと判定された特徴量に関連付けて前記新規登録すべきキー管理テーブルに登録されているインデックスキーのハッシュ値に等しいハッシュ値を有し、しかも、前記新規登録が終了しているキー管理テーブルにて特徴量に関連付けられていないインデックスキーを発行する第３手段と、
    該第３手段が発行したインデックスキー、及び前記特徴量を関連付けて前記新規登録が終了しているキー管理テーブルに登録する第４手段と、
    前記新規登録すべきキー管理テーブルに登録されているインデックスキーを、前記第３手段が発行したインデックスキーに対応付ける第５手段と、
    前記新規登録すべき特徴管理テーブルに登録されている識別情報及びインデックスキーを、該インデックスキーを前記第２手段及び／又は第５手段によって対応付けられているインデックスキーに変換して、前記新規登録が終了しているキー管理テーブル及び特徴管理テーブルに登録する第６手段と
    を更に有することを特徴とする請求項１から５の何れかひとつに記載の画像検索装置。
  7. 前記キー管理テーブルは、画像の特徴量又は画像に付属する付属情報と、少なくとも前記特徴量よりも情報量が少ないインデックスキーとが関連付けられるようにしてあり、
    前記検索手段は、
    前記蓄積管理テーブル、前記キー管理テーブル、及び／又は前記特徴管理テーブルを参照して、指定された付属情報に対応するインデックスキーを探し出す情報キー探索手段と、
    前記特徴管理テーブルを参照して、前記情報キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて、付属情報が一致していることを示す一致情報を付与する情報付与手段と
    を更に有し、
    前記結果出力手段は、前記蓄積管理テーブルを参照して、前記画像選択手段が選択した識別情報の内、前記情報付与手段が一致情報を付与した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得するようにしてあり、
    前記画像登録手段は、
    前記キー管理テーブルを参照し、前記リレーショナル・データベースに登録すべき画像の付属情報に関連付けてインデックスキーが既に登録されているか否かを判定する第２の登録判定手段と、
    該第２の登録判定手段が否と判定した場合、前記付属情報に対してインデックスキーを発行する第２のキー発行手段と、
    該キー発行手段が発行したインデックスキー、及び前記付属情報を関連付けて前記キー管理テーブルに登録する第２のキー管理登録手段と、
    前記情報発行手段が発行した識別情報、及び前記付属情報に関連付けて前記キー管理テーブルに登録されているインデックスキーを関連付けて前記特徴管理テーブルに登録する第２の特徴管理登録手段と
    を更に有することを特徴とする請求項１から６の何れかひとつに記載の画像検索装置。
  8. 互いに通信可能な複数の計算機を用いてなり、
    各計算機は、前記蓄積部、前記リレーショナル・データベースが有する各種管理テーブル、前記検索手段が有する各手段、前記表示部、前記画像登録手段が有する各手段の内の１つ以上を備えることを特徴とする請求項１から７の何れかひとつに記載の画像検索装置。
  9. 前記キー管理テーブルには、関連付けられているインデックスキー及び特徴量に更に関連付けて、該特徴量を有する画像の枚数を示す枚数情報が登録されるようにしてあり、
    前記キー管理登録手段は、インデックスキー及び特徴量を関連付けて前記キー管理テーブルに登録する際に、前記枚数情報を登録するようにしてあり、
    前記類似度算出手段は、
    前記特徴キー探索手段が探し出したインデックスキーの内、前記キー管理テーブルにて前記インデックスキーに一致するインデックスキーに関連付けられている枚数情報が示す枚数が所定枚数以上であり、且つ、前記枚数が最も少ないインデックスキーから枚数の少なさの順にインデックスキーを特定する手段と、
    前記特徴管理テーブルを参照して、前記手段が特定したインデックスキーに関連付けられている識別情報を特定し、特定した識別情報に関連付けて類似度を算出する手段と
    を有し、
    前記画像登録手段は、
    前記登録判定手段が、前記特徴算出手段が算出した特徴量に関連付けてインデックスキーが既に登録されていると判定した場合、登録されているインデックスキーに関連付けられている枚数情報を増加させる枚数計数手段
    を更に有することを特徴とする請求項１から８の何れかひとつに記載の画像検索装置。
  10. 前記画像選択手段は、
    暫定的に、前記類似度算出手段が算出した類似度が所定類似度以上に達した識別画像を選択する第１の手段と、
    最終的に、前記類似度算出手段が算出した類似度が最も高い識別画像から類似度の高さの順に識別画像を選択する第２の手段と
    を有し、
    前記結果出力手段は、
    前記第１の手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を暫定的な検索結果として前記表示部へ出力する手段と、
    前記第２の手段が選択した識別情報に一致する識別情報に関連付けられている画像を前記蓄積部から取得して、取得した画像を最終的な検索結果として前記表示部へ出力する手段と
    を有することを特徴とする請求項１から９の何れかひとつに記載の画像検索装置。
  11. 前記リレーショナル・データベースから画像の登録を抹消する際、少なくとも前記特徴管理テーブルについて、登録を抹消すべき画像の識別情報に対し、無効を意味する無効情報を付与する無効付与手段を更に備え、
    前記類似度算出手段は、前記無効情報が付与されている識別情報を除く識別情報の中から、前記特徴キー探索手段が探し出したインデックスキーに一致するインデックスキーに関連付けられている識別情報を特定するようにしてあることを特徴とする請求項１から１０の何れかひとつに記載の画像検索装置。
JP2007341547A 2007-12-29 2007-12-29 画像検索装置 Active JP5142705B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2007341547A JP5142705B2 (ja) 2007-12-29 2007-12-29 画像検索装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007341547A JP5142705B2 (ja) 2007-12-29 2007-12-29 画像検索装置

Publications (2)

Publication Number Publication Date
JP2009163466A JP2009163466A (ja) 2009-07-23
JP5142705B2 true JP5142705B2 (ja) 2013-02-13

Family

ID=40966022

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007341547A Active JP5142705B2 (ja) 2007-12-29 2007-12-29 画像検索装置

Country Status (1)

Country Link
JP (1) JP5142705B2 (ja)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130133243A (ko) * 2011-01-07 2013-12-06 톰슨 라이센싱 온라인 저장을 위한 장치 및 방법, 송신 장치 및 방법, 및 수신 장치 및 방법
CN103903291B (zh) * 2012-12-24 2017-05-31 阿里巴巴集团控股有限公司 一种自动修改图片的方法和装置
JP6329840B2 (ja) * 2014-07-30 2018-05-23 東芝テック株式会社 認識辞書管理装置及びプログラム
JP6515457B2 (ja) * 2014-07-31 2019-05-22 株式会社リコー 情報処理システム、情報処理方法および情報処理装置
US11651037B2 (en) * 2019-12-20 2023-05-16 Rakuten Group, Inc. Efficient cross-modal retrieval via deep binary hashing and quantization

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3143532B2 (ja) * 1992-11-30 2001-03-07 キヤノン株式会社 画像検索装置及び方法
JP2006185320A (ja) * 2004-12-28 2006-07-13 Ricoh Co Ltd 画像検索装置
EP1914680A4 (en) * 2005-03-01 2012-10-24 Univ Osaka Prefect Public Corp DOCUMENT / IMAGE PROCEDURE AND PROGRAM, AND DOCUMENT / IMAGE RECORDING AND SEARCH APPARATUS

Also Published As

Publication number Publication date
JP2009163466A (ja) 2009-07-23

Similar Documents

Publication Publication Date Title
US10025904B2 (en) Systems and methods for managing a master patient index including duplicate record detection
CN102918494B (zh) 基于数据库模型不可知论、纲要不可知论且工作负载不可知论的数据存储和存取模型的数据存储和/或检索方法和系统
US10572461B2 (en) Systems and methods for managing a master patient index including duplicate record detection
EP1074925B1 (en) Document management system, information processing apparatus, document management method and computer-readable recording medium
JP5142705B2 (ja) 画像検索装置
US7937652B2 (en) Document processing device, computer readable recording medium, and computer data signal
US20150106401A1 (en) System and methods for metadata management in content addressable storage
US20030225770A1 (en) Collaborative data cleansing
EP2013779A2 (en) Method, apparatus and computer-readabele medium to provide customized classification of documents in a file management system
CN107273977A (zh) 用于标识匹配的方法、系统和机器可读硬件存储装置
CN107148616A (zh) 用于分布式版本控制的高效注释系统
JP2009522677A (ja) ノードの番号付けによるファイル・システムのダンプ／復元のための方法、システム、およびデバイス
CN103631842A (zh) 用于检测多列复合键列集合的方法和系统
JP5424798B2 (ja) メタデータ設定方法及びメタデータ設定システム、並びにプログラム
CN114880483A (zh) 一种元数据知识图谱构建方法、存储介质及系统
JP3140922B2 (ja) 設備管理システム
US11880392B2 (en) Systems and methods for associating data with a non-material concept
JP4011662B2 (ja) 電子ファイリング方法及び装置
TWI659320B (zh) 內容可索引之文件影像檔的建立方法及其索引方法
Golshanara Temporal Data Exchange and Repair
JP2023176448A (ja) 情報処理装置、情報処理システム、情報処理方法及びプログラム
Chatterjee et al. A probabilistic approach to information retrieval in heterogeneous databases
CN117009588A (zh) 一种基于知识图谱的三维数据关联检索方法
JP2022050169A (ja) 情報処理システム及びプログラム
GB2493962A (en) Database record repair

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20100218

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20120227

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20120313

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20120409

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20121030

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20121120

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20151130

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 5142705

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150