(57)【要約】【課題】  本発明は、全文検索を効率よく行うことを目的とする。【解決手段】  バインダとバインダから参照される元文書（共有文書）の関係を情報テーブルとして保持し、バインダ文書作成／更新時に情報テーブルを更新しておく。また全文検索用のテキストを元文書から抽出しておく。バインダ文書を対象とした全文検索実行時に、共有文書が該当した場合には、その共有文書を含むバインダ文書の検索処理を行わずに検索該当文書とする。全文テキストデータを重複して持つ必要が無くなるため、保存に必要となるデータサイズが小さくなると同時に全文テキスト抽出処理時間の短縮となる。【選択図】  図１
2008027215.tif 000002
【特許請求の範囲】
【請求項１】
複数の電子文書を管理し、全文検索機能を持つ電子文書管理システムにおいて、
電子文書管理システムが管理する文書ならびに各種属性情報ならびに管理情報へのアクセスを可能とするインターフェース手段と、
構造化言語により記述された文書に対し、その属性情報を呼び出しながら文書管理に伴う必要な処理を実行することも可能とする文書属性情報読み出し手段と、
複数の元文書を束ね１つのバインダ文書とすることを可能とするバインダ文書手段と、
前記バインダ文書手段に束ねられる元文書とバインダ文書との関係をテーブルとして持ち管理する文書管理テーブル手段と、
バインダ文書の作成時あるいはバインダ文書の更新時に前記文書管理テーブル手段を更新する文書管理テーブル更新手段と、
文書が編集、更新された場合に編集された元文書のみの全文テキストを抽出する限定的全文テキスト抽出手段とを備え、
全文検索実行時に検索該当した元文書から前記文書管理テーブル手段を利用して検索該当するバインダ文書を特定し、該当したバインダ文書の検索処理をそれ以上行わないことを特徴とする電子文書管理システム。
【請求項２】
前記文書管理テーブル手段は、電子文書管理システム内の一意のID番号で元文書とバインダ文書の関係を管理することを特徴とする請求項１の電子文書管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、全文検索機能を有する電子文書管理システムに関し、全文検索機能のために登録された文書からテキストデータを抽出する場合の処理手順に関するものである。
【背景技術】
【０００２】
従来、全文検索機能のために登録された文書からテキストデータを抽出する場合、テキストデータの抽出処理は、テキストデータを含む電子文書の場合はテキストデータ部分のみを抜き出し、画像データの場合には文字認識技術（OCR）処理を施してテキストデータを抽出するものであった。テキストの抽出処理は、登録されている文書毎に実行するものであり、例え同じ内容の文書であっても、文書の数だけテキストデータ抽出処理を行っていた。
【０００３】
また、複数の文書から１つの文書を形成するバインダ文書も利用されてきたが、バインダ文書は元文書とは別に元文書の実体データを組み込むもので、いわば元文書コピーを複数持った１つの文書であった。
【特許文献１】特開2003-316773号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところが、全文テキストの抽出処理は、元文書の全文テキスト抽出処理とは別に、別途バインダ文書の全文テキストも抽出していた。複数のバインダ文書で共通に使われる元文書の数も決して少なくないため、全文テキストの抽出処理に時間がかかり、しかも全文テキストデータサイズが増大していた。
【０００５】
また、複数のバインダ文書に組み込まれている元文書が編集され更新された場合にも、その文書を組み込んでいたバインダ文書を更新した上で、元文書とバインダ文書の全文テキスト抽出を行っていた。
【０００６】
更には、全文検索時にも、バインダ文書毎に、バインダ文書に組み込まれるそれぞれの元文書の全文テキストデータに対して検索処理を行うため、決して効率の良い検索処理とはいえなかった。
【課題を解決するための手段】
【０００７】
上述した課題を解決するために、本発明は、
電子文書管理システムが管理する文書ならびに各種属性情報ならびに管理情報へのアクセスを可能とするインターフェース手段と、
属性情報等を含む構造化言語により記述された文書に対し、その属性情報を呼び出しながら文書管理に伴う必要な処理を実行することも可能とする文書属性情報読み出し手段と、
複数の元文書を束ね１つのバインダ文書とすることを可能とするバインダ文書手段と、
前記バインダ文書手段に束ねられる元文書とバインダ文書との関係をテーブルとして持ち管理する文書管理テーブル手段と、
バインダ文書の作成時あるいはバインダ文書の更新時に前記文書管理テーブル手段を更新する文書管理テーブル更新手段と、
文書が編集、更新された場合に編集された元文書のみの全文テキストを抽出する限定的全文テキスト抽出手段とを備え、
全文検索実行時に検索該当した元文書から前記文書管理テーブル手段を利用して検索該当するバインダ文書を特定し、該当したバインダ文書の検索処理をそれ以上行わないことを特徴とする。
【発明の効果】
【０００８】
全文テキストデータを重複して持つ必要が無くなるため、データサイズの縮小となると同時に全文テキスト抽出処理時間の短縮となる。更に文書更新時の再全文テキスト抽出処理に要する時間を短縮することが可能である。また、全文検索処理に要する時間を短縮することが可能である。
【発明を実施するための最良の形態】
【０００９】
（実施例１）
以下に、本発明の実施例を図面に基づき説明する。
【００１０】
図1は本発明における文書管理システムのシステムブロックを示した図である。本実施例における文書管理システムはパーソナルコンピュータのOS上で動作するクライアント（1000）・サーバ（1100）型のアプリケーションであり、スキャナなどのデバイスや、OS上のファイルから文書を取り込み、文書を複数のユーザで管理することを目的としている。また、保存される全ての文書はXML形式に自動的に変換されて取り扱われる。さらにWEBブラウザを利用して、サーバにアクセスすることによってそれらのデータを取り扱うことも可能である。
【００１１】
＜文書入出力処理部＞
まず、文書入出力や操作を行う処理部について説明する。
【００１２】
1001はユーザインターフェース部である。ユーザはユーザインターフェース部を介して文書サーバに対して文書の登録や、文書サーバからの文書の獲得、あるいは文書の検索といった操作を行うことになる。また、本発明にかかわる固定キーワードに対するアクセス権の設定、アクセス権の設定された文書の獲得、表示といった操作もここで行われる。
【００１３】
ユーザインターフェース部から操作された情報は1002のコマンド制御部で解析され、適切な処理が行われることになる。また必要であればサーバとの通信を行うためのコマンドはここで作成される。
【００１４】
スキャナ等のデバイスはデバイス制御部1003によって制御が行われる。ここでは、デバイス側から文書データを吸い上げたり、デバイス側から送信されるデータを受け取ったりする処理がなされる。
【００１５】
ファイルサーバ等のOS上に保存された文書ファイルは、文書データをインポートする形態で、1004のファイル制御部において入力処理させることができるようになっている。また、文書管理サーバ上で管理するファイルをOS上にエクスポートする処理もここで行われる。
【００１６】
1005は外部モジュール通信部で、外部アプリケーションとの通信を行い、文書管理サーバ内の文書を外部アプリケーションに渡したり、外部アプリケーションから文書を受け取とったりといった処理を行う。例えば、MAPIに対応したメーラーに文書管理サーバで管理している文書を渡したりする処理はここで行われる。
【００１７】
＜クライアントシステム内部処理部＞
次に、クライアントシステム内に配置される各種処理部について説明する。
【００１８】
1006は文書管理制御部であり、クライアントの心臓部である。ここでは、入出力処理部より渡されたファイルやコマンドに応じて処理を行う。
【００１９】
1007はテンポラリデータを保存するための内部データ保存部である。画像処理を行う過程で作成されるデータや、サーバとの通信の過程で作成されるデータ等を一時的に保存する場所である。
【００２０】
1008は文書変換処理部である。本実施例では全てのデータはXML形式で保存するため、XML形式でないファイルは本処理部でXML形式へのデータ変換を行っている。
【００２１】
1009はOCRエンジンで、ファイルが画像データの場合、1008の画像変換処理部の指示により、OCR処理をすることによってテキスト情報を抽出しXML形式への変換を行う。
【００２２】
1010は通信制御部で、サーバ1100と通信するための制御を行う。本実施例の通信制御部は文書管理サーバの処理に特化した制御のみを行っており、TCP/IP等の通信そのものの制御はOSに用意されたものを使用している。
【００２３】
＜サーバシステム内部処理部＞
次に、サーバシステム内に配置される各種処理部について説明する。
【００２４】
1101は通信制御部で、クライアントの通信制御部1011と通信のための制御を行う。ただしサーバの通信制御部は多数のクライアントの通信制御部と同時に通信を行うことが可能になっている。
【００２５】
1102はWWW制御部で、WEBブラウザから本サーバへアクセスしてきた場合の処理を行う。基本的には通信制御部1101と同様の処理を行うが、通信プロトコルとしてHTTPが用いられる。
【００２６】
1103は文書管理処理部であり、クライアントや、WEBからの指示に応じたサーバ側での処理を制御している。
【００２７】
1104はテンポラリデータを保存するための内部データ保存部である。クライアントとの通信の過程で作成されるデータや、文書変換ルールに従って変換された文書等を一時的に保存する場所である。
【００２８】
1105は検索制御部で、クライアントから依頼された検索のための処理を行ったり、登録された文書の検索用インデックス作成のための処理を行ったりしている。本発明にかかわる、文書内のキーワードの検索は本制御部で行っている。
【００２９】
＜データベース処理部＞
次に、データベース処理部について説明する。
【００３０】
1106はデータベース制御部で、データベースに保存するデータを作成し、ボリュームデータベース、属性データベース、全文検索用データベースに対応する文書を保存する処理を行う。また、クライアントからの要求に応じてそれぞれのデータベースからデータを取り出し、クライアントに渡す文書を作成する処理を行う。
【００３１】
1107はボリュームデータベースで、文書の実態が保存されるデータベースである。ボリュームデータベースは概念的なものであって、実態がOSのファイルシステムであっても問題はない。
【００３２】
1108は属性データベースで、文書の名前や作成日付、コメントなどの属性に関する情報が保存されるデータベースである。また、1108には文書管理システムを使用するユーザの情報等の管理情報データや、キーワードに対するアクセスコントロールテーブル、アクセス権に応じた文書変換ルールも保存している。
【００３３】
1109は全文検索用データベースで、登録された文書からテキストデータを抽出し、インデックス情報にしたデータが登録される。クライアントで全文検索が行われると、全文検索データベース内を検索する。
【００３４】
図2は本実施例の文書管理システムの基本動作である、文書登録処理の、サーバおよびクライアントにおけるフローを示す図である。
【００３５】
＜クライアント文書登録処理＞
まずクライアント側における文書登録の処理について説明する。
【００３６】
S2001でアプリケーションにファイルを取り込む処理を行う。この処理ではデバイス制御部（1003）、ファイル制御部（1004）、外部モジュール制御部（1005）のいずれかを使用して、ＯＳ上に存在するファイルやスキャナからの画像、外部アプリケーションからの文書を、文書管理アプリケーションに取り込む。
【００３７】
S2002で、文書変換処理が行われる。この処理は1008の文書変換処理部で行われ、文書データに対応したサムネイル作成や、必要に応じて文書管理システムでの文書保存形式に文書を変換するといった処理を行う。この際テンポラリフォルダ1007に一時的にファイルがためられることがある。本実施例では保存される文書の形式はすべてXML形式に変換されるため、文書がイメージ文書の場合は1009のOCRエンジンを使用してテキストデータを抽出する。
【００３８】
S2003で、サムネイルおよび文書データをサーバに送信するための処理が行われる。本実施例では通信のプロトコルとしてTCP/IPが用いられ、TCP/IPに関する基本的な処理はOSが処理するものとする。
【００３９】
以上がクライアントにおける文書登録処理である。
【００４０】
＜サーバ文書登録処理＞
次にサーバ側における文書登録の処理について説明する。
【００４１】
S2101で、クライアントから送信されたデータを受信する処理が行われる。ここもクライアントと同様にTCP/IPに関する基本的な処理はOSが処理するものとする。
【００４２】
S2102で、受信した文書の登録処理のための準備が行われる。この処理は1103の文書処理部で行われる。
【００４３】
S2103で、受け取った文書から、検索に用いるインデックスデータを抽出する。
【００４４】
S2104で、クライアントから受信した文書データを、1107のボリュームデータベースに保存する処理を行う。ボリュームデータベースに保存されるデータは、受信した文書データそのものおよび、サムネイルデータである。
【００４５】
S2105で、文書データから抽出した検索用のインデックスデータを、1109の全文検索用データベースに登録する処理を行う。
【００４６】
S2106で、文書の属性データおよび、ボリュームデータベースに登録した文書データのID、全文検索用データベースに登録した検索用インデックスデータのＩＤを属性データベース1108に登録する。これによって、属性データベース、ボリュームデータベース、検索用データベースに登録されたデータの対応付けを行っている。
【００４７】
以上がサーバにおける文書登録処理である。
【００４８】
続いて複数の元文書から構成されるバインダ文書の構成について図３を用いて説明する。
【００４９】
S3001とS3002は元文書であり、それぞれ単独の文書として電子文書管理システム内に保管されているものである。これら２つの元文書を１つに束ねてバインダ文書S3003が作成される。元文書S3001とS3002はバインダ文書S3003の作成と同時に削除することも可能だが、そのまま残すことも可能である。
【００５０】
次に、１つの元文書が複数のバインダ文書に組み込まれる場合、あるいは複数の元文書が1つのバインダ文書に組み込まれる場合の構成と、全文テキストデータの抽出について図４を用いて説明する。
【００５１】
S4001、S4002、S4003は元文書であり、S4004、S4005、S4006はバインダ文書である。S4001の元文書は、S4004、S4005の２つのバインダ文書に組み込まれ共有されていることになる。また、S4002、S4003の元文書は、１つのバインダ文書S4006に組み込まれていることになる。この時、全文テキストデータの抽出はS4004、S4005、S4006の各バインダ文書毎に実施される。つまり、元文書S4001はS4004とS4005の２つのバインダ文書の一部として重複して全文テキストデータの抽出が行われることになる。更に、例えば元文書S4001がイメージデータである場合、OCR処理を施してテキストデータの抽出を行うが、場合によっては誤認識が発生することがある。その場合は、ユーザが正しいテキストを入力し修正する必要があるのだが、その作業をS4004のバインダ文書と、S4005のバインダ文書の両方に対して修正作業を行う必要がある。
【００５２】
続いてバインダ文書の属性情報について図５を用いて説明する。S5001、S5002は図３を用いた説明と同様に元文書であり、これら元文書からバインダ文書S5003が作成される。バインダ文書S5003は構造化文書であり、その元文書に関する属性情報はS5004のように記述されている。前記属性情報S5004はバインダ文書作成時に、システム内で自動的に作成されるものであり、その時同時に、バインダ文書のID番号と、そのバインダ文書に束ねられた元文書のID番号がシステム内の管理テーブルに追加登録される。管理テーブルに関する説明は後述する。S5005は元文書S5001に相当する部分であり、CoverPageタグの中で、S5001が保管されている電子文書管理システム内でのキャビネット名とフォルダパス、そして文書名が記されている。同様にS5006は元文書S5002に相当する部分であり、Bodyタグの中でやはりS5002が保管されている電子文書管理システム内でのキャビネット名とフォルダパス、そして文書名が記されている。S5004はバインダ文書S5003の属性情報であり、実際の文書本文はこの属性情報とは別に文書データそのものとして別途管理されている。また、前述した通り、元文書S5001とS5002はバインダ文書S5003の作成と同時に削除することも可能だが、そのまま残すことも可能である。元文書をバインダ文書S5003の作成と同時に削除する場合には、ユーザの目からは元文書が単独の文書としてもはや存在しないように見えるが、文書データとしてはそのまま残され、バインダ文書S5003の一部として内部的に参照されることになる。この場合、S5005、S5006の各属性情報部分には、ユーザが把握することが出来るフォルダパスや文書名ではなく、システムが内部的に使用する保管場所IDや文書IDが記述されることになる。一方元文書を残す場合には、元文書S5001、S5002の文書データそのものとは別に、その２つの元文書を束ねた１つの文書データとしてバインダ文書S5003の文書データは存在する。
【００５３】
続いて元文書と、その元文書を束ねたバインダ文書との関係を記録する管理テーブルについて図６を用いて説明する。
【００５４】
S6001は元文書IDが記録される列であり、管理テーブルはバインダ文書に束ねられている１つの元文書に対して1行追加されていく。S6002はバインダ文書IDが記録される列であり、元文書を束ねるバインダ文書が増えるに従って新しいバインダ文書IDが追加されていく。バインダ文書IDと元文書IDはシステム内で固有な識別番号であり、このIDを用いて文書を特定することが可能である。図はS6003、S6004、S6005の3つの元文書がバインダ文書に束ねられている場合の例であり、例えばS6003の元文書のIDは100であり、3つのバインダ文書にて束ねてられていることが分かる。それぞれのバインダ文書のIDは5、10、30であることが分かる。同様にS6004、S6005の元文書が束ねられているバインダ文書のIDも分かる。例えばIDが10のバインダ文書は、元文書のIDが100の文書と、200の2つの元文書を束ねていることが分かる。そして、バインダ文書に束ねられていない元文書、つまり単独で存在する文書はS6006のようにバインダ文書IDを持たない。
【００５５】
続いて本発明に関わる全文テキストの抽出方法について、前述の図４と図６を用いて説明する。
【００５６】
元文書S4001が複数のバインダ文書に束ねられている場合には、S4001の全文テキストの抽出を一度のみとする。例えば図６を用いて説明すると、例えば元文書IDが200の元文書は、バインダ文書IDが5と10の2つのバインダ文書に束ねられているが、全ての元文書の全文テキストの抽出を行えば、バインダ文書の全文テキスト抽出処理を別途行う必要がない。つまり、ユーザがバインダ文書IDが10のバインダ文書の中の元文書IDが200の元文書を編集し変更した場合、全文テキストの抽出を再度実行する必要があるが、その場合でも変更された元文書IDが200の元文書に対して処理を実施するだけで良く、元文書IDが200の元文書を含むバインダ文書IDが5と10のバインダ文書の全文テキスト抽出を行う必要がない。
【００５７】
全文検索を実行する場合でも、検索対象となるキーワードについて例えば元文書IDが200の元文書が該当した場合、図６の管理テーブルから、即座にバインダ文書IDが５と１０のバインダ文書が該当すると判定することが可能となる。
【図面の簡単な説明】
【００５８】
【図１】本発明における文書管理システムのシステムブロック図
【図２】文書管理システムの基本動作フロー
【図３】複数の元文書から構成されるバインダ文書の構成図
【図４】元文書とバインダ文書の関係図
【図５】バインダ文書の属性情報
【図６】元文書と、その元文書を束ねたバインダ文書との関係を記録する管理テーブル
【図１】
2008027215.tif 000003
【図２】
2008027215.tif 000004
【図３】
2008027215.tif 000005
【図４】
2008027215.tif 000006
【図５】
2008027215.tif 000007
【図６】
2008027215.tif 000008