(57)【要約】【課題】本発明は、ＯＣＲ認識結果に対する訂正内容に応じて訂正箇所を確認できる仕組みを提供することを目的とする。【解決手段】本発明は、複数の文字列の領域を含む画像から認識した文字列および当該文字列を認識した領域を認識データとして取得する情報処理装置であって、前記取得した認識データの訂正を受け付ける受付手段と、前記受け付けた訂正の前後の認識データに基づいて、当該訂正の内容が所定の条件を満たすか否かを判定する判定手段と、前記所定の条件を満たすと判定された場合に、前記訂正を受け付けた認識データの訂正箇所を通知する通知手段とを備えることを特徴とする。【選択図】図４
2020170465.tif 000002
【特許請求の範囲】
【請求項１】
複数の文字列の領域を含む画像から認識した文字列および当該文字列を認識した領域を認識データとして取得する情報処理装置であって、
前記取得した認識データの訂正を受け付ける受付手段と、
前記受け付けた訂正の前後の認識データに基づいて、当該訂正の内容が所定の条件を満たすか否かを判定する判定手段と、
前記所定の条件を満たすと判定された場合に、前記訂正を受け付けた認識データの訂正箇所を通知する通知手段と
を備えることを特徴とする情報処理装置。
【請求項２】
前記受付手段により前記認識した文字列の訂正を受け付けた場合に、前記判定手段は所定の文字訂正パターンに基づいて判定することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記判定手段は、前記受付手段により前記文字列を認識した領域の訂正を受け付けたか否かにより判定することを特徴とする請求項１または２に記載の情報処理装置。
【請求項４】
前記通知手段は、前記所定の条件を満たすと判定された場合に、前記画像において前記認識データの訂正箇所に対応する領域を識別表示することを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
【請求項５】
複数の文字列の領域を含む画像から認識した文字列および当該文字列を認識した領域を認識データとして取得する情報処理装置の制御方法であって、
受付手段が、前記取得した認識データの訂正を受け付ける受付ステップと、
判定手段が、前記受け付けた訂正の前後の認識データに基づいて、当該訂正の内容が所定の条件を満たすか否かを判定する判定ステップと、
通知手段が、前記所定の条件を満たすと判定された場合に、前記訂正を受け付けた認識データの訂正箇所を通知する通知ステップと
を備えることを特徴とする情報処理装置の制御方法。
【請求項６】
複数の文字列の領域を含む画像から認識した文字列および当該文字列を認識した領域を認識データとして取得する情報処理装置において実行可能なプログラムであって、
前記情報処理装置を、
前記取得した認識データの訂正を受け付ける受付手段と、
前記受け付けた訂正の前後の認識データに基づいて、当該訂正の内容が所定の条件を満たすか否かを判定する判定手段と、
前記所定の条件を満たすと判定された場合に、前記訂正を受け付けた認識データの訂正箇所を通知する通知手段
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＯＣＲ結果の訂正内容を確認する技術に関する。
【背景技術】
【０００２】
ＯＣＲ（Ｏｐｔｉｃａｌ  Ｃｈａｒａｃｔｅｒ  Ｒｅｃｏｇｎｉｔｉｏｎ。光学文字認識）を使ってテキスト情報を画像より抽出する技術が広く知られているが、アナログ情報をデジタル情報に変換するという性質上、ＯＣＲの精度は１００％ではない。そのため、ＯＣＲの結果を確認・訂正する手順が必要とされている。また、ＯＣＲの対象のドキュメントが、請求書のような業務帳票である場合、ＯＣＲで読み取ったデータを最終的に会計システムに登録する前に、担当部門の上長等の承認者による承認が必要となっている。具体的には、請求書のケースでは、承認者は請求書画像から読み取った請求内容（特に請求元、請求対象、請求金額）を承認時に確認している。
【０００３】
特許文献１には、ＯＣＲ結果の確からしさを確認するために、認識処理の各処理（前処理、認識処理、解析処理）の状況を取得し、取得した処理状況により評価した信頼性情報に基づいて、認識候補の確からしさを評価、分類する技術が示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−１４６０７５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、通常の業務の流れとして、承認者が承認する前に、業務担当者が目視でＯＣＲ結果の確認を行い、認識結果に誤りがある場合には訂正を行う。この作業にはＯＣＲ認識誤りの見落としや訂正時の入力ミス等のリスクが存在する。また、業務担当者が故意に請求金額等を変更して会社に不正な金額を請求するリスクも考えられる。
【０００６】
特許文献１に記載の方法では、ＯＣＲ認識結果の確からしさを確認することはできるが、ＯＣＲ認識結果そのものが変更された場合に、その変更内容が妥当か否かをすぐに確認することはできない。
【０００７】
そこで、本発明は、ＯＣＲ認識結果に対する訂正内容に応じて訂正箇所を確認できる仕組みを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、複数の文字列の領域を含む画像から認識した文字列および当該文字列を認識した領域を認識データとして取得する情報処理装置であって、前記取得した認識データの訂正を受け付ける受付手段と、前記受け付けた訂正の前後の認識データに基づいて、当該訂正の内容が所定の条件を満たすか否かを判定する判定手段と、前記所定の条件を満たすと判定された場合に、前記訂正を受け付けた認識データの訂正箇所を通知する通知手段とを備えることを特徴とする。
【発明の効果】
【０００９】
本発明によれば、ＯＣＲ認識結果に対する訂正内容に応じて訂正箇所を確認できる仕組みを提供できるようになる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態である情報処理システム１の構成の一例を示すシステム構成図である。
【図２】情報処理システム１を構成するクライアントＰＣ２００、業務サーバ３００、ＤＢサーバ４００、ＯＣＲサーバ５００、メールサーバ６００に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【図３】情報処理システム１を構成する複合機１００に適用可能な情報処理装置のハードウェア構成の一例を示すブロック図である。
【図４】情報処理システム１を構成する各情報処理装置の機能構成の一例を示すブロック図である。
【図５】情報処理システム１のＯＣＲ（読取・認識）処理の一例を示すフローチャートである。
【図６】情報処理システム１のＯＣＲ（読取・認識）処理の一例を示すフローチャートである。
【図７】情報処理システム１のＶｅｒｉｆｉｃａｔｉｏｎ（確認・訂正）処理の一例を示すフローチャートである。
【図８】情報処理システム１のＶｅｒｉｆｉｃａｔｉｏｎ（確認・訂正）処理の一例を示すフローチャートである。
【図９】情報処理システム１のＡｐｐｒｏｖａｌ（承認／否認）処理の一例を示すフローチャートである。
【図１０】情報処理システム１のＡｐｐｒｏｖａｌ（承認／否認）処理の一例を示すフローチャートである。
【図１１】クライアントＰＣ２００のブラウザに表示される請求書詳細画面の一例を示す画面イメージである。
【図１２】クライアントＰＣ２００のブラウザに表示される承認依頼詳細画面の一例を示す画面イメージである。
【図１３】クライアントＰＣ２００のブラウザに表示される承認依頼詳細画面の一例を示す画面イメージである。
【図１４】情報処理システム１で使用するデータ類の一例を示すデータ構成図である。
【発明を実施するための形態】
【００１１】
以下、図面を参照して、本発明の実施形態を詳細に説明する。
【００１２】
図１は、本発明における情報処理システム１のシステム構成の一例を示す図である。
【００１３】
情報処理システム１は、複合機１００、クライアントＰＣ２００、業務サーバ３００、ＤＢサーバ４００、ＯＣＲサーバ５００、メールサーバ６００が、ＬＡＮ１０（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等のネットワークにて通信可能に接続されて構成される。
【００１４】
それぞれの情報処理機器の機能については、図４にて後述する。
【００１５】
以上で図１のシステム構成図の説明を終了する。
【００１６】
以下、図２を用いて、図１に示したクライアントＰＣ２００、業務サーバ３００、ＤＢサーバ４００、ＯＣＲサーバ５００、メールサーバ６００に適用可能な情報処理装置のハードウェア構成の一例について説明する。
【００１７】
図２は、情報処理装置のハードウェア構成の一例を示すブロック図である。
【００１８】
図２において、２００１はＣＰＵで、システムバス２００４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２００２あるいは外部メモリ２０１１には、ＣＰＵ２００１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ  Ｉｎｐｕｔ  ／  Ｏｕｔｐｕｔ  Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。
【００１９】
２００３はＲＡＭで、ＣＰＵ２００１の主メモリ、ワークエリア等として機能する。ＣＰＵ２００１は、処理の実行に際して必要なプログラム等をＲＯＭ２００２あるいは外部メモリ２０１１からＲＡＭ２００３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。
【００２０】
また、２００５は入力コントローラで、キーボード（ＫＢ）２００９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２００６はビデオコントローラで、ディスプレイ２０１０等の表示器への表示を制御する。なお、表示器はＣＲＴや、液晶ディスプレイ等の様々な種類が存在する。
【００２１】
２００７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶する外部記憶装置（ハードディスク（ＨＤ））や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるＣＦカードメモリ等の外部メモリ２０１１へのアクセスを制御する。
【００２２】
２００８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ１０）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。
【００２３】
なお、ＣＰＵ２００１は、例えばＲＡＭ２００３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ディスプレイ２０１０上での表示を可能としている。また、ＣＰＵ２００１は、ディスプレイ２０１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。
【００２４】
本発明を実現するための後述する各種プログラムは、外部メモリ２０１１に記録されており、必要に応じてＲＡＭ２００３にロードされることによりＣＰＵ２００１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２０１１に格納されており、これらについての詳細な説明も後述する。
【００２５】
以上で図２のハードウェア構成図の説明を終了する。
【００２６】
以下、図３を用いて、図１に示した複合機１００に適用可能な情報処理装置のハードウェア構成の一例について説明する。
【００２７】
図３は、情報処理装置のハードウェア構成の一例を示すブロック図である。
【００２８】
図３において、３０２０はコントローラユニットで、画像入力デバイスとして機能するスキャナ３０６０や、画像出力デバイスとして機能するプリンタ３０５０と接続する一方、ＬＡＮ（例えば、図１に示したＬＡＮ１０）や公衆回線（ＷＡＮ）（例えば、ＰＳＴＮまたはＩＳＤＮ等）と接続することで、画像データやデバイス情報の入出力を行う。
【００２９】
コントローラユニット３０２０において、３００１はＣＰＵで、システム全体を制御するプロセッサである。３００２はＲＡＭで、ＣＰＵ３００１が動作するためのシステムワークメモリであり、プログラムを記録するためのプログラムメモリや、画像データを一時記録するための画像メモリでもある。
【００３０】
３００３はＲＯＭで、システムのブートプログラムや各種制御プログラムが格納されている。３００４は外部記憶装置（ハードディスクドライブ（ＨＤＤ））で、システムを制御するための各種プログラム，画像データ等を格納する。
【００３１】
３００７は操作部インタフェース（操作部Ｉ／Ｆ）で、操作部（ＵＩ）３０３０とのインタフェース部であり、操作部３０３０に表示する画像データを操作部３０３０に対して出力する。また、操作部Ｉ／Ｆ３００７は、操作部３０３０から本システム使用者が入力した情報（例えば、ユーザ情報等）をＣＰＵ３００１に伝える役割をする。なお、操作部３０３０はタッチパネルを有する表示部を備え、該表示部に表示されたボタンを、ユーザが押下（指等でタッチ）することにより、各種指示を行うことができる。
【００３２】
３００５はネットワークインタフェース（Ｎｅｔｗｏｒｋ  Ｉ／Ｆ）で、ネットワーク（ＬＡＮ）に接続し、データの入出力を行う。３００６はモデム（ＭＯＤＥＭ）で、公衆回線に接続し、ＦＡＸの送受信等のデータの入出力を行う。
【００３３】
３００９は外部インタフェース（外部Ｉ／Ｆ）で、ＵＳＢ、ＩＥＥＥ１３９４，プリンタポート，ＲＳ−２３２Ｃ等の外部入力を受け付けるＩ／Ｆ部であり、本実施形態においては認証で必要となるＩＣカードの読み取り用のカードリーダ３０４０が外部Ｉ／Ｆ３００９に接続されている。そして、ＣＰＵ３００１は、この外部Ｉ／Ｆ３００９を介してカードリーダ３０４０によるＩＣカードからの情報読み取りを制御し、該ＩＣカードから読み取られた情報を取得可能である。尚、ＩＣカードに限らず、ユーザを特定することが可能な記憶媒体であればよい。この場合、記憶媒体にはユーザを識別するための識別情報が記憶される。この識別情報は、記憶媒体の製造番号でも、ユーザが企業内で与えられるユーザコードであってもよい。
以上のデバイスがシステムバス３０１０上に配置される。
【００３４】
３００８はイメージバスインタフェース（ＩＭＡＧＥ  ＢＵＳ  Ｉ／Ｆ）であり、システムバス３０１０と画像データを高速で転送する画像バス３０１５とを接続し、データ構造を変換するバスブリッジである。
【００３５】
画像バス３０１５は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス３０１５上には以下のデバイスが配置される。
【００３６】
３０１１はラスタイメージプロセッサ（ＲＩＰ）で、例えば、ＰＤＬコード等のベクトルデータをビットマップイメージに展開する。３０１２はプリンタインタフェース（プリンタＩ／Ｆ）で、プリンタ３０５０とコントローラユニット３０２０を接続し、画像データの同期系／非同期系の変換を行う。また、３０１３はスキャナインタフェース（スキャナＩ／Ｆ）で、スキャナ３０６０とコントローラユニット３０２０を接続し、画像データの同期系／非同期系の変換を行う。
【００３７】
３０１４は画像処理部で、入力画像データに対し補正、加工、編集や、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。また、これに加えて、画像処理部３０１４は、画像データの回転や、多値画像データに対してはＪＰＥＧ、２値画像データはＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理を行う。
【００３８】
スキャナ３０６０は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサで走査することで、ラスタイメージデータとして電気信号に変換する。原稿用紙は原稿フィーダのトレイにセットし、装置使用者が操作部３０３０から読み取り起動指示することにより、ＣＰＵ３００１がスキャナ３０６０に指示を与え、フィーダは原稿用紙を１枚ずつフィードし原稿画像の読み取り動作を行う。
【００３９】
プリンタ３０５０は、ラスタイメージデータを用紙上の画像に変換する部分であり、その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。プリント動作の起動は、ＣＰＵ３００１からの指示によって開始する。なお、プリンタ３０５０には、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセットがある。
【００４０】
操作部３０３０は、ＬＣＤ表示部を有し、ＬＣＤ上にタッチパネルシートが貼られており、システムの操作画面を表示するとともに、表示してあるキーが押されるとその位置情報を操作部Ｉ／Ｆ３００７を介してＣＰＵ３００１に伝える。また、操作部３０３０は、各種操作キーとして、例えば、スタートキー、ストップキー、ＩＤキー、リセットキー等を備える。
【００４１】
ここで、操作部３０３０のスタートキーは、原稿画像の読み取り動作を開始する時などに用いる。スタートキーの中央部には、緑と赤の２色ＬＥＤがあり、その色によってスタートキーが使える状態にあるかどうかを示す。また、操作部３０３０のストップキーは、稼働中の動作を止める働きをする。また、操作部３０３０のＩＤキーは、使用者のユーザＩＤを入力する時に用いる。リセットキーは、操作部からの設定を初期化する時に用いる。
【００４２】
カードリーダ３０４０は、ＣＰＵ３００１からの制御により、ＩＣカード（例えば、ソニー社のＦｅｌｉＣａ（登録商標））内に記憶されている情報を読み取り、該読み取った情報を外部Ｉ／Ｆ３００９を介してＣＰＵ３００１へ通知する。
【００４３】
以上で図３のハードウェア構成図の説明を終了する。
【００４４】
図４を用いて、本実施形態の各装置の機能について説明する。
【００４５】
まず、複合機１００の処理を実行するための機能について説明する。
【００４６】
複合機１００はスキャン部１０１、ファイル送信部１０２から構成される。
【００４７】
スキャン部１０１は、複合機１００のスキャナ３０６０を制御して、原稿となる紙上の画像をデジタル化し、任意の画像形式に変換して、任意のサーバの任意のフォルダに送信する機能を提供する。ファイル形式について、例えば、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）、ＴＩＦＦ（Ｔａｇｅｄ  Ｉｍａｇｅ  Ｆｉｌｅ  Ｆｏｒｍａｔ）、ＰＤＦ（Ｐｏｒｔａｂｌｅ  Ｄｏｃｕｍｅｎｔ  Ｆｏｒｍａｔ）、ＸＰＳ（ＸＭＬ  Ｐａｐｅｒ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ）、ＯＯＸＭＬ（Ｏｆｆｉｃｅ  Ｏｐｅｎ  ＸＭＬ）などがある。
【００４８】
ファイル送信部１０２は、ＦＴＰ、ＳＭＢ、ＷｅｂＤＡＶなどのプロトコルを使って、任意のサーバに対してファイルを送信する。
【００４９】
次に、クライアントＰＣ２００の処理を実行するための機能について説明する。
【００５０】
クライアントＰＣ２００はブラウザ部２０１から構成される。
【００５１】
ブラウザ部２０１は、任意のサーバ上で実行されているＷｅｂアプリケーションにＨＴＴＰないしはＨＴＴＰＳプロトコルでリクエストを送信し、サーバから返されるＨＴＭＬメッセージのレスポンスを、クライアントＰＣ２００上の画面にＵＩとして表示する。
【００５２】
次に、業務サーバ３００の処理を実行するための機能について説明する。
【００５３】
業務サーバ３００は画面表示部３０１、データ送受信部３０２、業務データ管理部３０３から構成される。
【００５４】
画面表示部３０１は、クライアントＰＣ２００のブラウザ部２０１等からのＨＴＴＰ・ＨＴＴＰＳプロトコルを使ったリクエストを受け付け、レスポンスとして画面情報をＨＴＭＬデータにして返却する。
【００５５】
データ送受信部３０２は、ＤＢサーバ４００のデータ送受信部４０２に対して、請求書データ１３０３のリクエストを送信する。また、ＤＢサーバ４００のデータ送受信部４０２から請求書データ１３０３のレスポンスを受信する
業務データ管理部３０３は、データ送受信部３０２で取得した請求書データ１３０３を参照し、画面表示部３０１で返却する画面情報の切り替えを行う。また、データ送受信部３０２で送信する請求書データ１３０３を書き換える。
【００５６】
次に、ＤＢサーバ４００の処理を実行するための機能について説明する。
【００５７】
ＤＢサーバ４００はデータ管理部４０１、データ送受信部４０２、業務データ記憶部４１０から構成される。
【００５８】
データ管理部４０１はデータ送受信部４０２で取得した請求書データ１３０３を業務データ記憶部４１０に書き込んだり、業務データ記憶部４１０の請求書データ１３０３を書き換えたりする。
【００５９】
データ送受信部４０２は業務サーバ３００のデータ送受信部３０２で取得したリクエストに対して請求書データ１３０３をレスポンスとして返却する。また、ＯＣＲサーバ５００からＯＣＲで抽出されたテキスト情報を受信する。
【００６０】
次に、ＯＣＲサーバ５００の処理を実行するための機能について説明する。
【００６１】
ＯＣＲサーバ５００はメール監視部５０１、ＯＣＲ部５０２、ネットワーク共有フォルダ部５０３から構成される。
【００６２】
メール監視部５０１はメールサーバ６００のメール管理部６０１を監視し、新規のメールが存在するかを確認したり、添付ファイルが存在するかを確認したりする。添付ファイルが存在する場合にはネットワーク共有フォルダ部５０３にファイルを保存する。
【００６３】
ＯＣＲ部５０２はネットワーク共有フォルダ部５０３に保存されたファイルを読み込み、ＯＣＲを行って画像からテキスト情報を抽出する。抽出したテキスト情報をＤＢサーバ４００のデータ送受信部４０２に送信する。
【００６４】
ネットワーク共有フォルダ部５０３は複合機１００のファイル送信部１０２から受信したファイルを保存したり、ＯＣＲサーバ５００のメール監視部５０１で存在を確認した添付ファイルを保存したりする。
【００６５】
次に、メールサーバ６００の処理を実行するための機能について説明する。
【００６６】
メールサーバ６００はメール管理部６０１、メール送受信部６０２から構成される。
【００６７】
メール管理部６０１は受信したメール及び送信したメールの管理を行う。ＯＣＲサーバ５００のメール監視部５０１からの監視を受け、新規のメールが存在する場合には該当のメール情報をＯＣＲサーバ５００のメール監視部５０１に引き渡す。
【００６８】
メール送受信部６０２はメールを受信したり、メールを送信したりする。
【００６９】
次に、図５、図６、図７、図８、図９、図１０を参照しながら、本発明に係る各ステップでの処理について説明する。
【００７０】
まず、図５、図６を参照しながら、ＯＣＲ（読取・認識）処理の処理フローについて説明する。
【００７１】
メールの添付ファイルを取得し、ＯＣＲするフローについて図５を用いて説明する。ＯＣＲサーバ５００ではメールサーバ６００に新規メールが存在するかを監視する（ステップＳ５００）。新規メールが存在する場合にはメールサーバ６００に対してメール取得の要求を行う（ステップＳ５０１）。メールサーバ６００はＯＣＲサーバ５００のメール取得要求に対し、メールの返却を行う（ステップＳ５０２）。ＯＣＲサーバ５００はメールサーバ６００から返却されたメールを受信する（ステップＳ５０３）。ＯＣＲサーバ５００はメールに添付ファイルが存在するか確認する（ステップＳ５０４）。添付ファイルが存在しない場合、ＯＣＲサーバ５００は引き続きメールサーバ６００の監視を行う。添付ファイルが存在する場合には添付ファイルをネットワーク共有フォルダに保存する（ステップＳ５０５）。
【００７２】
ＯＣＲサーバ５００はステップＳ５０５でネットワーク共有フォルダに保存されたファイルに対してＯＣＲを行う（ステップＳ５０６）。ＯＣＲ完了後、ＯＣＲしたデータ及び対象となったファイルをＤＢサーバ４００に送信する（ステップＳ５０７）。
【００７３】
ＤＢサーバ４００はＯＣＲサーバ５００から送信されたＯＣＲデータと対象となったファイルを受信する（ステップＳ５０８）。ＤＢサーバ４００は受信したＯＣＲデータを図１４の請求書データ１３０３のレコードとして業務データ記憶部４１０に保存し、対象となったデータを図１４のファイルデータ１３１４として保存する（ステップＳ５０９）。
【００７４】
複合機のスキャンファイルをＯＣＲするフローについて図６を用いて説明する。複合機１００でスキャンされたファイルをＯＣＲサーバ５００に送信する（ステップＳ６００）。ＯＣＲサーバ５００では受信したスキャンファイルをネットワーク共有フォルダに保存する（ステップＳ６０１）。Ｓ６０１以降の処理については図５と同様となるため、割愛する。
【００７５】
次に、図７、図８を参照しながらＶｅｒｉｆｉｃａｔｉｏｎ（確認・訂正）処理の処理フローについて説明する。
【００７６】
クライアントＰＣ２００はブラウザを起動する（ステップＳ７００）。ブラウザから本システムにアクセスすることで、クライアントＰＣ２００はログイン画面を業務サーバ３００にリクエストする（ステップＳ７０１）。業務サーバ３００はログイン画面を生成する（ステップＳ７０２）。クライアントＰＣ２００は生成されたログイン画面をブラウザに描画する（ステップＳ７０３）。
【００７７】
クライアントＰＣ２００はブラウザからログイン画面で入力を受け付け、業務サーバ３００に入力情報を送信する（ステップＳ７０４）。業務サーバ３００は図１４のユーザデータ１３００と入力情報を照会し、認証を行う（ステップＳ７０５）。
【００７８】
認証後、業務サーバ３００はログインユーザに紐づく請求書リストの取得をＤＢサーバ４００に対してリクエストする（ステップＳ７０６）。ＤＢサーバ４００はログインユーザのユーザＩＤと図１４の請求書データ１３０３の担当者ＩＤ１３１０が一致する請求書データを業務データ記憶部４１０から取得して請求書リストを返却する（ステップＳ７０７）。業務サーバ３００は取得した請求書リストから請求書リスト画面を生成し、クライアントＰＣ２００に返却する（ステップＳ７０８）。クライアントＰＣ２００は返却された請求書リスト画面をブラウザに描画する（ステップＳ７０９）。
【００７９】
クライアントＰＣ２００はブラウザから請求書選択を受け付け、業務サーバ３００に選択された請求書の情報を送信する（ステップＳ７１０）。業務サーバ３００では受信した請求書の情報をＤＢサーバ４００に引き渡し、請求書詳細情報を要求する（ステップＳ７１１）。ＤＢサーバ４００は受信した請求書の情報をキーとして業務データ記憶部４１０から該当する請求書の請求書データ１３０３を抽出する。抽出した請求書データ１３０３のファイルＩＤ１３１３に一致するファイルデータ１３１４も併せて抽出する。ＤＢサーバ４００は抽出した請求書データ１３０３とファイルデータ１３１４を請求書の詳細情報として業務サーバ３００に返却する（ステップＳ７１２）。業務サーバ３００は取得した請求書の詳細情報を基に図１１の請求書詳細画面１１００を生成して、クライアントＰＣ２００に返却する（ステップＳ７１３）。クライアントＰＣ２００は請求書詳細画面１１００をブラウザに表示する（ステップＳ７１４）。請求書詳細画面１１００は、左側にＯＣＲ処理の対象となったスキャンファイルの画像プレビュー、右側に請求データとしてＯＣＲの認識結果を表示する。
【００８０】
クライアントＰＣ２００はブラウザから領域訂正、または、手入力訂正を受け付ける。ここで、領域訂正・手入力訂正について記載する。
【００８１】
領域訂正はＯＣＲ処理の読み取り領域の誤りを訂正するものである。クライアントＰＣ２００のブラウザに表示された図１１の請求書詳細画面１１００にて請求データの入力項目Ｇｒｏｓｓ Ａｍｔのフィールド値（１１０１）にカーソルを合わせると、スキャンファイルの１１０３のように読み取り対象となった領域を強調表示する（本例では、誤った領域Ｓａｌｅｓ Ｔａｘを認識している）。スキャンファイルに強調表示された読み取り領域が請求データの対象項目と一致しない場合に、ＯＣＲ処理の読み取り領域の誤りを訂正し、訂正した領域についてＯＣＲを再実行する。操作としては、例えば、請求書詳細画面１１０２において、項目Ｇｒｏｓｓ Ａｍｔのフィールド値にフォーカスがある状態で、スキャンファイルの領域を１１０４のように移動する。これが領域訂正である。
【００８２】
手入力訂正はＯＣＲ処理の認識結果の請求データに誤りがある場合に、直接認識結果を訂正するものである。ＯＣＲ処理の読み取り領域は請求データの対象項目と一致していても、ＯＣＲした結果、スキャンファイルの値と請求データの値が一致しないことがある。例として、数字の「１」と「７」や「０」と「６」など、誤った数値として認識する場合などが挙げられる。このような場合に、認識結果をスキャンファイルに一致させるよう、請求データを直接訂正する。これが手入力訂正である。
【００８３】
クライアントＰＣ２００はブラウザに表示している請求書詳細画面１１００から領域訂正を受け付ける（ステップＳ８００）。クライアントＰＣ２００は訂正前の領域と訂正後の領域のデータをブラウザ内で保持し（ステップＳ８０１）、領域訂正フラグを有効化する（ステップＳ８０２）。
【００８４】
クライアントＰＣ２００はブラウザに表示している請求書詳細画面１１００から手入力訂正を受け付ける（ステップＳ８０３）。クライアントＰＣ２００は訂正前のフィールド値と訂正後のフィールド値のデータをブラウザ内で保持し（ステップＳ８１５）、直接訂正フラグを有効化する（ステップＳ８０４）。
【００８５】
請求書詳細画面１１００の承認依頼ボタンが押下されると、クライアントＰＣ２００は図１４の請求書データ１３０３のデータを業務サーバ３００に送信する（ステップＳ８０５）。
【００８６】
業務サーバ３００はクライアントＰＣ２００から請求書データ１３０３のデータを受信する（ステップＳ８０６）。
【００８７】
業務サーバ３００は請求書データ１３０３のフィールド毎に直接訂正フラグ１３０６が有効であるかを確認する（ステップＳ８０７）。直接訂正フラグが有効である場合、業務サーバ３００は訂正前のフィールド値と訂正後のフィールド値により、手入力訂正の内容がＯＣＲ誤認パターンと一致するかを判断する（ステップＳ８０８）。ＯＣＲ誤認パターンとは、数字の「１」と「７」や「０」と「６」などＯＣＲ処理において認識誤りの可能性が高いケースを集めたものである。ＯＣＲ誤認パターンはパターンテーブル（不図示）で設定してもよいし、プログラムで判断してもよい。ＯＣＲ誤認パターンと手入力訂正の内容が一致する場合、業務サーバ３００は重要度を低に設定する（ステップＳ８０９）。ＯＣＲ誤認パターンと訂正内容が一致することから、ＯＣＲの認識誤りを訂正した可能性が高いためである。ＯＣＲ誤認パターンと手入力訂正の内容が一致しない場合、業務サーバ３００は重要度を高に設定する（ステップＳ８１０）。ＯＣＲ誤認パターンと訂正内容が一致しないため、入力誤りや意図的に数値の変更を行った可能性が高いためである。
【００８８】
請求書データ１３０３の各フィールドに対して直接訂正フラグの確認とＯＣＲ誤認パターンの確認が終わった後、業務サーバ３００は請求書データ１３０３をＤＢサーバ４００に送信する（ステップＳ８１１）。
【００８９】
ＤＢサーバ４００は受信した請求書データ１３０３で業務データ記憶部４１０の該当する請求書データ１３０３を更新する。（ステップＳ８１２）
業務サーバ３００は承認依頼完了画面を生成し、クライアントＰＣ２００に送信する（ステップＳ８１３）。
【００９０】
クライアントＰＣ２００はブラウザに承認依頼完了画面（不図示）を表示する（ステップＳ８１４）。
【００９１】
次に、図９、１０を参照しながらＡｐｐｒｏｖａｌ（承認／否認）処理の処理フローについて説明する。
【００９２】
ステップＳ９００からステップＳ９０５までは図７のステップＳ７００からステップＳ７０５までと同様の処理となるため、割愛する。
【００９３】
ステップＳ７０５の認証後、業務サーバ３００はログインユーザに紐づく承認依頼リストの取得をＤＢサーバ４００に対してリクエストする（ステップＳ９０６）。ＤＢサーバ４００はログインユーザのユーザＩＤと図１４の請求書データ１３０３の承認者ＩＤ１３１１が一致する請求書データを業務データ記憶部４１０から取得して承認依頼リストを返却する（ステップＳ９０７）。業務サーバ３００は取得した承認依頼リストから承認依頼リスト画面を生成し、クライアントＰＣ２００に返却する（ステップＳ９０８）。クライアントＰＣ２００は返却された承認依頼リスト画面をブラウザに描画する（ステップ９０９）。
【００９４】
クライアントＰＣ２００はブラウザから承認依頼選択を受け付け、業務サーバ３００に選択された承認依頼の情報を送信する（ステップＳ９１０）。業務サーバ３００では受信した承認依頼の情報をＤＢサーバ４００に引き渡し、承認依頼詳細情報を要求する（ステップＳ９１１）。ＤＢサーバ４００は受信した請求書の情報をキーとして業務データ記憶部４１０から該当する請求書の請求書データ１３０３を抽出する。抽出した請求書データ１３０３のファイルＩＤ１３１３に一致するファイルデータ１３１４も併せて抽出する。ＤＢサーバ４００は抽出した請求書データ１３０３とファイルデータ１３１４を承認依頼詳細情報として業務サーバ３００に返却する（ステップＳ９１２）。業務サーバ３００は取得した承認依頼詳細情報から承認依頼詳細画面１２２０を生成する。承認依頼詳細画面１２２０は、左側にＯＣＲ処理の対象となったスキャンファイルの画像プレビュー、右側に請求データとしてＯＣＲの認識結果または訂正結果を表示する。
【００９５】
承認依頼詳細画面を生成する際、業務サーバ３００は領域訂正フラグ・直接訂正フラグ・重要度の高低から表示情報を変更する。変更内容の一例を以下に示す。
【００９６】
業務サーバ３００は承認依頼詳細情報の各フィールドに対して、領域訂正フラグが有効であるかを判別する（ステップＳ１０００）。
【００９７】
領域訂正フラグが有効である場合、訂正前・訂正後領域を図１２の承認依頼詳細画面１２００のようにハイライトする（ステップＳ１００１）。具体的には請求データの領域訂正が行われたＧｒｏｓｓ Ａｍｔのフィールド値（１２０１）をハイライトする。また、スキャンデータの訂正前領域（１２０２）と訂正後領域（１２０３）を強調表示したうえ、矢印で結び訂正の前後を強調表示する（本例では、誤ってＳａｌｅｓ Ｔａｘの領域が読み取られていたが、正しくＧｒｏｓｓ Ａｍｔの領域に訂正した結果を表示している）。これにより承認依頼詳細画面を参照するユーザは訂正前及び訂正後の領域の変更を目視で確認しやすくなる。
【００９８】
業務サーバ３００は承認依頼詳細情報の各フィールドに対して、直接訂正フラグが有効であるかを判別する（ステップＳ１００２）。
【００９９】
直接訂正フラグが有効である場合、業務サーバ３００は重要度の高低を判別する（ステップＳ１００３）。
【０１００】
重要度が高い場合、生成する承認依頼詳細画面は図１３の１２１０のようになる（例えば、認識結果”１２，２４０”を”９２，２４０”に訂正した場合）。具体的には、訂正された領域を１２１１のように背景色を赤とし、１２１２のように強調マーク「！」を表示する（ステップＳ１００４）。これにより、承認依頼詳細画面を参照するユーザは直接フィールド値が変更されていることを判別できる。また、入力誤りや意図的に変更された値である可能性が高いことを目視で確認しやすくなる。
【０１０１】
重要度が低い場合、生成する承認依頼詳細画面は図１２の１２０４のようになる（例えば、認識結果”１２，２４６”を”１２，２４０”に訂正した場合）。具体的には、訂正された領域を１２０５のように文字色を赤で表示する（ステップＳ１００５）。これにより、承認依頼詳細画面を参照するユーザは直接フィールド値が変更されていることを判別できる。また、ＯＣＲの認識誤りを訂正した可能性が高いことを目視で確認しやすくなる。
【０１０２】
また、直接フィールド値が変更された場合に、スキャンファイルのプレビュー上で、変更内容に対応する領域を強調表示してもよい。
【０１０３】
領域訂正フラグが有効であり、かつ、直接訂正フラグが有効である場合について記載する。
【０１０４】
領域訂正フラグが有効であり、かつ、直接訂正フラグが有効であり、かつ、手入力訂正の重要度が高い場合、生成する承認依頼詳細画面は図１３の１２１３のようになる。具体的には、訂正された領域を１２１４のように背景色を赤とし、１２１５のように強調マーク「！」を表示する。また、スキャンデータの訂正前領域１２１６と訂正後領域１２１７を強調表示したうえ、矢印で結び訂正の前後を強調表示する。
【０１０５】
領域訂正フラグが有効であり、かつ、直接訂正フラグが有効であり、かつ、手入力訂正の重要度が低い場合、生成する承認依頼詳細画面は図１３の１２０６のようになる。具体的には、訂正された領域を１２０７のように文字色を赤とする。また、スキャンデータの訂正前領域１２０８と訂正後領域１２０９を強調表示したうえ、矢印で結び訂正の前後を強調表示する。
【０１０６】
このように、Ｖｅｒｉｆｉｃａｔｉｏｎステップでの訂正方法に従って重要度を付与し、承認依頼詳細画面の表示を変更することで、承認依頼詳細画面を参照するユーザは重点的に確認すべき箇所を目視で瞬時に判別できる。また、訂正時の入力誤りや不正な数値の修正の見落としを防止すことができ、ユーザの利便性が向上する。
【０１０７】
業務サーバ３００は上記のステップＳ１０００からステップＳ１００５までを経て、承認依頼詳細画面を生成し、クライアントＰＣ２００に送信する（ステップＳ１００６）。
【０１０８】
クライアントＰＣ２００はブラウザ上に業務サーバから承認依頼詳細画面を受信し、図１２の承認依頼詳細画面１２２０をブラウザに描画する（ステップＳ１００７）。
【０１０９】
クライアントＰＣ２００は承認依頼詳細画面の承認ボタンまたは否認ボタンから承認または否認を受け付け、業務サーバ３００に送信する（ステップＳ１００８）。
【０１１０】
業務サーバ３００は受信した承認または否認のステータスをＤＢサーバ４００に送信する（ステップＳ１００９）。
【０１１１】
ＤＢサーバ４００は受信した承認または否認のステータスによって、業務データ記憶部４１０に格納されている請求書データ１３０３のステータス１３１２を更新する（ステップＳ１０１０）。
【０１１２】
業務サーバ３００は承認または否認に従い、承認または否認完了画面を生成して、クライアントＰＣ２００に送信する（ステップＳ１０１１）。
【０１１３】
クライアントＰＣ２００は受信した承認または否認完了画面をブラウザ上に描画する（ステップＳ１０１２）。
【０１１４】
次に、図１１、図１２、図１３の各画面について説明する。
【０１１５】
図１１の請求書詳細画面１１００はＯＣＲ結果が正しく読み取られているか確認を行うための画面である。ＯＣＲ結果が正しくない場合には認識結果の編集も行われる。請求書詳細画面１１００は、少なくともスキャンファイルと請求データが表示される。スキャンファイルはＯＣＲの対象となっているファイルのプレビューが表示されるものである。請求データはＯＣＲの結果、抽出されたデータの参照及び編集を行うものである。
【０１１６】
請求書詳細画面１１００上の請求データはあくまでも一例であり、ＯＣＲの対象となる請求書のフォーマット、利用者によって異なるものである。請求書詳細画面１１００では請求データのフィールド（項目）の一例として、Ｆｒｏｍ、Ｂｉｌｌ Ｔｏ、ｉｎｖ Ｄａｔｅ、Ｇｒｏｓｓ Ａｍｔを含めている。Ｆｒｏｍは請求書に記載されているＦｒｏｍから抽出されたフィールドの表示箇所であり、請求元を示すものである。Ｂｉｌｌ Ｔｏは請求書に記載されているＢｉｌｌ Ｔｏから抽出されたフィールドの表示箇所であり、請求書の送付先を示すものである。ｉｎｖ Ｄａｔｅは請求書に記載されているｉｎｖ Ｄａｔｅから抽出されたフィールドの表示箇所であり、請求書の日付を示すものである。Ｇｒｏｓｓ Ａｍｔは請求書に記載されているＧｒｏｓｓ Ａｍｔから抽出されたフィールドの表示箇所であり、請求書の総額を示すものである。
【０１１７】
請求書詳細画面１１００は承認依頼ボタンを備えている。承認依頼ボタンが選択されると、該当のＯＣＲした請求書データは確認が完了したものとして扱われ、承認者への承認依頼に回される。
【０１１８】
図１１の請求書詳細画面１１０２は請求書詳細画面１１００と同様の画面であり、図８の領域訂正の受付（ステップＳ８００）について説明するものであるため、詳細の記載は割愛する。
【０１１９】
図１２の承認依頼詳細画面１２２０は請求書詳細画面１１００のＯＣＲ結果の確認及び訂正の結果に誤りがないか、承認者が確認するための画面である。スキャンファイル及び請求データの各項目の詳細については請求書詳細画面１１００と同様のため割愛する。承認依頼詳細画面１２２０が請求書詳細画面１１００と異なる点としては請求データの各項目は編集不可であり、参照のみ可能という点である。これは承認者のデータ訂正を不可とすることで、承認者による入力の誤りや不正な入力を防止するためである。
【０１２０】
承認依頼詳細画面１２２０は承認ボタン・否認ボタンを備えている。承認ボタンが押下されると該当の請求データは請求書詳細画面１１００での訂正内容に問題がなかったものと判断され、承認済み扱いとされる。承認済み扱いとなった請求データはその後の業務フローに従い、請求が行われる。否認ボタンが押下されると該当の請求データは請求書詳細画面１１００での訂正内容に問題があった、または未訂正の箇所があるものと判断され、否認扱いとされる。否認扱いとなったデータは再度確認者が請求書詳細画面１１００にて確認し、編集を行う。
【０１２１】
図１２、図１３の１２００、１２０４、１２０６、１２１３は全て承認依頼詳細画面の表示形態の一例である。各承認依頼詳細画面の詳細は図１０のフローチャートにて記載しているので割愛する。
【０１２２】
次に、図１４の各データについて説明する。
【０１２３】
図１４のユーザデータ１３００はシステム内でのユーザの管理のために使用されるものである。ユーザＩＤ１３０１はユーザデータ１３００の各レコードを識別するためのもので、一意の値となるものである。ユーザ名１３０２は利用ユーザの名称が登録される。
【０１２４】
図１４の請求書データ１３０３は請求書のＯＣＲ後の認識結果情報を登録するものである。フィールド名１３１７は請求書の各フィールドの名称（項目名）を示す。フィールド値１３０４は請求書の各フィールドのＯＣＲの結果を格納するためのカラムである。
【０１２５】
読取領域１３０５はフィールド値１３０４の認識を行う際のＯＣＲの対象となった領域の情報である。例えば図１１の請求書詳細画面１１０２のＦｒｏｍの読み取り領域である１１０３を示すものである。
【０１２６】
直接訂正フラグ１３０６は図８のステップＳ８０３からステップＳ８０５の手入力訂正を行ったか否かを保持するための領域である。該当フィールドの手入力訂正が行われた場合には１が、行われていない場合には０が格納される。領域訂正フラグ１３０７は図８ステップＳ８００からステップＳ８０２の領域訂正を行ったか否かを保持するための領域である。該当フィールドの領域訂正が行われた場合には１が、行われていない場合には０が格納される。
【０１２７】
変更前フィールド値１３１８及び変更後フィールド値１３１９は図８のステップＳ８００の領域訂正、または、ステップＳ８０３において手入力訂正が行われた場合に、訂正前のフィールド値と訂正後のフィールド値を保持するために利用される。図１４のデータ例では、領域訂正によりフィールド値が変更され、変更前フィールド値１３１８には訂正前のフィールド値が保持され、変更後フィールド値１３１９には訂正後のフィールド値が保持される。
【０１２８】
変更前領域１３０８及び変更後領域１３０９は図８のステップＳ８００において領域訂正が行われた場合に、訂正前の領域と訂正後の領域を保持するために利用される。図１４のデータ例では、領域の情報には画像内の所定の箇所を示すコードを設定しているが、画像内の相対的な座標等を設定してもよい。変更前領域１３０８には訂正前の読み取り領域情報が保持され、変更後領域１３０９には訂正後の読み取り領域情報が保持される。
【０１２９】
ここまで記載してきた請求データ１３０３のフィールド名１３１７、フィールド値１３０４、読取領域１３０５、直接訂正フラグ１３０６、領域訂正フラグ１３０７、変更前フィールド値１３１８、変更後フィールド値１３１９、変更前領域１３０８及び変更後領域１３０９は全て請求データに含まれる項目の数だけ存在するものである。例えば図１１のＦｒｏｍのためのフィールド名１３１７、フィールド値１３０４、読取領域１３０５、直接訂正フラグ１３０６、領域訂正フラグ１３０７、変更前フィールド値１３１８、変更後フィールド値１３１９、変更前領域１３０８及び変更後領域１３０９が存在し、Ｂｉｌｌ Ｔｏのための同様のカラムが存在するといった具合である。
【０１３０】
担当者ＩＤ１３１０は該当の請求書データ１３０３の確認者のユーザＩＤ１３０１を格納するカラムである。該当の確認者はシステムにログイン後、自身のユーザＩＤに紐づく請求書データ１３０３を参照し、請求書詳細画面１１００にて請求データの確認及び訂正を行う。承認者ＩＤ１３１１は該当の請求データ１３０３の承認者のユーザＩＤ１３０１を格納するカラムである。該当の承認者はシステムにログイン後、自身のユーザＩＤに紐づく請求書データ１３０３を参照し、承認依頼詳細画面１２２０にて請求データの承認及び否認を行う。
【０１３１】
ステータス１３１２は該当請求データ１３０３の業務フローでの状態を管理するために利用される。具体的には、ステップＳ５０８からステップＳ５０９のＯＣＲデータの保持の際には新規というステータスが格納される。ステップＳ８１２の請求書詳細・訂正情報保存の際には承認依頼というステータスが格納される。ステップＳ１０１０のステータス更新では、承認済み・否認のいずれかのステータスが格納される。ファイルＩＤはＯＣＲの対象となったファイルデータ１３１４のファイルＩＤ１３１５と一致する値が格納される。これはＯＣＲ処理で作成された請求書データ１３０３とＯＣＲの対象となったファイルデータ１３１４を関連づけるためのものである。
【０１３２】
ファイルデータ１３１４はＯＣＲの対象となったファイルのデータを格納しておくためのテーブルである。ファイルＩＤ１３１５はファイルデータ１３１４の各レコードを識別するための一意の値が格納されるものである。ファイル１３１６はＯＣＲの対象となったファイルのデータを格納するカラムである。ファイルデータはＢａｓｅ６４ｄａｔａにデコードされた状態で保存される。
【０１３３】
上記により、承認者はＯＣＲ認識結果に対する訂正内容に応じて訂正箇所を確認できるようになる。
【０１３４】
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
【０１３５】
また、本発明におけるプログラムは、各フローチャートの処理方法をコンピュータが実行可能なプログラムであり、本発明の記憶媒体は各フローチャートの処理方法をコンピュータが実行可能なプログラムが記憶されている。なお、本発明におけるプログラムは図４の各装置の処理方法ごとのプログラムであってもよい。
【０１３６】
以上のように、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１３７】
この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。
【０１３８】
プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク、ハーｆドディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＥＥＰＲＯＭ、シリコンディスク、ソリッドステートドライブ等を用いることができる。
【０１３９】
また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１４０】
さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１４１】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１４２】
さらに、本発明を達成するためのプログラムをネットワーク上のサーバ、データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１４３】
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。
【符号の説明】
【０１４４】
１        情報処理システム
１０      ネットワーク（ＬＡＮ）
１００    複合機
２００    クライアントＰＣ
３００    業務サーバ
４００    ＤＢサーバ
５００    ＯＣＲサーバ
６００    メールサーバ
【図１】
2020170465.tif 000003
【図２】
2020170465.tif 000004
【図３】
2020170465.tif 000005
【図４】
2020170465.tif 000006
【図５】
2020170465.tif 000007
【図６】
2020170465.tif 000008
【図７】
2020170465.tif 000009
【図８】
2020170465.tif 000010
【図９】
2020170465.tif 000011
【図１０】
2020170465.tif 000012
【図１１】
2020170465.tif 000013
【図１２】
2020170465.tif 000014
【図１３】
2020170465.tif 000015
【図１４】
2020170465.tif 000016