JPH08147446A

JPH08147446A - 電子ファイリング装置

Info

Publication number: JPH08147446A
Application number: JP6285260A
Authority: JP
Inventors: Yoshikazu Yokomizo; 良和横溝; Susumu Sugiura; 杉浦　　進
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 1994-11-18
Filing date: 1994-11-18
Publication date: 1996-06-07
Anticipated expiration: 2020-08-17
Also published as: JP3683925B2

Abstract

(57)【要約】【目的】電子ファイリング装置において、異なるアプ
リケーションで扱われた情報を統合してファイリングで
きるようにすること。【構成】アプリケーションからの情報を受けるプリン
タードライバー（６）と、ファイリングに適したフォー
マットに変換する手段（１０−１）と、文字部分を認識
する手段（１０−２）と、キーワードを抽出する手段
（１０−３）と、データベースに登録する手段（１０−
４）とを備える。

Description

【発明の詳細な説明】

【０００１】

【産業上の利用分野】本発明は、文書を電子的な手段に
よりファイリング整理する電子ファイリング装置に関す
る。

【０００２】本発明は、紙の原稿をスキャンした画像
と、ＤＴＰ文書とを統合化し、共通に扱える電子ファイ
リング装置に関するものである。

【０００３】

【従来の技術】従来の電子ファイリング装置は、大型で
高価な専用機であった。また、操作方法も専用のものな
ので、専門的に教育されたオペレーターが必要であるな
ど、使いにくい面があった。また、従来の電子ファイリ
ング装置はパーソナルコンピュータとは独立した装置に
なっており、ＤＴＰ文書と共通に管理することはできな
かった。

【０００４】

【発明が解決しようとしている課題】小型で安価な電子
ファイリング装置を実現する為には、市販のパーソナル
コンピュータ（以下パソコン）をベースにしたファイリ
ング技術を実現する事が考えられる。電子ファイリング
装置に必要な機能要素は、スキャナー、ＯＣＲ、キーワ
ード検索機能、（光磁気）ディスク装置等であり、
「紙」に印刷された文書をスキャナーで読んでＯＣＲで
文字情報をコード化し、キーワードを自動的に拾い出し
てディスク装置に一緒に保存していた。専用機であれ
ば、これだけの機能で十分であるが、パソコンをベース
に電子ファイリングを行う際には、対象とする文書は
「紙」に印刷された文書だけではなく、キーボードから
入力して作成されたＤＴＰ文書も統一的に扱う必要性が
出てくる。ところが、ＤＴＰ文書というのは、作成した
アプリケーションによってファイルフォーマットが全く
異なり、それらをファイルの形で保存すると以下の様な
問題が生じる。

【０００５】（１）ネットワーク上にあるサーバーに保
存したＤＴＰ文書を複数のパソコンからアクセスする場
合、全てのパソコンに作成時に用いたアプリケーション
と同じアプリケーションが存在するという保証は無い。
バージョンが違うだけでも問題である。

【０００６】（２）ネットワーク上にアーキテクチャー
の異なるパソコンが存在する場合、たとえ同一アプリケ
ーションの作成したファイルでもファイル形式が異なる
のが普通なので、相互にアクセスできない。

【０００７】（３）市販のアプリケーションには、キー
ワードを抽出する機能など無いのが普通であるから、電
子ファイリング装置としては使用できない。

【０００８】（４）専用の検索ソフトを用意し、市販の
アプリケーションからは検索ソフトを介して間接的にフ
ァイリングをする場合、ファイルを媒介するか、カット
＆ペースト機能を媒介して文書情報を伝送する訳だが、
操作手順が繁雑で時間がかかり、自動化も困難である。

【０００９】（５）従来の電子ファイリング装置はパー
ソナルコンピュータとは独立した装置になっており、Ｄ
ＴＰ文書と共通に管理する事はできなかった。

【００１０】

【課題を解決する為の手段】上記課題を解決する為に、
本発明は、アプリケーションソフトウエアからプリンタ
ドライバーに伝達される情報をデータベースに蓄積する
手段を有する電子ファイリング装置を提供する。

【００１１】上記課題を解決する為に、本発明は好まし
くは前記電子ファイリング装置において、印刷用の描画
コマンドを文書蓄積に達したフォーマットに変換する手
段を有する。

【００１２】上記課題を解決する為に、本発明は好まし
くは前記電子ファイリング装置において、キーワード検
索用の情報を抽出して保存する手段を有することを特徴
とする請求項１に記載の電子ファイリング装置。

【００１３】上記課題を解決する為に、本発明は好まし
くは前記電子ファイリング装置において、描画コマンド
の中にビットマップ画像情報が含まれる場合には、該画
像データを蓄積する際に圧縮する手段を有する。

【００１４】上記課題を解決する為に、本発明はアプリ
ケーションソフトウエアからプリンタドライバーに伝達
される描画情報を、特徴に応じて分割する手段と、上記
課題を解決する為に、本発明は好ましくは該分割された
情報毎に最適な圧縮処理を施す手段と、上記課題を解決
する為に、本発明は好ましくは前記圧縮された情報をデ
ータベースに蓄積する電子ファイリング装置を提供す
る。

【００１５】上記課題を解決する為に、本発明は好まし
くは前記分割は、文字部分か、ベクトル描画部分か、ビ
ットマップ画像部分かによって行う。

【００１６】上記課題を解決する為に、本発明は好まし
くは前記電子ファイリング装置において、プリンタドラ
イバーに伝達される描画情報の内、ビットマップ画像部
分を認識してコード化する手段と、前記認識して得たコ
ードの内、文字コードは前記文字部分と同様に扱う。

【００１７】上記課題を解決する為に、本発明はアプリ
ケーションソフトウエアからプリンタドライバーに伝達
される描画情報からタイトル部分を抽出する手段と、前
記抽出されたタイトル情報を検索のキー情報として登録
する電子ファイリング装置を提供する。

【００１８】上記課題を解決する為に、本発明は好まし
くは前記タイトル情報は、タイトルの有無とする。

【００１９】上記課題を解決する為に、本発明は好まし
くは前記タイトル情報は、タイトルを認識して得たコー
ド情報とする。

【００２０】上記課題を解決する為に、本発明は好まし
くは前記描画情報から特徴に応じて分割する手段を有す
る。

【００２１】上記課題を解決する為に、本発明は好まし
くは前記分割は、文字部分か、ベクトル描画部分か、ビ
ットマップ画像部分かによって行う。

【００２２】上記課題を解決する為に、本発明はアプリ
ケーションソフトウエアからプリンタドライバーに伝達
される描画情報から表部分を抽出する手段と、前記抽出
された表情報を検索のキー情報として登録する電子ファ
イリング装置を提供する。

【００２３】上記課題を解決する為に、本発明は好まし
くは前記表情報は、表の有無とする。

【００２４】上記課題を解決する為に、本発明は好まし
くは前記表情報は、表を構成する段数とする。

【００２５】上記課題を解決する為に、本発明は好まし
くは前記描画情報から特徴に応じて分割する手段を有す
る。

【００２６】上記課題を解決する為に、本発明は好まし
くは前記分割は、文字部分か、ベクトル描画部分か、ビ
ットマップ画像部分かによって行う。

【００２７】上記課題を解決する為に、本発明はアプリ
ケーションソフトウエアからプリンタドライバーに伝達
される描画情報からグラフ部分を抽出する手段と、前記
抽出されたグラフ情報を検索のキー情報として登録する
電子ファイリング装置を提供する。

【００２８】上記課題を解決する為に、本発明は好まし
くは前記グラフ情報は、グラフの有無とする。

【００２９】上記課題を解決する為に、本発明は好まし
くは前記描画情報から特徴に応じて分割する手段を有す
る。

【００３０】上記課題を解決する為に、本発明は好まし
くは前記分割は、文字部分か、ベクトル描画部分か、ビ
ットマップ画像部分かによって行う。

【００３１】上記課題を解決する為に、本発明はアプリ
ケーションソフトウエアからプリンタドライバーに伝達
される描画情報からビットマップ画像部分を抽出する手
段と、上記課題を解決する為に、本発明は好ましくは前
記抽出されたビットマップ画像情報を検索のキー情報と
して登録する電子ファイリング装置を提供する。

【００３２】上記課題を解決する為に、本発明は好まし
くは前記ビットマップ画像情報は、ビットマップ画像の
有無とする。

【００３３】上記課題を解決する為に、本発明は好まし
くは前記ビットマップ画像情報は、ビットマップ画像の
個数とする。

【００３４】上記課題を解決する為に、本発明は好まし
くは前記描画情報から特徴に応じて分割する手段を有す
る。

【００３５】上記課題を解決する為に、本発明は好まし
くは前記分割は、文字部分か、ベクトル描画部分か、ビ
ットマップ画像部分かによって行う。

【００３６】上記課題を解決する為に、本発明は原稿を
光学的に読み取る手段と、前記読み取った原稿の画像を
圧縮してデータベースに保存する手段と、前記読み取っ
た画像を文字部分と画像部分とに分割する手段と、前記
分割された文字部分を認識してコード化し、保存する手
段と、前記保存した文字コードと指定されたキーワード
が一致するか否か判定する手段と、前記判定により一致
すると判定される場合に、一致する画像を伸長して表示
する手段とを有する電子ファイリング装置を提供する。

【００３７】上記課題を解決する為に、本発明は好まし
くは前記原稿を光学的に読み取る手段に替えて、公衆回
線により画像を受信する手段を有する。

【００３８】上記課題を解決する為に、本発明は好まし
くはアプリケーションソフトウエアからプリンタドライ
バーに伝達された情報を蓄積に適したフォーマットに変
換する手段と、前記変換された情報を蓄積する手段とを
有する電子ファイリンク装置。

【００３９】上記課題を解決する為に、本発明は好まし
くは前記変換の水準を複数段階設け、アプリケーション
ソフトウエアの機能の段階によって変換の水準を選択す
る。

【００４０】上記課題を解決する為に、本発明は好まし
くは前記プリンタドライバーの情報の流れを双方向とす
る。

【００４１】上記課題を解決する為に、本発明は好まし
くは前記アプリケーションソフトウエアとのインターフ
ェイスを汎用ドライバーの形式とする。

【００４２】上記課題を解決する為に、本発明は好まし
くは前記情報の蓄積は、ネットワーク上のデータベース
とする。

【００４３】上記課題を解決する為に、本発明は好まし
くは前記データベースに替えて、複数台数のクライアン
トコンピュータ同士で情報を送受信する手段を有する。

【００４４】

【目的】本発明は、従来ハード／ソフト共にスタンドア
ロンの機械として提供されていた文書蓄積／検索装置
を、市販されているコンピュータをベースにし、市販さ
れている幾多のアプリケーションをフロントエンドとす
る文書蓄積／検索装置を提供する事を目的とする。

【００４５】本発明は、デスクトップのパソコンを介し
て簡単に文書の蓄積／検索ができる様にすることで、小
型で安価な電子ファイリング方法及びその装置を提供す
ることを目的とする。

【００４６】本発明は、従来行われていたキーワード検
索に加えて、ＤＴＰ文書やスキャンされた画像の中に含
まれる「表」や「円グラフ」「タイトル」「ビットマッ
プ画像」等の有無や個数等によっても検索時間の短縮あ
るいは検索精度を上げる事を目的とする。

【００４７】

【実施例】以下、図に基づき本発明の実施例を詳細に説
明する。

【００４８】図１は本実施例の電子ファイリング装置の
ブロックダイヤグラムである。１００はホストコンピュ
ータであり、枠で囲まれた機能を実行する。ここでは１
つの枠で表したが、この枠内に表した各機能は１つ或い
は複数のＣＰＵで実行しても良いし、１つ或いは複数の
ホストコンピュータで実行しても良い。同図に於て、
１、２、３は市販のアプリケーションであり、例えばス
キャナーアプリ１、ワープロアプリ２、表計算アプリ３
等を示している。これらのアプリケーション間でデータ
のやり取りをするには、ファイル４、５を介して行うの
は非常に困難である。なぜなら、スキャナーアプリ、ワ
ープロアプリ、表計算アプリ等が生成するファイルのフ
ォーマットはそれぞれのベンダーが独自に定めたものな
ので、互換性は全く無いからである。アプリケーション
に依存しないファイルフォーマットとして「ＴＩＦＦ」
「ＰＩＣＴ」「ＥＰＳ」「ＧＩＦ」「ＴＧＡ」等の業界
標準フォーマットは全てのアプリケーションに対して万
能ではない。

【００４９】コンピューターがＭａｃｉｎｔｏｓｈ（登
録商標）やＷｉｎｄｏｗｓ（登録商標）の場合には、
「カット＆ペースト」の機能を用いてやり取りする仕組
みが用意されているが、フォーマットは「ＰＩＣＴ」か
「ＧＩＦ」に限定されてしまう。よって、コンピュータ
が限定された場合であってもカット＆ペーストでのデー
タのやり取りはできない。

【００５０】一方、これらのアプリケーションが印刷す
る際にプリンタードライバーに引き渡すデータは、Ｍａ
ｃｉｎｔｏｓｈの場合はＱｕｉｃｋＤｒａｗ（登録商
標）、Ｗｉｎｄｏｗｓの場合はＧＤＩ（登録商標）に統
一されている。図１はＭａｃｉｎｔｏｓｈのアプリケー
ション１、２、３がプリンタードライバー６に印刷デー
タを渡している時の様子を示している。この時、Ｐｏｓ
ｔｓｃｒｉｐｔアプリケーションの一部に例外はある
が、ほとんどのアプリケーションがＱｕｉｃｋＤｒａｗ
の描画コマンド７、８、９をプリンタードライバー６に
渡している。本発明はこの特徴に着目し、プリンタード
ライバー６の中に文書変換／蓄積機能を備え、Ｑｕｉｃ
ｋＤｒａｗを処理対象とした。

【００５１】１０−１はＱｕｉｃｋＤｒａｗ−共通文書
変換装置である。ＱｕｉｃｋＤｒａｗの描画コマンドは
コンピュータに依存した描画コマンドであり、Ｍａｃｉ
ｎｔｏｓｈのみに限定すれば殆んどのアプリケーション
に共通の言語であるが、ＷｉｎｄｏｗｓではＧＤＩコマ
ンドが用いられており、互換性は無い。従ってこのＱｕ
ｉｃｋＤｒａｗ−共通文書変換装置１０−１によりデー
タベース１３にセーブしやすい一般的なドキュメントの
形に変換を行う。

【００５２】共通文書１２、１４はドローであってもペ
イントであっても、また混在していてもどの場合でも各
々処理できる。ドローとは描画の線の太さ、色、座標点
を指定する数値で表現する描画方法で、それを受け取っ
た側も画像におとすにはその数値をデコードする機能が
なければならない。一方、ペイントとはビットマップ画
像の事であり、データのサイズは大きくなるが、受け取
った側のデコード機能は不用である。

【００５３】１０−２はＯＣＲ装置でビットマップ画像
を認識してコード化する場合に用いるが、すでにコード
状態であるドロー系の情報の場合にはこのＯＣＲ装置１
０−２はバイパスする。

【００５４】１０−３はキーワード抽出装置で、Ｑｕｉ
ｃｋＤｒａｗ−共通文書変換装置１０−１により変換し
て得た共通文書の中から、検索に使えそうな単語を拾い
だし、その共通文書とセットでアクセスする為のもので
ある。

【００５５】１０−４はデータベースＡＰＩで、ローカ
ルまたはネットワークを介して接続されているリモート
のデータベース１３に接続する為のものである。

【００５６】プリンタードライバーＡＰＩ６は、システ
ムが提供するものに合わせる。このＡＰＩはプリンタが
印刷だけを想定している通常の場合はデータの流れは一
方通行であり、データベース１３から引き出した文書を
ＱｕｉｃｋＤｒａｗコマンドに逆変換してアプリケーシ
ョン１、２、３側に送る事は出来ない。しかしながら、
本実施例におけるプリンタードライバーＡＰＩは汎用ド
ライバーの形式とする。プリンタードライバーを介して
双方向の文書交換をする為には、ＯＳやアプリケーショ
ンの変更が必要であるが、専用の文書検索ソフトウエア
を用いた場合には双方向の文書交換が実現できる。

【００５７】共通文書１２はＬＡＮ１１を介してデータ
ベース１３に送られる。

【００５８】この図１における装置を文書のファイリン
グシステムとして用いるには、通常スキャナー１５で原
稿を読み取る。その制御はスキャナーアプリ１が行う
が、そのアプリがスキャナー１５により読み取った原稿
を印刷する場合にはやはりＱｕｉｃｋＤｒａｗ７に変換
してプリンタードライバー６に伝達する。ＱｕｉｃｋＤ
ｒａｗとは言っても、スキャン画像の場合には中身はビ
ットマップであるから、１０−１でビットマップに戻
し、必要に応じて圧縮回路（図示せず）によって画像圧
縮を行う。

【００５９】プリンタードライバー６は、パソコンのＯ
Ｓがサポートする全てのＱｕｉｃｋＤｒａｗコマンドを
サポートしており、あらゆるアプリケーションからの印
刷要求に応える。一方、プリンタードライバー６が一方
通行であった時はアプリケーション１、２、３は自分の
都合により一部のＱｕｉｃｋＤｒａｗコマンドしかサポ
ートしなくても何等問題は無かった。ところが、プリン
タードライバー６を双方向性にし、ＱｕｉｃｋＤｒａｗ
−共通文書変換装置１０−１が出力するＱｕｉｃｋＤｒ
ａｗコマンドを各アプリケーションで表示可能にする為
には、やはり各アプリケーションが全てのＱｕｉｃｋＤ
ｒａｗコマンドをサポートする必要がある。なぜなら、
その文書は自分より高機能なアプリケーションが作成し
たものかも知れないからである。その為プリンタードラ
イバー６は、アプリケーションに伝達しようとしたドロ
ー系のコマンドがアプリケーションに理解できないと拒
絶された場合には、それをペイント系のデータに変換し
て再度伝達をしなおす。

【００６０】誤り制御機能の無いアプリケーションの為
に、ＱｕｉｃｋＤｒａｗ運用に水準を設け、例えばＪＩ
Ｓの漢字コードの毎く第一、第二、第三水準に分類し、
伝達しても理解されない事が分かっている場合には、あ
らかじめ低水準のＱｕｉｃｋＤｒａｗコマンドに変換し
て伝達しても良い。

【００６１】図２は、検索アプリの位置づけを説明する
図面である。同図に於て、図１と共通の機能要素には同
一の番号を付与してある。図１では市販のアプリケーシ
ョン１、２、３からデータベース１３への文書蓄積を説
明したが、市販のアプリケーションはやはり文書蓄積／
検索用に設計されている訳ではないから、スピーディー
な検索には専用の検索アプリ１６が必要となる。このア
プリはＱｕｉｃｋＤｒａｗ−共通文書変換装置１０−１
と直接接続する。データフォーマットはＱｕｉｃｋＤｒ
ａｗではなく共通文書フォーマット１７である。１０−
１は汎用ドライバーとして構築されている。

【００６２】図３は、ＯＣＲアクセラレーターを使う場
合の実施例である。１０−５がそのアクセラレータであ
る。アクセラレータは通常ハードウエアで実現する。Ｏ
ＣＲには変換時間がかかるので、専用のハードウエアに
処理を代行させる事により高速化が図れる。

【００６３】また、ＱｕｉｃｋＤｒａｗ−共通文書変換
装置１０−１はプリンタードライバー／汎用ドライバー
としてソフトウエアで実現する。一方、ＯＣＲ１０−
２、キーワード検索装置１０−３、データベースＡＰＩ
１０−４はバックグラウンドで走る汎用ドライバーとし
てソフトまたはハードで実現し、これらが処理をしてい
る時でも、オペレーターの他の装置を中断しない。

【００６４】図４はその関係を詳細に説明した図であ
る。１０−６はプリントキュー、１０−７はバッファー
メモリーである。ＱｕｉｃｋＤｒａｗ−共通文書変換装
置１０−１はもっぱらプリンタードライバー６と一体で
動作し、プリントキュー１０−６への出力はフォアグラ
ンドで行う。一方、ＯＣＲ１０−２以下はプリントキュ
ー１０−６から文書データーをバックグランドで受取
り、アプリケーション１、２、３、１６と同時並行的に
処理する。バッファーメモリー１０−７は、プリントキ
ュー１０−６が一時的に文書データーを蓄えておく為の
ものである。

【００６５】図５は、対話式会議システムへの応用例で
ある。同図に於て、左半分は図１のパソコンと同じ物で
あり、説明上必要な番号には「ａ」の枝番を付けてあ
る。一方、右半分は第２のパソコンで、「ｂ」の枝番を
付けたものは、「ａ」の枝番の付いた同じ番号の要素と
同じ物である。第１のパソコン（左）にはスキャナー１
５をそのまま残して説明してあるが、第２のパソコン
（右）にはスキャナーが無い場合の状態を説明してい
る。この場合、ＯＣＲ、キーワード検索、データーベー
スＡＰＩ機能は不用なので斜線で示した様に機能を止め
て使う。ネットワーク上を流れるデーターが共通文書で
ある限りは、アプリケーションとのインターフェースは
共通文書であっても他のフォーマット、即ち、Ｑｕｉｃ
ｋＤｒａｗあっても構わない。スキャナー１５からのデ
ータはプリンタードライバー６が共通文書に変換するの
で、何等問題無く、相互通信が可能である。

【００６６】本実施例においてはプリンタードライバー
の、専らファイリングの為に用いられている部分のみ説
明するので、ここからは「ファイリングドライバー」と
呼ぶ事にする。ファイリングドライバーの機能は以下の
通りである。

【００６７】（１）市販のアプリケーションからのファ
イリングを可能にする。

【００６８】（２）形式はプリンタドライバーの形式で
作成する。市販のアプリケーションから一般のプリンタ
ーに印刷する時と全く同じ操作により、ファイリングを
実現する。すなわち、アプリケーションから発行される
ＧＤＩ描画コマンドを所定のファイル形式に変換してハ
ードディスクにファイルを保存する。ファイリングに特
有のダイアログはファイリングドライバーが表示器（図
示せず）に表示する。

【００６９】（３）ネットワーク対応は、データベース
自身がネットワーク対応しており、ファイリングドライ
バーとしては、特にネットワークを意識しなくてもネッ
トワーク上のファイルサーバーにアクセスできる。

【００７０】（４）ファイル形式例えばマイクロソフト社のＷｉｎｄｏｗｓのＧＤＩの描
画コマンドは、最終的に以下の情報を含むファイル形式
でデータベースに保存される。

【００７１】ｉ）ビットマップ画像ｉｉ）文字情報ｉｉｉ）レイアウト情報ｉｖ）キーワード情報ビットマップ画像はファイリングの基本となる情報で、
「印刷ダイアログ」で選択した用紙サイズと同じサイズ
のビットマップ画像を、以下の圧縮方式のいずれかを用
いて圧縮する。

【００７２】ｉ）白黒２値画像ＪＢＩＧｉｉ）多値画像ＪＰＥＧ文字情報に関しては、本来のファイリングではスキャナ
ーで読んだビットマップ画像にＯＣＲを掛けて文字情報
を抽出する。ファイリングドライバーの中でもこの方法
を踏襲するが、ＧＤＩコードでドライバーに渡されるの
で、ＧＤＩコマンドから直接文字情報を抽出する。すな
わち、文字情報については、以下の２種類がある。

【００７３】ｉ）ＯＣＲによって得られる文字情報ｉｉ）ＧＤＩコマンドを解析して得られる文字情報レイアウト情報については、上記ＯＣＲの前処理プログ
ラムであるブロックセレクション（ＢＳ）情報から抽出
する。すなわち、レイアウト情報については以下の２種
類がある。

【００７４】ｉ）ブロックセレクションで得られるレイ
アウト情報ｉｉ）ＧＤＩコマンドを解析して得られるレイアウト情
報キーワード情報については、キーワード生成ルーチンを
用いて文字情報の中から抽出する。

【００７５】レイアウト情報抽出の方法は以下の通りで
ある。

【００７６】ＧＤＩコードを解析して、レイアウト情報
を抽出する。レイアウト情報はページ情報とブロック情
報とから成り、以下の手順でデーターの抽出を行う。

【００７７】ｉ）ＧＤＩコード抽出（データ入力）ｉｉ）ブロック分解ｉｉｉ）ブロック情報抽出ｉｖ）ページ情報抽出ｖ）ＤＢアクセス（ファイル作成）ブロック分解／情報抽出の方法は以下の通りである。

【００７８】〈バンディングの結合〉アプリから渡され
るＧＤＩコードバンディングされている場合には、１ペ
ージ分全部のＧＤＩコードを取得しまとめる。

【００７９】〈ビットマップ画像である事の判定方法〉（１）アプリから渡されるＧＤＩコードの中から、ビッ
トマップ画像（Ｉｍａｇｅ）として定義されている部分
は、ＭＳＷｉｎｄｏｗｓＳＤＫの記述により、容易
にビットマップ画像である事が判定できる。目標１で全
体画像をファイルに保存しているので、画像情報そのも
のは捨ててしまって構わない。ここで保存する情報は以
下の通り。

【００８０】ｉ）ビットマップ画像のＩＤｉｉ）ビットマップ画像の種類のＩＤ（二値、ハーフト
ーン、カラー、フルカラー）ｉｉｉ）ビットマップ画像のサイズｉｖ）印刷画面上での位置情報ｖ）ビットマップ画像の標準化色（８色）のヒストグラ
ムの上位３種類（標準化色とは、ＲＧＢ各色成分の上位
３ビットをテーブルルックアップ方式で８色に変換す
る。）などである。

【００８１】（２）判定に成功したＧＤＩコードは、次
の判定では無視する。〈表である事の判定方法〉ＷｉｎｄｏｗｓＯＳがファ
イリングドライバーに渡すＧＤＩコードを解析し、その
中に表が含まれているかどうかを判別する方法は以下の
通り。

【００８２】（１）グループ化：アプリケーションから
渡されるＧＤＩコードの中から、斜め線を無視し、縦線
／横線のみを選別し、Ｘ座標またはＹ座標が「一致」す
る直線をグループにしていく。（一致する直線を加える
毎にその直線の座標も「一致」の判定基準に加える）（２）矩形領域算出：グループ化した直線のグループの
内、Ｘ座標、Ｙ座標の最大値／最小値を「表」全体の矩
形領域と推定する。

【００８３】（３）セル数算出：発見したＸ座標及びＹ
座標の種類の数から１を引いた数をＸ座標及びＹ座標の
セル数と推定する。セル数がＸ、Ｙ方向共に２以上の
時、それを「表」と推定する。

【００８４】（４）セルサイズ算出：発見したＸ座標及
びＹ座標の、数字が互いに接近する二点間の差分をセル
サイズと推定する。

【００８５】（５）表の判定：矩形領域の内部に文字が
あれば、そこを「表」と断定する。文字が無ければ図形
と推定する。

【００８６】（６）書式：「表」の内部の文字はまとめ
て、ＴＡＢ−Ｔｅｘｔ形式で表現する。

【００８７】例えば、図６の様な表は図１７の様にＴＡ
Ｂ−Ｔｅｘｔ形式表記できる。

【００８８】ただし図１７において、（Ｔ）はタブ、
（ＣＲ）はキャリッジリターン。

【００８９】あるいは図１８の様にＳＹＬＫ形式で表記
しても良い。〈図形の判定方法〉（１）矩形領域の拡大：あるＧＤＩコードが矩形領域を
持っている場合には、その矩形領域を「拡大された矩形
領域」とし、直線の様に矩形領域を持たないＧＤＩコー
ドの場合には、それが持つ２点が構成する矩形領域を
「拡大された矩形領域」とする。

【００９０】（２）コードのグループ化：「拡大された
矩形領域」同士が重なるＧＤＩコード同士は、一つのグ
ループに属すると判定する。

【００９１】例えば、図７（Ａ）、（Ｂ）に示す様な図
形があった場合、（Ａ）は直線の矩形領域が大きいので
１個のグループと判定されるが、（Ｂ）は２個のグルー
プと判定される。

【００９２】（３）グループ化されたＧＤＩコーポネン
トのＸ座標およびＹ座標の最大値／最小値を「図形の矩
形領域」とする。グループ化されたＧＤＩコンポーネン
ト群を「ピクチャー」と呼ぶ。

【００９３】（４）「ピクチャー」をコード化する。

【００９４】コード化の基本ルールは図８に示す基本構
文に従って図１９の様な項目の内容を記述する。

【００９５】（５）図形を分類する図形は図２０のルールに従って分類する。

【００９６】〈テキスト部の判定〉（１）テキストの連結：１文字単独で文字が現れた場
合、フォントサイズから計算される「キャラクタ幅」に
単独文字があれば、「単語」として連結する。「単語」
はスペースを含まない。

【００９７】（２）「単語」の連結：「単語」同士がス
ペースのサイズ程度に近接していれば、「行」として連
結する。「行」はスペースを含み得る。

【００９８】（３）「文」の連結：「行」同士が「フォ
ント高さ」の３倍以内にあるときは、「文」として連結
する。「文」は複数の改行を含み得る。行端の「単語」
の連結はやらない。（日本語の場合、１行の全てが「単
語」として認識される場合がある。）（４）「文」をコード化する：コード化の基本ルールは
「ピクチャー」として類似しており、図９に示す基本構
文に従って図２１の様な項目の内容を記述する。

【００９９】〈ブロック情報抽出の方法〉ブロック毎に
ＩＤ番号を振る。その順番は、ｉ）自己ブロックＩＤｉｉ）自己ブロック位置ｉｉｉ）ブロックの大きさｉｖ）ブロック属性（テキスト、図形、表、イメージ、
グラフ、タイトル、文字コード）ｖ）親ブロックＩＤｖｉ）子ブロックＩＤｖｉｉ）そのページの中での順序

【０１００】〈ページ情報抽出の方法〉タイトル部の判
定方法は以下の通りである。

【０１０１】ステップ１：（１）最大フォントの判定：その文書の中で最もサイズ
の大きな「ストリング」を判定する。

【０１０２】（２）場所の判定：最大サイズの「ストリ
ング」が用紙の１／４より上（または下）にある時、そ
れをタイトルと判定する。

【０１０３】ステップ２：（１）特徴フォントの判定：同一サイズであっても、ア
ンダーライン、〈〉、「」、｛｝で特徴付けられた「ス
トリング」が用紙の１／４より上にある時、それをタイ
トルと判定する。

【０１０４】ステップ３：上記のいずれにも該当しない
時、タイトルは無いものと判定する。

【０１０５】〈紙の文書の電子ファイリングとの統合〉
図１０は、今まで述べてきたファイリングドライバーを
用いた市販アプリケーションからのファイリングと、紙
の文書の電子ファイリングとの統合化を説明する図であ
る。説明の都合上、市販アプリケーションからのファイ
リングを「ＤＴＰファイリング」、紙の文書の電子ファ
イリングを「ＯＣＲファイリング」と呼ぶ事にする。

【０１０６】図の中央にデータベース１３があり、それ
より左側には、今まで述べてきたファイリングドライバ
ーを用いた市販のアプリケーションからのファイリング
装置のブロック図が、右側には、紙の文書をスキャンし
てファイリングする電子ファイリング装置のブロック図
が書いてある。

【０１０７】図２と共通の構成要素には同一の番号が付
与してある。

【０１０８】同図に於て、２８はスキャナー、２９はそ
れをドライブする為のスキャナーモジュール、３１は電
子ファイリングエンジン、３０は検索モジュールであ
る。スキャナーモジュール２９と電子ファイリングエン
ジン３１は、それぞれスキャナーアプリケーション１と
検索アプリケーション１６に符合する。点線３３で囲ん
で示す様に、スキャナーモジュール２９と電子ファイリ
ングエンジン３１は電子ファイリングエンジン３１と一
体になり、全体で「電子ファイリングアプリケーショ
ン」を形成している。

【０１０９】電子ファイリングエンジン３１には、ブロ
ックセレクション、ＯＣＲ、キーワード抽出という３つ
の大きな機能がある。スキャナーモジュール２９に指示
してスキャナー２８から紙の原稿をスキャンして読み込
みます。読み込んだビットマップ画像はスキャナーモジ
ュール２９で二値化され、電子ファイリングエンジン内
でブロックセレクションプログラムにより、レイアウト
情報が抽出される。抽出される情報は、テキスト領域及
び画像領域のいずれかのプロファイルを持った矩形領域
情報である。

【０１１０】画像領域を示す情報は、レイアウト検索用
にデータベースに保存される。ブロックセレクションの
結果に基づき、ＯＣＲソフトによってテキスト領域が文
字コードに変換される。

【０１１１】その後、キーワード抽出プログラムにより
テキスト情報からキーワードとして使えそうな情報が抽
出され、それぞれデーターベースＡＰＩ３２を介してデ
ーターベース１３に保存される。保存された文書は、検
索モジュール３０で簡単に見る事ができる。

【０１１２】「ＯＣＲファイリング」はビットマップ画
像からブロックセレクションプログラムによってレイア
ウト情報を抽出するので、「ＤＴＰファイリング」ほど
には正確で詳細なレイアウト情報は得られないが、ビッ
トマップ画像の有無、タイトルの有無、と言ったレベル
の検索なら、両者共通に行える。ＯＣＲによって抽出し
たキャラクターコードは１００％正確ではない。しか
し、抽出したキャラクターコードそのものを再利用する
のではなく、全文検索用のインデックス構築の為に用い
るので、そこそこに正確であれば良く、手で認識誤りを
修正する必要はない。

【０１１３】データベースＡＰＩ３２を介して保存され
る情報は、ｉ）文書全体のビットマップ画像の圧縮結果ｉｉ）ブロックセレクション結果ｉｉｉ）ＯＣＲ結果ｉｖ）候補文字情報ｖ）ＯＣＲ結果から抽出したキーワード情報等である。

【０１１４】文書全体のビットマップ画像の圧縮方法は
ＪＢＩＧを用いる。ＪＢＩＧモノクロの文書の圧縮用で
あるが、階層符合化方式によりサムネール画像を簡単に
作れる。

【０１１５】図１１は、原稿の入力先としてＦａｘを取
り込んでいるところを示す図である。Ｆａｘ３４で受診
したＭＭＲ画像情報は、ＦａｘＩ／Ｆ３５でビットマッ
プ画像に伸長され、電子ファイリングエンジン３１に引
き渡される。それ以降は紙の原稿をスキャナーで読んだ
場合と全く同じである。

【０１１６】〈フローチャートの説明〉以下、フローチ
ャートを用いて、各部の動作を詳細に説明する。

【０１１７】図１２は、アプリケーションプログラム
と、ＯＳ（Ｗｉｎｄｏｗｓ）、ファイリングドライバー
の動作を説明するフローチャートである。図中、左側が
アプリケーション、中央がＯＳ、右側がファイリングド
ライバーの動作を示している。

【０１１８】ＯＳがマルチタスクのものならもち論、シ
ングルタスクの場合でも、アプリケーションとＯＳ、ド
ライバーの動作は見掛け上独立したタスクの様に振る舞
う。図中点線の矢印で示してある部分は、実際には関数
コールであるが、Ｃ⁺⁺やクラス定義の中では、「メッセ
ージ」という表現を用いる事が一般的であり、本実施例
ではその例に習う事にする。

【０１１９】アプリケーションがドキュメントを作成し
てそれを本発明の電子ファイルにファイリングする時、
通常の印刷動作と全く同じ操作を行なう。印刷メニュー
を選択すると（ステップ２）、ＯＳに対して印刷開始メ
ッセージが送られる。ＯＳはこの時種々のＯＳサービス
を実行しながら（ステップ６）イベントループに入り
（ステップ７）、アプリケーションからの印刷開始メッ
セージを受け付けると、ドライバーを起動させる（ステ
ップ８）。

【０１２０】ＯＳからのメッセージにより起動したファ
イリングドライバーは、レジスタセットやメモリ空間の
確保等の初期化処理を実行（ステップ１４）した後、初
期化完了メッセージをＯＳに返す。この間ＯＳはドライ
バーからの返事をループで待っている（ステップ９）。

【０１２１】そしてアプリケーションに対し、ドライバ
ーの準備が整った事を示すメッセージを送る（ステップ
１０）。

【０１２２】アプリケーションはステップ３のループか
ら抜け出し、プリンターに描画すべきＧＤＩコードを出
力する（ステップ４）。ＧＤＩコードを受け取ったＯＳ
は、プリンター（ドライバー）がＧＤＩプリンターなら
ばＧＤＩコードのままで、またビットマッププリンター
ならばＯＳの中でＧＤＩコードをラスタライズしてプリ
ンタードライバーに渡す（ステップ１１）。ファイリン
グドライバーは、プリンタードライバーをエミュレート
しており、ＧＤＩプリンターかビットマッププリンター
のどちらかである事を宣言することにより、そのどちら
でも実現可能である。もしＧＤＩプリンターであると宣
言すると、ＯＳからはＧＤＩコードがそのままの形で送
られて来るので、ドライバーの中では容易にＧＤＩコー
ドの解析ができるし、ビットマップが必要なら、ＯＳの
システムコールを呼んで、ラスタライズする事ができ
る。

【０１２３】もしビットマッププリンターであると宣言
すると、ＯＳの中でＧＤＩをビットマップに変換するＧ
ＤＩサービス（ステップ１１）が実行され、ファイリン
グドライバーにはビットマップが渡される。Ｗｉｎｄｏ
ｗｓの場合、たとえビットマップにしても、ビットマッ
プ・コードの片すみに元のＧＤＩコードが記載されてい
るから、本実施例ではビットマツプを宣言する事にす
る。

【０１２４】ファイリングドライバーは受け取ったＧＤ
Ｉコードを解析し（ステップ１６）、原稿に書かれてい
る内容の特徴を抽出し（ステップ１７）、それをデータ
ベース１３に保存する（ステップ１８）。ドライバーか
らＯＳに対し、印刷完了のメッセージが届いたら、ドラ
イバーの処理待ちになっているループ（ステップ１２）
から抜け出し、印刷完了メッセージをアプリケーション
に送る（ステップ１３）と共に、ファイリングドライバ
ーを終了させ、メモリー空間からスワップアウトする。
アプリケーションは、ＯＳからの印刷完了メッセージを
受けて、印刷シーケンスを終了する（ステップ５）。

【０１２５】図中、（＊１）で示した部分（ステップ１
６及びステップ１７）の詳細な処理を図１３のフローチ
ャートを用いて説明する。

【０１２６】図１３のフローチャートは、ファイリング
ドライバーでの動作である。ファイリングドライバー
は、ＯＳ経由でアプリケーションから取得したＧＤＩコ
ードを解析し、画像か（ステップ２１）、文字か（ステ
ップ２２）、ドローか（ステップ２３）を区別する。画
像を表すＧＤＩコードは、ＪＢＩＧ、ＪＰＥＧ、ＭＭＲ
等の圧縮アルゴリズムを用いて圧縮され（ステップ２
４）データベース１３の画像バッファに保存される。ド
ローとは、ベクトル情報の集合による線図形、面図形を
用いた描画を言う。

【０１２７】文字を表すＧＤＩコードはＲＡＭ（図示せ
ず）内の文字バッファに蓄えられ、文字バッファの処理
（ステップ２５）でタイトルであるかどうかの判定を受
けた後、文字に関する各種の情報（文字コード、スタイ
ル、文字色）を保存し、データベース１３のキーワード
として登録する。

【０１２８】ドロー部分のＧＤＩコードは、ドロー情報
の処理ルーチン（ステップ２７）に於て表、図形の判定
を受け、また、統計処理を受ける。

【０１２９】ＧＤＩコードが上記のいずれでも無い時
は、制御コードであるから、ステップ２６に於て制御コ
ードの処理を行う。制御コードの中身は、例えば紙サイ
ズ指定であり、また、紙方向指定、解像度指定、余白指
定、ページ番号指定、印刷枚数指定、改ページである。

【０１３０】特徴対抽出処理（ステップ１７）であるス
テップ２４、または２５、２６、２７の後は、次のＧＤ
Ｉコードを取得する為の準備（ステップ２８）に入る。
もし、制御コードが終了コードだった時は、ＧＤＩコー
ドの解析は終了するが、そうでない場合には次のＧＤＩ
コードを取得する為に、ステップ２０にループする。

【０１３１】図中、（＊２）で示すステップ２５の詳細
な処理を、図１４のフローチャートを用いて説明する。

【０１３２】図１４のフローチャートは、ファイリング
ドライバーでの動作である。ここでは文字バッファに蓄
えられた文字情報を解析して、タイトル文字かどうかの
判定を行い、キーワードとして登録している。

【０１３３】ＧＤＩコードの場合、文字コードは一連の
ストリング（文章）になって表現されるとは限らない。
ストリングのＧＤＩコードを吐き出すアプリケーション
は、エディターと呼ばれるソフトウエア位で、高級なＤ
ＴＰアプリケーションになればなるほど、むしろ一文字
一文字描画する場合が多い。高級なＤＴＰアプリケーシ
ョンは、ＧＤＩコードの表現能力を越えた高度の文章表
現をするので、一文字一文字の描画になる事が多い。

【０１３４】電子ファイルの場合それでは検索ができな
いので、文字を連結して単語や文章に変換する必要があ
る。それがステップ３０と３１であり、文字と文字との
間隔がその文字の高さの１／２以上であれば文字に区切
りと判断し（ステップ３２）、それ以上接近している場
合は単語の一部と判断する（ステップ３７）。単語の一
部と判断された場合には、単語の区切りを見つける為
に、その時処理したＧＤＩコードの文字情報を文字バッ
ファーに書き込み、次のＧＤＩコードを取得すべくこの
ルーチンを抜け、ステップ２８に進む。

【０１３５】一方、文字と文字の間隔が、文字の高さの
１／２より広い部分は、単語の区切りと判定し（ステッ
プ３２）、データベース１３にキーワードとして登録す
る。その中でもタイトルと思われる文字はキーワードの
中でも特にタイトルとして特別に保存し、タイトル文字
として検索の用に供する。タイトルと判定するアルゴリ
ズムは、対象とする文字が、原稿の縦寸法の上から１／
４以内にあると判断され（ステップ３３）、かつ、原稿
中で最大サイズの文字とステップ３４で判断される場合
にその文字をタイトルと判定し、タイトルであることを
識別できる情報を付加する。それ以外の文字はタイトル
以外の文字としてキーワード登録する（ステップ３
６）。タイトル自身もキーワードである事は言うまでも
ない。

【０１３６】図１３の中の（＊３）で示した部分（ステ
ップ２７）の詳細な処理を、図１５のフローチャートを
用いて説明する。

【０１３７】図１５のフローチャートはファイリングド
ライバーでの動作であり、ドロー情報の処理を行なう。
始めに、ＧＤＩコードが直線か否かを判別し（ステップ
４０）、直線である場合にはさらに表であるかどうかを
判別するルーチン（ステップ４１〜ステップ４８）に入
るが、直線以外の丸、だ円、四角、ポリゴン、斜目線、
曲線等である場合には、単純にドロー画グループに加え
（ステップ４９）データベース１３に保存する。

【０１３８】ステップ４０で直線と判別された場合、す
でにデータベース１３に登録済の直線グループの中の線
と接するかどうかを判定する（ステップ４１）。判定方
法は、その時処理対象となっている直線の持つ２点（始
点、終点）のＸ座標とＹ座標のどれかが既に登録済の直
線グループの中の線の持つ２点の座標のどれかと１つで
も一致し、かつ、他の座標が所定範囲内にあれば接して
いると判別する。

【０１３９】たとえば図１６の様に２本の線Ａ、Ｂが接
している事を証明するには、Ｘ₁ ＝Ｘ₃ をチェックするだけで良い。

【０１４０】ＡもＢも斜目線でない事は分かっているか
ら、Ｘ₁ ＝Ｘ₃ ＝Ｘ₄ でもある。ＢのＹ座標は、Ａの始点と終点の間になけれ
ばならないから、Ｙ₄ ≦Ｙ₁ ≦Ｙ₃ でなければならない。すなわち、２本の直線の有する各
４種類のＸ、Ｙ座標の内、３つが一致する成分を調べ、
もし一致する場合には、２つ共一致する成分を持つ直線
の他方の成分の間に他の線分の同じ座標が入っていれ
ば、接していると判別できる。これがＸ、Ｙ共に成り立
つ時は、２本の線は直角を形成する。

【０１４１】図１５に戻って説明すると、ステップ４１
で、どの直線グループとも接しないと判別された直線
は、それ自身が新たな直線グループを形成するものとし
て登録する（ステップ５０）。

【０１４２】一方、接する事が分かった直線について
は、その直線グループの一員として加える（ステップ４
２）。

【０１４３】ある直線グループの有するＸ座標Ｙ座標の
各々の最大、最小の４つにより定まる領域を、その直線
グループの矩形領域と定める。この矩形領域は、新たな
直線が加わる毎に再計算する（ステップ４３）。

【０１４４】その直線グループの構成するＸ座標だけま
たはＹ座標だけの種類の数を求め、それから１を引いた
数をセル数として算出する（ステップ４４）。

【０１４５】また同様に、Ｘ座標の成分と、Ｙ座標の成
分を別々に大きさ順にならべ、互いに接近する座標同士
の差分をセルサイズとして計算する（ステップ４５）。

【０１４６】この直線グループの矩形領域の中に、文字
が入る場合には（ステップ４６）、その文字を表中の文
字として表中の文字であることを識別できる情報ととも
に特別に登録し（ステップ４７）、かつ、その直線グル
ープを表と判定する（ステップ４８）。

【０１４７】文字を全く含まない直線グループは表とは
見なさず、通常の直線としてデータベース１３に登録す
る。

【０１４８】

【発明の効果】以上説明した様に、本発明を用いれば紙
の文書の電子ファイリングとＤＴＰアプリケーションで
作成したコンピュータファイル文書とが統合的に電子フ
ァイリングできるので、従来やや閉鎖的だった電子ファ
イリングがＤＴＰファイリングと共に効果的に、手軽に
利用できる様になる。

【０１４９】従来の電子ファイリングでは、特別に訓練
されたオペレーターが必要であったが、本発明による電
子ファイリングシステムによれば、自分の机の上から誰
でも扱える様になり、紙文化は一新することができる。

【０１５０】従来キーワード検索一辺倒だった電子ファ
イリングも、本発明を用いれば原稿の特徴量によるレイ
アウト検索が可能になり、例えば、タイトルが「野球」
で、絵が２枚入っていて、表が１本入っており、キーワ
ードが「長島茂雄」という検索が実行できるので、目的
の文書が極めてスピーディーに探す事ができる。

【０１５１】また、ビットマップの全体画像の圧縮方法
は、ＪＢＩＧという階層符合化理論を用いているので、
サムネール画像（小画像）表示による目視検索も使える
ので、原稿に書かれた内容をチェックしながらの検索も
可能になる。

【図面の簡単な説明】

【図１】本発明による電子ファイリング装置のブロック
ダイヤグラム。

【図２】検索アプリの位置づけを説明する図。

【図３】ＯＣＲアクセラレーターを使う場合の実施例を
示す図。

【図４】デバイスドライバーの要部を説明した図。

【図５】対話式会議システムへの応用例を示す図。

【図６】Ｔｅｘｔ−Ｔａｂ形式による表の情報の表現方
法を示す図。

【図７】図形のグループ化の為の２つの例を示す図。

【図８】ピクチャー部分をコード化する為の基本構文を
示す図。

【図９】テキスト部分をコード化する為の基本構文を示
す図。

【図１０】ファイリングドライバーと紙の文書の電子フ
ァイリングとの統合化を示す図。

【図１１】ファクシミリ文書の電子ファイリングを示す
図。

【図１２】実施例の全体処理のフローチャート。

【図１３】ＧＤＩコードの解析及び特徴抽出処理のフロ
ーチャート。

【図１４】文字バッファの処理のフローチャート。

【図１５】ドロー情報の処理のフローチャート。

【図１６】直線の解析を説明する図。

【図１７】ＴＡＢ−Ｔｅｘｔ形式表記例示図。

【図１８】表のＳＹＬＫ形式表記例示図。

【図１９】ピクチャーのコード化記述例示図。

【図２０】図形の分類例を示す図。

【図２１】文のコード化記述例示図。

Claims

【特許請求の範囲】

【請求項１】アプリケーションソフトウエアからプリ
ンタドライバーに伝達される情報をデータベースに蓄積
する手段を有することを特徴とする電子ファイリング装
置。
【請求項２】前記電子ファイリング装置において、印
刷用の描画コマンドを文書蓄積に達したフォーマットに
変換する手段を有することを特徴とする請求項１に記載
の電子ファイリング装置。
【請求項３】前記電子ファイリング装置において、キ
ーワード検索用の情報を抽出して保存する手段を有する
ことを特徴とする請求項１に記載の電子ファイリング装
置。
【請求項４】前記電子ファイリング装置において、描
画コマンドの中にビットマップ画像情報が含まれる場合
には、該画像データを蓄積する際に圧縮する手段を有す
ることを特徴とする請求項１に記載の電子ファイリング
装置。
【請求項５】アプリケーションソフトウエアからプリ
ンタドライバーに伝達される描画情報を、特徴に応じて
分割する手段と、該分割された情報毎に最適な圧縮処理を施す手段と、前記圧縮された情報をデータベースに蓄積することを特
徴とする電子ファイリング装置。
【請求項６】前記分割は、文字部分か、ベクトル描画
部分か、ビットマップ画像部分かによって行うことを特
徴とする請求項５に記載の電子ファイリング装置。
【請求項７】前記電子ファイリング装置において、プ
リンタドライバーに伝達される描画情報の内、ビットマ
ップ画像部分を認識してコード化する手段と、前記認識して得たコードの内、文字コードは前記文字部
分と同様に扱うことを特徴とする請求項６に記載の電子
ファイリング装置。
【請求項８】アプリケーションソフトウエアからプリ
ンタドライバーに伝達される描画情報からタイトル部分
を抽出する手段と、前記抽出されたタイトル情報を検索のキー情報として登
録することを特徴とする電子ファイリング装置。
【請求項９】前記タイトル情報は、タイトルの有無と
することを特徴とする請求項８に記載の電子ファイリン
グ装置。
【請求項１０】前記タイトル情報は、タイトルを認識
して得たコード情報とすることを特徴する請求項８に記
載の電子ファイリング装置。
【請求項１１】前記描画情報から特徴に応じて分割す
る手段を有することを特徴とする請求項８に記載の電子
ファイリング装置。
【請求項１２】前記分割は、文字部分か、ベクトル描
画部分か、ビットマップ画像部分かによって行うことを
特徴とする請求項８に記載の電子ファイリング装置。
【請求項１３】アプリケーションソフトウエアからプ
リンタドライバーに伝達される描画情報から表部分を抽
出する手段と、前記抽出された表情報を検索のキー情報
として登録することを特徴とする電子ファイリング装
置。
【請求項１４】前記表情報は、表の有無とすることを
特徴とする請求項１３記載の電子ファイリング装置。
【請求項１５】前記表情報は、表を構成する段数とす
ることを特徴とする請求項１３に記載の電子ファイリン
グ装置。
【請求項１６】前記描画情報から特徴に応じて分割す
る手段を有することを特徴とする請求項１３に記載の電
子ファイリング装置。
【請求項１７】前記分割は、文字部分か、ベクトル描
画部分か、ビットマップ画像部分かによって行うことを
特徴とする請求項１３に記載の電子ファイリング装置。
【請求項１８】アプリケーションソフトウエアからプ
リンタドライバーに伝達される描画情報からグラフ部分
を抽出する手段と、前記抽出されたグラフ情報を検索のキー情報として登録
することを特徴とする電子ファイリング装置。
【請求項１９】前記グラフ情報は、グラフの有無とす
ることを特徴とする請求項１８記載の電子ファイリング
装置。
【請求項２０】前記描画情報から特徴に応じて分割す
る手段を有することを特徴とする請求項１８に記載の電
子ファイリング装置。
【請求項２１】前記分割は、文字部分か、ベクトル描
画部分か、ビットマップ画像部分かによって行うことを
特徴とする請求項１８に記載の電子ファイリング装置。
【請求項２２】アプリケーションソフトウエアからプ
リンタドライバーに伝達される描画情報からビットマッ
プ画像部分を抽出する手段と、前記抽出されたビットマップ画像情報を検索のキー情報
として登録することを特徴とする電子ファイリング装
置。
【請求項２３】前記ビットマップ画像情報は、ビット
マップ画像の有無とすることを特徴とする請求項２２記
載の電子ファイリング装置。
【請求項２４】前記ビットマップ画像情報は、ビット
マップ画像の個数とすることを特徴とする請求項２２に
記載の電子ファイリング装置。
【請求項２５】前記描画情報から特徴に応じて分割す
る手段を有することを特徴とする請求項２２に記載の電
子ファイリング装置。
【請求項２６】前記分割は、文字部分か、ベクトル描
画部分か、ビットマップ画像部分かによって行うことを
特徴とする請求項２２に記載の電子ファイリング装置。
【請求項２７】原稿を光学的に読み取る手段と、前記読み取った原稿の画像を圧縮してデータベースに保
存する手段と、前記読み取った画像を文字部分と画像部分とに分割する
手段と、前記分割された文字部分を認識してコード化し、保存す
る手段と、前記保存した文字コードと指定されたキーワードが一致
するか否か判定する手段と、前記判定により一致すると判定される場合に、一致する
画像を伸長して表示する手段とを有することを特徴とす
る電子ファイリング装置。
【請求項２８】前記原稿を光学的に読み取る手段に替
えて、公衆回線により画像を受信する手段を有すること
を特徴とする請求項２７に記載の電子ファイリング装
置。
【請求項２９】アプリケーションソフトウエアからプ
リンタドライバーに伝達された情報を蓄積に適したフォ
ーマットに変換する手段と、前記変換された情報を蓄積する手段とを有することを特
徴とする電子ファイリング装置。
【請求項３０】前記変換の水準を複数段階設け、アプ
リケーションソフトウエアの機能の段階によって変換の
水準を選択することを特徴とする請求項２９に記載の電
子ファイリング装置。
【請求項３１】前記プリンタドライバーの情報の流れ
を双方向とすることを特徴とする請求項２９に記載の電
子ファイリング装置。
【請求項３２】前記アプリケーションソフトウエアと
のインターフェイスを汎用ドライバーの形式とすること
を特徴とする請求項２９に記載の電子ファイリング装
置。
【請求項３３】前記情報の蓄積は、ネットワーク上の
データベースとすることを特徴とする請求項２９に記載
の電子ファイリング装置。
【請求項３４】前記データベースに替えて、複数台数
のクライアントコンピュータ同士で情報を送受信する手
段を有することを特徴とする請求項３３に記載の電子フ
ァイリング装置。