JP2012014280A - 情報送信装置、情報送信装置の制御方法及びコンピュータプログラム - Google Patents

Abstract

【課題】 情報送信装置の表示部に表示される画面と共通の画面を外部装置において確認できるようにする。
【解決手段】 情報送信装置は、情報送信装置の情報を示すＷｅｂページであって、前記情報送信装置が備える表示部に表示される画面と共通の画面を示す画像データを含んだＷｅｂページを生成し、情報処理装置からの要求に応じて、前記生成されたＷｅｂページを当該情報処理装置に送信する。また、表示部に表示される画面が、関連する複数の画面のうちの１画面である場合、当該関連する複数の画面それぞれの画像データを取得し、その場合は、取得された複数の画面それぞれの画像データを含むＷｅｂページを生成する。
【選択図】 図６

Description

本発明は、自装置に関する情報を外部装置に送信する情報送信装置、その制御方法及びコンピュータプログラムに関する。

従来、Ｗｅｂサーバの機能を備えた画像処理装置が知られている。この画像処理装置は、画像処理装置のジョブ状況や画像処理装置が備える記憶装置に記憶されている画像データに関する情報をＷｅｂページとして生成する。そして、ネットワークを介して接続されたクライアントＰＣに送信することにより、クライアントＰＣのＷｅｂブラウザでこれらの情報を閲覧することができる（例えば特許文献１参照）。以後、このＷｅｂページをリモートＵＩと呼ぶ。このリモートＵＩを閲覧することで、ユーザは画像処理装置から離れた場所からでも該画像処理装置で実行されるジョブについての情報や画像データの情報を把握することができる。

一方、画像処理装置では、付随の操作パネル（以後これをローカルＵＩと呼ぶ）上の表示部に、画像処理装置のジョブ状況や、記憶されている画像データに関する情報が表示される。また、画像処理装置においてジャム等のエラーが発生したときには、エラー解消の手順が、ユーザのエラー解消作業に連動して画面遷移しながら表示部に表示される。

図３はローカルＵＩ上の表示部に表示される、ジャムエラーの解消手順を示したものである。まず、ローカルＵＩ上の表示部にて最初のエラー解消手順である図３（ａ）が表示される。次に、ユーザが前記表示された解消手順に従って画像処理装置の操作（エラー解消作業）を行うと、次の手順を示すべく図３（ｂ）がローカルＵＩ上の表示部に表示される。このようにユーザのエラー解消作業に連動してローカルＵＩ上の表示部に表示されるエラー解消手順の画面は図３（ａ）〜（ｄ）へと順次画面遷移していく。

特開２００２−００７０９５号公報

上述したように、従来、ジョブ状況や記憶される画像データに関する情報等の画像処理装置に関する情報をユーザが視認する方法として、ローカルＵＩとリモートＵＩがあった。しかしながら従来のリモートＵＩは、画像処理装置が備えるＷｅｂサーバがリモートＵＩ専用で用いられる画面を生成してブラウザに提供するものであった。そのため、ユーザはリモートＵＩから、画像処理装置の表示部に表示される画面と共通の画面や、エラー時に画像処理装置の表示部に表示されるエラー解消手順等の画面遷移そのものを見ることはできなかった。そして、ユーザは従来のリモートＵＩから、画像処理装置の表示部に現在表示されている画面そのものを把握できないために、エラー解消操作が的確に行われたか等の画像処理装置の状況を把握することも困難であった。

このように従来のリモートＵＩは、ローカルＵＩに表示される画面と共通の画面を表示するものではなかったために、ローカルＵＩに表示される画面と共通の画面を見たいユーザの要望には応えることができず、改善の余地があった。

そこで本願発明はこれらの問題点を解決できる装置を提供することを目的とする。

上記目的を達成するために本発明の情報送信装置は、情報送信装置の情報を示すＷｅｂページであって、前記情報送信装置が備える表示部に表示される画面と共通の画面を示す画像データを含んだＷｅｂページを生成する生成手段と、情報処理装置からの要求に応じて、前記生成手段によって生成されたＷｅｂページを当該情報処理装置に送信する送信手段と、前記表示部に表示される画面が、関連する複数の画面のうちの１画面である場合、当該関連する複数の画面それぞれの画像データを取得する取得手段とを有し、前記生成手段は、前記取得手段によって取得された複数の画面それぞれの画像データを含むＷｅｂページを生成することを特徴とする。

本発明により、装置の表示部に表示される画面と共通の画面を、離れた場所にある装置で確認することができるようになる。また、装置の表示部に表示される一連の画面遷移を、離れた場所にある装置で確認することができるようになる。

本実施例におけるシステム構成を説明する図である。 本実施例における画像処理装置のコントロールユニットの構成を説明するブロック図である。 本実施例における画像処理装置の表示部に表示される画面の例を示す図である。 本実施例における画像処理装置のソフトウェアモジュールの構成を示す図である。 本実施例におけるコンピュータと画像処理装置との間でのデータ処理手順の一例を示すフローチャートである。 図５のステップＳ５０９でのＣＧＩプログラム処理の処理手順を示すフローチャートである。 本実施例の画像処理装置に格納される画面情報テーブルの一例である。 本実施例における画像処理装置から送信されたＷｅｂページのＷｅｂブラウザでの表示例である。 図５のステップＳ５０９でのＣＧＩプログラム処理の処理手順を示すフローチャートである。 本実施例における画像処理装置から送信されたＷｅｂページのＷｅｂブラウザでの表示例である。 本実施例における画像処理装置から送信されたＷｅｂページのＷｅｂブラウザでの表示例である。

以下、本発明を実施するための形態について、図面を参照して説明する。

（第一の実施形態）
図１は、本発明を適用した一例である第１実施形態におけるシステム構成を示した図である。

図１において、画像処理装置２００は、スキャナ部２０７０、プリンタ部２０９５、コントロールユニット（Ｃｏｎｔｒｏｌｌｅｒ Ｕｎｉｔ）２０００、ローカルＵＩとしての表示・操作部２０１２から構成される。

画像処理装置２００のスキャナ部２０７０、プリンタ部２０９５、給紙部２１００、排紙部２１１０、表示・操作部２０１２は、それぞれコントロールユニット２０００に接続されている。コントロールユニット２０００は、ＬＡＮ２０１１などのネットワーク伝送手段に接続されている。

コントロールユニット（Ｃｏｎｔｒｏｌｌｅｒ Ｕｎｉｔ）２０００は、画像入力デバイスであるスキャナ部２０７０や画像出力デバイスであるプリンタ部２０９５と接続している。また、用紙などの給紙を行う給紙部２１００やプリントした用紙の排紙を行う排紙部２１１０と接続されている。給紙部２１００は不図示の複数の給紙段やインサーター等を含む。また、排紙部２１１０は不図示の複数の排紙ビンを備えたフィニッシャや製本機能を備えたフィニッシャなどオプション類を含む。

ローカルＵＩとしての表示・操作部２０１２は、ユーザとの操作インタフェースとして、装置本体の状態やジョブの情報等を表示する表示部を備えている。この表示部は、タッチパネル機能を備える。さらに、画像処理装置２００のステータスを示すＬＥＤ、ハードキーボタンキーなどを備えている。ユーザは表示・操作部２０１２に表示された情報により、画像処理装置のエラー状態等を知ることが可能となる。また、タッチパネルにより表示・操作部２０１２に表示された操作メニューボタンを押下し、また、ハードキーボタンを押下して画像処理装置２００を操作することが可能である。本実施例において画像処理装置２００は、クライアントＰＣからの要求に応じて該要求された情報をクライアントＰＣに送信する情報送信装置として動作する。尚、情報送信装置は、要求された情報を送信する機能を備えていればよく、プリンタ、スキャナ、複写機、ファックス等の画像処理装置に限定されるものではなく、その他の装置を含むものである。

コンピュータ１１は、不図示の表示装置，キーボード，ポインティングデバイス，コンピュータ本体とを含む。また、コンピュータ本体に内蔵される記憶装置からオペレーティングシステムをＲＡＭ上にロードして、各種のアプリケーションプログラムを実行する機能を有する。さらには、不図示のネットワークインターフェースによってネットワークを介して画像処理装置２００と通信可能であり、該通信により取得した情報を表示装置に表示することができる。また、いわゆるＷｅｂブラウザが記憶装置に記憶されており、コンピュータ１１はＷｅｂブラウザが動作可能に構成されている。このＷｅｂブラウザにより後述するＷｅｂサーバとして動作可能な画像処理装置２００と所定のプロトコルで通信可能になり、リモートＵＩを表示装置に表示できる。コンピュータ１１は、情報送信装置に情報を要求し、取得した情報を表示するクライアントＰＣである情報処理装置として動作する。尚、本実施例では、情報処理装置の一例としてコンピュータ１１を用いて説明するが、携帯電話等のその他の端末であっても構わない。

図１では、これら画像処理装置２００とコンピュータ１１がＬＡＮ２０１１を介して互いに通信可能に接続されている。このシステムにおいて、コンピュータ１１が備えるＷｅｂブラウザから、情報の取得が画像処理装置２００に対して要求されると、画像処理装置２００は要求された情報をコンピュータ１１に送信する。尚、画像処理装置２００とコンピュータ１１の接続形態はＬＡＮに限らず、インターネットや無線通信、その他のあらゆる接続方法によっても本システムは実現可能である。また、図１では、コンピュータ１１と画像処理装置２００のみがＬＡＮ２０１１に接続されているが、その他の端末が接続されていても構わない。

次に、図１に示したコントロールユニット２０００のハードウェア構成を詳細に説明するブロック図を図２に示す。図１と同一のものには同一の符号を付してある。

図２において、ＣＰＵ２００１は、システム全体を制御するコントローラである。このＣＰＵ２００１は、プログラム用ＲＯＭ２００３とＨＤＤ２００４に記憶された制御プログラム等に基づいてシステムバス２００７に接続される各種デバイスとのアクセスを統括的に制御する。また、各種デバイスに命令を与えることで、印刷処理や、表示・操作部２０１２に表示する表示画面データを生成する処理を実行する。また、後述するＣＧＩプログラムに基づき、後述するリモートＵＩで表示するＷｅｂページの作成を行う。さらには、デバイスインタフェース２０２０を介して接続されるスキャナ部２０７０から入力情報を読み込む。また、デバイスインタフェース２０２０を介して接続されるプリンタ部２０９５に出力情報としての画像信号を出力する。

また、２００３はＲＯＭで、制御プログラム、ソフトウェアモジュール、例えば図６に示すフローに対応するＣＧＩプログラム等が格納されている。このＣＧＩプログラムに基づき、各種情報の処理や演算、各種デバイスの制御等を行い、リモートＵＩで表示するＷｅｂページの作成を行う。また、システムのブートプログラムも格納し、ブートＲＯＭとしても機能する。

２００２はＲＡＭで、ＣＰＵ２００１が動作するためのシステムワークメモリであり、画像データや後述する画面情報テーブル等を一時記憶するためのメモリでもある。

２００４はハードディスクドライブ（ＨＤＤ）で、システムソフトウェア、表示・操作部２０１２に表示するためのリソースとなる表示データの画像データやメッセージデータ等を格納する。また、後述するＷｅｂページを生成するためのリソースファイルやテンプレートファイル等を格納する。

さらに、本画像処理装置のＨＤＤ２００４などの記憶装置には画面情報を規定した画面情報テーブルが格納されている。画面情報テーブルの一例を図７を用いて説明する。この画面情報テーブルは、後述の図６の各ステップや必要に応じてＲＡＭ２００２に展開されてＣＰＵ２００１は参照することが可能になる。

図中７０１はエラーＩＤの一覧を示している。７０２は各エラーＩＤに紐づくエラー画面の数がいくつあるかを示している。さらに、７０３は実際に紐付けられた画面のＩＤをその画面数分だけ格納している。例えば、エラーＩＤがＥｒｒ１の場合、それに紐づく画面数は４つであり、それぞれに対応した画面ＩＤはＳｃｒｅｅｎ１、Ｓｃｒｅｅｎ２、Ｓｃｒｅｅｎ３、Ｓｃｒｅｅｎ４であることを示している。７０４は各画面ＩＤ一覧を示している。７０５は前述の各画面ＩＤを表示するのに必要な表示内容に関する情報、例えばリソースとなる画像データや位置情報、メッセージ内容やその他の情報が含まれている。従って、前述の７０３で記載されている各画面ＩＤに対する表示内容は、この７０４から７０５をたどっていくことで参照可能となる。このように、画面情報テーブルによって表示・操作部２０１２に画面遷移され表示される一連の画面遷移を規定することができる。

２００６は操作部Ｉ／Ｆで、表示・操作部２０１２とのインタフェース部として機能し、表示・操作部２０１２に含まれるタッチパネル上に表示されたメニューボタンや、ハードキー等から本システムのユーザが入力した情報を、ＣＰＵ２００１に伝える役割をする。

さらに、操作部Ｉ／Ｆ２００６は表示・操作部２０１２に含まれるハードキーやタッチパネルよりユーザ入力を受け取り、操作内容を取得する。

一方、ＣＰＵ２００１は操作部Ｉ／Ｆ２００６から取得した操作内容と前述の制御プログラムに基づいて、表示・操作部２０１２に表示する画面として表示画面データが生成され、ＶＲＡＭ２００９で表示画面データを保持する。このＶＲＡＭ２００９で保持された表示画面データは、この操作部Ｉ／Ｆ２００６を介して表示・操作部２０１２に表示画面を出力する。

２００９はＶＲＡＭであり、ＣＰＵ２００１で生成された表示画面データを保持するメモリである。ＨＤＤ２００４から取得した表示データをＣＰＵ２００１は表示・操作部２０１２に表示するための画面として生成し、ＶＲＡＭ２００９は表示・操作部２０１２に表示されるように配置された画像データを保存するメモリである。

２０１０はネットワークインターフェース（ネットワークＩ／Ｆ）で、ＬＡＮ２０１１に接続し、情報の入出力を行う。２０５０はモデム（Ｍｏｄｅｍ）で、公衆回線２０５１に接続し、情報の入出力を行う。画像処理装置２００はネットワークＩ／Ｆ２０１０を介してＬＡＮ２０１１や公衆回線（ＷＡＮ）２０５１と接続することで、外部装置と画像情報やデバイス情報の入出力を行う。以上のデバイスがシステムバス２００７上に配置される。

２００５はイメージバスＩ／Ｆ（Ｉｍａｇｅ Ｂｕｓ Ｉ／Ｆ）で、システムバス２００７と画像データを高速で転送する画像バス２００８を接続し、データ構造を変換するバスブリッジである。

２００８は画像バスで、ＰＣＩバスまたはＩＥＥＥ１３９４で構成される。画像バス２００８上には以下のデバイスが配置される。

２０６０はラスタイメージプロセッサ（ＲＩＰ）で、ＰＤＬコードをビットマップイメージに展開する。

２０２０はデバイスＩ／Ｆ部で、本装置の各デバイスの画像入出力デバイスであるスキャナ部２０７０やプリンタ部２０９５とコントロールユニット２０００を接続し、各デバイスの状態の識別や画像データの同期系／非同期系の変換を行う。さらには、用紙などの給紙を行う給紙部２１００やプリントした用紙の排紙を行う排紙部２１１０と接続され、用紙の給紙や排紙の状況や状態はもちろん、接続デバイスのエラー情報や消耗品の残量の識別や検知なども行う。

２０８０はスキャナ画像処理部で、入力画像データに対し補正、加工、編集を行う。２０９０はプリンタ画像処理部で、プリント出力画像データに対して、プリンタの補正、解像度変換等を行う。

２０３０は画像回転部で、画像データの回転処理を行う。２０４０は画像圧縮部で、多値画像データはＪＰＥＧ、２値画像データはＪＢＩＧ、ＭＭＲ、ＭＨの圧縮伸長処理を行う。

続いて、本実施形態に係る本画像処理装置のＲＯＭ２００３あるいはＨＤＤ２００４に記録されており、適宜ＲＡＭ２００２にロードされＣＰＵ２００１で実行される各種のソフトウェアモジュールを図４のブロック図を用いて説明する。

図４において、１５０１はユーザーインターフェース（ＵＩ）を司るものであり、オペレータが本画像処理装置の表示・操作部２０１２を用いて本画像処理装置に対する各種操作・設定を行う際、機器との仲介を行うモジュールである。本モジュールは、オペレータの操作に従い、操作部Ｉ／Ｆ２００６を介して後述の各種モジュールに入力情報を転送し処理の依頼、或いはデータの設定等を行う。

１５０２はＷｅｂ−Ｓｅｒｖｅｒモジュールであり、ＬＡＮ２０１１に接続されたＷｅｂクライアントからの要求により、Ｗｅｂクライアントに情報を表示可能にする表示データの生成のために使用される。また、複合画像処理を行う管理情報やジョブ状況等の画像処理装置に関する情報を通知するために使用される。前述のＷｅｂクライアントからの要求は、ネットワークＩ／Ｆ２０１０を介して本画像処理装置に通知される。一方画像処理装置の管理情報は、後述のＣｏｎｔｒｏｌｌ−ＡＰＩ１５０６を介して読み取られる。そして、後述のＨＴＴＰ１５０３、ＴＣＰ／ＩＰ１５０４、Ｎｅｔｗｏｒｋ−Ｄｒｉｖｅｒ１５０５を介し、ネットワークＩ／Ｆ２０１０を介して本画像処理装置に接続されたＷｅｂクライアントに通知される。

Ｗｅｂ−Ｓｅｒｖｅｒモジュール１５０２は、いわゆるＷｅｂページ形式データを後述のＣＧＩプログラム等を用いて作成する。生成されるＷｅｂページ形式データは、画像を含むオブジェクト、テキスト等の情報を、Ｗｅｂクライアントに表示可能にする表示データであり、例えばＨＴＭＬ形式のデータである。Ｗｅｂ−Ｓｅｒｖｅｒモジュール１５０２によって、本画像処理装置はクライアントである情報処理装置に情報の送信、提供を可能とする情報送信装置として動作する。

１５０３はＨＴＴＰモジュールで、本複合型の画像処理装置がＨＴＴＰにより通信する際に使用され、後述のＴＣＰ／ＩＰモジュール１５０４により前述のＷｅｂ−Ｓｅｒｖｅｒモジュール１５０２に通信を提供するものである。

１５０４はＴＣＰ／ＩＰ通信モジュール（ＴＣＰ／ＩＰモジュール）であり、前述の各種モジュールに後述のＮｅｔｗｏｒｋ−Ｄｒｉｖｅｒによりネットワーク通信を提供するものである。１５０５はＮｅｔｗｏｒｋ−Ｄｒｉｖｅｒであり、ネットワークに物理的に接続されるネットワークＩ／Ｆ２０１０を制御するものである。

１５０６はＣｏｎｔｒｏｌｌ−ＡＰＩであり、上流モジュールに対し、下流モジュールとのインタフェースを提供する。これにより上流、及び下流のモジュール間の依存関係が軽減され、それぞれの流用性を高めることが可能となる。

１５０７はＪｏｂ−Ｍａｎａｇｅｒであり、前述の各種モジュールよりＣｏｎｔｒｏｌｌ−ＡＰＩ１５１８を介して指示される処理を解釈し、各モジュールに指示を与えるものである。また、本モジュールは、本複合型の画像処理装置内で実行されるハード的な処理を一元管理するジョブ制御部として機能するものである。この場合、必要に応じてイメージバスＩ／Ｆ２００５を介して各種処理部との情報の受け渡しを制御することも可能である。

以上の構成よりなる実施例の動作説明を図面などを参照して説明する。特に、本実施形態に係る画像処理装置における特徴的な機能であるリモートＵＩについて説明する。

リモートＵＩは、本装置外部から装置の状態等の情報を取得・設定、またはプリントや送信（Ｕｎｉｖｅｒｓａｌ−Ｓｅｎｄ）等の動作を行わせるためのユーザインターフェースを提供する機能である。リモートＵＩは、そのために外部装置に表示される表示画面そのものを意味することもできる。ユーザはネットワークに接続されたコンピュータから、Ｗｅｂブラウザを利用して本装置にアクセスすることによりリモートＵＩの機能を使用することができる。

図４に示したように、本装置内部ではＷｅｂ−Ｓｅｒｖｅｒモジュール１５０２が稼動しており、これによりＨＴＴＰ（Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）による通信が可能となっている。Ｗｅｂ−Ｓｅｒｖｅｒモジュール１５０２ではクライアントからの要求により起動されるＣＧＩ（Ｃｏｍｍｏｎ Ｇａｔｅｗａｙ Ｉｎｔｅｒｆａｃｅ）プログラムを動作させることができる。

なお、図２に示したＨＤＤ２００４中にはリソースファイル群、ページのテンプレートファイル群が格納されており、これらがリモートＵＩにおいて使用される。リソースファイルは、ページ表示に用いられるＨＴＭＬ（Ｈｙｐｅｒ Ｔｅｘｔ Ｍａｋｅ ｕｐ Ｌａｎｇｕａｇｅ）ファイルや画像ファイルなどである。なお、ＨＴＭＬファイルに限れられるものではなく、そのほかにも、リソースに関する情報を示す画面を表現する表示データであって、その他の言語で書かれたファイルでもよい。また、テンプレートファイルは、ＣＧＩプログラムから参照されページを作成するのに用いられるファイルである。

本装置にアクセスするために、ユーザはＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）を直接Ｗｅｂブラウザに入力するか、該ＵＲＬが埋め込まれたリンクを選択する。Ｗｅｂブラウザは、オペレータによって入力されたＵＲＬを指定するＨＴＴＰコマンドをネットワークを介して送信する。

Ｗｅｂ−Ｓｅｒｖｅｒモジュール１５０２は、このＨＴＴＰコマンドを受け取り、そのＨＴＴＰコマンドを解析し、それに応じた動作を行う。この動作には例えばＨＴＴＰコマンドの要求に従って、画像処理装置の情報の設定、取得、プリント出力等を本体に指示する。さらには、前述のテンプレートファイルよりその要求に応じたＷｅｂページを作成し、クライアントのＷｅｂブラウザに送信する。

また、Ｗｅｂブラウザは、画像処理装置から返されたＷｅｂページを表示する。こうしてコンピュータを操作するユーザは、Ｗｅｂブラウザを利用して装置にアクセスすることにより、画像処理装置に関する機能・状態・保持情報を取得および設定することが可能となる。また画像処理装置を操作することが可能となる。また、リモートＵＩの表示データがＨＴＭＬデータによって提供されることにより、コンピュータは、リモートＵＩを表示するために専用のソフトウェアを必要とせず、Ｗｅｂブラウザのような汎用的なソフトウェアがあればよい。

リモートＵＩの基本動作について図５でさらに説明する。

図５は、本実施形態に係るＷｅｂクライアント（ブラウザ）側であるコンピュータ１１とＷｅｂサーバ側である画像処理装置２００との間でのデータ処理手順の一例を示すフローチャートである。

Ｓ５０１〜Ｓ５０４とＳ５１２はコンピュータ１１で実行される処理を示し、Ｓ５０５〜Ｓ５１１、Ｓ５１３，Ｓ５１４は画像処理装置２００で実行される処理を示す。また、フロー中の破線で示される矢印は情報の送受信を示す。尚、Ｓ５０１〜Ｓ５１４の各ステップは、コンピュータ１１又は画像処理装置２００が備えるＣＰＵが、ＲＯＭ等のメモリに保持されたプログラムをＲＡＭに展開して実行することによって処理される。

まずコンピュータ１１側の処理を説明する。コンピュータ１１のフローは、Ｗｅｂブラウザがユーザの入力を受け付けるところからスタートする。まず、ステップＳ５０１で、ユーザからのＵＲＬの入力を待ち、ＵＲＬ等が入力された場合は、ステップＳ５０２に進む。ステップＳ５０２において、Ｗｅｂブラウザを実行しているコンピュータ１１は入力されたＵＲＬを指定したＨＴＴＰコマンドをＬＡＮ２０１１等の通信路を介して画像処理装置２００に送信する。このＨＴＴＰコマンドは、入力されたＵＲＬに対応するＨＴＭＬデータを要求するためのコマンドである。ステップＳ５０１で入力がない場合は再びＳ５０１で入力の受付待ちを行う。

次にコンピュータ１１は、ステップＳ５０３で画像処理装置２００からの返信を受け付けるべくＨＴＴＰレスポンスの受信を待つ。このＨＴＴＰレスポンスには、ステップＳ５０２のＨＴＴＰコマンドで指定したＵＲＬに対応するＨＴＭＬデータが含まれている。ステップＳ５０３でＨＴＴＰレスポンスを受信すると、ＷｅｂブラウザはＨＴＴＰレスポンスに含まれるＨＴＭＬデータを解釈する。そして、画像データ等へのリンクがあるか否かを判断することによって、ＨＴＭＬ文書を整形し表示する際にデータの要求が必要であるか否かを判断する。Ｗｅｂブラウザは、ＨＴＭＬ文書を整形表示する際にデータの要求が必要と判断された場合、ステップＳ５１２において、画像処理装置２００側に画像データ等のデータを要求する。そして必要なデータを取得した後、ステップＳ５０４に進み、ＷｅｂブラウザはＨＴＭＬ文書を整形して表示する。そして一つのセッションを終了する。尚、Ｓ５０３で受信したＨＴＭＬ文書を整形して表示する際に、リンクされた画像データ等がなく、データの要求が必要ない場合には、Ｓ５１２の処理は省略され、Ｓ５０４へと進む。

画像処理装置２００では、コンピュータ１１からのＨＴＴＰコマンドを待機する処理から開始される。ステップＳ５０５で、ＣＰＵ２００１は、ネットワークＩ／Ｆ２０１０を介してＨＴＴＰコマンドが受信されたと判断するとステップＳ５０６に進む。

ステップＳ５０６ではＣＰＵ２００１はＷｅｂブラウザからの要求がＣＧＩプログラムの起動要求であるか否かを判断する。ＣＧＩプログラムの起動要求であった場合は、ステップＳ５０７でＣＰＵ２００１はＣＧＩパラメータの解析を行い処理すべきＣＧＩプログラムを確定する。そしてパラメータをＲＡＭ２００２に記憶する。その後ステップＳ５０８に進み、該当のＣＧＩプログラムを起動する。

次にステップＳ５０９でＣＰＵ２００１はＣＧＩプログラムの処理を行う。そして、ステップＳ５１１で、前述のステップＳ５０９で処理された結果を、ＨＴＴＰレスポンスとしてコンピュータ１１へ送信する。このＨＴＴＰレスポンスには、後述するＣＧＩプログラムの処理によって生成されたＨＴＭＬデータが含まれている。

ステップＳ５１３において、ＣＰＵ２００１はネットワークＩ／Ｆ２０１０を介してコンピュータ１１からデータの要求があるかを判断する。ステップＳ５１３において、コンピュータ１１からデータの要求があると判断した場合、ステップＳ５１４では要求されたデータを送信し、一つのセッションを終了する。また、ステップＳ５１３において、コンピュータ１１からデータの要求がないと判断した場合も一つのセッションを終了する。尚、Ｓ５１３におけるデータ要求の受信やＳ５１４におけるデータの送信は、複数回行われてもよい。

前記ステップＳ５０８のＣＧＩプログラムは、コンピュータ１１からの要求に応じて、装置情報の取得・設定や、プリント出力等の動作を本体（この場合、ＪＯＢＭａｎａｇｅｒ１５０７）に要求する。また、ＣＧＩプログラムはそのページに対応したテンプレートファイルを使って送信するＨＴＭＬページを作成していく。テンプレートファイル中には、取得された情報を用いて記述を変更する部分があり、これによりその時の状態に応じたページ内容を作成することができる。ページ内容の作成のために必要な画像生成指示等もこのＣＧＩプログラムの処理の中で行われる。

一方、ステップＳ５０６でＣＧＩプログラムの起動要求でない場合は、ステップＳ５１０で指定されたリソースファイルをレスポンスとして返信し、一つのセッションを終了する。

続いて、本実施の形態における前述の図５のステップＳ５０９でのＣＧＩプログラム処理の処理手順を図６に示すフローチャートを用いて説明する。図６の各ステップは、画像処理装置２００が備えるＣＰＵが、ＲＯＭ等のメモリに保持されたプログラムをＲＡＭに展開して実行することによって処理される。

まず、ステップＳ６０１でＣＰＵ２００１は前述の図５のステップＳ５０７で解析したパラメータを受け取る。次にステップＳ６０２に進み、ＣＰＵ２００１はパラメータまたは装置情報から、ローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要であるか否かを判断する。

本実施例では、ローカルＵＩとしての表示・操作部２０１２に表示されるエラー画面をキャプチャ画面としてキャプチャすることができる。またパラメータ内部にエラーＩＤ情報を含めても良い。その場合コンピュータ１１は、取得すべきエラーＩＤ情報をＨＴＴＰリクエストに含めて画像処理装置２００に送信することになる。ＣＰＵ２００１は、パラメータからエラーＩＤ情報を取得し、図７の画面情報テーブルからエラーＩＤ情報によって規定されている画面遷移からコンピュータ１１に表示させるべき画面遷移を特定する。

また、このエラーＩＤ情報は現在画像処理装置２００で発生しているエラーなので、デバイスＩ／Ｆ部２０２０から取得した装置の状態を示すエラー情報を元にＣＰＵ２００１が判断し決定されても良い。その際エラーＩＤはＲＡＭ２００２などへ記録される。後述するステップで必要なエラーＩＤはステップＳ６０１でパラメータとともにＲＡＭ２００２から取得する。そして、ＣＰＵ２００１は、ＲＡＭ２００２からエラーＩＤ情報を取得し、図７の画面情報テーブルを参照し、エラーＩＤ情報によって規定されている画面遷移の中から表示する画面遷移を特定する。

ステップＳ６０２でＣＰＵ２００１がローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要でないと判断した場合は、ステップＳ６０４に進み、該当のパラメータまたは装置情報に応じた処理を行う。例えば、画像処理装置２００でエラーが生じていない場合は、ローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成を必要とせず、ＣＰＵ２００１はエラーが生じていない旨を示すＷｅｂページのＨＴＭＬデータを作成し、処理を終了する。

このように、該当のパラメータまたは装置情報に応じてローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要か否かを判断する。従ってユーザが希望している場合やユーザにキャプチャ画面を見せる必要がある状況にのみローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成を行うことができ、ユーザにとってより使い易いリモートＵＩの提供が可能となる。

前記ステップＳ６０２でローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要と判断された場合は、ステップＳ６０３に進む。ステップＳ６０３でＣＰＵ２００１はＨＤＤ２００４に保持されている図７の画面情報テーブルをＲＡＭ２００９へ展開し、指示されたエラーＩＤに関連する画面の総数を取得する。ここで指示されたエラーＩＤに関連する画面とは、概エラーＩＤによって規定されたエラー解消操作手順を順に示した画面とすることができる。

次にステップＳ６０５に進みＣＰＵ２００１は前記ステップＳ６０３で取得した画面数が複数画面存在するか否かを判断する。即ち、現在ローカルＵＩに表示されている画面が、関連する複数の画面の中の１画面であるのかどうかを判断する。ステップＳ６０５で画面数が単数（１つ）である場合はステップＳ６０６に進み、ＣＰＵ２００１は現在表示・操作部２０１２で表示されている画面をキャプチャする。また、この現在表示されている画面は、実際にはＶＲＡＭ２００９に展開されていて、ＣＰＵ２００１がＶＲＡＭ２００９で保持した表示画面データを取得するものである。そしてステップＳ６０７へ進み、ＣＰＵ２００１はキャプチャ画面へのリンクを含んだＨＴＭＬデータを生成する。ここで、現在ローカルＵＩに表示されている画面は、画像処理装置２００における現在のエラー情報あるいはエラー解消手順が表示されていると見なすことが可能である。

次に前述のステップＳ６０５でエラーＩＤに基づくエラー解消手順を示す画面数が複数あると判断した場合、即ち現在表示されている画面が、関連する複数の画面のうちの１画面であると判断された場合は、ステップＳ６０８に進む。ステップＳ６０８では、ＣＰＵ２００１は現在のエラー情報（エラーＩＤ）に紐づく一連の画面情報を後述する図７の画面情報テーブルより取得する。そしてステップＳ６０９に進み、ＣＰＵ２００１はエラーＩＤによって規定された関連画面のリソースとしての画像データ等をＨＤＤ２００４から一つずつ順に呼び出し、キャプチャ画面を生成する。具体的にはＣＰＵ２００１が、呼び出した画像データやメッセージデータをＶＲＡＭ２００９に展開し、面面情報テーブルより取得した画面情報に基づき処理し、表示・操作部２０１２で表示する体裁の表示画面データを生成する。そしてＶＲＡＭ２００９で保持した表示画面データを取得し、ＲＡＭ２００２やＨＤＤ２００４に保持しておく。あるいは、ＶＲＡＭ２００９ではなく、ＲＡＭ２００２に直接に画像データやメッセージデータを展開しそれを取得、保持するといったことも可能である。このようにエラー情報（エラーＩＤ）に紐づく一連の画面情報を呼び出し、処理を進めることでキャプチャ画面の生成が可能となる。

次にステップＳ６１０に進み、ＣＰＵ２００１は前記Ｓ６０５で判断したキャプチャ画面の画面数分だけ処理が終わったか否かを判断する。まだ関連画面が残っていた場合はステップＳ６０９に戻りＣＰＵ２００１は同様に次の画面を呼び出しキャプチャ画面を生成する。

ステップＳ６１０で全ての画面について終了した場合は、ステップＳ６１１に進み、ＣＰＵ２００１はステップＳ６０９で順次生成され保持したキャプチャ画面データの一覧画像を含むＷｅｂページを生成する。具体的には、キャプチャ画面の一覧画像データへのリンクを含んだＨＴＭＬデータを生成する。

以上説明した処理によって、前述の図５のステップＳ５０９のＣＧＩプログラム処理でＨＴＭＬデータが生成される。生成されたＨＴＭＬデータは、ステップＳ５１１においてコンピュータ１１に送信される。そして、コンピュータ１１はステップＳ５０３でレスポンスを受信すると、必要ならばステップＳ５１２において、ＨＴＭＬデータに含まれるリンクによって指定されたデータの要求を画像処理装置２００に対して行う。その後、ステップＳ５０４に進み、ＨＴＭＬデータを整形してＷｅｂページを表示する。尚、本実施形態におけるＶＲＡＭ２００９は、実際にＬＵＩへ表示するための画面データだけでなく、ＲＵＩ用にキャプチャするための画面データを展開する領域を持っており、キャプチャ用の画面データはキャプチャ用の領域に展開され、この領域に展開された画面データはＬＵＩには表示されない。また、キャプチャ用の領域に展開された画面データは、その画面データに対応する現象（例えばエラー状態）が解消した場合に、その領域から削除されることになる。

本実施例による画像処理装置２００から送信されたＷｅｂページのＷｅｂブラウザでの表示例を図８に示す。この画面はコンピュータ１１の表示部にＷｅｂブラウザによって表示されるものである。

この図８では画像処理装置２００でエラーが発生したときにリモートＵＩから閲覧できるエラー情報に関するページの例を示している。リモートＵＩのトップページでインデックス領域８０１にはユーザが指示可能なメニューボタンが並んでいる。ここでエラー情報ボタン８０２を押す（クリック）ことにより、エラー情報ページを表示するべくＨＴＴＰコマンドが画像処理装置２００へ送信される（前述のステップＳ５０２）。これを受けた画像処理装置２００は要求を満たすように前述の図で説明したＣＧＩプログラム処理を行い、図８に示す表示内容を記述したＨＴＭＬデータを送信する。メイン領域５０５にはエラーが発生している旨を示す情報８０３、エラー情報詳細８０４を表示している。さらにはエラー解消手順１から手順４までを示すローカルＵＩのキャプチャ画面の一覧画像８０５を表示している。このキャプチャ画面の一覧画像８０５には、エラー解消手順１から手順４までの画像８０６、８０７、８０８、８０９が含まれている。

なお、本実施形態においてキャプチャ画面の一覧８０６、８０７、８０８、８０９を一つの画像データとして生成することもできる。この場合ステップＳ６０８において、関連画面のリソースとして画像データ等をＨＤＤから一つずつ順に呼び出した際に、ＣＰＵ２００１がそれらを一つの画像として画面生成し、その生成した画像データをＨＤＤ等の記憶装置に記憶しておけばよい。

このように第一実施形態では、画像処理装置のローカルＵＩで表示される画面と共通の画面をリモートＵＩによって確認することができる。これにより画像処理装置から離れた場所にあるコンピュータからでも、画像処理装置に現在表示されている画面を確認することができる。更に、画像処理装置のローカルＵＩで表示される一連の画面遷移を、リモートＵＩによってコンピュータ上で一覧表示できるため、画像処理装置から離れた場所にあるコンピュータからでも、ユーザは必要な情報の視認が容易になる。例えば、画像処理装置のローカルＵＩで表示されるエラー解消手順の一覧をコンピュータ上で表示できるので、ユーザはエラー解消手順を事前に確認することが出来る。また、一連の画面遷移を一覧表示できるためユーザにとって理解しやすい情報表示が可能となる。尚、「共通」とは、完全に同一であることを意味するだけでなく、若干の相違点があっても、実質的に同一であるとみなせるものを含むものとする。

（第二の実施の形態）
以下、本発明の第二の実施形態について説明する。第二の実施形態では、第一の実施形態と比較して、ローカルＵＩに表示される画面遷移のキャプチャ画面をリモートＵＩにて表示する際の表示方法が異なる。第一の実施形態では、複数のキャプチャ画面を一覧画像としてリモートＵＩに表示した。これに対して第二の実施形態では、リモートＵＩへのローカルＵＩの一画面づつ表示し、ユーザがリモートＵＩを操作して次画面（又は前画面）を表示させる指示をするのに応じて、該当するキャプチャ画面を表示する方法である。これにより、ユーザは一連の画面遷移に用いられるキャプチャ画面のどれを表示対象とするかが選択可能となる。

尚、第二の実施形態では、第一の実施形態に対して、図６のフローチャートで示す処理が異なるだけであるので、それ以外の重複部分についての説明は省略し、異なる部分を説明する。

図５のステップＳ５０９でのＣＧＩプログラム処理に関して、第二の実施形態で行われる処理を図９に示すフローチャートを用いて説明する。図６の各ステップは、画像処理装置２００が備えるＣＰＵが、ＲＯＭ等のメモリに保持されたプログラムをＲＡＭに展開して実行することによって処理される。

まず、ステップＳ９０１でＣＰＵ２００１は前述の図５のステップＳ５０７で解析したパラメータを受け取る。次にステップＳ９０２に進み、ＣＰＵ２００１はＲＡＭ２００２に記憶されているパラメータを読み出し、ローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要であるか否かを判断する。ここでエラーＩＤ情報に関する説明は前述の図６での説明と同様であるので割愛する。

ステップＳ９０２でローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要でない場合は、ステップＳ９０４に進み、ＣＰＵ２００１は該当のパラメータ内容に応じた処理を行う。本実施の形態ではこの処理の説明は割愛する。その後処理を終了する。

前記ステップＳ９０２でパラメータからローカルＵＩのキャプチャ画面を含んだＷｅｂページの生成が必要と判断された場合は、ステップＳ９０３に進む。ステップＳ９０３で、ＣＰＵ２００１はパラメータ内容が画面指示要求を含むか否かを判断する。ここでは、パラメータにリモートＵＩ上で現在何番目の画面ＩＤを表示しているかの情報を含めることも可能である。このステップＳ９０３で画面指示がないと判断された場合はステップＳ９０５へ進む。

ここで画面指示が含まれていないと言うことは、エラー解消手順の表示の最初のページ要求と見なすこともできる。従って、ステップＳ９０５において、画面指示が含まれていないことがリモートＵＩ上で後述する次画面表示指示ボタンを表示させるべきか否かの判断材料ともなる。

ステップＳ９０５において、ＣＰＵ２００１はキャプチャすべき画面の総数やその他の画面情報をＨＤＤ２００４に記憶されている図７の画面情報テーブルより取得する。そしてステップＳ９０６へ進み、ＣＰＵ２００１はＩＤによって紐づけられた一連の画面の遷移に用いられる一番初めに表示される画面ＩＤの画面をキャプチャ処理する。また、このステップで画面遷移に用いられる他の関連画面も併せてキャプチャ画面を生成し、ＲＡＭ２００２やＨＤＤ２００４に予め保持するようにしても良い。

そしてステップＳ９０７へ進み、ＣＰＵ２００１は取得した一番初めに表示される画面のキャプチャ画面を含んだＷｅｂページを生成する。具体的には、そのキャプチャ画面のデータへのリンクを含んだＨＴＭＬデータを生成する。この際、前述の画面情報により画面総数が複数ならば、後述する次画面表示指示ボタンを表示するようにＨＴＭＬデータを作成し、リモートＵＩ上でユーザが表示する画像を選択できるようにする。その後処理を終了する。

また、本実施例では画面指示が無い場合に一番初めに表示される画面を表示するようにしたが、現在表示・操作部２０１２で表示されている画面をキャプチャし、リモートＵＩ上で表示することもできる。この場合、ステップＳ９０５において、ＣＰＵ２００１は操作部Ｉ／Ｆ２００６からの情報から現在表示・操作部２０１２で表示されている画面の画面ＩＤを取得する。また、現在表示・操作部２０１２で表示されている画面の画面ＩＤを常にＲＡＭ２００２等の記憶装置に記憶していても良い。そして、ＣＰＵ２００１は取得した現在表示・操作部２０１２で表示されている画面の画面ＩＤと図７の画面情報により、表示・操作部２０１２で現在表示されている画面が、規定された画面遷移のなかで何番目に表示される画面かを判断する。そして、ＣＰＵ２００１は、ステップＳ９０６で現在表示されている画面をキャプチャする。そしてステップＳ９０７へ進み、ＣＰＵ２００１は、前記取得したキャプチャ画面を含んだＷｅｂページを生成する。即ち、取得したキャプチャ画面のデータへのリンクを含んだＨＴＭＬデータを生成する。また、ステップＳ９０５で判断した画面が、規定された画面遷移のなかで何番目に表示される画面かによって、次画面が存在する場合は次画面表示指示ボタン、前画面がある場合は後述する前画面指示ボタンが併せて表示されるようにＨＴＭＬデータを生成する。

前記ステップＳ９０３で前画面要求指示だった場合はステップＳ９０８へ進み、ＣＰＵ２００１は前画面があるか否かをパラメータに含まれるリモートＵＩ上で表示されている画面ＩＤ、画面情報及びエラーＩＤから判断する。このステップで前画面がない場合は、そのまま処理を終了する。前記ステップＳ９０８で前画面がある場合は、ステップＳ９０９に進み、ＣＰＵ２００１は前画面のキャプチャ画面を既に生成してＲＡＭ２００２やＨＤＤ２００４から保持している場合、該当のキャプチャ画面データを呼び出す。キャプチャ画面を保持していない場合は、このステップで一つ前のエラー解消手順の画面を新たに生成してもよい。そしてステップＳ９１０に進み、ＣＰＵ２００１は生成または取得したキャプチャ画面を含んだＷｅｂページを生成する。即ち、そのキャプチャ画面のデータへのリンクを含んだＨＴＭＬデータを生成する。さらに、次画面表示指示ボタン、前画面がさらにある場合は後述する前画面指示ボタンを併せて表示されるようにＨＴＭＬデータを生成し、処理を終了する。

前記ステップＳ９０３で次画面要求指示だった場合は、ステップＳ９１１へ進み、ＣＰＵ２００１は次画面があるか否かをパラメータに含まれるリモートＵＩ上で表示されている画面ＩＤ、画面情報及びエラーＩＤから判断する。具体的には、ＣＰＵ２００１が、ＨＤＤ２００４に記憶されている図７の画面情報テーブルを参照し、現在のエラーＩＤに対応する関連画面が複数ある場合には、現在リモートＵＩで表示している画面ＩＤより次の画面があるか否かを判断する。例えば現在のエラーＩＤがＥｒｒ１だった場合、図７の画面情報テーブルの７０１より該当のＩＤをたどり、７０２で画面数が４である事がわかる。そして現在参照している画面ＩＤの次の画面ＩＤがあるか否かを７０３の情報から判断する。ここで次画面がないと判断された場合は、処理を終了する。

前述のステップＳ９１１で次画面があると判断された場合は、ステップＳ９１２へ進み、ＣＰＵ２００１は次画面のキャプチャ画面を既に生成してＲＡＭ２００２やＨＤＤ２００４から保持している場合、該当のキャプチャ画面データを呼び出す。キャプチャ画面を保持していない場合は、このステップで一つ次のエラー解消手順の画面を新たに生成してもよい。そしてステップＳ９１３に進み、ＣＰＵ２００１は、生成または呼び出したキャプチャ画面を含んだＷｅｂページを生成する。即ち、そのキャプチャ画面のデータへのリンクを含んだＨＴＭＬデータを生成する。更に、前画面がある場合には前画面表示指示ボタン、次画面がさらにある場合は次画面指示ボタンを併せて表示されるようにＨＴＭＬデータを生成しページを送信し、処理を終了する。

本実施例による画像処理装置２００から送信されたＷｅｂページのＷｅｂブラウザでの表示例を図１０に示す。この画面はコンピュータ１１の表示部にＷｅｂブラウザによって表示されるものである。

この図１０では画像処理装置２００でエラーが発生したときにリモートＵＩから閲覧できるエラー情報に関するページの例を示している。

図中、１００１は前画面表示指示ボタンを示している。また１００２は次画面表示指示ボタンを示している。これら前画面表示指示ボタン１００１や次画面表示指示ボタン１００２をクリックすることにより、該当のエラー解消手順の画面ページを表示するべくＨＴＴＰコマンドが画像処理装置２００へ送信される（前述のステップＳ５０２）。その際、ＨＴＴＰコマンドに含まれるパラメータにはＷｅｂページでのエラー情報表示要求指示と現在表示していた画面の画面ＩＤまたは画面が何番目の画面であったかが記載されていてもよい。これを受けた画像処理装置２００は要求を満たすように処理を行い、図１０に示す表示内容を記述したＨＴＭＬデータを送信する。１００３はこのようにして取得したエラー解消手順のキャプチャ画面の例を示している。

なお、本実施の形態では画面指示要求を次画面表示指示ボタン１００２や前画面表示指示ボタン１００１によって行ったが、これらに限定されるものではない。例えば、プルダウンメニューやラジオボタンによって手順数等を指定することで表示するキャプチャ画面を選択可能となるように構成しても良い。

なお、例えばステップＳ９０６、Ｓ９０９、Ｓ９１２で画面表示によって選択され呼び出された画像は、該当するＣＧＩプログラム処理内で、ＣＰＵ２００１によって伸長処理等の画像処理を施されるようにしてもよい。例えば、表示・操作部２０１２が小さい画面であっても、ユーザはコンピュータ１１の表示装置によって、伸長された画面を確認することが出来るので、ユーザにとって見やすい情報の表示が可能となる。

以上説明したように、第二の実施形態ではユーザが表示させるキャプチャ画面を選択可能になり、順番にキャプチャ画面を表示できるようになる。そして特に注目したいキャプチャ画面をクライアント上で表示できるため、ユーザにとってより見やすい表示が可能となる。

（第三の実施の形態）
次に本発明の第三の実施形態について説明する。第三の実施形態では、リモートＵＩに画像処理装置のローカルＵＩのキャプチャ画面を表示させるにあたって、第一の実施形態の表示方法とするか第二の実施形態の表示方法とするかをユーザに選択させるものである。

以下の説明では、第一の実施形態、第二の実施形態と重複する部分の説明は省略し、異なる部分のみ説明する。

本実施例による画像処理装置２００から送信されたＷｅｂページのＷｅｂブラウザでの表示例を図１１に示す。この画面はコンピュータ１１の表示部にＷｅｂブラウザによって表示されるものである。

図１１は画像処理装置２００でエラーが発生したときにリモートＵＩから閲覧できるエラー情報に関するページの例を示している。

図中、１１０１、１１０２、１１０３は表示方法指示の一例を示す。１１０１はユーザが選択可能な一覧表示ボタンを示している。また１１０２は同じく順次表示ボタン、１１０３は同じく非表示ボタンを示している。これら３つのボタンはお互いに排他であり、一連の画面遷移に用いる画像の表示方法をユーザはどれか一つを選択可能に指示することが出来る。

ユーザの選択として１１０１の一覧表示が選択された場合は、第一の実施形態で説明した、手順１から手順４のエラー解消手順を一覧表示する。図１１はこの表示の様子を示した一例である。

ユーザの選択として１１０２の順次表示が選択された場合は、第二の実施形態で説明した、手順１から手順４のエラー解消手順を順次表示する。その場合、リモートＵＩの画面は図１０のようになる。

ユーザの選択として１１０３の非表示が選択された場合は、エラー解消手順のキャプチャ画面を表示しないことが可能である。

これら一連の選択情報は前述の図５のＳ５０２でコンピュータ１１から画像処理装置２００に送信される。そして画像処理装置２００のＣＰＵ２００１は図５のステップＳ５０７において、表示方法の種類、もしくは表示方法の指示の有無を識別することが可能である。すなわち図５のステップＳ５０７においてＣＰＵ２００１は、前記図１１の表示方法指示のうちいずれかが選択されたかを判断し、適したＣＧＩプログラムを起動し、指示された表示方法で一連の画面遷移をクライアントに表示可能である。

また、図６のステップＳ６０５や図９のステップＳ９０５での画面数の判断によって画面数が単数であった場合、表示方法選択手段を設けないようにするか非表示ボタン１１０３だけを表示するようにすることも可能である。これによりユーザの手間が省ける。

以上説明したように本実施形態によれば、ユーザが表示方法を選択できるので、ユーザにとってより利便性が高い情報の提供が可能となる。

尚、図１１の１１０４はリモートＵＩの消耗品確認表示のためのメニューを示している。消耗品確認メニューでは、ユーザはトナー残量や用紙残量などの消耗品の確認が可能であり、当該メニュー画面に遷移する。ここで、このメニューが選択された場合には、エラー解消手順ではなく、消耗品交換手順としてローカルＵＩのキャプチャ画面を表示することも可能である。この場合は、リモートＵＩの消耗品確認画面において、その消耗品情報のメッセージと共に、消耗品交換手順をエラー解消手順と同様の手順で表示することになる。リモートＵＩで消耗品交換手順が確認できることで、交換する際に事前に消耗品の準備が出来るのでユーザの手間を軽減することが可能となり、より使い易いリモートＵＩが提供できる。

また、画像処理装置が有している機能をローカルＵＩ上で操作して行う際に表示・操作部２０１２で表示される画面遷移をキャプチャし、リモートＵＩ上で表示することもできる。この場合、図７で用いたエラーＩＤを操作ＩＤとして、その操作の説明をメッセージとともに、画面遷移を用いて表示するのでローカルＵＩ上での操作を戸惑うことなく実行することができる。

なお、図７で示した画面情報テーブルにおける一連の画面遷移を規定するＩＤはエラーＩＤ７０１に限定されるものではなく、表示・操作部２０１２で表示される一連の画面の遷移を表現するものであればどのような情報に基づいても良い。

また、一連の画面遷移を示す複数のキャプチャ画面をリモートＵＩに表示する際に、現在ローカルＵＩに表示されている画面をユーザが認識できるように表示してもよい。例えば、現在ローカルＵＩに表示されている画面に対して、リモートＵＩ上で「現在、表示中です」のようなメッセージを表示するか、その画面だけ枠を設けるかなどで識別可能にすることで実現できる。例えば、図８の例で、キャプチャ画面８０６〜８０９のうち、現在ローカルＵＩにおいて８０７が表示されている場合には、リモートＵＩ上で８０７のキャプチャ画面を強調表示する。

例えば、プリントオンデマンド（ＰＯＤ）に用いられる大型の画像処理装置のように、ローカルＵＩと実際のジャムが発生した箇所の距離が離れている場合に、本発明は便利である。ユーザが携帯可能なコンピュータに、本実施形態の図８等のリモートＵＩを表示させることにより、適切にエラー解除が行われているかの確認や次に操作すべき手順情報の確認のためにローカルＵＩとエラー箇所との間を往復しなくてもよくなるためである。

（その他の実施形態）
なお、上記実施形態では、本発明を、情報送信装置として動作可能な画像処理装置に適用した場合を例示したが、これに限定されるものではない。また複数の装置から構成されているシステムにおいても適用可能であり、例えば上記実施形態で説明した各フローチャートの処理を１つの装置が備える複数のＣＰＵで分担して処理したり、複数の装置が備えるそれぞれのＣＰＵで分担して処理してもよい。また、上記実施形態では、情報送信装置が提供するＷｅｂページはＨＴＭＬデータによって記述されたが、ＸＭＬ等その他のページ記述言語を用いて記述されても構わない。

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

２００１ ＣＰＵ
２００２ ＲＡＭ
２００３ ＲＯＭ
２００４ ＨＤＤ
２００９ ＶＲＡＭ

Claims (9)

1. 情報送信装置の情報を示すＷｅｂページであって、前記情報送信装置が備える表示部に表示される画面と共通の画面を示す画像データを含んだＷｅｂページを生成する生成手段と、
   情報処理装置からの要求に応じて、前記生成手段によって生成されたＷｅｂページを当該情報処理装置に送信する送信手段と、
   前記表示部に表示される画面が、関連する複数の画面のうちの１画面である場合、当該関連する複数の画面それぞれの画像データを取得する取得手段と、
   を有し、
   前記生成手段は、前記取得手段によって取得された複数の画面それぞれの画像データを含むＷｅｂページを生成することを特徴とする情報送信装置。
2. 前記生成手段は、前記取得手段によって取得された複数の画面を並べて表示するためのＷｅｂページを生成することを特徴とする請求項１記載の情報送信装置。
3. 前記生成手段は、前記取得手段によって取得された複数の画面をユーザの指示に応じて順番に表示するためのＷｅｂページを生成することを特徴とする請求項１記載の情報送信装置。
4. 前記生成手段は、前記取得手段によって取得された複数の画面を並べて表示するか、ユーザの指示に応じて順番に表示するかを選択可能にしたＷｅｂページを生成することを特徴とする請求項１記載の情報送信装置。
5. 前記関連する複数の画面は、前記情報送信装置において発生したエラーに対する解消手順を説明するための一連の画面であることを特徴とする請求項１乃至４の何れか一項に記載の情報送信装置。
6. 前記表示部に表示される画面のキャプチャ画面を生成するキャプチャ手段を更に有し、
   前記生成手段は、前記キャプチャ手段によって生成されたキャプチャ画面を前記画像データとして含んだＷｅｂページを生成することを特徴とする請求項１乃至５の何れか一項に記載の情報送信装置。
7. 前記情報送信装置は画像処理装置であり、前記生成手段によって生成されるＷｅｂページは、画像処理装置において行われる画像処理に関する設定を行うためのＷｅｂページであることを特徴とする請求項１乃至６の何れか一項に記載の情報送信装置。
8. 情報送信装置の制御方法であって、
   前記情報送信装置の情報を示すＷｅｂページであって、前記情報送信装置が備える表示部に表示される画面と共通の画面を示す画像データを含んだＷｅｂページを生成する生成ステップと、
   情報処理装置からの要求に応じて、前記生成ステップによって生成されたＷｅｂページを当該情報処理装置に送信する送信ステップと、
   前記表示部に表示される画面が、関連する複数の画面のうちの１画面である場合、当該関連する複数の画面それぞれの画像データを取得する取得ステップと、
   を有し、
   前記生成ステップは、前記取得ステップによって取得された複数の画面それぞれの画像データを含むＷｅｂページを生成することを特徴とする情報送信装置の制御方法。
9. 情報送信装置に、以下のステップを実行させるためのプログラムであって、
   前記情報送信装置の情報を示すＷｅｂページであって、前記情報送信装置が備える表示部に表示される画面と共通の画面を示す画像データを含んだＷｅｂページを生成する生成ステップと、
   情報処理装置からの要求に応じて、前記生成ステップによって生成されたＷｅｂページを当該情報処理装置に送信する送信ステップと、
   前記表示部に表示される画面が、関連する複数の画面のうちの１画面である場合、当該関連する複数の画面それぞれの画像データを取得する取得ステップと、
   を有し、
   前記生成ステップは、前記取得ステップによって取得された複数の画面それぞれの画像データを含むＷｅｂページを生成することを特徴とするプログラム。

Images