JP6161278B2 - 画像処理システム、管理装置、画像処理装置、画像処理方法およびコンピュータプログラム - Google Patents

Description

本発明は、画像処理システム、管理装置、画像処理装置、画像処理方法およびコンピュータプログラムに関する。

画像処理装置で紙文書を電子化し、電子化された文書データを文書管理サーバに送信して管理するシステムが提案されている。また、画像処理に関する設定（例えば、スキャン設定）と、画像処理結果のサーバへの送信設定が予め設定された指示情報（例えば、スキャンチケット）を用いて、紙文書の画像処理と画像処理結果の送信処理とを効率化させるシステムが考えられる。また、スキャンチケットをサーバで管理し、画像処理装置が必要に応じて上記スキャンチケットを参照することで、複数の画像処理装置から同じスキャンチケットを使用可能にするシステムも考えられる。

特許文献１は、他人に実行させるためのスキャンチケットを、スキャン処理を指示するチケットと送信処理を指示するチケットの二つに分割し、それぞれ別のサーバで管理することで、セキュリティを考慮した運用を可能にする画像処理システムを開示している。

特開２０１２−５１００号公報

しかし、特許文献１が開示する画像処理システムでは、二つに分割したチケットをそれぞれ別個のサーバで管理するので、画像処理装置を使用するユーザ、すなわちスキャンチケットを実行するユーザからは、送信するためのチケットを参照することができない。したがって、チケットを実行するユーザが、スキャン処理によって得られるデータの送信先を確認することができない。

また、特許文献１が開示する画像処理システムでは、二つに分割したチケットの一方が無効になっても、もう一方のチケットを連動して無効にする仕組みを有していない。特許文献１が開示する画像処理システムでは、例えば、送信するためのチケットが無効になっているのに、スキャンチケットが有効のままである場合、スキャンが正常に完了しても、送信できずに失敗する。

本発明は、上記の課題の少なくとも１つを解決するためになされたものである。本発明は、第１のユーザが第２のユーザに実行させる、画像処理と画像処理結果の外部装置への送信処理に関する指示情報を分割することなく、セキュリティを確保しつつ、上記指示情報に応じた処理を実現する仕組みの提供を目的とする。

本発明の一実施形態の画像処理システムは、画像処理を実行する画像処理装置と、前記画像処理と前記画像処理の実行結果の送信処理に関する指示情報を管理する管理装置とを備える。前記管理装置は、前記指示情報の生成要求を第１のユーザから受け付ける受付手段と、前記生成要求において指定されている前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであるかを判断する判断手段と、前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理の実行結果の送信先となる外部装置から、前記管理装置が前記画像処理の実行結果を前記外部装置に送信できるようにするための認可情報を取得する取得手段と、前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理および前記画像処理の実行結果の送信先に関する情報とを用いて、前記第２のユーザが実行可能な指示情報を生成する生成手段と、前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記取得手段で取得した前記認可情報を前記第２のユーザが利用可能な認可情報として、前記生成手段で生成される前記第２のユーザが実行可能な指示情報と紐付けて記憶手段に記憶して管理する管理手段と、前記第２のユーザの指示に応じた前記画像処理装置からの要求を受け付けて、前記第２のユーザが実行可能な指示情報を前記画像処理装置に応答する応答手段と、前記第２のユーザが実行可能な指示情報に基づいて画像処理を実行した前記画像処理装置から、前記画像処理の実行結果を取得する実行結果取得手段と、前記第２のユーザが実行可能な指示情報と紐づけて管理されている前記認可情報を前記記憶手段から取り出し、前記実行結果取得手段で取得した前記画像処理の実行結果を、当該取り出した前記認可情報を用いて前記外部装置に対して送信する送信手段とを備える。

本発明の情報処理システムによれば、ユーザが他のユーザに実行させる、画像処理と画像処理結果の外部装置への送信処理に関する指示情報を分割することなく、セキュリティを確保しつつ、指示情報に応じた処理を実現する仕組みを提供できる。例えば、他人に実行させるためのスキャンチケットを扱う画像処理システムを、セキュリティを確保しつつ、チケットを分割することなく提供できる。

本実施形態の画像処理システムのシステム構成の一例を示す図である。 ＭＦＰの構成例を示す図である。 チケット管理サーバの構成例を示す図である。 画像処理システムの動作処理を説明するシーケンス図である。 画像処理システムの動作処理を説明するシーケンス図である。 チケット管理サーバの機能ブロック図の例である。 チケット情報入力画面の一例を示す図である。 チケット作成処理の例を説明するフローチャートである。 ユーザ管理テーブルの一例を示す図である。 認可情報管理テーブルの一例を示す図である。 チケット管理テーブルの一例を示す図である。 チケット定義ファイルの一例を示す図である。 チケット実行処理の例を説明するフローチャートである。 チケット実行処理の例を説明するフローチャートである。 認可情報の状態とリクエストチケットの状態を同期させる処理の例を説明するフローチャートである。 ＭＦＰの機能ブロック図の一例を示す図である。 ＭＦＰによるチケット実行処理を説明するフローチャートである。 チケット作成処理の例を説明するフローチャートである。

（実施例１）
図１は、本実施形態の画像処理システムのシステム構成の一例を示す図である。図１に示す画像処理システムは、ＭＦＰ１０１、ＰＣ１０２、チケット管理サーバ１０３、文書管理サーバ１０４を備える。ＭＦＰは、Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌの略称である。ＰＣは、Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒの略称である。
ＭＦＰ１０１とＰＣ１０２とは、ＬＡＮ１１０を介して接続される。ＬＡＮは、Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。チケット管理サーバ１０３と文書管理サーバ１０４とは、ＷＡＮ１２０を介して接続される。ＷＡＮは、Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋの略称である。

ＬＡＮ１１０上の装置とＷＡＮ１２０上の装置とは、お互いのネットワークを通して、相互に通信可能である。図１は典型的なネットワーク構成の例であり、各装置がＬＡＮ１１０またはＷＡＮ１２０のどちらにあっても構わない。

ＭＦＰ１０１は、画像処理を実行する画像処理装置である。ＭＦＰ１０１は、コピー機能を有する。また、ＭＦＰ１０１は、原稿画像を読み取り、読み取って得られた文書データを、ＦＴＰプロトコルやＨＴＴＰプロトコル等を用いてチケット管理サーバ１０３に送信するデータ送信機能を有する。ＦＴＰは、Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略称である。ＨＴＴＰは、Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌの略称である。ＰＣ１０２は、チケット管理サーバ１０３や文書管理サーバ１０４のウェブページを閲覧するためのウェブブラウザがインストールされている。

チケット管理サーバ１０３は、スキャンチケット（以降、チケットとも記載する）を一元管理しているサーバである。また、チケット管理サーバ１０３は、ＭＦＰ１０１から送信された文書データを文書管理サーバ１０４に送信する機能を有する。

スキャンチケットは、スキャン処理と、スキャン処理の実行の結果得られる画像データの送信処理に関する指示情報である。チケット管理サーバ１０３が管理する指示情報は、スキャンチケットに限定されない。チケット管理サーバ１０３が、任意の画像処理と当該画像処理の実行結果の送信処理に関する指示情報を管理するようにしてもよい。

文書管理サーバ１０４は、文書データを管理するサーバであり、外部装置に対して文書データの登録や参照、削除といった処理を行うサービスを提供している。また、文書管理サーバ１０４は、サービスを利用するための認可手段（例えば、ＯＡｕｔｈ）を提供している。なお、本発明が適用可能な装置の数は、図１に示す装置の数に限定されない。

図２は、ＭＦＰの構成例を示す図である。ＭＦＰ１０１は、制御部２１０、操作部２１９、プリンタ２２０、スキャナ２２１を備える。制御部２１０は、ＭＦＰ１０１全体の動作を制御する。制御部２１０は、ＣＰＵ（Central Processing Unit）２１１乃至ネットワークＩ／Ｆ（Interface）２１８を備える。

ＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御処理を実行する。ＲＯＭは、Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙの略称である。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＲＡＭ２１３は、Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｏｍｒｙの略称である。

ＨＤＤ２１４は、画像データや各種プログラムを記憶する。ＨＤＤは、Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅの略称である。ＨＤＤ２１４には、後述する図１７のフローチャートに示される処理（チケット実行処理）を行うためのプログラムが記憶されており、ＣＰＵ２１１がこのプログラムをＲＡＭ２１３に読み出し、解析、実行することで、図１７のフローチャートの処理が実行される。

操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続する。操作部２１９には、タッチパネル機能を有する液晶表示部やキーボードなどが備えられている。プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続する。プリンタ２２０で印刷すべき画像データは、プリンタＩ／Ｆ２１６を介して制御部２１０からプリンタ２２０に転送され、プリンタ２２０において記録媒体上に印刷される。

スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続する。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。ネットワークＩ／Ｆ２１８は、制御部２１０（ＭＦＰ１０１）をＬＡＮ１１０に接続する。

図３は、チケット管理サーバの構成例を示す図である。なお、ＰＣ１０２と文書管理サーバ１０４は、チケット管理サーバ１０３と同様の構成を有しているため、ここで合わせて説明する。

チケット管理サーバは、制御部３１０、表示部３１８、キーボード３１９を備える。制御部３１０は、チケット管理サーバ１０３全体の動作を制御する。制御部３１０は、ＣＰＵ３１１乃至ネットワークＩ／Ｆ３１７を備える。ＣＰＵ３１１は、ＲＯＭ３１２に記憶されたコンピュータプログラム(制御プログラム)を読み出して各種制御処理を実行する。ＲＡＭ３１３は、ＣＰＵ３１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。

ＨＤＤ３１４は、画像データや各種プログラムおよび各種管理テーブルを記憶する。チケット管理サーバ１０３のＨＤＤ３１４には、後述する図８、図１３、図１４および図１５のフローチャートに示される処理を実行するためのプログラムが記憶されている。図８のフローチャートに示される処理は、チケット作成処理である。図１３および図１４のフローチャートに示される処理は、チケット実行処理である。図１５のフローチャートに示される処理は、認可情報の状態とリクエストチケットの状態との同期処理である。ＣＰＵ３１１が、ＨＤＤ３１４内のプログラムをＲＡＭ３１３に読み出し、解析、実行することで、図８、図１３、図１４および図１５のフローチャートの処理が実行される。また、チケット管理サーバ１０３のＨＤＤ３１４には、図９、図１０、図１１に示す各種管理テーブルや、図１２に示すチケット定義ファイルが記憶されている。

表示部Ｉ／Ｆ３１５は、表示部３１８と制御部３１０とを接続する。キーボードＩ／Ｆ３１６は、キーボード３１９と制御部３１０とを接続する。ＣＰＵ３１１は、キーボード３１９を介したユーザからの指示を認識し、認識した指示に応じて表示部３１８に表示する画面を遷移させる。

ネットワークＩ／Ｆ３１７は、制御部３１０をＬＡＮ１１０またはＷＡＮ１２０に接続する。ネットワークＩ／Ｆ３１７は、ＬＡＮ１１０上またはＷＡＮ１２０上の他の装置との間で各種情報を送受信する。

図４および図５は、本実施例の画像処理システムの動作処理を説明するシーケンス図である。まず、図４のステップＳ４０１からステップＳ４０９で、他人に実行させるためのチケット（以降、リクエストチケット）を作成する処理を説明する。

ＰＣ１０２が、チケット管理サーバ１０３にログインするため、ユーザが入力した認証情報（ユーザＩＤとパスワード）をチケット管理サーバ１０３に送信する（ステップＳ４０１）。すなわち、ＰＣ１０２が認証要求を行う。チケット管理サーバ１０３が、認証処理を行い、認証に成功したら、チケット情報入力画面を生成してＰＣ１０２に送信する（ステップＳ４０２）。チケット情報入力画面は、チケット情報（スキャン設定、送信設定やチケット実行者を特定する情報など）を入力するための画面である。ここで、チケット管理サーバ１０３にログインしたユーザをチケット作成者、リクエストチケットを実行するユーザを、チケット実行者と定義する。

次に、ＰＣ１０２が、チケット管理サーバ１０３から受信したチケット情報入力画面をウェブブラウザに表示する。そして、チケット作成者が入力を完了したら、チケット情報をチケット管理サーバ１０３に送信する（ステップＳ４０３）。ここで、チケット作成者が入力した送信先は、文書管理サーバ１０４のチケット作成者しかアクセスできない場所（送信先パス）とする。

チケット管理サーバ１０３は、ＰＣ１０２から受け取ったチケット情報をチェックし（ステップＳ４０４）、必要であれば文書管理サーバ１０４に対して認可情報の取得を要求する（ステップＳ４０５）。認可情報の取得要求を受け取った文書管理サーバ１０４は、認可情報を発行し、チケット管理サーバ１０３に認可情報を送信する（ステップＳ４０６）。

ここで、「認証」と「認可」の違いについて説明する。本実施例における「認証」とは、本人認証を指し、個人を特定する手段として使用される。認証の手段（認証情報）としては、ユーザＩＤとパスワードが用いられる。例えば、ステップＳ４０１では、ユーザＩＤとパスワードを用いてチケット管理サーバ１０３にログインしている。

一方、本実施例における「認可」とは、リソース（サービス）へのアクセス権を設定する手段として使用される。例えば、ステップＳ４０６で文書管理サーバ１０４によって発行された認可情報は、チケット管理サーバ１０３に対し、文書管理サーバ１０４のリソースにアクセスを行う許可を与えるために用いられる。文書管理サーバ１０４より受け取った認可情報はチケット管理サーバ１０３において、個人ごとに管理されており、他人が使用できないようになっている。そして、チケット管理サーバ１０３は、文書管理サーバ１０４のリソースにアクセスを行う際に、アクセス許可を得るために認可情報を使用する。

シーケンス図の説明に戻る。次にステップＳ４０７で、チケット管理サーバ１０３は、文書データを文書管理サーバ１０４に送信する際に必要になる認可情報を、チケット作成者しかアクセスできない領域から、チケット実行者がアクセスできる領域に複製する。最後に、チケット管理サーバ１０３は、チケットを生成して（ステップＳ４０８）、チケットの作成が完了したことをＰＣ１０２に通知する（ステップＳ４０９）。なお、ステップＳ４０８で生成されたチケットには、スキャン設定や送信設定、チケット作成者とチケット実行者を特定する情報が含まれている。チケットの詳細に関しては図１２を用いて後述する。

次にステップＳ４１０からステップＳ４２７で、リクエストチケットを実行する処理を説明する。ＭＦＰ１０１が、チケット実行者から、ＭＦＰ１０１にログインするための認証情報（ユーザＩＤとパスワード）を受け取る（ステップＳ４１０）。続いて、ＭＦＰ１０１が、ステップＳ４１０で受け取った認証情報をチケット管理サーバ１０３に送信し、認証を要求する（ステップＳ４１１）。本実施例では、ＭＦＰ１０１は自機に対する認証処理を、チケット管理サーバ１０３に移譲することで実現している。つまり、チケット管理サーバ１０３で認証されたユーザは、同時にＭＦＰ１０１でも認証されたものとする。

ＭＦＰ１０１から認証要求を受けたチケット管理サーバ１０３が、認証処理を行い、認証の結果をＭＦＰ１０１に送信する（ステップＳ４１２）。ＭＦＰ１０１はステップＳ４１２で送信された認証の結果を自機に対する認証の結果として扱う。ＭＦＰ１０１は、認証に成功したら、チケット管理サーバ１０３にチケット実行者が実行可能なチケットの一覧情報の取得を要求する（ステップＳ４１３）。

次に、図５に進んで、要求を受け取ったチケット管理サーバ１０３が、チケット実行者が実行可能なチケットの一覧情報をＨＤＤ３１４から取り出し（ステップＳ４１４）、ＭＦＰ１０１に送信する（ステップＳ４１５）。ここで送信されたチケット一覧には、ステップＳ４０８で生成されたリクエストチケットが含まれている。ＭＦＰ１０１は、ステップＳ４１５で受け取ったチケット一覧を操作部２１９に表示して、チケット実行者の指示を待ち受ける（ステップ４１６）。

次に、ＭＦＰ１０１は、チケット実行者から実行するチケットの選択を受け取ったら（ステップＳ４１７）、チケット管理サーバ１０３にチケット実行者が選択したチケットの詳細情報の取得を要求する（ステップＳ４１８）。ここで、チケット実行者が選択したチケットは、ステップＳ４０８で生成されたリクエストチケットであるものと仮定して以降の処理を説明する。また、チケットを特定する手段として、チケットごとに一意に割り当てられたチケットＩＤを用いる。

チケット管理サーバ１０３は、ステップＳ４１８で受け取った要求に従い、チケットの詳細情報をＨＤＤ３１４より取り出し（ステップＳ４１９）、ＭＦＰ１０１に送信する（ステップＳ４２０）。ＭＦＰ１０１は、受け取ったチケットの詳細情報を解析し（ステップＳ４２１）、スキャン設定を取り出してスキャンを実行する（ステップＳ４２２）。ＭＦＰ１０１は、チケット管理サーバ１０３にチケットＩＤとスキャンして得られた文書データを送信する（ステップＳ４２３）。

チケット管理サーバ１０３は、受け取ったチケットＩＤのチケット詳細情報をＨＤＤ３１４より取り出す（ステップＳ４２４）。チケット管理サーバ１０３は、詳細情報よりリクエストチケットである旨を判断して、文書データを文書管理サーバ１０４に送信する際に必要になる認可情報（ステップＳ４０７で複製しておいた認可情報）をＨＤＤ３１４より取り出す（ステップＳ４２５）。

チケット管理サーバ１０３は、ステップＳ４２５で取り出した認可情報を使用して、文書データを文書管理サーバ１０４へ送信する（ステップＳ４２６）。最後に、チケット管理サーバ１０３は、不要になった認可情報（ステップＳ４０７で複製しておいた認可情報）をＨＤＤ３１４から削除する（ステップＳ４２７）。

次に、図６乃至図１５を参照して、本実施例のチケット管理サーバ１０３の動作処理を説明する。
図６は、チケット管理サーバの機能ブロック図の例である。チケット管理サーバ１０３は、チケット管理部５０１、認証処理部５０２、送信処理部５０３を備える。

チケット管理部５０１は、チケットの管理を行う。チケット管理部５０１は、ＰＣ１０２の依頼を受けてチケットを生成する。また、チケット管理部５０１は、ＭＦＰ１０１の依頼を受けてチケットの一覧や詳細の情報を送信する。認証処理部５０２は、認証および認可の処理を行う。認証処理部５０２は、ＭＦＰ１０１やＰＣ１０２からの要求に応じて、チケット管理サーバ１０３に対する認証処理を行う。また、認証処理部５０２は、文書管理サーバ１０４に対して認可情報の取得要求を出したり、取得した認可情報を管理したりする。送信処理部５０３は、文書データを文書管理サーバ１０４に送信するための処理を行う。

チケット管理部５０１が備える上述した処理部の機能は、チケット管理サーバ１０３のＨＤＤ３１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ３１１がＲＡＭ３１３に読み出し、解析、実行することで実現される。

図７は、チケット情報入力画面の一例を示す図である。チケット情報入力画面６００は、チケット情報を入力するための画面である。チケット情報入力画面６００は、チケット管理サーバ１０３で生成され、ＰＣ１０２のウェブブラウザに表示される。

入力フィールド６０１は、チケット名称の設定を行うための文字列の入力を受け付ける入力フィールドである。領域６０２は、スキャンの設定を行うための入力フィールドが配置された領域である。図７に示す例では、領域６０２において、“ドキュメントサイズ”、“カラーモード”、“解像度”、“倍率”の設定を行うことができる。

入力フィールド６０３乃至６０５は、送信設定を行うための入力フィールドである。入力フィールド６０３は、文書管理サーバ１０４に送信する文書データのファイル形式を設定するための入力フィールドである。ユーザは、入力フィールド６０３上で、文書データのファイル形式を選択することができる。図７に示す例では、入力フィールド６０３において、“ＰＤＦ”（Ｐｏｒｔａｂｌｅ Ｄｏｃｕｍｅｎｔ Ｆｏｒｍａｔ）が選択されている。

入力フィールド６０４は、文書データを送信する文書管理サーバ１０４を設定するための入力フィールドである。ユーザは、入力フィールド６０４上で、文書管理サーバ１０４を選択することができる。図７に示す例では、入力フィールド６０４において、“ＸＸクラウドシステム”が選択されている。

入力フィールド６０５は、文書データを送信するパス（送信先パス）の設定を行うための、文字列の入力を受け付ける入力フィールドである。入力フィールド６０５に入力されるパスは、入力フィールド６０４で選択した文書管理サーバ１０４上のパスである。したがって、ウェブブラウザは、入力フィールド６０４が選択された際に、フィールド６０５に自動的にパスの一部を表示するようにしてもよいし、入力が完了した際に、フィールド６０４とフィールド６０５の整合性をチェックするようにしてもよい。

チェックボックス６０６は、作成するチケットが、他人に実行させるためのチケット（リクエストチケット）かどうかを設定するためのチェックボックスである。チェックボックス６０６にチェックが入っている場合、作成するチケットはリクエストチケットになる。チェックボックス６０６にチェックが入っていない場合、作成するチケットは、自分が実行するためのチケットになる。

領域６０７は、チケット実行者として指定したいユーザを検索するための領域である。図７に示す例では、名前、電子メールアドレス、内線番号でユーザを検索できるようになっているが、別の手段（例えばユーザＩＤなど）で検索できるようにしてもよい。また、チケット実行者として指定するユーザを検索せずに、ユーザＩＤなどで直接指定できるようにしてもよい。また、領域６０７は、チェックボックス６０６にチェックが入っている場合にのみ有効になるようにしてもよい。

ボタン６０８は、チケットの作成を指示するためのボタンである。ボタン６０８が押下されると、ＰＣ１０２（ウェブブラウザ）は、画面で入力された情報をチケット管理サーバ１０３に送信する。また、ボタン６０９は、チケットの作成をキャンセルするためのボタンである。

図８は、チケット管理サーバにおけるチケット作成処理の例を説明するフローチャートである。また、図８は、図４のシーケンス図におけるステップＳ４０１からステップＳ４０９を処理するためのチケット管理サーバ１０３の動作処理を示す。ここで、チケット管理サーバ１０３にログインしたユーザをチケット作成者、リクエストチケットを実行するユーザをチケット実行者と定義する。

まず、認証処理部５０２が、ＰＣ１０２からチケット作成者の認証要求を受け付ける（ステップＳ７０１）。認証要求には、ＰＣ１０２でユーザが入力した認証情報（ユーザＩＤとパスワード）が含まれている。認証処理部５０２は、受け取った認証情報をチケット管理サーバ１０３のＨＤＤ３１４に保存されているユーザ管理テーブルと付き合わせることで認証の成否を判定する（ステップＳ７０２）。認証が失敗した場合は、認証失敗をＰＣ１０２へ通知して（ステップＳ７２１）、処理を終了する。認証が成功した場合は、ステップＳ７０３に進む。

図９は、ユーザ管理テーブルの一例を示す図である。ユーザ管理テーブル１０００は、１レコードで１ユーザを定義している。ユーザＩＤ１００１は、ユーザを一意に識別するための識別子を定義している。メールアドレス１００２は、ユーザのメールアドレスを定義している。ユーザ姓１００３、ユーザ名１００４は、ユーザの名前を定義している。内線番号１００５は、ユーザの内線番号を定義している。パスワード１００６は、ユーザがログインするために必要なパスワードを定義している。パスワード１００５はパスワードそのものを平文として保存するのではなく、パスワードを不可逆な一方向関数に通してメッセージダイジェスト（ハッシュ値）として保存している。

ユーザ管理テーブル１０００は、図７の領域６０７でユーザを検索する際にも使用される。図９に示す例では、レコード１０１１にユーザ“ｙａｍａｄａ”とレコード１０１２のユーザ“ｏｏｋｕｂｏ”が定義されている。

図８に戻って、ステップＳ７０３で、チケット管理部５０１はチケット情報入力画面６００を生成して、ＰＣ１０２へ送信する。チケット管理部５０１は、ＰＣ１０２から送信されるチケット情報を待ち受け（ステップＳ７０４）、受け付けると、ステップＳ７０５に処理を進める。すなわち、チケット管理部５０１が、チケットの生成要求を第１のユーザから受け付ける受付手段として機能する。ここで、ＰＣ１０２より送信されるチケット情報は、ＰＣ１０２のウェブブラウザに表示されたチケット情報入力画面６００でチケット作成者が入力した情報である。

チケット情報を受け付けたチケット管理部５０１は、チケットを一意に識別するためのチケットＩＤを発番する（ステップＳ７０５）。次にチケット管理部５０１は、チェックボックス６０６で設定された情報から、チケットが他人に実行させるチケット（リクエストチケット）であるか否かを判別する（ステップＳ７０６）。すなわち、チケット管理部５０１は、生成要求に対応するチケットが第１のユーザとは異なる第２のユーザに実行させる指示情報であるかを判断する判断手段として機能する。チケットがリクエストチケットである場合は、ステップＳ７０７に進む。チケットがリクエストチケットでない場合は、ステップＳ７１１に進む。

次に、認証処理部５０２が、入力フィールド６０４、６０５で設定された文書管理サーバ１０４に対する有効な認可情報をチケット管理サーバ１０３内に保持しているか否かをチェックする（ステップＳ７０７）。有効な認可情報がチケット管理サーバ１０３内に保持されていない場合は、ステップＳ７０８に進む。有効な認可情報がチケット管理サーバ１０３内に保持されていない場合は、ステップＳ７１０に進む。

認可情報は、チケット管理サーバ１０３のＨＤＤ３１４に保存される認可情報管理テーブルで管理されている。有効な認可情報であるか否かは、認証処理部５０２が文書管理サーバ１０４に認可情報の有効性の問い合わせを行うことで実現する。

図１０は、認可情報管理テーブルの一例を示す図である。認可情報管理テーブル９００は、１レコードで１つの認可情報を管理している。

レコードＩＤ９０１は、レコードを一意に識別するための識別子を定義している。ユーザＩＤ９０２は、当該レコードにアクセス可能なユーザを定義している。例えば、レコードＩＤ９１１のレコードは、ユーザ“ｙａｍａｄａ”しかアクセスできない。

送信先システム９０３は、当該レコードが、どの送信先システム（文書管理サーバ１０４）の認可情報であるかを定義している。送信先パス９０４は、当該レコードの認可情報が有効であるパスを定義している。例えば、レコード９１１の送信先パス９０４の定義は“ｈｔｔｐ：／／ｘｘｃｏｌｕｄｓｙｓｔｅｍ．ｃｏｍ／ｍｙｐａｇｅ／ｙａｍａｄａ／”で始まるＵＲＬであれば、認可情報が有効であると示している。認可情報９０５は、文書管理サーバ１０４に文書データを送信（登録）する際に、登録サービスへのアクセス許可を得るために使用する認可情報である。

有効期限９０６は、当該レコードの認可情報の有効期限を定義している。有効期限は、認可情報を発行した文書管理サーバ１０４で指定される場合もあるが、チケット管理サーバ１０３で独自に指定してもよい。チケットＩＤ９０７は、当該レコードの認可情報を使用可能なチケットを定義している。例えば、レコード９１３はチケットＩＤが“Ｔ００３”であるチケットを実行する際にのみ使用可能であると定義している。チケットＩＤ９０７が定義されていないレコードは、チケットによる制限はない。

複製元レコードＩＤ９０８は、他のレコードからデータを複製したレコードにのみ定義される情報で、データの複製元のレコードＩＤを定義している。例えば、レコード９１３は、レコード９１１のデータを複製して生成されている。そのため、複製元レコードＩＤ９０８は、複製元のレコードＩＤ“Ａ００１”が設定されている。

複製元レコードから複製されるデータは、送信先システム９０３、送信先パス９０４、認可情報９０５、有効期限９０６である。レコードＩＤ９０１は、データを複製する際に、認証処理部５０２によって新規に発番される。ユーザＩＤ９０２にはリクエストチケットのチケット実行者のユーザＩＤが設定される。チケットＩＤ９０７には、図８のステップＳ７０５で発番されたチケットＩＤが設定される。

図８に戻って、ステップＳ７０７において、認証処理部５０２が、図７のチケット情報入力画面６００の入力フィールド６０４で指定された文書管理サーバ１０４に対して、認可情報の取得を要求する（ステップＳ７０８）。認証処理部５０２は、文書管理サーバ１０４から認可情報を受け取ったら、認可情報管理テーブル９００に認可情報を保存する（ステップＳ７０９）。すなわち、認証処理部５０２は、ユーザの認可情報と該ユーザに実行させるチケットとを紐付けて記憶手段に記憶して管理する管理手段として機能する。

次に、認証処理部５０２は、入力フィールド６０４、６０５で設定された文書管理サーバ１０４に対する認可情報を含んだレコードを、認可情報管理テーブル９００から取り出し、チケット実行者がアクセスできるレコードとして複製する（ステップＳ７１０）。認証処理部５０２は、例えば、図１０の認可情報管理テーブル９００内のレコード９１１のデータを複製することで、レコード９１３をチケット実行者に対応するレコードとして生成する。レコード９１１のデータは、チケットが示す画像処理（スキャン処理）の実行結果（画像データ）の送信先となる外部装置に対するチケット作成者（第１のユーザ）の認可情報である。したがって、ステップＳ７１０において、認証処理部５０２は、チケットが示すスキャン処理の実行結果の送信先となる外部装置（文書管理サーバ１０４）に対する第２のユーザの認可情報を生成する第１の生成手段として機能する。

次に、チケット管理部５０１が、ステップＳ７０４で受け付けたチケット情報と、ステップＳ７０５で発番したチケットＩＤに基づいて、チケットを生成する（ステップＳ７１１）。すなわち、チケット管理部５０１は、第１のユーザから受け付けたチケットの生成要求に基づいて、チケットを生成する第２の生成手段として機能する。チケットの詳細はチケット定義ファイルとして記録され、そのファイルはチケット管理サーバ１０３のＨＤＤ３１４に保存されるチケット管理テーブルで管理される。本実施例では、チケット定義ファイルはＸＭＬ（ＥｘｔｅｎｓｉｂｌｅＭａｒｋｕｐＬａｎｇｕａｇｅ）ファイルとして定義されている。

最後に、チケット管理部５０１は、チケットの作成が完了したことをＰＣ１０２に通知し（ステップＳ７１２）、処理を終了する。

図１１は、チケット管理テーブルの一例を示す図である。チケット管理テーブル１１００は１レコードで１つのチケット情報を定義している。

チケットＩＤ１１０１は、チケットを一意に識別するための識別子を定義している。チケット名称１１０２は、チケットの名称を定義している、チケットの名称は、チケット情報入力画面６００の入力フィールド６０１で設定された情報である。チケット作成者１１０３は、当該レコードのチケットを作成したユーザのユーザＩＤを定義している。チケット実行者１１０４は、当該レコードのチケットを実行できるユーザのユーザＩＤを定義している。つまり、チケット作成者１１０３とチケット実行者１１０４に異なるユーザが定義されているレコードは、リクエストチケットのチケット情報である。図１１に示す例では、レコード１１１３が、リクエストチケットのチケット情報である。

チケット定義ファイル１１０５は、チケット定義ファイルのファイル名を定義している。使用可能フラグ１１０６は、当該レコードのチケットが使用可能であるか否かを定義している。実行済フラグ１１０７は、当該レコードのチケットが実行済であるか否かを定義している。本実施例では、チケットの実行は一度限りと定義し、チケットの実行が完了したら、実行済フラグ１１０７を“ｔｒｕｅ”に変更し、未実行のチケットと区別する。

図１２は、チケット定義ファイルの一例を示す図である。チケット定義ファイルは、チケットの詳細情報を記載したファイルである。本実施例では、チケット定義ファイルはＸＭＬ形式で記載されているが、チケット管理サーバ１０３が処理できる形式であればフォーマットは問わない。

タグ１２０１は、“Ｔｉｃｋｅｔ”タグであり、１つのチケットを示している。本タグ内にチケットに関する定義が記載されている。属性１２０２は、“ｎａｍｅ”属性であり、チケット名称を示している。図１２に示す例では、チケット名称は、“議事録送信”である。属性１２０２の値は、チケット情報入力画面６００の入力フィールド６０１で入力された内容が記載される。

属性１２０３は、“ｏｗｎｅｒ”属性であり、チケットを作成したユーザ（チケット作成者）のユーザＩＤが記載されている。チケット作成者は、チケット情報入力画面６００でチケット情報を入力したユーザ、つまり図８のステップＳ７０２の判断処理で認証が成功したユーザである。

属性１２０４は、“ｕｓｅｒ”属性であり、チケットを実行できるユーザ（チケット実行者）のユーザＩＤが記載されている。チケット実行者は、チケット情報入力画面６００の領域６０７で設定されたユーザである。

属性１２０５は、“ｉｄ”属性であり、チケットを一意に識別するためのチケットＩＤが記載されている。図１２に示す例では、チケットＩＤが“Ｔ００３”であり、そのチケット情報は、チケット管理テーブル１１００（図１１）のレコード１１１３に定義されている。

また、属性１２０２、１２０３、１２０４の値は、それぞれ、チケット管理テーブル１１００のチケット名称１１０２、チケット作成者１１０３、チケット実行者１１０４と同一の値である。

タグ１２０６は、“Ｓｃａｎ”タグであり、本タグ内にスキャン設定が記載されている。本タグ内には、チケット情報入力画面６００の領域６０２で入力された内容が記載される。

タグ１２０７は、“ＦｉｌｅＦｏｒｍａｔ”タグであり、文書管理サーバ１０４に送信する文書データのファイル形式を示している。本タグ内には、チケット情報入力画面６００の入力フィールド６０３で選択された値が記載されている。

タグ１２０８は、“ＴａｒｇｅｔＳｙｓｔｅｍ”タグであり、文書データを送信する文書管理サーバ１０４を示している。本タグ内には、チケット情報入力画面６００の入力フィールド６０４で選択された値が記載されている。

タグ１２０９は、“ＴａｒｇｅｔＰａｔｈ”タグであり、文書データを送信する文書管理サーバ１０４上のパス（送信先パス）を示している。本タグ内には、チケット情報入力画面６００の入力フィールド６０５で入力された値が記載されている。

図１３および図１４は、チケット管理サーバにおけるチケット実行処理の例を説明するフローチャートである。また、図１３は、図４および図５のシーケンス図におけるステップＳ４０１からステップＳ４２７を処理するためのチケット管理サーバ１０３の動作処理を示す。

まず、認証処理部５０２が、ＭＦＰ１０１からチケット実行者の認証要求を受け付ける（ステップＳ８０１）。認証要求には、ユーザの操作にしたがってＭＦＰ１０１が入力した認証情報（ユーザＩＤとパスワード）が含まれている。

認証処理部５０２は、受け取った認証情報をチケット管理サーバ１０３のＨＤＤ３１４に保存されているユーザ管理テーブル１０００と付き合わせることで認証の成否を判定する（ステップＳ８０２）。認証が成功である場合は、次のステップＳ８０３に進む。認証が失敗である場合、認証処理部５０２は、認証失敗をＭＦＰ１０１へ通知して（ステップＳ８２１）、処理を終了する。

チケット管理部５０１は、ＭＦＰ１０１からチケット実行者が実行可能なチケットの一覧情報の取得要求が来るのを待ち受ける（ステップＳ８０３）。チケット管理部５０１が、ＭＦＰ１０１からチケット実行者が実行可能なチケットの一覧情報の取得要求を受け付けると、次のステップＳ８０４に処理を進める。続いて、チケット管理部５０１が、チケット管理テーブル１１００から、チケット実行者が実行可能なチケットの一覧情報を取得し（ステップＳ８０４）、ＭＦＰ１０１に送信する（ステップＳ８０５）。ここで送信するチケットの一覧情報には、チケットＩＤやチケットの名称、チケット作成者などの情報が含まれている。ステップＳ８０４で取得する実行可能なチケットの一覧とは、チケット管理テーブル１１００において、使用可能フラグ１１０６が“ｔｒｕｅ”かつ実行済フラグ１１０７が“ｆａｌｓｅ”のレコードである。

次に、チケット管理部５０１が、ＭＦＰ１０１からチケットの詳細情報の取得要求が来るのを待ち受ける（ステップＳ８０６）。チケット管理部５０１が、ＭＦＰ１０１からチケットの詳細情報の取得要求を受け付けると、次のステップＳ８０７に処理を進める。ここで、ＭＦＰ１０１より受け付けるチケットの詳細情報の取得要求では、チケットを特定する情報としてチケットＩＤが用いられる。

チケット管理部５０１は、チケットＩＤに対応するチケット定義ファイルを、チケット管理テーブル１１００を参照して特定し、チケット定義ファイルに記載されたチケットの詳細情報を取得する（ステップＳ８０７）。チケット管理部５０１は、取得したチケットの詳細情報をＭＦＰ１０１に送信する（ステップＳ８０８）。すなわち、チケット管理サ部５０１は、第２のユーザの指示に応じたＭＦＰ１０１からの要求を受け付けて、第２のユーザに実行させるチケットをＭＦＰ１０１に応答する。

次に、図１４に進んで、チケット管理部５０１が、ＭＦＰ１０１から、チケットＩＤと文書データが送信されてくるのを待ち受ける（ステップＳ８０９）。チケット管理部５０１が、ＭＦＰ１０１から、チケットＩＤと文書データとを受け付けると、次のステップＳ８１０に処理を進める。ここで、ＭＦＰ１０１から送信されるのは、ステップＳ８０８で送信したチケット詳細情報のチケットＩＤと、チケット詳細情報に定義されたスキャン設定でスキャンした文書データである。すなわち、チケット管理部５０１は、チケットに基づいてスキャン処理を実行したＭＦＰ１０１からスキャン処理の実行結果を取得する実行結果取得手段として機能する。

チケット管理部５０１は、ステップＳ８０９で受信したチケットＩＤに対応するチケット定義ファイルを、チケット管理テーブル１１００を参照して特定し、チケット定義ファイルに記載されたチケットの詳細情報を取得する（ステップＳ８１０）。

次に、チケット管理部５０１が、チケットがリクエストチケットであるか否かを判別する。チケットがリクエストチケットである場合は、ステップＳ８１２へ処理を進める。チケットがリクエストチケットでない場合は、ステップＳ８１３へ処理を進める（ステップＳ８１１）。ここで、チケット管理部５０１は、チケットがリクエストチケットであるか否かを、チケットの詳細情報に定義されたチケット作成者とチケット実行者が別ユーザであるか否かで判別する。チケット作成者とチケット実行者が別ユーザである場合、チケット管理部５０１は、チケットがリクエストチケットであると判断する。チケット作成者とチケット実行者が同一ユーザである場合、チケット管理部５０１は、チケットがリクエストチケットでなく、通常のチケットであると判断する。

次に、ステップＳ８１２において、認証処理部５０２が、ステップＳ８０２で認証を受けたユーザのユーザＩＤとチケットＩＤをキーにして、認可情報管理テーブル９００から、文書管理サーバ１０４に対する認可情報を取り出す。ここで、ステップＳ８０２で認証を受けたユーザは、チケットを実行しているユーザであり、チケットの詳細情報に定義されたチケット実行者と同一ユーザである。すなわち、認証処理部５０２は、管理されている第２のユーザの許可情報を用いて文書管理サーバ１０４からのアクセス許可を得る許可取得手段として機能する。

一方、ステップＳ８１３では、認証処理部５０２が、ステップＳ８０２で認証を受けたユーザのユーザＩＤとチケット詳細情報に定義された送信先をキーにして、認可情報管理テーブル９００から、文書管理サーバ１０４に対する認可情報を取り出す。

ステップＳ８１４において、送信処理部５０３が、前ステップ（Ｓ８１２，Ｓ８１３）で取り出した認可情報を使って、文書管理サーバ１０４が提供する文書データの登録サービスへのアクセス許可を取得する。そして、送信処理部５０３が、チケットに定義された送信先（文書管理サーバ１０４）に対して文書データを送信（登録）する。ここで、送信処理部５０３が送信する文書データは、ステップＳ８０９でＭＦＰ１０１から受信した文書データである。すなわち、送信処理部５０３は、アクセス許可が得られた場合に、画像処理の実行結果を外部装置に対して送信する送信手段として機能する。

文書データの送信が完了したら、チケット管理部５０１が、実行したチケットをチケット管理テーブル１１００において実行済に変更する（ステップＳ８１５）。認証処理部５０２が、実行したチケットがリクエストチケットであるかを判断する（ステップＳ８１６）。実行したチケットがリクエストチケットでない場合は、処理を終了する。実行したチケットがリクエストチケットである場合は、認証処理部５０２が、ステップＳ８１２で取りだした認可情報を認可情報管理テーブル９００から削除して（ステップＳ８１７）、処理を終了する。

図１５は、チケット管理サーバにおける、認可情報の状態とリクエストチケットの状態を同期させる処理の例を説明するフローチャートである。図１５に示すフローチャートの処理は定期的に実行されてもよいし、チケット管理サーバ１０３のユーザによって明示的に実行されてもよい。

まず、認証処理部５０２が、認可情報管理テーブル９００から、処理対象のレコード（以降、検査レコードと呼ぶ）を一つ取り出す（ステップＳ１３０１）。次に、認証処理部５０２が、検査レコードに定義されている認可情報９０５が有効な認可情報であるか否かを判断する（ステップＳ１３０２）。認証処理部５０２は、有効な認可情報であるか否かを、文書管理サーバ１０４に認可情報の有効性の問い合わせを行うことで判断する。すなわち、認証処理部５０２は、記憶手段に記憶されている許可情報が有効であるか否かを確認する確認手段として機能する。検査レコードに定義されている認可情報９０５が有効な認可情報である場合は、ステップＳ１３０７に進む。検査レコードに定義されている認可情報９０５が有効な認可情報でない場合は、ステップＳ１３０３に進む。

ステップＳ１３０３において、認証処理部５０２が、検査レコードを複製したレコード（以降、複製レコードと呼ぶ）を認可情報管理テーブル９００から検索する。具体的には、認証処理部５０２は、認可情報管理テーブル９００から、複製元レコードＩＤ９０８が検査レコードのレコードＩＤと一致するレコードを検索する。認証処理部５０２が、検索した結果、複製レコードがある場合には、ステップＳ１３０５へ処理を進める。複製レコードがない場合は、ステップＳ１３０７へ処理を進める（ステップＳ１３０４）。

ステップＳ１３０５において、チケット管理部５０１が、複製レコードを使用するチケット（リクエストチケット）を無効にする。具体的には、チケット管理部５０１は、チケット管理テーブル１１００よりチケットＩＤ１１０１が、複製レコードに定義されているチケットＩＤ９０７と一致するレコードを特定し、そのレコードの使用可能フラグ１１０６を“ｆａｌｓｅ”に変更する。すなわち、チケット管理部５０１は、無効であることが確認された認可情報を複製元とする許可情報を記憶手段内で検索し（Ｓ１３０３）、検索された許可情報に紐付くチケットを無効にする（Ｓ１３０５）。

次に、認証処理部５０２が、検査レコードに定義されたユーザＩＤ９０２のユーザ（Ｓ１３０５で処理したリクエストチケットのチケット作成者）に対して、認可情報が無効である旨とリクエストチケットが無効になった旨を通知する（ステップＳ１３０６）。本実施例では通知方法として、電子メールを使用する。具体的には、認証処理部５０２は、検査レコードに定義されたユーザＩＤ９０２のメールアドレスを、ユーザ管理テーブル１０００より取得し、取得したメールアドレスに対して、電子メールを送付する。

次に、認証処理部５０２は、認可情報管理テーブル９００に処理対象のレコードが他に存在するかを判断する。処理対象のレコードが他に存在する場合は、ステップＳ１３０１に戻る。処理対象のレコードが他に存在しない場合は、処理を終了する。

次に、図１６および図１７を参照して、本実施例のＭＦＰ１０１の動作処理の詳細について説明する。
図１６は、本実施例のＭＦＰの機能ブロック図の一例を示す図である。ＭＦＰ１０１は、チケット処理部１４０１、認証処理部１４０２、スキャン処理部１４０３、送信処理部１４０４を備える。

図１６に示す各処理部の機能と、図１７のフローチャートの処理は、ＭＦＰ１０１のＨＤＤ２１４に記憶されているプログラム（ソフトウェア）を、ＣＰＵ２１１がＲＡＭ２１３に読み出し、解析、実行することで実現される。

チケット処理部１４０１は、チケットの処理を行う。チケット処理部１４０１は、チケット管理サーバ１０３からチケットの一覧情報や詳細情報を取得したり、取得したチケットの情報を操作部２１９に表示したりする。

認証処理部１４０２は、認証の処理を行う。認証処理部１４０２は、ユーザの要求を受けてＭＦＰ１０１に対する認証処理を行ったり、チケット管理サーバ１０３に対して認証要求を出したりする。スキャン処理部１４０３は、スキャンの処理を行う。スキャン処理部１４０３は、チケットに定義されたスキャン設定にしたがってスキャナ２２１でスキャンを実行する。送信処理部１４０４は、スキャン処理部１４０３でスキャンした文書データをチケット管理サーバ１０３に送信する処理を行う。

図１７は、ＭＦＰによるチケット実行処理を説明するフローチャートである。このチケット実行処理は、図４および図５のシーケンス図におけるステップＳ４１０からステップＳ４２３の処理を実現するためのＭＦＰ１０１の動作処理である。

まず、認証処理部１４０２が、ＭＦＰ１０１にログインするためにユーザが操作部２１９から入力した認証情報（ユーザＩＤとパスワード）を受け取る（ステップＳ１５０１）。認証処理部１４０２が、受け取った認証情報をチケット管理サーバ１０３に送信し、認証を要求する（ステップＳ１５０２）。本実施例では、ＭＦＰ１０１は、自機に対する認証処理を、チケット管理サーバ１０３に移譲することで実現している。つまり、チケット管理サーバ１０３で認証されたユーザは、同時にＭＦＰ１０１でも認証されたものとする。

次に、認証処理部１４０２は、チケット管理サーバ１０３から認証結果を受信する（ステップＳ１５０３）。認証処理部１４０２が、受信した認証結果を自機に対する認証の結果として扱う。認証処理部１４０２は、認証に成功している場合は、ステップＳ１５０４へ処理を進める。認証処理部１４０２は、認証に失敗している場合は、認証失敗をユーザに通知するため、操作部２１９に認証が失敗した旨を表示して（ステップＳ１５２１）、処理を終了する。ここで、認証に成功したユーザ（ＭＦＰ１０１にログインしたユーザ）をチケット実行者と定義する。

ステップＳ１５０５において、チケット処理部１４０１が、チケット管理サーバ１０３に対して、チケット実行者が実行可能なチケットの一覧情報の取得を要求する。チケット処理部１４０１が、チケット管理サーバ１０３から送信されるチケットの一覧情報を待ち受ける（ステップＳ１５０６）。チケット処理部１４０１が、チケット管理サーバ１０３から送信されるチケットの一覧情報を受信すると、次のステップＳ１５０７に処理を進める。そして、チケット処理部１４０１は、受信したチケットの一覧情報を操作部２１９に表示する。チケット処理部１４０１が、チケットの一覧情報を、操作部２１９にボタンとして表示してもよいし、リストとして表示してもよい。

次に、チケット処理部１４０１が、チケット実行者がチケットの実行のためにチケットを選択するのを待ち受ける（ステップＳ１５０８）。チケット処理部１４０１が、チケット実行者からチケットの選択を受け付けると、次のステップＳ１５０９に処理を進める。そして、チケット処理部１４０１が、チケット実行者が選択したチケットの詳細情報の取得をチケット管理サーバ１０３に要求する。

次に、チケット処理部１４０１が、チケット管理サーバ１０３から送信されたチケットの詳細情報を受け取る（ステップＳ１５１０）。チケット処理部１４０１が、受け取ったチケットの詳細情報を解析してスキャン設定を取り出す（ステップＳ１５１１）。スキャン処理部１４０３が、ステップＳ１５１１で取り出したスキャン設定にしたがってスキャナ２２１でスキャンを実行する（ステップＳ１５１２）。

そして、送信処理部１４０４は、実行したチケットのチケットＩＤとスキャンして得られた文書データをチケット管理サーバ１０３に送信し（ステップＳ１５１３）、処理を終了する。

以上、実施例１において説明した手順により、他人に実行させるためのスキャンチケットを扱う画像処理システムを、セキュリティを確保しつつ、チケットを分割することなく提供できる。また、認可情報の状態とリクエストチケットの状態を同期させることができるようになり、ユーザの利便性が向上する。

（実施例２）
次に、実施例２について説明する。前述した実施例１の情報処理システムでは、文書管理サーバ１０４の認可情報を、チケットを作成する際に、認可情報管理テーブル９００において、チケット作成者のレコードからチケット実行者のレコードへ複製していた。これに対し、実施例２の情報処理システムでは、認可情報を複製するのではなく、作成したチケット専用の認可情報を取得するようにする。

図１８は、実施例２におけるチケット管理サーバによるチケット作成処理の例を説明するフローチャートである。図８と同じステップ番号を持つステップは、図８のフローチャートで説明した各ステップと同様の処理が行われるため説明は省略する。

図１８のフローチャートが、図８のフローチャートと異なるのは、図１８では、図８のステップＳ７０７からステップＳ７１０の代わりに、ステップＳ１６０１とステップＳ１６０２を処理する点である。

ステップＳ１６０１において、認証処理部５０２が、入力フィールド６０４で指定された文書管理サーバ１０４に対して、入力フィールド６０５の送信先パスに文書データを送信する際に必要になる認可情報の取得を要求する。ここで要求する認可情報は、文書データを登録するのに最低限必要なリソース、サービスに対する認可情報とする。認可情報の有効範囲は、文書管理サーバ１０４によって異なるが、文書管理サーバ１０４が提供する範囲において、最低限必要なリソース、サービスを要求する。例えば、文書管理サーバ１０４から文書データを取得するサービス（取得サービス）と、文書管理サーバ１０４に文書データを登録するサービス（登録サービス）があるのなら、最低限必要なのは登録サービスだけである。また、認可情報が有効である文書管理サーバ１０４のパスを限定できるのであれば、入力フィールド６０５の送信先パスのみアクセスできる認可情報を要求する。

ステップＳ１６０２において、認証処理部５０２が、文書管理サーバ１０４から認可情報を受け取ったら、認可情報管理テーブル９００に認可情報を保存する。このとき、レコードに記録されるのは、レコードＩＤ９０１、ユーザＩＤ９０２、送信先システム９０３、送信先パス９０４、認可情報９０５、有効期限９０６、チケットＩＤ９０７である。

以上、実施例２において説明した手順により、作成したチケット専用の認可情報を取得することで、他人に実行させるためのスキャンチケットを扱う画像処理システムを、高いセキュリティを確保したうえで、ユーザに提供できる。

（その他の実施例）
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。

１０１ ＭＦＰ
１０２ ＰＣ
１０３ チケット管理サーバ
１０４ 文書管理サーバ

Claims (8)

1. 画像処理を実行する画像処理装置と、前記画像処理と前記画像処理の実行結果の送信処理に関する指示情報を管理する管理装置とを備えるシステムであって、
   前記管理装置は、
   前記指示情報の生成要求を第１のユーザから受け付ける受付手段と、
   前記生成要求において指定されている前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであるかを判断する判断手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理の実行結果の送信先となる外部装置から、前記管理装置が前記画像処理の実行結果を前記外部装置に送信できるようにするための認可情報を取得する取得手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理および前記画像処理の実行結果の送信先に関する情報を用いて、前記第２のユーザが実行可能な指示情報を生成する生成手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記取得手段で取得した前記認可情報を前記第２のユーザが利用可能な認可情報として、前記生成手段で生成される前記第２のユーザが実行可能な指示情報と紐付けて記憶手段に記憶して管理する管理手段と、
   前記第２のユーザの指示に応じた前記画像処理装置からの要求を受け付けて、前記第２のユーザが実行可能な指示情報を前記画像処理装置に応答する応答手段と、
   前記第２のユーザが実行可能な指示情報に基づいて画像処理を実行した前記画像処理装置から、前記画像処理の実行結果を取得する実行結果取得手段と、
   前記第２のユーザが実行可能な指示情報と紐づけて管理されている前記認可情報を前記記憶手段から取り出し、前記実行結果取得手段で取得した前記画像処理の実行結果を、当該取り出した前記認可情報を用いて前記外部装置に対して送信する送信手段と、
   を備えることを特徴とする画像処理システム。
2. 前記管理装置は、さらに、
   前記記憶手段に記憶されている認可情報が有効であるか否かを前記外部装置に確認する確認手段を備え、
   前記管理手段は、前記確認手段により無効であることが確認された認可情報を前記記憶手段内で検索し、検索された認可情報に紐付く指示情報を無効にする
   ことを特徴とする請求項１に記載の画像処理システム。
3. 前記管理装置が備える前記管理手段は、前記送信手段が前記画像処理の実行結果を前記外部装置に対して送信した後に、前記第２のユーザが実行可能な指示情報と紐づけて管理されている前記認可情報を前記記憶手段から削除する
   ことを特徴とする請求項１に記載の画像処理システム。
4. 前記画像処理は、文書のスキャン処理である
   ことを特徴とする請求項１乃至３のいずれか１項に記載の画像処理システム。
5. 画像処理装置が行う画像処理と前記画像処理の実行結果の送信処理に関する指示情報を管理する管理装置であって、
   画像処理と前記画像処理の実行結果の送信処理に関する指示情報の生成要求を第１のユーザから受け付ける受付手段と、
   前記生成要求において指定されている前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであるかを判断する判断手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理の実行結果の送信先となる外部装置から、前記管理装置が前記画像処理の実行結果を前記外部装置に送信できるようにするための認可情報を取得する取得手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記生成要求において指定されている前記画像処理および前記画像処理の実行結果の送信先に関する情報を用いて、前記第２のユーザが実行可能な指示情報を生成する生成手段と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると前記判断手段で判断した場合、前記取得手段で取得した前記認可情報を前記第２のユーザが利用可能な認可情報として、前記生成手段で生成される前記第２のユーザが実行可能な指示情報と紐付けて記憶手段に記憶して管理する管理手段と
   を備えることを特徴とする管理装置。
6. 請求項５に記載の管理装置に対して、前記第２のユーザの指示に基づいて前記第２のユーザが実行可能な指示情報を要求する要求手段と、
   前記要求に応じた前記管理装置から前記第２のユーザが実行可能な指示情報を取得し、前記第２のユーザが実行可能な指示情報が示す画像処理を実行する実行手段と、
   前記画像処理の実行結果を前記管理装置に送信する送信手段とを備える
   ことを特徴とする画像処理装置。
7. 画像処理を実行する画像処理装置と、前記画像処理と前記画像処理の実行結果の送信処理に関する指示情報を管理する管理装置とを備えるシステムにおける画像処理方法であって、
   前記管理装置が、前記指示情報の生成要求を第１のユーザから受け付ける受付工程と、
   前記管理装置が、前記生成要求において指定されている前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであるかを判断する判断工程と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると判断された場合、前記管理装置が、前記生成要求において指定されている前記画像処理の実行結果の送信先となる外部装置から、前記管理装置が前記画像処理の実行結果を前記外部装置に送信できるようにするための認可情報を取得する取得工程と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると判断された場合、前記管理装置が、前記生成要求において指定されている前記画像処理および前記画像処理の実行結果の送信先に関する情報を用いて、前記第２のユーザが実行可能な指示情報を生成する生成工程と、
   前記指示情報の実行者が前記第１のユーザとは異なる第２のユーザであると判断された場合、前記管理装置が、前記取得工程で取得した前記認可情報を前記第２のユーザが利用可能な認可情報として、前記生成工程で生成される前記第２のユーザが実行可能な指示情報と紐付けて記憶手段に記憶して管理する管理工程とを有する
   ことを特徴とする画像処理方法。
8. コンピュータを、請求項１乃至５のいずれか１項に記載の前記管理装置の各手段として機能させるためのコンピュータプログラム。
   

Images