JP2011004352A - 画像処理システム、その制御方法、及びプログラム - Google Patents

Abstract

【課題】他の画像処理装置で実行されているジョブに関する所定のイベントを受信すると、イベントを受信した画像処理装置においてその後の処理を好適に制御する画像処理システムを提供する。
【解決手段】第１画像処理装置と第２画像処理装置とが通信可能に接続された画像処理システムにおいて、第１画像処理装置にユーザがログインした場合に所定のイベントの発生を通知するよう第２画像処理装置に要求し、第２画像処理装置から所定のイベントが発生したことが通知された場合に、所定のイベントが発生したジョブに対する指示をログインしているユーザから受け付けて、受け付けた指示を第２画像処理装置に送信することができる画像処理システムを提供する。
【選択図】図８

Description

本発明は、外部装置と通信を行う画像処理システム、その制御方法及びプログラムに関するものである。

近年のオフィス環境では、ネットワークを介して接続された複数のＭＦＰやプリンタを、用途や装置の状況に応じて使い分けることが一般的になってきている。また、同時に複数の装置を用いて複数の処理を平行に行うことも可能になっている。例えば、プリンタで印刷を行っている最中に別のＭＦＰで原稿コピーを行ったり、大量の原稿を複数のＭＦＰに分けて並行してスキャンするなどといった利用方法がある。

また、セキュリティ意識の高まりからパーソナルコンピュータなどの情報処理装置に限らず、ＭＦＰやプリンタなどの装置においてもユーザ認証に基づいたアクセス制御が行われるようになっている。ユーザ認証を行うことにより、ＭＦＰにログインしたユーザに対して各種ＭＦＰの機能や保存データに対するアクセス制御を行うことが可能になる。例えば、ユーザに関連付けられた印刷やコピー、ＦＡＸ送信／受信、保存文書といったジョブは、関連付けられたユーザのみが実行でき、キャンセルや停止などのジョブ操作を行うこともできる。さらに、ジョブの名称などの属性やジョブの処理結果などの履歴も関連付けられたユーザのみが参照できる。

さらに、ネットワークを介して他の装置からジョブ操作を行う場合や属性又は履歴の参照を行う場合も直接ＭＦＰにログインしてジョブ操作や参照を行う場合と同様に前述のアクセス制御は有効にする必要がある。即ち、ネットワークを介してジョブ操作や参照を行う場合には、他の装置で行ったユーザ認証情報を当該ＭＦＰに送信する。ＭＦＰは、受信したユーザ認証情報を用いて直接ユーザがログインした場合と同様のアクセス制御を行う。

一方、ネットワークを介して、印刷指示したユーザに印刷結果を知らせる方法として、特許文献１には、クライアント装置とサーバ装置とによって、印刷指示したユーザが現在ログインしている装置を管理する技術が提案されている。印刷装置は印刷結果を通知する際に、印刷指示したユーザが現在ログインしている装置をサーバ装置に問い合わせて、現在ログインしている装置に印刷結果を送信する。特許文献１では、印刷結果を通知する際にユーザが現在ログインしている装置を調べてログインしている装置に印刷結果を送信することで、印刷指示を行ったユーザに印刷結果をすばやく確実に伝えることを可能にしている。

特開２００７−２８００４５号公報

しかしながら、上述のように単に印刷結果をユーザがログインしている装置に送信する場合、送信された印刷結果を受信した装置では現在ログイン中のユーザに参照させてよい情報であるか否かを判断することができない。また、印刷処理が用紙なしやメモリフルなどの理由により中断している場合に、送信された印刷結果を受信した装置では、現在ログイン中のユーザがジョブ操作を行うことができるか否かを判断することができないという問題がある。

本発明は、上述の問題に鑑みて成されたものであり、他の画像処理装置で実行されているジョブに関する所定のイベントを受信すると、イベントを受信した画像処理装置においてその後の処理を好適に制御する画像処理システムを提供することを目的とする。

本発明は、例えば、第１画像処理装置と第２画像処理装置とが通信可能に接続された画像処理システムとして実現できる。第１画像処理装置は、ユーザ認証を行い、ユーザ認証されたユーザを第１画像処理装置にログインさせる認証手段と、認証手段による認証により第１画像処理装置にログインしたユーザが第２画像処理装置にログインしている場合に、第２画像処理装置にて実行されるジョブに所定のイベントが発生したことを通知するよう第２画像処理装置に要求する要求手段と、要求手段による要求に応答して第２画像処理装置から所定のイベントの発生が通知された場合に、所定のイベントが発生したジョブに対する指示をログインしているユーザから受け付ける受付手段と、受付手段により指示が受け付けられた場合に、指示を第２画像処理装置に送信する送信手段と、を備え、第２画像処理装置は、要求手段による要求を受信する受信手段と、受信手段により要求が受信された場合であって、第２画像処理装置にて実行されるジョブに所定のイベントが発生した場合に、所定のイベントの発生を第１画像処理装置に通知するイベント通知手段と、送信手段により送信された指示に基づいて所定のイベントが発生したジョブを制御する制御手段と、を備えることを特徴とする。

本発明によれば、他の画像処理装置で実行されているジョブに関する所定のイベントを受信すると、イベントを受信した画像処理装置においてその後の処理を好適に制御する画像処理システムを提供できる。

本実施形態に係る画像処理システム１０００の全体構成を示す図である。 本実施形態に係るＭＦＰの構成例を示すブロック図である。 本実施形態に係るジョブの状態変化通知を依頼する処理手順を示すフローチャートである。 本実施形態に係るジョブの状態変化通知を依頼するための送信パケットの構成例を示す図である。 本実施形態に係るジョブの状態変化通知依頼を受信した際の処理手順を示すフローチャートである。 本実施形態に係るジョブの実行中にイベントが発生した場合の処理手順を示すフローチャートである。 本実施形態に係るイベント通知の送信パケットの構成例を示す図である。 本実施形態に係るイベント通知を受信した際の処理手順を示すフローチャートである。 本実施形態に係るイベント通知内容の詳細表示及びジョブ操作処理の処理手順を示すフローチャートである。 本実施形態に係るジョブの代行先を検索する処理手順を示すフローチャートである。 本実施形態に係るジョブ代行先を判断するためのジョブ属性及び能力情報の一例を示す図である。

以下に本発明の一実施形態を示す。以下で説明される個別の実施形態は、本発明の上位概念、中位概念及び下位概念など種々の概念を理解するために役立つであろう。また、本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されるわけではない。

＜第１の実施形態＞
まず、図１を参照して、本実施形態に係る画像処理システム１０００の構成について説明する。画像処理システム１０００では、ＬＡＮ１０１０、ルータ１０１１、インターネット／イントラネット１０１２、及びＰＴＳＮ／ＩＳＤＮ１０３０を介して複数の各種装置が通信可能に接続されている。１００１は、本実施形態に係るＭＦＰであり、スキャナとプリンタとを備えている。ＭＦＰ１００１は、スキャナを用いて読み取った画像をＬＡＮ１０１０に流したり、ＬＡＮ１０１０から受信した画像をプリンタを用いて印刷（シート上への画像形成）することができる。即ち、ＭＦＰ１００１は、画像読取装置として機能することができ、かつ、画像処理装置として機能することができる。また、ＭＦＰ１００１は、スキャナを用いて読み取った画像をＦＡＸ送信機能により、ＰＳＴＮ／ＩＳＤＮ１０３０に送信したり、ＰＳＴＮ／ＩＳＤＮ１０３０から受信した画像をプリンタによりプリントアウトすることもできる。

１００２は、データベースサーバであり、ＭＦＰ１００１により読み込んだ２値画像及び多値画像のデータをデータベースとして管理する。１００３は、データベースサーバ１００２のデータベースクライアントであり、データベースサーバ１００２に保存されている画像の閲覧や検索等を行うことができる。１００４は、電子メールサーバであり、ＭＦＰ１００１により読み取った画像を電子メールの添付として受け取ることができる。１００５は、電子メールサーバ１００４のクライアントであり、電子メールサーバ１００４で受け取ったメールを受信し閲覧したり、電子メールを送信したりすることができる。

１００６はＨＴＭＬ文書をＬＡＮ１０１０に接続された各装置に提供するＷＷＷサーバであり、ＭＦＰ１００１によりＷＷＷサーバ１００６で提供されるＨＴＭＬ文書をプリントアウトできる。１００７は、ＤＮＳサーバ１００７である。ルータ１０１１は、ＬＡＮ１０１０をインターネット／イントラネット１０１２と連結する。インターネット／イントラネット１０１２には、データベースサーバ１０２１、ＷＷＷサーバ１０２２、電子メールサーバ１０２３、ＭＦＰ１０２４が接続されている。一方、ＭＦＰ１００１は、ＰＳＴＮ／ＩＳＤＮ１０３０を介して、ＦＡＸ装置１０３１と送受信可能になっている。また、ＬＡＮ１０１０上にＭＦＰ１０４０も連結されており、ＭＦＰ１００１により読み取った画像をプリントアウトすることができる。

次に、図２を参照して、本実施形態に係る画像処理装置であるＭＦＰ１００１のハードウェア構成について説明する。なお、ＭＦＰ１１００、１０４０については、ＭＦＰ１００１と同様のハードウェア構成であるため、説明を省略する。図２に示すように、ＣＰＵ２０１、ＲＡＭ２０２、ＬＣＤ２０３、入力デバイス２０４、ＲＯＭ２０５、スキャナエンジン２０６、プリンタエンジン２０７、ＤＩＳＫ２０８及びネットワークＩ／Ｆ２０９がシステムバス２１０を介して相互に接続されている。

画像処理装置を制御するプログラムは、ＲＯＭ２０５又はＤＩＳＫ２０８に記憶されており、必要に応じてＲＡＭ２０２に読み出されてＣＰＵ２０１によって実行される。また、ＲＯＭ２０５やＤＩＳＫ２０８には、制御プログラム以外にも画像処理装置自体や画像処理装置で処理されるジョブ（画像処理）の機能及び状態を示す属性情報や出力の対象となるジョブ・データや、受信して蓄積されたジョブ・データなどが記憶されている。さらに、ＣＰＵ２０１は、ネットワークＩ／Ｆ２０９を介してネットワークで接続された外部との通信を行う。ネットワークＩ／Ｆ２０９は、イーサネット（登録商標）インターフェースだけではなく、ＵＳＢやＩＥＥＥ１３９４又はブルートゥース（登録商標）などの無線通信ネットワークＩ／Ｆであってもよい。さらに、ＣＰＵ２０１は、ＬＣＤ２０３及び入力デバイス２０４を介してユーザにメッセージを表示したり、ユーザからの入力を受け付ける。

本実施形態では、特に断らない限り、ＭＦＰ１００１において、ＣＰＵ２０１がシステムバス２１０を介して入力デバイス２０４からのユーザ入力を受け取り、実施する。また、ＣＰＵ２０１がシステムバス２１０を介して、ＲＡＭ２０２、ＬＣＤ２０３、ＲＯＭ２０５、スキャナエンジン２０６、プリンタエンジン２０７、ＤＩＳＫ２０８及びネットワークＩ／Ｆ２０９を制御し実施する。

ＭＦＰ１００１は、スキャナエンジン２０６を用いて紙文書を読み込みイメージデータを作成するスキャンジョブを実行できる。また、プリンタエンジン２０７を用いて外部から受信したデータを出力するプリントジョブを実行でき、スキャナエンジン２０６とプリンタエンジン２０７とを用いて紙文書の複写を行うコピージョブを実行することができる。

ここで、本実施形態に係るＭＦＰ（画像処理装置）の処理に関する用語について定義する。印刷、スキャン、ＦＡＸ送信、ＦＡＸ受信、文書保存、文書送信などの画像処理を、ジョブと称する。ジョブが実行待ちなのか、実行中なのか、処理完了したのか、中断中なのかを示すジョブの状態の変化を通知する処理を、ジョブの状態変化通知と称する。ジョブの状態変化などを含む画像処理装置内で発生する事象を、イベントと称する。所定のイベントが発生したときに予め登録された通知先にイベント発生及びそのイベント内容を通知することを、イベント通知と称する。イベントが発生したときにイベント通知をさせるように予め登録するための依頼を、イベント通知依頼と称する。

次に、図３を参照して、ＭＦＰ１１００が、ユーザ認証を行いユーザをログインさせたときの処理について説明する。ここで、ユーザ認証は、ユーザが入力したユーザＩＤ（ユーザの識別情報）とパスワードの照合により実行されてもよいし、入力されたＩＣカード内の認証情報との照合により実行されてもよい。なお、ユーザ認証に先立って、ＭＦＰ１１００にはユーザ認証を行う際に照合する認証情報（識別情報）がＲＯＭ２０５又はＤＩＳＫ２０８に登録されている。また、データベースサーバ１００２、又は不図示のＩＣカード内に登録されていてもよい。この場合、ＭＦＰ１１００は、データベース１００２、又はＩＣカードから認証情報を取得する。したがって、ユーザ認証処理では、照合する認証情報をＲＯＭ２０５、ＤＩＳＫ２０８、データベースサーバ１００２又はＩＣカードからＲＡＭ２０２に読み込んで処理する。なお、以下の説明において、Ｓに続く番号は、各フローチャートにおけるステップ番号を示す。また、以下の説明では、一例として、ＭＦＰ１１００を第１画像処理装置として説明し、ＭＦＰ１００１を第２画像処理装置として説明する。

Ｓ３０１では、ＭＦＰ１１００は、ユーザ認証によって得られたユーザのユーザＩＤやユーザ権限などのユーザ情報をＲＯＭ２０５、ＤＩＳＫ２０８、データベースサーバ１００２、又はＩＣカードから取得する。取得したユーザ情報は、一旦ＲＡＭ２０２に記憶される。Ｓ３０２では、ＭＦＰ１１００は、通知依頼を行うイベントを決定する。本実施形態では、通知依頼するイベントとして、ジョブの状態変化通知について説明する。しかしながら、本発明において通知依頼するイベントは、これに限定されない。例えば、ＭＦＰ１００１におけるスキャナエンジン２０６やプリンタエンジン２０７の状態変化を通知するイベントであってもよいし、アプリケーションの状態変化やＭＦＰ１１００の構成情報や設定値が変更されたことを通知するイベントであってもよい。また、通知依頼するイベントの決定は、予め登録された情報をＲＯＭ２０５、ＤＩＳＫ２０８、又はデータベースサーバ１００２から読み込んで決定してもよいし、ＬＣＤ２０３及び入力デバイス２０４を介してユーザに指定させて決定してもよい。また、Ｓ３０２で決定する内容には、イベントの通知条件の指定も含んでよい。決定した内容は、一旦ＲＡＭ２０２に記憶しておく。

Ｓ３０３では、ＭＦＰ１１００は、パケット生成手段として機能し、Ｓ３０２で決定したジョブの状態変化通知依頼を行うためのジョブの状態変化通知依頼パケットの生成を行う。生成するパケットの詳細については、図４を用いて後述する。生成したパケットは、一旦ＲＡＭ２０２に記憶される。Ｓ３０４では、ＭＦＰ１１００は、パケット送信手段として機能し、Ｓ３０３で生成したジョブの状態変化通知依頼パケットをＲＡＭ２０２から読み込み、ネットワークＩ／Ｆ２０９を介してＬＡＮ１０１０内にブロードキャストすることにより、イベントの通知依頼を要求する。Ｓ３０３で生成したパケットは、ブロードキャストされることでＬＡＮ１０１０内の各ノードに送信される。受信側の処理は図５を用いて後述する。

図３に示す処理によって、ログインしたユーザのジョブの状態変化通知依頼を処理可能なＬＡＮ１０１０内のＭＦＰ１００１には、通知依頼したジョブの状態変化が発生したときに通知処理が必要であることが登録される。また、ＬＡＮ１０１０内の他の画像処理装置についてもＭＦＰ１００１と同様の受信処理を行い通知依頼されたジョブの状態変化が発生したときに通知処理が必要であることが登録されることが望ましい。なお、ジョブの状態変化通知依頼を処理できないＬＡＮ１０１０内の装置は、単に通知依頼を無視するだけで何も行わないものとする。

なお、通知依頼が処理される以前にジョブの状態変化が発生していた場合には、通知は行われない。このため、ＭＦＰ１１００は、図３に示したユーザログイン時の処理のほかにログインした時点ですでにログインしたユーザのジョブの状態変化が発生していないか否かを確認する処理を行うことが望ましい。

次に、図４を参照して、ＭＦＰ１１００がＳ３０３で生成して、Ｓ３０４で送信し、ＭＦＰ１００１が受信して当該要求に応答するジョブの状態変化通知依頼パケットの構成について説明する。なお、図４で示すジョブの状態変化通知依頼パケットの構成は一例であって、内容や識別子、格納順、その他の詳細について本発明を実施する上で特に構成は限定しない。

４０１〜４０５は、パケットの基本構造を示す。４１１〜４１８はパラメータ部４０５の詳細を示す。まず、基本構造４０１〜４０５について説明する。ヘッダ部４０１はプロトコル識別子やプロトコルバージョン、リプライ要求フラグ、パケットインデックスなどを含むオペレーションコード４０３に依存しない情報から成る。ＭＦＰ１１００が送信する図４に示すパケットを受信する装置はヘッダ部４０１を見て処理可能なプロトコルであるか否かを判断することができる。

リクエストユーザ部４０２は、図４で示すジョブの状態変化通知依頼パケットを送信した際にＭＦＰ１１００にログインしているユーザのユーザ情報を示す。例えば、ＭＦＰ１１００がＳ３０１で取得してＲＡＭ２０２に記憶したユーザ情報が格納される。ユーザ情報を格納することで、図４に示すパケットを受信する画像処理装置は、どのユーザがログインしている画像処理装置からのジョブの状態変化通知依頼であるかを判断することができる。オペレーションコード部４０３は、プロトコルにおけるオペレーション種別を識別するためのコードを格納する。例えば、ジョブの状態変化通知依頼の場合には、イベント通知依頼であることを示す”Ｓｕｂｓｃｒｉｂｅ Ｅｖｅｎｔ”を格納する。サイズ部４０４は、パラメータ部４０５のサイズを示す。パラメータ部４０５が可変長であるためパラメータ部のサイズを格納しておく。パラメータ部４０５は、オペレーションコード部４０３に対応したパラメータを格納する。オペレーションコード部４０３により格納される情報は変化する。

次に、パラメータ部４０５の詳細について４１１〜４１８を用いて説明する。ＩＰ部４１１は、イベントが発生したときに通知する通知先ＩＰアドレスの指定を示す。Ｐｏｒｔ部４１２は、ＩＰ部４１１で示すノードの受信ポート番号の指定を示す。図４の場合、ＩＰアドレス１７２．２４．１００．１のポート９０５０番への通知依頼であることを示す。Ｍｏｄｅ部４１３は、ＳｕｂｓｃｒｉｂｅＥｖｅｎｔにおける通知依頼モードの指定を示す。”ＢｙＵｓｅｒ“の場合には、ユーザをキーにした通知依頼することを示す。ユーザはＵｓｅｒ部４１４で示す。Ｕｓｅｒ部４１４は、通知依頼のキーとなるユーザの指定を示し、４１４における”Ｔａｒｏ”は、関連するユーザが”Ｔａｒｏ”であるジョブに対してのみ通知依頼を行うことを示す。ＥｖｅｎｔＩＤ部４１５は通知依頼するイベントの指定を示し、”ＪｏｂＳｔａｔｅＣｈａｎｇｅｄ”は、ジョブの状態変化イベントの指定を示す。ＮｏｔｉｆｙＣｏｎｄｉｔｉｏｎＬｉｓｔ部４１６はイベント通知条件の指定を列挙して示す。ＮｏｔｉｆｙＣｏｎｆｉｔｉｏｎＬｉｓｔ部４１６は、ジョブの状態変化について、実際に通知する条件を絞るためのデータであり、４１７ではジョブの状態が”Ｃｏｍｐｌｅｔｅｄ”（完了）に遷移したときに通知する指定を示す。４１８ではジョブの状態が”ＯｐｅｒａｔｏｒＣａｌｌ”（オペレータ呼び出し）に遷移したときに通知する指定を示す。

次に、図５を参照して、ＭＦＰ１００１が、図４に示すようなイベント通知依頼パケットを受信した際の処理について説明する。なお、図５で示す処理は、ＭＦＰ１００１に限らずＬＡＮ１０１０内の他の装置で実施されてもよい。

Ｓ５０１では、ＭＦＰ１００１は、オペレーションコード部４０３を読み出して、オペレーションコードが”ＳｕｂｓｃｒｉｂｅＥｖｅｎｔ”であるか否かを判定する。オペレーションコードが”ＳｕｂｓｃｒｉｂｅＥｖｅｎｔ”であるときにはＳ５０２へと進み、それ以外であるときにはそのほかのオペレーション固有の処理を行うため、Ｓ５２０へと進む。Ｓ５２０では、ＭＦＰ１００１は、オペレーションコードに対応した処理を行ったのち、Ｓ５０７へと進む。

Ｓ５０２では、ＭＦＰ１００１は、Ｍｏｄｅ部４１３の情報を読み出して、通知依頼モードが”ＢｙＵｓｅｒ”であるか否かを判定する。通知依頼モードが”ＢｙＵｓｅｒ”であるときには、Ｓ５０３へと進み、それ以外であるときには、Ｓ５１０へと進む。Ｓ５１０では、ＭＦＰ１００１は、”ＢｙＵｓｅｒ”以外の通知依頼モードに応じた処理を行ってＳ５０７へと進む。

Ｓ５０３では、ＭＦＰ１００１は、Ｕｓｅｒ部４１４から通知依頼の検索キーとなるユーザの指定（例えば、”Ｔａｒｏ”）を読み出す。読み出したユーザ指定は一旦ＲＡＭ２０２に記憶する。続いて、Ｓ５０４では、ＭＦＰ１００１は、通知依頼モードが”ＢｙＵｓｅｒ”であるため、ＭＦＰ１００１が管理しているジョブリストの中に、関連ユーザが”Ｔａｒｏ”であるジョブが存在するかどうかを検索して、Ｓ５０５へと進む。ここで関連ユーザというのは、ジョブ属性として保存されているジョブの実行依頼を行ったユーザのことを示す。例えば、印刷ジョブであればクライアントＰＣからデータ投入を行ったときのクライアントＰＣにログインしていたユーザである。また、コピージョブであればＭＦＰ１００１の入力デバイス２０４からコピー実行ボタンを押下したときのログインユーザが該当する。

Ｓ５０５では、ＭＦＰ１００１は、Ｓ５０４で検索した結果、該当ジョブが見つかったかどうかを判定する。該当ジョブが見つかっていればＳ５０６へと進む。該当ジョブが見つからなければＳ５０７へと進む。Ｓ５０６では、ＭＦＰ１００１は、該当ジョブに対するジョブの状態変化のイベント通知登録を行う。Ｓ５０６で行う処理では、ＭＦＰ１００１が、ＥｖｅｎｔＩＤ部４１５のイベント識別子と共に、イベント通知条件４１７、４１８も併せて通知登録を行う。さらに、イベント通知依頼パケットのＩＰ部４１１の指定とＰｏｒｔ部４１２の指定をイベントの通知先として通知登録する。ここで、イベント通知登録は、ＲＡＭ２０２又はＤＩＳＫ２０８に保存される。イベント通知処理の詳細は、図６を用いて後述する。イベント通知登録を行ったら、Ｓ５０７へと進む。

Ｓ５０７では、ＭＦＰ１００１は、受信したパケットの処理が完了したため、処理結果を送信元にリプライする。ここでの処理結果とは、処理の正常終了や処理の異常終了のことである。ただし、ヘッダ部４０１の返信要求フラグがオフになっているときには、リプライを行わずに処理を終了する。

次に、図６を参照して、ＭＦＰ１００１が、イベントを検知して処理する流れについて説明する。以下で説明する処理では、ＭＦＰ１００１がユーザ”Ｔａｒｏ”のジョブを実行中であり、予め図４で示したイベント通知依頼パケットを受信し、図５で説明したイベント通知登録処理を行っているものとする。

Ｓ６０１では、ＭＦＰ１００１は、イベントを検知するまでイベント有無の判定を繰り返し行う。イベントが発生すると、Ｓ６０２に進む。Ｓ６０２では、ＭＦＰ１００１は、検知したイベントについてイベントの通知登録が行われているか否かを判定する。イベントの通知登録は、予めイベント通知依頼に基づき行われており、ＲＡＭ２０２又はＤＩＳＫ２０８に保存されているため、該当するメモリから読み出して判定される。例えば、ジョブの状態変化イベントを検知した場合には、ＭＦＰ１００１は、予めジョブの状態変化イベントがイベント通知登録されているか否かを判定する。該当するイベント通知登録があれば、Ｓ６０３へと進み、該当するイベント通知登録がなければ処理を終了する。

次に、Ｓ６０３では、ＭＦＰ１００１は、Ｓ６０２で判定したイベント通知登録のエントリについて、通知条件が含まれるか否かを判定する。通知条件が含まれなければＳ６０５へと進み、通知条件が含まれればＳ６０４へと進む。通知条件が含まれる場合、Ｓ６０４では、ＭＦＰ１００１は、イベント通知登録のエントリから通知条件を読み出して、検知しているイベントと比較して通知条件を満たすか否かを判定する。例えば、図４に示すようなイベント通知依頼を受信して処理し、イベント通知登録を行っている場合には、検知したジョブの状態変化イベントのジョブ状態が”Ｃｏｍｐｌｅｔｅｄ”又は”ＯｐｅｒａｔｏｒＣａｌｌ”であるか否かを判定する。登録してあるイベント通知条件の何れかと合致すれば、イベント通知処理を行うため、Ｓ６０５へと進む。一方、合致しなければ、イベント通知は行わないため処理を終了する。

Ｓ６０５では、ＭＦＰ１００１は、検知したイベントをイベント通知登録に基づいてイベント通知するための通知パケットを生成する。生成する通知パケットの詳細は、図７を用いて後述する。続いて、Ｓ６０６では、ＭＦＰ１００１は、Ｓ６０５で生成したイベント通知パケットを、イベント通知登録に基づく通知先のＩＰアドレス及びポート番号へと送信し、処理を終了する。

次に、図７を参照して、ＭＦＰ１００１が図６のＳ６０５で生成してＳ６０６で送信するイベント通知パケットの構成について説明する。リクエストユーザ７０１は、イベント通知依頼を受信したときにＭＦＰ１１００にログインしていたユーザを示す。また、Ｒｅａｄ７１２はジョブの状態変化イベントを通知したジョブについて参照権限があるユーザ及びユーザグループを示す。図７に示す”ｅｖｅｒｙｏｎｅ”は誰でも参照可能であることを示す。Ｅｘｅｃｕｔｅ７１３はジョブの状態変化を通知したジョブについて、ジョブキャンセルやジョブの転送、中断、などのジョブ操作権限があるユーザ及びユーザグループを示す。例えば、Ｅｘｅｃｕｔｅ７１３に設定されている”Ｔａｒｏ”は、ジョブに関連するユーザであるため、ジョブ操作権限が与えられている。同様に”Ａｄｍｉｎ”は、管理者権限のあるユーザであるためジョブ操作権限が与えられている。このように、本実施形態によれば、イベント通知パケットに対して、当該ジョブ（画像処理）に対する操作権限及び参照権限を示すアクセス制限情報が付加される。ＥｖｅｎｔＩＤ７１４は通知したイベントの識別子を示す。ＪｏｂＩＤ７１５はジョブの識別子を示す。ジョブの識別子１００１を指定することで通知されたジョブに関する参照や操作が可能になる。ＪｏｂＳｔａｔｅ７１６はジョブの状態を示す。”ＯｐｅｒａｔｏｒＣａｌｌ”はオペレータ操作が必要なエラー発生であることを示す。Ｒｅａｓｏｎ７１７は、ＪｏｂＳｔａｔｅ７１６に関する要因を示す。”ＭｅｍｏｒｙＦｕｌｌ”はメモリ不足が発生していることを示す。

なお、図７で示したイベント通知パケットの構成は、ジョブの状態変化イベントを通知する場合の一例である。したがって、上述の内容に加えて、他の内容が含まれてもよく、例えばジョブ名を示す文字列やイベント通知を受信して表示する場合の表示文字列などが含まれてもよい。さらに、イベント通知パケットの構成は、通知するイベントによって異なってもよいし、同じイベントを通知する場合でも通知する状態や予め登録されたイベント通知依頼に応じて異なってもよい。

次に、図８を参照して、ＭＦＰ１１００が、図７に示すジョブの状態変化のイベント通知を受信して処理する流れについて説明する。Ｓ８０１では、ＭＦＰ１１００は、受信したイベント通知パケットからＥｖｅｎｔＩＤ７１４を読み出して、通知依頼を行ったジョブの状態変化イベントであるか否かを判定する。ジョブの状態変化イベントであると判定したら、Ｓ８０２へと進み、異なると判定したらＳ８１０へと進む。Ｓ８１０では、ＭＦＰ１１００は、別のＥｖｅｎｔに対応する処理を行い処理を終了する。処理の必要がないイベントであれば、受信したイベント通知の内容は破棄して処理を終了する。

Ｓ８０２では、ＭＦＰ１１００は、現在ＭＦＰ１１００にログインしているユーザのユーザ情報を取得する。ＭＦＰ１１００は、予めユーザをユーザ認証してログインさせている。このため、ユーザ情報は、ＲＡＭ２０２、ＤＩＳＫ２０８又はデータベースサーバ１００２から取得可能となる。

Ｓ８０３では、ＭＦＰ１１００は、参照判定手段として機能し、受信したイベント通知パケットからＲｅａｄ７１２を読み出して参照ユーザの制限があるか否かを判定する。例えば、Ｒｅａｄ部７１２の値が”ｅｖｅｒｙｏｎｅ”である場合には、参照ユーザの制限はないと判定する。参照ユーザの制限があれば、Ｓ８０４へと進み、参照ユーザの制限がなければＳ８０５へ進む。Ｓ８０４では、ＭＦＰ１１００は、参照ユーザの制限があるため、Ｓ８０２で取得した現在ＭＦＰ１１００にログインしているユーザに参照権限があるか否かを判定する。参照権限があれば、Ｓ８０５へと進み、参照権限がなければ処理を終了する。

Ｓ８０５では、ＭＦＰ１１００は、表示制御手段として機能し、受信したイベント通知の概要について、現在ログイン中のユーザは参照可能であるため、イベント通知で受信したジョブの状態をＬＣＤ２０３によって表示する。例えば、図７で示したイベント通知パケットを受信した場合には、ＭＦＰ１１００は、ジョブ識別子７１５のジョブにおいてオペレータ操作を必要とするメモリ不足エラーが発生していることを表示する。ここで、イベント通知内容を詳細に表示する条件として、ＭＦＰ１１００のＬＣＤ２０３及び入力デバイス２０４を介してユーザが操作して選択した場合のみとしてもよい。このように、本実施形態では、イベント通知を受信した場合に、イベント通知があったことのみを表示し、ユーザが操作して選択しない限りイベント通知内容の詳細表示は行わないこととする。

次に、図９を参照して、ＭＦＰ１１００が、図８の処理を行った後にＭＦＰ１１００のＬＣＤ２０３及び入力デバイス２０４を介したユーザの操作に従ってイベント通知内容の詳細表示を行ったり、ジョブ操作を行う処理について説明する。Ｓ９０１では、ＭＦＰ１１００は、図７で示す通知パケットのＥｘｅｃｕｔｅ部７１３を参照し、当該ジョブについて操作権限の制限があるか否かを判定する。例えば、Ｅｘｅｃｕｔｅ部７１３に示す”Ｔａｒｏ、Ａｄｍｉｎ”の値である場合は、操作権限の制限があることを示す。操作権限の制限がなければＳ９０３へと進み、操作権限の制限があればＳ９０２へと進む。

Ｓ９０２では、ＭＦＰ１１００は、操作判定手段として機能し、ログインユーザに操作権限があるか否かを判定する。操作権限があるか否かは、Ｓ８０２で取得したログインユーザ情報とＥｘｅｃｕｔｅ部７１３の情報とを比較して判定する。例えば、ログインユーザ情報からユーザ名が”Ｔａｒｏ”でＥｘｅｃｕｔｅ部７１３が”Ｔａｒｏ、Ａｄｍｉｎ”であるときには、ログインユーザに操作権限があると判定する。ログインユーザに操作権限があると判定した場合はＳ９０３へと進み、操作権限がないと判定した場合にはＳ９１０へと進む。

Ｓ９１０では、ＭＦＰ１１００は、ログインユーザがジョブ操作を行うことができないため、図７に示したジョブの状態変化のイベント通知によって通知された内容に基づき、ＬＣＤ２０３にイベントの詳細内容を示す表示画面を表示して処理を終了する。表示する内容は、ジョブがオペレータコールで停止していることを示すメッセージやジョブＩＤなどである。一方、Ｓ９０３では、ＭＦＰ１１００は、ログインユーザがジョブ操作を行うことができるため、ＬＣＤ２０３を介してユーザにジョブ操作を選択させるための操作画面を表示する。操作画面に表示する内容は、Ｓ９１０で表示する内容とは少なくともジョブキャンセルやエラースキップなどジョブ操作を選択可能なボタンを表示する点で異なる。また、操作画面に表示する内容には、イベント通知の内容に基づいてＭＦＰ１００１に情報取得を行った結果を表示してもよい。また、操作をしないことを選択するボタンを表示してもよい。

Ｓ９０４では、ＭＦＰ１１００は、受付手段として機能し、操作画面に表示した内容に対して入力デバイス２０４を介したユーザの指示を受け付ける。ユーザの指示を受け付けると、Ｓ９０５において、ＭＦＰ１１００は、ユーザ入力に基づいてジョブの操作依頼をＭＦＰ１００１に送信する。その後、ＭＦＰ１１００は、ＭＦＰ１００１から送信されるジョブの操作依頼結果を受信して結果をＬＣＤ２０３を介してユーザに表示する。例えば、ジョブキャンセル依頼を送信した場合には、実際にジョブキャンセルが実行できたかどうかがリプライされるため、リプライを受信して、ジョブキャンセル処理の結果を表示して処理を終了する。

次に、図１０を参照して、ＭＦＰ１１１０が、ＭＦＰ１００１で実行中のジョブがオペレータコールなどによって停止している場合に図９のＳ９０３においてジョブの代行先のＭＦＰを検索して表示可能にする処理について説明する。ここで、ジョブの代行とはＭＦＰ１００１で実行中のジョブが停止している場合に、停止している当該ジョブを他のＭＦＰ、例えばＭＦＰ１１００で再実行することを示す。ジョブの代行は、停止中の元ジョブの内容をすべて破棄して最初から実行してもよいし、停止中の元ジョブの続きから実行してもよい。なお、ジョブの代行先とは、ジョブの代行を行う場合に、後からジョブを投入される側のＭＦＰのことを示す。

Ｓ１００１では、ＭＦＰ１１００は、ＬＣＤ２０３及び入力デバイス２０４を介して、ジョブの代行先であるＭＦＰの検索を行うか否かをユーザに選択させる。ＭＦＰの検索を行うことが選択された場合には、Ｓ１００２へと進み、ＭＦＰの検索を行わないことが選択された場合には、処理を終了する。

Ｓ１００２では、ＭＦＰ１１００は、ジョブの代行先であるＭＦＰとして適切な条件を知るためにイベント通知されたジョブの属性取得依頼をＭＦＰ１００１に対して送信し、ジョブの属性情報を取得する。ここでジョブの属性情報とは、例えばコピージョブの場合、カラーモード、読み取り解像度、ステープル処理設定の有無、メディア指定などのジョブの処理内容を示す。ジョブの代行先であるＭＦＰを判断するために取得するジョブ属性がどんなものであるかは、予めジョブ種別毎に登録されており、ＲＯＭ２０５又はＤＩＳＫ２０８に保存されているものとする。例えば、印刷ジョブについては、使用するメディア指定やカラーモード、さらには印刷のカラーモードなどを知るためにこれらのジョブ属性を取得する。また、コピージョブについては、原稿スキャンによるＡＣＳ（Ａｕｔｏ Ｃｏｌｏｒ Ｓｅｌｅｃｔ）の結果で決定するカラーモードや読み取り解像度などを知るためにこれらのジョブ属性を取得する。取得したジョブ属性は、一旦ＲＡＭ２０２に記憶する。属性の詳細については、図１１を用いて後述する。

Ｓ１００３では、ＭＦＰ１１００は、Ｓ１００２で取得したジョブ属性に基づいて適合するＭＦＰを検索する。なお、検索のためにＬＡＮ１０１０内のＭＦＰの画像処理能力を示す能力情報を予め取得する。例えば、コピージョブの場合には、カラースキャン可能であるか、読み取り可能解像度、ステープル可能か、設定されている出力用紙サイズなどの情報を取得する。取得したＬＡＮ１０１０内のＭＦＰの能力情報は一旦ＲＡＭ２０２に記憶してＳ１００４へと進む。

Ｓ１００４では、ＭＦＰ１１００は、Ｓ１００２で取得したジョブ属性と、Ｓ１００３で取得したＭＦＰの能力情報とから、代行するジョブを処理可能なＭＦＰを判断する。具体的には、Ｓ１００３で取得したＭＦＰの能力情報がＳ１００２で取得したジョブの属性を満たすかどうかを判断する。ジョブの属性を満たすと判断したＭＦＰは、実行中のジョブの設定を変更することなくジョブの代行が可能なＭＦＰであることになる。ただし、必ずしもジョブの属性を全て満たす必要はなく、代行するジョブを実行可能であるか否かは、特定の属性のみで判断して代行可能と判断してもよい。例えば、コピージョブでは、カラーモードの能力のみが必須として判断してもよい。この場合、他のジョブ属性については、代行可能なＭＦＰの能力に合わせて、適宜変更されてもよい。

その後、Ｓ１００５では、ＭＦＰ１１００は、Ｓ１００４でジョブ属性を満たすと判断したＭＦＰをジョブの代行先候補としてＬＣＤ２０３を介してユーザにリスト表示し、処理を終了する。このように、ジョブ属性と各ＭＦＰの能力情報とに基づいたジョブの代行先候補を表示することにより、ユーザは、ＭＦＰ１００１で実行中のジョブを他のＭＦＰで実行する場合にどのＭＦＰが適切であるか否かを容易に判断することできる。

次に、図１１を参照して、図１０で示した処理で取得、参照するジョブ属性及びＭＦＰの能力情報について説明する。１１１０は、参照するジョブ属性及びＭＦＰの能力情報の概念的な構成を示す。なお、ここでは実行中のジョブはコピージョブであるとして説明する。

実行中のジョブ属性１１１１は、ＭＦＰ１００１で実行中のジョブの属性を示し、Ｓ１００２で取得するジョブ属性の情報を示す。実行中のジョブ属性１１１１では、ＡＣＳによるカラーモードがカラー、読み取り解像度が１２００ＤＰＩ、ステープル指定があり、出力用紙サイズがＡ３となっている。一方、１１１２及び１１１３は、それぞれＭＦＰ１１００、ＭＦＰ１０４０の能力情報を示し、Ｓ１００３で取得する能力情報を示す。能力情報１１１２は、ＭＦＰ１１００において、カラースキャン可能であり、読み取り解像度が１２００ＤＰＩ、ステープル指定が可能、メディアにＡ３がないことを示す。また、能力情報１１１３は、ＭＦＰ１０４０において、モノクロスキャンが可能であり、読み取り解像度が１２００ＤＰＩ、ステープル指定が不可能、メディアにＡ３があることを示す。

１１１０に示すようなジョブ属性及び各ＭＦＰの能力情報とから、Ｓ１００４で示すようなＭＦＰ１００１で実行中のジョブを代行可能かどうかを判断することが可能になる。さらに、Ｓ１００４で１１１０に示すようなＭＦＰの能力情報をＬＣＤ２０３を介してユーザに参照させることにより、ジョブの代行先としてどのＭＦＰが適切であるかの判断材料をユーザに示すことが可能になる。

以上説明したように、本実施形態によれば、第１画像処理装置と第２画像処理装置とが通信可能に接続された画像処理システムとして実現される。第１画像処理装置は、ユーザがログインした場合に所定のイベントの発生を通知するよう第２画像処理装置に要求し、第２画像処理装置から所定のイベントが発生したことが通知された場合に、所定のイベントが発生したジョブに対する指示をログインしているユーザから受け付けて、受け付けた指示を第２画像処理装置に送信する。これにより、第１画像処理装置は、第２画像処理装置にて実行中のジョブに関する状態変化通知を、受信して処理することができる。さらに、第１画像処理装置は、ジョブの状態変化通知に含まれるアクセス制限情報と、ログインしているユーザ情報とから判断して、適切な表示及びユーザ操作のみをさせることが可能となる。つまり、本実施形態に係る画像処理システムによれば、他の画像処理装置で実行されているジョブに関する所定のイベントを受信すると、イベントを受信した画像処理装置においてその後の処理を好適に制御することができる。

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

Claims (8)

1. 第１画像処理装置と第２画像処理装置とが通信可能に接続された画像処理システムであって、
   前記第１画像処理装置は、
   ユーザ認証を行い、該ユーザ認証されたユーザを前記第１画像処理装置にログインさせる認証手段と、
   前記認証手段による認証により前記第１画像処理装置にログインしたユーザが前記第２画像処理装置にログインしている場合に、前記第２画像処理装置にて実行されるジョブに所定のイベントが発生したことを通知するよう前記第２画像処理装置に要求する要求手段と、
   前記要求手段による要求に応答して前記第２画像処理装置から前記所定のイベントの発生が通知された場合に、前記所定のイベントが発生したジョブに対する指示を前記ログインしているユーザから受け付ける受付手段と、
   前記受付手段により前記指示が受け付けられた場合に、前記指示を前記第２画像処理装置に送信する送信手段と、
   を備え、
   前記第２画像処理装置は、
   前記要求手段による要求を受信する受信手段と、
   前記受信手段により前記要求が受信された場合であって、前記第２画像処理装置にて実行されるジョブに前記所定のイベントが発生した場合に、前記所定のイベントの発生を前記第１画像処理装置に通知するイベント通知手段と、
   前記送信手段により送信された前記指示に基づいて前記所定のイベントが発生したジョブを制御する制御手段と、
   を備えることを特徴とする画像処理システム。
2. 前記第２画像処理装置は、
   前記要求手段による要求に含まれる前記ユーザを識別するための識別情報に基づいて、前記１画像処理装置にログインしたユーザが前記第２画像処理装置にて実行されるジョブの操作権限を有するか否かを判断する判断手段を有し、
   前記イベント通知手段は、前記判断手段により前記１画像処理装置にログインしたユーザが前記第２画像処理装置にて実行されるジョブの操作権限を有すると判断された場合に、前記操作権限を示すアクセス制限情報とともに前記所定のイベントの発生を通知することを特徴とする請求項１に記載の画像処理システム。
3. 前記第１画像処理装置は、
   前記操作権限を示すアクセス制限情報が前記第２画像処理装置から通知された場合に、前記所定のイベントが発生したジョブの操作を行うための操作画面を表示する表示制御手段を有することを特徴とする請求項２に記載の画像処理システム。
4. 前記要求手段は、
   前記認証手段によって前記第１画像処理装置にログインしたユーザを示すユーザ情報と、前記所定のイベントの通知先とを少なくとも含むパケットを生成するパケット生成手段と、
   前記要求として、前記パケット生成手段により生成された前記パケットを前記第２画像処理装置に送信するパケット送信手段と
   を備えることを特徴とする請求項１乃至３の何れか１項に記載の画像処理システム。
5. 前記パケット生成手段は、前記所定のイベントが発生した場合の通知条件を前記パケットに設定し、
   前記イベント通知手段は、前記所定のイベントが発生した場合であって、かつ、前記通知条件を満たす場合に前記所定のイベントの発生を通知することを特徴とする請求項４に記載の画像処理システム。
6. 前記第１画像処理装置は、
   前記イベント通知手段により通知された前記所定のイベントが前記第２画像処理装置にて実行されるジョブの中断を示す場合に、該ジョブの処理内容を示す属性情報を前記第２画像処理装置から取得する手段と、
   ネットワークを介して接続された複数の画像処理装置の画像処理能力を示す能力情報を取得する手段と、
   前記属性情報及び前記能力情報とから、前記複数の画像処理装置において前記第２画像処理装置にて中断されたジョブを処理可能であるか否かを決定する手段と、
   前記中断されたジョブを処理可能であると決定された画像処理装置を選択可能に表示する手段と
   をさらに備えることを特徴とする請求項１乃至５の何れか１項に記載の画像処理システム。
7. 第１画像処理装置と第２画像処理装置とが通信可能に接続された画像処理システムの制御方法であって、
   前記第１画像処理装置が、
   認証手段が、ユーザ認証を行い、該ユーザ認証されたユーザを前記第１画像処理装置にログインさせる認証ステップと、
   要求手段が、前記認証ステップによる認証により前記第１画像処理装置にログインしたユーザが前記第２画像処理装置にログインしている場合に、前記第２画像処理装置にて実行されるジョブに所定のイベントが発生したことを通知するよう前記第２画像処理装置に要求する要求ステップと、
   受付手段が、前記要求ステップによる要求に応答して前記第２画像処理装置から前記所定のイベントの発生が通知された場合に、前記所定のイベントが発生したジョブに対する指示を前記ログインしているユーザから受け付ける受付ステップと、
   送信手段が、前記受付ステップにて前記指示が受け付けられた場合に、前記指示を前記第２画像処理装置に送信する送信ステップと、
   を実行し、
   前記第２画像処理装置が、
   受信手段が、前記要求ステップによる要求を受信する受信ステップと、
   通知手段が、前記受信ステップにて前記要求が受信された場合であって、前記第２画像処理装置にて実行されるジョブに前記所定のイベントが発生した場合に、前記所定のイベントの発生を前記第１画像処理装置に通知するイベント通知ステップと、
   制御手段が、前記送信ステップにて送信された前記指示に基づいて前記所定のイベントが発生したジョブを制御する制御ステップと、
   を実行することを特徴とする画像処理システムの制御方法。
8. 請求項７に記載の画像処理システムの制御方法をコンピュータに実行させるためのプログラム。

Images