(57)【要約】【課題】画像処理装置と通信する情報処理装置個々に適切なエラー報知を行うことが期待できるエラー報知技術を提供すること。【解決手段】ＰＣ１０に記憶されているステータスモニタ４１は，監視対象の画像処理装置２０，２１，２２の状態情報を取得する。そして，監視対象の画像処理装置２０，２１，２２を利用するジョブの実行要求を受け付けた後，その実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，監視対象の画像処理装置２０，２１，２２から取得した状態情報に基づくエラー情報を報知する。【選択図】            図４
2014197304.tif 000002
【特許請求の範囲】
【請求項１】
画像処理を行う画像処理装置と通信する情報処理装置に，
前記画像処理装置の状態に関する情報である状態情報を取得する取得処理と，
前記画像処理装置に対して画像処理を行わせるジョブの実行要求を受け付ける受付処理と，
前記受付処理にて前記実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，前記取得処理にて取得した前記状態情報に基づくエラー情報を報知する報知処理と，
を実行させることを特徴とするプログラム。
【請求項２】
請求項１に記載するプログラムにおいて，
前記報知処理では，少なくとも前記実行要求を受け付けてから，前記実行要求に対応するデータの送信あるいは受信が完了したことを示す完了通知を受け付けるまでの期間である期間Ａを，前記報知期間とすることを特徴とするプログラム。
【請求項３】
請求項２に記載するプログラムにおいて，
前記報知処理では，前記期間Ａに加え，さらに前記完了通知を受け付けてから所定時間が経過するまでの期間である期間Ｂまでの期間を，前記報知期間とすることを特徴とするプログラム。
【請求項４】
請求項１に記載するプログラムにおいて，
前記報知処理では，前記報知期間を，前記実行要求に対応するジョブの属性に基づいて決定することを特徴とするプログラム。
【請求項５】
請求項１から請求項４のいずれか１つに記載するプログラムにおいて，
前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求に対応するジョブで実行させる画像処理に関連しないエラー情報を，報知対象から除外することを特徴とするプログラム。
【請求項６】
請求項１から請求項４のいずれか１つに記載するプログラムにおいて，
前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求に対応するジョブで実行させる画像処理に関連しないエラー情報を，前記実行要求に対応するジョブで実行させる画像処理に関連するエラー情報と比較して報知度合いを弱めて報知することを特徴とするプログラム。
【請求項７】
請求項１から請求項６のいずれか１つに記載するプログラムにおいて，
前記取得処理では，前記情報処理装置と通信する複数の画像処理装置の状態情報を取得し，
前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求の通知先となる画像処理装置以外の画像処理装置のエラー情報を，報知対象から除外することを特徴とするプログラム。
【請求項８】
請求項１から請求項６のいずれか１つに記載するプログラムにおいて，
前記取得処理では，前記情報処理装置と通信する複数の画像処理装置の状態情報を取得し，
前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求の通知先となる画像処理装置以外の画像処理装置のエラー情報を，前記実行要求の通知先となる画像処理装置と比較して報知度合いを弱めて報知することを特徴とするプログラム。
【請求項９】
請求項１から請求項７のいずれか１つに記載するプログラムにおいて，
前記報知処理では，前記情報処理装置と前記画像処理装置とが一対一で接続されている場合に，前記報知期間中に前記取得処理が取得したすべての状態情報に基づくエラー情報を報知対象とすることを特徴とするプログラム。
【請求項１０】
画像処理を行う画像処理装置と通信する通信部と，
制御部と，
を備え，
前記制御部は，
前記画像処理装置の状態に関する情報である状態情報を取得する取得処理と，
前記画像処理装置に対して画像処理を行わせるジョブの実行要求を受け付ける受付処理と，
前記受付処理にて前記実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，前記取得処理にて取得した前記状態情報に基づくエラー情報を報知する報知処理と，
を実行することを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は，プログラムおよび情報処理装置に関する。さらに詳細には，エラーの内容やその対処方法等のエラー情報を報知するエラー報知技術に関するものである。
【背景技術】
【０００２】
プリントやスキャン等の画像処理動作を行う画像処理装置では，紙詰まり，用紙切れ，着色剤不足等，画像処理動作を継続できない各種のエラーが発生する。エラーの発生時の対処方法としては，例えば画像処理装置を利用する情報処理装置に，エラー情報を報知する技術が知られている。
【０００３】
例えば，特許文献１には，エラー情報を報知する技術として，１台のデジタル複合機に少なくとも１台のホストＰＣが接続されている画像形成システムであって，デジタル複合機にエラーが発生した場合，そのエラーを回復させるための情報をデジタル複合機からホストＰＣに送信する技術が開示されている。特許文献１のデジタル複合機は，送信先のホストＰＣとのインターフェースを特定し，そのインターフェースに応じて適切なマニュアルを送信している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１０−１５７９２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら，前記した従来の技術には，次のような問題があった。すなわち，エラー情報を受け取った情報処理装置にとって，そのエラー情報が不要な場合がある。例えば，プリントジョブを投入していないユーザにとっては，着色剤不足や用紙ジャム等のプリント機能に関するエラー情報は利用価値が低い。このような場合には，エラーの報知が反ってユーザに困惑を招く可能性があることから，改善の余地がある。
【０００６】
本発明は，前記した従来の技術が有する問題点を解決するためになされたものである。すなわちその課題とするところは，画像処理装置と通信する情報処理装置個々に適切なエラー報知を行うことが期待できるエラー報知技術を提供することにある。
【課題を解決するための手段】
【０００７】
この課題の解決を目的としてなされたプログラムは，画像処理を行う画像処理装置と通信する情報処理装置に，前記画像処理装置の状態に関する情報である状態情報を取得する取得処理と，前記画像処理装置に対して画像処理を行わせるジョブの実行要求を受け付ける受付処理と，前記受付処理にて前記実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，前記取得処理にて取得した前記状態情報に基づくエラー情報を報知する報知処理とを実行させることを特徴としている。
【０００８】
本明細書に開示されるプログラムは，情報処理装置に，画像処理装置の状態情報を取得させる。状態情報の取得方法は，画像処理装置に直接問い合わせてもよいし，ステータスモニタ等の画像処理装置の状態を監視する他の手段に問い合わせてもよい。そして，監視対象の画像処理装置に対するジョブの実行要求を受け付けた後，その実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，監視対象の画像処理装置から取得した状態情報に基づくエラー情報を，情報処理装置に報知させる。状態情報は，報知期間中のみで取得してもよいし，それ以外の期間においても定期的あるいは適宜に取得してもよい。また，所定時間は，固定値であっても可変値であってもよい。
【０００９】
すなわち，画像処理装置に画像処理を実行させるジョブの実行要求を受け付けてから所定時間内に当該画像処理装置に発生しているエラーは，情報処理装置が要求したジョブに関するエラーである可能性が高い。一方で，所定時間外に画像処理装置に生じているエラーは情報処理装置が関与しないエラーである可能性が高い。そのため，本明細書に開示されるプログラムは，画像処理装置に画像処理を実行させるジョブの実行要求を受け付けてから所定時間が経過するまでを報知期間とし，情報処理装置に，その報知期間内であれば，画像処理装置から取得した状態情報に基づくエラー情報を報知させることで，利用価値が高いエラー報知が期待できる。
【００１０】
また，前記報知処理では，少なくとも前記実行要求を受け付けてから，前記実行要求に対応するデータの送信あるいは受信が完了したことを示す完了通知を受け付けるまでの期間である期間Ａを，前記報知期間とするとよい。少なくとも期間Ａでは，情報処理装置から送信されたジョブを画像処理装置が処理している可能性が高い。そのため，期間Ａではエラー情報を報知する方が好ましい。
【００１１】
また，前記報知処理では，前記期間Ａに加え，さらに前記完了通知を受け付けてから所定時間が経過するまでの期間である期間Ｂまでの期間を，前記報知期間とするとよい。上述の期間Ａが過ぎた後であっても，画像処理装置側でジョブが完了していない可能性がある。そのため，期間Ａが過ぎた後であっても，期間Ｂとして報知期間を多少延長する方が好ましい。
【００１２】
また，前記報知処理では，前記報知期間を，前記実行要求に対応するジョブの属性に基づいて決定するとよい。属性には，部数，両面設定，カラー設定，集約設定等のドライバの設定や，サイズ，ページ総数等のジョブの情報が該当する。画像処理にかかる時間はジョブの属性によって異なる。そのため，ジョブの属性に応じて報知期間を可変にする方が好ましい。
【００１３】
また，前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求に対応するジョブで実行させる画像処理に関連しないエラー情報を，報知対象から除外するとよい。画像処理に関連しないエラー情報を報知しても利用価値が低い。そのため，画像処理装置に実行させた画像処理に関連しないエラー情報は報知しない方が好ましい。
【００１４】
あるいは，前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求に対応するジョブで実行させる画像処理に関連しないエラー情報を，前記実行要求に対応するジョブで実行させる画像処理に関連するエラー情報と比較して報知度合いを弱めて報知するとよい。報知度合いの強弱としては，例えば，ポップアップ表示の有無，点滅表示の有無，警告音の有無，メッセージボックスの大小が該当する。画像処理に関連しないエラー情報を報知しても利用価値が低い。そのため，画像処理装置に実行させた画像処理に関連しないエラー情報は弱めに報知する方が好ましい。
【００１５】
また，前記取得処理では，前記情報処理装置と通信する複数の画像処理装置の状態情報を取得し，前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求の通知先となる画像処理装置以外の画像処理装置のエラー情報を，報知対象から除外するとよい。ジョブを投入していない画像処理装置のエラー情報を報知しても利用価値が低い。そのため，そのような画像処理装置のエラー情報は報知しない方が好ましい。
【００１６】
あるいは，前記取得処理では，前記情報処理装置と通信する複数の画像処理装置の状態情報を取得し，前記報知処理では，前記報知期間内に取得した前記状態情報に基づくエラー情報のうち，前記実行要求の通知先となる画像処理装置以外の画像処理装置のエラー情報を，前記実行要求の通知先となる画像処理装置と比較して報知度合いを弱めて報知するとよい。ジョブを投入していない画像処理装置のエラー情報を報知しても利用価値が低い。そのため，そのような画像処理装置のエラー情報は弱めに報知する方が好ましい。
【００１７】
また，前記報知処理では，前記情報処理装置と前記画像処理装置とが一対一で接続されている場合に，前記報知期間中に前記取得処理が取得したすべての状態情報に基づくエラー情報を報知対象とするとよい。一対一で接続されている画像処理装置については，当該装置に発生しているエラーが情報処理装置が投入したジョブに関連する可能性が高い。そのため，そのような画像処理装置のエラー情報は報知する方が好ましい。
【００１８】
また，本明細書には，画像処理を行う画像処理装置と通信する通信部と，制御部とを備え，前記制御部は，前記画像処理装置の状態に関する情報である状態情報を取得する取得処理と，前記画像処理装置に対して画像処理を行わせるジョブの実行要求を受け付ける受付処理と，前記受付処理にて前記実行要求を受け付けてから所定時間が経過するまでの期間である報知期間内に，前記取得処理にて取得した前記状態情報に基づくエラー情報を報知する報知処理とを実行することを特徴とする情報処理装置が開示されている。
【発明の効果】
【００１９】
本発明によれば，画像処理装置と通信する情報処理装置個々に適切なエラー報知を行うことが期待できるエラー報知技術が実現される。
【図面の簡単な説明】
【００２０】
【図１】実施の形態に係る画像処理システムの構成を示すブロック図である。
【図２】実施の形態に係る画像処理システムの印刷手順を示すブロック図である。
【図３】実施の形態に係る画像処理システムのＭＦＰのエラー報知の手順を示すシーケンス図である。
【図４】実施の形態に係るステータスモニタの管理処理の手順を示すフローチャートである。
【図５】実施の形態に係るステータスモニタの報知許可設定処理（第１の形態）の手順を示すフローチャートである。
【図６】実施の形態に係るステータスモニタの報知許可設定処理（第２の形態）の手順を示すフローチャートである。
【図７】実施の形態に係るステータスモニタの報知処理の手順を示すフローチャートである。
【発明を実施するための形態】
【００２１】
以下，本発明にかかる装置を具体化した実施の形態について，添付図面を参照しつつ詳細に説明する。本形態は，複合機（ＭＦＰ）と，そのＭＦＰ用のデバイスドライバが組み込まれたパーソナルコンピュータ（ＰＣ）とを有する画像処理システムに本発明を適用したものである。
【００２２】
［画像処理システムの構成］
本形態の画像処理システム１００は，図１に示すように，ＭＦＰ２０（印刷装置の一例），２１，２２と，これらＭＦＰを制御するＰＣ１０（情報処理装置の一例）とを備えている。画像処理システム１００では，ＰＣ１０とＭＦＰ２０，２１とが有線ＬＡＮケーブルを介して通信可能に接続され，ＰＣ１０とＭＦＰ２２とがＵＳＢケーブルを介して通信可能に接続されている。
【００２３】
なお，画像処理システム１００を構成する画像処理装置および情報処理装置は図示されたものに限るものではない。また，ＰＣ１０とＭＦＰ２０等との接続は，有線ＬＡＮケーブルやＵＳＢケーブルに限らず，その他のシリアル通信ケーブル，パラレル通信ケーブル，さらには無線ＬＡＮ等の無線通信であってもよい。
【００２４】
ＰＣ１０は，各種処理を実行するＣＰＵ１１（制御部の一例）と，当該ＰＣ１０の起動時にＣＰＵ１１が行う起動処理のプログラム（ＢＩＯＳ）等を記憶したＲＯＭ１２と，ＣＰＵ１１が各種処理を行う際に一時的な記憶領域として利用されるＲＡＭ１３と，各種のプログラムやデータを記憶したハードディスクドライブ（ＨＤＤ）１４とを有するコントローラ３０（制御部の一例）を備えている。
【００２５】
また，ＰＣ１０は，キーボードやマウス等からなる操作部１５と，液晶ディスプレイ等からなる表示部１６と，ＵＳＢインターフェース１７（通信部の一例）と，ネットワークインターフェース１８（通信部の一例）とを有し，これらがコントローラ３０と電気的に接続され，これらがコントローラ３０によって制御される。
【００２６】
ＰＣ１０には，オペレーティングシステム（ＯＳ）と，アプリケーションプログラム（文書作成ソフト，作図ソフト，表計算ソフト，写真データ編集ソフト等）と，ＭＦＰ２０，２１，２２を制御するデバイスドライバと，各ＭＦＰ２０の状態を監視するステータスモニタ（プログラムの一例）が記憶されている。なお，各種プログラムは，ＣＤ−ＲＯＭなどの記憶媒体に記憶されているものをインストールしてもよいし，ネットワーク上のサーバに記憶されているものをダウンロードしてインストールしてもよい。
【００２７】
ＭＦＰ２０は，用紙に画像を形成する機能を有していればよく，その画像形成方式は，電子写真方式，インクジェット方式，その他の一般的な画像形成方式を採用していればよい。また，カラー画像及びモノクロ画像の画像形成が可能であっても，モノクロ画像のみの画像形成が可能であってもよい。この他，ＭＦＰ２０は，画像読み取り機能，ＦＡＸ送信機能，ＦＡＸ受信機能を有している。ＭＦＰ２１，２２についてもＭＦＰ２０と同様である。
【００２８】
［ＰＣの動作］
続いて，本形態の画像処理システム１００において，ＭＦＰ２０に印刷を行わせる際の，ＰＣ１０の動作について，図２のブロック図を参照しつつ説明する。なお，図２中，グラフィックエンジン５１，スプーラ５２は，ＯＳの一部として提供される。
【００２９】
図２中，デバイスドライバ４０は，ＭＦＰ２０用のプリンタドライバであって，印刷対象となる画像データの加工処理や，加工処理が反映された画像データに基づく印刷データの生成処理を行う。加工処理としては，例えば，ウォータマーク，ヘッダー，フッター等の合成，拡大，縮小等の倍率変更，画像回転，２ｉｎ１，４ｉｎ１等の集約が該当する。
【００３０】
また，ステータスモニタ４１は，ＰＣ１０と通信可能に接続する全てのＭＦＰ（本形態ではＭＦＰ２０，２１，２２）の状態情報を定期的に取得し，取得した状態情報をユーザに閲覧可能に表示する。具体的に，ステータスモニタ４１は，稼働状況（実行中，待機状態，スリープ状態等）や，ＭＦＰにエラーが発生している場合にはそのエラーの種類を，状態情報として取得する。本形態では，ステータスモニタ４１がデバイスメーカーから提供されるが，ＯＳの一部として提供されてもよい。ステータスモニタ４１の動作手順については後述する。
【００３１】
グラフィックエンジン５１は，デバイスドライバ４０の制御を行うモジュールである。グラフィックエンジン５１は，アプリケーションプログラム６１からの命令を受け付け，その命令をデバイスドライバ４０に受け渡す。
【００３２】
スプーラ５２は，デバイスドライバ４０によって生成された印刷データを一時的に格納し，印刷データを順次に指定されたＭＦＰに出力する機能を有するモジュールである。本明細書において「デバイスドライバ４０が印刷データをＭＦＰ２０に送信する」と記載した場合，それは「デバイスドライバ４０が印刷データをスプーラ５２に格納する」ことを意味し，実際にスプーラ５２によってＭＦＰ２０に印刷データが送信されたことまでは意味しない。
【００３３】
ＰＣ１０からＭＦＰ２０に印刷を行わせる際には，図２に示すように，先ず，ＰＣ１０に組み込まれているアプリケーションプログラム６１がユーザからの印刷指示を受け付け，印刷開始通知を出力する。そして，ＯＳの一部であるグラフィックエンジン５１がその印刷開始通知を受け付け，アプリケーションプログラム６１から印刷対象の画像データの取得を開始する。
【００３４】
グラフィックエンジン５１は，画像データの取得を開始すると，デバイスドライバ４０に対して描画命令を行う。デバイスドライバ４０は，描画命令を受け付けると，当該描画命令に基づいてビットマップ画像（ＢＭＰ画像）を生成し，さらにそのＢＭＰ画像に基づいてＰＤＬ形式の印刷データを生成する。
【００３５】
デバイスドライバ４０は，印刷データの生成後，当該印刷データをスプーラ５２に格納する。印刷データがスプーラ５２に格納されると，スプーラ５２は格納されている印刷データをＭＦＰ２０に送信する。印刷データを受信したＭＦＰ２０は，その印刷データに基づいて印刷を行う。
【００３６】
続いて，本形態の画像処理システム１００において，ＭＦＰ２０のエラー情報をステータスモニタ４１で報知する際の，ＰＣ１０の動作について，図３のシーケンス図を参照しつつ説明する。なお，図３中，ステータスモニタ４１については，ＭＦＰ２０の状態を監視する管理部４１Ａと，ＭＦＰ２０のエラー情報を報知する報知部４１Ｂとに分けて説明する。なお，管理部４１Ａと報知部４１Ｂとは，別モジュールであってもよいし，同一モジュールであってもよい。
【００３７】
本形態の画像処理システム１００にてＭＦＰ２０のエラー情報をＰＣ１０で報知する際には，先ず，ステータスモニタ４１の管理部４１Ａの起動時に，管理部４１ＡがＯＳ５０から監視対象のデバイスドライバの情報であるドライバ情報を取得する。ドライバ情報は，レジストリ等のＯＳ５０が保有する設定保存領域に記憶される。ドライバ情報には，例えば，ドライバの種類や，接続インターフェースの種類が含まれる。ドライバ情報は，例えば，インストール時のインストーラによって，あるいはデバイスドライバの起動時にデバイスドライバ自身によって，設定保存領域に記憶される。
【００３８】
さらにステータスモニタ４１の管理部４１Ａは，プリンタドライバがあった場合，ＯＳ５０に対して，監視対象のプリンタドライバを使用するジョブが登録された際にジョブの登録があったことを通知するように設定する。以下，この通知を「ジョブ登録通知」とする。エラー報知は，デバイスドライバごとに行われるため，通知設定はプリンタドライバごとに行われる。例えば，ＰＣ１０に，ＭＦＰ２０用のプリンタドライバが組み込まれている場合には，ＭＦＰ２０用のプリンタドライバを使用するジョブが登録された場合に通知するように設定する。ＯＳ５０は，通知設定がなされると，スプーラ５２に印刷ジョブが格納された際にジョブ登録通知を出力する。
【００３９】
なお，スキャナドライバの場合には，スキャナドライバが読み取りデータを記憶する記憶領域を確保し，さらに読み取り状況を当該記憶領域に記憶する。ステータスモニタ４１の管理部４１Ａは，スキャナドライバの記憶領域から読み取り状況を取得し，スキャンジョブの開始および終了を検知する。なお，スキャンジョブが投入された際，スキャナドライバからステータスモニタ４１の管理部４１Ａに対してジョブ登録通知を出力する構成であってもよい。スキャンジョブであった場合の動作については説明を省略する。
【００４０】
ステータスモニタ４１の管理部４１ＡがＯＳ５０に対して通知設定を行った後，ステータスモニタ４１の監視対象となる全てのデバイスに対して，定期的な状態の問合せを開始する。すなわち，管理部４１Ａは，ＭＦＰ２０の状態の監視を開始する。なお，ステータスモニタ４１は，管理部４１ＡによってＭＦＰ２０の状態の監視を開始するものの，報知部４１Ｂによるエラー情報の報知は，管理部４１Ａによって報知が許可されるまで行わない。エラー情報の報知は，初期状態では許可されていない。
【００４１】
その後，ＰＣ１０に監視対象のデバイスドライバを利用する印刷ジョブが登録されると，ＯＳ５０からステータスモニタ４１に対してジョブ登録通知が出力される。ステータスモニタ４１の管理部４１Ａは，そのジョブ登録通知を受け付けると，当該通知を受け付けてから所定時間が経過するまでの期間中，報知部４１Ｂによるエラー情報の報知を許可する。
【００４２】
ステータスモニタ４１の報知部４１Ｂは，管理部４１Ａによって報知が許可されると，管理部４１Ａが取得したＭＦＰ２０の最新の状態情報に基づくエラー情報を報知する。報知部４１Ｂは，管理部４１ＡがＭＦＰ２０の状態情報を取得するたびに，最新のエラー情報を報知する。なお，報知部４１Ｂによるエラー情報の報知態様としては，例えば，表示部１６へのポップアップ表示が該当する。この他，警告音出力等を行ってもよい。また，例えば，ダイアログボックスを点滅表示させてもよい。
【００４３】
印刷ジョブが終了すると，ＯＳ５０はステータスモニタ４１に対してジョブ終了通知を出力する。なお，印刷ジョブの終了については，スプーラ５２から最終ページの印刷データが出力されたことを意味する。そのため，ジョブ終了通知が出力されてからＭＦＰ２０で最終ページの印刷が完了するまでにタイムラグがある。一方，スキャンジョブであればスキャンデータの受信が完了したことを意味する。そのため，ジョブの終了検知時にはＭＦＰ２０での読み取りが完了している。
【００４４】
そこで，ステータスモニタ４１の管理部４１Ａは，印刷ジョブのジョブ終了通知を受け付けた場合，印刷が完了するまでのタイムラグを考慮し，ジョブ終了通知を受け付けてから所定時間の経過後に状態の報知を禁止する。すなわち，ジョブ登録通知を受け付けてからジョブ終了通知を受け付けるまでの期間Ａと，ジョブ終了通知を受け付けてから所定時間が経過するまでの期間Ｂとの合算期間が，エラー情報の報知が許可される報知期間となる。一方，スキャンジョブの終了検知時には，ＭＦＰ２０での読み取りおよびその読み取りデータの受信が完了しており，ジョブの終了検知後に発生したエラーはＰＣ１０が要求したジョブとの関連性が低い。そのため，上述の期間Ｂを０秒とし，上述の期間Ａのみが報知期間となる。報知が禁止されると，報知部４１Ｂでのエラー情報の報知は行われない。
【００４５】
すなわち，ＰＣ１０がジョブを登録した後，監視対象の画像処理装置にエラーが発生している場合には，そのエラーが上述のジョブに与える影響が大きい。そのため，そのエラー情報は，ＰＣ１０を利用するユーザにとって利用価値が高い。一方で，ＰＣ１０がジョブを登録していない間に発生したエラーの情報は，ＰＣ１０を利用するユーザにとって利用価値が必ずしも高くない。そのため，ステータスモニタ４１の報知部４１Ｂは，ジョブが登録されてからＭＦＰ２０が当該ジョブを実行している期間に相当する報知期間中，ＭＦＰ２０から得られたエラー情報を報知し，それ以外の期間は仮にＭＦＰ２０にエラーが発生したとしてもそのエラー情報を報知しない。
【００４６】
なお，ステータスモニタ４１の管理部４１Ａは，ジョブの登録に関係なく，定期的に監視対象の画像処理装置の状態を取得する。これにより，報知部４１Ｂによるエラー情報の報知とは別に，ユーザからの要求に応じていつでも画像処理装置の最新の状態を表示できる。
【００４７】
［ステータスモニタの動作］
［管理処理］
続いて，前述したエラー報知手順を実現するために，ステータスモニタ４１の管理部４１Ａが実行する管理処理について，図４のフローチャートを参照しつつ説明する。管理処理は，ステータスモニタ４１の起動を契機に，ＣＰＵ１１によって実行される。
【００４８】
管理処理では，先ず，監視対象のデバイスの状態を定期的に問い合わせるための監視タイマーを初期化して起動する（Ｓ１０１）。そして，デバイスドライバのドライバ情報をＯＳ５０の設定保存領域から取得する（Ｓ１０２）。
【００４９】
次に，Ｓ１０２で取得したドライバ情報に基づいて，接続インターフェースが一対一接続であるか否かを判断する（Ｓ１０３）。一対一接続としては，本形態ではＵＳＢインターフェース１７が該当する。この他，シリアルケーブルや専用回線を介して一対一で接続される形態も含まれる。一対一接続でない場合（Ｓ１０３：ＮＯ），例えばイーサネット（登録商標）等のネットワーク接続の場合，ＯＳ５０に対して，監視対象となるデバイスドライバを利用するジョブが登録された際にステータスモニタ４１に対してジョブ登録通知を出力するように設定する（Ｓ１１１）。
【００５０】
上述のＳ１０３およびＳ１１１の処理を繰り返し，Ｓ１０２で取得したドライバ情報に記憶されるデバイスドライバ全てに対して行う。例えば，ＭＦＰ２０のプリンタドライバとＭＦＰ２２のプリンタドライバとを監視対象とする場合，ＭＦＰ２０がネットワークインターフェース１８で接続され，ＭＦＰ２２がＵＳＢインターフェース１７で接続されることから，ＭＦＰ２０のプリンタドライバを利用するジョブが登録された際にはステータスモニタ４１に対してジョブ登録通知が行われるように設定される。
【００５１】
各デバイスドライバに対する通知設定の後，ドライバ情報が更新されたか否かを判断する（Ｓ１０４）。すなわち，管理処理の実行開始後に，監視対象となるデバイスドライバの追加ないし削除があったか否かを判断する。ドライバ情報が更新された場合には（Ｓ１０４：ＹＥＳ），Ｓ１０２に移行し，通知設定をやり直す。
【００５２】
ドライバ情報が更新されていない場合には（Ｓ１０４：ＮＯ），エラー情報の報知許可を設定する報知許可設定処理を実行する（Ｓ１０５）。ここで，Ｓ１０５の報知許可設定処理について，図５のフローチャートを参照しつつ説明する。
【００５３】
報知許可設定処理では，先ず，ジョブ登録通知が有ったか否かを判断する（Ｓ１５１）。ジョブ登録通知が有った場合には（Ｓ１５１：ＹＥＳ），エラー情報の報知を許可する（Ｓ１６１）。これにより，報知部４１Ｂによるエラー情報の報知が許可される。報知許可の有無の情報は，管理部４１Ａと報知部４１Ｂとで共用可能な記憶手段，例えばレジストリやファイルに記憶される。エラー情報の報知が許可されると，報知部４１Ｂがデバイスの状態情報に基づいてエラー情報を報知する。報知部４１Ｂの処理については後述する。一方，ジョブ登録通知が無かった場合には（Ｓ１５１：ＮＯ），エラー情報の報知は許可されない。
【００５４】
Ｓ１６１の後，あるいはジョブ登録通知が無かった場合には（Ｓ１５１：ＮＯ），ジョブ終了通知が有ったか否かを判断する（Ｓ１５２）。ジョブ終了通知が有った場合には（Ｓ１５２：ＹＥＳ），通知対象となったジョブの種類を取得する（Ｓ１７１）。そして，そのジョブの種類に基づいて，報知期間の終了時間を決定する（Ｓ１７２）。すなわち，図３中の期間Ｂを決定する。Ｓ１７２での報知期間の終了時間の決定方法としては，例えば，印刷ジョブであれば印刷が完了するまでのタイムラグを考慮してあらかじめ規定された時間を設定する。一方，スキャンジョブであれば，読み取ったデータの受信が完了した時点でスキャンが完了していることから，期間Ｂを０に設定する。Ｓ１７２の後は，報知期間用のタイマーである報知タイマーを初期化して起動する（Ｓ１７３）。
【００５５】
Ｓ１７３の後，あるいはジョブ終了通知が無かった場合には（Ｓ１５２：ＮＯ），報知期間が経過したか否かを判断する（Ｓ１５３）。具体的にＳ１５３では，Ｓ１７３で起動した報知タイマーが，Ｓ１７２で決定した終了時間以上となった場合に期間Ｂが経過した，すなわち報知期間が経過したと判断する。一方，Ｓ１７３で起動した報知タイマーが，終了時間を経過していない，あるいは報知期間が設定されていない場合，すなわちエラー情報の報知が禁止されている間，Ｓ１５３では報知期間を経過していないと判断する。
【００５６】
報知期間が経過した場合には（Ｓ１５３：ＹＥＳ），エラー情報の報知を禁止する（Ｓ１８１）。そして，報知タイマーを停止させる（Ｓ１８２）。Ｓ１８２の後，あるいは報知期間が経過していない場合には（Ｓ１５３：ＮＯ），報知許可設定処理を終了する。なお，上述の報知許可設定処理の説明は，プリンタドライバの報知許可設定についての説明であり，スキャナドライバの場合にはＳ１５１にてスキャンジョブの開始検知の有無を判断し，Ｓ１５２ではスキャンジョブの終了検知の有無を判断する。
【００５７】
なお，図５に示した報知許可設定処理（第１の形態）では，ジョブ終了通知を受け付けたことを契機に期間Ｂを決定することで報知期間を決定している。すなわち，図３中の，期間Ａ＋期間Ｂ＝報知期間としているが，ジョブ登録通知を受け付けたことを契機に，すなわちエラー情報の報知が許可された時点で報知期間を決定してもよい。この場合の報知許可設定処理（第２の形態）を，図６に示す。
【００５８】
図６に示す報知許可設定処理では，ジョブ登録通知が有った場合には（Ｓ１５１：ＹＥＳ），そのジョブによって利用されるデバイスドライバの設定情報を取得し（Ｓ２７１），そのデバイスドライバの設定情報に基づいて，報知期間の終了時間を決定する（Ｓ２７２）。Ｓ２７２の報知期間の終了時間の決定方法としては，例えば，印刷部数ｎに比例して報知期間が長くなるように設定する。また，カラー印刷の場合にモノクロ印刷よりも報知期間が長くなるように設定する。あるいはカラー印刷の枚数が閾値以上の場合には報知期間に位置ずれ補正の時間を加味する。また，両面印刷の場合に片面印刷よりも報知期間が長くなるように設定する。すなわち，Ｓ２７２では，デバイスドライバの設定情報から得られるジョブの属性に基づいて報知期間を決定する。
【００５９】
Ｓ２７２の後，エラー情報の報知を許可し（Ｓ１６１），報知タイマーを初期化して起動する（Ｓ１７３）。Ｓ１７３の後，あるいはジョブ登録通知が無かった場合には（Ｓ１５１：ＮＯ），報知期間が経過したか否かを判断する（Ｓ１５３）。そして，報知期間が経過した場合には（Ｓ１５３：ＹＥＳ），エラー情報の報知を禁止し（Ｓ１８１），報知タイマーを停止させる（Ｓ１８２）。
【００６０】
すなわち，図６に示した第２の形態の報知許可設定処理では，ジョブ終了通知とは無関係に報知期間が設定される。そのため，ジョブ終了通知の出力は不要であり，図５に示した第１の形態の報知許可設定処理と比較して処理がシンプルになる。一方で，第２の形態では，ジョブ終了通知と無関係に報知期間の終了時間を決定することから，ジョブが終了する前に報知期間が終了してしまうリスクがある。そのため，第１の形態の方が，より確実にジョブの終了まで報知期間を確保できる。
【００６１】
なお，第１の形態では，ジョブの種類に応じて報知期間を可変値としているが，固定値であってもよい。また，期間Ｂを報知期間に含めず，ジョブ終了通知を受け付けたことを契機に報知期間を終了させる，すなわち期間Ａのみを報知期間としてもよい。また，第２の形態と同様に，デバイスドライバの設定に応じて期間Ｂを可変値としてもよい。また，第２の形態では，デバイスドライバの設定に応じて報知期間を可変値としているが，固定値であってもよい。また，第１の形態と同様に，ジョブの種類に応じて可変値としてもよい。
【００６２】
図４の説明に戻り，Ｓ１０５での報知許可設定処理の後は，ステータスモニタ４１を終了させる終了通知があったか否かを判断する（Ｓ１０６）。終了通知があった場合には（Ｓ１０６：ＹＥＳ），管理処理を終了する。
【００６３】
終了通知がなかった場合には（Ｓ１０６：ＮＯ），監視対象となるデバイスへの状態の問い合わせ間隔が経過したか否かを判断する（Ｓ１０７）。具体的にＳ１０７では，Ｓ１０１で起動した監視タイマーが所定時間以上となった場合に問い合わせ間隔が経過したと判断する。問い合わせ間隔が経過していない場合には（Ｓ１０７：ＮＯ），Ｓ１０４に移行し，Ｓ１０４以降の判断を繰り返す。
【００６４】
問い合わせ間隔が経過した場合には（Ｓ１０７：ＹＥＳ），監視タイマーを初期値にリセットして再起動させる（Ｓ１２１）。さらに，監視対象となるデバイスに状態を問い合わせ，各デバイスの状態情報を取得する（Ｓ１２２）。その後，ステータスモニタ４１の報知部４１Ｂに対して報知通知を出力する（Ｓ１２３）。Ｓ１２３の後は，Ｓ１０４に移行し，再度問い合わせ間隔が経過するのを待つ。そして，問い合わせ間隔が経過する度にＳ１２１以降の処理を繰り返す。
【００６５】
［報知処理］
続いて，前述したエラー報知手順を実現するために，ステータスモニタ４１の報知部４１Ｂが実行する報知処理について，図７のフローチャートを参照しつつ説明する。報知処理は，管理部４１Ａから報知通知（図４の管理処理中のＳ１２３参照）が出力されたことを契機に，ＣＰＵ１１によって実行される。
【００６６】
報知処理では，先ず，管理部４１Ａが取得した最新の状態情報を取得する（Ｓ２０１）。そして，状態情報に含まれるエラー情報に，報知すべきエラーが有るか否かを判断する（Ｓ２０２）。例えばＳ２０２では，待機状態，スリープ状態等，エラーに関係しない状態情報は報知すべきエラーに含まない。また，例えば，ＭＦＰ２０のプリンタドライバを監視対象とした場合，ＭＦＰ２０のエラー情報であったとしてもスキャナやＦＡＸ通信に関連するエラー情報は利用価値が低い。すなわち，ジョブ登録通知があったジョブと関連しないエラー情報は，報知すべき対象ではないと判断する。また，ＭＦＰ２０およびＭＦＰ２２のプリンタドライバを監視対象とし，ＭＦＰ２０に対する印刷ジョブがあった場合，ＭＦＰ２２のエラー情報は利用価値が低い。すなわち，複数のデバイスを報知対象とした場合，ジョブ登録通知があったジョブが利用するデバイス以外のデバイスのエラー情報も，報知すべき対象ではないと判断する。報知すべきエラーが無いと判断した場合には（Ｓ２０２：ＮＯ），エラー情報を報知することなく，報知処理を終了する。
【００６７】
報知すべきエラーが有ると判断した場合には（Ｓ２０２：ＹＥＳ），報知すべきエラーが発生しているデバイスとの接続インターフェースが一対一接続であるか否かを判断する（Ｓ２０３）。一対一接続である場合には（Ｓ２０３：ＹＥＳ），発生中のエラーが他のＰＣ１０自らから投入したジョブである可能性が高い。そのため，報知許可の有無に関係なく，エラー情報を報知する（Ｓ２０５）。
【００６８】
一方，一対一接続でない場合には（Ｓ２０３：ＮＯ），管理部４１Ａにてエラーの報知が許可されているか否かを判断する（Ｓ２０４）。具体的には，管理部４１の管理処理のＳ１６１やＳ１８１にて記憶された，報知許可の有無の情報を読み出す。そして，報知が許可されている場合には（Ｓ２０４：ＹＥＳ），エラー情報を報知し（Ｓ２０５），報知処理を終了する。一方，報知が許可されていない場合には（Ｓ２０４：ＮＯ），エラー情報を報知することなく，報知処理を終了する。
【００６９】
以上詳細に説明したように，ＰＣ１０がジョブの実行要求を受け付けてからの所定時間内に，監視対象のデバイスに発生しているエラーは，ＰＣ１０が要求したジョブに関するエラーである可能性が高い。一方で，所定時間外に監視対象のデバイスに発生したエラーは，ＰＣ１０が関与しないエラーである可能性が高い。そのため，本形態のステータスモニタ４１は，その所定時間内（報知期間内）であればエラー情報を報知する。これにより，利用価値が高いエラー報知が期待できる。
【００７０】
なお，本実施の形態は単なる例示にすぎず，本発明を何ら限定するものではない。したがって本発明は当然に，その要旨を逸脱しない範囲内で種々の改良，変形が可能である。例えば，ＭＦＰは，画像処理の機能を備えるものであればよく，プリンタ，スキャナ，複写機，ＦＡＸ装置であっても適用可能である。また，ＰＣは，画像処理装置に対して画像処理ジョブを投入する装置であればよく，スマートフォンやＰＤＡであってもよい。
【００７１】
また，実施の形態では，ステータスモニタ４１の管理部４１Ａが，報知期間であるか否かに関わらず定期的にＭＦＰ２０の状態情報を取得しているが，報知期間中にのみ状態情報を取得するようにしてもよい。
【００７２】
また，実施の形態では，ジョブ登録通知があったジョブの種類と関連しないエラー情報や，ジョブ登録通知があったジョブが利用するデバイス以外のデバイスのエラー情報を，Ｓ２０２にて報知すべきエラーでないとして，報知していないが，報知してもよい。この場合，報知すべきでないエラーと判断されたエラー情報は，報知すべきエラーと判断されたエラー情報と比較して利用価値が低いため，報知すべきでないエラーと判断されたエラー情報を報知すべきエラーと判断されたエラー情報と比較して報知度合いを弱め，報知すべきエラーと区別して報知するとよい。報知度合いの強弱は，例えば，ポップアップ表示の有無，点滅表示の有無，警告音の有無，メッセージボックスの大小によって実現可能である。
【００７３】
また，実施の形態では，エラーの報知をステータスモニタ４１の報知部４１Ｂに行わせているが，これに限るものではない。例えば，メールを送信してもよい。また，例えば表示機能を有する他のアプリケーション（ブラウザやＯＳが管理するステータスモニタ等）に表示させてもよい。
【００７４】
また，実施の形態に開示されている処理は，単一のＣＰＵ，複数のＣＰＵ，ＡＳＩＣなどのハードウェア，またはそれらの組み合わせで実行されてもよい。また，実施の形態に開示されている処理は，その処理を実行するためのプログラムを記録した記録媒体，または方法等の種々の態様で実現することができる。
【符号の説明】
【００７５】
１０    ＰＣ
２０，２１，２２    ＭＦＰ
４０    デバイスドライバ
４１    ステータスモニタ
１００  画像処理システム
【図１】
2014197304.tif 000003
【図２】
2014197304.tif 000004
【図３】
2014197304.tif 000005
【図４】
2014197304.tif 000006
【図５】
2014197304.tif 000007
【図６】
2014197304.tif 000008
【図７】
2014197304.tif 000009