JP4895340B2

JP4895340B2 - 情報処理装置およびその方法

Info

Publication number: JP4895340B2
Application number: JP2005104363A
Authority: JP
Inventors: 充鵜沢
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-03-31
Filing date: 2005-03-31
Publication date: 2012-03-14
Anticipated expiration: 2025-03-31
Also published as: US20060221357A1; US8112706B2; JP2006285612A

Description

本発明は情報処理装置およびその方法に関し、例えば、文書管理システムのようなデータを管理するシステムの情報処理に関する。

近年、環境問題に対する意識が高まる中、オフィスのペーパレス化が急速に進んでいる。このような状況において、バインダなどによって蓄積された文書や配布資料などをスキャナで読み取り、読み取った文書画像へのレイアウトを解析してオブジェクトに分割し、オブジェクトを解析し処理してオブジェクトをデータ化することで、オブジェクトの再利用、文書画像の圧縮蓄積および文書のオリジナル文書の検索を実現するシステムが提案されている（例えば特許第3017851号公報）。

オリジナル文書の検索は、オリジナル文書および読み取った文書画像からそれぞれ、テキスト、写真、線画などのオブジェクトの属性ごとの特徴量を算出し、テキストの類似度、写真の類似度、そして各オブジェクトのレイアウトに関するレイアウトの類似度など、複数の類似度を算出し、それら算出結果を総合的に判断する検索手法（このような検索を「複合検索」という）が適している。

複合検索によれば、検索性能を飛躍的に向上させることが可能である。とくに、文書管理システムが取り扱う文書は、テキスト属性のオブジェクトが多い文書から写真や線画の多い文書に至る、多岐に亘る文書が存在するため、検索精度、検索効率を考えると、複合検索の有効性は極めて高いと言える。

ところで、文書管理システムに登録する文書が、文書画像を読み取って作成した電子データであれば、レイアウト解析、オブジェクト解析により解析された情報に基づき検索インデックスを作成することが可能である。同様に、登録する文書が、ラスタ形式の画像データであれば、解析情報に基づき検索インデックスを作成することが可能である。しかし、登録する文書が、パーソナルコンピュータ(PC)上のアプリケーションで作成されたアプリケーションデータの場合は、同様の解析処理を行うことができず検索インデックスを作成することができない。言い換えれば、PC上で生成される文書のアプリケーションデータと、紙に印刷された文書を読み取った電子データを同一に扱うことはできない。

勿論、オフィスで頻繁に使われる汎用のアプリケーションについては、文書管理システムに、当該アプリケーションのデータを解析するプログラムをモジュールとして組み込み、アプリケーションデータをラスタライズして、読み取った文書画像と同様に解析処理を行い検索インデックスを作成することは可能である。しかし、すべてのアプリケーションに対して、上記の解析モジュールを用意することは不可能だから、文書管理システムがラスタライズできないアプリケーションデータは上記の解析処理によって検索インデックスを作成することができない。

特許第3017851号公報

本発明は、アプリケーションデータを検索可能にデータ管理システムに登録することを目的とする。

本発明は、前記の目的を達成する一手段として、以下の構成を備える。

本発明にかかる情報処理は、データ管理システムへのアプリケーションデータの登録指示を受け付け、前記登録指示が示すアプリケーションデータが前記データ管理システムによって解釈されレンダリングが可能か否かを判定し、前記アプリケーションデータを前記データ管理システムがレンダリング可能なPDLデータに変換し、前記判定結果が解釈およびレンダリング不能を示す場合、前記登録指示が示すアプリケーションデータに検索情報を付加するか否かを示す指示を受け付け、前記判定結果が解釈およびレンダリング可能を示す場合は前記登録指示が示すアプリケーションデータを前記データ管理システムに送信し、前記判定結果が解釈およびレンダリング不能を示し、前記受け付けた指示が検索情報の付加を示す場合は前記登録指示が示すアプリケーションデータを前記変換したPDLデータと前記アプリケーションデータを組み合わせたデータを前記データ管理システムに送信し、前記送信されたPDLデータは、当該PDLデータに対応するアプリケーションデータを検索するための検索インデックスを作成するために前記データ管理システムに使用され、前記検索インデックスは、前記PDLデータをレンダリングしたビットマップ画像データのレイアウト特徴量から作成されることを特徴とする。

本発明によれば、アプリケーションデータを検索可能に電子データ管理システムに登録することができる。従って、例えば文書管理システムにおいて、文書から読み取った画像データとアプリケーションデータを区別することなく扱うことができる。

以下、本発明にかかるデータ管理システムの実施例として文書管理システムを図面を参照して詳細に説明する。

［画像処理システム］
図1は複合機を使用して情報の電子化を行う文書管理システムの構成例を示すブロック図である。

この文書管理システムは、オフィス（のような複数の区分）10と20がインターネットのようなWAN 104で接続された環境で実現される。

オフィス10内に構築されたLAN 107には、複合機(MFP: Multi-Function Processor) 100、MFP 100を制御するマネージメントPC 101、クライアントPC 102、文書管理サーバ106、文書管理サーバによって管理されるデータベース105などが接続されている。オフィス20はオフイス10とほぼ同様の構成を有するが、オフィス20内に構築されたLAN 108には、少なくとも文書管理サーバ106、文書管理サーバによって管理されるデータベース105、クライアントPC 102などが接続されている。オフィス10のLAN 107とオフィス20のLAN 108は、LAN 107に接続されたプロキシサーバ103、WAN 104、および、LAN 108に接続されたプロキシサーバ103を介して、相互に接続されている。

図1に示す文書管理システムにおいて、検索対象の文書の登録場所はとくに限定されない。つまり、MFP 100の記憶部、マネージメントPC 101の記憶部、データベースサーバ105に何れに登録されていてもよい。ただし、登録文書を検索することができるように、文書の登録場所はLAN107または108を介してアクセス可能な状態になっている。

また、後述する情報処理は、図1に示す文書管理システムの任意の装置上で実現可能である。つまり、MFP 100の後述するデータ処理装置、マネージメントPC 101、文書管理サーバ106の何れかあるいはすべてが当該情報処理を実行する機能を備えていてよい。

● マネージメントPC
図2はマネージメントPC 101とMFP 100の構成例を示すブロック図である。

マネージメントPC 101のCPU 1は、RAM 2をワークメモリとして、ROM 3のプログラムROMまたはハードディスク(HD) 11に格納されたオペレーティグシステム(OS)やプログラムを実行し、システムバス1に接続された各部を総括的に制御するとともに、MFP 100の制御および後述する情報処理などを実行する。また、HD 11に格納されたアプリケーションプログラムを実行して、図形、写真画像、文字、線画、表、コンピュータグラフィックス(CG)などが混在する文書を処理する。

また、ROM 3のプログラムROMまたはHD 11は、文書管理システム用のドライバプログラムを記憶する。また、ROM 3のデータROMまたはHD 11は、文書処理などの際に使用する各種データが記憶し、さらに、HD 11は文書処理に使用するフォントデータなどを記憶する。

キーボードコントローラ(KBC) 5は、キーボードやマウスなどのポインティングデバイスからなる入力デバイス9からの入力を制御する。ビデオカード(VC) 6は、モニタ10の表示を制御する。ディスクコントローラ(DKC) 7は、各種プログラム、各種データを記憶するHD 11の読み書きを制御する。ネットワークインタフェイスカード(NIC) 31は、LAN 107とのデータのやり取りを制御する。汎用インタフェイス(I/F) 8は、例えばUSB (Universal Serial Bus)はIEEE1394などのシリアルバスなどで、通信線109を介してMFP 100に接続される。

なお、通信線109を介してMFP 100に接続されていない点を除けば、クライアントPC 102もマネージメントPC 101とほぼ同様の構成および機能を有する。従って、以下で説明するマネージメントPC 101の動作、機能は、MFP 100の制御に関する部分を除くと、そのままクライアントPC 102の動作、機能に当てはまる。

CPU 1は、モニタ10に表示したユーザインタフェイスに対して、ユーザが入力デバイス9を操作して入力する指示に基づき、様々なウィンドウを開き、様々なデータ処理を実行する。ユーザは、文書の印刷または登録を望む場合、印刷または登録画面を開く。この印刷または登録画面は、文書管理システムのドライバソフトウェアによって提供されるユーザインタフェイスであり、ユーザは当該画面を用いて、プリンタの設定、印刷モードの設定、および、文書が登録された（または文書を登録する）記憶部の選択、登録モードの設定を含む様々な設定、選択を行うことができる。

● MFP
図2に示すように、MFP 100は、CPUを備えるデータ処理部15を中心に、汎用I/F 18、RAM19、ROM 13、プリンタI/F 16およびプリンタ17、スキャナI/F 14およびスキャナ12、キーボードやタッチパネルで構成される操作パネル20、LCDなどのディスプレイ23、並びに、HDなどの記憶部24を有する。

データ処理部15は、RAM 19をワークメモリとして、ROM 13のプログラムROMまたは記憶部24に格納された制御プログラムに基づき、MFP 100を統括的に制御し、ROM 13のプログラムROMまたは記憶部24に格納された画像処理プログラムに基づき、次の処理を制御する。

データ処理部15は、ディスプレイ23にユーザインタフェイスを表示して、操作パネル20を操作するユーザからの指示を受け付ける。ユーザが原稿の複写を指示した場合、オートドキュメントフィーダ(ADF)を有するスキャナ12を制御して、一枚または重ねられた複数の原稿それぞれの画像を、光源で照射し、原稿からの反射像をレンズで固体撮像素子上に結像し、固体撮像素子からラスタ順の画像読取信号（例えば600dpi、8ビット）を得る。そして、画像読取信号を記録信号へ変換し、複数枚の記録紙に複写する場合は、一旦、記憶部24に一頁分の記録信号を記憶した後、記録信号を繰り返しプリンタ17に出力することで、複数の記録紙に画像を形成する。

一方、クライアントPC 102から出力されるプリントデータは、LAN 107を介してNIC 32へ入力され、データ処理部15によって記録可能なラスタデータに変換された後、プリンタ17によって記録紙上に画像として形成される。

また、データ処理部15は、汎用I/F 18を介してマネージメントPC 101と通信し、MFP 100の状態や画像処理の結果などをマネージメントPC 101に送信するとともに、マネージメントPC 101から指示やデータを受信する。従って、MFP 100に対するユーザの指示は、MFP 100に装備された操作パネル20およびマネージメントPC 101の入力デバイス9によって行うことができる。

● 処理の概要
図3はマネージメントPC 101（またはクライアントPC 102）およびMFP 100による文書管理処理を説明する機能ブロック図である。

ユーザは、マネジメントPC 101またはMFP 100を操作して、MFP 100の記憶部24、マネージメントPC 101のHD 11、データベースサーバ105などに文書を登録し、あるいは、ユーザが所持する文書のオリジナルデータまたは類似する文書データを検索することができる。その際、マネジメントPC 101およびMFP 100は、検索の指定内容を含むユーザの入力、MFP 100の状態、登録すべき文書、文書管理システムの動作状態、検索状況、検索結果、検索した文書などをディスプレイ23またはモニタ10に表示する。

また、ユーザは、LAN 107を介してマネジメントPC 101およびMFP 100に接続されたクライアントPC 102を操作して、クライアントPC 102のHD 11に格納したアプリケーションデータをMFP 100に供給して、文書の印刷、文書管理システムへの登録、文書のオリジナルデータまたは類似する文書データの検索、検索した文書の印刷などが可能である。

文書の印刷、つまり、クライアントPC 102で稼働するアプリケーション322によってモニタ10に表示されている文書を印刷する場合、ユーザは、入力デバイス9を操作して印刷を指示する。印刷を指示されたアプリケーション322は、プリンタドライバ324を呼び出すとともに、アプリケーションデータ（GDI (Graphic Device Interface)描画命令（関数））をグラフィクエンジン323に渡す。グラフィクエンジン323は、GDI描画命令をDDI (Device Driver Interface)描画命令（関数）に変換して、プリンタドライバ324に渡す。プリンタドライバ324は、DDI描画命令をプリンタが解釈可能なページ記述言語(PDL)のようなデータ記述言語で記述したデータ（以下「PDLデータ」と呼ぶ）に変換してMFP 100に送信する。

MFP 100のデータ処理部15は、通信制御部312によりクライアントPC 102からPDLデータを含む印刷ジョブを受信すると、レンダリング部314により受信したPDLデータをレンダリングしてラスタ画像に変換し、画像処理部317により様々な画像処理を施して、プリンタ17により記録紙に画像を印刷する。

［文書管理］
次に、文書の登録および検索について説明する。

実施例の文書管理システムは、文書画像を用いて、システムに登録されたオリジナルデータを検索することが可能である。検索対象の文書は、テキストが主体の文書、テキストと表によって構成された文書、タイトル（テキスト）と表のみで構成された文書、写真と線画によって構成された文書というように、文書によってその特徴が異なる。実施例の文書管理システムは、様々な文書に対応し、精度よく検索を実行するために、文書それぞれがもつ特徴量を活かした検索を行う。

また、実施例の文書管理システムは、文書から読み取った画像から作成したデータ（以下「電子化データ」と呼ぶ）と、アプリケーションデータを同一に扱い、どちらのデータも文書として登録することができる。従って、ユーザが所有する文書から登録された文書を検索する場合、電子化データだけでなくアプリケーションデータも検索することが可能である。電子化データとアプリケーションデータを同一に扱って検索するために、両データから同じ基準で検索インデックスを作成し、同じ基準で類似率を計算する。

● 検索インデックスの作成
図4は検索インデックスの構成例を示す図である。

検索インデックスは、詳細は後述するが、レイアウト特徴量およびブロック特徴量から構成する。レイアウト特徴量は、文書画像をテキスト、写真、表、線画、図形などの属性ごとにセグメント化して、各ブロック（セグメント）の位置、大きさといったレイアウトに関する情報を特徴量とする。

また、ブロック特徴量は、各ブロックの特徴量で、テキスト属性のブロックであればテキストのコード、フォント情報などであり、表属性のブロックであればセルの数、大きさ、罫線の数などである。つまり、ブロックの属性に応じた細かな特徴量をブロック特徴量にする。なお、検索インデックスに用いる特徴量は、電子化データ、アプリケーションデータとも同じ解析処理によって計算する。

● 電子化データの登録
次に、電子化データの登録処理を説明する。当該処理は、マネージメントPC 101のCPU 1、MFP 100のデータ処理部15、クライアントPC 102のCPU 1の何れが実行してもよいが、以下では、MFP 100のデータ処理部15が実行するとして説明する。

ユーザは、文書を登録する記憶部を設定（または選択）し、登録形態などの情報を入力する。図3において、データ処理部15は、ユーザの指示を入力し、スキャナ12により文書画像を読み取り、画像処理部317により入力画像処理を施す。画像処理部317は、処理した画像データをインデックス作成部316に送る。インデックス作成部316は、上述したセグメント化を行って電子化データを作成するとともに検索インデックスを作成し、電子化データと検索インデックスをデータベース管理部313に送る。データベース管理部313は、電子化データと検索インデックスを関連付けて、ユーザが設定した記憶部に登録する。なお、検索インデックスの登録場所は、関連付けしたデータの登録場所と異なる場合もある。また、検索インデックスの作成および関連付けは後述する。

● アプリケーションデータの登録
次に、クライアントPC 102（またはマネージメントPC 101）からアプリケーションデータを登録する処理を説明する。この処理には、ハイパテキストマークアップ言語(HTML)などで記述されたデータ（以下「HTMLデータ」と呼ぶ）の解釈、および、ハイパテキスト転送プロトコル(http)をサポートするアプリケーション（以下「ブラウザ」と呼ぶ）320を利用する。

ユーザは、ブラウザ320を操作して、文書管理システムのユニフォームリソースロケータ(URL)（例えば、//docusys.xx.jp/、//192.168.100.35/など）を指定すると、文書管理システムからHTMLデータを受信する。言い換えれば、文書管理システムはWebサーバとしても機能している。また、IPアドレスで文書管理システムのWebサーバを指定する場合は、文書管理システムのソフトウェアを実行している装置（MFP 100、マネージメントPC 101または文書管理サーバ106）のIPアドレスを指定する必要がある。一方、ドメイン名（上の例では「docusys.xx.jp」を指定する場合、ブラウザ320は、ネットワーク上のドメインネームサービス(DNS)サーバからドメイン名に対応するIPアドレスを受信し、受信したIPアドレスに基づき文書管理システムのWebサーバにアクセスする。

図5は受信したHTMLデータの表示例を示す図である。図5において、ブラウザウィンドウ6001には、文書管理システムが管理し、ユーザに提供するフォルダの構成が表示されている。フォルダ6010はユーザにとってルートフォルダで、ルートフィルダ6010には四つの下位フォルダ6011〜6014が収容されている。なお、ユーザがURL+フォルダの形式（例えば、//docusys.xx.jp/mine/）を指定した場合は、指定フォルダより下位のフォルダ構成が表示される。例えば、ユーザがフォルダ6014をクリックするなどして選択すると、ウィンドウ6015にフォルダ6014が収容するファイル名などが表示される。ユーザは、文書管理システムに登録したいアプリケーションデータのアイコンを、ウィンドウオペレーティングシステムの操作と同様に、所望するフィルダにドラッグアンドドロップすることで、登録すべきアプリケーションデータおよび登録場所をブラウザ320に指示する。

図6はアプリケーションデータを登録する際にブラウザ320が実行する処理を示すフローチャートである。なお、この処理は、例えば、文書管理システムから受信したHTMLデータに含まれるJava(登録商標)Scriptのようなスクリプトをブラウザ320が実行することで実現する。

ブラウザ320は、ユーザからアプリケーションデータの登録指示を受けると(S750)、そのアプリケーションデータのファイル情報を取得し(S751)、取得したファイル情報を基に文書管理システムがアプリケーションデータを処理可能か否かを判定する(S752)。なお、処理可能とは、当該アプリケーションデータを作成したアプリケーションと同様に、文書管理システムが、当該アプリケーションデータを解釈してレンダリング可能であることを意味する。また、ステップS752における判定は、アプリケーションデータのバイナリレベルの構成を参照して判定してもよいし、アプリケーションデータのファイル名拡張子に基づき判定してもよい。

ブラウザ320は、文書管理システムが処理可能と判定した場合は、ユーザが予めブラウザ320に設定した登録設定情報と登録場所の情報を取得し(S757)、登録設定情報および登録場所の情報を例えばヘッダ情報として付加したアプリケーションデータを文書管理システムへ送信する(S758)。

一方、ブラウザ320は、文書管理システムが処理不能と判定した場合は、検索情報を付加するか否かの指示をユーザに促し(S753)、付加しない旨の指示を受けた場合は、検索情報を付加しない旨を登録設定情報に設定し、登録場所の情報を取得し(S757)、登録設定情報および登録場所の情報を例えばヘッダ情報として付加したアプリケーションデータを文書管理システムへ送信する(S758)。

また、ブラウザ320は、検索情報を付加する旨の指示を受けた場合、文書管理システム用のプリンタドライバ（つまりMFP 100用のプリンタドライバ）がクライアントPC 102にインストールされているか否かを判定し(S754)、未インストールの場合は文書管理システムからプリンタドライバを取得して、クライアントPC 102にインストールする(S755)。

次に、ブラウザ320は、アプリケーションデータを生成したアプリケーションを起動し、図3に示したアプリケーション322、グラフィクエンジン323およびプリンタドライバ324の組み合わせによってアプリケーションデータをPDLデータに変換し、変換終了後、アプリケーション322を終了する(S756)。続いて、登録設定情報と登録場所の情報を取得し(S757)、登録設定情報および登録場所の情報を例えばヘッダ情報として付加したPDLデータとアプリケーションデータの組み合わせを文書管理システムへ送信する(S758)。

文書管理システムは、クライアントPC 102から受信したデータを記憶部へ登録する。なお、文書管理システムは、マネージメントPC 101のCPU 1、MFP 100のデータ処理部15、文書管理サーバ106の何れが実行してもよいが、以下では、MFP 100のデータ処理部15が実行するとして説明する。

図3に示すデータ処理部15は、通信制御部312によりデータを受信すると、データのヘッダ情報を参照して、記憶部に登録すべきデータの場合は、当該データをデータベース管理部313へ送る。データベース管理部313は、データのヘッダ情報を参照してアプリケーションデータか否かを判定し、アプリケーションデータの場合は当該データをアプリケーションデータ処理部315へ送る。

アプリケーションデータ処理部315は、アプリケーションデータをレンダリングしてビットマップ画像データを作成し、ビットマップ画像データをインデックス生成部316へ送る。インデックス生成部316は、検索インデックスを作成し、検索インデックスをデータベース管理部313に送る。データベース管理部313は、登録設定情報から抽出した情報を検索インデックスに追加し、登録場所の情報が示す記憶部に、アプリケーションデータと検索インデックスを関連付けて登録する。

また、データのヘッダ情報に検索情報を付加しない旨が記録されたアプリケーションデータの場合、データベース管理部313は、登録設定情報から抽出した情報を検索インデックスとして、登録場所の情報が示す記憶部に、アプリケーションデータと検索インデックスを関連付けて登録する。

また、PDLデータが組み合わされたアプリケーションデータの場合、データベース管理部313は、PDLデータをレンダリング部314に送る。レンダリング部314は、PDLデータをレンダリングしてビットマップ画像データを作成し、ビットマップ画像データをインデックス生成部316へ送る。インデックス生成部316は、検索インデックスを作成し、検索インデックスをデータベース管理部313に送る。データベース管理部313は、登録設定情報から抽出した情報を検索インデックスに追加し、データのヘッダ情報に示される登録場所に、アプリケーションデータと検索インデックスを関連付けて登録する。

● プリンタドライバを利用した登録の詳細
図7はプリンタドライバを利用したアプリケーションデータの登録構成の一例を示す図であるが、クライアントPC 102がMFP 100で印刷を行う場合と同じ構成になる。なお、図3や図7に示すアプリケーション322、グラフィックエンジン323、プリンタドライバ324およびシステムスプーラ954は、HD 11にファイルとして格納されていて、実行する場合にOSまたはそれらを利用するモジュールによってRAM 2にロードされるプログラムモジュールである。また、アプリケーション322やプリンタドライバ324は、図示しないCD-ROMなどのメディア、あるいは、LAN 107を介してHD 11のHDに追加（インストール）することができる。

アプリケーション322は、MFP 100で印刷を行う場合、グラフィックエンジン323を利用して出力（描画）を行う。グラフィックエンジン323は、アプリケーション322から受信したGDI描画命令をDDI描画命令に変換してプリンタドライバ324に送る。プリンタドライバ324は、DDI描画命令（以下「印刷命令」と呼ぶ）をプリンタが処理可能なPDLデータに変換する。システムスプーラ954は、PDLデータをMFP 100に出力する。

［中間コードスプール機能がある場合のプリンタドライバを利用した登録］
図8はプリンタドライバを利用したアプリケーションデータの印刷または登録構成の他例を示す図であるが、印刷または登録データを一旦中間コードでスプールする場合の構成例である。

スプーラ1014は、グラフィックエンジン323からプリンタドライバ324へ送られる印刷命令を受け取って、中間コードからなるスプールファイル1015を生成する。これにより、スプーラ1014がすべての印刷命令を中間コードに変換してスプールファイル1015に格納した時点でアプリケーション322は印刷処理から開放される。言い換えれば、アプリケーション322は短時間に印刷処理から開放される。

スプールファイル1015に格納した中間コードは加工することができる。つまり、印刷または登録データに、拡大縮小（変倍）処理や、複数頁を一頁にレイアウトして印刷または登録するなど、アプリケーション322がもたない機能を実現することができる。中間コード状態の印刷または登録データを加工するには、通常、プリンタドライバ324が提供するユーザインタフェイスから設定を行う。

図8において、ディスパッチャ1012は、グラフィックエンジン323が出力する印刷命令を受け取り、アプリケーション322からグラフィックエンジン323へ発行された印刷命令の場合は、印刷命令をスプーラ1014へ送る。

スプーラ1014は、受け取った印刷命令を中間コードに変換してスプールファイル1015に格納する。また、スプーラ1014は、プリンタドライバ324によって設定された印刷または登録データに対する加工設定をプリンタドライバ324から取得してスプールファイル1014に格納する。なお、スプールファイル1015は、通常、HD 11上にファイルとして作成するが、RAM 2に作成しても構わない。

次に、スプーラ1014は、スプールファイル1015の作成状況をスプールファイルマネージャ1016に通知する。この通知に基づき、スプールファイルマネージャ1016は、スプールファイル1015に格納された印刷または登録データを加工設定に従い印刷することができるか否かを判定する。スプールファイルマネージャ1016は、印刷可能と判定すると、デスプーラ1017に、スプールファイル1015に格納された中間コードの印刷処理を指示する。

デスプーラ1017は、スプールファイル1015に格納された中間コードを、スプールファイル1015に格納された加工設定に従って加工し、加工した印刷または登録データをグラフィックエンジン323経由で出力する。

ディスパッチャ1012は、グラフィックエンジン323が出力する印刷命令がデスプーラ1017からグラフィックエンジン323へ発行された印刷命令の場合は、印刷命令をプリンタドライバ324へ送る。

プリンタドライバ324は、印刷命令をPDLデータに変換してシステムスプーラ954へ送る。システムスプーラ954は、PDLデータをMFP 100に出力する。

図8に示す構成によれば、上述した変倍処理や複数頁のレイアウト処理など、通常、アプリケーション322がもたない機能を実現することが可能である。さらに、登録処理においては、PDLデータに登録設定情報やアプリケーションデータのような電子データを組み込むことも可能である。

図9は文書登録時にプリンタドライバ324が提供するユーザインタフェイスの一例を示す図である。

プリンタドライバ324は、ブラウザ320と同様のフォルダ表示（図5参照）を行うとともに、文書管理システムが提供する記憶部（図では「データベース1」のように表示）を選択するプルダウンメニュー1157、および、登録設定情報などを設定するための詳細設定ボタン1156を表示する。

● PDLデータに組み込まれたアップリケーションデータの登録
図10は文書管理システムがPDLデータを解釈して文書を登録する処理を説明するフローチャートで、データ処理部15が実行する処理である。

図3に示すデータ処理部15は、通信制御部312によりPDLデータを受信すると(S1201)、PDLデータをレンダリング部314に送り、PDLデータをレンダリングさせる(S1202)。その際、レンダリング部314は、PDLデータに登録設定情報とアプリケーションデータが組み込まれている場合、それらを抽出して、レンダリングしたビットマップ画像データに添付する。

次に、データ処理部15は、印刷ジョブか登録ジョブかを判定し(S1203）、印刷ジョブであればレンダリング部314が出力するビットマップ画像データを画像処理部317へ送って、出力画像処理（輝度-濃度変換、マスキング、UCR、ガンマ補正、中間調処理、スクリーン線処理など）を行い(S1207)、プリンタ17に送って画像を印刷する(S1208)。

一方、登録ジョブの場合、データ処理部15は、ビットマップ画像データ、登録設定情報およびアプリケーションデータをインデックス生成部316へ送って、サムネイル画像を生成し(S1204)、検索インデックスを作成する(S1205)。そして、サムネイル画像、検索インデックス、登録設定情報およびアプリケーションデータをデータベース管理部313へ送り、登録設定情報から抽出した情報を検索インデックスに追加して、サムネイル画像、アプリケーションデータおよび検索インデックスを関連付けて記憶部24などに登録する(S1206)。

［検索インデックスの作成処理］
図11はインデックス生成部316が実行する画像データから検索インデックスを作成する処理を示すフローチャートである。

画像データを文字および線画領域、および、写真領域（写真属性のセグメント）に分割する。そして、文字および線画領域線から、さらに、段落を塊としてテキスト属性のセグメント、線属性のセグメント、罫線で囲まれた表属性のセグメント、図形属性のセグメントに分離するブロックセレクション(BS)処理を実行する(S1301)。その際、分割した各セグメントの配置を示すレイアウト情報を図4に示すレイアウト特徴量にする。

次に、写真属性のセグメントを除く各セグメントのオブジェクトをベクトル化し(S1302)、得られるデータをドキュメントアナリシスアウトプットフォーマット(DAOF)データとしてまとめる(S1303)。続いて、DAOF化したデータからテキストブロックの特徴量(S1304)、写真ブロックの特徴量(S1305)、表ブロックの特徴量(S1306)、線ブロックの特徴量(S1307)をそれぞれ抽出して、インデックス情報としてDAOFデータに追加する(S1308)。

● BS処理
BS処理は、図12に示す一頁の画像をオブジェクトの集合体と認識して、各オブジェクトの属性を文字(TEXT)、図形(PICTURE)、写真(PHOTO)、線画(LINE)、表(TABLE)に判別し、異なる属性を持つセグメント（ブロック）に分割する処理である。次に、ブロックセレクションの具体例を説明する。

先ず、処理すべき画像を白黒画像に二値化して、輪郭線追跡によって黒画素で囲まれる画素の塊を抽出する。所定面積以上の黒画素の塊については、その内部の白画素について輪郭線追跡を行い白画素の塊を抽出する。さらに、所定面積以上の白画素の塊の内部の黒画素の塊を抽出するというように、黒画素および白画素の塊の抽出を再帰的に繰り返す。

このようにして得られた画素塊に外接する矩形ブロックを生成し、矩形ブロックの大きさおよび形状に基づき属性を判定する。例えば、縦横比が1に近く、大きさが所定範囲の画素塊を文字属性の画素塊とし、さらに、近接する文字属性の画素塊が整列していてグループ化が可能な場合はそれらを文字領域とする。また、縦横比が小さい扁平な画素塊を線画領域に、所定以上の大きさで、かつ、矩形に近い形状を有し、整列した白画素塊を内包する黒画素塊が占める範囲を表領域に、不定形の画素塊が散在する領域を写真領域、その他の任意形状の画素塊を図画領域に、のようにそれぞれ分類する。

図13はブロックセレクションの結果の一例を示す図で、図13(a)は抽出された各矩形ブロックのブロック情報を示す。ブロック情報には、各ブロックの属性、位置の座標X、Y、幅W、高さH、OCR情報などが含まれる。属性は1〜5の数値で与えられ、「1」は文字属性、「2」は図形属性、「3」は表属性、「4」は線画属性、「5」は写真属性を表す。また、座標X、Yは入力画像における各矩形ブロックの始点のXY座標（左上角の座標）を、幅W、高さHは矩形ブロックのX座標方向の幅、Y座標方向の高さを、ポインタ情報の有無をそれぞれ表す。

また、図13(b)は入力ファイル情報で、ブロックセレクションによって抽出された矩形ブロックの総数を示す。

これら矩形ブロックごとのブロック情報は特定領域のベクトル化に利用される。また、ブロック情報によって、ベクトル化された特定領域とラスタデータの相対位置関係を特定することができ、入力画像のレイアウトを損わずにベクトル化領域とラスタデータ領域を合成することが可能になる。

● ベクトル化処理
ベクトル化処理は、各ブロックに属性に応じた適応的な処理を施し、各ブロックの再利用性を実現しつつ、高圧縮で高品質なデータへ変換する処理である。ベクトル化方法には、次の手法が存在する。

（a）文字属性のセグメントの場合は、OCR処理により文字画像を文字コードに変換する、または、文字のサイズ、スタイル、字体を認識して視覚的に忠実なフォントデータに変換する。

（b）線画または文字属性のセグメントで、OCR処理による文字認識が不可能な場合は、線画または文字の輪郭を追跡し、輪郭情報（アウトライン）を線分のつながりとして表現する形式に変換する。

（c）図形属性のセグメントの場合は、図形オブジェクトの輪郭を追跡し、輪郭情報を線分のつながりとして表現する形式に変換する。

（d）上記(b)または(c)の手法で得られた線分形式のアウトライン情報をベジェ関数などでフィッティングして関数情報に変換する。

（e）上記(c)の手法で得られた図形オブジェクトの輪郭情報から、図形の形状を認識し、円、矩形、多角形などの図形定義情報に変換する。

（f）表属性のセグメントの場合、罫線や枠線を認識し、所定のフォーマットの帳票フォーマット情報に変換する。

以上の手法のほかにも、画像データをコード情報、図形情報、関数情報などのコマンド定義形の情報に置き替える種々のベクトル化処理が考えられる。
文字領域のベクトル化

図14はベクトル化処理の詳細を示すフローチャートで、データ処理部115（またはマネージメントPC 101）によって実行される処理である。

まず、ブロック情報を参照して文字属性のセグメントか否か判断し(S901)、文字属性のセグメントであればステップS902に進んでパターンマッチングの一手法を用いて文字認識を行い、対応する文字コードを得る。

また、文字属性のセグメント以外の場合は、詳細は後述するが、画像の輪郭に基づくベクトル化を実行する(S912)。

文字属性のセグメントの場合は、横書き、縦書きの判定（組み方向の判定）を行うために、画素値に対する水平、垂直の射影をとり(S902)、射影の分散を評価し(S903)、水平射影の分散が大きい場合は横書き、垂直射影の分散が大きい場合は縦書きと判定して、その判定結果に基づき、行の切り出した後、文字を切り出して文字画像を得る(S904)。

文字列および文字への分解は、横書きならば水平方向の射影を利用して行を切り出し、切り出した行に対する垂直方向の射影から文字を切り出す。縦書きの文字領域に対しては、水平と垂直について逆の処理を行えばよい。なお、行、文字の切り出しに際して、文字のサイズも検出し得る。

次に、切り出した各文字について、文字画像から得られる特徴を数十次元の数値列に変換した観測特徴ベクトルを生成する(S905)。特徴ベクトルの抽出には種々の公知手法があるが、例えば、文字をメッシュ状に分割し、各メッシュ内の文字線を方向別に線素としてカウントしたメッシュ数次元ベクトルを特徴ベクトルとする方法がある。

次に、観測特徴ベクトルと、予め字種ごとに求めてある辞書特徴ベクトルとを比較して、観測特徴ベクトルと辞書特徴ベクトルの距離を算出し(S906)、算出した距離を評価して、最も距離の近い字種を認識結果とする(S907)。さらに、距離の評価結果から最短距離と閾値を比較して、最短距離が閾値未満であれば類似度が高いと判定し、最短距離が閾値以上であれば類似度が低いと判定する(S908)。最短距離が閾値以上の場合（類似度が低い場合）は、形状が類似する他の文字と誤認識している可能性が高いので、ステップS907の認識結果を採用せず、文字画像を線画と同様に扱い、文字画像のアウトラインをベクトル化する(S911)。言い換えれば、誤認識の可能性が高い文字画像は、視覚的に忠実なアウトラインのベクトルデータを生成する。

一方、類似度が高い場合は、ステップS907の認識結果を採用するとともに、文字認識に用いる字種数分の辞書特徴ベクトルを、文字形状種すなわちフォント種に対して複数用意しておき、パターンマッチングの際に、文字コードとともにフォント種を出力することで文字フォントを認識する(S909)。続いて、文字認識およびフォント認識よって得られた文字コードおよびフォント情報を参照し、文字コードおよびフォント情報それぞれに対応して予め用意されたアウトラインデータを用いて、各文字をベクトルデータに変換する(S910)。なお、カラー画像データの場合は、文字の色を抽出してベクトルデータとともに記録する。

以上の処理により、文字属性のセグメントに含まれる文字画像をほぼ形状、大きさ、色が忠実なベクトルデータに変換することができる。
文字領域以外のベクトル化

文字属性のセグメント以外、すなわち図形属性、線画属性、表属性と判定されるセグメントは、黒画素塊を抽出し、その輪郭をベクトルデータに変換する。なお、写真属性のセグメントおよび背景は、データ圧縮はするが、ベクトル化せず画像データのままにする。

文字領域以外のベクトル化は、まず、線画などを直線および/または曲線の組み合わせとして表現するために、曲線を複数の区間（画素列）に区切る「角」を検出する。図15はベクトル化における角抽出処理を説明する図で、角は曲率が極大になる点で、図15の曲線上の画素Piが角か否かは以下のように判定する。

画素Piを起点とし、線画曲線に沿って画素Piから両方向に所定画素数kずつ離れた画素Pi-k、Pi+kを線分Lで結ぶ。画素Pi-k、Pi+k間の距離をd1、画素Piから線分Lに直交するように下した線分の長さ（画素piと線分Lの距離）をd2が極大になる場合、あるいは、画素Pi-k、Pi+k間の弧の長さをAと距離d1の比d1/Aが所定の閾値以下になる場合、画素Piを角と判定する。

角を検出後、角によって分割された線画曲線の画素列を直線あるいは曲線で近似する。直線への近似は最小二乗法などにより実行し、曲線への近似は三次スプライン関数などを用いる。画素列を分割する角の画素は近似直線あるいは近似曲線における始端または終端になる。

さらに、ベクトル化された輪郭内に白画素塊の内輪郭が存在するか否かを判定し、内輪郭が存在する場合はその輪郭をベクトル化し、内輪郭の内輪郭というように、再帰的に黒画素塊および白画素塊の内輪郭をベクトル化する。

以上のように、輪郭の区分線を直線または曲線で近似する方法を用いれば、任意形状の図形のアウトラインをベクトル化することができる。また、入力画像がカラーの場合は、カラー画像から図形の色を抽出してベクトルデータとともに記録する。

図16はベクトル化において輪郭線をまとめる処理を説明する図である。

輪郭線の注目区間で外輪郭PRjと、内輪郭PRj+1または他の外輪郭が近接している場合、二つまたは三つ以上の輪郭線をひとまとめにして、太さをもつ線として表現することができる。例えば、輪郭PRj+1上の画素Pと、画素Piと最短距離の輪郭PRj上の画素Q間の距離PQを算出し、複数の画素間の距離PQiのばらつきが僅かである場合は、輪郭PRjおよびPRj+1を注目区間を線分PQの中点Mの点列に沿う直線または曲線で近似する。そして、中点Mの点列に沿う近似直線または近似曲線の太さは、例えば、距離PQiの平均値とすればよい。

線や線の集合体である表罫線は、太さをもつ線の集合として表すことにより、効率よくベクトル表現することができる。
図形の認識

以上で線図形などのアウトラインをベクトル化した後、ベクトル化された区分線を図形オブジェクトごとにグループ化する。

図17はベクトル化で生成したベクトルデータのグループ化処理を示すフローチャートで、ベクトルデータを図形オブジェクトごとにグループ化する処理を示している。

まず、各ベクトルデータの始点および終点を算出し(S1401)、始点および終点の情報を用いて、図形要素を検出する(S1402)。図形要素とは、区分線によって構成される閉図形であり、検出に際しては、始点、終点になっている共通の角の画素においてベクトルを連結する。すなわち、閉形状を構成するベクトル群はそれぞれ、その両端に連結するベクトルを有するという原理を応用する。

次に、図形要素内に他の図形要素もしくは区分線が存在するか否かを判定し(S1403)、存在すれば、ステップS1401およびS1402を再帰的に繰り返して、それらをグループ化して一つの図形オブジェクトとし(S1404)、存在しなければ、その図形要素を図形オブジェクトとする(S1405)。

なお、図17には一つの図形オブジェクト分の処理しか示さないが、他の図形オブジェクトが存在すれば、その分、図9の処理を繰り返す。
図形要素の検出

図18は図形要素の検出処理を示すフローチャートである。

まず、ベクトルデータより、両端に連結するベクトルを有しないベクトルを除去して、閉図形を構成するベクトルを抽出する(S1501)。

次に、閉図形を構成するベクトルについて、ベクトルの何れかの端点（始点または終点）を開始点として、一定方向（例えば時計回り）に順にベクトルを探索する。すなわち、他端点において他のベクトルの端点を探索し、所定距離内の最近接端点を連結ベクトルの端点とする。閉図形を構成するベクトルを一回りして開始点に戻ると、通過したベクトルすべてを一つの図形要素を構成する閉図形としてグループ化する(S1502)。また、閉図形内部にある閉図形を構成するベクトルもすべて再帰的にグループ化する。さらに、グループ化されていないベクトルの始点を開始点とし、上記と同様の処理を繰り返す。

そして、除去したベクトルのうち、閉図形としてグループ化したベクトルに端点が近接しているベクトル（閉図形に連結するベクトル）を検出し、検出したベクトルをそのグループにグループ化する(S1503)。

また、図19は図形を認識する他の方法を説明する図で、表属性のブロックの画像を二値化してアウトライン化したベクトル画像を示す図である。

図19に示す各閉曲線について、アウトラインの曲率、および、角情報から図形の形状を示す情報（円、楕円または多角形を示す情報）を抽出する。円は曲率が一定か否かで判断し、楕円は曲率の遷移情報を用いて判断する。また、多角形は角と角の間の曲率で判断する。例えば、図19の画像からは円および矩形の情報が抽出される。

次に、抽出した図形アウトラインと周辺のアウトラインの関係を調べる。例えば、アウトライン1103について詳しく説明すると、アウトライン1103に対応する外輪郭のアウトライン1104の記号○で示す角1111〜1116の間の曲率と、角間の距離との関係からアウトライン1103は太さをもつ楕円曲線として表現される。このとき、角1111と1112の間、角1113と1114の間、角1115と1116の間は楕円を構成しない部位のアウトラインとして分離する。なお、予め二値画像を細線化すれば、楕円と線の結合部位1121〜1123を効率的に抽出することも可能である。最後に、各アウトラインの直線部位を検出し、抽出した直線と対になる直線が存在するか判定し、存在すれば太さをもつ罫線に置き換える。なお、図形として認識されなかったものは、そのままアウトラインで記述する。

以上の処理によって、図形属性のセグメントに含まれる図形をほぼ形状、大きさ、色が忠実な再利用可能なベクトルデータに変換することができる。
表の認識

表の認識は、表のセルおよびその構成を認識し、枠を罫線の集合として表現する。

図20は表属性のブロックの画像を二値化してアウトライン化したベクトル画像を示す図である。アウトライン化すると、外輪郭と内輪郭が求められるが、例えば、外輪郭9001と内輪郭9002、9003、9004の関係よりセルの角9011、9012を求める。図21はセルの角を求めた結果を示す図で、セルの角を記号○で、罫線を実線で示す。これにより、セルの構成および罫線の位置情報が得られる。次に、各罫線が外輪郭と内輪郭の間を通るように各罫線の位置を調整し、輪郭線と罫線の位置の関係から罫線の太さを決定する。

以上の処理により、所定の太さをもつ罫線によって表を表現することが可能である。なお、このような二値画像から表の構成を認識する処理は、黒く塗り潰された領域を抽出する可能性がある。このような領域は本来セルであるが、二値化処理の際に閾値によりセルが抽出されてない可能性があるので、領域内のエッジ情報を調べたり、もしくは、閾値を変更して再度二値化しアウトライン化することで、より正確にセルを抽出して表を忠実にベクトル化することができる。

● 写真属性のセグメントおよび背景領域
前述したが、写真属性のセグメントおよび背景領域は、ベクトル化せずに適応的にデータ圧縮を施す。つまり、写真属性のセグメントおよび背景については、個別に、ラスタデータとしてJPEG圧縮したデータファイルを作成する。その際、背景の情報は画像中の不要部を意味するので、必要ならば低解像度もしくは高圧縮率によって画像データを作成することで、DAOF化の際にそのデータ量を減らすことができる。

● DAOFデータ
図22は一頁分の画像データをBS処理し、ベクトル化した結果、中間データ形式のファイルとして得られるDAOFデータ構造を示す図である。

DAOFは、ヘッダ1601、レイアウト記述データ部1602、文字認識記述データ部1603、表記述データ部1604および画像記述データ部1605からなり、ヘッダ1601は処理対象の入力画像に関する情報を保持する。

レイアウト記述データ部1602は、入力画像中の矩形セグメントの属性を示すTEXT（文字）、TITLE（タイトル）、CAPTION（キャプション）、LINE（線画）、PICTURE（図形）、FRAME（枠）、TABLE（表）、PHOTO（写真）などの情報と、それら矩形セグメントの位置情報を保持する。

文字認識記述データ部1603は、TEXT、TITLE、CAPTIONなどの文字属性の矩形セグメントのうち、ユーザにより指定された領域について、文字認識して得た文字認識結果を保持する。

表記述データ部1604は表属性の矩形セグメントの表構造の詳細を保持し、画像記述データ部1605は、図形属性や線画属性の矩形セグメントにおける、入力画像データから切り出した画像データを保持する。

ベクトル化した指定領域の画像記述データ部1605には、ベクトル化処理により得られたセグメントの内部構造や、画像の形状や文字コード等を表すデータの集合が保持される。一方、ベクトル化しない指定領域以外のセグメントに対しては、入力画像データそのものが保持される。

図23は文書構造ツリーの生成処理(S1703)の詳細を示すフローチャートである。なお、この処理における、全体制御の基本ルールとして、処理の流れはミクロブロック（単一矩形ブロック）からマクロブロック（矩形ブロックの集合体）へ移行する。以後「矩形ブロック」は、ミクロブロックおよびマクロブロック両者を意味するものとする。

まず、矩形ブロック単位に、縦方向の関連性に基づき矩形ブロックをグループ化する(S1801)。なお、図23に示す処理は繰り返し実行されることがあるが、処理開始直後はミクロブロック単位の判定になる。ここで、関連性とは、距離が近い、ブロック幅（横方向の場合は高さ）がほぼ同一である、などの特徴によって定義される。また、距離、幅、高さなどの情報はDAOFを参照する。

例えば、図24に示す入力画像の場合、その最上部で矩形ブロックT1、T2が横方向に並置されている。矩形ブロックT1、T2の下には横方向セパレータS1が存在し、横方向セパレータS1の下に矩形ブロックT3、T4、T5、T6、T7が存在する。矩形ブロックT3、T4、T5は、横方向セパレータS1の下側領域の左半部に、上から下に縦方向に配置され、矩形ブロックT6、T7は、横方向セパレータS1の下側領域の右半部に、上下に配置されている。

ステップS1801で、縦方向の関連性に基づくグルーピングを実行すると、矩形ブロックT3、T4、T5が一つのグループ（矩形ブロックV1）にまとめられ、矩形ブロックT6、T7が一つのグループ（矩形ブロックV2）にまとめられる。グループV1、V2は同一階層になる。

次に、縦方向のセパレータの有無をチェックする(S1802)。セパレータは、DAOF中で線画属性をもつオブジェクトであり、アプリケーションソフトウェア中では、明示的にブロックを分割する機能をもつ。セパレータを検出すると、処理対象の階層において、入力画像の領域をセパレータを境界として左右に分割する。図24の例には、縦方向のセパレータは存在しない。

次に、縦方向のグループの高さの合計が、入力画像の高さに等しいか否かを判定する(S1803)。すなわち、縦方向（例えば上から下）に処理対象の領域を移動しながら、横方向のグルーピングを行えば、入力画像全体の処理が終了した場合は、グループの高さの合計が入力画像の高さになることを利用して、処理の終了を判断する。

グルーピングが未了の場合は、横方向の関連位に基づき矩形ブロックをグループ化する(S1804)。これによって、図15に示す矩形ブロックT1、T2が一つのグループ（矩形ブロックH1）にまとめられ、矩形ブロックV1、V2が一つのグループ（矩形ブロックH2）にまとめられる。グループH1、H2は同一階層になる。ここでも、処理開始直後はミクロブロック単位での判定になる。

次に、横方向のセパレータの有無をチェックする(S1805)。セパレータを検出すると、処理対象の階層において、入力画像の領域をセパレータを境界として上下に分割する。なお、図24には、横方向のセパレータS1が存在する。

次に、横方向のグループの幅の合計が、入力画像の幅に等しいか否かを判定する(S1806)。これによって横方向のグルーピングに関する終了を判定する。横方向のグループの幅の合計が入力画像の幅（ページ幅）になった場合は、文書構造ツリーの生成処理を終了する。横方向のグループの幅の合計がページ幅未満であれば、処理をステップS1801に戻し、もう一段上の階層で縦方向の関連性チェックから繰り返す。

図25は、図24に示す画像V0から得られる文書構造ツリーを示す図である。

画像V0は、最上位階層にグループH1、H2、セパレータS1を有し、グループH1には第二階層の矩形ブロックT1、T2が属する。また、グループH2には、第二階層のグループV1、V2が属し、グループV1には、第三階層の矩形ブロックT3、T4、T5が属し、グループV2には、第三階層の矩形ブロックT6、T7が属する。

図25に示すツリーに達した段階で、横方向のグループの幅の合計がページ幅になるので、処理を終了し、最後にページ全体を表す最上位階層のV0を文書構造ツリーに付加する。そして、文書構造ツリーが完成した後、その情報に基づきアプリケーションデータを生成する。

まず、グループH1が横方向に二つの矩形ブロックT1、T2を有するので2カラムとして、T1のDAOFを参照し、その内部情報（文字認識結果の文章、画像等）を一つ目のカラム（左カラム）に出力する。その後、二つ目のカラム（右カラム）に移動して、T2の内部情報を出力し、その儀、セパレータS1を出力する。

次に、グループH2に移り、グループH2は横方向に二個の矩形ブロックV1、V2を有するので2カラムとして、グループV1の矩形ブロックT3、T4、T5の順にその内部情報を一つ目のカラム（左カラム）出力し、その後、二つ目のカラム（右カラム）に移動して、V2の矩形ブロックT6、T7の順にその内部情報を出力する。

● 特徴量の抽出(S1304〜S1307)
まず、概念検索用に、テキスト属性ブロックのオブジェクトからテキストブロックの特徴量を抽出する。後述する概念検索では、入力された文章の意味や文脈を解析し、その内容に関連する文書を検索する。概念検索によれば、通常の検索とは異なり、明確なキーワードが分からない場合でも、文書の検索が可能になる。概念検索用の検索インデックスの作成に使うテキストは文字認識したもの、あるいは、アプリケーションデータに格納されたテキストを使用する。

次に、全文検索用に、テキスト属性ブロックのオブジェクトからテキストブロックの特徴量を抽出する。なお、全文検索用のインデックス作成に使うテキストは、概念検索用のインデックスの作成に使用したものと同じである。

次に、画像検索用に、写真属性のブロックのオブジェクトから特徴量を抽出する。例えば、写真属性のブロックをメッシュ状に分割し、各区分の平均色を特徴量としたり、色の分布を特徴量とする。

次に、表検索用に、表属性のブロックのオブジェクトから特徴量を抽出する。表検索用の特徴量にはセルの構成を使用する。つまり、表を構成する各セルの大きさ、位置、セル内のテキストを特徴量とする。

次に、線画検索用に、図形属性および線属性のブロックのオブジェクトから特徴量を抽出する。線画の特徴量としては図形認識によって得た情報を使用する。例えば、図形を構成している線の位置、線幅、長さに加えて、図形の形状、位置、大きさなどである。

［文書登録の詳細］
上記の検索インデックスの生成処理により、検索インデックスが作成され、DAOF化された電子化データ、または、アプリケーションデータ（以下、まとめて「文書データ」と称す）は、ユーザが設定した登録設定情報および登録場所を示す情報を基に、記憶部のあるフォルダへ格納され、文書管理システムに登録される。

図26は文書管理システムに登録する文書データの一例を示す図である。なお、実施例では、文書管理システムのデータベースをXML (Extensible Markup Language)データベースとし、XML表現のデータを格納する。

図26に示す例では、文書データは、originalタグ領域2301に例えばBinHex変換されたバイナリデータとして格納されている。また、metaimageタグ領域2303は、文書データに関する解析情報を格納し、検索インデックスはタグ領域2304〜2306のように、DAOF化した文書データ表現に従い、最小単位のブロックごとに格納されている。また、BS処理、ベクトル化およびDAOF化したデータをそのままvectorgraphicタグ領域2307〜2309に格納してもよい。なお、BS処理、ベクトル化およびDAOF化したデータはベクタ画像としてoriginalタグ領域2301の文書データを表現するものであり、例えば文書データが電子化データの場合はベクタ画像のみを格納し、電子化データを格納する必要はない。

また、ブロックごとに検索インデックスとベクタ画像を格納することで、後述する類似原本検索の拡張として、ブロックごとの検索、ブロック情報の取り出し、といった高度な検索も可能である。

また、pdlタグ領域2302にPDLデータを格納してもよい。PDLデータを格納しない場合は、MFP 100により、検索結果のベクタ画像から文書を印刷する、あるいは、マネージメントPC 101のアプリケーションやプリンタドライバを使用して検索結果のアプリケーションデータから文書を印刷することになるが、PDLデータを格納すれば、MFP 100により、直ちに、検索結果の文書をPDLデータを用いて高画質に印刷することができる。

なお、上記の文書データの格納形態は、ユーザが設定する登録設定情報に基づき決定する。

なお、図26に示す例では、文書データと検索インデックスを一つのXMLデータファイルに格納する例を示している。もし、検索処理速度の向上を図るならば、検索インデックスは、記憶部の検索インデックス領域（検索テーブル）に、XMLデータファイルへのリンク情報とともに格納すればよい。

［検索処理］
次に、文書管理システムに登録された文書の検索を説明する。

図27は文書管理システムの文書検索処理を説明するフローチャートである。なお、この処理は、マネージメントPC 101のCPU 1、MFP 100のデータ処理部15、文書管理サーバ106の何れでも行えるが、以下ではMFP 100のデータ処理部15が行うとして説明する。

図3において、データ処理部15は、ユーザから文書の検索を指示されると、例えばスキャナ12により検索対象の文書の画像を読み取り、画像処理部317により入力画像処理を行う(S2401)。なお、スキャナ12による文書画像の読み取りのほか、例えば、通信制御部312によりクライアントPC 102から検索対象の文書画像の画像データを受信してもよい。

次に、データ処理部15は、文書画像の画像データをインデックス生成部316へ送り、上述したセグメント化を行って検索インデックスを作成し(S2402)、作成したDAOFデータの例えばベクタ画像とブロック解析情報をディスプレイ23に表示する(S2403)。

ユーザは、表示されたベクタ画像およびブロック解析情報を確認し、操作パネル20を操作して、必要であれば、検索対象の記憶部を指定し、解析結果の一つのブロックについて検索する、といった詳細な検索設定を行った後、検索を指示する。

データ処理部15は、ユーザの検索設定および検索指示を取得し(S2404)、検索設定に基づき記憶部にアクセスして(S2405)、後述する複合検索処理を実行する(S2406)。そして、検索の結果、類似度の高い文書データ（候補）を検出した場合、ディスプレイ23に候補のサムネイル画像などを表示する(S2407)。ユーザは、複数の候補が表示された場合、操作パネル20を操作して、それら候補の中から文書を特定する。

データ処理部15は、ユーザが文書を特定したか否かを判定し(S2408)、特定した場合は、特定された文書をディスプレイ23に表示し、ユーザの指示に応じて文書データを編集、転送または印刷する(S2409)。また、ユーザが文書データを特定せずに、操作パネル20のキャンセルボタンを押して所望する文書データが検出されなかった旨を示すと、データ処理部15は、検索設定を変更するか否かの旨をディスプレイ23に表示し、ユーザの判断を待つ(S2410)。ユーザが操作パネル20を操作して検索設定を変更する旨を指示した場合、データ処理部15は、処理をステップS2404に戻す。

● 複合検索処理(S2406)
複合検索処理は、インデックス生成部316によりBS処理した入力画像データの、図4に示す検索インデックスと、既に登録されている文書データの、図4に示す検索インデックスとを順次比較して、一致または類似する文書データを検索する処理である。つまり、レイアウト特徴量に基づき各ブロックの座標、幅、高さを比較し、ブロック特徴量に基づき各ブロックの属性を比較する。なお、ブロック特徴量の比較は、属性により異なる比較方法を適用する。

図28は複合検索処理を説明するフローチャートである。

まず、記憶部にアクセスして一つの文書データを選択し(S551)、レイアウト特徴量に基づく比較、および、ブロック特徴量に基づく比較を行って、入力画像データのブロックごとに文書データのブロックとの類似率を計算する(S552)。

次に、入力画像データのブロックごとの類似率から式(1)により総合類似率Nを計算する(S553)。
N = Σw_i×n_i +γ …(1)
ここで、n_iはブロックiの類似率
w_iは、ブロックiの類似率を評価する重み係数
γは補正項

なお、補正項γは、例えば、文書データから選出されなかったブロックの評価値などとする。また、重み係数は、ブロックが文書内に占める面積の比率（占有率）から求める。例えばブロックxの面積をSxとすると、ブロックxの重み係数w_xは式(2)で計算する。
w_x = Sx/ΣSi …(2)
ここで、ΣSiは全ブロックの面積の和

このような占有率を用いた重み付け処理により、入力画像データ内で大きな領域を占めるブロックの類似率nがより総合類似率Nに反映される。

次に、総合類似率Nと閾値Thを比較して(S554)、N＞Thの場合は当該文書データを候補として記録し(S555)、文書データのサムネイル画像などを表示する。続いて、記憶部に登録された全文書データについて総合類似度Nを計算したか否かを判定し(S556)、未了であれば処理をステップS551に戻す。

例えば、図12に示す画像が入力画像データであり、図29に示す画像が登録された文書データの画像例である。図29に示す文書データは、ブロックB1'〜B10'に分割され、写真属性のブロックを除くブロックのデータはベクトル化されている。

図30はブロックの類似率を算出する処理(S552)の詳細を示すフローチャートである。

ブロックの類似率を算出する場合、まず、入力画像データのブロック（以下「入力ブロック」と呼ぶ）とレイアウト的に一致する文書データのブロックを選出する(S561)。なお、入力画像データの複数のブロックに対して、文書データのブロックが重複して選出されてもよい。

次に、入力ブロックと選出ブロックの位置を比較し(S562)、サイズを比較し(S563)、属性を比較して(S563)、それらの誤差からレイアウト類似率を計算する。続いて、ブロックのオブジェクトを比較して、ブロックの類似率を計算する(S565)。その際、オブジェクトは同じ属性として比較する必要があるため、もし属性が異なる場合は、属性を一致させるために、一方のオブジェクトを再ベクトル化するなどの前処理を行う。

ブロックの位置、サイズおよび属性の類似率、並びに、ブロックのオブジェクトの類似率の合計をブロックの類似率とする。なお、図30の処理は、入力画像データのブロックすべてについて繰り返し実行する。

ブロックのオブジェクトを比較する場合、属性に応じて最適な比較手法を適用する。図31は属性に応じたブロックの比較方法を示すフローチャートである。

比較するブロックが写真属性の場合(S2811)は、入力ブロックと選出ブロックの写真ブロック特徴量の誤差から類似率を算出し(S2801)、算出した類似率をRAM 19の所定領域に記憶する(S2802)。写真ブロック特徴量は、色分布、色モーメントのような色に関する特徴量、共起行列、コントラスト、エントロピ、Gabor変換などで表現されるテクスチャ特徴量、フーリエ記述子などの形状特徴量などが挙げられる。これらの特徴量のうち最適な組み合わせを用いればよい。

比較するブロックがテキスト属性の場合(S2812)は、検索インデックスの生成時にOCR処理によって得た文字コードから、入力ブロックと選出ブロックの要約文を作成して概念検索を行い類似率を算出し(S2803)、算出した類似率をRAM 19の所定領域に記憶する(S2804)。続いて、入力ブロックから抽出した重要語が選出ブロックに含まれるか否かの全文検索を行い類似率を算出し(S2805)、算出した類似率をRAM 19の所定領域に記憶する(S2806)。

比較するブロックが表属性の場合(S2813)は、入力ブロックと選出ブロックの表ブロック特徴量の誤差から類似率を算出し(S2807)、算出した類似率をRAM 19の所定領域に記憶する(S2808)。表ブロック特徴量は、セル数、セルのサイズ、セルの構成、セルのテキストなどである。

比較するブロックが線属性や図形属性の線画ブロックの場合(S2814)は、入力ブロックと選出ブロックの線画ブロック特徴量の誤差から類似率を算出し(S2809)、算出した類似率をRAM 19の所定領域に記憶する(S2810)。線画ブロック特徴量は、線画を構成する線の位置、幅および長さ、並びに、図形の種類、位置、サイズおよび形状などである。

このように、文書画像から電子データを検索する際に画像解析情報を用いた高度な検索機能を行う文書管理システムを提供することができる。とくに、この文書管理システムは、文書画像を読み取って作成した電子データを登録して検索可能にするだけでなく、コンピュータ上で動作するアプリケーションに固有のデータであるアプリケーションデータを同様に登録して検索可能にすることができる。言い換えれば、文書画像から作成した電子データとアプリケーションデータを同等に扱うことができる。

以下、本発明にかかる実施例2の文書管理システムを説明する。なお、実施例2において、実施例1と略同様の構成については、同一符号を付して、その詳細説明を省略する。

実施例1では、文書から読み取った画像を基に、文書データを検索する処理を説明した。実施例2では、クライアントPC 102（またはマネージメントPC 101）から文書管理システムにPDLデータを渡すことで、文書データを検索する処理を説明する。

図32は文書データの検索機能を追加したプリンタドライバ324の検索設定ウィンドウの一例を示す図である。

ユーザは、プルダウンメニュー2801から検索する記憶部（図では「データベース3」のように表示）を選択し、さらに、必要であれば、ウィンドウ2802に表示されたフォルダを開いて検索するフォルダを指定する。なお、図32に示す例は、データベース3のフォルダ2851以下のフォルダに登録された文書データを検索する状態である。また、詳細設定ボタン2856により、例えばアプリケーションデータの二頁分の文書データを検索する、テキストを主体に検索する、といった詳細な検索設定を行うことができる。

検索設定ウィンドウによる検索設定が終了し、検索が指示されると、実施例1で説明したプリンタドライバ324を用いる登録処理と同様に、検索設定情報を埋め込んだPDLデータが文書管理システムへ送られる。文書管理システムは、検索ジョブ用のPDLデータを受信すると、指定の記憶部を検索し、検索結果（例えば候補リスト）をプリンタドライバ324へ返す。プリンタドライバ324は、受信した検索結果をモニタ10に表示する。ユーザは、モニタ10に表示された候補リストから文書データを特定することで、文書管理システムから当該文書データを取得する。

図33は文書管理システムの登録、検索処理を説明するフローチャートである。実施例1と同様に、MFP 100のデータ処理部15が実行するとして説明する。

図3に示すデータ処理部15は、通信制御部312によりクライアントPC 102からPDLデータを受信すると(S3101)、PDLデータをレンダリング部314によりレンダリングする(S3102)。その際、検索設定情報または登録設定情報を検出した場合(S3103)、レンダリングした画像データをインデックス生成部316へ送って検索インデックスを生成する(S3106)。また、検索設定情報や登録設定情報を検出しなかった場合、言い換えれば印刷ジョブのPDLデータの場合は、レンダリングした画像データを画像処理部317へ送って出力画像処理を施し(S3104)、プリンタ17により記録紙に印刷する(S3105)。

印刷ジョブではない場合、データ処理部15は、検索ジョブか登録ジョブかを判定し(S3107)、登録ジョブであればサムネイル画像を生成し(S3111)、登録処理を実行する(S3112)。また、検索ジョブであれば検索設定情報に基づき、指定の記憶部にアクセスして(S3108)、複合検索を行い(S3109)、検索結果（例えば候補リスト）をクライアントPC 102のプリンタドライバへ返す(S3110)。

このように、上述した実施例の文書管理システムは、文書管理システムを複雑化、肥大化することなく、登録時に、どのようなアプリケーションのデータにも、文書から読み取った画像データと同様の検索インデックスを付加することができる。従って、アプリケーションデータと、文書から読み取った画像データを区別することなく同一に扱い、登録し検索することが可能である。

［他の実施例］
なお、本発明は、複数の機器（例えばホストコンピュータ、インタフェイス機器、リーダ、プリンタなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、複写機、ファクシミリ装置など）に適用してもよい。

また、本発明の目的は、前述した実施例の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施例の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施例の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施例の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

複合機を使用して情報の電子化を行う文書管理システムの構成例を示すブロック図、マネージメントPCとMFPの構成例を示すブロック図、マネージメントPC（またはクライアントPC）およびMFPによる文書管理処理を説明する機能ブロック図、検索インデックスの構成例を示す図、 HTMLデータの表示例を示す図、アプリケーションデータを登録する際にブラウザが実行する処理を示すフローチャート、プリンタドライバを利用したアプリケーションデータの登録構成の一例を示す図、プリンタドライバを利用したアプリケーションデータの印刷または登録構成の他例を示す図、文書登録時にプリンタドライバが提供するユーザインタフェイスの一例を示す図、文書管理システムがPDLデータを解釈して文書を登録する処理を説明するフローチャート、インデックス生成部が実行する画像データから検索インデックスを作成する処理を示すフローチャート、 BS処理を説明する図、ブロックセレクションの結果の一例を示す図、ベクトル化処理の詳細を示すフローチャート、ベクトル化における角抽出処理を説明する図、ベクトル化において輪郭線をまとめる処理を説明する図、ベクトル化で生成したベクトルデータのグループ化処理を示すフローチャート、図形要素の検出処理を示すフローチャート、図形を認識する他の方法を説明する図、表属性のブロックの画像を二値化してアウトライン化したベクトル画像を示す図、セルの角を求めた結果を示す図、一頁分の画像データをBS処理し、ベクトル化した結果、中間データ形式のファイルとして得られるDAOFデータ構造を示す図、文書構造ツリーの生成処理の詳細を示すフローチャート、画像の一例を示す図、図24に示す画像から得られる文書構造ツリーを示す図、文書管理システムに登録する文書データの一例を示す図、文書管理システムの文書検索処理を説明するフローチャート、複合検索処理を説明するフローチャート、登録された文書データの画像例を示す図、ブロックの類似率を算出する処理の詳細を示すフローチャート、属性に応じたブロックの比較方法を示すフローチャート、文書データの検索機能を追加したプリンタドライバの検索設定ウィンドウの一例を示す図、文書管理システムの登録、検索処理を説明するフローチャートである。

Claims

データ管理システムへのアプリケーションデータの登録指示を受け付ける第一の受付手段と、
前記登録指示が示すアプリケーションデータが前記データ管理システムによって解釈されレンダリングが可能か否かを判定する判定手段と、
前記アプリケーションデータを前記データ管理システムがレンダリング可能なPDLデータに変換する変換手段と、
前記判定手段の判定結果が解釈およびレンダリング不能を示す場合、前記登録指示が示すアプリケーションデータに検索情報を付加するか否かを示す指示を受け付ける第二の受付手段と、
前記判定結果が解釈およびレンダリング可能を示す場合は前記登録指示が示すアプリケーションデータを前記データ管理システムに送信し、前記判定結果が解釈およびレンダリング不能を示し、前記第二の受付手段が受け付けた指示が検索情報の付加を示す場合は前記登録指示が示すアプリケーションデータを前記変換したPDLデータと前記アプリケーションデータを組み合わせたデータを前記データ管理システムに送信する送信手段とを有し、
前記送信されたPDLデータは、当該PDLデータに対応するアプリケーションデータを検索するための検索インデックスを作成するために前記データ管理システムに使用され、前記検索インデックスは、前記PDLデータをレンダリングしたビットマップ画像データのレイアウト特徴量から作成されることを特徴とする情報処理装置。
前記検索インデックスは、さらに、前記ビットマップ画像データのテキスト属性のブロックの特徴量、写真属性のブロックの特徴量、表属性のブロックの特徴量、線属性のブロックの特徴量から作成されることを特徴とする請求項1に記載された情報処理装置。
前記送信手段は、前記判定結果が解釈およびレンダリング不能を示し、前記第二の受付手段が受け付けた指示が検索情報を付加しないを示す場合は、前記登録指示が示すアプリケーションデータを前記データ管理システムに送信することを特徴とする請求項1または請求項2に記載された情報処理装置。
第一の受付手段が、データ管理システムへのアプリケーションデータの登録指示を受け付けるステップと、
判定手段が、前記登録指示が示すアプリケーションデータが前記データ管理システムによって解釈されレンダリングが可能か否かを判定するステップと、
変換手段が、前記アプリケーションデータを前記データ管理システムがレンダリング可能なPDLデータに変換するステップと、
第二の受付手段が、前記判定ステップの判定結果が解釈およびレンダリング不能を示す場合、前記登録指示が示すアプリケーションデータに検索情報を付加するか否かを示す指示を受け付けるステップと、
送信手段が、前記判定結果が解釈およびレンダリング可能を示す場合は前記登録指示が示すアプリケーションデータを前記データ管理システムに送信し、前記判定結果が解釈およびレンダリング不能を示し、前記第二の受付手段が受け付けた指示が検索情報の付加を示す場合は前記登録指示が示すアプリケーションデータを前記変換したPDLデータと前記アプリケーションデータを組み合わせたデータを前記データ管理システムに送信するステップとを有し、
前記送信されたPDLデータは、当該PDLデータに対応するアプリケーションデータを検索するための検索インデックスを作成するために前記データ管理システムに使用され、前記検索インデックスは、前記PDLデータをレンダリングしたビットマップ画像データのレイアウト特徴量から作成されることを特徴とする情報処理方法。
前記検索インデックスは、さらに、前記ビットマップ画像データのテキスト属性のブロックの特徴量、写真属性のブロックの特徴量、表属性のブロックの特徴量、線属性のブロックの特徴量の特徴量から作成されることを特徴とする請求項4に記載された情報処理方法。
前記送信手段は、前記判定結果が解釈およびレンダリング不能を示し、前記第二の受付手段が受け付けた指示が検索情報を付加しないを示す場合は、前記登録指示が示すアプリケーションデータを前記データ管理システムに送信することを特徴とする請求項4または請求項5に記載された情報処理方法。
情報処理装置を制御して、請求項4から請求項6の何れか一項に記載された情報処理を実現することを特徴とするコンピュータプログラム。