JP4724428B2 - 画像読み取り装置および画像処理方法 - Google Patents

Description

本発明は、帳票原稿を読み取り可能な画像読み取り装置、画像処理方法に関するものである。

従来よりさまざまな業務において、情報の伝達、保存には紙の帳票を用いるのが一般的だが、これを電子化しコンピュータシステムで取り扱えるようにして業務の効率を上げる努力がなされてきている。

そして、紙の帳票を電子化する際には、スキャナを用いてビットマップイメージを作成するが、帳票そのままのイメージとして扱うと容量が大きく、また再利用が困難であるため、これをテキスト化し情報の扱いを容易にするシステムがＯＣＲ（Ｏｐｔｉｃａｌ Ｃｈａｒａｃｔｅｒ Ｒｅｃｏｇｎｉｔｉｏｎ）システムである。

このＯＣＲシステムにおいては、帳票の定型パターンが決まっていることを利用して、文字認識率を上げる工夫がなされている。例えばページ上のどの位置にどのパターンの文字が書かれているかをあらかじめテンプレートとして用意しておけば、文字認識時の選択の幅が縮まるので文字認識率が飛躍的に向上する。

１帳票が１ページから構成されるのであればテンプレートを使用した処理は容易だが、実際には書き込み位置が異なる複数のページからなるものが一般的であり、１帳票あたりに複数ページ分のテンプレートが用意され、いくつかの処理方法が取られている。

具体的には、（１）スキャナから１帳票だけ読込み、その帳票単位でテキスト化するもの、（２）ドキュメントフィーダから一括してスキャンし、ページ単位でどのページかを自動的に判断し（一般に帳票認識と呼ばれる）最適なテンプレートを選択するもの、（３）一般に、ドキュメントフィーダから一括して複数の帳票を読み込ませるもの等がある。なお、（３）の場合は、全て同じ形式の帳票であることが多い。
特開２００４−００５２６８号公報

しかしながら、上記方法（１）においては、確実に該当するページのテンプレートを用いることができるが、スキャナの操作を一帳票単位ごとに行わなければならないため、処理の時間と人手がかかる。

上記方法（２）の方法においては、ドキュメントフィーダを用いることで大量のドキュメントを一括読込みすることができ、処理の手間が軽減できる。ところが、帳票認識において、用意されているページのテンプレート全てから最適なものを選ぶため、どのページかを誤認識しやすく、また非常に処理が重くなり時間がかかってしまう。

また、原稿が紙として用意されているのではなく、ＰＤＦファイルやアプリケーションファイルで用意されていて帳票原稿の作成者が各自印刷する、といった場合には、作成者の環境によって片面と両面のいずれの形で帳票原稿として作成されるかわからないケースがある。このような場合、上記方法（３）の方法においては、同じ形式の帳票であっても、単純にＯＣＲ処理をかけるわけにはいかず、白紙ページ除去などの前処理を行う必要がある。さらに、上記方法（３）の方法においては、一括読込みの際、ある帳票の途中で区切られたら、ＯＣＲ処理の帳票単位にまとめようとした際に、次の一括読込みの処理とＯＣＲ処理が終わるまで待たされる、といった問題もある。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、複数の帳票種別を含む帳票原稿を一括して読み取る場合に、サーバ側での帳票認識処理負担を大幅に軽減できる帳票原稿データをサーバ装置に転送できる仕組みを提供することである。

上記目的を達成する本発明の画像読取り装置は以下に示す構成を備える。

帳票原稿を読み取って得られる画像情報をネットワークを介してサーバ装置に転送可能な画像読取り装置であって、複数のページから構成される帳票種別に対応し、少なくとも前記帳票種別のページ数を含む帳票構成情報を記憶する帳票情報記憶手段と、読み取る帳票原稿の帳票の種別を指定する指定手段と、前記指定手段により指定された帳票種別のページ数を、前記帳票情報記憶手段に記憶されている前記情報構成情報に基づいて取得する取得手段と、複数の帳票を含む帳票原稿をページ単位にスキャンして帳票原稿データを生成するスキャン手段と、前記取得手段により取得された前記帳票種別のページ数に基づいて、前記スキャン手段により生成された帳票原稿データを１帳票分のページ数からなる帳票原稿データに分割する分割手段と、前記分割手段により分割されたそれぞれの帳票原稿データに対して、前記帳票構成情報を割り当て、前記サーバに送信する送信手段と、を有することを特徴とする。

本発明によれば、画像読取り装置側でサーバ装置側での帳票認識処理負担を大幅に軽減できる帳票データを効率よく生成することができる。

また、サーバ装置側で帳票認識処理負担を大幅に軽減した文字認識処理を行い、短時間に効率的に帳票データを電子化して蓄積することができる。

さらに、画像読取り装置側でサーバ装置側での帳票認識処理負担を大幅に軽減できる帳票データを効率よく生成し、該生成された帳票データをサーバ装置が取得して、帳票認識処理負担を大幅に軽減した文字認識処理を行い、短時間に効率的に帳票データを電子化して蓄積するシステムを自在に構築できる。

次に本発明を実施するための最良の形態について図面を参照して説明する。

〔第１実施形態〕
図１は、本発明の第１実施形態を示す画像読取り装置およびサーバ装置を適用可能な画像処理システムの構成を説明するブロック図である。なお、本実施形態では、画像読取り装置として、マルチファンクション装置を例とするが、ネットワーク通信機能を備えているスキャナ装置であっても、本発明を適用可能である。

図１において、１１０はマルチファンクション装置（ＭＦＰ）で、スキャン機能、プリント機能、コピー機能等を備える。１２０はサーバ装置（サーバ）で、帳票認識処理およびＯＣＲ処理を行う。１３０はクライアントＰＣで、サーバ１２０での帳票認識およびＯＣＲの処理結果を確認したり修正したりする。

１４０はクライアントＰＣで、クライアントＰＣ１３０での確認・修正結果を承認する。１５０は業務用サーバであり、クライアントＰＣ１４０で承認された電子データを使用する。なお、ＭＦＰ１１０、サーバ１２０、クライアントＰＣ１３０，業務用サーバ１５０はそれぞれネットワークを介して通信可能に構成されている。

図２は、図１に示したＭＦＰ１１０とサーバ１２０の原稿処理状例を説明する概略図であり、ＭＦＰ１１０のスキャナ機能を利用して原稿画像を読み取り、サーバ１２０へ読み取った画像データを転送する原稿処理例に対応する。

図２において、１１１はスキャナで、ドキュメントフィーダ１１３から給送される原稿の各ページを読み取り、帳票データの一例であるページ単位にビットマップ化したイメージデータのイメージファイル３００をサーバ１２０へ転送する。なお、イメージファイル３００は、ビットマップデータだけでなく、JPEGやTIFFなど、圧縮済のイメージデータなどで構成されてもよい。

１１２はパネルで、ＭＦＰ１１０に対する機能設定や読取り処理等の指示を行うキーとディスプレイ等から構成されている。１１３はドキュメントフィーダで、複数部の帳票を１ページずつスキャナ１１１に送り込む。２１０、２２０、２３０、２４０、２５０、２６０はそれぞれ同じフォーマットの帳票である。なお、帳票２１０は、複数のページ、例えば１〜３頁の帳票２１１、２１２、２１３から構成されている。

また、現在ドキュメントフィーダ１１３上には、帳票２１０から帳票２６０までの複数帳票の束がドキュメントフィーダ１１３にセットされている。

３００はイメージファイルで、帳票２１０、２２０、２３０、２４０、２５０、２６０からスキャンされて、コントローラ部ＣＯＮＴ１の内部メモリに一時的に蓄積したり、ＨＤ１１０Ａ内に蓄積される。

３１０はイメージ帳票で、内部メモリ上に蓄積されたイメージファイル３００からコントローラ部ＣＯＮＴ１のＣＰＵまたは図示しない画像処理プロセッサ等により帳票単位（帳票２１０、２２０、２３０、２４０、２５０、２６０）に切り出される。１２１は例えばハードディスク（ＨＤ１１０Ａ）で構成されるイメージ帳票スプーラで、サーバ１２０内に設けられる。

３２０は帳票パターン情報テーブルで、読み込み得る帳票に関するページ構成情報等を持つ。データ処理装置で作成、保存され、適当なタイミングでネットワークを介してＭＦＰ１１０へダウンロードされる。

なお、ＭＦＰ１１０内で切り出されたイメージ帳票３１０がイメージ帳票スプーラ１２１に対してネットワーク経由で送られる。この際、コントローラ部ＣＯＮＴ１がイメージ帳票ファイルを所定の圧縮形式データ圧縮処理を行い、サーバ装置１２０で該圧縮されたイメージ帳票ファイルを解凍して処理することは任意である。

サーバ装置１２０には、ＣＰＵ，ＲＡＭ，ＲＯＭ等を含むコントローラ部ＣＯＮＴ２を備え、図示しないネットワークコントローラを介してネットワーク上のクライアントＰＣやＭＦＰ１１０と通信可能に構成され、後述するフローチャートの手順に従い、ＭＦＰ１１０から取得するイメージ帳票３１０をネットワークを介して取得し、ハードディスク（ＨＤ）１２０Ａ内に帳票種別毎のフォームテンプレートを参照してＯＣＲ処理を行い、電子化帳票を生成する。なお、生成された電子化帳票を、所定の電子文書形式（例えばＰＤＦ形式）や、業務に汎用のアプリケーションに対応付けられた文書ファイルに変換してスプールするように構成してもよい。

また、コントローラ部ＣＯＮＴ２は、ハードディスク（ＨＤ）１２０Ａ内の帳票認識処理プログラムを実行して、イメージ帳票３１０から帳票認識処理を行うことも可能に構成されている。

さらに、ハードディスク１２０Ａは、イメージ帳票、フォームテンプレート、電子化帳票等を記憶するスプーラとしても機能する。

なお、上記実施形態では、パネル１１２から帳票種別を指定入力する場合を説明するが、ネットワーク上のクライアントＰＣ１３０、１４０から指定される構成であっても構わない。

また、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１が、サーバ装置１２０より帳票エラー通知がなされる場合を考慮して、生成されたイメージ帳票をＨＤ１１０Ａに保持して、そのエラーがページ構成の順序が異なる場合には、そのページ順序を入れ替え等を行い、再度サーバ装置１２０に転送制御するように構成してもよい。

図３は、図１に示したサーバ１２０のデータ処理例を説明する概略図であり、図２と同一のものには同一の符号を付してある。

図３において、イメージ帳票スプーラ１２１内のイメージ帳票３１０が、イメージページ３１１、３１２、３１３から構成されている。

１２２はＯＣＲ処理部で、図示しない外部記憶装置に記憶されたＯＣＲモジュールを図示しないワークメモリ上に読み込んで、イメージページ３１１、３１２、３１３に対してＯＣＲ処理を実行する。

１２３はフォームテンプレート部で、ユーザ等から登録されたフォームテンプレートが複数登録されており、ＯＣＲ処理部１２２がそのフォームテンプレートを参照可能に構成されている。

４１０は電子化帳票Ａであり、ＯＣＲ処理部１２２でＯＣＲ処理済みのテキストページ４１１、４１２、４１３から構成されている。１２４は電子化帳票スプーラで、電子化帳票を蓄積する。

図４は、図３に示したイメージ帳票ファイル３１０のフォーマット例を示す構造図であり、図１と同一のものには同一の符号を付してある。

図４において、５０１はイメージ帳票ＩＤ、５０２は帳票種別、５０３はページ数でありイメージページ３１１、３１２、３１３からなる。なお、イメージページ３１１、３１２、３１３からなイメージ帳票３１０は帳票イメージスプーラ１２１上に連続して確保されるイメージ領域に格納している。

図５は、本発明に係る画像読取り装置における第１のデータ処理手順の一例を示すフローチャートであり、クライアントＰＣ１４０からユーザがログインする際のＭＦＰ１１０内の処理手順に対応する。なお、Ｓ１〜Ｓ９は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

ＭＦＰ１１０は、特に処理を行っていない場合は、入力を待っており（Ｓ１）、パネル１１２からのログイン入力があることをコントローラ部ＣＯＮＴ１内のＣＰＵが検出すると、パネル１１２からのログイン入力を読み込む（Ｓ２）。

そして、入力されるログイン入力と内部にもつログインアカウント情報とを上記コントローラ部ＣＯＮＴ１内のＣＰＵが照合し（Ｓ３）、照合結果が一致する（ＯＫ）状態か否かを判断して（Ｓ４）、認証結果が一致しない場合には、ステップＳ１へ戻る。

一方、ステップＳ４で、認証結果が一致すると判断した場合は、さらに、入力を待ち（Ｓ５）、パネル１１２から入力される帳票種別を読み込み（Ｓ６）、該読み込んだ帳票種別がＭＦＰ１１０のハードディスクＨＤ１１０Ａ等に登録されているかをコントローラ部ＣＯＮＴ１のＣＰＵが照合し（Ｓ７）、帳票種別が登録されているものと一致して照合ＯＫとなったかどうかをコントローラ部ＣＯＮＴ１のＣＰＵが判別して、一致していないと判別した場合は、ステップＳ５へ戻る。

一方、ステップＳ８で、帳票種別が登録されているものと一致して照合ＯＫであると判別した場合は、その帳票のページ数を帳票パターン情報テーブル３２０から取得し（Ｓ９）、本処理を終了する。

次に、図６に示すフローチャートに従って、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理を説明する。

図６は、本発明に係る画像読取り装置における第２のデータ処理手順の一例を示すフローチャートであり、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理手順に対応する。なお、Ｓ１１〜Ｓ１８は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

先ず、ＭＦＰ１１０は、ドキュメントフィーダ１１３にドキュメントがセットされているかどうかを検出する図示しないセンサからのセンサ出力状態をコントローラ部ＣＯＮＴ１の内のＣＰＵが監視しており（Ｓ１１）、原稿がドキュメントフィーダ１１３にセットされたことを検出したら（Ｓ１２）、パネル１１２に付随するキーの入力を待つ（Ｓ１３）。

そして、パネル１１２の読込みキー（図示しない）が押されたことをコントローラ部ＣＯＮＴ１内のＣＰＵが検出すると（Ｓ１４）、次に、ドキュメントフィーダ１１３にセットされた全ドキュメントの全ページをスキャンし終えたか否かをコントローラ部ＣＯＮＴ１内のＣＰＵが判別して（Ｓ１５）、終了していないと判別した場合は、ステップＳ１６以降へ進み、終了していると判別した場合には、本処理を終了する。

一方、ステップＳ１５で、終了していないと判別した場合は、ドキュメントフィーダ１１３が、図２に示す帳票２１０の紙ページ２１１をフィードさせ（Ｓ１６）、スキャナ１１１でページをスキャンし（Ｓ１７）、スキャナ１１１で読み込まれたビットマップイメージを圧縮処理してイメージファイル３００に書き込み（Ｓ１８）、例えばＨＤ１１０Ａ上に蓄積した後、ステップＳ１５へ戻る。

このようにして、ドキュメントフィーダ１１３にセットされた全ドキュメント（帳票２１０、２２０、２３０、２４０、２５０、２６０）の全ページの一括スキャンと、イメージデータの圧縮処理等を終了する。

次に、図７のフローチャートに従って、読込んだイメージファイル３００を分割送信するＭＦＰ１１０内部処理を説明する。

図７は、本発明に係る画像読取り装置における第３のデータ処理手順の一例を示すフローチャートであり、読込んだイメージファイル３００を分割送信するＭＦＰ１１０内部処理手順に対応する。なお、Ｓ２１〜Ｓ３１は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

まず、ドキュメントフィーダ１１３の１回の連続的な読込みにより完成した１つのイメージファイル３００をＨＤ１１０Ａ上からコントローラ部ＣＯＮＴ１内のＣＰＵが取得する（Ｓ２１）。次に、前回のイメージファイルの分割送信処理において、残ページがあったかどうかをコントローラ部ＣＯＮＴ１内のＣＰＵがチェックし（Ｓ２２）、残ページがあると判別した場合は、それらの残ページを取り出し（Ｓ２３）、ステップＳ２４へ進む。

一方、ステップＳ２２で、残ページがないと判別した場合は、残ページおよびイメージページ３００内に一帳票分の未処理のページがあるかどうかをコントローラ部ＣＯＮＴ１のＣＰＵが判別して（Ｓ２４）、一帳票分の未処理のページがあると判別した場合は、１帳票分のページのイメージをＨＤ１１０Ａ上から読み出し（Ｓ２５）、図４に示したフォーマットに従って１つのファイルにまとめて（Ｓ２６）、コントローラ部ＣＯＮＴ１のＣＰＵが帳票種別５０２とページ数５０３とをファイルの属性として付与し（Ｓ２７）、イメージ帳票３１０としてネットワークを介してサーバ１２０に転送して（Ｓ２８）、ステップＳ２４へ戻る。つまり、イメージファイル３００に一帳票分の未処理のページが残っている限りステップＳ２４に戻り、ステップＳ２４〜Ｓ２８に戻り処理を繰り返す。

一方、ステップＳ２４で、一帳票分の未処理のページがないと判別した場合は、ステップＳ２９で、未処理のイメージファイル３００にページが１つでも残っているか否かをコントローラ部内のＣＰＵが判別して（Ｓ２９）、もし一帳票分の未処理のページが残っていないが、残ページがあると判別した場合は、残ページとして保存し（Ｓ３０）、ステップＳ３１へ進む。

一方、ステップＳ２９で、残ページがないと判別した場合は、イメージファイル３００をＨＤ１１０Ａ上から削除し（Ｓ３１）、本処理を終了する。

次に、図８のフローチャートに従って、帳票認識処理とＯＣＲ処理を行うサーバ１２０の内部処理を説明する。

図８は、本発明に係るサーバ装置における第１のデータ処理手順の一例を示すフローチャートであり、サーバ１２０による読込んだイメージ帳票３１０に対する帳票認識処理とＯＣＲ処理手順に対応する。なお、Ｓ５１〜Ｓ６２は各ステップを示し、各ステップは、サーバ１２０内のＣＰＵおよびＯＣＲ処理部１２２が実行するステップである。

先ず、図１に示したようにネットワークを介してＭＦＰ１１０から送信されたイメージ帳票３１０のファイルを取得し（Ｓ５１）、取得したファイルが図４に示したフォーマットに従う帳票種別５０２を持っているか否かをサーバ１２０内のＣＰＵがチェックし（Ｓ５２）、もし帳票種別５０２を持たない、もしくは図４のフォーマットに従っていない形式であると判別した場合は、各ページに対して帳票認識の処理を行う（Ｓ５３）。そして、帳票認識の結果から一帳票にページをまとめて（Ｓ５４）、ステップＳ５５へ進み、一帳票単位の処理に入る。

一方、ステップＳ５２で、イメージ帳票３１０より帳票種別が明確であると判別した場合は、特になにもせず、ステップＳ５５以降の一帳票単位の処理に入る。

そして、全ページの終了状態をサーバ１２０内のＣＰＵが判別して（Ｓ５５）で、全ページを終了していないと判別した場合は、１つのイメージ帳票３００から１ページ分のイメージページを取り出し（Ｓ５６）、指定された帳票種別５０２の該当ページのテンプレートを図３に示すようにサーバ１２０内のメモリに記憶されているフォームテンプレート１２３から取り出し（Ｓ５７）、このテンプレートを使用してＯＣＲ処理部１２２によりページのテキスト領域に対してＯＣＲ処理を行う（Ｓ５９）。

そして、ＯＣＲ処理によりページ単位にテキストページ４１１として抽出したら（Ｓ５９）、それらを電子化帳票４１０に書き加え（Ｓ６０）、ステップＳ５５へ戻る。

そして、ステップＳ５５で、ページ数５０３で特定される一帳票分全ページの処理が終了したと判別した場合は、１つの電子化帳票４１０として電子化帳票スプーラ１２４に対して出力し（Ｓ６１）、ＭＦＰ１１０から取得してワークメモリ上に保持されるイメージ帳票３１０を削除して（Ｓ６２）、本処理を終了する。

なお、この帳票のＯＣＲ処理に誤認識があれば、ポストエディット用のクライアントＰＣ１３０から人手で修正し、承認用のクライアントＰＣ１４０で承認する。

そして、完成した電子化帳票４１０は、さらに業務用サーバ１５０内の電子化帳票スプーラ１２４（例えばサーバ１２０内のハードディスク等内に確保される）に送られ、帳票データベースとして各業務のクライアントＰＣからの参照要求に応え、さまざまな形で共有されるデータとして記憶管理される。

このようにして、ドキュメントフィーダ１１３から一括して同じ形式の帳票を複数読込ませるようなケースでは、帳票認識処理とＯＣＲ処理として機能するサーバ１２０において、取得するファイルに帳票種別５０２を付与することができ、ステップＳ５３、ステップＳ５４の処理が全く不要になる。

なお、ステップＳ５４の処理は、用意されているテンプレートの数が多いと、その全てのテンプレートと入力ページのマッチングが行なわれるので非常に処理が重くなるため、この処理を省略できることによる負荷の軽減効果は大きい。

また、帳票認識処理とＯＣＲ処理とを行うサーバ１２０においては、必ず帳票単位で処理を行うため、ドキュメントフィーダにセットした紙の途中で一つの帳票が区切られてしまっても、次の読込み処理が終わるまで処理が待たされてしまうといったこともない。

以上の説明から、ドキュメントフィーダ１１３を用いることで大量のドキュメントを一括読込みすることができ、確実にＯＣＲ処理用のページのテンプレートを選択でき、また帳票認識の処理の必要がなくなるため、サーバ１２０のデータ処理負担が大幅に軽減され、より高速にデータ処理を行い、電子化帳票スプーラ１２４に対して、電子化された電子化帳票４１０を効率よく蓄積できる。

〔第２実施形態〕
上記第１実施形態では、あらかじめサーバ１２０のフォームテンプレート１２３に登録されている帳票種別５０２とページ数５０３とからＭＦＰ１１０から取得されるイメージ帳票３１０の各ページに対してＯＣＲ処理を実行する場合について説明したが、イメージ帳票内のページ読込順序と登録されているテンプレート中のページの順序とが異なる場合にはＯＣＲ処理がエラーとなる場合がある。そこで、帳票の種別があらかじめわかっていても、ＭＦＰ１１０からネットワークを介して取得するイメージ帳票３１０に対して全ページに帳票認識処理をかけることで、ドキュメントフィーダ１１３への入力時に各帳票単位で、各ページ順序が入れ替わっていたり、別のページが混入していることに気が付かないまま処理を継続してしまったりする事態を避けることができるように構成してもよい。以下、その実施形態について説明する。

なお、第２実施形態では、帳票認識処理とＯＣＲ処理とを行うサーバ１２０の内部処理以外は第１実施形態と同じであるため、ハードウエアに関する説明を割愛する。

図９は、本発明に係るサーバ装置における第２のデータ処理手順の一例を示すフローチャートであり、帳票認識処理とＯＣＲ処理とを行うサーバ１２０の内部処理手順に対応する。なお、Ｓ７１〜Ｓ８４は各ステップを示す。

先ず、ＭＦＰ１１０からネットワークを介して送信されたイメージ帳票３１０のファイルを取得し（Ｓ７１）、図４に示したフォーマットに従って帳票種別５０２を取得し（Ｓ７２）、全ページの終了状態をサーバ１２０内のＣＰＵが判別して（Ｓ７３）、終了していないと判別した場合は、各ページに対して帳票認識処理をかける（Ｓ７４）。そして、ステップＳ７３へ戻る。

一方、ステップＳ７３で、１帳票分の全ページの帳票認識処理が終了していると判別した場合は、帳票認識結果と取得した帳票種別５０２とをサーバ１２０内のＣＰＵが比較して両者が一致するか否かを判別し（Ｓ７５）、一致しないページが見つかったと判別した場合は、ポストエディット用のクライアントＰＣ１３０もしくは承認用のクライアントＰＣ１４０に対しエラーを通知して（Ｓ７６）、クライアント側の表示装置にその旨を表示し、本帳票の処理を終了する。

一方、ステップＳ７５で、全ページの終了状態をサーバ１２０内のＣＰＵが判別して（Ｓ７７）、すべてのページが終了していないと判別した場合は、１イメージ帳票から１ページ分のイメージを取り出し（Ｓ７８）、指定された帳票種別の該当ページのテンプレートをフォームテンプレート１２３から取り出し（Ｓ７９）、このテンプレートを使用してＯＣＲ処理部１２２によりページのＯＣＲ処理を行う（Ｓ８０）。

そして、ＯＣＲ処理部１２２のＯＣＲ処理により、ページ単位にテキストページ４１１として抽出したら（Ｓ８１）、それらを電子化帳票４１０に書き加え（Ｓ８２）、ステップＳ７７へ戻る。

一方、ステップＳ７７で、１帳票分全ページの処理が終了していると判別した場合は、１つの電子化帳票４１０として電子化帳票スプーラ１２４に対して出力し（Ｓ８３）、ＭＦＰ１１０から取得しているイメージ帳票３１０をワーク上から削除して（Ｓ８４）、本処理を終了する。

このようにして、帳票の種別があらかじめわかっていても、全ページに帳票認識処理をかけることで、ドキュメントフィーダへの入力時にページ順序が入れ替わっていたり、別のページが混入していたりすることに気が付かないまま処理を継続するのを避けることができる。

この場合、帳票認識処理があるため、サーバ１２０によるデータ処理負荷の軽減はできないが、ユーザが処理速度とエラー処理のトレードオフにより機能を選択することができ、ユーザの利便性が向上する。

以上の説明から、サーバの処理速度に余裕がある場合には、帳票認識処理による帳票の照合を行うことで、ドキュメントフィーダでの入力でのミスを容易に発見するシステムを供給でき、使い勝手のよい画像処理システムを構築できる。

上記実施形態によれば、ドキュメントフィーダを用いることで大量のドキュメントを一括読込みすることができ、確実にＯＣＲ処理用のページのテンプレートを選択でき、サーバの負荷を軽減し、より高速に処理を行えるシステムを供給できる。

また、サーバの処理速度に余裕がある場合には、ドキュメントフィーダでの入力でのミスを容易に発見するシステムを供給できる。

〔第３実施形態〕
上記第１実施形態では、ＭＦＰ１１０において、イメージファイル３００が完成した後に、分割送信処理を行っている場合について説明したが、読み込む帳票のページ数が多いとその時間が無駄になるので、イメージファイル３００が完成する前にページを読み出し、分割送信処理を行うよう構成してもよい。以下、その実施形態について説明する。

なお、第３実施形態では、ユーザログイン処理とドキュメントフィーダ１１３からの読み込み処理とを行うＭＦＰ１１０の内部処理以外は第１実施形態と同じであるため、説明を割愛する。

図１０は、本発明に係る画像読取り装置における第４のデータ処理手順の一例を示すフローチャートであり、読込んだイメージファイル３００を分割送信するＭＦＰ１１０内部処理手順に対応する。なお、Ｓ９１〜Ｓ１０２は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

まず、ドキュメントフィーダ１１３の１回の連続的な読込みが開始され、１つのイメージファイル３００がＨＤ１１０Ａ上に作成されると同時に、分割処理を開始する。この時点では、イメージファイル３００内にはまだページが書き込まれていない。

前回のイメージファイルの分割送信処理において、残ページがあったかどうかをコントローラ部ＣＯＮＴ１内のＣＰＵがチェックし（Ｓ９１）、残ページがあると判別した場合は、それらの残ページを取り出し（Ｓ９２）、もし残ページがない場合は、何もせずステップＳ９３へ進む。

イメージファイル３００が既に閉じられてもうページが増えない状態であるかを、コントローラ部ＣＯＮＴ１のＣＰＵが判別し（Ｓ９３）、まだ増えるようであれば、ページが蓄積されるのを監視する（Ｓ９４）。もし増えていて一帳票分の未処理ページが蓄積したら（Ｓ９５）、一帳票分のページのイメージを読み出す（Ｓ９６）。もし、ステップＳ９５である一定時間一帳票分の未処理ページが蓄積しなければ、ステップＳ９３へ戻り、処理を繰り返す。

そして、ステップＳ９６で読み出した一帳票分の未処理ページを一つのファイルにまとめて（Ｓ９７）、コントローラ部ＣＯＮＴ１のＣＰＵが帳票種別５０２とページ数５０３とをファイルの属性として付与し（Ｓ９８）、イメージ帳票３１０としてネットワークを介してサーバ１２０に転送して（Ｓ９９）、ステップＳ９３へ戻る。つまり、イメージファイル３００に一帳票分の未処理のページが残っている限りＳ９３に戻り処理を繰り返す。

一方、ステップＳ９５で、一帳票分の未処理のページがないと判別され、またステップＳ９３でもうこれ以上ページが増えないことが検知された場合は、ステップＳ１００で、未処理のイメージファイル３００にページが１つでも残っているか否かをコントローラ部内のＣＰＵが判別して（Ｓ１００）、もし一帳票分の未処理のページが残っていないが、残ページがあると判別した場合は、残ページとして保存し（Ｓ１０１）、ステップＳ１０２へ進む。

一方、ステップＳ１００で、残ページがないと判別した場合は、イメージファイル３００をＨＤ１１０Ａ上から削除し（Ｓ１０２）、本処理を終了する。

このようにして、イメージページ３００の完成を待たずに、分割転送処理を開始することで、読み込み処理中にも分割転送処理を開始でき、ひいてはサーバ１２０における帳票認識処理、ＯＣＲ処理も開始することができる。

そうすると、物理的な制約の大きいドキュメントフィーダ１１３の動作速度と比較すると、より高速化の著しいＣＰＵの速度に依存する分割転送処理、帳票認識処理およびＯＣＲ処理を同時に進めることができ、システム全体の処理速度が向上する。

以上の説明から、イメージファイル３００の完成を待たずに分割送信処理を開始することで、帳票認識処理およびＯＣＲ処理を同時に進めることができ、より高速に処理を行えるシステムを供給できる。

上記実施形態によれば、ドキュメントフィーダを用いることで大量のドキュメントを一括読込みすることができ、確実にＯＣＲ処理用のページのテンプレートを選択でき、サーバの負荷を軽減し、より高速に処理を行えるシステムを供給できる。

〔第４実施形態〕
上記第１実施形態では、ＭＦＰ１１０において、読み込む原稿すべてが片面か両面かをユーザが見て判断し、それに従ってドキュメントフィーダを動作させる場合の説明をしたが、あらかじめその帳票原稿が必ず片面もしくは必ず両面であることが明白である、もしくは帳票単位に片面の帳票原稿と両面の帳票原稿が混ざっていることが明白であるならば帳票パターン情報に事前に記録しておき、ドキュメントフィーダの動作に利用する構成にしてもよい。さらに、ＯＣＲ処理が不必要なページが原稿内に含まれていたり、ＯＣＲ処理に向いたスキャンモードがページ単位であらかじめ判断できる場合、これも帳票パターン情報に記録しておきスキャン時に利用する構成にしてもよい。以下、その実施形態について説明する。

なお、第４実施形態では、ＭＦＰ１１０の分割送信処理およびサーバ１２０の処理は第１実施形態と同じであるため、説明を割愛する。

図１１は、本発明に係る画像読取り装置における第５のデータ処理手順の一例を示すフローチャートであり、クライアントＰＣ１４０からユーザがログインする際のＭＦＰ１１０内の処理手順に対応する。なお、Ｓ２１１〜Ｓ２２１は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

ＭＦＰ１１０は、特に処理を行っていない場合は、入力を待っており（Ｓ２０１）、パネル１１２からのログイン入力があることをコントローラ部ＣＯＮＴ１内のＣＰＵが検出すると、パネル１１２からのログイン入力を読み込む（Ｓ２０２）。

そして、入力されるログイン入力と内部にもつログインアカウント情報とを上記コントローラ部ＣＯＮＴ１内のＣＰＵが照合し（Ｓ２０３）、照合結果が一致する（ＯＫ）状態か否かを判断して（Ｓ２０４）、認証結果が一致しない場合には、ステップＳ２０１へ戻る。

一方、ステップＳ２０４で、認証結果が一致すると判断した場合は、さらに、入力を待ち（Ｓ２０５）、パネル１１２から入力される帳票種別を読み込み（Ｓ２０６）、該読み込んだ帳票種別がＭＦＰ１１０のハードディスクＨＤ１１０Ａ等に登録されているかをコントローラ部ＣＯＮＴ１のＣＰＵが照合し（Ｓ２０７）、帳票種別が登録されているものと一致して照合ＯＫとなったかどうかをコントローラ部ＣＯＮＴ１のＣＰＵが判別して（Ｓ２０８）、一致していないと判別した場合は、ステップＳ２０５へ戻る。

なお、帳票種別は、図１２の帳票パターン情報テーブル３２０の形式でＨＤ１１０Ａに登録されている。

一方、ステップＳ２０８で、帳票種別が登録されているものと一致して照合ＯＫであると判別した場合は、その帳票種別を元に帳票パターン情報テーブルから、必要ページ数、総ページ数、両面属性、スキャンモードリストを取得し（Ｓ２０９）、さらに保存して（Ｓ２１０）、本処理を終了する。

図１２は、図２に示した帳票パターン情報テーブル３２０の一例を示す図である。

図１２に示すように、本実施形態では、帳票パターン情報テーブル３２０は、帳票種別に、必要ページ数、総ページ数、両面属性、スキャンモードリスト等を記憶している。

次に、図１３に示すフローチャートに従って、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理を説明する。

図１３は、本発明に係る画像読取り装置における第６のデータ処理手順の一例を示すフローチャートであり、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理手順に対応する。なお、Ｓ２１１〜Ｓ２２１は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

先ず、ＭＦＰ１１０は、ドキュメントフィーダ１１３にドキュメントがセットされているかどうかを検出する図示しないセンサからのセンサ出力状態をコントローラ部ＣＯＮＴ１の内のＣＰＵが監視しており（Ｓ２１１）、原稿がドキュメントフィーダ１１３にセットされたことを検出したら（Ｓ２１２）、パネル１１２に付随するキーの入力を待つ（Ｓ２１３）。

そして、パネル１１２の読込みキー（図示しない）が押されたことをコントローラ部ＣＯＮＴ１内のＣＰＵが検出すると（Ｓ２１４）、第１のデータ処理手順により保存したページ属性を取得し（Ｓ２１５）、その両面属性が片面であれば、ドキュメントフィーダ１１３を片面のみ読み取るよう動作設定し（Ｓ２１７）、原稿のスキャン処理を行い（Ｓ２１８）、処理を終了する。

一方、ステップＳ２１６で、両面属性が両面であると判断した場合は、ドキュメントフィーダ１１３を両面とも読み取るよう動作設定し（Ｓ２１９）、片面の時と同様の原稿のスキャン処理を行い（Ｓ２１８）、処理を終了する。

さらに、ステップＳ２１６で、両面属性が混在であると判断した場合は、ドキュメントフィーダ１１３を両面とも読み取るよう動作設定し（Ｓ２２０）、片面と両面の原稿が混在しているケースのスキャン処理を行い（Ｓ２２１）、処理を終了する。

次に、図１４に示すフローチャートに従って、図１４のステップＳ２１８のスキャン処理をより詳細に説明する。

図１４は、本発明に係る画像読取り装置における第７のデータ処理手順の一例を示すフローチャートであり、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理手順であって、図１４のステップＳ２１８のスキャン処理の詳細手順に対応する。なお、Ｓ２３１〜Ｓ２３８は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

まず、一連のドキュメントをドキュメントフィーダ１１３で読み取る処理に入り、フィーダに積載した分のスキャン処理が終了しているかどうかコントローラ部ＣＯＮＴ１内のＣＰＵが判断する（Ｓ２３１）。なお、終了していると判断した場合は、本処理を終了する。

ステップＳ２３１で、最初は、まだ一つも帳票の処理が行われていないので、ステップＳ２３２へ進み、１帳票分のスキャン処理を終了しているかどうかをコントローラ部ＣＯＮＴ１内のＣＰＵが判断して（Ｓ２３２）、終了していると判断した場合は、ページ属性のスキャンモードリストの先頭を参照する（Ｓ２３３）。そして、ペーパをフィードし（Ｓ２３５）、参照先のスキャンモードが「無視」であるかどうかをコントローラ部ＣＯＮＴ１内のＣＰＵが判断して（Ｓ２３６）、無視であると判断した場合は、スキャンせずにステップＳ２３１に戻る。

一方、ステップＳ２３６において、参照先のスキャンモードが「無視」でないと判断した場合は、そのモードである「文書」もしくは「写真」の動作に従って最初のページをスキャンし（Ｓ２３７）、結果を圧縮してイメージファイル３００に書き込み（Ｓ２３８）、ステップＳ２３１に戻る。

そして、ステップＳ２３１において、ドキュメントフィーダ１１３に積載したドキュメントのペーパーフィードが全て終了すれば、本処理を終了し、それ以外であると判断した場合は、ステップＳ２３２へ行き処理を継続する。

一方、ステップＳ２３２で、まだ一帳票の処理途中であると判断した場合は、スキャンモードリストの参照先を次のページへ進め（Ｓ２３４）、該一帳票の処理が終われば再度ステップＳ２３３に進み、参照先をページ属性のスキャンモードリストの先頭に戻し、ペーパーフィード以降の処理を繰り返す。

このようにして、ドキュメントフィーダ１１３にセットされた全ドキュメント（帳票２１０、２２０、２３０、２４０、２５０、２６０）の全ページの一括スキャンと、イメージデータの圧縮処理等を終了する。

以上の説明から、両面属性が片面もしくは両面の時、イメージファイル３００には、ＯＣＲ処理に必要なページが、期待されるスキャンモードでスキャンした結果で収められることがわかる。さらに必要なページ数で分割することで、サーバに送られるイメージファイル３１０が、各帳票ごとに作成されることがわかる。

次に、図１５に示すフローチャートに従って、図１３のステップＳ２２１のスキャン処理をより詳細に説明する。

図１５は、本発明に係る画像読取り装置における第８のデータ処理手順の一例を示すフローチャートであり、ユーザが帳票をドキュメントフィーダ１１３から読込ませる際のＭＦＰ１１０内の処理手順であって、図１３のステップＳ２２１の混在原稿スキャン処理の詳細手順に対応する。なお、Ｓ２４１〜Ｓ２４５は各ステップを示す。また、各ステップは、ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより実行されることで実現される。

まず一連のドキュメントをドキュメントフィーダ１１３で読み取る処理に入る（Ｓ２４１）。そして、ドキュメントフィーダ１１３によりペーパをフィードし（Ｓ２４２）、１ページ分のスキャンを行う（Ｓ２４３）。このとき図１３に示したステップＳ２２０で両面読み取りの設定が行なわれているため、必ず両面でスキャンされる。

そして、もしページをスキャンした結果が白紙ページであるかどうかを判断して（Ｓ２４４）、白紙ページであると判断した場合、そのページをどこにも保存することなくステップＳ２４１に戻る。

一方、ステップＳ２４４で、白紙ページでないと判断した場合は、そのページを圧縮処理（ＭＦＰ１１０のコントローラ部ＣＯＮＴ１内のＣＰＵにより圧縮処理される）して、イメージファイル３００に書き込む。

以上の処理を繰り返し、ステップＳ２４１で、ドキュメントフィーダ１１３に積載したドキュメントのペーパーフィードが全て終了すれば、処理を終了する。

このようにして、ドキュメントフィーダ１１３にセットされた全ドキュメント（帳票２１０、２２０、２３０、２４０、２５０、２６０）の全ページの一括スキャンと、イメージデータの圧縮処理等を終了する。

以上の説明から、両面属性が混在の時、イメージファイル３００には、ＯＣＲ処理に必要なページが収められることがわかる。さらに、必要なページ数で分割することで、サーバに送られるイメージファイル３１０が、帳票一部ごとに作成されることがわかる。

以下、図１２、図１６および図１７を用いて、ドキュメントフィーダ１１３に置かれた各原稿のページがどのようにしてイメージ帳票３１０としてサーバに送られるかの例を具体的に説明する。

図１６は、本発明に係る画像読取り装置における片面の帳票原稿とイメージ帳票ファイルの関係の例を示す概略図であり、指定された帳票のページ構成は、必要ページ数が３ページ、総ページ数が３ページ、両面属性が片面、スキャンモードリストが文書―文書―写真であり、３部の帳票原稿がドキュメントフィーダ１１３に置かれた場合に対応する。この帳票は、図１２の帳票パターン情報テーブル３２０の帳票Ｃに該当する。

図１３のフローチャートで説明したように、両面属性が片面である場合、ドキュメントフィーダ１１３は、常に片面でスキャンを行うので、図１６に示した左の列にある９枚の帳票原稿から９ページ分の片面スキャンを行い、図１６中の真中の列のように、９ページ分のスキャン結果が得られる。

また、スキャンモードリストが文書―文書―写真であるので、トータルで３ページ目、６ページ目、９ページ目が写真モードで、他のページは文書モードでスキャンされる。これらはイメージファイル３００に書き込まれる。

さらに、必要ページ数、総ページ数とも３ページであるため、先頭から３ページずつ分割され、右の列のように３ページから構成されるイメージ帳票３１０が３つ作成される。

図１７は、本発明に係る画像読取り装置における混在の帳票原稿とイメージ帳票ファイルの関係の例を示す概略図であり、指定された帳票のページ構成は、必要ページ数が３ページ、総ページ数が３ページ、両面属性が混在であり、１部の片面の帳票原稿と１部の両面の帳票原稿が連続してドキュメントフィーダ１１３に置かれた場合に対応する。この帳票は図１２の帳票パターン情報テーブル３２０の帳票Ｄに該当する。

図１３のフローチャートで説明したように、両面属性が混在である場合、ドキュメントフィーダ１１３は、常に両面でスキャンを行うので、図１７に示す左の列にある５枚の帳票原稿から１０ページ分の両面スキャンを行い、真中の列のように、１０ページ分のスキャン結果が得られる。

図１４に示したフローチャートで説明したように、これらのうち白紙ページでないページだけがイメージファイル３００に書き込まれるので、色のついた６ページ分が残る。さらに必要ページ数、総ページ数とも３ページであるため、先頭から３ページずつ分割され、右の列のように３ページから構成されるイメージ帳票３１０が２つ作成される。

以上の説明から、同じページ数からなる帳票が、片面印刷されているものと両面印刷されているものが混在している場合でも、原稿の裏面が白紙であれば、ＯＣＲ処理をかける際には、同じページ数からなる１ファイルとして扱うことができることがわかる。

以下、図１８，図１９に示すメモリマップを参照して本実施形態に係る画像読取り装置およびサーバ装置を適用可能な画像処理システムで読み取り可能なデータ処理プログラムの構成について説明する。

図１８は、本実施形態に係る画像読取り装置を適用可能な画像処理システムで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図であり、図１９は、本実施形態に係るサーバ装置を適用可能な画像処理システムで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図５，図６，図７，図８，図９，図１０、図１１，図１３，図１４，図１５に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

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

プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

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

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

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

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

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から排除するものではない。

本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではなく、以下の実施態様も含まれることはいうまでもない。以下、その実施態様１〜２３について説明する。

〔実施態様１〕
帳票原稿を読み取って得られる画像情報をネットワークを介してサーバ装置に転送可能な画像読取り装置であって、読み取る帳票原稿の種別と各帳票のページ構成情報を記憶する帳票情報記憶手段（例えば図２に示すＨＤ１１０ａ）と、読み取る帳票原稿の種別を指定する指定手段（例えばパネル１１２）と、複数部数一括して帳票原稿をページ単位にスキャンして帳票原稿イメージを出力するスキャン手段（図２に示すスキャナ１１１）と、前記スキャン手段により一括してスキャンされる前記帳票原稿イメージを前記指定手段により指定される帳票原稿の種別に基づき、前記帳票情報記憶手段に記憶されるページ情報に基づいてまとった帳票イメージファイルを生成する生成手段（図２に示すコントローラ部ＣＯＮＴ１による）と、前記生成手段により生成される帳票イメージファイルを前記サーバに送信する送信手段（図２に示すコントローラ部ＣＯＮＴ１が図示しないネットワークコントローラに接続されるネットワークを介してサーバ１２０に送信する）とを有することを特徴とする画像読取り装置。

これにより、入力される帳票原稿束の切れ目等を考慮することなく、複数束の帳票原稿を一括して画像読取り処理を実行させて、読取り処理効率を向上させることが可能となる。また、読み取られた帳票イメージが指定される帳票種別で登録されたページ数で自動的に分割されて１つの帳票データが生成されるため、帳票イメージの切れ目が他の帳票イメージに混ざった状態でサーバ装置に送信してしまう事態を確実に防止できる。

〔実施態様２〕
前記各帳票のページ構成情報は、実際に必要なページ数と、総ページ数と、各ページのページサイズと、両面属性と、各ページスキャンモードのリストとを含むことを特徴とする実施態様１記載の画像読取り装置。

これにより、帳票原稿の構成を自在に編成できるため、種々のサイズの帳票原稿が混在していても正確に各帳票の切れ目を認識した帳票原稿読み取りを正確に行える。

〔実施態様３〕
前記生成手段は、前記帳票データに帳票種別、ページ数、帳票イメージを付与可能とすることを特徴とする実施態様１記載の画像読取り装置。

これにより、帳票種別とページ数をサーバ装置に通知して、帳票イメージの帳票認識処理を行うことなく、文字認識処理を実行させて、電子化帳票作成効率を格段に向上させることができる。

〔実施態様４〕
前記生成手段は、前記スキャン手段によりスキャンされた前記原稿イメージが白紙ページかどうかを認識可能とすることを特徴とする実施態様１記載の画像読取り装置。

これにより、スキャンされた原稿イメージから白紙ページを除去することができ、正確に各帳票の切れ目を認識した帳票原稿読み取りを正確に行える。

〔実施態様５〕
前記各帳票のページ構成情報は、ネットワークを介してデータ処理装置からダウンロード可能とすることを特徴とする実施態様１記載の画像読取り装置。

これにより、各帳票のページ構成情報の詳細をデータ処理装置から取得して画像処理装置に対して正確に入力することができる。

〔実施態様６〕
前記各帳票のページ構成情報の両面属性は、片面、両面、混在の属性値を持つことを特徴とする実施態様１記載の画像読取り装置。

これにより、原稿のスキャン時にどの面をスキャンするのかの指示を省略でき、作業負荷を軽減することができる。

〔実施態様７〕
前記各帳票のページ構成情報のスキャンモードリストは、ページ単位に文書モード、写真モード、無視モードの属性値を持つリストであることを特徴とする実施態様１記載の画像読取り装置。

これにより、原稿のスキャン時にページ単位でスキャンの方法を変えることができ、文字認識の確度を向上させ、また無駄なページを作成しないことで、電子化帳票作成効率を格段に向上させることができる。

〔実施態様８〕
ネットワークを介して画像読取り装置により生成される帳票データを取得可能なサーバ装置であって、文字認識処理するための帳票構成を示すテンプレートを帳票種別毎に記憶するテンプレート記憶手段（図３に示すフォームテンプレート１２３）と、前記帳票データに付与される帳票種別に従い前記テンプレート記憶手段から特定されるテンプレートに基づき、前記帳票データの各ページに文字認識処理を行う文字認識処理手段（図３に示すＯＣＲ処理部１２２）と、前記文字認識処理手段により認識される各ページのテキストデータを電子化帳票ファイルとして生成するファイル生成手段（図３に示すＯＣＲ処理部１２２）とを有することを特徴とするサーバ装置。

これにより、帳票データに対して帳票認識処理を行うことなく、各帳票データの文字認識処理を実行でき、最終的な電子化帳票を作成までに要する処理時間を大幅に短縮して、サーバ装置側の認識処理負担を大幅に軽減できる。

〔実施態様９〕
前記帳票データの各ページの帳票認識を行う帳票認識手段（図３に示すＯＣＲ処理部１２２）と、前記帳票認識手段により認識される各ページの帳票認識結果と前記テンプレート記憶手段に記憶される帳票種別が一致しない場合に、帳票エラーを通知する通知手段（図２に示すコントローラ部ＣＯＮＴ２が図示しないネットワークコントローラに接続されるネットワークを介して図１に示したクライアントＰＣ１３０等に通知する）とを有することを特徴とする実施態様８記載のサーバ装置。

これにより、取得される帳票データの各ページが登録されている帳票種別に一致するか判別することで、画像読取り装置側で帳票原稿中の各ページの順序が変更されて読み取られた場合や、画像読取り装置側で帳票原稿中に他の帳票原稿が紛れ込んで読み取られた場合を事前に認識して、帳票データの真偽性を考慮した、帳票認識処理を行うことも可能となり、電子化される帳票の各ページのデータに対する信頼性を高めることができる。

〔実施態様１０〕
前記通知手段は、前記画像読取り装置、またはネットワークを介して通信可能なデータ処理装置に帳票エラーを通知することを特徴とする実施態様８記載のサーバ装置。

これにより、帳票エラーとなっている帳票データが生成されていることを、帳票入力者等にその旨を確実に通知して、帳票原稿の確認と再入力作業を催促することができる。

〔実施態様１１〕
画像読取り装置が読み取る画像情報をネットワークを介してサーバ装置に転送して画像処理を行う画像処理システムであって、前記画像読取り装置は、読み取る帳票原稿の種別と各帳票のページ構成情報を記憶する帳票情報記憶手段と、読み取る帳票原稿の種別を指定する指定手段と、複数部数一括して帳票原稿をページ単位にスキャンして帳票原稿イメージを出力するスキャン手段と、前記スキャン手段により一括してスキャンされる前記帳票原稿イメージを前記指定手段により指定される帳票原稿の種別に基づき、前記帳票情報記憶手段に記憶されるページ情報に基づいてまとった帳票データを生成する生成手段と、前記生成手段により生成される帳票データを前記サーバに送信する送信手段とを有し、前記サーバ装置は、文字認識処理するための帳票構成を示すテンプレートを帳票種別毎に記憶するテンプレート記憶手段と、前記帳票データに付与される帳票種別に従い前記テンプレート記憶手段から特定されるテンプレートに基づき、前記帳票データの各ページに文字認識処理を行う文字認識処理手段と、前記文字認識処理手段により認識される各ページのテキストデータを電子化帳票ファイルとして生成するファイル生成手段とを有することを特徴とする画像処理システム。

これにより、実施態様１、８と同等の効果を期待できる。

〔実施態様１２〕
読み取る帳票原稿の種別と各帳票のページ構成情報を記憶する帳票情報記憶手段を備え、帳票原稿を読み取って得られる画像情報をネットワークを介してサーバ装置に転送可能な画像読取り装置における画像処理方法であって、読み取る帳票原稿の種別を指定する指定ステップ（図５に示すステップＳ５）と、複数部数一括して帳票原稿をページ単位にスキャンして帳票原稿イメージを出力するスキャンステップ（図６に示すステップＳ１７）と、前記スキャンステップにより一括してスキャンされる前記帳票原稿イメージを前記指定ステップにより指定される帳票原稿の種別に基づき、前記帳票情報記憶手段に記憶されるページ情報に基づいてまとった帳票データを生成する生成ステップ（図６に示すステップＳ１８）と、前記生成ステップにより生成される帳票データを前記サーバに送信する送信ステップ（図７に示すステップＳ２８）とを有することを特徴とする画像処理方法。

これにより、実施態様１と同等の効果を期待できる。

〔実施態様１３〕
前記各帳票のページ構成情報は、実際に必要なページ数と、総ページ数と、各ページのページサイズと、両面属性と、各ページスキャンモードのリストを含むことを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様２と同等の効果を期待できる。

〔実施態様１４〕
前記生成ステップは、前記帳票データに帳票種別、ページ数、帳票イメージを付与可能とすることを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様３と同等の効果を期待できる。

〔実施態様１５〕
前記生成ステップは、前記スキャン手段によりスキャンされた前記原稿イメージが白紙ページかどうかを認識可能とすることを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様４と同等の効果を期待できる。

〔実施態様１６〕
前記各帳票のページ構成情報は、ネットワークを介してデータ処理装置からダウンロード可能とすることを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様５と同等の効果を期待できる。

〔実施態様１７〕
前記各帳票のページ構成情報の両面属性は、片面、両面、混在の属性値を持つことを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様６と同等の効果を期待できる。

〔実施態様１８〕
前記各帳票のページ構成情報のスキャンモードリストは、ページ単位に文書モード、写真モード、無視モードの属性値を持つリストであることを特徴とする実施態様１２記載の画像処理方法。

これにより、実施態様７と同等の効果を期待できる。

〔実施態様１９〕
文字認識処理するための帳票構成を示すテンプレートを帳票種別毎に記憶するテンプレート記憶手段を備え、ネットワークを介して画像読取り装置により生成される帳票データを取得可能なサーバ装置における画像処理方法であって、前記帳票データに付与される帳票種別に従い前記テンプレート記憶手段から特定されるテンプレートに基づき、前記帳票データの各ページに文字認識処理を行う文字認識処理ステップ（図８に示すステップＳ５８、Ｓ５９）と、前記文字認識処理ステップにより認識される各ページのテキストデータを電子化帳票ファイルとして生成するファイル生成ステップ（図８に示すステップＳ６０）とを有することを特徴とする画像処理方法。

これにより、実施態様８と同等の効果を期待できる。

〔実施態様２０〕
前記帳票データの各ページの帳票認識を行う帳票認識ステップ（図９に示すステップＳ７４）と、前記帳票認識ステップにより認識される各ページの帳票認識結果と前記テンプレート記憶手段に記憶される帳票種別が一致しない場合に、帳票エラーを通知する通知ステップ（図９に示すステップＳ７６）とを有することを特徴とする実施態様１９記載の画像処理方法。

これにより、実施態様９と同等の効果を期待できる。

〔実施態様２１〕
前記通知ステップは、前記画像読取り装置、またはネットワークを介して通信可能なデータ処理装置に帳票エラーを通知することを特徴とする実施態様２０記載の画像処理方法。

これにより、実施態様１０と同等の効果を期待できる。

〔実施態様２２〕
実施態様１２〜２１のいずれかに記載の画像処理方法を実行させるためのプログラムを格納したことを特徴とするコンピュータが読み取り可能な記憶媒体。

これにより、実施態様１２〜２１と同等の効果を期待できる。

〔実施態様２３〕
実施態様１２〜２１のいずれかに記載の画像処理方法を実行させることを特徴とするプログラム。

これにより、実施態様１２〜２１と同等の効果を期待できる。

第１実施形態を示す画像読取り装置およびサーバ装置を適用可能な画像処理システムの構成を説明するブロック図である。 図１に示したＭＦＰとサーバの原稿処理状例を説明する概略図である。 図１に示したサーバのデータ処理例を説明する概略図である。 図３に示したイメージ帳票ファイルのフォーマット例を示す構造図である。 本実施形態に係る画像読取り装置における第１のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第２のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第３のデータ処理手順の一例を示すフローチャートである。 本実施形態に係るサーバ装置における第１のデータ処理手順の一例を示すフローチャートである。 本実施形態に係るサーバ装置における第２のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第４のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第５のデータ処理手順の一例を示すフローチャートである。 図２に示した帳票パターン情報テーブルの一例を示す図である。 本実施形態に係る画像読取り装置における第６のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第７のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における第８のデータ処理手順の一例を示すフローチャートである。 本実施形態に係る画像読取り装置における片面の帳票原稿とイメージ帳票ファイルの関係の例を示す概略図である。 本実施形態に係る画像読取り装置における混在の帳票原稿とイメージ帳票ファイルの関係の例を示す概略図である。 本実施形態に係る画像読取り装置を適用可能な画像処理システムで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。 本実施形態に係るサーバ装置を適用可能な画像処理システムで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

符号の説明

１１０ ＭＦＰ
１１１ スキャナ
１１３ ドキュメントフィーダ
１２０ サーバ装置
１２１ イメージ帳票スプーラ
３００ イメージファイル
３１０ イメージ帳票
３２０ 帳票パターン情報テーブル
ＣＯＮＴ コントローラ部

Claims (10)

1. 帳票原稿を読み取って得られる画像情報をネットワークを介してサーバ装置に転送可能な画像読取り装置であって、
   複数のページから構成される帳票種別に対応し、少なくとも前記帳票種別のページ数を含む帳票構成情報を記憶する帳票情報記憶手段と、
   読み取る帳票原稿の帳票種別を指定する指定手段と、
   前記指定手段により指定された帳票種別のページ数を、前記帳票情報記憶手段に記憶されている前記情報構成情報に基づいて取得する取得手段と、
   複数の帳票を含む帳票原稿をページ単位にスキャンして帳票原稿データを生成するスキャン手段と、
   前記取得手段により取得された前記帳票種別のページ数に基づいて、前記スキャン手段により生成された帳票原稿データを１帳票分のページ数からなる帳票原稿データに分割する分割手段と、
   前記分割手段により分割されたそれぞれの帳票原稿データに対して、前記帳票構成情報を割り当て、前記サーバに送信する送信手段と、
   を有することを特徴とする画像読取り装置。
2. 前記分割手段は、前記スキャン手段により生成された帳票原稿データのうち、１帳票分のページ数に満たない帳票原稿データを保存しておき、次に分割を行う際に、前記保存しておいた帳票原稿データを取得し、前記スキャン手段により新たに生成された帳票原稿データと合わせて分割を行うことを特徴とする請求項１に記載の画像読取り装置。
3. 前記帳票情報記憶手段に記憶されている前記情報構成情報は、対応する帳票種別の両面属性を少なくとも含み、
   前記スキャン手段は、前記指定手段により指定された帳票種別に対応する両面属性に従って、原稿のスキャン及び前記帳票原稿データの生成を行うことを特徴とする請求項１または２のいずれかに記載の画像読取り装置。
4. 前記スキャン手段は、前記指定手段により指定された帳票種別に対応する両面属性が片面である場合には、帳票原稿の片面のみをスキャンし、前記指定手段により指定された帳票種別に対応する両面属性が両面である場合には、帳票原稿の両面をスキャンし、前記指定手段により指定された帳票種別に対応する両面属性が片面と両面との混在である場合には、帳票原稿をスキャンし、スキャンした原稿に含まれる複数ページのうち、白紙であるページの帳票原稿データを生成せず、スキャンした原稿に含まれる白紙でないページの帳票原稿データを生成することを特徴とする請求項３に記載の画像読取り装置。
5. 前記帳票情報記憶手段に記憶されている前記情報構成情報は、対応する帳票種別に含まれる各ページにおけるスキャンの必要の有無を示すスキャンモード情報を少なくとも含み、
   前記スキャン手段は、帳票原稿に含まれる複数ページのうち、前記指定手段により指定された帳票種別に対応するスキャンモード情報においてスキャンの必要があると示されているページをスキャンし、スキャンの必要がないと示されているページをスキャンしないことを特徴とする請求項１乃至４のいずれか１項に記載の画像読取り装置。
6. 帳票原稿を読み取って得られる画像情報をネットワークを介してサーバ装置に転送可能な画像読取り装置における画像処理方法であって、
   複数のページから構成される帳票種別に対応し、少なくとも前記帳票種別のページ数を含む帳票構成情報を帳票情報記憶手段に記憶する帳票情報記憶工程と、
   読み取る帳票原稿の帳票種別を指定する指定工程と、
   前記指定工程により指定された帳票種別のページ数を、前記帳票情報記憶手段に記憶されている前記情報構成情報に基づいて取得する取得工程と、
   複数の帳票を含む帳票原稿をページ単位にスキャンして帳票原稿データを生成するスキャン工程と、
   前記取得工程により取得された前記帳票種別のページ数に基づいて、前記スキャン工程により生成された帳票原稿データを１帳票分のページ数からなる帳票原稿データに分割する分割工程と、
   前記分割工程により分割されたそれぞれの帳票原稿データに対して、前記帳票構成情報を割り当て、前記サーバに送信する送信工程と、
   を有することを特徴とする画像処理方法。
7. 前記分割工程は、前記スキャン工程により生成された帳票原稿データのうち、１帳票分のページ数に満たない帳票原稿データを保存しておき、次に分割を行う際に、前記保存しておいた帳票原稿データを取得し、前記スキャン工程により新たに生成された帳票原稿データと合わせて分割を行うことを特徴とする請求項６に記載の画像処理方法。
8. 前記帳票情報記憶工程に記憶されている前記情報構成情報は、対応する帳票種別の両面属性を少なくとも含み、
   前記スキャン工程は、前記指定工程により指定された帳票種別に対応する両面属性に従って、原稿のスキャン及び前記帳票原稿データの生成を行うことを特徴とする請求項６または７のいずれかに記載の画像処理方法。
9. 前記スキャン工程は、前記指定工程により指定された帳票種別に対応する両面属性が片面である場合には、帳票原稿の片面のみをスキャンし、前記指定工程により指定された帳票種別に対応する両面属性が両面である場合には、帳票原稿の両面をスキャンし、前記指定工程により指定された帳票種別に対応する両面属性が片面と両面との混在である場合には、帳票原稿をスキャンし、スキャンした原稿に含まれる複数ページのうち、白紙であるページの帳票原稿データを生成せず、スキャンした原稿に含まれる白紙でないページの帳票原稿データを生成することを特徴とする請求項８に記載の画像処理方法。
10. 前記帳票情報記憶手段に記憶されている前記情報構成情報は、対応する帳票種別に含まれる各ページにおけるスキャンの必要の有無を示すスキャンモード情報を少なくとも含み、
    前記スキャン工程は、帳票原稿に含まれる複数ページのうち、前記指定工程により指定された帳票種別に対応するスキャンモード情報においてスキャンの必要があると示されているページをスキャンし、スキャンの必要がないと示されているページをスキャンしないことを特徴とする請求項６乃至９のいずれか１項に記載の画像処理方法。

Images