JP6094188B2 - 管理サーバ、画像処理システム、とその処理方法及びプログラム - Google Patents

Description

申請内容情報の否認に従ってスキャンチケットを発行し、申請内容情報の画像データを容易に更新できる画像処理システム、管理サーバ、画像処理システム、とその処理方法及びプログラムに関する。

従来、業務ワークフローシステムでは、出張や外出をした際の交通費精算の申請を行うものが多くなってきている。一般に、電車やバスの交通機関を利用した場合には、ワークフローシステム上の申請だけで、経理処理がなされるが、タクシーや新幹線のような所定の交通機関を利用した場合には、領収書の提出が必要となっている。従来の業務ワークフローシステムでは、領収書の提出が必要な交通費申請の場合、業務ワークフロー上の申請だけではなく、台紙に領収書を糊付けして紙面で提出をしている。

先行文献１では、交通費精算の申請を行うと、領収書が必要な場合、申請入力時にシステムが自動判定して専用台紙を印刷出力し、申請者はこれに領収書を貼付して紙面で提出を行う技術が開示されている。この技術では、印刷出力する専用台紙に、交通費申請された申請番号を特定できるバーコードを印刷しているので、領収書が添付された台紙が提出された経理部門では、バーコードリーダーでバーコードを読み取ることで、申請番号とのマッチングを簡単に行うことができる。

特開２００２−２７９１４６号

しかしながら、特許文献１に記載されている技術では、専用用紙の印刷出力を行って、領収書を物理的に添付する必要があり、ペーパーレス化がまだ進んでいないという問題がある。

一方で、近年、オフィスには、電子化機能を用いた複合機が多くあるため、その複合機の電子化機能を用いることにより、さらなる業務効率の向上が求められている。

そのため、領収書を複合機のスキャナ部で読み取り、電子化機能を用いて電子データ化し、文書管理サーバに電子データを送信して登録することで、さらなるペーパー化を進めることができると予想される。

しかしながら、この場合であっても、経理担当または交通費申請の承認を行う管理者は、ワークフローシステム側で申請された交通費精算の申請内容と、複合機から送信されて文書管理サーバに登録されている電子データの内容とが正しいかを、その都度チェックしなければならず、業務負担が大きいという問題がある。

また、交通費申請を行った申請者は、領収書を複合機で電子化して所定のサーバ（文書管理サーバ）に記憶させるという操作を行わなければならず、操作負担が大きいことと、この処理を忘れてしまうという問題がある。

また、申請内容に不備があり、申請内容が承認者によって否認された場合には、既に申請した申請内容を確認する、或いは否認理由を確認しなければならず、申請が否認された場合の業務負担が大きいという問題があった。

そこで、本願発明は、否認理由の種別に従って、画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行し、否認された申請情報のファイルを画像処理装置から容易に更新できる仕組みを提供することを目的とする。

本発明は、画像読み取り機構を備える画像処理装置と、申請されたファイルを含む申請情報を記憶する記憶装置と通信可能な管理サーバであって、前記申請情報に対する否認理由の種別を受け付ける受付手段と、前記受付手段により受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定手段と、前決定手段により、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成手段とを備えることを特徴とする。

本願発明によれば、否認理由の種別に従って、画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行し、否認された申請情報のファイルを画像処理装置から容易に更新できる。

本発明の画像処理システムの一例を示すシステム構成図である。 ワークフローサーバ、チケットサーバ、認証サーバ、クライアント端末のハードウェア構成を示すブロック図である。 複合機のハードウェア構成を示すブロック図である。 本願発明に係るワークフローシステムの申請処理と、申請内容に基づくスキャンチケット生成処理の一例を示すフローチャートである。 本願発明に係るチケットサーバにおける申請内容に基づくスキャンチケット生成処理の一例を示すフローチャートである。 本願発明に係るチケットサーバにおけるスキャンチケット生成処理の具体例を示すフローチャートである。 本願発明に係る複合機におけるログイン処理からスキャン処理を実行する処理手順の一例を示すフローチャートである。 本願発明に係るワークフローサーバにおける申請済みの伝票の確認表示を行う処理手順の一例を示すフローチャートである。 本願発明に係るクライアント端末に表示される申請ワークフローのメインメニューの表示画面の一例を示す図である。 本願発明に係るクライアント端末に表示される交通費精算入力を行う表示画面の一例を示す図である。 本願発明に係る交通費精算入力を行う表示画面の各項目の定義の一例を示す図である。 本願発明に係るクライアント端末からワークフローサーバに送信される情報から生成される、ワークフローサーバで管理されている申請情報内容の一例を示す図である。 本願発明に係るチケットサーバで生成されるスキャンチケットのデータ構成の一例を示す図である。 本願発明に係る画像処理装置において表示されるユーザログイン後の表示画面の一例を示す図である。 本願発明に係る画像処理装置において表示される、スキャンチケットに基づくスキャン指示を行う際のスキャン確認画面の一例を示す図である。 本願発明に係る画像処理装置において表示される、スキャン指示を行う際の画面の一例を示す図である。 本願実施に係るクライアント端末に表示される、交通費精算一覧画面の一例を示す図である。 本願実施に係るクライアント端末（管理者）に表示される、交通費精算承認画面の一例を示す図である。

本発明の技術的特徴を簡単に説明すると、画像読み取り機構を備える画像処理装置と通信可能な、クライアント装置から申請された申請内容情報を管理する管理サーバは、前記申請内容情報が承認者によって否認されたか否かを判定し、申請内容情報が否認されたと判定された場合に、否認された申請内容情報に再度画像データを対応づけて記憶させるべく、否認された申請内容情報に従って、前記画像処理装置で画像の読み取りを実行するためのスキャンチケットを生成することである。

以下、図面を参照して、本発明の技術的特徴を、以下の実施の形態で詳細に説明する。

図１は、本発明の管理サーバとして好適なチケットサーバ１００（ワークフローサーバの役割も行う）および画像処理装置として好適な複合機３００を含む画像処理システムの構成の一例を示すシステム構成図である。

図１に示すように、本実施形態の画像処理システムは、１又は複数のクライアント端末４００（例えば、ユーザ毎）、クライアント端末（管理者）５００、複数の複合機３００、管理サーバ（チケットサーバ／ワークフローサーバ）１００、認証サーバ２００がローカルエリアネットワーク（ＬＡＮ）６００を介して接続され、情報の送受信を行う構成となっている。なお、後述するように、管理サーバ１００は、チケットサーバとワークフローサーバとして、別の装置に分けて構成してもよい。

クライアント端末４００には、管理サーバ１００（ワークフローサーバ側の機能）と通信を行い、交通費精算で用いる帳票に必要なフォーム及びテキストデータを取得し、交通費申請画面を表示するためのソフトウェア（例えば、ブラウザ）がインストールされている。このソフトウェア（ブラウザ）は、ユーザにより交通費申請画面で入力指定された申請内容を示す申請内容情報をＨＴＴＰ通信を行うことにより、管理サーバ１００へ送信する。

管理サーバ１００では、交通費精算のような業務ワークフローを制御するウェブアプリケーションがインストールされており、クライアント端末４００から受信した申請内容情報を内部のメモリに蓄積する。そして、申請内容情報に基づいて、業務ワークフローを制御し、アクティビティを進めたり、差し戻したりワークフロー制御を行う。アクティビティとは、ワークフローの各工程のことであり、申請工程、承認工程などに相当する。

認証サーバ２００は、ＩＣカード認証用テーブルを記憶しており、複合機３００のカードリーダへＩＣカードをかざすことによってなされる認証依頼に応じて、該ＩＣカード認証用テーブルを用いて認証処理を行う。

クライアント端末（管理者）５００は、申請内容に対する承認者の端末であって、管理サーバ１００に申請された内容を確認し、承認・否認といったワークフロー処理を行う。

以下、図２を用いて、図１に示したクライアント端末、クライアント端末（管理者）、管理サーバ、認証サーバに適用可能な情報処理装置のハードウェア構成について説明する。図２は、図１に示したクライアント端末，管理サーバ、認証サーバに適用可能な情報処理装置のハードウェア構成を示すブロック図である。

図２において、２０１はＣＰＵで、システムバス２０４に接続される各デバイスやコントローラを統括的に制御する。また、ＲＯＭ２０２あるいは外部メモリ２１１には、ＣＰＵ２０１の制御プログラムであるＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ ／ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）やオペレーティングシステムプログラム（以下、ＯＳ）や、各サーバ或いは各ＰＣの実行する機能を実現するために必要な後述する各種プログラム等が記憶されている。

２０３はＲＡＭで、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ＣＰＵ２０１は、処理の実行に際して必要なプログラム等をＲＯＭ２０２あるいは外部メモリ２１１からＲＡＭ２０３にロードして、該ロードしたプログラムを実行することで各種動作を実現するものである。

また、２０５は入力コントローラで、キーボード（ＫＢ）２０９や不図示のマウス等のポインティングデバイス等からの入力を制御する。２０６はビデオコントローラで、ＣＲＴディスプレイ（ＣＲＴ）２１０等の表示器への表示を制御する。なお、図２では、ＣＲＴ２１０と記載しているが、表示器はＣＲＴだけでなく、液晶ディスプレイ等の他の表示器であってもよい。これらは必要に応じて管理者が使用するものである。

２０７はメモリコントローラで、ブートプログラム，各種のアプリケーション，フォントデータ，ユーザファイル，編集ファイル，各種データ等を記憶するハードディスク（ＨＤ）や、フレキシブルディスク（ＦＤ）、或いはＰＣＭＣＩＡカードスロットにアダプタを介して接続されるコンパクトフラッシュ（登録商標）メモリ等の外部メモリ２１１へのアクセスを制御する。

２０８は通信Ｉ／Ｆコントローラで、ネットワーク（例えば、図１に示したＬＡＮ６００）を介して外部機器と接続・通信するものであり、ネットワークでの通信制御処理を実行する。例えば、ＴＣＰ／ＩＰを用いた通信等が可能である。

なお、ＣＰＵ２０１は、例えばＲＡＭ２０３内の表示情報用領域へアウトラインフォントの展開（ラスタライズ）処理を実行することにより、ＣＲＴ２１０上での表示を可能としている。また、ＣＰＵ２０１は、ＣＲＴ２１０上の不図示のマウスカーソル等でのユーザ指示を可能とする。

本発明を実現するための図４〜図８の管理サーバ１００、クライアント端末４００で実行されるフローチャートで後述する各ステップの処理は、コンピュータで読み取り実行可能なプログラムにより実行され、そのプログラムは外部メモリ２１１に記録されている。そして、必要に応じてＲＡＭ２０３にロードされることによりＣＰＵ２０１によって実行されるものである。さらに、上記プログラムの実行時に用いられる定義ファイル及び各種情報テーブル等も、外部メモリ２１１に格納されており、これらについての詳細な説明も後述する。

次に、図３を用いて、図１に示した複合機３００のハードウェア構成について説明する。
図３は、図１に示した複合機３００のハードウェア構成の一例を示すブロック図である。

図３において、３１６はコントローラユニットで、画像入力デバイスとして機能するスキャナ３１４や、画像出力デバイスとして機能するプリンタ部３１２と接続する一方、ＬＡＮ（例えば、図１に示したＬＡＮ６００）や公衆回線（ＷＡＮ）（例えば、ＰＳＴＮまたはＩＳＤＮ等）と接続することで、画像データやデバイス情報の入出力を行う。

コントローラユニット３１６において、３０１はＣＰＵで、システム全体を制御するプロセッサである。３０２はＲＡＭで、ＣＰＵ３０１が動作するためのシステムワークメモリであり、プログラムを記録するためのプログラムメモリや、画像データを一時記録するための画像メモリでもある。

３０３はＲＯＭで、システムのブートプログラムや各種制御プログラムが格納されている。３０４はハードディスクドライブ（ＨＤＤ）で、システムを制御するための各種プログラム，画像データ等を格納する。

３０７は操作部インタフェース（操作部Ｉ／Ｆ）で、操作部（キーボード）３０８とのインタフェース部である。また、操作部Ｉ／Ｆ３０７は、操作部３０８から入力したキー情報（例えば、スタートボタンの押下）をＣＰＵ３０１に伝える役割をする。

３０５はネットワークインタフェース（Ｎｅｔｗｏｒｋ Ｉ／Ｆ）で、ネットワーク（ＬＡＮ）６００に接続し、データの入出力を行う。３０６はモデム（ＭＯＤＥＭ）で、公衆回線に接続し、ＦＡＸの送受信等のデータの入出力を行う。

３１８は外部インタフェース（外部Ｉ／Ｆ）で、ＵＳＢ、ＩＥＥＥ１３９４，プリンタポート，ＲＳ−２３２Ｃ等の外部入力を受け付けるＩ／Ｆ部であり、本実施形態においては認証で必要となる携帯端末のＩＣカード（記憶媒体）の読み取り用のカードリーダ３１９が外部Ｉ／Ｆ部３１８に接続されている。そして、ＣＰＵ３０１は、この外部Ｉ／Ｆ３１８を介してカードリーダ３１９による携帯端末のＩＣカードからの情報読み取りを制御し、該携帯端末のＩＣカードから読み取られた情報を取得可能である。以上のデバイスがシステムバス３０９上に配置される。

３２０はイメージバスインタフェース（ＩＭＡＧＥ ＢＵＳ Ｉ／Ｆ）であり、システムバス３０９と画像データを高速で転送する画像バス３１５とを接続し、データ構造を変換するバスブリッジである。
画像バス３１５は、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス３１５上には以下のデバイスが配置される。

３１０はラスタイメージプロセッサ（ＲＩＰ）で、例えば、ＰＤＬコード等のベクトルデータをビットマップイメージに展開する。３１１はプリンタインタフェース（プリンタＩ／Ｆ）で、プリンタ部３１２とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。また、３１３はスキャナインタフェース（スキャナＩ／Ｆ）で、スキャナ３１４とコントローラユニット３１６を接続し、画像データの同期系／非同期系の変換を行う。

３１７は画像処理部で、入力画像データに対し補正、加工、編集を行ったり、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。また、これに加えて、画像処理部３１７は、画像データの回転や、多値画像データに対してはＪＰＥＧ、２値画像データはＪＢＩＧ、ＭＭＲ、ＭＨ等の圧縮伸張処理を行う。そして、この画像処理部３１７は、スキャナ部３１４を駆動して画像読み取りされた画像データを画像処理して、ファイル出力可能な形式（例えば、ＰＤＦ形式ファイル）に変換し、ＣＰＵ３０１と連携して、ネットワークＩ／Ｆ３０５を介して、外部装置に画像データのファイルを送信することができる。

スキャナ部３１４は、原稿となる紙上の画像を照明し、ＣＣＤラインセンサで走査することで、ラスタイメージデータとして電気信号に変換する。原稿用紙は原稿フィーダのトレイにセットし、装置使用者が操作部３０８から読み取り起動指示することにより、ＣＰＵ３０１がスキャナ３１４に指示を与え、フィーダは原稿用紙を１枚ずつフィードし原稿画像の読み取り動作を行う。

プリンタ部３１２は、ラスタイメージデータを用紙上の画像に変換する部分であり、その方式は感光体ドラムや感光体ベルトを用いた電子写真方式、微少ノズルアレイからインクを吐出して用紙上に直接画像を印字するインクジェット方式等があるが、どの方式でも構わない。プリント動作の起動は、ＣＰＵ３０１からの指示によって開始する。なお、プリンタ部３１２には、異なる用紙サイズまたは異なる用紙向きを選択できるように複数の給紙段を持ち、それに対応した用紙カセットがある。

操作部３０８は、ＬＣＤ表示部を有し、ＬＣＤ上にタッチパネルシートが貼られており、システムの操作画面を表示するとともに、表示してあるキーが押されるとその位置情報を操作部Ｉ／Ｆ３０７を介してＣＰＵ３０１に伝える。また、操作部３０８は、各種操作キーとして、例えば、スタートキー、ストップキー、ＩＤキー、リセットキー等を備える。

尚、表示部はプリンタによって表示性能が異なり、タッチパネルを介して操作をできるプリンタ、単に液晶画面を備え文字列を表示（印刷状態や印刷している文書名の表示）させるだけのプリンタによって本発明は構成されている。

ここで、操作部３０８のスタートキーは、原稿画像の読み取り動作を開始する時などに用いる。スタートキーの中央部には、緑と赤の２色ＬＥＤがあり、その色によってスタートキーが使える状態にあるかどうかを示す。また、操作部３０８のストップキーは、稼働中の動作を止める働きをする。また、操作部３０８のＩＤキーは、使用者のユーザＩＤを入力する時に用いる。リセットキーは、操作部からの設定を初期化する時に用いる。

カードリーダ３１９は、ＣＰＵ３０１からの制御により、携帯端末内に備えられたＩＣカードに記憶されている情報を読み取り、該読み取った情報を外部Ｉ／Ｆ３１８を介してＣＰＵ３０１へ通知する。

以上のような構成によって、複合機３００は、スキャナ３１４から読み込んだ画像データをＬＡＮ６００上に送信したり、ＬＡＮ６００から受信した印刷データをプリンタ部３１２により印刷出力することができる。

また、スキャナ３１４から読み込んだ画像データをモデム３０６により、公衆回線上にＦＡＸ送信したり、公衆回線からＦＡＸ受信した画像データをプリンタ部３１２により出力することできる。

図４は、申請者端末であるクライアント端末４００（クライアント装置）及び管理サーバ１００（チケットサーバ／ワークフローサーバ）及び管理者端末であるクライアント端末５００、画像処理装置である複合機３００による全体の流れを説明するフローチャートである。具体的には、ワークフローシステムの申請処理と、申請内容に基づくスキャンチケット生成処理、申請内容の承認処理の一例を示すフローチャートである。なお、ステップＳ４０１、ステップＳ４０４〜ステップＳ４０８、ステップＳ４１１、ステップＳ４１５〜Ｓ４１９は、クライアント端末４００のＣＰＵ２０１が実行する。ステップＳ４０２、ステップＳ４０３、ステップＳ４０９、ステップＳ４１０、ステップＳ４１４は、管理サーバ１００のＣＰＵ２０１が実行する。そして、ステップＳ４１２は、複合機３００のＣＰＵ３０１が実行する。ステップＳ４１３は、クライアント端末５００（管理者端末）と管理サーバ１００が実行する。

ステップＳ４０１では、クライアント端末４００は、管理サーバ１００のワークフローサーバに対して、申請画面の取得要求を送信する。具体的には、クライアント端末４００で表示部にブラウザを起動させ、交通費申請等の業務申請をするためのワークフローのＵＲＬを入力することで、ワークフローのウェブアプリケーションを実行するためのログイン要求およびそのログイン後のトップ画面の取得要求を送信する。

ステップＳ４０２では、ワークフローサーバ１００は、クライアント端末４００から、申請画面要求を受信し、ステップＳ４０３で交通費の精算を行うための申請画面の表示情報（申請画面情報）をクライアント端末４００に返送する（申請画面情報送信）。この申請画面の表示情報とは、例えばＨＴＭＬ形式の表示情報であり、この表示情報に基づいて、クライアント端末４００ではブラウザで表示することが可能となっている。なお、申請画面の表示を行う際には、ユーザはクライアント端末４００からユーザ認証を用いてログインを行う必要があり、ステップＳ４０２でログインされてから、申請を行うステップＳ４１０までは、セッション管理されており、ログインしているユーザ識別情報をワークフローサーバでは管理しており、ユーザを識別することができるものとする。なお、ワークフロー処理において、ユーザ識別情報を記憶してセッション管理することは既知の技術であるため、その詳細な説明は省略する。

次にステップＳ４０４では、クライアント端末４００は、ワークフローサーバ１００から送信された申請画面の表示情報を受信し、ステップＳ４０５で、表示情報に基づいて表示部にブラウザで申請画面の表示を行う。ここで表示される申請画面の一例を図９に示す。

図９は、クライアント端末４００又はクライアント端末５００の表示部にブラウザにより表示される申請画面の一例である。申請画面のメインメニュー９００では、交通費精算一覧ボタン９０１と、交通費精算登録ボタン９０２が用意されている。交通費精算登録ボタン９０２が押下されると、交通費精算入力画面（図１０）に表示が切り替わる。具体的には、交通費精算登録ボタン９０２が押下されると、ワークフローサーバ１００に交通費精算入力画面の表示要求をＨＴＴＰ通信で行い、その要求に応じて交通費精算入力画面の表示情報を受信して、表示部に図１０の交通費精算入力画面を表示する。一方、交通費精算一覧ボタン９０１が押下されると、交通費精算一覧画面（図１７の１７００）に表示が切り替わる。この場合も同様に、交通費精算一覧ボタン９０１が押下されると、ワークフローサーバ１００に交通費精算一覧画面の表示要求をＨＴＴＰ通信で行い、その要求に応じて交通費精算一覧画面の表示情報を受信して、表示部に図１７の交通費精算一覧画面１７００を表示する。クライアント端末５００の表示部で未承認の交通費精算を承認する場合には、１７０１が表示される。

図１０は、クライアント端末４００の表示部にブラウザにより表示される交通費精算入力画面の一例である。交通費精算入力画面では、ユーザにより申請内容を入力さえせるためのフィールドが項目１〜項目１１まで用意されている。そして、申請内容の情報をワークフローサーバ１００に登録要求するための「登録ボタン１２」、申請内容をクリア（消去）してユーザに入力をし直しさせるための「クリアボタン１３」、および、交通費精算のメインメニュー（図９）に表示画面を戻すための「戻るボタン１４」がそれぞれ用意されている。
図１０の各項目や各ボタンの説明を図１１の交通費精算入力を行う表示画面の各項目の定義情報を用いて説明する。

項目１は、外出日をユーザが入力するための項目である。入力形式は、ｙｙｙｙ／ｍｍ／ｄｄであり、登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。
項目２は、行先をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。
項目３は、要件をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。

項目４は、時間をユーザが入力するための項目である。入力形式は、ｈｈ：ｍｍであり、外出時間として、開始と終了の２つの時間入力を行う。登録ボタン押下時に、この設定値＜ｔｉｍｅＦｒｏｍ＞と＜ｔｉｍｅＴｏ＞が管理サーバ１００へ出力されて管理される。

項目５は、交通手段をユーザが入力するための項目である。設定値としてはコンボボックス（プルダウンメニューでもよい）で選択可能であり、「１：電車・バス」「２：タクシー」「３：新幹線・特急」「４：飛行機」「５：その他」となっている。登録ボタン押下時に、選択された値＜ｒｏｕｔｅＦｒｏｍ＞と＜ｒｏｕｔｅＴｏ＞が管理サーバ１００へ出力されて管理される。

項目６は、経路をユーザが入力するための項目であり、開始と終了の２つの地点の入力を行う。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。
項目７は、金額をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。
項目８は、備考をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。

項目９は、承認者をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。なお、承認者９の値は、ユーザに指定させずに、管理サーバ１００のワークフローサーバで組織データを管理しておき、ユーザから申請があったときに、ユーザの上司に相当する人を承認者に自動的に割り当てるようにしてもよい。

項目１０は、発行元課をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。なお、発行元課の値は、ユーザに指定させずに、管理サーバ１００のワークフローサーバで課コードを管理しておき、ユーザから申請があったときに、ユーザの所属している課コードを自動的に割り当てるようにしてもよい。
項目１１は、負担課をユーザが入力するための項目である。登録ボタン押下時に、この設定値が管理サーバ１００へ出力されて管理される。

項目１２は、登録ボタンであり、このボタンが押下されると、交通費精算入力画面で入力されている各項目（１〜１２）が、管理サーバ１００へ出力されて管理される。そして、この登録ボタンが押下された際に、項目５の「交通手段」で「１：電車・バス」以外が選択された場合には、申請者のユーザＩＤ（ユーザ識別情報）に紐づけて、領収書のためのジョブＩＤ（ＹＹＹＹＭＭＤＤ：日付の連番）、ジョブ名称（交通費精算領収書）、機密フラグ（１：一般、２：秘、３：極秘）、ジョブ実行時間（システムタイム）、スキャンフラグ（０：未スキャン、１：スキャン済み）、スキャンファイル名（未スキャン時は空欄、スキャン済み時はファイル名）が、管理サーバ１００に登録されることになる。
項目１３は、クリアボタンであり、このボタンが押下されると、交通費精算入力画面で入力されている各項目の値がクリアされる。
項目１４は、戻るボタンであり、このボタンが押下されると、メニュー画面に表示を戻す。

このようにして申請される申請内容情報（申請ファイル）を、図１２を用いて説明する。図１２は、クライアント端末４００から送信されてくる申請された内容により管理サーバ１００で管理される申請内容情報（申請ファイル）の一例である。
図１２の申請内容情報において、項目名「外出日」は、図１０の交通費精算入力画面の項目１の「外出日」で入力された値が設定される。
項目名「行先」は、図１０の交通費精算入力画面の項目２の「行先」で入力された値が設定される。
項目名「要件」は、図１０の交通費精算入力画面の項目３の「要件」で入力された値が設定される。
項目名「時間（Ｆｒｏｍ）」は、図１０の交通費精算入力画面の項目４の「時間」で入力された＜ｔｉｍｅＦｒｏｍ＞の値が設定される。
項目名「時間（Ｔｏ）」は、図１０の交通費精算入力画面の項目４の「時間」で入力された＜ｔｉｍｅＴｏ＞の値が設定される。

項目名「交通手段」は、図１０の交通費精算入力画面の項目５の「交通手段」で選択・入力された値が設定される。ここで設定される値は、「１」〜「５」の値だけでよい。
項目名「経路（Ｆｒｏｍ）」は、図１０の交通費精算入力画面の項目６の「経路」で入力された＜ｒｏｕｔｅＦｒｏｍ＞が設定される。
項目名「経路（Ｔｏ）」は、図１０の交通費精算入力画面の項目６の「経路」で入力された＜ｒｏｕｔｅＴｏ＞が設定される。
項目名「金額」は、図１０の交通費精算入力画面の項目７の「金額」で入力された値が設定される。
項目名「備考」は、図１０の交通費精算入力画面の項目８の「備考」で入力された値が設定される。

項目名「承認者」は、図１０の交通費精算入力画面の項目９の「承認者」で入力された値が設定される。なお、前述したように、承認者９の値がユーザ指定ではなく、管理サーバ１００のワークフローサーバで組織データを管理している場合には、ユーザから申請があったときに、ユーザの上司に相当する人を承認者に自動的に割り当てるようにしてもよい。

項目名「発行元課」は、図１０の交通費精算入力画面の項目１０の「発行元」で入力された値が設定される。なお、前述したように、発行元課の値がユーザ指定ではなく、管理サーバ１００のワークフローサーバで課コードを管理している場合には、ユーザから申請があったときに、ユーザの所属している課コードを自動的に割り当てるようにしてもよい。
項目名「負担課」は、図１０の交通費精算入力画面の項目１１の「負担課」で入力された値が設定される。

項目名「ユーザＩＤ」は、交通費精算のワークフローにログインしたときのログインＩＤが、ユーザＩＤ（ユーザ識別情報）として登録される。このユーザＩＤは、前述したように、ワークフローサーバでセッション管理する際に、ログインしているユーザ識別情報を管理しているものとする。また、これに限ることなく、交通費精算入力画面（図１０）で、新たにユーザＩＤの入力項目を用意し、この画面を介して入力されたユーザＩＤを用いて管理してもよい。

項目名「ユーザ名」は、上記のユーザＩＤに対応するユーザ名である。ユーザＩＤとユーザ名との対応テーブル（図示省略）は、あらかじめ外部メモリ２１１に格納されている。また、その他の手法として、ユーザＩＤとユーザ名の対応テーブルを有している認証サーバに、ユーザＩＤをキーにしてユーザ名の問い合わせを行い、その応答でユーザ名を取得して、申請ファイルに設定してもよい。
項目名「更新日時」は、交通費精算入力画面で登録ボタンが押下されたときのタイムスタンプを設定する。

項目名「スキャン予約ジョブＩＤ」は、交通費精算入力画面で登録ボタンが押下されたときに、スキャン予約情報（スキャンチケット）作成処理で採番されたジョブＩＤを設定する。

項目名「スキャン予約ジョブ名」は、交通費精算入力画面で登録ボタンが押下されたときに、スキャン予約情報（スキャンチケット）作成処理で作成されたジョブ名を設定する。設定内容としては、例えば、「交通費領収書（ｙｙｙｙｍｍｄｄ−日付の連番）」というジョブ名称でよい。ここで設定されるジョブ名称は、後述するように、複合機３００の操作部にジョブリストとして一覧表示される。

項目名「スキャンフラグ」は、スキャンの状態を設定するフラグである。スキャンが実行され、スキャン結果のＰＤＦファイルがＦＴＰ送信されて管理サーバ１００に格納された際に、フラグを「１」に設定する。スキャン待ちの状態では、フラグは「０」となっている。

項目名「スキャンファイル名」は、スキャン結果のファイル名が設定される。スキャンが実行され、ＦＴＰでＰＤＦファイルがいるが送信されて管理サーバ１００に格納された際に、そのファイル名を設定する。このファイル名は、複合機３００で付与されるものであるが、本実施の形態では、「スキャン予約ジョブＩＤ＋タイムスタンプ．ｐｄｆ」というファイル名となる。

図４のフローチャートに説明を戻す。ステップＳ４０６では、ユーザ操作に従って、図１０の交通費精算入力画面を介して申請情報の入力を受け付ける。そして、ステップＳ４０７では、登録ボタン１２が押下されて、申請の指示を受け付けたかを判断する。申請の指示を受け付けたと判断されるとステップＳ４０８で、交通費精算入力画面を介して入力されている申請情報の内容を示す申請内容情報を、管理サーバ１００へ送信することで申請を行う。一方、申請の指示を受け付けていない場合には、ステップＳ４０６の申請情報の入力ステップを繰り返す。また、ステップＳ４０７で、クリアボタンが押下された場合にも、入力されている設定値をクリアした後、同様にステップＳ４０６に処理を戻す。

次にステップＳ４０９では、管理サーバ１００は、クライアント端末４００から申請内容情報を受信し、ステップＳ４１０で申請処理とスキャンチケット生成処理を行う。申請処理とスキャンチケット生成処理の詳細については、次の図５のフローチャートを用いて後述する。スキャンチケット生成処理が行われると、ステップＳ４１１では、申請された結果、スキャンチケットが生成された結果を受信して、表示部に表示する。その後、ユーザはスキャンを実行するため、複合機３００に赴き、ステップＳ４１２で、複合機３００においてスキャン処理が実行される。このスキャン処理については、図７のフローチャートを用いて後述する。

ステップＳ４１３では、クライアント端末４００から申請された申請情報に対して、承認処理がなされる。この承認処理については、図８のフローチャートを用いて後述する。
ステップＳ４１４では、ステップＳ４１３の承認処理の結果（承認、否認）を、クライアント端末４００からの要求に従って、送信する。

ステップＳ４１５では、承認結果を受信して、承認結果を表示する。ステップＳ４１６で、承認結果が承認か否かを判定する。承認結果が承認であった場合には、処理を終了し。承認結果が否認であった場合には、ステップＳ４１７で申請情報の詳細を、管理サーバ１００（チケットサーバ／ワークフローサーバ）から取得して、表示する。

ステップＳ４１８では、図１８で入力された否認理由により、再スキャンが必要と判定された場合には、再スキャンが必要である旨の通知を表示し、再スキャンをするためにステップＳ４１２へ処理を移す。また、否認理由により、申請情報自体が間違っている場合には、ステップＳ４１９で、申請情報が間違っている旨の通知を表示し、申請情報の変更画面に推移する。そして、変更画面で入力された情報に変更するべく、管理サーバ１００（チケットサーバ／ワークフローサーバ）へ、申請情報を送信して、処理を終了とする。

図５は、管理サーバ１００（チケットサーバ／ワークフローサーバ）における申請内容に基づく申請処理とスキャンチケット生成処理の一例を説明するフローチャートである。なお、ステップＳ５０１〜ステップＳ５０７は、管理サーバ１００のＣＰＵ２０１が実行する。

ステップＳ５０１では、管理サーバ１００（ワークフローサーバ）は、クライアント端末４００から受信されて外部メモリ２１１に記憶されている申請内容情報を取得する。そして、ステップＳ５０２では、領収書の添付書類の申請が必要であるか否か、すなわち、申請内容情報の「交通手段」の項目の選択値が「１：電車・バス」であるか否かを判断する。「交通手段」の項目の選択値が「１：電車・バス」であれば、領収書の添付書類の申請が不要であると判断され、「交通手段」の項目の選択値が「１：電車・バス」以外であれば、領収書の添付書類の申請が必要であると判断される。なお、この判断のために、管理サーバ１００には、「交通手段」の項目の選択値がどの選択値であれば領収書の添付書類の申請が必要であるかを示す対応テーブルを設けておくか、本プログラム中に記述しておくことにより実現できる。すなわち、本ステップで、クライアント端末４００から申請された申請内容情報に従って、複合機３００で画像の読み取り処理が必要であるか否かを判断することになる。

ステップＳ５０２で添付書類が不要であると判断されると、ステップＳ５０３に処理を進めて、申請内容情報（申請ファイル）をワークフローの新規伝票として登録し、次のアクティビティに処理を進めるワークフロー制御処理を行う。このワークフロー制御処理の詳細は既知の技術であるため詳細な説明は省略する。

一方、ステップＳ５０２で添付書類が必要であると判断されると、複合機３００で画像読み取り処理を行わせるために、新規を含むスキャンチケットの生成命令を出力する。そして、ステップＳ５０５では、スキャンチケットを生成する。このスキャンチケットの生成処理の詳細については、図６を用いて後述する。なお、管理サーバ１００が、ワークフローサーバとチケットサーバ（スキャンチケットサーバ）に分けて構成されている場合には、ステップＳ５０４でワークフローサーバがスキャンチケットの生成命令を、チケットサーバに対して送信することで、スキャンチケットの生成を要求する（生成要求）。ここで、管理サーバ１００が、ワークフローサーバとチケットサーバ（スキャンチケットサーバ）に分けて構成されておらず、一体のサービスとして実現する場合には、スキャンチケット生成命令の出力は不要で、ステップＳ５０５へ処理を飛ばすことも可能である。

次にステップＳ５０６では、クライアント端末４００から申請された申請内容情報と、ステップＳ５０５で生成されたスキャンチケットのＩＤ（チケット識別情報）とを紐づけて（対応づけて）外部メモリ２１１に記憶する。そして、ステップＳ５０７では、申請内容情報（申請ファイル）をワークフローの新規伝票として登録する。このときは、必要な情報（添付書類）が揃っていないため、ワークフロー制御では、次のアクティビティに進めない。

図６は、管理サーバ１００（チケットサーバ／ワークフローサーバ）におけるスキャンチケット生成処理の具体例を示すフローチャートである。なお、ステップＳ６０１〜ステップＳ６０６は、管理サーバ１００のＣＰＵ２０１が実行する。

ステップＳ６０１では、管理サーバ１００のチケットサーバは、ワークフローサーバからスキャンチケット生成命令を受信する。なお、前述したように、チケットサーバとワークフローサーバの各機能を同一筺体の管理サーバ１００で実現する場合には、スキャンチケット生成命令の送受信は省略可能である。また、承認者によって申請情報が否認された場合で、再スキャンが必要な否認理由であった場合にも、スキャンチケット生成命令を受信する。なお、スキャンチケット生成命令を用いる場合には、例えば、新規、追加、差替が含まれ、これにより、後述のステップＳ６０５で種別が決定される

ステップＳ６０２では、ユーザ名を取得する。この「ユーザ名」は、ワークフローにログインしているユーザのユーザＩＤに対応するユーザ名である。ユーザＩＤとユーザ名との対応テーブル（図示省略）は、あらかじめ管理サーバ１００の外部メモリ２１１に格納されているので、ワークフローサーバからユーザＩＤを受け取ることにより、ユーザ名を取得することができる。また、ワークフローサーバ側で対応テーブルを保持している場合は、ユーザ名自体を送信してもらうことで取得してもよい。また、その他の手法として、ユーザＩＤとユーザ名の対応テーブルを有している認証サーバに、ユーザＩＤをキーにしてユーザ名の問い合わせを行い、その応答でユーザ名を取得してもよい。

次に、ステップＳ６０３では、スキャン設定情報を外部メモリ２１１から取得する。スキャン設定情報は、あらかじめ外部メモリ２１１に保存されている。スキャン設定情報は、画像処理装置である複合機３００で画像の読み取りを実行するための指示内容が定義されている。この指示内容は、例えば、複合機３００の画像読み取り機構（スキャナ部３１４）の読み取り解像度、カラー／モノクロ指定、読み取り原稿サイズを含んでいる。なお、スキャン設定情報には、更に、スキャンした画像ファイルをＦＴＰ送信する際の送信先であるＦＴＰ送信パスも含まれている。このＦＴＰ送信パスは、ワークフローサーバにおいて申請された交通費精算伝票ジョブに添付書類として保管するためのファイルパスであり、ＦＴＰ送信パスは、ワークフローサーバ内の外部メモリ２１１に用意されているファイル管理領域である。

ステップＳ６０４では、管理サーバ１００（チケットサーバ）は、スキャンチケットＩＤ（スキャン予約ジョブＩＤ）を発行する。このスキャンチケットＩＤは、クライアント端末から管理サーバ１００（ワークフローサーバ）に交通費精算の申請がなされたときに、採番される。スキャンチケットＩＤ（スキャン予約ジョブＩＤ）は、例えば、ｙｙｙｙｍｍｄｄ−日付の連番を用いて、「２００９１２１００００１」（２００９年１２月１０日に採番された０００１番目のＩＤ）として採番される。よって、ステップＳ６０４の管理サーバ１００のチケットサーバにおける処理は、ワークフローサーバから採番されたスキャンチケットＩＤ（チケット識別情報）を取得する処理に相当する。

次に、ステップＳ６０５では、スキャンチケットの種別を決定する。種別の決定は、申請情報が新規に登録された（申請された）場合には、チケット種別として、「１：新規」が決定される。また、承認者により、申請情報が否認された場合には、否認理由に応じてチケット種別に「２：追加」「３：差替」のフラグが決定される。より詳細には、図１８にて否認理由「ファイル差し替え」が選択された場合には、チケット種別として「３：差替」に決定され、図１８にて否認理由「ファイル追加」が選択された場合には、チケット種別として「２：追加」に決定される。これらに情報に従ってスキャンチケットが生成される。スキャンチケットのデータ構造の一例を図１３を用いて説明する。
図１３は、チケットサーバで生成されるスキャンチケットのデータ構成の一例を示す図である。
項目「ユーザＩＤ」は、図１２で管理されている申請ファイルのユーザＩＤに対応し、ステップＳ６０１で取得されて設定される。

項目「スキャン予約のジョブＩＤ」は、図１２で管理されている「スキャン予約ジョブＩＤ」に対応しており、このＩＤはワークフローサーバで採番されており、ステップＳ６０４でチケットサーバが取得し、ステップＳ６０５でスキャンチケットを生成するときに設定される。

項目「スキャン予約のジョブ名」は、図１２で管理されている「スキャン予約ジョブ名」に対応しており、このジョブ名はワークフローサーバで生成されており、ステップＳ６０５でチケットサーバがスキャンチケットを生成するときに、スキャンチケットに設定される。

項目「機密フラグ」は、ワークフローサーバで、クライアント端末４００から申請された申請内容に従って、画像読み取りすべき書類の重要度を判定し、その判定結果に応じて、「１：一般」「２：秘」「３：極秘」のいずれかの機密フラグが割り当てられる。ここで設定される機密フラグは、後述する複合機３００の表示部にジョブリストを一覧表示する際に、ジョブ名称に引き続いて表示されることになる。書類の重要度の判定については、例えば、ワークフローにおける申請内容が「交通費精算」であれば、「１：一般」になり、機密情報を扱うワークフローで発生した画像読み取りであれば、「２：秘」や「３：極秘」として設定されることになる。ワークフローサーバでは、申請内容と極秘フラグを対応づける機密対応テーブル（図示省略）を外部メモリ２１１に保持しており、そのテーブルを検索することで、機密フラグの値を設定することができる。そして、チケットサーバは、ワークフローサーバから取得した機密フラグの値を、スキャンチケットに設定することになる。

項目「チケット種別」は、ワークフローサーバで、申請情報が新規に登録された（申請された）場合には、チケット種別として、「１：新規」が設定される。また、承認者により、申請情報が否認された場合には、否認理由に応じてチケット種別に「２：追加」「３：差替」のフラグが設定される。より詳細には、図１８にて否認理由「ファイル差し替え」が選択された場合には、チケット種別として「３：差替」が設定され、図１８にて否認理由「ファイル追加」が選択された場合には、チケット種別として「２：追加」が設定される。

項目「ジョブ実行時間」は、スキャン予約を行った日時が設定される項目であり、具体的には、ワークフローサーバからチケットサーバに依頼された時間を設定する。また、管理サーバ１００の１サービスで実現する場合には、クライアント端末４００から、交通費精算の申請がなされた時間を設定してもよい。

項目「ＦＴＰ送信パス」は、スキャンした画像ファイルをＦＴＰ送信する際の送信先のファイルパスである。このＦＴＰ送信パスは、ワークフローサーバにおいて申請された交通費精算伝票ジョブに添付書類として保管するためのファイルパスであり、ＦＴＰ送信パスは、ワークフローサーバ内の外部メモリ２１１に用意されているファイル管理領域である。

項目名「スキャンフラグ」は、図１２で管理されている「スキャンフラグ」に対応しており、スキャンの状態を設定するフラグである。スキャンが実行され、スキャン結果のＰＤＦファイルがＦＴＰ送信されて管理サーバ１００に格納された際に、フラグを「１」に設定する。スキャン待ちの状態では、フラグは「０」となっている。

項目名「スキャンファイル名」は、図１２で管理されている「スキャンファイル名」に対応しており、スキャン結果のファイル名が設定される。スキャンが実行され、ＦＴＰでＰＤＦファイルがいるが送信されて管理サーバ１００に格納された際に、そのファイル名を設定する。このファイル名は、複合機３００で付与されるものであるが、本実施の形態では、「スキャン予約ジョブＩＤ＋タイムスタンプ．ｐｄｆ」というファイル名となる。
以上説明したようなデータ構成で、スキャンチケットが、チケットサーバにより生成される。

そして、ステップＳ６０６では、管理サーバ１００のチケットサーバは、生成されたスキャンチケットを外部メモリ２１１に登録して処理を終了する。なお、このときに、ステップＳ６０３で取得されたスキャン設定情報が、生成されたデータ構造のスキャンチケットに登録される。このデータ構造では、スキャンファイル名の項目の後に、スキャン設定情報として引き続き持たせている。

このように、クライアント端末４００から申請された申請内容に基づいて、複合機３００で画像の読み取り処理が必要であると判断された場合に、管理サーバ１００は、複合機３００で画像の読み取りを実行するための指示内容が定義されているスキャンチケットを生成する（スキャンチケット生成）。より詳細には、クライアント装置からの申請内容情報の新規申請があった場合には、当該申請内容情報に新規に画像データを対応付けるためのスキャンチケットを生成する。

また、申請内容情報が否認されてスキャンチケットが生成される際、否認理由が差し替えを示す場合に、否認された申請内容情報に対応付けて記憶されている画像データを差し替えるためのスキャンチケットを生成し、否認理由が追加を示す場合に、否認された申請内容情報に対応付けて記憶されている画像データに加えて他の画像データを追加するためのスキャンチケットを生成する。

図７は、管理サーバ１００と複合機３００におけるログイン処理からスキャン処理を実行する処理手順の一例を示すフローチャートである。また、ステップＳ４１２のスキャン処理の詳細を示すフローチャートである。なお、ステップＳ７０１、Ｓ７０２、Ｓ７０５〜Ｓ７０９、Ｓ７１４〜Ｓ７１７は、複合機３００のＣＰＵ３０１または画像処理部３１７が実行し、ステップＳ７０３、Ｓ７０４、Ｓ７１０〜Ｓ７１３、Ｓ７１８〜Ｓ７２３は、管理サーバ１００のＣＰＵ２０１が実行する。

ステップＳ７０１では、複合機３００は、操作者であるユーザからログイン要求を受け付け、認証サーバ２００に認証要求を行い、認証されるとログイン成功として、複合機３００の利用を許可する処理である。具体的な一例では、ユーザがＩＣカードをカードリーダ３１９にかざすと、ＩＣカードからカードＩＤが読み取られ、そのカードＩＤを用いて認証サーバ２００に認証要求を行う。認証サーバ２００では、ユーザＩＤとカードＩＤの対応テーブルを保管しており、複合機３００から認証要求されたカードＩＤに対応するユーザＩＤが登録されているか判断し、登録されていれば認証成功とユーザＩＤを、登録されていなければ認証失敗の応答を行う。

ステップＳ７０２では、認証成功されたユーザＩＤをＨＤＤ３０４に記憶し、そのユーザＩＤを用いて管理サーバ１００に対して、スキャンチケットの一覧要求を行う。この一覧要求には、ユーザＩＤが含まれている。また、複合機３００では、ユーザがログアウトするまで、ログインしているユーザＩＤをＨＤＤ３０４に記憶しておき、ログイン中のユーザを把握している。

ステップＳ７０３では、管理サーバ１００は、複合機３００から送信されたスキャンチケットの一覧要求を受信し、その一覧要求に含まれるユーザＩＤに対応するスキャンチケットを特定する。そして、特定されたスキャンチケットのスキャンチケットＩＤ（スキャン予約ジョブＩＤ）、スキャン予約ジョブ名を含む一覧情報を生成・取得する。

ステップＳ７０４では、生成されたスキャンチケットの一覧情報を、要求元の複合機３００に送信する。すなわち、複合機３００からの一覧要求に応じて、スキャンチケット生成部により生成されているスキャンチケットを特定するためのチケット識別情報（スキャンチケットＩＤ）を含むスキャンジョブの一覧情報を、複合機３００に送信する（一覧送信）。

ステップＳ７０５では、複合機３００は、管理サーバ１００からスキャンチケットの一覧情報を受信し、受信したスキャンチケットの一覧情報を、ステップＳ７０６で表示部（タッチパネルであるため操作部３０８）に表示する。ここで表示される操作画面の一例を、図１４に示す。

図１４は、複合機３００において表示されるユーザログイン後の表示画面の一例を示す図である。表示画面１４０１は、複合機３００においてユーザがログインした際に最初に表示される表示画面である。

この表示画面には、スキャン予約の表示領域、プリント予約の表示領域の他、マイメニューとして簡易な操作ボタンが用意されている。スキャン画面への遷移ボタン１４０２が押下されると、スキャン予約の表示領域に表示されているスキャン予約ジョブの一覧が拡大表示される（図１５）。

また、マイメニューの表示領域中にあるスキャンボタン１４０３は、通常の複合機３００における画像読み取りの開始ボタンであり、このボタン１４０３が押下されると、画像読み取り機構（スキャナ部３１４）が駆動し、原稿台に乗せられている原稿の画像読み取り処理が行われる。この通常の画像読み取り処理は、本発明の主要部に密接に関連する処理ではないため、詳細な説明は省略する。

図１５に、複合機３００において表示される、スキャン予約ジョブの一覧を表示する画面であり、かつ、スキャンチケットに基づくスキャン指示を行う際のスキャン確認画面の一例を示す図である。

１５０１には、管理サーバ１００から送信されてきた一覧情報に含まれるスキャン予約ジョブ名が「文書名」の欄に表示される。また、チケット種別フラグの値が「種別」の欄に表示され、機密フラグの値が、「機密」の欄に表示され、スキャンチケットのジョブ実行時間の値が「予約日時」の欄に表示される。なお、この一覧に表示する値は、「文書名」の欄にスキャン予約ジョブ名を表示すれば、ユーザは画像読み取り処理が必要であることが認識できるので、少なくともこの「文書名」を表示することになる。

そして、一覧取得ボタン１５０２は、再度、管理サーバ１００からスキャン予約ジョブの一覧情報の取得要求を行うための指示部である。ログインした後で、管理サーバ１００に新たなワークフローの伝票が登録され、書類添付が必要なジョブでありスキャンチケットが発行されている場合には、この一覧取得ボタンを押下しないと、表示されないため用意されている。

このように、ステップＳ７０６のスキャンチケット一覧表示処理では、管理サーバ１００に対する要求に応じて管理サーバ１００から送信されるスキャンジョブの一覧情報を用いて、表示部（タッチパネル機能を有する操作部３０８）にスキャンジョブの一覧を表示する（表示制御）。

次にステップＳ７０７では、図１５に表示されたスキャンチケットの一覧表示の操作画面（タッチパネル）から、ユーザにより画像読み取り処理を行う文書名の選択を受け付ける。具体的には、タッチパネル機能を備える操作画面（図１５）上で、個別の文書名の部分がタッチされると、画像読み取り処理を行う文書名の選択を受け付けたことになる。
すなわち、表示部に表示されたスキャンジョブの一覧から、実行するスキャンジョブの選択と、実行の指示とを受け付ける（ユーザ操作受付）ことができる。

ステップＳ７０８では、文書名の選択がなされたことにより、図１６の操作画面を表示し、スキャン指示を受け付けたか否かを判断する。図１６の操作画面は、図１５の操作画面において任意の文書名が選択されることにより表示される。図１６の表示例では、先頭の文書１６０１が選択されたことにより、実行の可否を問い合わせるダイアログが表示されている例を示している。ここで、ＯＫボタン１６０２が押下されると、スキャン指示を受け付けたと判断される。

スキャン指示が受け付けられると、ステップＳ７０９において、スキャン指示で選択されているスキャンチケットＩＤ（チケット識別情報）を含むスキャン要求を管理サーバ１００へ送信する。このスキャン要求は、具体的にはスキャンチケットそのものを管理サーバ１００から複合機３００へ送信してもらうための取得要求ということもできる。すなわち、この処理では、タッチパネルの操作部（ユーザ操作受付）により受け付けたスキャンジョブに対応するスキャンチケットを識別するチケット識別情報を含むスキャンチケット取得要求を、管理サーバ１００に送信する（スキャンチケット取得要求手段）。

そして、ステップＳ７１０では、管理サーバ１００は複合機３００からスキャン要求を受信し、受信されたスキャン要求中に含まれるスキャンチケットＩＤを読みだして、対応するスキャンチケットを特定する。そして、ステップＳ７１１では、特定されたスキャンチケットに対応するスキャン設定情報を取得する。ここでいうスキャン設定情報とは、複合機３００で画像の読み取りを実行するための指示内容が定義されている情報であり、ステップＳ６０３で取得され、生成されるスキャンチケットの内部に、ステップＳ６０６で登録されている。なお、スキャン設定情報は、スキャンチケットのデータ構造中に持たせてあるが、スキャンチケットに対応させて（紐づけて）記憶しておき、このスキャン設定情報部分をまとめて、スキャンチケットと呼ぶことにする。

ステップＳ７１２では、特定されたスキャンチケットからチケット種別を判別し、種別ごとに異なる処理を行う。チケット種別が新規である場合は、ステップＳ７１３の処理に移行し、スキャン命令送信処理を行う。

また、チケット種別が新規以外の場合は、ステップＳ７２２の処理に移行し、さらにスキャン種別の判別を行い、チケット種別が追加の場合は、ステップＳ７１３の処理に移行し、スキャン命令送信処理を行う。チケット種別が差替の場合は、ステップＳ７２３の処理に移行する。

ステップＳ７２３では、スキャンチケットに対応する申請内容情報の画像ファイル（否認された申請内容情報のスキャンによって登録されたファイル）の削除命令を発行し、削除を実行する。すなわち、否認理由が差し替えを示す場合に、否認された申請内容情報に対応付けて記憶されている画像データを削除する（画像データ制御）。否認理由が追加を示す場合に、否認された申請内容情報に対応付けて記憶されている画像データを削除されないように制御する。

なお、本実施形態では、スキャンチケットが選択された場合に、申請内容情報の画像ファイルを削除するようにしたが、否認されてチケット種別が「差替」として設定されたスキャンチケットが生成された際に、スキャンチケットに対応する申請内容情報の画像ファイルを削除するようにしてもよい。
これにより、一度申請した申請内容情報に対応する申請に必要な画像ファイルを差し替えることができる。

ステップＳ７１３では、スキャン設定情報を含むスキャン命令を複合機３００に送信する。このスキャン命令は、スキャンチケットのファイルとして送信されてもいいし、リモートスキャン命令のように、ファイル形式でない命令形式であってもよい。いずれの場合でも、複合機には、スキャン設定情報と、ＦＴＰ送信先パスと、スキャン指示を含んでおり、どちらの形式で送信されても、送信される内容をここでは便宜的にスキャンチケットと呼ぶ。つまり、実際に管理サーバ１００から複合機３００へ送信されるスキャンチケットには、少なくともスキャン設定情報と、ＦＴＰ送信先パスと、スキャン指示とを含むものであり、図１３で示したスキャンチケットのすべてのデータ構成を備えていなくてもよい。

このように、複合機３００からのチケット識別情報を含むスキャンチケット取得要求に応じて、生成済みの複数のスキャンチケットからこのスキャンチケット取得要求に含まれるチケット識別情報で識別される指示内容が定義されているスキャンチケットを特定し、複合機３００に送信することができる（ステップＳ７１３：チケット送信）。

ステップＳ７１４では、複合機３００は、管理サーバ１００からスキャンチケット（スキャン命令）を受信し、ステップＳ７１５で、スキャンチケット（スキャン命令）に含まれるスキャン設定情報をＲＡＭ３０２に登録する。そして、ステップＳ７１６で、ＲＡＭ３０２に登録されているスキャン設定情報を画像処理部３１７で画像読み取り設定として反映して、スキャナ部３１４を駆動して画像読み取り処理を実行する。

そして、ステップＳ７１７では、読み取られた画像を画像処理部３１７で送信ファイル形式（本実施例では、ＰＤＦファイル形式）に変換し、スキャンチケットＩＤを属性情報として記憶させ、得られた画像ファイルを、管理サーバ１００へ送信する。なお、スキャンチケットＩＤは、画像ファイルの属性情報の記憶領域に書き込んでもいいが、ＸＭＬファイルを別に用意して、画像ファイルとＸＭＬファイル（属性情報）とを別ファイルとして送信してもよい。また、送信される画像ファイルには、前述したように、スキャンファイル名が、「ジョブＩＤ＋タイムスタンプ．ｐｄｆ」として生成される。

このように、複合機３００では、管理サーバ１００から送信されるスキャンチケット（一部でもよい）を用いて、画像読み取り機構を用いて画像読み取り処理を行い、得られた画像を、スキャンチケットで指定されるＦＴＰ送信先である管理サーバに送信することができる（画像処理）。
ステップＳ７１８では、管理サーバ１００は、複合機３００からスキャンされた画像ファイルと属性情報とを受信する（画像受信）。

そして、ステップＳ７１９で、受信された画像ファイルに対応する申請内容情報を特定する。具体的には、画像ファイルの属性情報に記述されているスキャンチケットＩＤ（スキャン予約ジョブＩＤ）を検索条件として、管理サーバ１００のワークフローサーバの外部メモリ２１１に格納されている申請内容情報を検索する。前述したように、ステップＳ５０６では、クライアント端末４００から申請された申請内容情報と、ステップＳ５０５で生成されたスキャンチケットのＩＤ（チケット識別情報）とを紐づけて（対応づけて）外部メモリ２１１に記憶しているため、検索可能である。

ステップＳ７２０では、管理サーバ１００は、特定された申請内容情報と、受信した画像ファイルを紐づけて登録する。なお、ワークフローシステムにおいて、ワークフローで順に処理される伝票（ジョブ）と、その伝票に関連して登録（アップロード）する添付ファイルの紐づけ処理は既知の技術であるため、その詳細な説明は省略する。

また、チケット種別が「追加」のスキャンチケットを用いてスキャンされた場合には、先のスキャンで紐づけられた画像ファイルに加えて、このスキャンによる画像ファイルが紐づけられるものとする。

すなわち、管理サーバ１００では、画像読み取り処理で用いたスキャンチケットのチケット識別情報を用いて、受信された画像を、クライアント端末４００から申請された申請内容情報と対応づけて記憶することができる。

そして、ステップＳ７２０でスキャンされた画像ファイルを申請内容情報と紐づけて記憶することができた場合には、管理サーバ１００のワークフローサーバは、申請内容情報に必要な添付書類が用意できたとして、ワークフローシステムの伝票（ジョブ）を次の承認アクティビティに処理を進めることができる。承認アクティビティに処理が進むと、承認者である上司に処理が移り、承認の可否を指定してもらうことになる。

そして、ステップＳ７２１で、管理サーバ１００は、申請内容情報に紐づけて画像ファイルを登録できた際に、登録した画像ファイルのスキャンチケットＩＤに対応するスキャンチケットを削除して処理を終了する。

図８は、管理サーバ１００のワークフローサーバとクライアント端末５００の管理者端末における申請済みの伝票（ジョブ）の承認処理行う処理手順の一例を示すフローチャートである。またステップＳ４１３の承認処理の詳細を示すフローチャートである。なお、ステップＳ８０１、Ｓ８０５〜Ｓ８０８、Ｓ８１０〜Ｓ８１１は、クライアント端末５００のＣＰＵ２０１が実行し、ステップＳ８０２〜Ｓ８０４、Ｓ８０９、Ｓ８１２〜Ｓ８１５は、管理サーバ１００のＣＰＵ２０１が実行する。

ステップＳ８０１では、クライアント端末５００は、管理サーバ１００のワークフローサーバに対して、未承認申請情報の要求を行う。具体的には、図９のメインメニュー９２０で、未承認一覧ボタン９０３が押下されることにより、図１７の交通費精算一覧画面１７０１を表示するための要求に相当する。

ステップＳ８０２では、管理サーバ１００のワークフローサーバは、未承認申請情報要求を受信し、ステップＳ８０３で、未承認申請情報を外部メモリ２１１から取得する。ここで、未承認申請情報とは、クライアント端末４００から申請された伝票（ジョブ）のうち、承認者である上司に承認されていない伝票のことである。図５のステップＳ５０２で説明したが、領収書等の添付書類が必要な申請であるか否かを判定しており、添付書類が不要な申請の場合には、承認者の承認アクティビティに処理を進めている。また、領収書等の添付書類が必要な申請である場合であっても、ステップＳ７２０で、添付書類の紐づけが完了すると、承認者の承認アクティビティに処理を進めている。このように、次の承認アクティビティに処理が進んでいる状態であっても、承認者に承認されていない伝票が取得されることになる。ここでは、クライアント端末５００からのユーザ識別情報を含む申請済み情報の取得要求に応じて、前記申請済み情報の表示画面の画面情報を生成することができる（申請済み画面情報生成）。

ステップＳ８０４では、取得された未承認申請情報の一覧情報をクライアント端末５００に送信する。ここでは、図１７の交通費精算一覧画面１７０１の画面情報（ＨＴＭＬ形式のファイル）を送付することになる。

そして、複合機３００で画像の読み取り処理が必要である申請内容情報（図１７の１７０２と１７０３）について、画像読み取り処理により得られた画像が登録済みであるか否かを識別可能に表示画面の画面情報を生成することができる。図１７の１７０１の例では、画像読み取り処理により得られた画像が登録済みであれば１７０３のように、ＰＤＦボタンが明確に表示され、画像読み取り処理により得られた画像が登録済みでなければ１７０２にように、ＰＤＦボタンがグレイアウトで表示されることになる。なお、１７０１の例では、１７０２は画像が登録されていないため、チェックできないようにチェックボックスが制御されている。

そして、ステップＳ８０５では、クライアント端末５００は、管理サーバ１００から未承認申請情報である図１７の交通費精算一覧画面１７０１の画面情報を受信し、ステップＳ８０６で、交通費精算一覧画面をブラウザを用いて表示部に表示する。

ステップＳ８０７では、選択された伝票に対して承認ボタンが押下されたか否かを判定する。より詳細には、承認者が操作するクライアント端末５００で、交通費精算一覧画面１７０１から、承認可能な伝票（例えば、１行目の添付書類不要の伝票、もしくは、３行目１７０３の添付書類が必要で準備できている伝票）が選択されると、図１８の１８００のように承認するか否かを選択できるダイアログが表示され、承認または否認することを指定できる。そして、承認の指定がなされると、ステップＳ８０８へ処理を移す。また、否認が指定されると、ステップＳ８１０へ処理を移す。

ステップＳ８０８では、伝票を識別する情報（ジョブを識別する情報）とともに承認された旨の情報が管理サーバ１００に送信され、ステップＳ８０９では、指定された伝票の申請内容情報が承認登録される。

ステップＳ８１０では、図１８で示すように否認が選択されると、１８０１で否認理由を選択するダイアログを表示する。そして、承認者の選択に応じて否認理由が入力され、ＯＫボタンが押下されると、ステップＳ８１１では、伝票を識別する情報（ジョブを識別する情報）とともに否認された旨の情報（例えば、否認理由を示すフラグ）を管理サーバ１００に送信する。
ステップＳ８１２では、否認理由と伝票を識別する情報（ジョブを識別する情報）を受信する。

ステップＳ８１３では、受信した否認理由に従って、再スキャンが必要か否か（スキャンチケットを再生成するか否か）を判定する。否認理由が「ファイル差し替え」「ファイル追加」である場合には、ステップＳ８１４へ処理を移し、否認理由が「申請データ変更」である場合にはステップＳ８１５へ処理を移す。なお、「申請データ変更」とは、クライアント端末４００で入力された申請内容情報（例えば、金額）に誤りがあった場合に選択される。

なお、本実施形態では、ステップＳ８０９とステップＳ８１２の処理を便宜上分けて説明したが、より詳細には、管理サーバでは、クライアント端末５００からの要求（Ｓ８０８、Ｓ８１１）を受信すると、要求を判定（否認されたか否かを判定）し、否認された場合には、スキャンチケットを生成する。すなわち、ステップＳ８０９とステップＳ８１２は、申請内容情報が承認者によって否認されたか否かを判定する（否認判定）。またステップＳ８１４は、申請内容情報が否認されたと判定された場合に、否認された申請内容情報に再度画像データを対応づけて記憶させるべく、否認された申請内容情報に従って、複合機で画像の読み取りを実行するためのスキャンチケットを生成する。

さらに、否認された否認理由を判定し、否認理由が差し替えを示す場合には、否認された申請内容情報に対応付けて記憶されている画像データを差し替えるためのスキャンチケットを生成する。また、否認理由が追加を示す場合には、否認された申請内容情報に対応付けて記憶されている画像データに加えて他の画像データを追加するためのスキャンチケットを生成する。
また、否認された場合でも、上述のステップＳ８１３のように否認理由によりスキャンチケットを生成するか否かを判定する。

ステップＳ８１４では、否認理由が「ファイル差し替え」「ファイル追加」であったため、再度画像ファイルを添付して申請をさせるために、スキャンチケットを生成する。ここでスキャンチケットを生成するために追加又は差替を含むスキャンチケット生成命令を出力する。なお、スキャンチケットの生成は、否認された申請内容情報に従って、上述の図６の処理で生成される。

ステップＳ８１４でスキャンチケットを生成する場合には、ステップＳ６０５で、否認理由が「ファイル差し替え」の場合には、チケット種別として「３：差替」が決定され、否認理由が「ファイル追加」の場合には、チケット種別として「２：追加」が決定される
ステップＳ８１５では、ステップＳ８１５では、指定された伝票の申請内容情報が否認登録される。

以上説明した本実施の形態によれば、申請内容情報の否認結果に応じて、画像読み取りを行うためのスキャンチケットを発行し、否認された申請内容情報の画像データを容易に更新できる。

そして本実施の形態によれば、新規に生成されたスキャンチケットか、否認によって生成されたスキャンチケットかを判別することができるため申請者の負担も軽減できるという効果が得られる。

以上説明したように、本発明におけるプログラムは、図４〜図８に示すフローチャートの処理に従って管理サーバ１００、複合機３００としてのコンピュータが実行可能なプログラムであり、本発明の記憶媒体は図４〜図８の処理方法を管理サーバ１００、複合機３００が実行可能なプログラムを記憶されている。なお、本発明におけるプログラムは図４〜図８の各装置の処理方法ごと、別の独立したプログラムであってもよい。

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

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

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

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

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

また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。

さらに、本発明を達成するためのプログラムをネットワーク上のサーバ，データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。

また上記のソフトウェアで実現する各処理を、ファームウェアやハードウェア構成にして、各処理を各手段として実現することも可能であり、本発明の技術的範囲はこのようなファームウェアやハードウェア構成による実現も含むものである。

１００ 管理サーバ（チケットサーバ／ワークフローサーバ）
２００ 認証サーバ
３００ 複合機
４００ クライアント端末（申請者用）
５００ クライアント端末（管理者用）
２０１ ＣＰＵ
２０２ ＲＯＭ
２０３ ＲＡＭ
２１０ 表示部（操作部）
２１１ 外部メモリ

Claims (11)

1. 画像読み取り機構を備える画像処理装置と、申請されたファイルを含む申請情報を記憶する記憶装置と通信可能な管理サーバであって、
   前記申請情報に対する否認理由の種別を受け付ける受付手段と、
   前記受付手段により受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定手段と、
   前記決定手段により、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成手段と
   を備えることを特徴とする管理サーバ。
2. 前記否認理由の種別が、前記申請情報に含まれるファイルに対する否認を示す否認種別である場合に、前記スキャンチケット生成手段によりスキャンチケットを生成することを特徴とする請求項１に記載の管理サーバ。
3. 前記否認理由の種別が、ユーザの入力操作により申請画面で入力された情報に対する否認を示す否認種別である場合に、前記スキャンチケット生成手段によりスキャンチケットを生成することなく、前記申請情報の否認登録をする請求項１又は２に記載の管理サーバ。
4. 前記スキャンチケット生成手段により生成されたスキャンチケットに対応する情報の一覧を画像処理装置に送信する送信手段と、
   前記画像処理装置で指定された情報に対応するスキャンチケットを用いたスキャンにより得られたファイルを、前記申請情報に対応付けるべく登録する登録手段と
   を更に備えることを特徴とする請求項１乃至３のいずれか１項に記載の管理サーバ。
5. 前記否認理由の種別が、ファイルの差し替えを示す否認種別である場合に、前記申請情報に含まれるファイルの削除処理を実行する削除実行手段と
   を更に備えることを特徴とする請求項１乃至４のいずれか１項に記載の管理サーバ。
6. 前記記憶装置は、前記管理サーバに備えることを特徴とする請求項１乃至５のいずれか１項に記載の管理サーバ。
7. 画像読み取り機構を備える画像処理装置と、クライアント装置から申請されたファイルを含む申請情報を記憶する記憶装置と、管理サーバを含む画像処理システムであって、
   前記管理サーバは、
   前記申請情報に対する否認理由の種別を受け付ける受付手段と、
   前記受付手段により受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定手段と、
   前記決定手段により、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成手段と
   を備え、
   前記画像処理装置は、
   前記スキャンチケットに基づいた命令により実行された、前記画像読み取り機構による画像読み取り処理により得られたファイルを、所定の送信先に送信するファイル送信手段と
   を備えることを特徴とする画像処理システム。
8. 画像読み取り機構を備える画像処理装置と、申請されたファイルを含む申請情報を記憶する記憶装置と通信可能な管理サーバの処理方法であって、
   前記申請情報に対する否認理由の種別を受け付ける受付ステップと、
   前記受付ステップで受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定ステップと、
   前記決定ステップで、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成ステップと
   を含むことを特徴とする処理方法。
9. 画像読み取り機構を備える画像処理装置と、申請されたファイルを含む申請情報を記憶する記憶装置と通信可能な管理サーバのプログラムであって、
   前記管理サーバを、
   前記申請情報に対する否認理由の種別を受け付ける受付手段と、
   前記受付手段により受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定手段と、
   前記決定手段により、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成手段
   として機能させることを特徴とするプログラム。
10. 画像読み取り機構を備える画像処理装置と、クライアント装置から申請されたファイルを含む申請情報を記憶する記憶装置と、管理サーバを含む画像処理システムの処理方法であって、
    前記管理サーバが、
    前記申請情報に対する否認理由の種別を受け付ける受付ステップと、
    前記受付ステップで受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定ステップと、
    前記決定ステップで、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成ステップとを
    含み、
    前記画像処理装置が、
    前記スキャンチケットに基づいた命令により実行された、前記画像読み取り機構による画像読み取り処理により得られたファイルを、所定の送信先に送信するファイル送信ステップと
    を含むことを特徴とする処理方法。
11. 画像読み取り機構を備える画像処理装置と、クライアント装置から申請されたファイルを含む申請情報を記憶する記憶装置と、管理サーバを含む画像処理システムのプログラムであって、
    前記管理サーバを、
    前記申請情報に対する否認理由の種別を受け付ける受付手段と、
    前記受付手段により受け付けた否認理由の種別により前記申請情報に含まれるファイルに更新が必要となる場合に、前記申請情報に対して新たに対応付けるファイルを生成するために用いられる、前記画像処理装置で画像の読み取りを実行するための命令を出力可能なスキャンチケットを発行するか否かを決定する決定手段と、
    前記決定手段により、前記申請情報のスキャンチケットを発行すると決定された場合に、当該申請情報に対応するスキャンチケットを生成するスキャンチケット生成手段として機能させ、
    前記画像処理装置を、
    前記スキャンチケットに基づいた命令により実行された、前記画像読み取り機構による画像読み取り処理により得られたファイルを、所定の送信先に送信するファイル送信手段
    として機能させることを特徴とするプログラム。

Images