(57)【要約】【課題】  ・矩形領域指定においては、対象となる領域の複雑性に対処不可能である。・非矩形領域指定においては、指定処理あるいは装置に対する負荷が大きい。・閉領域指定においては、原稿によってマーカー色に制限が生じ、誤差を無くすための調整が容易でない。という旨の課題である。【解決手段】編集の対象となる領域の選択が、原稿上で異なる特徴を持った領域を単位として指定されるであろうことを想定し、簡便にして必要十分な複雑性に対応する領域指定方法を提供する。【選択図】  図１
2005174079.tif 000002
【特許請求の範囲】
【請求項１】
原稿を読み取り走査する読み取り手段と、
読み取り手段で得られた画像情報をオブジェクト毎に分割する分割手段と、
読み取り手段で得られた画像情報を領域毎に編集する編集手段と、
領域を指定する領域指定手段とを備え、
前記領域指定手段が、
領域の座標を指定する第一の指定手段と、
指定されたオブジェクトの座標を領域とみなす第二の指定手段と、
第一の指定手段と第二の指定手段のどちらを使用するかを選択する選択手段を備えることを特徴とする画像処理装置。
【請求項２】
前記第二の指定手段が、指定された点を含むオブジェクトの座標を領域とみなすことを特徴とする請求項１記載の画像処理装置。
【請求項３】
前記第二の指定手段が、指定された種類のオブジェクトの座標を領域とみなすことを特徴とする請求項１記載の画像処理装置。
【請求項４】
前記第二の指定手段によって複数のオブジェクトが指定された場合、すべてのオブジェクトを領域とみなすことを特徴とする請求項１記載の画像処理装置。
【請求項５】
前記第二の指定手段によって複数のオブジェクトが指定された場合、それらの中から選択させるオブジェクト選択手段を備えることを特徴とする請求項１記載の画像処理装置。
【請求項６】
分割手段によって分割されたオブジェクト毎に、オブジェクトの属性を決定する属性決定手段を備えることを特徴とする請求項１記載の画像処理装置。
【請求項７】
読み取り手段で得られた画像情報から原稿の電子ファイルを特定する特定手段と、
特定手段で原稿の電子ファイルを特定できない場合に、読み取り手段で得られる画像情報をベクトルデータに変換するベクトル化手段を備え、
前記編集手段は、電子ファイルの画像情報あるいはベクトルデータに変換された画像情報に対して編集処理を行うことを特徴とする請求項１記載の画像処理装置。
【請求項８】
前記特定手段は原稿に付加的に記録された電子ファイルの格納場所を認識する手段を含むことを特徴とする第７項記載の画像処理装置。
【請求項９】
前記特定手段は原稿中に記載された特定の情報を記憶手段で格納されたファイルの中から検索する手段を有することを特徴とする第７項記載の画像処理装置。
【請求項１０】
前記ベクトル化手段は原稿中の文字をOCRするOCR手段を含むことを特徴とする第７項記載の画像処理装置。
【請求項１１】
前記ベクトル化手段は原稿を複数のオブジェクトに分割し、各オブジェクトに対して独立にベクトル化することを特徴とする第７項記載の画像処理装置。
【請求項１２】
前記ベクトル化手段はベクトル化されたオブジェクトを既存の文書作成ソフトで扱える既定フォーマットに変換するフォーマット変換手段を含むことを特徴とする第７項記載の画像処理装置。
【請求項１３】
前記ベクトル化手段でベクトル化されたベクトルデータを記憶する画像記憶手段と、
該ベクトルデータに該データを格納する格納場所を付加情報として付加する情報付加手段を備えることを特徴とする第７項記載の画像処理装置。
【請求項１４】
前記特定手段は電子ファイルから原稿中に記載された特定の情報が得られる場合に限って、該電子ファイルに特定することを特徴とする第７項記載の画像処理装置。
【請求項１５】
読み取り手段で得られた画像情報から原稿の電子ファイルを特定する特定手段と、
特定手段で特定された電子ファイルがオブジェクト単位で既存の文書作成ソフトで扱えない場合に、読み取り手段で得られる画像情報をベクトルデータに変換するベクトル化手段を備え、
前記編集手段は電子ファイルの画像情報あるいはベクトルデータに変換された画像情報に対して編集処理を行うことを特徴とする請求項１記載の画像処理装置。
【請求項１６】
前記ベクトル化手段は原稿を読み取り走査して得られる画像情報をオブジェクト毎に分割する手段と、
該分割されたオブジェクト単位で記憶手段に格納されたファイルの中から一致するオブジェクトを検索する手段を有し、
該検索手段で得られた情報を用いてベクトル化することを特徴とする第７項記載の画像処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複写機などの画像処理装置で読み取った画像データに対する編集処理において、編集の対象となる領域を特定可能な画像処理装置に関する。
【背景技術】
【０００２】
従来、原稿中の領域を特定して編集作業を行う場合、廉価なシステムにおいては２点指定による矩形領域指定、高価なシステムにおいては連続点指定による非矩形領域指定、カラフルでない原稿に対してはマーカー指定による閉領域指定等の手段があった。（例えば、特許文献１参照）
【特許文献１】特開昭63-285685号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
しかしながら上記列挙した手段においては、以下のような課題があった。
すなわち、
・矩形領域指定においては、対象となる領域の複雑性に対処不可能である。
・非矩形領域指定においては、指定処理あるいは装置に対する負荷が大きい。
・閉領域指定においては、原稿によってマーカー色に制限が生じ、誤差を無くすための調整が容易でない。
という旨の課題である。
【課題を解決するための手段】
【０００４】
上記課題を解決するため、本発明においては、編集の対象となる領域の選択が、原稿上で異なる特徴を持った領域を単位として指定されるであろうことを想定し、簡便にして必要十分な複雑性に対応する領域指定方法を提供する。
【０００５】
請求項１記載の発明は、原稿を読み取る読み取り手段で得られた画像情報をオブジェクト毎に分割する手段を有し、このオブジェクトを指定することでオブジェクトの占める領域を編集対象領域とする第二の指定手段を持つ。これにより、１点の指定でオブジェクトを指定することで、領域の形状の複雑性によらず、領域指定が可能となる。
【０００６】
請求項２記載の発明は、１点の座標指定によって分割されたオブジェクトの一つを特定することで領域指定を可能とする。
【０００７】
請求項３記載の発明は、分割の元となる属性等の指定によってオブジェクトを指定することで領域指定を可能とする。
【０００８】
請求項４記載の発明は、請求項２の記載で複数の点の座標を指定した場合、あるいは請求項３の記載で指定された属性のオブジェクトが複数存在する場合、複数のオブジェクトの指定を有効とし、複数領域の指定を可能とする。
【０００９】
請求項５記載の発明は、請求項４記載の発明と対照で、複数のオブジェクトの中から少なくとも一つのオブジェクトを再選択することを可能とする。
【００１０】
請求項６記載の発明は、オブジェクト分割手段において、請求項３記載の発明で私用するようなオブジェクト毎の属性を決定することを可能とする。
【００１１】
請求項７記載の発明は、領域に対する編集処理を実行する際に、元の原稿の画像情報ではなく、ベクトル化された画像情報に対して編集処理を実行することで、編集処理の効果や精度を高くすることを可能とする。
【００１２】
請求項８記載の発明は、原稿の画像情報をベクトル化したデータを電子ファイルに求める際に、原稿に付加された格納場所を認識することで電子ファイルを容易に検索することを可能とする。
【００１３】
請求項９記載の発明は、電子ファイル特定手段が原稿中に記載された特定の情報を記憶手段で格納されたファイルの中から検索する手段を有し、検索の結果、特定情報の一致によって電子ファイルを特定する事で、付加情報が記録されていない文書に対しても容易にオリジナルの電子ファイルを特定出来る。
【００１４】
請求項１０記載の発明は、ベクトル化手段は原稿中の文字領域を光学的文字認識するOCR手段によって文字部分を文字フォントデータにベクトル化することで、文字部を高品位に保つことを可能とする。
【００１５】
請求項１１記載の発明は、ベクトル化されたオブジェクトを独立に扱う事により、編集の効率を高くすることを可能とする。
【００１６】
請求項１２記載の発明は、ベクトル化手段はベクトル化されたオブジェクトを既存の文書作成ソフトで扱える例えばリッチ・テキスト・フォーマットに変換するので、ベクトル化したオブジェクトを既存の文書作成アプリソフト上で再利用することを可能とする。
【００１７】
請求項１３記載の発明は、該文書を再度原稿として画像読み取り手段で読み取った際には、この付加情報から電子ファイルを特定する事を可能とする。
【００１８】
請求項１４記載の発明は、元の電子ファイルの特定にあたって、単にポインター情報から特定する場合に対してより確度の高い特定を可能とする。
【００１９】
請求項１５記載の発明は、前記特定手段で得られた該原稿の電子ファイルがイメージファイルやPDFの様にオブジェクト単位で既存の文書作成ソフトウエアーで扱えない場合にも、前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする為イメージファイルに対しても再利用可能なベクトルデータに変換することを可能とする。
【００２０】
請求項１６記載の発明は、全てのオブジェクトに対するベクトル化を不要とすることで、処理の高速化および高画質化を可能とする。
【発明の効果】
【００２１】
請求項１記載の発明は、原稿を読み取る読み取り手段で得られた画像情報をオブジェクト毎に分割する手段を有し、このオブジェクトを指定することでオブジェクトの占める領域を編集対象領域とする第二の指定手段を持つ。これにより、１点の指定でオブジェクトを指定することで、領域の形状の複雑性によらず、領域指定が可能となる。
【００２２】
請求項２記載の発明は、１点の座標指定によって分割されたオブジェクトの一つを特定することで領域指定を可能とする。
【００２３】
請求項３記載の発明は、分割の元となる属性等の指定によってオブジェクトを指定することで領域指定を可能とする。
【００２４】
請求項４記載の発明は、請求項２の記載で複数の点の座標を指定した場合、あるいは請求項３の記載で指定された属性のオブジェクトが複数存在する場合、複数のオブジェクトの指定を有効とし、複数領域の指定を可能とする。
【００２５】
請求項５記載の発明は、請求項４記載の発明と対照で、複数のオブジェクトの中から少なくとも一つのオブジェクトを再選択することを可能とする。
【００２６】
請求項６記載の発明は、オブジェクト分割手段において、請求項３記載の発明で私用するようなオブジェクト毎の属性を決定することを可能とする。
【００２７】
請求項７記載の発明は、領域に対する編集処理を実行する際に、元の原稿の画像情報ではなく、ベクトル化された画像情報に対して編集処理を実行することで、編集処理の効果や精度を高くすることを可能とする。
【００２８】
請求項８記載の発明は、原稿の画像情報をベクトル化したデータを電子ファイルに求める際に、原稿に付加された格納場所を認識することで電子ファイルを容易に検索することを可能とする。
【００２９】
請求項９記載の発明は、電子ファイル特定手段が原稿中に記載された特定の情報を記憶手段で格納されたファイルの中から検索する手段を有し、検索の結果、特定情報の一致によって電子ファイルを特定する事で、付加情報が記録されていない文書に対しても容易にオリジナルの電子ファイルを特定出来る。
【００３０】
請求項１０記載の発明は、ベクトル化手段は原稿中の文字領域を光学的文字認識するOCR手段によって文字部分を文字フォントデータにベクトル化することで、文字部を高品位に保つことを可能とする。
【００３１】
請求項１１記載の発明は、ベクトル化されたオブジェクトを独立に扱う事により、編集の効率を高くすることを可能とする。
【００３２】
請求項１２記載の発明は、ベクトル化手段はベクトル化されたオブジェクトを既存の文書作成ソフトで扱える例えばリッチ・テキスト・フォーマットに変換するので、ベクトル化したオブジェクトを既存の文書作成アプリソフト上で再利用することを可能とする。
【００３３】
請求項１３記載の発明は、該文書を再度原稿として画像読み取り手段で読み取った際には、この付加情報から電子ファイルを特定する事を可能とする。
【００３４】
請求項１４記載の発明は、元の電子ファイルの特定にあたって、単にポインター情報から特定する場合に対してより確度の高い特定を可能とする。
【００３５】
請求項１５記載の発明は、前記特定手段で得られた該原稿の電子ファイルがイメージファイルやPDFの様にオブジェクト単位で既存の文書作成ソフトウエアーで扱えない場合にも、前記画像読み取り走査手段で得られるイメージ情報をベクトル化手段でベクトルデータに変換する事を特徴とする為  イメージファイルに対しても再利用可能なベクトルデータに変換することを可能とする。
【００３６】
請求項１６記載の発明は、全てのオブジェクトに対するベクトル化を不要とすることで、処理の高速化および高画質化を可能とする。
【発明を実施するための最良の形態】
【００３７】
本発明の実施の形態について説明する。
【００３８】
図１は本発明にかかる画像処理装置構成例を示すブロック図である。
【００３９】
この画像処理装置は、オフィス１０とオフィス２０がインターネット１０４で接続された環境で実現する。
【００４０】
オフィス１０内に構築されたＬＡＮ１０７には、ＭＦＰ１００、ＭＦＰ１００を制御する管理ＰＣ１０１、クライアントＰＣ（外部記憶手段）１０２、文書管理サーバ１０６、そのデータベース１０５、およびプロキシサーバ１０３が接続されている。
【００４１】
ＬＡＮ１０７およびオフィス２０内のＬＡＮ１０８はプロキシサーバ１０３を介してインターネット１０４に接続される。
【００４２】
ＭＦＰ１００は本発明において紙文書の画像読み取り部と読み取った画像信号に対する画像処理の一部を担当し、画像信号はＬＡＮ１０９を用いて管理ＰＣ１０１に入力する。
【００４３】
管理ＰＣは通常のＰＣであり、内部に画像記憶手段、画像処理手段、表示手段、入力手段を有するが、その一部をＭＦＰ１００に一体化して構成されている。
【００４４】
図２はＭＦＰ１００の構成図である。
【００４５】
図２においてオートドキュメントフィーダ（以降ＡＤＦと記す）を含む画像読み取り部１１０は束状のあるいは１枚の原稿画像を図示しない光源で照射し、原稿反射像をレンズで固体撮像素子上に結像し、固体撮像素子からラスター状の画像読み取り信号を６００ＤＰＩの密度のイメージ情報として得る。
【００４６】
通常の複写機能はこの画像信号をデータ処理部１１５で記録信号へ画像処理し、複数毎複写の場合は記録装置１１１に一旦１ページ分の記録データを記憶保持した後、記録装置１１２に順次出力して紙上に画像を形成する。
【００４７】
一方クライアントＰＣ１０２から出力されるプリントデータはＬＡＮ１０７からネットワークＩＦ１１４を経てデータ処理装置１１５で記録可能なラスターデータに変換した後、前記記録装置で紙上に記録画像として形成される。
【００４８】
ＭＦＰ１００への操作者の指示はＭＦＰに装備されたキー操作部と管理ＰＣに入力されるキーボードおよびマウスからなる入力装置１１３から行われ、これら一連の動作はデータ処理装置１１５内の図示しない制御部で制御される。
【００４９】
一方、操作入力の状態表示および処理中の画像データの表示は表示装置１１６で行われる。
【００５０】
尚、記録装置１１１は管理ＰＣからも制御され、これらＭＦＰと管理ＰＣとのデータの授受および制御はネットワークＩＦ１１７および直結したＬＡＮ１０９を用いて行われる。
【００５１】
次に本発明による画像処理全体の概要を図３を用いて説明する。
【００５２】
図３においてまず、ＭＦＰ１００の画像読み取り部１１０を動作させ１枚の原稿をラスター状に走査し、イメージ情報入力処理１２０で６００ＤＰＩ−８ビットの画像信号を得る。
【００５３】
該画像信号をデータ処理部１１５で前処理を施し記録装置１１１に１ページ分の画像データとして保存する。
【００５４】
管理ＰＣ１０１のＣＰＵは該格納された画像信号から、まず文字／線画部分とハーフトーンの画像部分とに領域を分離し、文字部はさらに段落で塊として纏まっているブロック毎に、あるいは、線で構成された表、図形に分離し各々セグメント化する。
【００５５】
一方ハーフトーンで表現される画像部分は、矩形に分離されたブロックの画像部分、背景部等、いわゆるブロック毎に独立したオブジェクトに分割する（ステップ１２１）。
【００５６】
このとき原稿画像中に付加情報として記録された２次元バーコード、あるいはＵＲＬに該当するオブジェクトを検出し、ＵＲＬはＯＣＲで文字認識し、あるいは２次元バーコードなら該マークを解読して（ステップ１２２）該原稿のオリジナル電子ファイルが格納されている記録装置内のポインター情報を検出する（ステップ１２３）。
【００５７】
尚、ポインター情報を付加する手段は他に文字と文字の間隔に情報を埋め込む方法、ハーフトーンの画像に埋め込む方法等直接可視化されないいわゆる電子透かしによる方法もある。
【００５８】
ポインター情報が検出された場合、ステップ１２５に分岐し、ポインターで示されたアドレスから元の電子ファイルを検索する。
【００５９】
電子ファイルは図１においてクライアントＰＣ内のハードディスク内、あるいはオフィス１０あるいは２０のＬＡＮに接続された文書管理サーバ１０５内のデータベース１０５内、あるいはＭＦＰ１００自体が有する記憶装置１１１のいずれかに格納されており、ステップ１２３で得られたアドレス情報に従ってこれらの記憶装置内を検索する。
【００６０】
ステップ１２５で電子ファイルが見つからなかった場合、あるいはポインター情報自体が存在しなかった場合はステップ１２６に分岐する。
【００６１】
ステップ１２６はいわゆる文書検索処理ルーチンである。
【００６２】
まずステップ１２２で各文字ブロックに対して行ったＯＣＲの結果から単語を抽出して全文検索、あるいは各オブジェクトの配列と各オブジェクトの属性からいわゆるレイアウト検索を行う。
【００６３】
検索の結果、類似度の高い電子ファイルが見つかった場合、サムネイル等を表示（ステップ１２７）し、複数の中から操作者の選択が必要なら走者者の入力操作によってファイルの特定を行う。
【００６４】
尚、候補が１ファイルの場合、自動的にステップ１２８からステップ１３４に分岐し、格納アドレスを通知する。
【００６５】
ステップ１２６の検索処理で電子ファイルが見つからなかった場合、あるいは見つかったがＰＤＦあるいはＴＩＦＦに代表されるいわゆるイメージファイルであった場合、ステップ１２９に分岐する。
【００６６】
ステップ１２９はイメージデータからベクトルデータへの変換処理部であり、オリジナル電子ファイルに近い電子ファイルに変換する。
【００６７】
まずステップ１２２でＯＣＲされた文字ブロックに対しては、さらに文字のサイズ、スタイル、字体を認識し、原稿を走査して得られた文字に可視的に忠実なフォントデータに変換する。
【００６８】
一方、線で構成される表、図形ブロックに対してはアウトライン化する。
【００６９】
画像ブロックに対してはイメージデータとして個別のＪＰＥＧファイルとして処理する。
【００７０】
これらのベクトル化処理は各オブジェクト毎に行い、さらに各オブジェクトのレイアウト情報を保存して例えばＲＴＦに変換(ステップ１３０)して電子ファイルとして記憶装置１１１に格納（ステップ１３１）する。
【００７１】
今ベクトル化した原稿画像は以降同様の処理を行う際に直接電子ファイルとして検索できるように、まずステップ１３２において検索のためのインデックス情報を生成して検索用インデックスファイルに追加する。
【００７２】
さらに、ステップ１３４で今操作者が行いたい処理が記録であると判断されれば、ステップ１３５に分岐し、ポインター情報をイメージデータとしてファイルに付加する。
【００７３】
検索処理で電子ファイルが特定できた場合も同様に以降からは直接電子ファイルを特定するためにステップ１２８からステップ１３３に分岐し、格納アドレスを操作者に通知すると共に、今紙に記録する場合は、同様にポインター情報を電子ファイルに付加する。
【００７４】
尚ステップ１２５でポインター情報から電子ファイルが特定できた場合、検索処理で電子ファイルが特定できた場合、ベクトル化により電子ファイルに変換した場合、ステップ１３３において該電子ファイルの格納アドレスを操作者に通知する。
【００７５】
以上、本発明によって得られた電子ファイル自体を用いて例えば文書の加工、蓄積、伝送、記録をステップ１３６で行うことが可能になる。
【００７６】
これらの処理はイメージデータを用いる場合に比べて、情報量が削減されて蓄積効率が高まり、伝送時間が短縮され、また記録表示する際には高品位なデータとして非常に優位となる。
【００７７】
以下、各処理ブロックに関して説明する。
【００７８】
まずステップ１２１で示すブロックセレクション処理について説明する。
【００７９】
（ブロックセレクション処理）
ブロックセレクション処理とは、図４の右に示すステップ１２０で読み取った１ページのイメージデータを左に示す様に、オブジェクト毎の塊として認識し、該ブロック各々を文字／図画／写真／線／表等の属性に判定し、異なる属性を持つ領域に分割する処理である。
【００８０】
ブロックセレクション処理の実施例を以下に説明する。
【００８１】
先ず、入力画像を白黒に二値化し、輪郭線追跡をおこなって黒画素輪郭で囲まれる画素の塊を抽出する。
【００８２】
面積の大きい黒画素の塊については、内部にある白画素に対しても輪郭線追跡をおこない白画素の塊を抽出、さらに一定面積以上の白画素の塊の内部からは再帰的に黒画素の塊を抽出する。
【００８３】
このようにして得られた黒画素の塊を、大きさおよび形状で分類し、異なる属性を持つ領域へ分類していく。
【００８４】
たとえば、縦横比が１に近く、大きさが一定の範囲のものを文字相当の画素塊とし、さらに近接する文字が整列良くグループ化可能な部分を文字領域、扁平な画素塊を線領域、一定大きさ以上でかつ四角系の白画素塊を整列よく内包する黒画素塊の占める範囲を表領域、不定形の画素塊が散在している領域を写真領域、それ以外の任意形状の画素塊を図画領域、などとする。
【００８５】
ブロックセレクション処理で得られた各ブロックに対するブロック情報を図５に示す。
【００８６】
これらのブロック毎の情報は以降に説明するベクトル化、或いは検索の為の情報として用いる。
【００８７】
（ポインター情報の検出）
次に、ステップ１２２で示すファイルの格納位置をイメージ情報から抽出する為のＯＣＲ／ＯＭＲ処理について説明する。
【００８８】
図６は原稿画像中に付加された２次元バーコード(ＱＲコードシンボル)を復号して、データ文字列を出力する過程を示すフローチャートである。
【００８９】
２次元バーコードの付加された原稿３１０の一例を図７に示す。
【００９０】
まず、データ処理装置１１５内のページメモリに格納された原稿３１０を表すイメージ画像をＣＰＵ(不図示)で走査して、先に説明したブロックセレクション処理の結果から所定の２次元バーコードシンボル３１１の位置を検出する。
【００９１】
ＱＲコードの位置検出パターンは、シンボルの４隅のうちの３隅に配置される同一の位置検出要素パターンから構成される （ステップ３００）。
【００９２】
次に、位置検出パターンに隣接する形式情報を復元し、シンボルに適用されている誤り訂正レベルおよびマスクパターンを得る（ステップ３０１）。
【００９３】
シンボルの型番を決定した（ステップ３０２）後、形式情報で得られたマスクパターンを使って符号化領域ビットパターンをＸＯＲ演算することによってマスク処理を解除する（ステップ３０３）。
【００９４】
尚、モデルに対応する配置規則に従い、シンボルキャラクタを読取り、メッセージのデータ及び誤り訂正コード語を復元する（ステップ３０４）。
【００９５】
復元されたコード上に、誤りがあるかどうかの検出を行い（ステップ３０５）、誤りが検出された場合、ステップ３０６に分岐し、これを訂正する。
【００９６】
誤り訂正されたデータより、モード指示子および文字数指示子に基づいて、データコード語をセグメントに分割する（ステップ３０７）。
【００９７】
最後に、仕様モードに基づいてデータ文字を復号し、結果を出力する（ステップ３０８）。
【００９８】
尚、２次元バーコード内に組み込まれたデータは、対応するファイルのアドレス情報を表しており、例えばファイルサーバ名およびファイル名からなるパス情報で構成される。
【００９９】
或いは、対応するファイルへのＵＲＬで構成される。
【０１００】
本実施例ではポインター情報が２次元バーコードを用いて付与された原稿３１０について説明したが、直接文字列でポインター情報が記録される場合は所定のルールに従った文字列のブロックを先のブロックセレクション処理で検出し、該  ポインター情報を示す文字列の各文字を文字認識する事で、直接元ファイルのアドレス情報を得る事が可能である。
【０１０１】
又或いは図７の文書３１０の文字ブロック３１２、或いは３１３の文字列に対して隣接する文字と文字の間隔等に視認し難い程度の変調を加え、該文字間隔に情報を埋め込むことでもポインター情報を付与できる。
【０１０２】
いわゆる透かし情報は、後述する文字認識処理を行う際に各文字の間隔を検出すれば、ポインター情報が得られる。
【０１０３】
又、自然画３１４の中に電子透かしとしてポインター情報を付加する事も可能である。
【０１０４】
（ポインター情報によるファイル検索）
次に、図３で先に説明したステップ１２５およびステップ１２８で示す、ポインター情報からの電子ファイルの検索について図８のフローチャートを使用して説明する。
【０１０５】
まず、ポインタ情報に含まれるアドレスに基づいて、ファイルサーバを特定する。（ステップ４００）。
【０１０６】
ここでファイルサーバとは、クライアントＰＣ１０２や、データベース１０５を内蔵する文書管理サーバ１０６や、記憶装置１１１を内蔵するＭＦＰ１００自身を指す。
【０１０７】
ここでアドレスとは、ＵＲＬや、サーバ名とファイル名からなるパス情報である。
【０１０８】
ファイルサーバが特定できたら、ファイルサーバに対してアドレスを転送する。（ステップ４０１）。
【０１０９】
ファイル・サーバは、アドレスを受信すると、該当するファイルを検索する（ステップ４０２）。
【０１１０】
ファイルが存在しない場合（ステップ４０３−Ｎ）には、ＭＦＰに対してその旨通知する。
【０１１１】
ファイルが存在した場合（ステップ４０３−Ｙ）には、図３で説明した様に、ファイルのアドレスを通知（ステップ１３４）すると共に、ユーザの希望する処理が画像ファイルデータの取得であれば、ＭＦＰに対してファイルを転送する。（ステップ４０８）
（ファイル検索処理）
次に、図３のステップ１２６で示すファイル検索処理の詳細について図５、図１０を使用して説明を行う。
【０１１２】
ステップ１２６の処理は、前述したように、ステップ１２４で入力原稿にポインタ情報が存在しなかった場合、または、ポインタ情報は在るが電子ファイルが見つからなかった場合、或いは電子ファイルがイメージファイルであった場合に行われる。
【０１１３】
ここでは、ステップ１２２の結果、抽出された各ブロック及び入力ファイルが、図５に示す情報（ブロック情報、入力ファイル情報）を備えるものとする。
情報内容として、属性、座標位置、幅と高さのサイズ、ＯＣＲ情報有無を例としてあげる。
【０１１４】
属性は、文字、線、写真、絵、表その他に分類する。
【０１１５】
また簡単に説明を行うため、ブロックは座標Ｘの小さい順（例、Ｘ１＜Ｘ２＜Ｘ３＜Ｘ４＜Ｘ５＜Ｘ６）にブロック１、ブロック２、ブロック３、ブロック４、ブロック５、ブロック６と名前をつけている。
【０１１６】
ブロック総数は、入力ファイル中の全ブロック数であり、図１０の場合は、ブロック総数は６である。
【０１１７】
以下、これらの情報を使用して、データベース内から、入力ファイルに類似したファイルのレイアウト検索を行うフローチャートを図１０に示す。
【０１１８】
ここで、データベースファイルは、図５と同様の情報を備えることを前提とする。
【０１１９】
フローチャートの流れは、入力ファイルとデータベース中のファイルを順次比較するものである。
【０１２０】
まず、ステップ５１０にて、後述する類似率などの初期化を行う。
次に、ステップ５１１にてブロック総数の比較を行い、ここで、真の場合、さらにファイル内のブロックの情報を順次比較する。
【０１２１】
ブロックの情報比較では、ステップ５１３、５１５、５１８にて、属性類似率、サイズ類似率、ＯＣＲ類似率をそれぞれ算出し、ステップ５２２にてそれらをもとに総合類似率を算出する。
【０１２２】
各類似率の算出方法については、公知の技術が用いられるので説明を省略する。
ステップ５２３にて総合類似率が、予め設定された閾値Ｔｈより高ければステップ５２４にてそのファイルを類似候補としてあげる。
【０１２３】
但し、図中のＮ、Ｗ、Ｈは、入力ファイルのブロック総数、各ブロック幅、各ブロック高さとし、ΔＮ、ΔＷ、ΔＨは、入力ファイルのブロック情報を基準として誤差を考慮したものである。
【０１２４】
ｎ、ｗ、ｈは、データベースファイルのブロック総数、各ブロック幅、各ブロック高さとする。
【０１２５】
また、不図示ではあるが、ステップ５１４にてサイズ比較時に、位置情報ＸＹの比較などを行ってもよい。
【０１２６】
以上、検索の結果  類似度が閾値Ｔｈより高く、候補として保存されたデータベースファイル（ステップ５２４）をサムネイル等で表示（ステップ１２７）する。
【０１２７】
複数の中から操作者の選択が必要なら操作者の入力操作よってファイルの特定を行う。
【０１２８】
（ベクトル化処理）
ファイルサーバーに元ファイルが存在しない場合は、図４に示すイメージデータを各ブロック毎にベクトル化する。
【０１２９】
次に、図３のステップ１２９で示されるベクトル化について詳説する。
【０１３０】
まず、文字ブロックに対しては各文字に対して文字認識処理を行う。
【０１３１】
『文字認識』
文字認識部では、文字単位で切り出された画像に対し、パターンマッチの一手法を用いて認識を行い、対応する文字コードを得る。
【０１３２】
この認識処理は、文字画像から得られる特徴を数十次元の数値列に変換した観測特徴ベクトルと、あらかじめ字種毎に求められている辞書特徴ベクトルと比較し、最も距離の近い字種を認識結果とする処理である。
【０１３３】
特徴ベクトルの抽出には種々の公知手法があり、たとえば、文字をメッシュ状に分割し、各メッシュ内の文字線を方向別に線素としてカウントしたメッシュ数次元ベクトルを特徴とする方法がある。
【０１３４】
ブロックセレクション（ステップ１２１）で抽出された文字領域に対して文字認識を行う場合は、まず該当領域に対し横書き、縦書きの判定をおこない、各々対応する方向に行を切り出し、その後文字を切り出して文字画像を得る。
【０１３５】
横書き、縦書きの判定は、該当領域内で画素値に対する水平/垂直の射影を取り、水平射影の分散が大きい場合は横書き領域、垂直射影の分散が大きい場合は縦書き領域と判断すればよい。
【０１３６】
文字列および文字への分解は、横書きならば水平方向の射影を利用して行を切り出し、さらに切り出された行に対する垂直方向の射影から、文字を切り出すことでおこなう。
【０１３７】
縦書きの文字領域に対しては、水平と垂直を逆にすればよい。
【０１３８】
尚、この時文字のサイズが検出出来る。
【０１３９】
『フォント認識』
文字認識の際に用いる、字種数ぶんの辞書特徴ベクトルを、文字形状種すなわちフォント種に対して複数用意し、マッチングの際に文字コードとともにフォント種を出力することで、文字のフォントが認識出来る。
【０１４０】
『文字のベクトル化』
前記文字認識およびフォント認識よって得られた、文字コードおよびフォント情報を用いて、各々あらかじめ用意されたアウトラインデータを用いて、文字部分の情報をベクトルデータに変換する。
【０１４１】
尚、元原稿がカラーの場合は、カラー画像から各文字の色を抽出してベクトルデータとともに記録する。
【０１４２】
以上の処理により文字ブロックに属するイメージ情報をほぼ形状、大きさ、色が忠実なベクトルデータに変換出来る。
【０１４３】
『文字以外の部分のベクトル化』
ブロックセレクション処理（ステップ１２１）で、図画あるいは線、表領域とされた領域を対象に、中で抽出された画素塊の輪郭をベクトルデータに変換する。
具体的には、輪郭をなす画素の点列を角と看倣される点で区切って、各区間を部分的な直線あるいは曲線で近似する。
【０１４４】
角とは曲率が極大となる点であり、曲率が極大となる点は、図１１に図示するように、任意点Ｐｉに対し左右ｋ個の離れた点Ｐｉ−ｋ、Ｐｉ＋ｋの間に弦を引いたとき、この弦とＰｉの距離が極大となる点として求められる。
【０１４５】
さらに、Ｐｉ−ｋ、Ｐｉ＋ｋ間の弦の長さ／弧の長さをＲとし、Ｒの値が閾値以下である点を角とみなすことができる。
【０１４６】
角によって分割された後の各区間は、直線は点列に対する最小二乗法など、曲線は３次スプライン関数などを用いてベクトル化することができる。
【０１４７】
また、対象が内輪郭を持つ場合、ブロックセレクションで抽出した白画素輪郭の点列を用いて、同様に部分的直線あるいは曲線で近似する。
【０１４８】
以上のように、輪郭の区分線近似を用いれば、任意形状の図形のアウトラインをベクトル化することができる。
【０１４９】
元原稿がカラーの場合は、カラー画像から図形の色を抽出してベクトルデータとともに記録する。
【０１５０】
さらに、図１２に示す様に、ある区間で外輪郭と、内輪郭あるいは別の外輪郭が近接している場合、２つの輪郭線をひとまとめにし、太さを持った線として表現することができる。
【０１５１】
具体的には、ある輪郭の各点Ｐｉから別輪郭上で最短距離となる点Ｑｉまで線を引き、各距離ＰＱｉが平均的に一定長以下の場合、注目区間はＰＱｉ中点を点列として直線あるいは曲線で近似し、その太さはＰＱｉの平均値とする。
【０１５２】
線や線の集合体である表罫線は、前記のような太さを持つ線の集合として効率よくベクトル表現することができる。
【０１５３】
尚、先に文字ブロックに対する文字認識処理を用いたベクトル化の説明をした中において、該文字認識処理の結果、辞書からの距離が最も近い文字を認識結果として用いるが、この距離が所定値以上の場合は、必ずしも本来の文字に一致せず、形状が類似する文字に誤認識している場合が多い。
【０１５４】
従って本発明では、この様な文字に対しては、上記した様に、一般的な線画と同じに扱い、該文字をアウトライン化する。
【０１５５】
即ち、従来、文字認識処理で誤認識を起こす文字に対しても、誤った文字にベクトル化されず、可視的にイメージデータに忠実なアウトライン化によるベクトル化が行える。
【０１５６】
又、写真と判定されたブロックに対しては本発明では、ベクトル化出来ない為、イメージデータのままとする。
【０１５７】
（図形認識）
上述したように任意形状の図形のアウトラインをベクトル化した後、これらベクトル化された区分線を図形オブジェクト毎にグループ化する処理について説明する。
【０１５８】
図１３は、ベクトルデータを図形オブジェクト毎にグループ化するまでのフローチャートを示している。
【０１５９】
まず、各ベクトルデータの始点、終点を算出する（７００）。
【０１６０】
次に各ベクトルの始点、終点情報を用いて、図形要素を検出する（７０１）。
【０１６１】
図形要素の検出とは、区分線が構成している閉図形を検出することである。
【０１６２】
検出に際しては、閉形状を構成する各ベクトルはその両端にそれぞれ連結するベクトルを有しているという原理を応用し、検出を行う。
【０１６３】
次に図形要素内に存在する他の図形要素、もしくは区分線をグループ化し、一つの図形オブジェクトとする（７０２）。
【０１６４】
また、図形要素内に他の図形要素、区分線が存在しない場合は図形要素を図形オブジェクトとする。
【０１６５】
図１４は、図形要素を検出するフローチャートを示している。
【０１６６】
先ず、ベクトルデータより両端に連結していない不要なベクトルを除去し、閉図形構成ベクトルを抽出する（７１０）。
【０１６７】
次に閉図形構成ベクトルの中から該ベクトルの始点を開始点とし、時計回りに順にベクトルを追っていく。
【０１６８】
開始点に戻るまで行い、通過したベクトルを全て一つの図形要素を構成する閉図形としてグループ化する（７１１）。
【０１６９】
また、閉図形内部にある閉図形構成ベクトルも全てグループ化する。
さらにまだグループ化されていないベクトルの始点を開始点とし、同様の処理を繰り返す。
【０１７０】
最後に、７１０で除去された不要ベクトルのうち、７１１で閉図形としてグループ化されたベクトルに接合しているものを検出し一つの図形要素としてグループ化する（７１２）。
【０１７１】
以上によって図形ブロックを個別に再利用可能な個別の図形オブジェクトとして扱う事が可能になる。
【０１７２】
（アプリデータへの変換処理）
ところで、一頁分のイメージデータをブロックセレクション処理（ステップ１２１）し、ベクトル化処理（ステップ１２９）した結果は図１５に示す様な中間データ形式のファイルとして変換されているが、このようなデータ形式はドキュメント・アナリシス・アウトプット・フォーマット（ＤＡＯＦ）と呼ばれる。
【０１７３】
図１５はＤＡＯＦのデータ構造を示す図である。
【０１７４】
図１５において、７９１はＨｅａｄｅｒであり、処理対象の文書画像データに関する情報が保持される。
【０１７５】
レイアウト記述データ部７９２では、文書画像データ中のＴＥＸＴ（文字）、ＴＩＴＬＥ（タイトル）、ＣＡＰＴＩＯＮ（キャプション）、ＬＩＮＥＡＲＴ（線画）、ＥＰＩＣＴＵＲＥ（自然画）、ＦＲＡＭＥ（枠）、ＴＡＢＬＥ（表）等の属性毎に認識された各ブロックの属性情報とその矩形アドレス情報を保持する。
【０１７６】
文字認識記述データ部７９３では、ＴＥＸＴ、ＴＩＴＬＥ、ＣＡＰＴＩＯＮ等のＴＥＸＴブロックを文字認識して得られる文字認識結果を保持する。
【０１７７】
表記述データ部７９４では、ＴＡＢＬＥブロックの構造の詳細を格納する。
【０１７８】
画像記述データ部７９５は、ＰＩＣＴＵＲＥやＬＩＮＥＡＲＴ等のブロックのイメージデータを文書画像データから切り出して保持する。
【０１７９】
このようなＤＡＯＦは、中間データとしてのみならず、それ自体がファイル化されて保存される場合もあるが、このファイルの状態では、所謂一般の文書作成アプリケーションで個々のオブジェクトを再利用する事は出来ない。
【０１８０】
そこで、次にこのＤＡＯＦからアプリデータに変換する処理（ステップ１３０）について詳説する。
【０１８１】
図１６は、全体の概略フローである。
【０１８２】
８０００は、ＤＡＯＦデータの入力を行う。
【０１８３】
８００２は、アプリデータの元となる文書構造ツリー生成を行う。
【０１８４】
８００４は、文書構造ツリーを元に、ＤＡＯＦ内の実データを流し込み、実際のアプリデータを生成する。
【０１８５】
図１７は、８００２文書構造ツリー生成部の詳細フロー、図１８は、文書構造ツリーの説明図である。
【０１８６】
全体制御の基本ルールとして、処理の流れはミクロブロック（単一ブロック）からマクロブロック（ブロックの集合体）へ移行する。
【０１８７】
以後ブロックとは、ミクロブロック、及びマクロブロック全体を指す。
【０１８８】
８１００は、ブロック単位で縦方向の関連性を元に再グループ化する。
【０１８９】
スタート直後はミクロブロック単位での判定となる。
【０１９０】
ここで、関連性とは、距離が近い、ブロック幅（横方向の場合は高さ）がほぼ同一であることなどで定義することができる。
【０１９１】
また、距離、幅、高さなどの情報はＧＡＯＦを参照し、抽出する。
【０１９２】
図１８（ａ）は実際のページ構成、（ｂ）はその文書構造ツリーである。
【０１９３】
８１００の結果、Ｔ３、Ｔ４、Ｔ５が一つのグループＶ１、Ｔ６、Ｔ７が一つのグループＶ２が同じ階層のグループとしてまず生成される。
【０１９４】
８１０２は、縦方向のセパレータの有無をチェックする。
【０１９５】
セパレータは、例えば物理的にはＤＡＯＦ中でライン属性を持つオブジェクトである。
【０１９６】
また論理的な意味としては、アプリ中で明示的にブロックを分割する要素である。
【０１９７】
ここでセパレータを検出した場合は、同じ階層で再分割する。
【０１９８】
８１０４は、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する。
【０１９９】
ここで、縦方向のグループ長がページ高さとなっている場合は、文書構造ツリー生成は終了する。
【０２００】
図１８の場合は、セパレータもなく、グループ高さはページ高さではないので、８１０６に進む。
【０２０１】
８１０６は、ブロック単位で横方向の関連性を元に再グループ化する。
【０２０２】
ここもスタート直後の第一回目はミクロブロック単位で判定を行うことになる。
【０２０３】
関連性、及びその判定情報の定義は、縦方向の場合と同じである。
【０２０４】
図１８の場合は、Ｔ１、Ｔ２でＨ１、Ｖ１、Ｖ２でＨ２、がＶ１、Ｖ２の１つ上の同じ階層のグループとして生成される。
【０２０５】
８１０８は、横方向セパレータの有無をチェックする。
【０２０６】
図１８では、Ｓ１があるので、これをツリーに登録し、Ｈ１、Ｓ１、Ｈ２という階層が生成される。
【０２０７】
８１１０は、分割がこれ以上存在し得ないか否かをグループ長を利用して判定する。
【０２０８】
ここで、横方向のグループ長がページ幅となっている場合は、文書構造ツリー生成は終了する。
【０２０９】
そうでない場合は、８１０２に戻り、再びもう一段上の階層で、縦方向の関連性チェックから繰り返す。
【０２１０】
図１８の場合は、分割幅がページ幅になっているので、ここで終了し、最後にページ全体を表す最上位階層のＶ０が文書構造ツリーに付加される。
【０２１１】
文書構造ツリーが完成した後、その情報を元に８００６においてアプリデータの生成を行う。
【０２１２】
図１８の場合は、具体的には、以下のようになる。
【０２１３】
すなわち、Ｈ１は横方向に２つのブロックＴ１とＴ２があるので、２カラムとし、Ｔ１の内部情報（ＤＡＯＦを参照、文字認識結果の文章、画像など）を出力後、カラムを変え、Ｔ２の内部情報出力、その後Ｓ１を出力となる。
【０２１４】
Ｈ２は横方向に２つのブロックＶ１とＶ２があるので、２カラムとして出力、Ｖ１はＴ３、Ｔ４、Ｔ５の順にその内部情報を出力、その後カラムを変え、Ｖ２のＴ６、Ｔ７の内部情報を出力する。
【０２１５】
以上によりアプリデータへの変換処理が行える。
【０２１６】
（ポインター情報の付加）
次に、ステップ１３５で示す、ポインター情報付加処理について説明する。
【０２１７】
今、処理すべき文書が検索処理で特定された場合、あるいはベクトル化によって元ファイルが再生できた場合において、該文書を記録処理する場合においては、紙への記録の際にポインター情報を付与する事で、この文書を用いて再度各種処理を行う場合に簡単に元ファイルデータを取得できる。
【０２１８】
図１９はポインター情報としてのデータ文字列を２次元バーコード（ＱＲコードシンボル：ＪＩＳ  Ｘ０５１０）３１１にて符号化して画像中に付加する過程を示すフローチャートである。
【０２１９】
２次元バーコード内に組み込むデータは、対応するファイルのアドレス情報を表しており、例えばファイルサーバ名およびファイル名からなるパス情報で構成される。
【０２２０】
或いは、対応するファイルへのＵＲＬや、対応するファイルの格納されているデータベース１０５内あるいはＭＦＰ１００自体が有する記憶装置内で管理されるファイルＩＤ等で構成される。
【０２２１】
まず、符号化する種種の異なる文字を識別するため、入力データ列を分析する。
また、誤り検出及び誤り訂正レベルを選択し、入力データが収容できる最小型番を選択する。(ステップ９００)。
【０２２２】
次に、入力データ列を所定のビット列に変換し、必要に応じてデータのモード（数字、英数字、８ビットバイト、漢字等）を表す指示子や、終端パターンを付加する。
【０２２３】
さらに所定のビットコード語に変換する。（ステップ９０１）。
【０２２４】
この時、誤り訂正を行うため、コード語列を型番および誤り訂正レベルに応じて所定のブロック数に分割し、各ブロック毎に誤り訂正コード語を生成し、データコード語列の後に付加する（ステップ９０２）。
【０２２５】
該ステップ９０２で得られた各ブロックのデータコード語を接続し、各ブロックの誤り訂正コード語、必要に応じて剰余コード語を後続する。（ステップ９０３)。
【０２２６】
次に、マトリクスに位置検出パターン、分離パターン、タイミングパターンおよび位置合わせパターン等とともにコード語モジュールを配置する。（ステップ９０４）。
【０２２７】
更に、シンボルの符号化領域に対して最適なマスクパターンを選択して、マスク処理パターンをステップ９０４で得られたモジュールにＸＯＲ演算により変換する （ステップ９０５)。
【０２２８】
最後に、ステップ９０５で得られたモジュールに形式情報および型番情報を生成して、２次元コードシンボルを完成する。（ステップ９０６）。
【０２２９】
上記に説明した、アドレス情報の組み込まれた２次元バーコードは、例えば、クライアントPC１０２から電子ファイルをプリントデータとして記録装置１１２に紙上に記録画像として形成する場合に、データ処理装置１１５内で記録可能なラスターデータに変換された後にラスターデータ上の所定の個所に付加されて画像形成される。
【０２３０】
ここで画像形成された紙を配布された使用者は、画像読取り部１１０で読み取ることにより、前述したステップ１２３にてポインター情報からオリジナル電子ファイルの格納場所を検出することができる。
【０２３１】
尚、同様の目的で付加情報を付与する手段は、本実施例で説明した２次元バーコードの他に、例えば、ポインター情報を直接文字列で文書に付加する方法、文書内の文字列、特に文字と文字の間隔を変調して情報を埋め込む方法、文書中の中間調画像中に埋め込む方法等、一般に電子透かしと呼ばれる方法が適用出来る。
【０２３２】
（領域指定）
図２０に領域指定方法の選択を示すフローを表す。
【０２３３】
２００１で表したのは、従来の指定方法と本発明による指定方法との分岐である。
【０２３４】
従来の指定方法には、２００４で示すマーカー処理による領域指定と、２００５に示すデジタイザでの座標入力による領域指定とがあり、２００２で表す「デジタイザを使用するか否か」で分岐する。
【０２３５】
本発明による領域指定には、２００６で示すデジタイザでの座標入力による領域指定と、２００７で示す属性入力による領域指定とがあり、２００３で表す「座標入力によるか否か」で分岐する。
【０２３６】
２００４のマーカー処理および２００５のデジタイザ入力による座標指定方法は既知であるため説明を省略する。
【０２３７】
２００６で示すデジタイザ入力によるオブジェクト指定は、まずデジタイザで入力された座標を含むオブジェクトを検索する。
【０２３８】
これは例えば、図５のブロック情報で示される、座標Ｘ、座標Ｙ、幅Ｗ、高さＨで示される矩形内に、デジタイザで入力された座標が含まれるか否かを判断することで可能である。
【０２３９】
もしデジタイザで入力された座標を内包するブロックがあった場合、そのブロックを指定された領域とみなす。
【０２４０】
簡便のため、本発明はブロック情報を矩形として管理しているが、非矩形であっても構わないのはもちろんである。
【０２４１】
２００７で示す属性入力によるオブジェクト指定は、操作部等により、領域として指定したいオブジェクトの属性を入力する。
【０２４２】
これは例えば、図５のブロック情報で示される属性と同一であるかを判断することで可能である。
【０２４３】
いずれの処理においても複数の領域を指定可能であるが、これらをそのまま選択したり、あるいはその中から少なくとも一つの領域を指定することが考えられる。
【０２４４】
このような処理を行うのが２００８で示される後処理である。
【０２４５】
（ファイルアクセス権に関する別実施例）
我々が扱う文書ファイルの中には、第三者による再利用を制限すべき物がある。
【０２４６】
先の実施例ではファイルサーバに蓄積されたファイルは全て自由にアクセス出来、ファイル全体、或いはその一部のオブジェクトは全て再利用が可能な事を前提に説明した。
【０２４７】
そこで、先の実施例でポインター情報からファイルを検索した際に、検索の結果、特定出来たファイルにアクセス権の制限が有る場合についての別実施例を図９を用いて説明する。
【０２４８】
ステップ４０３までは先の実施例と同様の為説明は省略する。
【０２４９】
ファイルが特定された場合、ファイルサーバはそのファイルのアクセス権情報を調べ、アクセス制限がある場合（ステップ４０４)には、ＭＦＰに対してパスワードの送信を要求する（ステップ４０５）。
【０２５０】
ＭＦＰは操作者に対してパスワードの入力を促し、入力されたパスワードをファイルサーバに送信する（ステップ４０６）。
【０２５１】
ファイルサーバは送信されたパスワードを照合し、一致した場合には（ステップ４０７）
図３で説明した様に、ファイルのアドレスを通知（ステップ１３４）すると共に、ユーザの希望する処理が画像ファイルデータの取得であれば、ＭＦＰに対してファイルを転送する（ステップ４０８）。
【０２５２】
尚、アクセス権の制御を行う為の認証の方法は、ステップ４０５、４０６に示したパスワードによる方法に限定されず、例えば、指紋認証等の一般に広く用いられている生体認証、カードによる認証等、全ての認証手段を用いる事が出来る。
【０２５３】
又、本別実施例では紙文書に付加的に付与されたポインター情報によりファイルを特定した場合の実施例を示したが、図３ステップ１２６−１２８で示す、いわゆる検索処理でファイルを特定した場合においても同様の制御が可能である。
【０２５４】
一方、ファイルサーバ内からファイルを特定出来なかった場合、即ち図３のステップ１２９−１３２で説明したベクトル化処理に対しても、制限を加える事が出来る。
【０２５５】
即ち紙文書を走査して得られたイメージ情報から該文書に対してのアクセス権の制限の存在を検出した場合には、認証確認が取れた場合のみベクトル化処理を行う事で、機密性の高い文書の使用に制限をかける事が出来る。
【０２５６】
（ファイル特定に関する別実施例）
先の実施例では原稿走査して得られるイメージ情報から元ファイルデータを特定する手段は、図３に示す様に、文書中に付与されたポインター情報に従う手段か、或いは文書中に記載された各オブジェクト情報に従う検索手段のいずれかに依るが、より正確に元ファイルを特定するには、該両手段を併用すれば良い。
【０２５７】
即ち、原稿中から得られるポインター情報から元ファイルの存在が検出出来たとしても、更に該文書中のオブジェクト情報を使って、例えば、レイアウト情報に従うレイアウト検索、文字認識されたキーワードによる全文検索を検出されたファイルに対して行い、高い一致が得られた場合に該検出したファイルを、正式に元ファイルであると特定する。
【０２５８】
これは、例えば、ポインター情報の下位の部分が曖昧だったり、誤り訂正でも訂正できなかった場合に対して、検索の範囲を絞り込んでファイルを特定出来る為、より高速で、確度の高いファイル特定が行える。
【０２５９】
（ベクトル化の別実施例）
先の実施例では検索手段で、元ファイルの特定が出来ない場合、イメージ画像全体に対してベクトル化処理を行うが、例えば、一般の文書の場合、文書中のオブジェクト全て新規に作成された物でなく、一部のオブジェクトは他のファイルから流用して作成される場合がある。
【０２６０】
例えば、背景オブジェクト（壁紙）は文書作成アプリケーションで幾つかのパターンを予め用意してあり、その中から選択して用いるのが通常である。
【０２６１】
従ってこのようなオブジェクトは文書ファイルデータベースの中の他の文書ファイル中に存在している可能性が高く、又  再利用可能なベクトルデータとして存在する可能性が高い。
【０２６２】
従ってこのような背景から、図３のベクトル化処理１２９の別実施例として、ブロックセレクション処理で個別のオブジェクトに分割された各オブジェクトに対して該オブジェクト単位でデータベース中から該一致するオブジェクトを一部に含むファイルを検索し、一致したオブジェクトに対して個別に該ファイルからオブジェクト単位でベクトルデータを取得する。
【０２６３】
これに依って、文書全体をベクトル化する必要が無くなり、より高速にベクトル化出来、更にベクトル化による画質劣化を防止出来る。
【０２６４】
一方、図３において検索処理１２６−１２８で元ファイルがＰＤＦとして特定できた場合、該ＰＤＦがその文書の文字オブジェクトに対して既に文字認識された文字コードを付加ファイルとして有している場合がある。
【０２６５】
このようなＰＤＦファイルをベクトル化する際には、該文字コードファイルを用いれば、１２９以降のベクトル化処理の中の文字認識処理を省く事が出来る。
【０２６６】
即ちベクトル化処理をより高速に処理する事が可能に成る。
【図面の簡単な説明】
【０２６７】
【図１】画像処理装置構成例を示すブロック図である。
【図２】ＭＦＰの構成図である。
【図３】ＭＦＰの画像処理全体の概要フローである。
【図４】ブロックセレクションを説明する図である。
【図５】ブロックセレクションで得られたブロック情報である。
【図６】２次元バーコードを出コードするフローである。
【図７】２次元バーコードが付与された原稿を示す図である。
【図８】ポインター情報から電子ファイルを検索するフローである。
【図９】図８にファイルアクセス権の制御を加えたフローである。
【図１０】ファイル検索処理の詳細を示すフローである。
【図１１】ベクトル化で曲率が極大となる点を示す図である。
【図１２】ベクトル化で２つの輪郭線をまとめる図である。
【図１３】ベクトルデータを図形オブジェクト毎にグループ化するフローである。
【図１４】図形要素を検出するフローである。
【図１５】ＤＡＯＦのデータ構造を示す図である。
【図１６】ＤＡＯＦをアプリデータへ変換するフローである。
【図１７】文書構造ツリー生成部の詳細フローである。
【図１８】文書構造ツリーの説明図である。
【図１９】ポインター情報を符号化して付加するフローである。
【図２０】領域指定方法の選択を示すフローである。
【図１】
2005174079.tif 000003
【図２】
2005174079.tif 000004
【図３】
2005174079.tif 000005
【図４】
2005174079.tif 000006
【図５】
2005174079.tif 000007
【図６】
2005174079.tif 000008
【図７】
2005174079.tif 000009
【図８】
2005174079.tif 000010
【図９】
2005174079.tif 000011
【図１０】
2005174079.tif 000012
【図１１】
2005174079.tif 000013
【図１２】
2005174079.tif 000014
【図１３】
2005174079.tif 000015
【図１４】
2005174079.tif 000016
【図１５】
2005174079.tif 000017
【図１６】
2005174079.tif 000018
【図１７】
2005174079.tif 000019
【図１８】
2005174079.tif 000020
【図１９】
2005174079.tif 000021
【図２０】
2005174079.tif 000022