JPWO2011121723A1 - 画像処理装置、画像処理装置の制御方法、及びプログラム - Google Patents

Abstract

サーバからの要求に基づく処理を実行する情報処理装置において、ブラウザがサーバからの指示を待つことなしに適切にユーザに状態変化を通知し、更に、サーバからの指示を受信次第、適切な操作画面を表示する仕組みを提供することを目的とする。Ｗｅｂサーバ１０２からの要求に基づく処理を実行するサービスプロバイダ４４０は状態変化を監視する。サービスプロバイダ４４０が状態変化を検知するとＷｅｂブラウザ４３０に状態と、状態に対応したコンテンツ情報を通知する。Ｗｅｂブラウザ４３０はサービスプロバイダ４４０からの状態変化通知に含まれるコンテンツ情報に従がって画面を表示する。更に、Ｗｅｂブラウザ４３０はＷｅｂサーバ１０２からの指示にしたがいＵＲＬにアクセスし、適切な操作画面を取得し、表示する。

Description

本発明は、ネットワークを介して接続された外部装置によって提供される操作画面を表示可能な画像処理装置、当該画像処理装置の制御方法、及びプログラムに関する。

Ｗｅｂブラウザが組み込まれたＭＦＰ（Ｍｕｌｔｉ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）と、Ｗｅｂサーバとがネットワークを介して通信可能な画像処理システムが一般的に知られている。この画像処理システムによれば、ＭＦＰは、Ｗｅｂサーバによって提供されるＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）等で記述された画面情報を受信し、ＭＦＰを操作するための画面である操作画面を表示する。そして、この操作画面を介してユーザから各種の操作を受け付けることが可能である。これにより、ＭＦＰの操作画面を表示するための全ての画面情報をＭＦＰ自身で保持する必要がなくなり、また操作画面のカスタマイズをＷｅｂサーバで容易に行うことが可能である。

また更には、特許文献１のような技術が知られている。特許文献１は、外部サーバからのＷｅｂサービスの要求に応じてジョブを実行するＭＦＰにおいて、ジョブ実行中にエラー（例えばプリンタの紙詰まりなど）が発生した場合について開示している。特許文献１によれば、上述のようなエラーが発生した場合、ＭＦＰは外部サーバにエラーを通知する。そして外部サーバから送信された画面情報を取得し適切なエラー画面を表示する。このような処理を行うことで、エラーの内容を通知する画面や、エラーから復帰するための処理をガイダンスする画面などに関してもＷｅｂサーバで容易にカスタマイズすることが可能である。

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

しかしながら、特許文献１に開示されている画像処理システムの構成では以下のような課題がある。例えば、ジョブの実行中に上述のようなエラーが発生した場合を考える。特許文献１によれば、ＭＦＰは外部サーバにエラーの発生を通知し（あるいは外部サーバにエラー画面を要求し）、その応答を待つ。このとき、実際にエラーが発生してから外部サーバが提供するエラー画面を表示するまでに、Ｗｅｂサーバおよびネットワークを経由してエラー画面の画面情報を取得するため、タイムラグが発生する。このタイムラグの間、ユーザはエラーが発生したことを把握することができない。

エラー画面の画面情報をＭＦＰ自身が保持するように構成し、エラーが発生した場合にはＭＦＰ自身が保持する画面情報に基づきエラー画面を表示すれば、上述のタイムラグは発生することはない。しかしこれでは、エラー画面を外部装置でカスタマイズすることはできない。

またエラー画面に関してだけでなく、一般に、画像処理装置が実行するジョブの状態の変化が発生した場合にも同様の課題がある。すなわち、ユーザは少なくともジョブの処理状態が変化してから外部装置から受信した画面情報に基づく画面が表示されるまでの間、その状態の変化を把握することができない。

本発明は、上記課題に鑑みて、ジョブの状態が変化した場合、その状態の変化をユーザに迅速に通知することができるような仕組みを提供することを目的とする。

上記目的を達成するために、本発明における画像処理装置は、外部装置とネットワークを介して通信可能な画像処理装置であって、前記外部装置からの要求に応じてジョブを実行する実行手段と、前記実行手段が実行するジョブの状態の変化を検知する検知手段と、前記検知手段によって検知された状態の変化に対応する第１の画面を表示するための画面情報を記憶する記憶手段と、前記検知手段によって検知された状態の変化を前記外部装置に通知する通知手段と、前記通知手段による通知を受けた外部装置から、前記検知手段によって検知された状態の変化に対応する第２の画面を表示するための画面情報を受信する受信手段と、前記受信手段によって受信された画面情報に基づいて生成された第２の画面を操作部に表示する表示制御手段とを備え、前記表示制御手段は、前記検知手段によって状態の変化が検知された場合、少なくとも前記受信手段によって受信された画面情報に基づいて生成された第２の画面を表示する前に、前記記憶手段に記憶された画面情報に基づいて第１の画面を表示することを特徴とする。

本発明によれば、画像処理装置において実行されるジョブの状態の変化が発生した場合、その状態の変化をユーザに迅速に通知する仕組みを提供することができる。

本発明の実施形態における画像処理システムの全体図である。 本発明の実施形態におけるＭＦＰ１０１及びＷｅｂサーバ１０２のハードウェア構成を示すブロック図である。 本発明の実施形態における画像処理システムのソフトウェア構成を示すブロック図である。 本発明の実施形態における画面情報管理部３４４が管理するデータについて説明するための図である。 本発明の実施形態におけるＷｅｂブラウザ３３０、Ｗｅｂサーバ１０２、及びサービスプロバイダ３４０のそれぞれの動作について示すシーケンス図である。 本発明の実施形態におけるＷｅｂブラウザ３３０によって表示される画面の遷移を示す図である。 本発明の実施形態におけるＷｅｂブラウザ３３０、Ｗｅｂサーバ１０２、及びサービスプロバイダ３４０のそれぞれの動作について示すシーケンス図である。 本発明の実施形態におけるＷｅｂブラウザ３３０によって表示される画面の遷移を示す図である。 本発明の実施形態におけるサービスプロバイダ３４０が行う処理を示すフローチャートである。 本発明の実施形態におけるＷｅｂブラウザ３３０が行う処理を示すフローチャートである。 本発明の実施形態における画像処理システムのソフトウェア構成を示すブロック図である。 本発明の実施形態におけるＷｅｂブラウザ３３０、Ｗｅｂサーバ１０２、及びサービスプロバイダ３４０のそれぞれの動作について示すシーケンス図である。 本発明の実施形態における本発明の実施形態におけるサービスプロバイダ３４０が行う処理を示すフローチャートである。 本発明の実施形態におけるＷｅｂブラウザ３３０が行う処理を示すフローチャートである。

以下、図面を参照して本発明の実施の形態について詳しく説明する。なお、以下の実施の形態は特許請求の範囲に係る発明を限定するものでない。また実施の形態で説明されている特徴の組み合わせの全てが発明の解決手段に必須のものとは限らない。

図１を参照して、本実施形態における画像処理システムの構成について説明する。この画像処理システムにおいて、ＭＦＰ１０１ａ、ＭＦＰ１０１ｂ、ＭＦＰ１０１ｃ及びＷｅｂサーバ１０２がＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１１０を介して互いに通信可能に接続されている。

ＭＦＰ１０１ａ〜ｃは、スキャン機能、プリント機能、コピー機能、送信機能などの複数の機能を兼ね備えている。ＭＦＰ１０１ａ〜ｃはそれぞれ異なる機能を備えていてもよいし、同一の機能を備えていてもよい。以下、ＭＦＰ１０１ａ〜ｃは同一のＭＦＰであるとして、単にＭＦＰ１０１と称する。ＭＦＰ１０１は画像処理装置の一例であって、これらの機能のいずれかを備えたＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）であってもよい。またＭＦＰ１０１は後述するＷｅｂブラウザ３３０を更に備えている。Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２から画面情報を受信し、受信した画面情報を解析してＭＦＰの操作部に操作画面を表示することが可能である。本実施形態では、画面情報として、ＨＴＭＬ形式で記述されたデータであるＨＴＭＬデータを例にして説明する。ただし画面情報は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式やＷＭＬ（Ｗｉｒｅｌｅｓｓ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式、ＸＨＴＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｈｙｐｅｒｔｅｘｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式などのデータで記述されていてもよい。更に、ＨＴＭＬデータが他の言語で記述された画面情報を参照していてもよい。

またＷｅｂサーバ１０２は外部装置の一例であり、Ｗｅｂサーバ１０２の他の形態としてＰＣや、記憶装置、その他の演算装置を用いてもかまわない。なお、ここでは、Ｗｅｂサーバ１０２が１台でサービスを提供する例を示した。しかしながら、Ｗｅｂサーバ１０２の他の形態として、複数のサーバによって構成され、そのサーバ群の中で複数のヴァーチャルマシンを起動して分散処理を行うようにしても構わない。この場合、所定の条件に応じてヴァーチャルマシンを増加させるスケールアウトと呼ばれる技術（クラウドコンピューティング）が用いられる。

またＬＡＮ１１０の代わりに、ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）や、ＵＳＢケーブル、無線などの通信回線を利用してもかまわない。

図２を参照して、ＭＦＰ１０１及びＷｅｂサーバ１０２のハードウェア構成について説明する。まず、ＭＦＰ１０１のハードウェア構成から説明する。ＣＰＵ２１１を含む制御部２１０は、ＭＦＰ１０１全体の動作を制御する。制御部２１０に含まれるＣＰＵ２１１は、ＲＯＭ２１２に記憶された制御プログラムを読み出して読取制御や送信制御などの各種制御を行う。ＲＡＭ２１３は、ＣＰＵ２１１の主メモリ、ワークエリア等の一時記憶領域として用いられる。

ＨＤＤ２１４は、画像データや各種制御プログラム、或いは各種情報テーブルを記憶する。操作部Ｉ／Ｆ２１５は、操作部２１９と制御部２１０とを接続するインターフェースである。操作部２１９は、タッチパネル機能を有する液晶表示部やキーボードなどを備えている。また、ＭＦＰ１０１が備えるＷｅｂブラウザ３３０は、操作部２１９の液晶表示部に、Ｗｅｂサーバ１０２から受信する画面情報に基づき生成された操作画面を表示する。

プリンタＩ／Ｆ２１６は、プリンタ２２０と制御部２１０とを接続するインターフェースである。プリンタ２２０によって印刷される画像データはプリンタＩ／Ｆ２１６を介して制御部２１０から転送され、プリンタ２２０において記録媒体上に印刷される。

スキャナＩ／Ｆ２１７は、スキャナ２２１と制御部２１０とを接続するインターフェースである。スキャナ２２１は、原稿上の画像を読み取って画像データを生成し、スキャナＩ／Ｆ２１７を介して制御部２１０に入力する。

ネットワークＩ／Ｆ２１８は、制御部２１０（ＭＦＰ１０１）とＬＡＮ１１０とを接続するインターフェースである。ネットワークＩ／Ｆ２１８は、ＬＡＮ１１０上のＷｅｂサーバ１０２に画像データなどの各種情報を送信したり、ＬＡＮ１１０上のＷｅｂサーバ１０２から画像データなどの各種情報を受信したりする。

同様に図２を参照して、Ｗｅｂサーバ１０２のハードウェア構成について説明する。ＣＰＵ２３１を含む制御部２３０は、Ｗｅｂサーバ１０２全体の動作を制御する。制御部２３０に含まれるＣＰＵ２３１は、ＲＯＭ２３２に記憶された制御プログラムを読み出して各種制御処理を実行する。ＲＡＭ２３３は、ＣＰＵ２３１の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ２３４は、画像データや各種プログラム、或いは後述する各種情報テーブルを記憶する。

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

図３を参照して、図１に示す画像処理システムのソフトウェア構成について説明する。まずＭＦＰ１０１が有するソフトウェアの構成について説明する。

ＭＦＰ１０１は、Ｗｅｂブラウザ３３０及びサービスプロバイダ３４０を実装する。Ｗｅｂブラウザ３３０及びサービスプロバイダ３４０のそれぞれは、ＭＦＰ１０１が備えるＣＰＵ２１１がＨＤＤ２１４に格納されているプログラムである。

Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２とＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）に従がって通信する。Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２によって生成されたＨＴＭＬデータを受信し、操作画面を生成して操作部２１９に表示制御する。Ｗｅｂブラウザ３３０は、単にＷｅｂサーバ１０２から送信されたＨＴＭＬデータに基づき操作画面（第２の画面）を表示するだけでなく、ＨＤＤ２１４に格納されたＨＴＭＬデータなどの画面情報に基づき操作画面（第１の画面）を表示することも可能である。なお、Ｗｅｂブラウザ３３０は、ＭＦＰ１０１の外部にある装置と通信が可能であり、外部装置から画面情報を取得し、操作部２１９に画面を表示することが可能であれば、他のソフトウェアで実現してもよい。

Ｗｅｂブラウザ３３０は、通信部３３１、解析部３３２、状態通知受信部３３３、及び画面表示部３３４を有している。

通信部３３１は、ネットワークＩ／Ｆ２１８を利用して、ＨＴＴＰに従がってＷｅｂアプリケーション３１０の画面提供部３１１と通信する。具体的には、通信部３３１は、ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）によって特定されるリソースに対するリクエストを発行し、そのレスポンスを受信する。この過程で、各種符号化形式に則した通信データの符号化・復号化を行う。例えば、通信中のデータの安全性を確保するため、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔ Ｌａｙｅｒ）による通信を行う。

解析部３３２は、画面提供部３１１から通信部３３１を介して受信したレスポンスに含まれるＨＴＭＬデータを解析する。そして、Ｗｅｂブラウザ３３０で表示すべき操作画面を生成する。

状態通知受信部３３３は、スキャナ２２１やプリンタ２２０の処理状態が変化したことを示す通知（以下、「状態通知」ともいう）を状態監視部３４３から受信する。処理状態の変化とは、ジョブの実行中にエラーが発生してエラー状態となったり、エラー状態から正常の状態に復帰したりすることが挙げられる。また、ジョブが完了したことなども処理状態の変化に含まれる。エラー状態とは、例えば、スキャナ２２１の読取失敗や、紙詰まり、プリンタ２２０の紙不足や、トナー切れ、インク不足、その他ハードウェアの故障などの状態である。状態通知受信部３３３は、更に、操作部２１９に簡易的な画面である簡易画面（第１の画面）を表示するためのＨＴＭＬデータを受信することができる。このＨＴＭＬデータはＭＦＰ１０１のＨＤＤ２１４に格納されている。状態通知受信部３３３は、受信したＨＴＭＬデータを取得し、解析部３３２へ転送する。簡易画面は、エラーが発生したことを通知する画面や、ジョブが完了したことを通知する画面である。

画面表示部３３４は、解析部３３２で生成された画面を操作部２１９に表示する。なお、画面表示部３３４は、Ｗｅｂサーバ１０２から送信されるＨＴＭＬデータのみならず、ＨＤＤ２１４に格納されているＨＴＭＬデータに基づいて簡易画面（第１の画面）を表示することも可能である。

以上よりＷｅｂブラウザ３３０のソフトウェア構成について説明した。

次にサービスプロバイダ３４０のソフトウェア構成について説明する。サービスプロバイダ３４０は、Ｗｅｂサーバ１０２から依頼されたＷｅｂサービスを提供するモジュールである。Ｗｅｂサービスは、ＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）によって識別されるソフトウェアによって提供されるサービスである。本実施形態においては、サービスプロバイダ３４０は、Ｗｅｂサーバ１０２からＳＯＡＰ（Ｓｉｍｐｌｅ Ｏｂｊｅｃｔ Ａｃｃｅｓｓ Ｐｒｏｔｏｃｏｌ）にしたがったリクエストを受信する。サービスプロバイダ３４０は、受信したリクエストに従がって、Ｗｅｂサービスとしてスキャナ２２１またはプリンタ２２０にジョブを実行させる。Ｗｅｂサーバ１０２から送信されるリクエストは、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述されており、プリントやスキャンのための設定値を含んでいる。リクエストには、例えば「原稿をスキャンしてＴＩＦＦ形式で保存する」等のジョブをＷｅｂサービスとして依頼するメッセージが記述されている。ジョブの例としては、「コピージョブ」「スキャンジョブ」「プリントジョブ」「送信ジョブ」（あるいはこれらを組み合わせたジョブ）などが挙げられる。

サービスプロバイダ３４０は、通信部３４１、ジョブ生成部３４２、状態監視部３４３、及び画面情報管理部３４４を有する。

通信部３４１は、ネットワークＩ／Ｆ２１８を利用して、Ｗｅｂサーバ１０２からＳＯＡＰにしたがったリクエストを受信する。なお、本実施形態では、通信部３４１をＷｅｂブラウザ３３０の通信部３３１と別個に設けているが、これら通信部が同一の通信部であってもかまわない。また通信部プロトコルとしてＳＯＡＰを利用しているが、別のプロトコルを用いてもかまわない。

ジョブ生成部３４２は、通信部３４１を介して受信したリクエストを受け取り、依頼されたＷｅｂサービスを提供するため、ジョブを生成して実行する。なお、ジョブ生成部３４２は、Ｗｅｂブラウザ３３０によって受信されるＨＴＴＰにしたがったメッセージに埋め込まれたジョブスクリプトなどを解釈することによってジョブを生成してもよい。

状態監視部３４３は、ジョブ生成部３４２によるジョブの実行中に、スキャナ２２１やプリンタ２２０、その他のハードウェアの状態を監視する。状態監視部３４３は、これらの状態が変化すると、状態通知をＷｅｂブラウザ３３０に内部的に送信する。具体的には、スキャナ２２１で読み取り失敗やプリンタ２２０で紙詰まりなどのエラーが発生したことを検知すると、エラーが発生したことを示す通知であるエラー発生通知をＷｅｂブラウザ３３０に送信する。またエラーから復帰したことを検知すると、エラーから復帰したことを示す通知であるエラー復帰通知を送信する。またジョブが正常に完了したことを検知すると、ジョブが正常に完了したことを示す通知であるジョブ完了通知を送信する。このように、状態監視部３４３はＭＦＰ１０１の処理状態が変化したことを示す状態通知をＷｅｂブラウザに送信する。

また状態監視部３４３は、状態通知を送信するとともに、検知した処理状態の変化に対応する簡易画面のＨＴＭＬデータを送信する。このＨＴＭＬデータは、状態監視部３４３に検知される処理状態に関連づけられて、画面情報管理部３４４によってＨＤＤ２１４に格納されている。

以上より、ＭＦＰ１０１のソフトウェア構成について説明した。

同様に図３を参照してＷｅｂサーバ１０２のソフトウェア構成について説明する。Ｗｅｂサーバ１０２は、Ｗｅｂアプリケーション３１０を実装している。Ｗｅｂアプリケーション３１０は、Ｗｅｂブラウザ３３０からリクエストを受信すると、Ｗｅｂブラウザに対して操作画面を表示するための画面情報や画像データを送信するレスポンスを送信する。またＷｅｂアプリケーション３１０は、サービスプロバイダ３４０に対してＷｅｂサービスを依頼するリクエストを送信し、サービスプロバイダ３４０から送信されるレスポンスを受信する。

Ｗｅｂアプリケーション３１０は、画面提供部３１１と実行指示部３１２とを有している。

画面提供部３１１は、ネットワークＩ／Ｆ２１８を利用して、ＭＦＰ１０１の通信部３３１とＨＴＴＰに従がって通信する。画面提供部３１１は、Ｗｅｂブラウザ３３０で操作部２１９に操作画面を表示するためのＨＴＭＬデータを送信する。また画面提供部３１１は、Ｗｅｂブラウザ３３０で操作部２１９に表示された操作画面を介して入力されたユーザからの指示（実行イベント）を、ＭＦＰ１０１からのリクエストとして受信する。そして、リクエストに対するレスポンスとしてＷｅｂブラウザ３３０に操作画面の情報を送信する。また画面提供部３１１は、Ｗｅｂブラウザ３３０で表示された操作画面を介して入力された指示や実行イベントを、実行指示部３１２に通知する。

なお画面提供部３１１と実行指示部３１２は、同一のＷｅｂサーバ１０２内に存在しているが、異なる装置に存在していても構わない。この場合は、画面提供部３１１を実装する装置と実行指示部３１２を実装する装置とが、互いにネットワークやその他の通信回線を介して通信する。

実行指示部３１２は、画面提供部３１１から通知された実行イベントを取得し、ＭＦＰ１０１のサービスプロバイダ３４０にＷｅｂサービスを依頼するリクエストを生成する。このリクエストは、具体的には、ＳＯＡＰにしたがったメッセージである。そして実行指示部３１２は、生成したリクエストをサービスプロバイダ３４０に送信する。また実行指示部３１２は、サービスプロバイダ３４０に送信するリクエストに、ジョブの完了時にＷｅｂブラウザ３３０で表示させたい操作画面に対応するＵＲＩを、復帰ＵＲＩとして含めることもできる。

次に図４を参照して、画面情報管理部３４４によって管理されるデータベースについて説明する。図４に示すデータベースの各レコードは、状態４００と画面情報４０１とを構成要素としている。つまり、画面情報管理部３４４は、複数の処理状態と、その処理状態に対応する状態発生時に表示すべき画面の画面情報とを関連付けてＨＤＤ２１４に管理する。

図５を参照して、本実施形態における画像処理システムの動作について説明する。図５は、Ｗｅｂブラウザ３３０と、サービスプロバイダ３４０と、Ｗｅｂサーバ１０２（Ｗｅｂアプリケーション）の動作を示すシーケンス図である。図５のシーケンス図は、サービスプロバイダ３４０がジョブを実行中にエラーが発生したことを前提としている。エラーが発生せずに正常にジョブが完了する場合の動作については図７にて後述する。

まず、Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２のＷｅｂアプリケーション３１０に対してリクエスト５００を送信する。このリクエスト５００は、図６（ａ）に示す操作画面の画面情報を要求するリクエストである。

次に、Ｗｅｂサーバ１０２は、Ｗｅｂブラウザ３３０からリクエスト５００を受信し、リクエスト５００に対するレスポンス５０１をＷｅｂブラウザ３３０に送信する。レスポンス５０１には、図６(a)に示す操作画面の画面情報が含まれている。このようなリクエストとレスポンスのやり取りをＷｅｂブラウザ３３０とＷｅｂアプリケーション３１０は複数回繰り返しても構わない。

Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２から受信したレスポンス５０１に含まれるＨＴＭＬデータを解析し、解析結果に基づき生成された操作画面を操作部２１９に表示する。図６（ａ）の操作画面は、画面表示部３３４が操作部２１９に表示する画面の一例である。図６（ａ）は、「原稿をスキャンして保存する」という一連のジョブを実行するための操作画面である。以降の説明では、この「原稿をスキャンして保存する」というジョブを実行する場合を例にして説明する。ただし、これ以外にも、ＭＦＰが備える他の機能を利用するジョブであってもよく、「コピージョブ」「送信ジョブ」「プリントジョブ」等のジョブを実行してもかまわない。

図６（ａ）の操作画面には、フォルダ名、ファイル名、ファイル形式、解像度を設定するフォーム、及びスキャンボタンが表示されている。ユーザがこれらのフォームに設定値を入力しスキャンボタンを押下すると、スキャンの実行イベントがＷｅｂサーバ１０２に通知される。なお、これらの設定値は、図６（ａ）の操作画面で設定するようにしてもよいし、Ｗｅｂアプリケーション３１０自体がデフォルトの設定値として予め保持しているパラメータを使用してもかまわない。

Ｗｅｂブラウザ３３０は、図６（ａ）の操作画面を介したユーザ操作に応じて、リクエスト５０２をＷｅｂアプリケーション３１０に送信する。リクエスト５０２には、ユーザ操作によってスキャンボタンが押下されたことを示す実行イベントと、フォルダ名、ファイル名、ファイル形式、解像度の設定値とが含まれている。

Ｗｅｂサーバ１０２は、Ｗｅｂブラウザ３３０からリクエスト５０２を受信し、リクエスト５０２に対するレスポンス５０３をＷｅｂブラウザ３３０に送信する。Ｗｅｂブラウザ３３０は、受信したレスポンス５０３に基づいて操作部２１９に図６（ｂ）の実行画面を表示する。図６（ｂ）は、図６（ａ）でユーザが指示した実行イベントにしたがったジョブが実行中（読み取り中）であることを示す画面である。

次に、Ｗｅｂサーバ１０２は、サービスプロバイダ３４０にリクエスト５０４を送信する。リクエスト５０４は、「原稿をスキャンして保存する」といったジョブの実行をＷｅｂサービスとしてサービスプロバイダ３４０に依頼するメッセージが含まれている。

サービスプロバイダ３４０は、Ｗｅｂサーバ１０２からリクエスト５０４を受信し、受信したリクエスト５０４に従がって依頼されたジョブを実行する。

サービスプロバイダ３４０の状態監視部３４３は、リクエスト５０４に従がってジョブを実行している途中に何らかの原因でエラー発生すると、そのエラーの発生を検知する。状態監視部３４３は、検知したエラーに対応する画面情報を画面情報管理部３４４から参照し、発生したエラーの状態に関連付けてＨＤＤ２１４に格納されているＨＴＭＬデータを取得する。このＨＴＭＬデータは、操作部２１９にエラー画面を表示するための画面情報である。状態監視部３４３は、エラーが発生したことを通知するエラー発生通知５０５を、画面情報管理部３４４を介してＨＤＤ２１４から取得したＨＴＭＬデータとともにＷｅｂブラウザ３３０に送信する。

Ｗｅｂブラウザ３３０は、エラー発生通知５０５とともにエラー画面のＨＴＭＬデータを受信する。Ｗｅｂブラウザ３３０は、エラー発生通知５０５を受信することによりエラーが発生したと判断する。そして、受信したＨＴＭＬデータに基づいて図６（ｃ）のエラー画面を表示する。

図６（ｃ）にエラー画面の一例を示す。図６（ｃ）に示される画面には、エラーが発生したことをユーザに通知するためのメッセージが表示されている。図６（ｃ）に示される画面は、第１の画面の一例である。

一方、サービスプロバイダ３４０は、レスポンス５０６をＷｅｂサーバ１０２に送信する。レスポンス５０６は、例えば、Ｗｅｂサーバ１０２が送信したリクエスト５０４に従がって、エラーが発生しジョブが一時停止したことを示すレスポンスである。レスポンス５０６を受信したＷｅｂサーバ１０２は、エラーに対応する操作画面を表示するためのＨＴＭＬデータの格納位置を示すＵＲＬ５０７を、サービスプロバイダ３４０に送信する。Ｗｅｂサーバ１０２は、ＵＲＬ５０７を送信し、ＭＦＰ１０１の状態変化に対する適切な画面を表示させることができる。なおＵＲＬを送信する代わりに、画面情報であるＨＴＭＬデータを直接サービスプロバイダ３４０に送信してもよい。

サービスプロバイダ３４０は、ＵＲＬ５０７を受信し、Ｗｅｂブラウザ３３０へＵＲＬ５０７をＵＲＬ５０８として転送する。なお、Ｗｅｂブラウザ３３０は、サービスプロバイダ３４０からの通知や画面情報を受け付けることが可能となっている。すなわちＷｅｂブラウザ３３０は、単にＷｅｂサーバ１０２上のＷｅｂアプリケーション３１０との通信だけではなく、サービスプロバイダ３４０からの特殊なコマンドを受け付けることが可能となっている。

Ｗｅｂブラウザ３３０は、サービスプロバイダ３４０から受信したＵＲＬ５０８に基づき、エラーに対する操作画面を要求する。具体的には、リクエスト５０９をＷｅｂサーバ１０２に送信する。リクエスト５０９は、エラー状態に対応する操作画面を要求するリクエストである。

Ｗｅｂサーバ１０２は、Ｗｅｂブラウザ３３０からリクエスト５０９を受信し、リクエスト５０９に含まれるＵＲＬ５０８によって特定されるＨＴＭＬデータをレスポンス５１０として送信する。

Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２からレスポンス５１０を受信し、レスポンス５１０に含まれる画面情報に基づき図６（ｄ）の操作画面を操作部２１９に表示する。図６（ｄ）の操作画面には、読み取り時にエラーが発生したことを通知し、再度スキャンの実行を促すメッセージが表示されている。ユーザは、必要に応じてエラーの状態を確認し、この操作画面を介してスキャンボタンを押下することにより、再度同じジョブ、あるいは設定を変更したジョブを実行させることができる。図６（ｄ）に示される画面は、第２の画面の一例である。

図７は、Ｗｅｂブラウザ３３０と、サービスプロバイダ３４０と、Ｗｅｂサーバ１０２（Ｗｅｂアプリケーション）の動作を示したシーケンス図である。図５は、サービスプロバイダ３４０がジョブを実行中にエラーが発生した場合について示していたのに対し、図７はサービスプロバイダ３４０が実行するジョブが正常に完了した場合について示している。

図７に示す５００〜５０４までのシーケンス、すなわち、Ｗｅｂサーバ１０２がリクエスト５０４をサービスプロバイダ３４０に送信するまでの動作は、図５と同様である。図７が図５と異なる点は、サービスプロバイダ３４０において、Ｗｅｂブラウザ３３０にジョブ完了通知７００を送信する点と、Ｗｅｂサーバ１０２に対してジョブが完了したことを示すレスポンス７０１を送信する点である。以下この部分について説明する。

サービスプロバイダ３４０は、Ｗｅｂサーバ１０２から受信したリクエスト５０４に基づくジョブが完了すると、ジョブの完了による処理状態の変化を検知する。状態監視部３４３は、この処理状態の変化を検知すると、ジョブの完了という状態４００に関連付けてＨＤＤ２１４に格納されている画面情報（ＨＴＭＬデータ）を参照し、取得する。このＨＴＭＬデータは、操作部２１９に簡易的にジョブの完了を通知するための画面の画面情報である。状態監視部３４３は、ジョブが完了したことを示すジョブ完了通知７００を、画面情報管理部３４４を介してＨＤＤ２１４から取得したＨＴＭＬデータとともにＷｅｂブラウザ３３０に送信する。

Ｗｅｂブラウザ３３０はジョブ完了通知７００とＨＴＭＬデータとを受信する。そして、ジョブ完了通知７００とともに受信したＨＴＭＬデータに基づき図８（ｃ）の操作画面を操作部２１９に表示する。図８（ｃ）に示す画面は、画面情報管理部３４４によってＨＤＤ２１４に格納されている画面情報に基づき表示される第１の画面の一例であり、ジョブが完了したことをユーザに通知するメッセージが表示されている。この結果ユーザは、Ｗｅｂサーバ１０２から受信した画面情報に基づく操作画面（第２の画面）が表示されるのを待たなくても即座にジョブが完了したことを知ることができる。

サービスプロバイダ３４０は、ＵＲＬ５０７を受信し、Ｗｅｂブラウザ３３０へＵＲＬ５０７をＵＲＬ５０８として転送する。５０７と５０８は同一のＵＲＬである。

Ｗｅｂブラウザ３３０は、サービスプロバイダ３４０から受信したＵＲＬ５０８に基づき、ジョブ実行後に表示すべき操作画面を要求する。

Ｗｅｂサーバ１０２は、Ｗｅｂブラウザ３３０からリクエスト５０９を受信し、リクエスト５０９に含まれるＵＲＬ５０８によって特定されるＨＴＭＬデータをレスポンス５１０として送信する。

Ｗｅｂブラウザ３３０は、Ｗｅｂサーバ１０２からレスポンス５１０を受信し、レスポンス５１０に含まれる画面情報に基づき図８（ｄ）の操作画面を操作部２１９に表示する。

図８（ｄ）に示す画面は、Ｗｅｂサーバ１０２から受信する画面情報に基づき表示される第２の画面の一例である。本実施形態においては図８（ｄ）は図８（ａ）と同じ操作画面であるが、実行完了後のジョブの設定情報や履歴などを詳細に表示する操作画面であったり、次に実行すべきジョブの操作画面であったりしてもよい。

次に図９のフローチャートを参照して、ＭＦＰ１０１のサービスプロバイダ３４０が実行する処理について説明する。図９のフローチャートに示す各動作は、ＣＰＵ２１１がＲＯＭ２１２に格納されたプログラムを実行することにより実現される。

ステップＳ９０１（以下、ステップの表記は省略する）にて、通信部３４１は、Ｗｅｂサーバ１０２の実行指示部３１２からリクエスト５０４を受信する。

Ｓ９０２にて、ジョブ生成部３４２は、通信部３４１を介して受信したリクエスト５０４に含まれるメッセージに従がってＷｅｂサービスを呼び出す。具体的には、例えば、ジョブ生成部３４２は「原稿をスキャンして保存する」というジョブを生成し、スキャナ２１１に原稿の読み取りを行わせ、ネットワークＩ／Ｆ２１８を利用して指定された外部装置の指定フォルダにファイルを格納する。

Ｓ９０３にて、状態監視部３４３は、ジョブの処理状態が変化したことを検知する。例えば、ジョブ生成部３４２による処理の実行中にエラーの発生したことを検知したり、ジョブが完了したことを検知したりする。ジョブの処理状態の変化を検知すると、Ｓ９０４にて、状態監視部３４３はＷｅｂブラウザ３３０の状態通知受信部３３３に状態通知を行う。具体的には、エラーの発生を検知した場合には、図５で示したエラー発生通知５０５を送信する。ジョブが完了した場合には、図７で示したジョブ完了通知７００を送信する。（以下、エラー発生通知５０５とジョブ完了通知を総称して状態通知と称する）。

状態監視部３４３は、状態通知とともに、検知した処理の状態の変化に対する操作画面の情報（ＨＴＭＬデータ）を画面情報管理部３４４から取得して送信する。エラーが発生した場合にはＨＴＭＬデータＡを送信し、ジョブが完了した場合にはＨＴＭＬデータＢを送信するというように、それぞれの状態に応じたＨＴＭＬデータを状態通知に含めて送信する。また、画面情報管理部３４４がＨＤＤ２１４で管理する画面情報は、エラーの状態を更に細分化して管理することもできる。例えば、スキャナ２２１による読み取りエラーの場合とプリンタ２２０の紙詰まりエラーの場合とで異なるＨＴＭＬデータを管理してもよい。

Ｓ９０５にて、通信部３４１は、状態監視部３４３が処理状態を検知したことを受けて、レスポンス５０６をＷｅｂサーバ１０２の実行指示部３１２に送信する。Ｓ９０４とＳ９０５によれば、ＭＦＰ１０１は、Ｗｅｂブラウザ３３０とＷｅｂサーバ１０２のそれぞれにエラーが発生したことを示す通知を送信することになる。

Ｓ９０６にて、通信部３４１は、Ｗｅｂサーバ１０２の実行指示部３１２からＵＲＬ５０７を受信する。ＵＲＬ５０７は、Ｗｅｂブラウザ３３０によってエラー状態に対する操作画面のＨＴＭＬデータの格納場所を示している。通信部３４１は、ＵＲＬ５０７を状態監視部３４３へ送る。

Ｓ９０７にて、ＵＲＬ５０７を受信した状態監視部３４３は、状態監視部３４３へＵＲＬ５０８を転送する。

図１０のフローチャートを参照して、Ｗｅｂブラウザ３３０が実行する処理について説明する。図１０のフローチャートに示す各動作は、ＣＰＵ２１１がＲＯＭ２１２に格納されたプログラムを実行することにより実現される。図１０のフローチャートは、ユーザによりＷｅｂブラウザ３３０の起動指示がなされ、Ｗｅｂブラウザ３３０がＷｅｂサーバ１０２に操作画面を要求することにより処理が開始される。

Ｓ１００１にて、Ｗｅｂブラウザ３３０は図６（ａ）の操作画面を要求する処理を行う。通信部３３１は、Ｗｅｂサーバ１０２の画面提供部３１１にＨＴＴＰにしたがったリクエスト５００を送信する。リクエスト５００は、Ｗｅｂブラウザ３３０で管理されている初期表示ＵＲＬに基づいて送信されてもよいし、ユーザが指定したＵＲＬに基いて送信されてもよい。

Ｓ１００２にて、Ｗｅｂブラウザ３３０は図６（ａ）に示す操作画面を表示する処理を行う。通信部３３１はＷｅｂサーバ１０２からレスポンス５０１を受信する。解析部３３２は通信部３３１を介してＨＴＭＬデータを取得し、そのＨＴＭＬデータを解析して操作画面を生成する。画面表示部３３４は、解析部３３２によって生成された操作画面を操作部２１９に表示する。そしてユーザは操作部２１９に表示された操作画面を介して、フォルダ名やファイル名、ファイル形式、解像度などの値を設定し、スキャンボタンを押下する。

Ｓ１００３にて、通信部３３１は、図６（ａ）の操作画面を介して行われたユーザ操作（実行イベント）をＷｅｂサーバ１０２に送信する。

Ｓ１００４にて、Ｗｅｂブラウザ３３０は図６（ｂ）の操作画面を表示する処理を行う。具体的には、通信部３３１は、画面提供部３１１からレスポンス５０３を受信する。このレスポンス５０３には、実行画面を表示するためのＨＴＭＬデータが記述されている。解析部３３２はＨＴＭＬデータを解析して操作画面を生成し、画面表示部３３４は解析部３３２によって生成された操作画面を操作部２１９に表示する。

Ｓ１００５にて、状態通知受信部３３３は、状態通知（エラー発生通知５０５またはジョブ完了通知７００）をサービスプロバイダ３４０から受信する。

Ｓ１００６にて、状態通知受信部３３３は、サービスプロバイダ３４０の状態監視部３４３から受信した状態通知に含まれるＨＴＭＬデータを解析部３３２に転送する。そして、画面表示部３３４は、解析部３３２が解析したＨＴＭＬの解析結果に基づいて生成された簡易画面を操作部２１９に表示する。本実施形態における簡易画面とは、図６（ｃ）に示すように、例えば単にエラーが発生したことを通知する画面や、図８（ｃ）のように、単にジョブが完了したこと通知する画面などである。ただし、図６（ｃ）や図８（ｃ）のような簡易的な画面でなく、より詳細な画面を表示するようにしてもかまわない。

Ｓ１００６によれば、エラー発生時に、即座にユーザにエラーの発生を通知することが可能となる。例えば、ＭＦＰの処理中にエラーが発生したにも関わらずエラー画面が何も表示されない、といった事態を避けることが可能であり、ユーザを困惑させずに済む。

あるいはジョブの完了時には、即座にジョブの完了を通知することが可能である。例えば、ジョブが完了したことを通知されたユーザは、次の操作画面（図８（ｄ））が表示されるのを待つ必要はなく、図８（ｃ）の簡易画面が操作部２１９に表示された時点でＭＦＰ１０１の前から立ち去ることも可能である。

Ｓ１００７にて、状態通知受信部３３３は、サービスプロバイダ３４０の状態監視部３４３から転送されたＵＲＬ５０８を受信する。このＵＲＬ５０８は、エラー状態に対する図６（ｄ）の操作画面、あるいは、ジョブの実行が完了に対する図８（ｄ）の操作画面のＨＴＭＬデータの格納場所が示されている。

Ｓ１００８にて、通信部３３１は、状態通知受信部３３３が受信したＵＲＬ５０８に基づき操作画面を要求するため、Ｗｅｂサーバ１０２へリクエスト５０９を送信する。

Ｓ１００９にて、通信部３３１は、操作画面を要求するリクエスト５０９に対するレスポンス５１０をＷｅｂサーバ１０２の画面提供部３１１から受信する。そして、解析部３３２は、レスポンス５１０に含まれるＨＴＭＬデータを解析する。次に、画面表示部３３４は、解析部３３２が解析したＨＴＭＬデータの解析結果に基づいて、検知した処理状態に対する操作画面を操作部２１９に表示する。Ｓ８１２にて表示する操作画面は、Ｓ８１２にて表示される簡易画面よりも詳細なメッセージが記述された画面であることが好ましい。例えば、エラーに対する画面である場合には、エラーなどの異常状態から正常状態に復帰させるためのガイダンスが記述されている画面であったり、エラーの内容がより詳細に示された画面であったりすることが好ましい。このことによって、ＭＦＰ１０１で表示する画面を外部のＷｅｂサーバ１０２から取得でき、より詳細な画面を表示させることが可能である。またＷｅｂサーバ上で容易にカスタマイズされた操作画面をＭＦＰ１０１で表示させることが可能である。

以上の通り、本実施形態によれば、ＭＦＰ１０１の処理の状態が変化した場合、Ｗｅｂブラウザ３３０は、画面情報管理部３４４によって管理されている画面を操作部２１９に表示し、その後、Ｗｅｂサーバ１０２から受信する画面情報に基づき処理状態の変化に対する操作画面を表示する。この結果、ユーザは処理状態の変化を即座に把握できるとともに、処理状態の変化に対して行うべき操作方法などが示された詳細な画面情報をＷｅｂサーバから取得することもできる。

なお、実施例１においては、処理状態の変化の一例として、エラーが発生した場合、及びジョブが完了した場合について説明した。しかし本実施形態における処理状態の変化は、前述の状態変化に限定されるものではない。例えば、サービスプロバイダ３４０の処理が、スキャンからプリント、プリントから送信といった変化するような場合でもよい。

なお、実施例１においては、画面情報管理部３４４が管理する画面情報は、コラム「状態」に応じて複数の画面情報を記憶していた。しかし、単にエラーが発生したことを通知するだけであれば、複数の画面情報をそれぞれの処理状態に関連付けて記憶する必要はない。この場合、単にエラーが発生したことを示すエラー画面を表示する画面情報のみを管理すればよい。

その他の変形例として、エラー画面やジョブ完了画面などの簡易画面をＷｅｂブラウザ３３０が表示するのではなく、サービスプロバイダ３４０自身が表示する形態も考えられる。この場合には、サービスプロバイダ３４０は、Ｗｅｂブラウザ３３０の画面表示部３３４とは別個の画面表示部を備えている。これにより、状態通知及び画面情報をＷｅｂブラウザ３３０に送信する必要がなくなり、より迅速に簡易画面を表示することができる。

次に実施例２について説明する。実施例１では、サービスプロバイダ３４０の処理の状態が変化した場合、ＭＦＰ１０１のサービスプロバイダ３４０は、状態通知とともに画面情報（ＨＴＭＬデータ）をＷｅｂブラウザ３３０に送信していた。しかし実施例２においては、サービスプロバイダ３４０は状態通知のみを送信することを特徴とする。そしてＷｅｂブラウザ３３０は、自身が保持する画面情報に基づき簡易画面を表示することを特徴とする。

図１１を参照して実施例２における画像処理システムのソフトウェア構成について説明する。実施例１と異なるのは、実施例１ではサービスプロバイダ３４０が備えていた画面情報管理部３４４をＷｅｂブラウザ３３０内に配している点である。それ以外のソフトウェア構成については図３と実質的に同一であり、説明は省略する。また、実施例２において、ＭＦＰ１０１、Ｗｅｂサーバ１０２のハード構成は図２に示すものと同一である。

図９のフローチャートを参照して、ＭＦＰ１０１のサービスプロバイダ３４０が行う処理について、実施例１と異なる部分についてのみ説明する。実施例２において、サービスプロバイダ３４０の状態監視部３４３は、図９のフローチャートのＳ９０５にて、状態通知とともに簡易画面を表示するためのＨＴＭＬデータを送信せずに、状態通知のみを送信する。

図１０のフローチャートを参照して、ＭＦＰ１０１のＷｅｂブラウザ３３０が行う処理について、実施例１と異なる部分についてのみ説明する。Ｓ１００５にて、状態通知受信部３３３は、状態通知を受信すると、状態通知に記述された状態に対応する画面情報（ＨＴＭＬデータ）を、画面情報管理部３４４によって管理されるＨＤＤ２１４から取得する。このように、実施例２によれば、簡易画面を表示するための画面情報をＷｅｂブラウザ３３０自身が記憶する。この結果、状態監視部３４３が状態通知とともに画面情報を送信する必要がなくなり、より迅速に簡易画面を表示することができる。

次に実施例３について説明する。実施例１では、ＭＦＰ１０１は簡易画面を表示した後に、Ｗｅｂサーバ１０２から受信した画面情報に基づく操作画面を表示していた。実施例３では、エラーが発生した場合において、簡易画面を表示した後にエラーから復帰した場合の処理について説明する。なお実施例３は、実施例１、２において、エラーが発生した場合に特化した実施形態である。

実施例３における画像処理システムのハードウェア構成及びソフトウェア構成については実施例１と同様であるため説明は省略する。

ここで例えば、ユーザがエラーに対するリカバリ処理を行うことにより、ＭＦＰ１０１がエラーから復帰した場合を考える。例えばスキャナ２２１の読み取りエラーの場合には、不図示のフィーダに詰まった用紙を取り除くことによりエラーから復帰する。また別の例として、プリンタ２２０によるプリントジョブを実行中においてトナー不足のエラーの場合にはトナーを補給することによりエラーから復帰する。

このようにエラーから復帰した状態で、Ｗｅｂサーバ１０２からエラーに対応する操作画面のＵＲＬ（あるいは画面情報）を受信したとしても、ＭＦＰ１０１はエラー画面を表示する必要はない。

そこで本実施形態では、エラーが発生した場合の処理について詳しく説明する。図１２は、実施例３におけるＷｅｂブラウザ３３０、Ｗｅｂサーバ１０２、及びサービスプロバイダ３４０のそれぞれの動作について示すシーケンス図である。サービスプロバイダ３４０の処理実行中にエラーが発生してからエラー発生通知を送信するところまで（図１２の５００から５０６）は、図５のシーケンス図と同様である。

サービスプロバイダ３４０は、エラー復帰を検知すると、エラーから復帰したことを示す通知であるエラー復帰通知１２００をＷｅｂブラウザ３３０に送信する。Ｗｅｂブラウザ３３０はエラー復帰通知１２００を受信すると、キャッシュされて保持されているデータを参照して、図６（ｃ）に示すようなエラー画面を表示する前に表示していた操作画面を表示する。あるいは、再度リクエスト５００を送信することによりレスポンス５０１を受信し操作画面を表示する。サービスプロバイダ３４０は、Ｗｅｂサーバ１０２から受信したＵＲＬ５０７を、Ｗｅｂブラウザ３３０に転送せず、受信したＵＲＬの無効化を行う。具体的には、受信したＵＲＬ５０７を破棄する。更に、サービスプロバイダ３４０は、エラーの発生によって一時停止していたジョブの実行を再開するようＭＦＰ１０１を制御する。また、発生したエラーの種類によってはジョブの少なくとも一部の処理を実行し直すといったリカバリ処理が必要になる場合もある。サービスプロバイダ３４０はエラーから復帰した場合に、必要に応じてリカバリ処理を実行する。

図１３を参照して、実施例３においてＭＦＰ１０１のサービスプロバイダ３４０が行う処理について説明する。図１３のフローチャートに示す各動作は、ＣＰＵ２１１がＲＯＭ２１２に格納されたプログラムを実行することにより実現される。

Ｓ１３０１及びＳ１３０２の処理は、図９のＳ９０１及びＳ９０２の処理と同様である。

Ｓ１３０３にて、状態監視部３４３は、エラーが発生したことを検知する。エラーの発生を検知すると、Ｓ１３０４にて、状態監視部３４３は、Ｗｅｂブラウザ３３０の状態通知受信部３３３にエラー発生通知５０５を送信する。

なお、ＭＦＰ１０１がジョブを実行する場合、必ずエラーが発生するわけではないので、Ｓ１０３の処理が必ず行われるわけではないが、ここでは、エラーが発生した場合を想定して説明する。なお、図１３のフローチャートには図示しないが、Ｓ１３０３にてエラーではなく正常にジョブが終了したことを検知した場合には、図９のフローチャートにおけるＳ９０４〜Ｓ９０７に従った処理を行う。Ｓ９０４にて状態通知（ジョブ完了通知７００）をＷｅｂブラウザ３３０の状態通知受信部３３３に送信する。Ｓ９０５にて、通信部３４１は、レスポンス７０１（状態完了通知）をＷｅｂサーバ１０２の実行指示部３１２に送信する。Ｓ９０６にて、Ｗｅｂサーバ１０２の実行指示部３１２からＵＲＬ５０７を受信すると、Ｓ９０７にてＵＲＬ５０８をＷｅｂブラウザ３３０に転送する。

Ｓ１３０５にて、サービスプロバイダ３４０の通信部３４１は、レスポンス５０６をＷｅｂサーバ１０２の実行指示部３１２に送信する。Ｓ１３０６にて、状態監視部３４３は、エラーが復帰したことを検知した場合には、Ｓ１３０７にてエラー復帰通知１２００をＷｅｂブラウザ３３０へ送信する。

Ｓ１３０７にて、ジョブ生成部３４２は一時停止していたジョブを再開する。そして、再開したジョブが正常に終了したことを検知した場合には、Ｓ１３０３にて正常にジョブが終了したことを検知した場合と同様に、図９のフローチャートにおけるＳ９０４〜Ｓ９０７に従った処理を行う。

Ｓ１３０８にて、サービスプロバイダ３４０は、エラー復帰通知１２００をＷｅｂブラウザ３３０へ送信する。

Ｓ１３０９にて、通信部３４１はＷｅｂサーバ１０２の実行指示部３１２からＵＲＬ５０７を受信すると、Ｓ１３１０にて状態監視部３４３はそのＵＲＬの無効化処理を行う。具体的には、受信したＵＲＬの破棄を行う。

Ｓ１３０６でＮｏの場合、すなわち状態監視部３４３がエラーからの復帰を検知しない場合はＳ１３１１に進む。Ｓ１３１１にて、通信部３４１はＷｅｂサーバ１０２の実行指示部３１２からＵＲＬ５０７を受信したか否かを判定する。ＵＲＬ５０７を受信したと判断された場合はＳ１３１２に進み、そうでない場合はＳ１３０６に戻る。Ｓ１３１２にて、状態監視部３４３は通信部３４１によって受信されたＵＲＬ５０７をＷｅｂブラウザ３３０の状態通知受信部３３３に転送する。

図１４を参照して、実施例３におけるＭＦＰ１０１のＷｅｂブラウザ３３０が行う処理について説明する。図１４のフローチャートに示す各動作は、ＣＰＵ２１１がＲＯＭ２１２に格納されたプログラムを実行することにより実現される。図１４のフローチャートは、図１０のフローチャートで説明したＷｅｂブラウザ３３０がエラー画面を出した後に、エラーから復帰した場合の処理である。Ｓ１４０１〜Ｓ１４０４までの処理については、図１０のＳ１００１〜Ｓ１００４と同様である。

Ｓ１４０５にて、状態通知受信部３３３は、エラー発生通知５０５及び画面情報を受信する。

なお、図１４のフローチャートには図示しないが、Ｓ１４０５にてエラー発生通知５０５ではなく、ジョブ完了通知７００を受信した場合においては、図１０のフローチャートのＳ１００６〜Ｓ１００９に示す処理を行う。すなわち、Ｓ１００６にて、画面表示部３３４は、ジョブ完了通知７００とともに受信されたＨＴＭＬデータに基づき図８（ｃ）の画面を表示する。Ｓ１００７にて、状態通知受信部３３３は、サービスプロバイダ３４０から転送されたＵＲＬ５０８を受信する。Ｓ１００８にて、通信部３３１はＵＲＬ５０８によって特定される操作画面を要求する。Ｓ１００９にて、画面表示部３３４は、図８（ｄ）に示す画面を表示する。

Ｓ１４０５にてエラー発生通知５０５を受信すると、Ｓ１４０６にて、画面表示部３３４は、エラー発生通知５０５とともに受信した画面情報に基づき図６（ｃ）の簡易画面を表示する。

Ｓ１４０７にて、状態通知受信部３３３は、サービスプロバイダ３４０からエラー復帰通知１２００を受信したか否かを判定する。エラー復帰通知１２００を受信した場合Ｓ１４０８に進む。Ｓ１４０８にて、状態通知受信部３３３は、エラーが発生する前に画面表示部３３４が操作部２１９に表示していた操作画面を表示するよう画面表示部３３４に指示する。画面表示部３３４は、キャッシュされて保持されているデータを参照し操作画面を表示する。キャッシュされて保持されているデータがない場合には、通信部３３１はリクエスト５０２を再送し、レスポンス５０３をＷｅｂサーバ１０２から受信する。画面表示部３３４はレスポンス５０３に含まれる画面情報に基づき操作画面を表示する。以上のようにして、Ｗｅｂブラウザ３３０はエラーが発生する前に画面表示していた画面を表示する。

Ｓ１４０７にてＮｏの場合、すなわち状態通知受信部３３３がエラー復帰通知１２００を受信しない場合はＳ１４０９に進む。Ｓ１４０９にて、状態通知受信部３３３は転送されたＵＲＬ５０８を受信したか否かを判定する。受信した場合にはＳ１４１０に進み、そうでない場合にはＳ１４０７に戻る。Ｓ１４１０にて、通信部３３１は、転送されたＵＲＬ５０８に基づきＷｅｂサーバ１０２へリクエスト５０９を送信する。

Ｓ１４１１にて、図６（ｄ）の画面を表示する処理を行う。具体的には、通信部３３１は、リクエスト５０９に対するレスポンス５１０をＷｅｂサーバ１０２の画面提供部３１１から受信する。解析部３３２は、受信したレスポンス５１０に含まれるＨＴＭＬデータを解析する。画面表示部３３４は、解析部３３２の解析結果に基づいてエラーに対する操作画面を操作部２１９に表示する。

本実施形態によれば、サービスプロバイダ３４０は、エラーから復帰した場合、Ｗｅｂサーバ１０２から受信したＵＲＬをＷｅｂブラウザ３３０に転送しない。この結果、エラーから復帰してジョブが再開しているにも関わらずエラーに対する画面が表示されるようなことがない。

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

本発明は上記実施の形態に制限されるものではなく、本発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、本発明の範囲を公にするために以下の請求項を添付する。

１０１ ＭＦＰ
１０２ Ｗｅｂサーバ
３１０ Ｗｅｂアプリケーション
３３０ Ｗｅｂブラウザ
３４０ サービスプロバイダ

Claims (7)

1. 外部装置とネットワークを介して通信可能な画像処理装置であって、
   前記外部装置からの要求に応じてジョブを実行する実行手段と、
   前記実行手段が実行するジョブの状態の変化を検知する検知手段と、
   前記検知手段によって検知された状態の変化に対応する第１の画面を表示するための画面情報を記憶する記憶手段と、
   前記検知手段によって検知された状態の変化を前記外部装置に通知する通知手段と、
   前記通知手段による通知を受けた外部装置から、前記検知手段によって検知された状態の変化に対応する第２の画面を表示するための画面情報を受信する受信手段と、
   前記受信手段によって受信された画面情報に基づいて生成された第２の画面を操作部に表示する表示制御手段とを備え、
   前記表示制御手段は、前記検知手段によって状態の変化が検知された場合、少なくとも前記受信手段によって受信された画面情報に基づいて生成された第２の画面を表示する前に、前記記憶手段に記憶された画面情報に基づいて第１の画面を表示することを特徴とする画像処理装置。
2. 前記検知手段は、前記実行手段が実行するジョブの状態が正常状態からエラー状態へ変化することを検知することを特徴とする請求項１に記載の画像処理装置。
3. 前記表示制御手段は、前記検知手段によって前記ジョブの状態がエラー状態から復帰したことを検知された場合、前記外部装置から受信した画面情報に基づいて第２の画面を表示しないことを特徴とする請求項２に記載の画像処理装置。
4. 前記第１の画面は、前記実行手段が実行するジョブの状態がエラー状態であることをユーザに通知するための画面であり、前記表示制御手段によって表示される第２の画面は、前記ジョブの状態をエラー状態から正常な状態に復帰させるためにガイダンスする画面であることを特徴とする請求項２に記載の画像処理装置。
5. 前記検知手段は、前記ジョブが実行中の状態から実行が完了した状態へ変化したことを検知することを特徴とする請求項１に記載の画像処理装置。
6. 外部装置とネットワークを介して通信可能な画像処理装置の制御方法であって、
   前記外部装置からの要求に応じてジョブを実行する実行ステップと、
   前記実行ステップで実行するジョブの状態の変化を検知する検知ステップと、
   前記検知ステップで検知された状態の変化に対応する第１の画面を表示するための画面情報を記憶手段に記憶する記憶ステップと、
   前記検知ステップで検知された状態の変化を前記外部装置に通知する通知ステップと、
   前記通知ステップで通知を受けた外部装置から、前記検知ステップで検知された状態の変化に対応する第２の画面を表示するための画面情報を受信する受信ステップと、
   前記受信ステップで受信された画面情報に基づいて生成された第２の画面を操作部に表示する表示制御ステップとを有し、
   前記表示制御ステップでは、前記検知ステップで状態の変化が検知された場合、少なくとも前記受信ステップで受信された画面情報に基づいて生成された第２の画面を表示する前に、前記記憶手段に記憶された画面情報に基づいて第１の画面を表示することを特徴とする制御方法。
7. 請求項６に記載の制御方法を画像処理装置に実行させるためのコンピュータが読み取り可能なプログラム。

Images