JP2005149098A - 画像処理システム及び画像処理装置並びに画像処理方法 - Google Patents

Abstract

【課題】 原稿に対応する電子ファイルの有無に関わらず、ユーザが所望するアプリケーションフォーマットの電子ファイルを好適に取得することができる画像処理システム及び画像処理装置並びに画像処理方法を提供する。
【解決手段】 アプリケーションフォーマットを指定するとともに、原稿を読み取ってイメージ情報を取得し、原稿に対応する電子ファイルをサーバが保持する電子ファイルの中から特定する。また、取得されたイメージ情報を文字コード化、ベクトルデータに変換、又は所定の画像形式に変換する。そして、原稿に対応する電子ファイルが特定できた場合、それが指定されたフォーマットであるか否かを照合する。ここで、電子ファイルが特定されなかった場合、又は当該フォーマットでないと照合された場合は変換により得られたデータを、当該フォーマットであると照合された場合は当該電子ファイルを選択的に出力する。
【選択図】 図３

Description

本発明は、複写機等の画像処理装置で読み取った画像を既存の文書作成アプリケーションソフトで再利用可能なベクトルデータに変換する画像処理システム及び画像処理装置並びに画像処理方法に関する。

近年、環境問題がクローズアップされている中で、オフィス等でのペーパーレス化が急速に進んでいる。そこで、従来からバインダー等で蓄積・保存された紙文書をスキャナで読み取って、ポータブルドキュメントフォーマット（以下、「ＰＤＦ」と略す。）に変換し、画像記憶装置（データベース）に蓄積・保存する文書管理システムが構築されている。

一方、機能が拡張されたデジタル複合機（以下、「ＭＦＰ」と略す。）には、画像（イメージデータ）を紙文書として印刷・出力する際に、当該画像が記憶されている画像記憶装置内のポインタ情報を紙文書の表紙或いは記載情報中に付加情報として記録しておくものがある。そして、当該画像が記録された紙文書を複写する場合には、表紙等に付加されているポインタ情報からオリジナルの画像が格納されている画像記憶装置内の格納場所を検出し、紙文書から読み取られた画像を再印刷等に用いるのではなく、画像記憶装置内に記憶されているオリジナルの画像を編集や再印刷に直接用いることができる。これにより、紙文書として保存する必要がなく、紙文書から読み取られた画像を何度も再利用することによって生じる画質の劣化等の問題を防ぐことができる。

このような、あらゆる紙文書に対しても再利用可能な電子ファイルとして扱える画像処理システムに関する提案はこれまでにもなされている（例えば、特許文献１参照。）。この画像処理システムにおいては、紙文書に付加されたポインタ情報により、電子ファイルがデータベース（ファイルサーバ）上に見つかった場合は、当該電子ファイルの取得を行っていた。
特開開平１０−１４３４１４号公報

しかしながら、取得した電子ファイルが、ユーザ個人のＰＣ環境では取り扱うことができないアプリケーションで作成されている場合、又は取り扱うことは可能であるが、所望とするアプリケーションで作成されていないような場合には、当該電子ファイルを取得せずに、新規に紙文書からベクトルデータを生成し、それを取得する方が好ましいと考えられる。例えば、当該電子ファイルがＰＤＦファイルのようにファイル全体が１つのイメージデータとして保存されるような場合、一般的なユーザ個人のＰＣ環境では当該電子ファイルを取得した場合であってもそれを再編集等することはできない。

本発明は、このような事情を考慮してなされたものであり、原稿に対応する電子ファイルの有無に関わらず、ユーザが所望するアプリケーションフォーマットの電子ファイルを好適に取得することができる画像処理システム及び画像処理装置並びに画像処理方法を提供することを目的とする。

上記課題を解決するために、本発明は、サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理システムであって、
所定のアプリケーションフォーマットを指定する指定手段と、
原稿を読み取ってイメージ情報を取得する読取手段と、
前記読取手段で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定手段と、
前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
前記読取手段で取得された前記イメージ情報を、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
前記特定手段により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定手段により指定されたアプリケーションフォーマットであるか否かを照合する照合手段と、
前記特定手段で前記電子ファイルが特定されなかった場合、又は前記照合手段により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換手段により得られたデータを、前記照合手段により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力手段と
を備えることを特徴とする。

また、本発明は、サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理装置であって、
所定のアプリケーションフォーマットを指定する指定手段と、
原稿を読み取ってイメージ情報を取得する読取手段と、
前記読取手段で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定手段と、
前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
前記読取手段で取得された前記イメージ情報を、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
前記特定手段により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定手段により指定されたアプリケーションフォーマットであるか否かを照合する照合手段と、
前記特定手段で前記電子ファイルが特定されなかった場合、又は前記照合手段により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換手段により得られたデータを、前記照合手段により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力手段と
を備えることを特徴とする。

さらに、本発明は、サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理方法であって、
所定のアプリケーションフォーマットを指定する指定工程と、
原稿を読み取ってイメージ情報を取得する読取工程と、
前記読取工程で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定工程と、
前記読取工程で取得された前記イメージ情報を文字コード化する文字処理工程と、
前記読取工程で取得された前記イメージ情報をベクトルデータに変換するベクトル化工程と、
前記読取工程で取得された前記イメージ情報を所定の画像形式に変換する画像変換工程と、
前記読取工程で取得された前記イメージ情報を、その属性に応じて前記文字処理工程、前記ベクトル化工程、前記画像変換工程の少なくともいずれかを用いて変換する変換工程と、
前記特定工程により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定工程により指定されたアプリケーションフォーマットであるか否かを照合する照合工程と、
前記特定工程で前記電子ファイルが特定されなかった場合、又は前記照合工程により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換工程により得られたデータを、前記照合工程により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力工程と
を有することを特徴とする。

本発明によれば、原稿に対応する電子ファイルの有無に関わらず、ユーザが所望するアプリケーションフォーマットの電子ファイルを好適に取得することができる。

以下、図面を参照して、本発明の実施形態について説明する。

図１は、本発明の第１の実施例に係る画像処理システムの構成を示すブロック図である。図１に示す画像処理システムは、オフィス１０とオフィス２０とをインターネット等のネットワーク１０４で接続された環境で実現される。

オフィス１０内に構築されたＬＡＮ１０７には、ＭＦＰ１００と、ＭＦＰ１００を制御するマネージメントＰＣ１０１と、クライアントＰＣ１０２と、文書管理サーバ１０６ａと、そのデータベース１０５ａ及びプロキシサーバ１０３ａが接続されている。また、オフィス２０内に構築されたＬＡＮ１０８には、文書管理サーバ１０６ｂと、そのデータベース１０５ｂ及びプロキシサーバ１０３ｂが接続されている。尚、クライアントＰＣ１０２は、外部記憶部、検索イメージ入力部及び検索結果出力部を備えている。また、ＬＡＮ１０７及びオフィス２０内のＬＡＮ１０８は、プロキシサーバ１０３ａ、１０３ｂを介してインターネット等のネットワーク１０４に接続されている。

ＭＦＰ１００は、本実施形態において紙文書を光学的に読み取って画像信号に変換する画像読み取り処理と、読み取った画像信号に対する画像処理の一部を担当し、画像信号はＬＡＮ１０９を用いてマネージメントＰＣ１０１に入力する。尚、マネージメントＰＣ１０１は、通常のＰＣでも実現可能であり、内部に画像記憶部、画像処理部、表示部及び入力部を備える。尚、マネージメントＰＣ１０１は、その一部又は全部をＭＦＰ１００と一体化して構成してもよい。

図２は、本発明の第１の実施例に係るＭＦＰ１００の構成を示すブロック図である。図２において、オートドキュメントフィーダ（以下、「ＡＤＦ」と略す。）を含む画像読み取り部１１０は、束状或いは１枚の原稿画像を内部に備える光源で照射し、原稿反射像をレンズで固体撮像素子上に結像し、固体撮像素子からラスタ状の画像読み取り信号を例えば６００ｄｐｉの密度のイメージ情報として得る。そして通常の複写機能を用いる場合は、この画像信号をデータ処理部１１５で記録信号へ画像処理し、複数毎複写の場合は記憶装置１１１に一旦１ページ分の記録データを保持した後、形成装置１１２に順次出力して紙上に画像を形成する。

一方、クライアントＰＣ１０２から出力されるプリントデータは、ＬＡＮ１０７からＭＦＰ１００に入力され、ネットワークＩＦ１１４を経てデータ処理装置１１５で記録可能なラスタデータに変換された後、形成装置１１２に出力して紙上に記録画像として形成される。

ＭＦＰ１００への操作者の指示は、ＭＦＰ１００に装備されているキー等の入力装置１１３、或いはマネージメントＰＣ１０１のキーボードやマウス等からなる入力装置から行われ、これら一連の動作はデータ処理装置１１５内の制御部で制御される。

一方、操作入力の状態表示及び処理中の画像データの表示は、ＭＦＰ１００の表示装置１１６又は、マネージメントＰＣ１０１、クライアントＰＣ１０２のモニタ等で行われる。尚、記憶装置１１１は、マネージメントＰＣ１０１からも制御され、ＭＦＰ１００とマネージメントＰＣ１０１とのデータの授受及び制御は、ネットワークＩＦ１１７及び直結したＬＡＮ１０９を用いて行われる。

［処理概要］
次に、本発明の一実施形態に係る画像処理システムによる画像処理全体の概要について説明する。図３は、本発明の第１の実施例に係る画像処理システムによる画像処理の手順について説明するためのフローチャートである。

ユーザは、ＭＦＰ１００の操作部（ＵＩ）等を用いて各種アプリケーションの設定に関する指定・登録を行う（ステップＳ１２０）。尚、ステップＳ１２０の各種設定処理の詳細については後述する。

次に、ＭＦＰ１００における画像読み取り部１１０を動作させて１枚の原稿をラスタ走査し、例えば、６００ｄｐｉ、８ビットの画像信号を得る（イメージ情報入力処理：ステップＳ１２１）。尚、当該画像信号は、データ処理装置１１５で前処理を施して記憶装置１１１に１ページ分の画像データとして保存する。

次に、マネージメントＰＣ１０１のＣＰＵにより、記憶装置１１１に格納された画像信号から、まず文字／線画部分とハーフトーンの画像部分とに領域を分離する。そして、文字部分はさらに段落で塊として纏まっているブロック毎に、或いは、線で構成された表、図形に分離し各々セグメント化する。一方、ハーフトーンで表現される画像部分は、矩形に分離されたブロックの画像部分、背景部等のいわゆるブロック毎に独立したオブジェクトに分割する（ＢＳ処理：ステップＳ１２３）。

このとき、原稿画像中に付加情報として記録された２次元バーコード、或いはＵＲＬに該当するオブジェクトを検出して、ＵＲＬはＯＣＲ処理（光学的文字認識処理）で文字認識し、２次元バーコード又は当該オブジェクトを解読する（ステップＳ１２４）。

次いで、原稿のオリジナル電子ファイルが格納されている記憶装置内のポインタ情報を検出する（ステップＳ１２５）。尚、ポインタ情報を付加する手段としては、他に文字と文字の間隔に情報を埋め込む方法や、ハーフトーンの画像に埋め込む方法等の直接可視化されない電子透かしによる方法を用いた場合であってもよい。このように付加情報が電子透かしとして埋め込まれている場合は、ステップＳ１２５では透かし情報を検出して解読することとなる。

そして、ポインタ情報が検出されたか否かを判定し（ステップＳ１２６）、ポインタ情報が検出された場合（Ｙｅｓ）は、ポインタで示されたアドレスから原稿に対応する電子ファイルを検索することによって特定する（ステップＳ１２７）。電子ファイルは、図１においてクライアントＰＣ１０２内のハードディスク内、或いはオフィス１０、２０のＬＡＮ１０７、１０８に接続された文書管理サーバ１０６ａ、１０６ｂ内のデータベース１０５ａ、１０５ｂ、或いはＭＦＰ１００自体が有する記憶装置１１１のいずれかに格納されている。そして、ステップＳ１２５で得られたアドレス情報に従って、これらの記憶装置内から検索される。

その結果、ステップＳ１２７で電子ファイルが見つかった場合（Ｙｅｓ）、ステップ１３９に分岐してアプリケーション照合を行う。また、電子ファイルが見つからなかった場合（Ｎｏ）は、ステップＳ１２８に分岐する。さらに、ステップＳ１２６で、ポインタ情報自体が存在しなかった場合（Ｎｏ）も、ステップＳ１２８に分岐する。

ステップＳ１２８は、いわゆる文書検索処理ルーチンである。まず、ステップＳ１２４で各テキストブロックに対して行ったＯＣＲの結果から単語を抽出して、全文検索或いは各オブジェクトの配列と各オブジェクトの属性からいわゆるレイアウト検索を行う。検索の結果、類似度の高い電子ファイルが見つかった場合はそのサムネイル等を表示する（ステップＳ１２９）。また、検索された電子ファイルが複数存在する場合等の操作者の選択が必要な場合は、操作者の入力操作よってファイルの特定を行う。そして、ステップＳ１３０で（Ｙｅｓ）と判断され、ステップ１３９に分岐してアプリケーション照合を行う。

また、ステップＳ１２８の検索処理で電子ファイルが見つからなかった場合、ステップＳ１３０で（Ｎｏ）と判断され、ステップＳ１３１に分岐してベクトル化処理を行う。

ステップＳ１３１では、ラスタイメージデータからベクトルデータへの変換処理を行って、オリジナルの電子ファイルに近い、編集容易で容量の小さい電子ファイルに変換する。すなわち、ステップＳ１２４でＯＣＲ処理された文字ブロックに対して、文字種、文字のサイズ、スタイル及び字体等を認識し、原稿を走査して得られた文字に可視的に忠実なフォントデータに変換し、文字コード化する（文字コード、サイズ、スタイル、字体を示すコードとフォントデータとを対応付ける。）。一方、線や曲線で構成される線画、表、又は図形ブロック等に対してはアウトライン化、関数近似化（直線近似、曲線近似、図形近似等）を行う。さらに、画像ブロックに対しては、イメージデータを圧縮して個別のＪＰＥＧファイル等として処理する。

尚、ここでは文字コード化、イメージデータの圧縮も含めてベクトルデータへの変換処理として説明したが、原稿によっては当然にベクトル化されるデータが含まれない（例えば、写真のみの原稿や文字のみの原稿）があるが、ここではこのように画像の属性（文字、線画、自然画等）に応じた形式に変換する処理をベクトル化処理と称することとする。

尚、これらのベクトル化処理は、各オブジェクト毎に行い、更に各オブジェクトのレイアウト情報を保存して、例えば、ｒｔｆやｓｖｇ等のアプリデータに変換し（ステップＳ１３２）、変換後のファイルを電子ファイルとして記憶装置１１１等に格納する（ステップＳ１３３）。

ベクトル化された原稿画像は、以降同様の処理を行う際に直接電子ファイルとして検索することができるように、検索のためのインデックス情報を生成して（ステップＳ１３４）、検索用インデックスファイルに追加する。そして、格納アドレスを操作者（クライアント）に通知する（ステップＳ１３５）。

さらに、操作者が行おうしている処理が記録であるか否かが判断され（ステップＳ１３６）、記録の場合（Ｙｅｓ）はステップＳ１３７に分岐して、ポインタ情報をイメージデータとしてファイルに付加する。

尚、以上本発明によって得られた電子ファイル自体を用いて、例えば文書の加工、画像の編集、蓄積、伝送、記録をステップＳ１３８で行うことが可能になる。

上述したような処理によって、イメージデータをそのままの形で取得するような場合に比べて、取得後の当該電子ファイルの再利用・再編集が容易になるだけでなく、情報量を削減することにより蓄積効率が高まり、伝送時間が短縮され、記録表示する際には高品位なデータとして非常に優位となるという効果が得られる。

以下各処理ブロックに対して詳細に説明する。

［アプリケーション指定・登録処理］
まず、ステップＳ１２０で行われるアプリケーション指定・登録処理について説明する。図１８は、アプリケーション指定・登録処理（ステップＳ１２０）の手順を詳細に説明するためのフローチャートである。ユーザは、ＭＦＰ１００の入力装置１１３等の操作部（ＵＩ）を用いて、原稿に付加されているポインタ情報より電子ファイルを取得するための検索処理（特定処理）を行うか否かを設定する（ステップＳ２００１）。これは、ポインタ情報が示す電子ファイルが、検索対象データベース（ファイルサーバ）に存在しないことが予め判っているときなどの用途で用いられる。或いは、ポインタ情報が示す電子ファイルが存在すると判っていても、その電子ファイルに拘らないという場合や、その電子ファイルが所望のアプリケーションで作成されたものではない、即ち所望の電子ファイルではないと判っている場合には、検索処理をＯＦＦに設定することが処理時間上からも望ましい。従って、本実施例では、特定処理の実行の可否を選択させることとしている。

一方で、ポインタ情報が示す電子ファイルの有無が不明な場合、或いはその電子ファイルがどのアプリケーションで作成されているかが不明な場合等は、検索処理をＯＮに設定する。

そして、次にアプリケーションフォーマットの指定・登録を行う（ステップＳ２００２）。すなわち、この処理によって指定・登録されたアプリケーションフォーマットの電子ファイルのみを取得対象ファイルとすることが可能となる。指定・登録内容の例としては、符号２００３で示すように、アプリケーション名、アプリケーション拡張子（例えば、ｄｏｃ，ｐｐｔ，ｘｌｓ等）、ファイルフォーマット（例えば、ＪＰＥＧ，ｔｉｆｆ，ｓｖｇ等）が挙げられる。

これらの設定された内容は記憶装置１１１に格納され、ファイル特定の実行処理（ステップＳ１２２）及び後述するアプリケーション照合処理（ステップＳ１３９）で用いられる。例えば、ステップＳ２００１において検索処理をＯＦＦに設定した場合、図３のステップＳ１２２はＮｏとなって電子ファイル検索を行わず、ベクトル化処理（ステップＳ１３１）へ進む。

次に、ステップＳ１２０１で示すブロックセレクション（ＢＳ）処理について説明する。

［ブロックセレクション処理］
図４は、ブロックセレクション処理によって読み取った１枚のイメージデータを属性を判定し複数のブロックに分割する様子を示す図である。すなわち、ブロックセレクション処理とは、符号４１に示すステップＳ１２１で読み取った一頁のイメージデータを、符号４２に示すようにオブジェクト毎の塊として認識し、それぞれのブロックを文字（Text）、写真（Photo）、線（Line）、表（Table）等の属性に判定し、異なる属性を持つ領域（ブロック）に分割する処理である。

ブロックセレクション処理の一実施例を以下に説明する。

まず、入力画像を白黒に２値化して、輪郭線追跡を行って黒画素輪郭で囲まれる画素の塊を抽出する。そして、面積の大きい黒画素の塊については、内部にある白画素に対して同様に輪郭線追跡を行って白画素の塊を抽出する。さらに、一定面積以上の白画素の塊の内部からも再帰的に黒画素の塊を抽出する。尚、上記処理は、白地に黒字等で記載されている原稿の場合の処理であって、それ以外の場合は背景に相当する色を「白」、オブジェクトに相当する色を「黒」とすることにより同様に処理することができる。

このようにして得られた黒画素の塊を、大きさ及び形状等で分類し、異なる属性を持つ領域へ分類する。例えば、縦横比が１に近く、大きさが一定の範囲のものを文字相当の画素塊とし、さらに近接する文字が整列良くグループ化可能な部分を文字領域とする。また、扁平な画素塊を線領域、一定の大きさ以上でかつ四角系の白画素塊を整列よく内包する黒画素塊の占める範囲を表領域、不定形の画素塊が散在している領域を写真領域、それ以外の任意形状の画素塊を図画領域等とする。

図５は、ブロックセレクション処理で得られた各ブロックに対するブロック情報の一例について示す図である。図５に示されるブロック毎の情報は、後述するベクトル化、検索処理のための情報として用いられる。

［イメージデータからポインタ情報の検出］
まず、ステップＳ１２４で示す電子ファイルの格納位置を、読み取られたイメージデータから抽出するためのＯＣＲ／ＯＭＲ処理について説明する。

図６は、原稿画像中に付加された２次元バーコード（ＱＲコードシンボル）を復号してデータ文字列を出力する手順を説明するためのフローチャートである。図７は、２次元バーコードが付加された原稿３１０の一例を示す図である。

まず、データ処理装置１１５内のページメモリに格納された原稿３１０を読み取って得られたイメージデータを内部のＣＰＵで走査して、前述したブロックセレクション処理の結果から所定の２次元バーコードシンボル３１１の位置を検出する。ＱＲコードの位置検出パターンは、シンボルの４隅のうちの３隅に配置される同一の位置検出要素パターン３１１ａ〜３１１ｃから構成される (ステップＳ３００)。

次に、位置検出パターンに隣接する形式情報を復元し、シンボルに適用されている誤り訂正レベル及びマスクパターンを得る（ステップＳ３０１)。さらに、シンボルの型番を決定した後（ステップＳ３０２）、形式情報で得られたマスクパターンを使って符号化領域ビットパターンをＸＯＲ演算することによってマスク処理を解除する（ステップＳ３０３）。

そして、モデルに対応する配置規則に従い、シンボルキャラクタを読み取り、メッセージのデータ及び誤り訂正コード語を復元する（ステップＳ３０４）。次いで、復元されたコード上に誤りがあるかどうかの検出を行う（ステップＳ３０５）。その結果、誤りが検出された場合（Ｙｅｓ）は当該誤りを訂正する（ステップＳ３０６）。そして、誤り訂正されたデータより、モード指示子及び文字数指示子に基づいて、データコード語をセグメントに分割する（ステップＳ３０７）。最後に、仕様モードに基づいてデータ文字を復号し、結果を出力する（ステップＳ３０８）。尚、ステップＳ３０５で誤りが検出されなかった場合（Ｎｏ）は、上記ステップＳ３０７に進む。

ここで、２次元バーコード内に組み込まれたデータは、対応する電子ファイルが格納されているサーバアドレス情報（ポインタ情報）を表しており、例えばファイルサーバ名及びサーバアドレスを示すＩＰアドレス、対応するＵＲＬ等からなるパス情報で構成される。

本実施例では上述したように、ポインタ情報が２次元バーコードを用いて付与された原稿３１０を例に挙げて説明したが、直接文字列でポインタ情報が記録される場合には、所定のルールに従った文字列のブロックを前述したブロックセレクション処理で検出し、当該ポインタ情報を示す文字列の各文字を文字認識することで、直接、オリジナルの電子ファイルが保存されているサーバのサーバアドレス情報を得ることが可能である。

また、図７の文書３１０の文字ブロック３１２や文字ブロック３１３の文字列に対して、隣接する文字と文字の間隔等に視認し難い程度の変調を加え、当該文字間隔を用いた透かし情報を埋め込むことでもポインタ情報を付与することができる。このような透かし情報は、後述する文字認識処理を行う際に各文字の間隔を検出することによって、ポインタ情報を得ることができる。また、自然画ブロック３１４の中に電子透かしとしてポインタ情報を付加することも可能である。

［ポインタ情報によるファイル検索］
次に、図３を用いて説明したステップＳ１２７、Ｓ１３０の処理で行われるポインタ情報からの電子ファイルが格納されているサーバの検索処理について詳細に説明する。図８は、検出されたポインタ情報から電子ファイルが格納されているサーバを検索する処理手順について説明するためのフローチャートである。

まず、ポインタ情報に含まれるサーバアドレスに基づいて、当該電子ファイルが格納されているファイルサーバを特定する（ステップＳ４００）。ここでファイルサーバとは、クライアントＰＣ１０２や、データベース１０５ａ、ｂを内蔵する文書管理サーバ１０６ａ、ｂや、記憶装置１１１を内蔵するＭＦＰ１００自身を指す。また、アドレスとは、ＵＲＬやサーバ名からなるパス情報である。

そして、ファイルサーバを特定した後、図３を用いて説明したステップＳ１２７におけるポインタ情報が示すサーバ（ファイルサーバ）内を検索するための準備をファイルサーバに対して要求する（ステップＳ４０１）。ファイルサーバは、ステップＳ１２８のファイル検索処理に従って、該当する電子ファイルを検索する（ステップＳ４０２）。そして、電子ファイルが存在するか否かを判定する（ステップＳ４０３）。

この結果、電子ファイルが存在しない場合（Ｎｏ）は、ＭＦＰ１００に対してその旨を通知して終了する。一方、電子ファイルが存在する場合（Ｙｅｓ）は、図３を用いて前述したように、ステップＳ１２９からステップＳ１３２までの処理を行うために候補表示を行い、その後、該当する電子ファイルのアドレスを通知すると共に、当該電子ファイルをユーザ（すなわち、ＭＦＰ１００）に対して転送する（ステップＳ４０８）。

［アプリケーションの照合］
図１９は、ステップＳ１３９で行われるアプリケーション照合処理の詳細について説明するためのフローチャートである。ステップＳ１２５で検出されたポインタ情報からステップＳ１２７で電子ファイルを検索した結果、電子ファイルが存在する場合（Ｙｅｓ）、当該アプリケーション照合が行われる（ステップＳ１３９）。ここでは、検索した電子ファイルが、前述したように、アプリケーション指定・登録処理（ステップＳ１２０）において指定・登録された内容の電子ファイルであるか否か（すなわち、指定されたアプリケーション名等か否か）を判断する。図１９では、一例として、アプリケーションの拡張子の照合（ステップＳ２１０１）と、ヘッダの解析照合（ステップＳ２１０２）を挙げているが、これらの方法に限定するものではない。

そして、照合結果において、一致すると判断された場合（Ｙｅｓ）は、格納アドレスを通知して（ステップＳ１３５）、その電子ファイルの取得を行う。一方、一致しないと判断された場合（Ｎｏ）は、その電子ファイルは取得せずに入力された原稿のベクトル化を行う（ステップＳ１３１）。

［ファイル検索処理］
次に、図３のステップＳ１２８で示すファイル検索処理の詳細について図５及び図１０を使用して説明する。ステップＳ１２８の処理は、前述したように、ステップＳ１２６で入力原稿（入力ファイル）にポインタ情報が存在しなかった場合、ポインタ情報は存在するが電子ファイルが見つからなかった場合に行われる。

ここでは、ステップＳ１２０２のＯＣＲ／ＯＭＲ処理の結果、抽出された各ブロック及び入力ファイルが、図５に示す情報（ブロック情報、入力ファイル情報）を備えるものとする。本実施形態では、情報内容として、図５に示すように属性、座標位置、幅及び高さのサイズ、ＯＣＲ情報の有無を用いる。

属性は、さらに、文字、線、写真、絵、表等に分類される。尚、図５では説明を簡単にするため、ブロックは座標Ｘの小さい順（例えば、Ｘ１＜Ｘ２＜Ｘ３＜Ｘ４＜Ｘ５＜Ｘ６）に、ブロック１、ブロック２、ブロック３、ブロック４、ブロック５、ブロック６としている。また、ブロック総数は、入力ファイル中の全ブロック数であり、図５に示す例におけるブロック総数は６である。以下、これらの情報を使用して、データベース内から入力イメージファイルに類似した電子ファイルのレイアウト検索を行う手順について説明する。図１０は、データベース内から入力イメージファイルに類似した電子ファイルのレイアウト検索を行う手順について説明するためのフローチャートである。尚、データベースファイルも、図５に示す情報と同様の情報を備えることを前提とする。図１０のフローチャートの流れは、入力された原稿から読み取られた電子ファイルとデータベース中の電子ファイルを順次比較するものである。

まず、後述する類似率等の初期化を行って初期値を設定する（ステップＳ５１０）。次に、ブロック総数の比較を行い（ステップＳ５１１）、真の場合（Ｙｅｓ）は、さらにファイル内のブロックの情報を順次比較する（ステップＳ５１２）。すなわち、データベースのファイルのブロック数ｎが入力ファイルのブロック数Ｎの誤差ΔＮ範囲内かどうかを調べ、誤差範囲内であれば真（Ｙｅｓ）、範囲外であれば偽（Ｎｏ）とする。また、ステップＳ５１２では、入力ファイルとデータベースファイルのブロック属性を比較して一致すればステップＳ５１３以降の比較処理へ進み、不一致であればステップＳ５２１に進む。

ブロックの情報比較では、ステップＳ５１３、Ｓ５１５、Ｓ５１８において、それぞれ属性類似率、サイズ類似率、ＯＣＲ類似率をそれぞれ算出し、ステップＳ５２２においてそれらに基づいて総合類似率を算出する。各類似率の算出方法については、公知の技術を用いることができるので説明を省略する。

ステップＳ５２３においては、総合類似率が予め設定された閾値Ｔｈより高いかどうかを判定し、高い場合（Ｙｅｓ）は、その電子ファイルを類似候補として挙げて保存する（ステップＳ５２４）。尚、図中のＮ、Ｗ、Ｈは、入力ファイルのブロック総数、各ブロック幅、各ブロック高さ、ΔＮ、ΔＷ、ΔＨは、入力ファイルのブロック情報を基準として誤差を考慮したものである。また、ｎ、ｗ、ｈは、データベースファイルのブロック総数、各ブロック幅、各ブロック高さとする。尚、ステップＳ５１４におけるサイズ比較時に、位置情報（Ｘ，Ｙ）の比較等を行ってもよい。

以上、検索の結果、総合類似率が閾値Ｔｈより高いもので候補として保存されたデータベースファイルをサムネール等で表示する（ステップＳ１２９）。これにより、複数の中から操作者の選択が必要な場合は、操作者の入力操作よってファイルの特定を行う。

［ベクトル化処理］
ファイルサーバにオリジナルの電子ファイルが存在しない場合、又は、前述したようにステップＳ１２０のアプリケーション指定・登録処理において検索処理のＯＦＦを選択した場合は、図４に示すイメージデータを各ブロック毎にベクトル化する。以下では、図３のベクトル化処理（ステップＳ１３１）について詳細に説明する。

《文字認識》
前述したように、ステップＳ１２０のアプリケーションの指定・登録処理によってＯＣＲ処理を行うと指定した場合、文字ブロックに対しては各文字に対して文字認識処理が行われる。本実施例の文字認識処理では、文字単位で切り出された画像に対し、パターンマッチングの一手法を用いて認識を行い、対応する文字コードを得る。この認識処理は、文字画像から得られる特徴を数十次元の数値列に変換した観測特徴ベクトルと、あらかじめ字種毎に求められている辞書特徴ベクトルと比較し、最も距離の近い字種を認識結果とする処理である。尚、特徴ベクトルの抽出には種々の公知手法があり、例えば、文字をメッシュ状に分割し、各メッシュ内の文字線を方向別に線素としてカウントしたメッシュ数次元ベクトルを特徴とする方法を用いることができる。

ブロックセレクション処理（ステップＳ１２３）で抽出された文字領域に対して文字認識を行う場合、まず該当領域に対して横書き、縦書きの判定を行い、各々対応する方向に行を切り出し、その後文字を切り出して文字画像を得る。横書き、縦書きの判定は、該当領域内で画素値に対する水平／垂直の射影を取り、水平射影の分散が大きい場合は横書き領域、垂直射影の分散が大きい場合は縦書き領域と判断すればよい。

また、文字列及び文字への分解は、横書きの場合は水平方向の射影を利用して行を切り出し、さらに切り出された行に対する垂直方向の射影から、文字を切り出す。一方、縦書きの文字領域に対しては、水平と垂直を逆にすればよい。尚、文字のサイズは切り出した大きさに基づいて検出することができる。

《フォント認識》
文字認識の際に用いられる字種数分の辞書特徴ベクトルを、文字形状種、すなわちフォント種に対して複数用意し、マッチングの際に文字コードとともにフォント種を出力することで、文字のフォントを認識することができる。

《文字のベクトル化》
前述した文字認識及びフォント認識によって得られた、文字コード及びフォント情報を用いて、アウトライン化処理によるアウトラインデータを用いて、文字部分の情報をベクトルデータに変換する。尚、元原稿がカラーの場合は、カラー画像から各文字の色を抽出してベクトルデータとともに記録する。以上の処理により、文字ブロックに属するイメージ情報をほぼ形状、大きさ、色が忠実なベクトルデータに変換することができる。

《文字以外の部分のベクトル化》
ステップＳ１２３のブロックセレクション処理で、線画或いは線、表領域とされた領域を対象として、それぞれ抽出された画素塊の輪郭をベクトルデータに変換する。具体的には、輪郭を成す画素の点列を角とみなされる点で区切って、各区間を部分的な直線或いは曲線で近似する。ここで、「角」とは、曲率が極大となる点である。

図１１は、曲率が極大となる点を説明するための図である。図１１に示すように、任意点Ｐiに対して左右ｋ個の離れた点Ｐi-k〜Ｐi+kの間に弦を引いたとき、この弦とＰiの距離が極大となる点として求められる。さらに、Ｐi-k〜Ｐi+k間の弦の長さ／弧の長さをＲとし、Ｒの値が閾値以下である点を角とみなすことができる。角によって分割された後の各区間は、直線は点列に対する最小二乗法等を用いて、曲線は３次スプライン関数等を用いてベクトル化することができる。

また、対象が内輪郭を持つ場合、ブロックセレクション処理で抽出した白画素輪郭の点列を用いて、同様に部分的直線或いは曲線で近似する。

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

図１２は、外輪郭が内輪郭又は別の外輪郭と近接している場合に太さを持った線として表現する例について説明するための図である。図１２に示すように、ある区間で外輪郭が、内輪郭又は別の外輪郭が近接している場合、２つの輪郭線を一まとめにし、太さを持った線として表現することができる。具体的には、ある輪郭の各点Ｐiから別輪郭上で最短距離となる点Ｑiまで線を引き、各距離ＰＱiが平均的に一定長以下の場合、注目区間はＰＱi中点を点列として直線又は曲線で近似し、その太さはＰＱiの平均値とする。線や線の集合体である表罫線は、前記したような太さを持つ線の集合として、効率よくベクトル表現することができる。

尚、文字ブロックに対する文字認識処理を用いたベクトル化については前述したように、当該文字認識処理の結果、辞書からの距離が最も近い文字を認識結果として用いる。ここで、この距離が所定値以上の場合は、必ずしも本来の文字に一致するとは限らず、形状が類似する文字に誤認識するような場合が多い。従って、本実施例では、このような文字に対しては上記したように、一般的な線画と同様に扱って当該文字をアウトライン化する。すなわち、従来は文字認識処理で誤認識を起こしていたような文字でも、誤った文字にベクトル化されることなく、可視的にイメージデータに忠実なアウトライン化によるベクトル化を行うことができる。また、写真と判定されたブロックに対しては、本実施例ではベクトル化せずに、イメージデータのままとするか、所望の圧縮率で圧縮する。

［アプリデータへの変換処理］
図１３は、一頁分のイメージデータをブロックセレクション処理（ステップＳ１２３）及びベクトル化処理（ステップＳ１３１）によって変換された結果として得られる中間データ形式のファイルのデータ構造を示す図である。図１５に示すようなデータ形式は、ドキュメント・アナリシス・アウトプット・フォーマット（ＤＡＯＦ）と呼ばれる。すなわち、図１３は、ＤＡＯＦのデータ構造を示す図である。

図１３において、７９１はHeader（ヘッダ）であり、処理対象の文書画像データに関する情報が保持される。７９２はレイアウト記述データ部であり、文書画像データ中のTEXT（文字）、TITLE（タイトル）、CAPTION（キャプション）、LINEART（線画）、PICTURE（自然画）、FRAME（枠）、TABLE（表）等の属性毎に認識された各ブロックの属性情報とその矩形アドレス情報を保持する。

７９３は文字認識記述データ部であり、TEXT、TITLE、CAPTION等のTEXTブロックを文字認識して得られる文字認識結果を保持する。７９４は表記述データ部であり、TABLEブロックの構造の詳細を格納する。７９５は画像記述データ部であり、PICTUREやLINEART等のブロックのイメージデータを文書画像データから切り出して保持する。

このようなＤＡＯＦは、中間データとしてのみならず、それ自体がファイル化されて保存される場合もあるが、このファイルの状態では、一般の文書作成アプリケーションで個々のオブジェクトを再利用・再編集等することはできない。そこで、次に、ＤＡＯＦからアプリデータに変換する処理（ステップＳ１３２）について詳説する。

図１４は、アプリデータへの変換処理全体の概略手順を説明するためのフローチャートである。まず、ＤＡＯＦデータを入力する（ステップＳ８００）。次いで、アプリデータの元となる文書構造ツリー生成を行う（ステップＳ８０２）。そして、生成した文書構造ツリーに基づいて、ＤＡＯＦ内の実データを流し込み、実際のアプリデータを生成する（ステップＳ８０４）。

図１５は、文書構造ツリー生成処理（ステップＳ８０２）の詳細な処理手順を説明するためのフローチャートである。また、図１６は、文書構造ツリーの概要を説明するための図である。尚、全体制御の基本ルールとして、処理の流れはミクロブロック（単一ブロック）からマクロブロック（ブロックの集合体）へ移行するものとする。また、以後の説明では、ブロックとは、ミクロブロック及びマクロブロック全体を指す。

まず、ブロック単位で縦方向の関連性を元に再グループ化する（ステップＳ８０２ａ）。尚、スタート直後はミクロブロック単位での判定となる。ここで、関連性とは、距離が近く、ブロック幅（横方向の場合は高さ）がほぼ同一であること等で定義することができる。また、距離、幅、高さ等の情報はＤＡＯＦを参照して抽出する。

図１６において、（ａ）は実際のページ構成、（ｂ）はその文書構造ツリーを示している。ステップＳ８０２ａのグループ化の結果、Ｔ３、Ｔ４、Ｔ５が一つのグループＶ１として、Ｔ６、Ｔ７が一つのグループＶ２として、それぞれ同じ階層のグループとして生成される。

次に、縦方向のセパレータの有無をチェックする（ステップＳ８０２ｂ）。セパレータは、例えば、物理的にはＤＡＯＦ中でライン属性を持つオブジェクトである。また、論理的な意味としては、アプリ中で明示的にブロックを分割する要素である。ここでセパレータを検出した場合は、同じ階層で再分割する。

次いで、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する（ステップＳ８０２ｃ）。例えば、縦方向のグルーピング長がページ高さか否かを判定する。その結果、縦方向のグループ長がページ高さとなっている場合は（Ｙｅｓ）、文書構造ツリー生成は終了する。例えば、図１６に示すような構造の場合は、セパレータもなく、グループ高さはページ高さではないので、Ｎｏと判定され、ステップＳ８０２ｄに進む。

ステップＳ８０２ｄでは、ブロック単位で横方向の関連性を元に再グループ化する。但し、この再グループ化においてもスタート直後の第一回目は、ミクロブロック単位で判定を行うことになる。また、関連性及びその判定情報の定義は、縦方向の場合と同じである。例えば、図１６の構造の場合は、Ｔ１とＴ２でＨ１、Ｖ１とＶ２でＨ２が生成され、Ｈ１はＴ１、Ｔ２の一つ上、Ｈ２はＶ１、Ｖ２の１つ上の同じ階層のグループとして生成される。

次いで、横方向セパレータの有無をチェックする（ステップＳ８０２ｅ）。図１８では、Ｓ１があるので、これをツリーに登録し、Ｈ１、Ｓ１、Ｈ２という階層が生成される。そして、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する（ステップＳ８０２ｆ）。例えば、横方向のグルーピング長がページ幅か否かを判定する。その結果、横方向のグループ長がページ幅となっている場合（Ｙｅｓ）、文書構造ツリー生成は終了する。一方、ページ幅となっていない場合（Ｎｏ）は、ステップＳ８０２ｂに戻り、再度もう一段上の階層で、縦方向の関連性チェックから繰り返す。例えば、図１６の構造の場合は、分割幅がページ幅になっているので、ここで終了し、最後にページ全体を表す最上位階層のＶ０が文書構造ツリーに付加される。

文書構造ツリーが完成した後、その情報に基づいて、ステップＳ８０４においてアプリデータの生成を行う。図１６の構造の場合は、具体的に以下のようになる。

すなわち、Ｈ１は横方向に２つのブロックＴ１、Ｔ２があるので、２カラムとし、Ｔ１の内部情報（ＤＡＯＦを参照した文字認識結果の文章や画像等）を出力後、カラムを変えて、Ｔ２の内部情報出力し、その後Ｓ１を出力する。また、Ｈ２は横方向に２つのブロックＶ１、Ｖ２があるので、２カラムとして出力し、Ｖ１はＴ３、Ｔ４、Ｔ５の順にその内部情報を出力し、その後カラムを変えて、Ｖ２のＴ６、Ｔ７の内部情報を出力する。以上により、アプリデータへの変換処理を行うことができる。

尚、このアプリデータの変換は指定されたアプリケーションの種別に応じて適宜変換される。即ち、指定されたアプリケーションで用いられるオブジェクトの種別のみが含まれるようにする。例えば、指定されたアプリケーションがイメージとテキストのみを扱うものであれば、線画像、図形等があってもそれを関数近似処理した関数に置き換えるのではなく、イメージデータとして処理する。

［ポインタ情報の付加］
次に、ステップＳ１３７で示されるポインタ情報付加処理について詳細に説明する。処理すべき文書が検索処理で特定された場合、或いはベクトル化によって元ファイルが再生できた場合において、該文書を記録処理する場合においては、紙への記録の際にポインタ情報を付与することで、この文書を用いて再度各種処理を行う場合に簡単に元ファイルデータを取得できる。

図１７は、ポインタ情報としてのデータ文字列を２次元バーコード（ＱＲコードシンボル：ＪＩＳ Ｘ０５１０）３１１を用いて符号化して画像中に付加する手順を説明するためのフローチャートである。

２次元バーコード内に組み込むデータは、対応するファイルが格納されるサーバアドレス情報を表しており、例えばファイルサーバ名からなるパス情報で構成される。或いは、対応するサーバのＵＲＬや、対応するファイルが格納されているデータベース１０５ａ、ｂ内或いはＭＦＰ１００自体が有する記憶装置１１１を管理するためのＩＤ等で構成される。

まず、符号化する種種の異なる文字を識別するため、入力データ列を分析する。また、誤り検出及び誤り訂正レベルを選択し、入力データが収容できる最小型番を選択する（ステップＳ９００）。次に、入力データ列を所定のビット列に変換し、必要に応じてデータのモード（数字、英数字、８ビットバイト、漢字等)を表す指示子や、終端パターンを付加する。さらに、所定のビットコード語に変換することによってデータの符号化を行う（ステップＳ９０１）。

この時、誤り訂正を行うため、コード語列を型番及び誤り訂正レベルに応じて所定のブロック数に分割し、各ブロック毎に誤り訂正コード語を生成し、データコード語列の後に付加する（ステップＳ９０２）。さらに、ステップＳ９０２で得られた各ブロックのデータコード語を接続し、各ブロックの誤り訂正コード語、また必要に応じて剰余コード語を接続して、メッセージの構築を行う（ステップＳ９０３）。

次に、マトリックスに位置検出パターン、分離パターン、タイミングパターン及び位置合わせパターン等とともにコード語モジュールを配置する（ステップＳ９０４）。さらに、シンボルの符号化領域に対して最適なマスクパターンを選択して、マスク処理パターンをステップＳ９０４で得られたモジュールにＸＯＲ演算により変換する（ステップＳ９０５）。最後に、ステップＳ９０５で得られたモジュールに形式情報及び型番情報を生成して、２次元コードシンボルを完成させる（ステップＳ９０６）。

上述したサーバアドレス情報の組み込まれた２次元バーコードは、例えば、クライアントＰＣ１０２から電子ファイルをプリントデータとして形成装置１１２で紙上に記録画像として形成する場合に、データ処理装置１１５内で記録可能なラスタデータに変換された後にラスタデータ上の所定の個所に付加されて画像形成される。ここで、画像形成された紙を配布されたユーザは、画像読み取り部１１０で読み取ることにより、前述したステップＳ１２３においてポインタ情報からオリジナルの電子ファイルが格納されているサーバの場所を適切に検出することができる。

尚、同様の目的で付加情報を付与する手段は、本実施例で説明した２次元バーコードの他に、例えば、ポインタ情報を直接文字列で文書に付加する方法、文書内の文字列、特に文字と文字の間隔を変調して情報を埋め込む方法、文書中の中間調画像中に埋め込む方法等の一般に電子透かしと呼ばれる方法を適用してもよい。

上述したように本実施例によれば、原稿を読み取ったイメージデータからユーザが所望している（クライアント側で指定された）アプリケーションフォーマットの電子ファイルを効率良く取得することができる。

上記第１の実施例では、ユーザが予めアプリケーションの指定・登録処理（図３のステップＳ１２０）を行うことにより、ユーザが所望とするアプリケーションフォーマットの電子ファイルの取得を実現したが、本実施例においては、ポインタ情報に基づいて電子ファイルを検索した結果、検索された電子ファイルのアプリケーションフォーマットを検出し、それをユーザに通知することにより、所望とするアプリケーションフォーマットの取得の可否を問う処理の実現を可能とする。

図２０は、本発明の第２の実施例に係る画像処理システムの動作手順を説明するためのフローチャートである。なお、第１の実施例と同様のステップに関しては同一の符号を付してその説明を省略する。また、本実施例に係る画像処理システムは、上述した第１の実施例におけるものと同様である。

まず、ユーザがファイル特定を実行するか否かの設定を行う（ステップＳ１４０）。ここで、前述した第１の実施例では、アプリケーションフォーマットの指定・登録（ステップＳ１２０）を行ったが、本実施例ではそれは行わない。

その後、第１の実施例と同様の処理を行って、取得したポインタ情報からの電子ファイルの検索の結果、電子ファイルが有ると判定された場合（ステップＳ１２７でＹｅｓ）、アプリケーションフォーマットの検出を行う（ステップＳ１４１）。当該フォーマットの検出方法は、上記第１の実施例と同様の手段を用いて、拡張子の検出及びファイルヘッダの解析等によって検出する。尚、ここで当該電子ファイルに関するその他の情報（例えば、電子ファイルへのアクセス権、ファイル取得時に課金されるか否か、ファイルサイズ、ページ数、要約、内容等）をさらに検出してもよい。

次に、検出されたアプリケーションフォーマットをユーザに通知する（ステップＳ１４２）。通知方法は、ユーザが確認容易なＭＦＰ１００の操作部（ＵＩ）等への通知が望ましく、アプリケーションフォーマットだけでなく、前述したような電子ファイルに関するその他の情報（ファイルへのアクセス権、ファイル取得時に課金されるか否か、ファイルサイズ、ページ数、要約、内容等）の通知も併せて行ってもよい。

そして、当該電子ファイルを取得するか否かをユーザに問う（ステップＳ１４３）。以下、ユーザが取得すると判断した場合は電子ファイルの取得を行い、そうでなければ入力原稿のベクトル化を行い、作成されたベクトルデータを取得するようにする。

次に、ファイルアクセス権について考慮した実施例について説明する。通常扱われる文書ファイルの中には、第三者による再利用を制限することが望ましい文書がある。前述した実施例では、ファイルサーバに蓄積された電子ファイルは全て自由にアクセスすることが可能であり、ファイル全体、或いはその一部のオブジェクトは全て再利用が可能なことを前提に説明した。以下では、ポインタ情報から電子ファイルを検索した際に、検索の結果から特定された電子ファイルにアクセス権の制限が有る場合について説明する。

図９は、ファイルアクセス権を含むポインタ情報から電子ファイルが格納されているサーバを検索する処理手順について説明するためのフローチャートである。図９において、ステップＳ４００〜Ｓ４０３までは、図８におけるステップと同様であるため、説明は省略する。ステップＳ４０３で電子ファイルが特定された場合（Ｙｅｓ）、ファイルサーバはそのファイルのアクセス権情報を調べる（ステップＳ４０４）。その結果、アクセス制限がある場合（Ｙｅｓ）は、ＭＦＰ１００に対してパスワードの送信を要求する（ステップＳ４０５）。

そして、ＭＦＰ１００は、操作者に対してパスワードの入力を促し、入力されたパスワードをファイルサーバに送信する（ステップＳ４０６）。ファイルサーバは送信されたパスワードを照合し（ステップＳ４０７）、一致した場合（Ｙｅｓ）は、図３を用いて説明したように、電子ファイルのアドレスを通知すると共に、ユーザの希望する処理がイメージデータの取得であれば、ＭＦＰ１００に対して電子ファイルを転送する（ステップＳ４０８）。

尚、アクセス権の制御を行うための認証の方法は、ステップＳ４０５、Ｓ４０６に示したパスワードによる方法に限定されず、例えば、指紋認証等の一般に広く用いられている生体認証、カードによる認証等のあらゆる認証情報を用いた認証手段を用いることができる。

また、本実施例では、紙文書に付加的に付与されたポインタ情報によりファイルを特定した場合の例について説明したが、図３のステップＳ１２８〜Ｓ１３０で示す検索処理によってファイルを特定した場合においても同様の制御が可能である。

一方、ステップＳ４０３でファイルサーバ内からファイルを特定することができなかった場合は、図３のステップＳ１３１で説明したベクトル化処理に対しても、制限を加えることができる。すなわち、紙文書を走査して得られたイメージデータからオリジナルの電子ファイルに対してのアクセス権の制限の存在を検出した場合には、認証確認が取れた場合のみベクトル化処理を行うことで、機密性の高い文書の使用に制限をかけることができる。

前述した実施例では、原稿画像を走査して得られるイメージ情報からサーバが保存するオリジナルのファイルデータを特定する手段としては、図３に示すように、文書中に付与されたポインタ情報に従って特定する手段か、文書中に記載された各オブジェクト情報に従って検索して特定する手段のいずれかであった。これに対し、より正確にオリジナルの電子ファイルを特定するには、上述した両手段を併用すれば良い。

すなわち、原稿画像中から得られるポインタ情報から元ファイルの存在が検出できた場合であっても、さらに当該文書中のオブジェクト情報を使って、例えば、レイアウト情報に従うレイアウト検索や文字認識されたキーワードによる全文検索を検出されたファイルに対して行う。そして、高い一致度が得られた場合に当該検出された電子ファイルを、正式にオリジナルのファイルであると特定するようにする。このようにすることにより、例えば、ポインタ情報の下位の部分が曖昧であったり、誤り訂正でも訂正できなかった場合に対して、検索の範囲を絞り込んでファイルを特定することができるので、より高速で確実な電子ファイルの特定を行うことが可能となる。

以上、実施形態例を詳述したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。

尚、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラム（実施形態では図に示すフローチャートに対応したプログラム）を、システムあるいは装置に直接あるいは遠隔から供給し、そのシステムあるいは装置のコンピュータが該供給されたプログラムコードを読み出して実行することによっても達成される場合を含む。

従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明は、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。

その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等の形態であっても良い。

プログラムを供給するための記録媒体としては、例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などがある。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページから本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される他、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。

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

本発明の第１の実施例に係る画像処理システムの構成を示すブロック図である。 本発明の第１の実施例に係るＭＦＰ１００の構成を示すブロック図である。 本発明の第１の実施例に係る画像処理システムによる画像処理の手順について説明するためのフローチャートである。 ブロックセレクション処理によって読み取った１枚のイメージデータを属性を判定し複数のブロックに分割する様子を示す図である。 ブロックセレクション処理で得られた各ブロックに対するブロック情報の一例について示す図である。 原稿画像中に付加された２次元バーコード（ＱＲコードシンボル）を復号してデータ文字列を出力する手順を説明するためのフローチャートである。 ２次元バーコードが付加された原稿３１０の一例を示す図である。 検出されたポインタ情報から電子ファイルが格納されているサーバを検索する処理手順について説明するためのフローチャートである。 ファイルアクセス権を含むポインタ情報から電子ファイルが格納されているサーバを検索する処理手順について説明するためのフローチャートである。 データベース内から入力イメージファイルに類似した電子ファイルのレイアウト検索を行う手順について説明するためのフローチャートである。 曲率が極大となる点を説明するための図である。 外輪郭が内輪郭又は別の外輪郭と近接している場合に太さを持った線として表現する例について説明するための図である。 一頁分のイメージデータをブロックセレクション処理及びベクトル化処理によって変換された結果として得られる中間データ形式のファイルのデータ構造を示す図である。 アプリデータへの変換処理全体の概略手順を説明するためのフローチャートである。 文書構造ツリー生成処理の詳細な処理手順を説明するためのフローチャートである。 文書構造ツリーの概要を説明するための図である。 ポインタ情報としてのデータ文字列を２次元バーコードを用いて符号化して画像中に付加する手順を説明するためのフローチャートである。 アプリケーション指定・登録処理（ステップＳ１２０）の手順を詳細に説明するためのフローチャートである。 ステップＳ１３９で行われるアプリケーション照合処理の詳細について説明するためのフローチャートである。 本発明の第２の実施例に係る画像処理システムの動作手順を説明するためのフローチャートである。

符号の説明

１００ デジタル複合機（ＭＦＰ）
１０１ マネージメントＰＣ
１０２ クライアントＰＣ
１０３ａ、１０３ｂ プロキシサーバ
１０４ ネットワーク
１０５ａ、１０５ｂ データベース
１０６ａ、１０６ｂ 文書管理サーバ
１０７、１０８、１０９ ＬＡＮ
１１０ 画像読み取り部
１１１ 記憶装置
１１２ 形成装置
１１３ 入力装置
１１４、１１７ ネットワークＩ／Ｆ
１１５ データ処理装置
１１６ 表示装置

Claims (27)

1. サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理システムであって、
   所定のアプリケーションフォーマットを指定する指定手段と、
   原稿を読み取ってイメージ情報を取得する読取手段と、
   前記読取手段で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定手段と、
   前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
   前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
   前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
   前記読取手段で取得された前記イメージ情報を、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
   前記特定手段により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定手段により指定されたアプリケーションフォーマットであるか否かを照合する照合手段と、
   前記特定手段で前記電子ファイルが特定されなかった場合、又は前記照合手段により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換手段により得られたデータを、前記照合手段により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力手段と
   を備えることを特徴とする画像処理システム。
2. 前記照合手段により照合された前記電子ファイルが前記指定手段で指定された前記アプリケーションフォーマットでない場合、前記変換手段は、前記読取手段で取得された前記イメージ情報を変換し、
   前記出力手段は、前記変換手段で得られたデータを出力する
   ことを特徴とする請求項１に記載の画像処理システム。
3. 前記特定手段が、前記イメージ情報から前記原稿中に付加されている該原稿に対応する電子ファイルの格納場所を示す情報を認識することによって、該電子ファイルを特定することを特徴とする請求項１又は２に記載の画像処理システム。
4. 前記特定手段が、前記イメージ情報から前記原稿中に埋め込まれている所定情報に基づいて前記サーバが保持する電子ファイルの中から前記原稿に対応する電子ファイルを特定することを特徴とする請求項１又は２に記載の画像処理システム。
5. 前記変換手段によって得られたデータを所定の格納場所に格納する格納手段と、
   前記変換手段で得られたデータが格納された格納場所に関する情報を付加情報として生成する生成手段と、
   前記付加情報と前記変換手段で得られたデータとを所定媒体上に形成する形成手段と
   をさらに備えることを特徴とする請求項１又は２に記載の画像処理システム。
6. 前記ベクトル化手段が、
   前記読取手段で取得された前記イメージ情報に対してアウトライン化を行うアウトライン化手段と、
   アウトライン化された前記イメージ情報に関するアウトラインデータに基づいて、該イメージ情報の直線近似、曲線近似又は図形近似を行う関数近似手段と
   を備えることを特徴とする請求項１又は２に記載の画像処理システム。
7. 前記文字処理手段が、
   原稿中の文字を文字認識処理する文字認識手段と、
   前記文字認識手段による文字認識処理結果に基づいて前記文字を文字種に応じた文字コードと対応付けられたフォントデータに置き換えるフォント化手段と
   を備えることを特徴とする請求項１又は２に記載の画像処理システム。
8. 前記変換手段が、前記イメージ情報を複数のオブジェクトに分割し、それぞれのオブジェクトを、その属性に応じて独立に処理することを特徴とする請求項１又は２に記載の画像処理システム。
9. 前記変換手段が、属性に応じて変換された前記オブジェクトを所定のアプリケーションで取り扱い可能なフォーマットに変換するフォーマット変換手段をさらに備えることを特徴とする請求項８に記載の画像処理システム。
10. 前記変換手段で得られたデータを所定の格納場所に格納する格納手段と、
    前記変換手段で得られたデータが格納された格納場所に関する情報を付加情報として生成する生成手段と、
    前記付加情報をユーザに通知する通知手段と
    をさらに備えることを特徴とする請求項１又は２に記載の画像処理システム。
11. 前記特定手段が、前記読取手段によって取得された前記原稿のイメージ情報を複数のオブジェクトに分割し、それぞれのオブジェクトのレイアウト情報を取得し、該レイアウト情報と前記原稿に付加されている前記情報とを用いて、該原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定することを特徴とする請求項３に記載の画像処理システム。
12. 前記原稿に対応する電子ファイルの有無に関わらず、前記特定手段による電子ファイルの特定処理を実行させるか否かを選択する選択手段をさらに備えることを特徴とする請求項１又は２に記載の画像処理システム。
13. 前記指定手段が、前記アプリケーションフォーマットのアプリケーション名、アプリケーション拡張子、又はファイルフォーマットの少なくともいずれか１つを含むファイル識別情報を指定することを特徴とする請求項１又は２に記載の画像処理システム。
14. 前記照合手段が、前記電子ファイルのファイル拡張子又はファイルヘッダの解析により照合を行うことを特徴とする請求項１又は２に記載の画像処理システム。
15. サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理システムであって、
    原稿を読み取ってイメージ情報を取得する読取手段と、
    前記読取手段で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定手段と、
    前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
    前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
    前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
    前記読取手段で取得された前記イメージ情報を、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
    前記特定手段により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルのアプリケーションフォーマットを検出する検出手段と、
    前記検出手段により検出された前記アプリケーションフォーマットを前記クライアントに通知する通知手段と、
    前記特定手段で前記ファイルが特定されなかった場合又は前記検出手段により前記電子ファイルのアプリケーションフォーマットが検出されなかった場合は前記変換手段により得られたデータを、前記検出手段により前記電子ファイルのアプリケーションフォーマットを検出した場合は検出されたデータを選択的に出力する出力手段と
    を備えることを特徴とする画像処理システム。
16. 前記特定手段によって特定された前記電子ファイルにアクセス制限があるか否かを判定する判定手段と、
    アクセス制限がある場合、前記電子ファイルに対するアクセスの可否を認証する認証手段と、
    前記認証手段により前記電子ファイルに対するアクセスが認証された場合、前記電子ファイルに対するアクセスを許可する許可手段と
    をさらに備えることを特徴とする請求項１、２又は１５に記載の画像処理システム。
17. 前記判定手段によりアクセス制限があると判定された場合、前記クライアントに対して認証情報の入力を要求する要求手段と、
    前記クライアントで入力された認証情報を取得する取得手段とをさらに備え、
    前記認証手段が、前記取得手段により取得された前記認証情報に基づいてアクセスの可否を認証する
    ことを特徴とする請求項１６に記載の画像処理システム。
18. サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理装置であって、
    所定のアプリケーションフォーマットを指定する指定手段と、
    原稿を読み取ってイメージ情報を取得する読取手段と、
    前記読取手段で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定手段と、
    前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
    前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
    前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
    前記読取手段で取得された前記イメージ情報を、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
    前記特定手段により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定手段により指定されたアプリケーションフォーマットであるか否かを照合する照合手段と、
    前記特定手段で前記電子ファイルが特定されなかった場合、又は前記照合手段により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換手段により得られたデータを、前記照合手段により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力手段と
    を備えることを特徴とする画像処理装置。
19. サーバが保持する電子ファイルの中から指定された原稿に対応する電子ファイルを検索し、検索された電子ファイルを出力する画像処理方法であって、
    所定のアプリケーションフォーマットを指定する指定工程と、
    原稿を読み取ってイメージ情報を取得する読取工程と、
    前記読取工程で取得された前記イメージ情報から、前記原稿に対応する電子ファイルを前記サーバが保持する電子ファイルの中から特定する特定工程と、
    前記読取工程で取得された前記イメージ情報を文字コード化する文字処理工程と、
    前記読取工程で取得された前記イメージ情報をベクトルデータに変換するベクトル化工程と、
    前記読取工程で取得された前記イメージ情報を所定の画像形式に変換する画像変換工程と、
    前記読取工程で取得された前記イメージ情報を、その属性に応じて前記文字処理工程、前記ベクトル化工程、前記画像変換工程の少なくともいずれかを用いて変換する変換工程と、
    前記特定工程により前記原稿に対応する電子ファイルが特定できた場合、該電子ファイルが前記指定工程により指定されたアプリケーションフォーマットであるか否かを照合する照合工程と、
    前記特定工程で前記電子ファイルが特定されなかった場合、又は前記照合工程により前記電子ファイルが前記アプリケーションフォーマットでないと照合された場合は前記変換工程により得られたデータを、前記照合工程により前記電子ファイルが前記アプリケーションフォーマットであると照合された場合は該電子ファイルを選択的に出力する出力工程と
    を有することを特徴とする画像処理方法。
20. 所定のアプリケーションフォーマットを指定する指定手段と、
    原稿を読み取ってイメージ情報を取得する読取手段と、
    前記読取手段で取得された前記イメージ情報を文字コード化する文字処理手段と、
    前記読取手段で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
    前記読取手段で取得された前記イメージ情報を所定の画像形式に変換する画像変換手段と、
    前記指定手段で指定されたアプリケーションフォーマットに基づき前記読取手段で取得された前記イメージデータを、その属性に応じて前記文字処理手段、前記ベクトル化手段、前記画像変換手段の少なくともいずれかを用いて変換する変換手段と、
    前記変換手段により得られたデータを出力する出力手段と
    を備えることを特徴とする画像処理装置。
21. 前記変換手段は、前記読取手段で取得されたイメージ情報を、その属性に応じて複数のオブジェクトに分割し、それぞれのオブジェクトを独立に処理することを特徴とする請求項２０に記載の画像処理装置。
22. 前記ベクトル化手段は、
    前記読取手段で取得されたイメージ情報に対してアウトライン化を行うアウトライン化手段と、
    アウトライン化されたイメージ情報に関するアウトラインデータに基づいて該イメージ情報の直線近似、曲線近似又は図形近似を行う関数近似手段と
    を備えることを特徴とする請求項２０又は２１に記載の画像処理装置。
23. 前記文字処理手段は、
    原稿中の文字を認識する文字認識手段と、
    前記文字認識手段による文字認識処理結果に基づいて当該文字を文字種に応じた文字コードと対応付けられたフォントデータに置き換えるフォント化手段と
    を備えることを特徴とする請求項２０又は２１に記載の画像処理装置。
24. 前記画像変換手段は、前記読取手段で取得されたイメージ情報を所定の圧縮方式で圧縮することを特徴とする請求項２０又は２１に記載の画像処理装置。
25. 所定のアプリケーションフォーマットを指定する指定工程と、
    原稿を読み取ってイメージ情報を取得する読取工程と、
    前記読取工程で取得された前記イメージ情報を文字コード化する文字処理手段と、
    前記読取工程で取得された前記イメージ情報をベクトルデータに変換するベクトル化手段と、
    前記読取工程で取得された前記イメージ情報を所定の画像形式に変換する画像変換工程と、
    前記指定工程で指定されたアプリケーションフォーマットに基づき前記読取工程で取得された前記イメージデータを、その属性に応じて前記文字処理手段、前記ベクトル化工程、前記画像変換工程の少なくともいずれかを用いて変換する変換工程と、
    前記変換工程により得られたデータを出力する出力工程と
    を有することを特徴とする画像処理方法。
26. コンピュータに、所定のアプリケーションフォーマットを指定する指定手順と、
    原稿を読み取りイメージ情報を取得する読取手順と、
    前記読取手順で取得された前記イメージ情報を文字コード化する文字処理手順と、
    前記読取手順で取得された前記イメージ情報をベクトルデータに変換するベクトル化手順と、
    前記読取手順で取得された前記イメージ情報を所定の画像形式に変換する画像変換手順と、
    前記指定手順で指定されたアプリケーションフォーマットに基づき前記読取手順で取得された前記イメージデータを、その属性に応じて前記文字処理手順、前記ベクトル化手順、前記画像変換手順の少なくともいずれかを用いて変換する変換手順と、
    前記変換手順により得られたデータを出力する出力手順と
    を実行させるためのプログラム。
27. 請求項２６に記載のプログラムを格納したことを特徴とするコンピュータ読み取り可能な記録媒体。

Images