(57)【要約】      （修正有）【課題】  通信装置における異常の発生及び解消を管理装置において的確に把握し、異常への対応に要する労力を低減すると共に、管理装置と被管理装置との間にファイアウォールが配置されている場合でも遠隔管理を行うことができるようにする。【解決手段】  管理装置において、被管理装置から異常の発生を示す異常情報（ＳＣコール）とその解消を示す異常解消情報（ＳＣ解除コール）を受信して管理し、上記異常情報を受信した場合でも、その異常情報と対応する上記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する。そして、異常情報の受信から所定時間以内に異常が解消されたものと判断しなかった場合にその異常の発生をその管理装置のオペレータに通知する手段を設けるとよい。【選択図】        図２０
2004248256.tif 000002
【特許請求の範囲】
【請求項１】
自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置をネットワークを介して遠隔管理する管理装置であって、
前記被管理装置と通信するための通信手段と、
前記被管理装置から前記異常情報を受信して管理する異常情報管理手段とを設け、
該異常情報管理手段に、前記被管理装置から前記異常解消情報を受信する異常解消情報受信手段と、
前記異常情報を受信した場合でも、その異常情報と対応する前記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する手段とを設けたことを特徴とする管理装置。
【請求項２】
請求項１記載の管理装置であって、
前記異常情報は、異常の種類毎に異なる情報であり、
前記異常情報管理手段は、異常の種類毎にその解消の有無を判断する手段を有することを特徴とする管理装置。
【請求項３】
請求項２記載の管理装置であって、
前記異常解消情報は、前記異常情報に対応して、解消された異常の種類毎に異なる情報であることを特徴とする管理装置。
【請求項４】
請求項１又は２記載の管理装置であって、
前記異常解消情報は、前記被管理装置において全ての異常が解消されたことを示す情報であることを特徴とする管理装置。
【請求項５】
請求項１乃至４のいずれか一項記載の管理装置であって、
前記異常情報の受信から第１の所定時間以内に前記異常情報管理手段が該異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生を当該管理装置のオペレータに通知する異常通知手段を設けたことを特徴とする管理装置。
【請求項６】
請求項１乃至４のいずれか一項記載の管理装置であって、
前記異常情報管理手段に、前記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する電源ＯＮ通知受信手段を設け、
前記異常情報の受信から第１の所定時間以内または、該異常情報の受信後前記第１の所定時間以内に該異常情報の発信元の被管理装置から前記電源ＯＮ通知を受信してかつ該受信から第２の所定時間以内に、前記異常情報管理手段が前記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生を当該管理装置のオペレータに通知する異常通知手段を設けたことを特徴とする管理装置。
【請求項７】
請求項１乃至４のいずれか一項記載の管理装置であって、
前記異常情報管理手段に、前記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する電源ＯＮ通知受信手段と、
管理対象となっている異常情報の送信元の被管理装置から前記電源ＯＮ通知を受信し、該受信から第２の所定時間以内にその異常情報と対応する前記異常解消情報を受信しない場合には、該異常情報に係る異常は電源の再投入では解消されない異常であるものと判断する手段を設けたことを特徴とする管理装置。
【請求項８】
請求項７記載の管理装置であって、
前記異常情報の受信から第１の所定時間以内または、該異常情報の受信後前記第１の所定時間以内に該異常情報の発信元の被管理装置から前記電源ＯＮ通知を受信してかつ該受信から前記第２の所定時間以内に、前記異常情報管理手段が前記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生を当該管理装置のオペレータに通知する異常通知手段を設け、
該異常通知手段に、前記異常情報管理手段が前記通知に係る異常は電源の再投入では解消されない異常であるものと判断した場合に、その旨を前記オペレータに通知する手段を設けたことを特徴とする管理装置。
【請求項９】
請求項５，６，８のいずれか一項記載の管理装置であって、
前記異常情報の受信後、前記異常通知手段による通知より前には、該異常情報に係る異常の発生を前記オペレータに通知しないようにしたことを特徴とする管理装置。
【請求項１０】
請求項５，６，８のいずれか一項記載の管理装置であって、
管理対象とする被管理装置のユーザ情報を記憶するユーザ情報記憶手段を設け、
前記第１の所定時間を、該手段に記憶しているユーザ情報に従って定めるようにしたことを特徴とする管理装置。
【請求項１１】
請求項６乃至８のいずれか一項記載の管理装置であって、
前記第２の所定時間を、前記被管理装置の機種に応じて定めるようにしたことを特徴とする管理装置。
【請求項１２】
請求項１乃至５のいずれか一項記載の管理装置であって、
前記異常情報及び前記異常解消情報は構造化言語形式で記載された情報であることを特徴とする管理装置。
【請求項１３】
請求項６乃至８のいずれか一項記載の管理装置であって、
前記異常情報，前記異常解消情報及び前記電源ＯＮ通知は構造化言語形式で記載された情報であることを特徴とする管理装置。
【請求項１４】
管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、
前記複数の通信装置にそれぞれ、前記管理装置と通信するための通信手段と、自身の異常及びその異常の解消を検出する異常検出手段と、該手段が異常を検出した場合に前記管理装置に異常情報を送信する異常通知手段と、前記異常検出手段が異常解消を検出した場合に前記管理装置に異常解消情報を送信する異常解消通知手段とを設け、
前記管理装置に、前記通信装置と通信するための通信手段と、前記通信装置から前記異常情報を受信して管理する異常情報管理手段とを設け、
該異常情報管理手段に、前記通信装置から前記異常解消情報を受信する異常解消情報受信手段と、
前記異常情報を受信した場合でも、その異常情報と対応する前記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する手段とを設けたことを特徴とする遠隔管理システム。
【請求項１５】
請求項１４記載の遠隔管理システムであって、
前記異常情報は、異常の種類毎に異なる情報であり、
前記異常解消情報は、該異常情報に対応して、解消された異常の種類毎に異なる情報であり、
前記管理装置の前記異常情報管理手段は、異常の種類毎にその解消の有無を判断する手段を有することを特徴とする遠隔管理システム。
【請求項１６】
請求項１４又は１５記載の遠隔管理システムであって、
前記管理装置に、前記異常情報の受信から第１の所定時間以内に前記異常情報管理手段が該異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生を当該管理装置のオペレータに通知する異常通知手段を設けたことを特徴とする遠隔管理システム。
【請求項１７】
請求項１４又は１５記載の遠隔管理システムであって、
前記通信装置に、電源をＯＮされた場合に前記管理装置に対して電源ＯＮ通知を送信する電源ＯＮ通知手段を設け、
前記管理装置の前記異常情報管理手段に、前記通信装置から前記電源ＯＮ通知を受信する電源ＯＮ通知受信手段を設け、
該管理装置に、前記異常情報の受信から第１の所定時間以内または、該異常情報の受信後前記第１の所定時間以内に該異常情報の発信元の被管理装置から前記電源ＯＮ通知を受信してかつ該受信から第２の所定時間以内に、前記異常情報管理手段が前記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生を当該管理装置のオペレータに通知する異常通知手段を設けたことを特徴とする遠隔管理システム。
【請求項１８】
請求項１７記載の遠隔管理システムであって、
前記第２の所定時間を、前記通信装置の機種に応じて定めるようにしたことを特徴とする遠隔管理システム。
【請求項１９】
請求項１６乃至１８のいずれか一項記載の遠隔管理システムであって、
前記管理装置に、管理対象とする通信装置のユーザ情報を記憶するユーザ情報記憶手段を設け、
前記第１の所定時間を、該手段に記憶しているユーザ情報に従って定めるようにしたことを特徴とする遠隔管理システム。
【請求項２０】
自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置をネットワークを介して遠隔管理する管理装置を制御するコンピュータを、
前記被管理装置と通信するための通信手段と、
前記被管理装置から前記異常情報を受信して管理し、前記被管理装置から前記異常解消情報を受信し、前記異常情報を受信した場合でも、その異常情報と対応する前記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する異常情報管理手段として機能させるためのプログラム。
【請求項２１】
請求項２０記載のプログラムであって、
前記異常情報を、異常の種類毎に異なる情報とし、
前記異常解消情報を、該異常情報に対応して、解消された異常の種類毎に異なる情報とし、
前記異常情報管理手段は、異常の種類毎にその解消の有無を判断する機能を有することを特徴とするプログラム。
【請求項２２】
請求項２０又は２１記載のプログラムであって、
前記コンピュータを、前記異常情報の受信から第１の所定時間以内に前記異常情報管理手段が該異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生を当該管理装置のオペレータに通知する異常通知手段として機能させるためのプログラムをさらに含むことを特徴とするプログラム。
【請求項２３】
請求項２０又は２１記載のプログラムであって、
前記異常情報管理手段は、前記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する機能を有し、
前記コンピュータを、前記異常情報の受信から第１の所定時間以内または、該異常情報の受信後前記第１の所定時間以内に該異常情報の発信元の被管理装置から前記電源ＯＮ通知を受信してかつ該受信から第２の所定時間以内に、前記異常情報管理手段が前記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生を当該管理装置のオペレータに通知する異常通知手段として機能させるためのプログラムをさらに含むことを特徴とするプログラム。
【請求項２４】
請求項２３記載のプログラムであって、
前記第２の所定時間を、前記被管理装置の機種に応じて定めるようにしたことを特徴とするプログラム。
【請求項２５】
請求項２２乃至２４のいずれか一項記載のプログラムであって、
前記コンピュータを、管理対象とする被管理装置のユーザ情報を記憶するユーザ情報記憶手段として機能させるプログラムをさらに含み、
前記第１の所定時間を、該手段に記憶しているユーザ情報に従って定めるようにしたことを特徴とするプログラム。
【請求項２６】
自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置を、該被管理装置とネットワークを介して通信可能な管理装置によって遠隔管理する管理方法であって、
前記管理装置によって前記被管理装置から前記異常情報を受信して管理し、前記被管理装置から前記異常解消情報を受信し、前記異常情報を受信した場合でも、その異常情報と対応する前記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断することを特徴とする管理方法。
【請求項２７】
請求項２６記載の管理方法であって、
前記異常情報を、異常の種類毎に異なる情報とし、
前記異常解消情報を、該異常情報に対応して、解消された異常の種類毎に異なる情報とし、
前記管理装置が異常の種類毎にその解消の有無を判断するようにしたことを特徴とする管理方法。
【請求項２８】
請求項２６又は２７記載の管理方法であって、
前記異常情報の受信から第１の所定時間以内に該異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生を当該管理装置のオペレータに通知するようにしたことを特徴とする管理方法。
【請求項２９】
請求項２６又は２７のいずれか一項記載の管理方法であって、
前記管理装置によって、前記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信し、前記異常情報の受信から第１の所定時間以内または、該異常情報の受信後前記第１の所定時間以内に該異常情報の発信元の被管理装置から前記電源ＯＮ通知を受信してかつ該受信から第２の所定時間以内に、前記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生を当該管理装置のオペレータに通知するようにしたことを特徴とする管理方法。
【請求項３０】
請求項２９記載の管理方法であって、
前記第２の所定時間を、前記被管理装置の機種に応じて定めることを特徴とする管理方法。
【請求項３１】
請求項２８乃至３０のいずれか一項記載の管理方法であって、
前記管理装置に、管理対象とする被管理装置のユーザ情報を記憶させ、前記第１の所定時間をそのユーザ情報に従って定めることを特徴とする管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、被管理装置をネットワークを介して遠隔管理する管理装置と、このような管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システム、および上記管理装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラム、並びに被管理装置をその被管理装置とネットワークを介して通信可能な管理装置によって遠隔管理する管理方法に関する。
【背景技術】
【０００２】
従来から、通信機能を備えたプリンタ，ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた電子装置（通信装置）を被管理装置とし、サービスセンタ（管理センタ）の管理装置が公衆回線やインタネット等のネットワーク経由でこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。
あるいは、被管理装置が直接管理装置と通信する通信機能を持たない場合、その被管理装置にネットワーク経由で通信手段（通信機能）を有する仲介装置を接続し、管理装置がネットワーク及び仲介装置経由で被管理装置を遠隔管理する遠隔管理システムも提案されている。
【０００３】
ここで、例えば被管理装置を画像形成装置とし、その画像形成装置を遠隔管理する遠隔管理システムについて説明する。
画像形成装置としては、既知の感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル（異常）が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
この保守管理を充実させる目的で、画像形成装置の遠隔管理システムとして、画像形成装置の内部又は外部に通信装置を設け、画像形成装置とサービスセンタ（管理センタ）に設置された管理装置とを公衆回線（電話回線）を介して接続し、画像形成装置の異常発生時にその旨を管理装置に通報するようにしたものが既に開発され（例えば特許文献１〜５参照）、市販されている。
【０００４】
このような遠隔管理システムにおいて画像形成装置に異常が発生した場合の制御について説明する。
まず、図４１に、従来の遠隔管理システムにおける画像形成装置に異常が発生した場合の処理シーケンスを簡単に示す。この図においては、画像形成装置内部の処理及び画像形成装置と管理装置との間のデータ転送経路の図示は省略している。
この遠隔管理システムにおいては、画像形成装置が各種のセンサ等により自身の異常を検出する異常検出部（異常検出手段）を備えている。そして、異常が発生すると、対応する異常検出部がその異常を例えばＳＣ（サービスマンコール）として検出し、ＳＣが発生した旨の情報（異常情報）をＳＣコールとして管理装置に送信する。
【０００５】
管理装置側では、このＳＣコールを受信するとそのＳＣコールに含まれる情報を記憶すると共に、端末の画面にその情報を表示する等してオペレータに異常の発生を通知する。
これを受けて管理装置のオペレータ（以下「センタオペレータ」という」が画像形成装置の状態を知るべく状態取得要求の送信を管理装置に指示すると、管理装置がこれに応じて画像形成装置に状態取得要求を送信する。画像形成装置は、これに応答して自身の状態を示す情報（正常か異常か）を返し、センタオペレータはこの情報によって画像形成装置の状態を知ることができる。そして、異常が回復していない場合には、ユーザ（画像形成装置の利用者）に電話等によって連絡して異常の状況を確認すると共に、必要であれば保守員（カスタマーエンジニア：ＣＥ）の手配を行う。
【０００６】
次に、このような処理におけるのデータの流れについてより詳細に説明する。図４２，図４３はそれぞれ、上記の処理における通信シーケンスを詳細に示した図であり、図４２は異常が解消していない場合、図４３は解消した場合の例を示す図である。
画像形成装置は、スキャナ又はプロッタ等のエンジン内に異常検出部を備えており、その異常検出部がエンジンの状態を監視し、異常が発生した場合にこれを例えばＳＣとして検出し、ＳＣが発生した旨（異常情報）をコントローラへ通知する。
コントローラは、エンジンからＳＣが発生した旨が通知されると、そのエンジン内でＳＣが発生したと判定し、ＳＣコール（ＳＣ情報の自動通報）用のメッセージを生成して仲介装置であるラインアダプタへ送信する。このとき、操作部上の文字表示器に「ＳＣコール中」のメッセージを表示する。
【０００７】
ラインアダプタは、コントローラからＳＣコール用のメッセージを受信すると、コール受付ＯＫをコントローラへ通知すると共に、公衆回線経由でサービスセンタの管理装置に対してＳＣコールを行う。つまり、ＳＣコールを知らせるＳＣコール情報（異常情報）を公衆回線経由でサービスセンタの管理装置へ自動通報する。
サービスセンタの管理装置は、機器利用者（この例では画像形成装置を利用しているユーザ）側に設置されているラインアダプタから通報されたＳＣコール情報を受信し、その受信が正常に終了すると、その旨（ＳＣコールに対する処理が成功した旨）のコール結果（ＯＫ）を公衆回線経由で通報元のラインアダプタへ送信する。また、受信したＳＣコールの情報をキュー（例えばハードディスク装置内のデータベース）に格納して記憶し、センタオペレータによって対応する処理が行われるまでキューイング（保持）する。さらに、受信したＳＣコールの情報を表示部に表示してセンタオペレータに知らせる。
【０００８】
通報元のラインアダプタは、サービスセンタの管理装置からコール結果（ＯＫ）を受信すると、そのコール結果（ＯＫ）を画像形成装置のコントローラへ送信する。
画像形成装置のコントローラは、ラインアダプタからコール結果（ＯＫ）を受信すると、操作部上の文字表示器に「ＳＣコール成功」のメッセージを表示する。
一方、センタオペレータは、管理装置の表示部の表示を見て通報元の画像形成装置のエンジン内でＳＣが発生したことを認識すると、対応する作業を開始する。
すなわち、まず、ＳＣコールの送信元の機器（画像形成装置）の状態を知るため、管理装置を操作し、状態取得要求にその機器の識別情報を付加してＳＣコールの送信元のラインアダプタへ送信させる。すると、このラインアダプタが付加された識別情報を参照してＳＣコールの送信元の機器のコントローラに状態取得要求を転送する。
【０００９】
画像形成装置のコントローラは、ラインアダプタから状態取得要求を受信すると、エンジンの状態を調べ、その結果を示す状態応答をラインアダプタへ送信する。このとき、例えばユーザ（オペレータ）による主電源のＯＦＦ／ＯＮ（主電源を一旦ＯＦＦにして再びＯＮにすること。以下「電源の再投入」ともいう）によってＳＣ状態（異常）が解消することもあるため、この場合にはＳＣ状態の解消を示す情報を状態応答としてラインアダプタへ送信する。
ラインアダプタは、画像形成装置のコントローラから状態応答を受信すると、その状態応答を公衆回線経由でサービスセンタの管理装置へ送信する。
【００１０】
サービスセンタの管理装置は、通報元のラインアダプタから状態応答情報を受信すると、その状態応答情報を表示部に表示してセンタオペレータに知らせる。
センタオペレータは、管理装置の表示部の表示を見てＳＣコール送信元の画像形成装置のエンジン内でＳＣが発生したままであることを認識すると（図４２の場合）、該当するユーザ（その画像形成装置の利用者）へ電話をかけて異常の発生状況を確認し、解除の方法を指示したり、必要であればサービスステーションに連絡を取り、保守員を手配するという処理を実施する。通報元のラインアダプタに接続されている画像形成装置のエンジン内でＳＣが発生していない（異常が解消された：図４３の場合）ことを認識すると、ユーザへの連絡は行わない。
【００１１】
なお、ここではセンタオペレータが状態取得要求の送信を手動で指示し、これに対する応答に応じて対処する例について説明したが、受信したＳＣコールに係る異常がリセットで復旧するか否か判断し、復旧するものであれば画像形成装置にリセット信号を送信してリセット動作を行わせ、その後一定時間後に状態取得要求を自動で行う技術についても、特許文献６に記載されている。
【特許文献１】特開平８−３１４８１５号公報
【特許文献２】特開２００２−１４４６８４号公報
【特許文献３】特開２００１−３４１２２号公報
【特許文献４】特開２００１−１０９３３４号公報
【特許文献５】特開２００１−１９４９６４号公報
【特許文献６】特開平１１−３３１３９９号公報（特に図面の図４及び明細書の００２１段落）
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、このような遠隔管理システムでは、以下に示すような問題があった。すなわち、被管理装置（ここでは画像形成装置）で異常が発生した場合でも、電源の再投入で解消するような場合もあり、このようなものであればユーザ側でも対応可能であることが考えられる。しかし、このような場合でも、センタ側では状態取得要求に対する応答を得るまで異常の解消を知ることができない。従って、図４１乃至図４３を用いて説明した例では、センタオペレータが状態取得要求の送信を指示し、その結果を参照して対応を判断する必要があるので、ユーザ側で対応可能であり、特にユーザへの連絡が必要ない異常についても、一定の労力を割いて対応しなければならないという問題があった。
【００１３】
特許文献６に記載のように自動的に状態取得要求を送信するようにした場合でも、これに対する応答を得るまで異常の解消を知ることができないため、異常が解消していたとしてもＳＣコールのデータベースを速やかに更新することができないという問題があった。この問題を解消するためには頻繁に状態取得要求を行うようにすることも考えられるが、そうすると、通信トラフィックや処理負担の増大につながるという新たな問題が生じる。
【００１４】
また、近年においては、被管理装置と管理装置とをインターネットを介して接続して管理システムを構成することも試みられるようになってきたが、セキュリティを考慮して、被管理装置が接続される顧客側のネットワークにはファイアウォールが設置されることが多い。このような場合、ファイアウォールの外側の管理装置からファイアウォールの内側の被管理装置に対するアクセスは大きく制限されるので、状態取得要求の送信は困難であるという問題がある。ファイアウォールを越えて管理装置から被管理装置に情報を送信する方法としては、例えば被管理装置から管理装置に対してＨＴＴＰ（Hyper Text Transfer Protocol）によってセッションを張り（通信を要求して通信経路を確立し）、そのレスポンスとして必要な情報を送信することが考えられるが、これでは被管理装置からのポーリングを待たねばならず、いつでも状態取得要求を送信できるわけではない。
【００１５】
この発明は、上記の問題点に鑑みてなされたものであり、画像形成装置等の通信装置を被管理装置として管理装置によってネットワークを介して遠隔管理する場合において、通信装置における異常の発生及び解消を管理装置において的確に把握し、異常への対応に要する労力を低減することを目的とする。さらに、管理装置と被管理装置との間にファイアウォールが配置されている場合でも遠隔管理を行うことができるようにすることも目的とする。
【課題を解決するための手段】
【００１６】
上記の目的を達成するため、この発明は、自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置をネットワークを介して遠隔管理する管理装置において、上記被管理装置と通信するための通信手段と、上記被管理装置から上記異常情報を受信して管理する異常情報管理手段とを設け、その異常情報管理手段に、上記被管理装置から上記異常解消情報を受信する異常解消情報受信手段と、上記異常情報を受信した場合でも、その異常情報と対応する上記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する手段とを設けたものである。
【００１７】
このような管理装置において、上記異常情報を、異常の種類毎に異なる情報とし、上記異常情報管理手段に、異常の種類毎にその解消の有無を判断する手段を設けるとよい。
さらに、上記異常解消情報を、上記異常情報に対応して、解消された異常の種類毎に異なる情報とするとよい。
また、これらの管理装置において、上記異常解消情報を、上記被管理装置において全ての異常が解消されたことを示す情報とするとよい。
さらに、上記の管理装置において、上記異常情報の受信から第１の所定時間以内に上記異常情報管理手段がその異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生をその管理装置のオペレータに通知する異常通知手段を設けるとよい。
【００１８】
あるいは、上記異常情報管理手段に、上記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する電源ＯＮ通知受信手段を設け、上記異常情報の受信から第１の所定時間以内または、その異常情報の受信後上記第１の所定時間以内にその異常情報の発信元の被管理装置から上記電源ＯＮ通知を受信してかつその受信から第２の所定時間以内に、上記異常情報管理手段が上記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生をその管理装置のオペレータに通知する異常通知手段を設けるとよい。
【００１９】
あるいはまた、上記異常情報管理手段に、上記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する電源ＯＮ通知受信手段と、管理対象となっている異常情報の送信元の被管理装置から上記電源ＯＮ通知を受信し、その受信から第２の所定時間以内にその異常情報と対応する上記異常解消情報を受信しない場合には、その異常情報に係る異常は電源の再投入では解消されない異常であるものと判断する手段を設けるとよい。
このような管理装置において、さらに、上記異常情報の受信から第１の所定時間以内または、その異常情報の受信後上記第１の所定時間以内にその異常情報の発信元の被管理装置から上記電源ＯＮ通知を受信してかつその受信から上記第２の所定時間以内に、上記異常情報管理手段が上記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生をその管理装置のオペレータに通知する異常通知手段を設け、その異常通知手段に、上記異常情報管理手段が上記通知に係る異常は電源の再投入では解消されない異常であるものと判断した場合に、その旨を上記オペレータに通知する手段を設けるとよい。
【００２０】
また、上記の管理装置において、上記異常情報の受信後、上記異常通知手段による通知より前には、その異常情報に係る異常の発生を上記オペレータに通知しないようにするとよい。
また、管理対象とする被管理装置のユーザ情報を記憶するユーザ情報記憶手段を設け、上記第１の所定時間を、その手段に記憶しているユーザ情報に従って定めるようにするとよい。
さらにまた、上記第２の所定時間を、上記被管理装置の機種に応じて定めるようにするとよい。
また、上記の管理装置において、上記異常情報及び上記異常解消情報を構造化言語形式で記載された情報とするとよい。
あるいは、上記異常情報，上記異常解消情報及び上記電源ＯＮ通知を構造化言語形式で記載された情報とするとよい。
【００２１】
この発明はまた、管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記管理装置と通信するための通信手段と、自身の異常及びその異常の解消を検出する異常検出手段と、その手段が異常を検出した場合に上記管理装置に異常情報を送信する異常通知手段と、上記異常検出手段が異常解消を検出した場合に上記管理装置に異常解消情報を送信する異常解消通知手段とを設け、上記管理装置に、上記通信装置と通信するための通信手段と、上記通信装置から上記異常情報を受信して管理する異常情報管理手段とを設け、その異常情報管理手段に、上記通信装置から上記異常解消情報を受信する異常解消情報受信手段と、上記異常情報を受信した場合でも、その異常情報と対応する上記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する手段とを設けたものである。
【００２２】
このような遠隔管理システムにおいて、上記異常情報を、異常の種類毎に異なる情報とし、上記異常解消情報を、その異常情報に対応して、解消された異常の種類毎に異なる情報とし、上記管理装置の上記異常情報管理手段に、異常の種類毎にその解消の有無を判断する手段を設けるとよい。
さらに、上記管理装置に、上記異常情報の受信から第１の所定時間以内に上記異常情報管理手段がその異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生をその管理装置のオペレータに通知する異常通知手段を設けるとよい。
【００２３】
あるいは、上記通信装置に、電源をＯＮされた場合に上記管理装置に対して電源ＯＮ通知を送信する電源ＯＮ通知手段を設け、上記管理装置の上記異常情報管理手段に、上記通信装置から上記電源ＯＮ通知を受信する電源ＯＮ通知受信手段を設け、その管理装置に、上記異常情報の受信から第１の所定時間以内または、その異常情報の受信後上記第１の所定時間以内にその異常情報の発信元の被管理装置から上記電源ＯＮ通知を受信してかつその受信から第２の所定時間以内に、上記異常情報管理手段が上記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生をその管理装置のオペレータに通知する異常通知手段を設けるとよい。
さらに、上記第２の所定時間を、上記通信装置の機種に応じて定めるようにするとよい。
さらにまた、上記管理装置に、管理対象とする通信装置のユーザ情報を記憶するユーザ情報記憶手段を設け、上記第１の所定時間を、その手段に記憶しているユーザ情報に従って定めるようにするとよい。
【００２４】
また、この発明のプログラムは、自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置をネットワークを介して遠隔管理する管理装置を制御するコンピュータを、上記被管理装置と通信するための通信手段と、上記被管理装置から上記異常情報を受信して管理し、上記被管理装置から上記異常解消情報を受信し、上記異常情報を受信した場合でも、その異常情報と対応する上記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断する異常情報管理手段として機能させるためのプログラムである。
【００２５】
このようなプログラムにおいて、上記異常情報を、異常の種類毎に異なる情報とし、上記異常解消情報を、その異常情報に対応して、解消された異常の種類毎に異なる情報とし、上記異常情報管理手段に、異常の種類毎にその解消の有無を判断する機能を設けるとよい。
さらに、上記コンピュータを、上記異常情報の受信から第１の所定時間以内に上記異常情報管理手段がその異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生をその管理装置のオペレータに通知する異常通知手段として機能させるためのプログラムをさらに含めるようにするとよい。
【００２６】
あるいは、上記異常情報管理手段に、上記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信する機能を設け、上記コンピュータを、上記異常情報の受信から第１の所定時間以内または、その異常情報の受信後上記第１の所定時間以内にその異常情報の発信元の被管理装置から上記電源ＯＮ通知を受信してかつその受信から第２の所定時間以内に、上記異常情報管理手段が上記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生をその管理装置のオペレータに通知する異常通知手段として機能させるためのプログラムをさらに含むめるようにするとよい。
さらに、上記第２の所定時間を、上記被管理装置の機種に応じて定めるようにするとよい。
さらにまた、上記コンピュータを、管理対象とする被管理装置のユーザ情報を記憶するユーザ情報記憶手段として機能させるプログラムをさらに含め、上記第１の所定時間を、その手段に記憶しているユーザ情報に従って定めるようにするとよい。
【００２７】
また、この発明の管理方法は、自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置を、その被管理装置とネットワークを介して通信可能な管理装置によって遠隔管理する管理方法において、上記管理装置によって上記被管理装置から上記異常情報を受信して管理し、上記被管理装置から上記異常解消情報を受信し、上記異常情報を受信した場合でも、その異常情報と対応する上記異常解消情報を受信した場合には、その異常情報に係る異常は解消されたものと判断するようにしたものである。
このような管理方法において、上記異常情報を、異常の種類毎に異なる情報とし、上記異常解消情報を、その異常情報に対応して、解消された異常の種類毎に異なる情報とし、上記管理装置が異常の種類毎にその解消の有無を判断するようにするとよい。
さらに、上記異常情報の受信から第１の所定時間以内にその異常情報に係る異常が解消されたものと判断しなかった場合にその異常の発生をその管理装置のオペレータに通知するようにするとよい。
【００２８】
あるいは、上記管理装置によって、上記被管理装置が電源をＯＮされた場合に送信する電源ＯＮ通知を受信し、上記異常情報の受信から第１の所定時間以内または、その異常情報の受信後上記第１の所定時間以内にその異常情報の発信元の被管理装置から上記電源ＯＮ通知を受信してかつその受信から第２の所定時間以内に、上記異常情報に係る異常が解消されたものと判断しなかった場合に、その異常の発生をその管理装置のオペレータに通知するようにするとよい。
さらに、上記第２の所定時間を、上記被管理装置の機種に応じて定めるようにするとよい。
さらにまた、上記管理装置に、管理対象とする被管理装置のユーザ情報を記憶させ、上記第１の所定時間をそのユーザ情報に従って定めるようにするとよい。
【発明の効果】
【００２９】
この発明の管理装置、遠隔管理システム、管理方法によれば、被管理装置と管理装置との間にファイアウォールが設けられている場合でも、管理装置で異常の発生とその解消の状況をリアルタイムに把握することができ、適切かつ効率的な管理を行うことができる。また、ユーザ側で簡単に対処可能な異常については管理センタ側でのサポートを省略することができ、異常への対応に要する労力を低減することができる。
また、この発明のプログラムによれば、コンピュータに管理装置を制御させてこのような管理装置の動作と機能を実現し、同様な効果を得ることができる。
【発明を実施するための最良の形態】
【００３０】
以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
まず、この発明による管理装置によって被管理装置の遠隔管理を行う、この発明による通信装置の遠隔管理システムの構成例について説明する。
図１は、その遠隔管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される通信装置（電子装置）を説明の便宜上「被管理装置」と云う。
【００３１】
この遠隔管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，デジタル複合機等の画像形成装置やスキャナ装置を含む画像処理装置、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置（電子装置）を被管理装置１０（１０ａ，１０ｂ，１０ｃ，１０ｄ，１０ｅ，１０ｆ）とする管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）等のネットワークによって接続された遠隔管理仲介装置である仲介装置１０１（１０１ａ，１０１ｂ，１０１ｃ）、更に仲介装置１０１とインタネット１０３（公衆回線又は専用回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。被管理装置１０および仲介装置１０１は機器利用者（ユーザ）側のオフィス等に、管理装置１０２はサービスセンタ（管理センタ）にそれぞれ設置されている。
【００３２】
ここで、管理装置１０２が新たな方式を用いて遠隔管理するサービス（ＮＲＳ）を実現するために、機器利用者側のＬＡＮ等のネットワークに、ＮＲＳに対応するソフトウェアを実装した仲介装置１０１および被管理装置１０が接続されている。その仲介装置１０１および被管理装置１０には、管理装置１０２が従来の方式を用いて遠隔管理するサービス（ＣＳＳ）も実現するために、ＣＳＳに対応するソフトウェアも実装している。ＮＲＳを実現するためには、ＣＳＳを実現する場合と同様に、仲介装置１０１および被管理装置１０を初期設置すればよい。
公衆回線（又は専用回線）としては、アナログ回線，ＡＤＳＬ回線，デジタル回線（ＩＳＤＮ回線），光ファイバー利用回線等の固定電話回線や、携帯電話回線，ＰＨＳ回線等の移動電話回線がある。
なお、仲介装置１０１と被管理装置１０との接続は、ネットワークに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Small Computer System Interface）規格等に準拠したパラレル接続等によって行ってもよい。例えば、ＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。
【００３３】
仲介装置１０１および被管理装置１０は、その利用環境に応じて多様な階層構造を成す。
例えば、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Hyper Text Transfer Protocol）による直接的なコネクションを確立できる仲介装置１０１ａが、被管理装置１０ａおよび１０ｂを従える単純な階層構造になっているが、同図に示す設置環境Ｂでは、４台の被管理装置１０を設置するため、１台の仲介装置１０１を設置しただけでは負荷が大きくなる。そのため、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる仲介装置１０１ｂが、被管理装置１０ｃおよび１０ｄだけでなく、他の仲介装置１０１ｃを従え、この仲介装置１０１ｃが被管理装置１０ｅおよび１０ｆを更に従えるという階層構造を形成している。この場合、被管理装置１０ｅおよび１０ｆを遠隔管理するために管理装置１０２から発せられた情報は、仲介装置１０１ｂとその下位のノードである仲介装置１０１ｃとを経由して、被管理装置１０ｅ又は１０ｆに到達することになる。
【００３４】
また、設置環境Ｃのように、被管理装置１０に仲介装置１０１の機能を併せ持たせた仲介機能付被管理装置（以下単に「被管理装置」ともいう）１１ａ，１１ｂを、別途仲介装置１０１を介さずにインタネット１０３によって管理装置１０２に接続するようにしてもよい。
図示はしていないが、仲介機能付被管理装置１１の下位に更に被管理装置１０を接続することもできる。
なお、各設置環境Ａ，Ｂ，Ｃには、セキュリティ面を考慮し、ファイアウォール１０４（１０４ａ，１０４ｂ，１０４ｃ）を設置する。このファイアウォール１０４は、プロキシサーバによって構成する。
また、各被管理装置１０，１１に、ネットワーク経由でパーソナルコンピュータ等の端末装置や他の電子装置（外部装置）を接続することもできる。
【００３５】
このような遠隔管理システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。
管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
【００３６】
すなわち、仲介装置１０１又はこれと接続された被管理装置１０では、管理装置１０２への要求を生成してこれを管理装置１０２へ引き渡し、この要求に対する応答を取得できる一方で、管理装置１０２は、上記仲介装置１０１側への要求を生成してこれを仲介装置１０１側へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、仲介装置１０１に被管理装置１０に対して各種要求を送信させ、被管理装置１０からの応答を仲介装置１０１を介して取得することも含まれる。
なお、ＲＰＣを実現するために、ＳＯＡＰ（Simple Object Access Protocol），ＨＴＴＰ，ＦＴＰ（File Transfer Protocol）,ＣＯＭ（Component Object Model），ＣＯＲＢＡ（Common Object Request Broker Architecture）等の既知のプロトコル（通信規格），技術，仕様などを利用することができる。
【００３７】
この送受信のデータ送受モデルを図２の概念図に示す。なお、この図においては、ファイアウォール１０４の存在は考慮していない。
（Ａ）は、被管理装置１０で管理装置１０２に対する要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの要求に対する応答ａを返すというモデルになる。同図に示す仲介装置１０１は複数であるケースも想定できる（上記図１に示す設置環境Ｂ）。なお、（Ａ）では、応答ａだけでなく応答遅延通知ａ′を返信するケースが表記されている。これは、管理装置１０２を、仲介装置１０１を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し（通信可能状態を解除し）、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
【００３８】
（Ｂ）は、管理装置１０２で被管理装置１０に対する要求が発生したケースである。このケースでは、管理装置１０２が管理装置側要求ｂを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、当該要求に対する応答ｂを返すというモデルになっている。なお、（Ｂ）のケースでも、応答を即座に返せないときに応答遅延通知ｂ′を返すことは（Ａ）のケースと同様である。
【００３９】
次に、図１に示す管理装置１０２の物理的構成について簡単に説明すると、当該管理装置１０２は、ＣＰＵ，ＲＯＭ，ＲＡＭ等からなる制御装置や、データベース，モデム，プロキシ（Ｐｒｏｘｙ）サーバ等を備えている。その構成については、追って詳細に説明する。
さらに、図１に示す仲介装置１０１における物理的構成について簡単に説明すると、当該仲介装置１０１は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ，不揮発性メモリ，ネットワークインタフェース（ＮＩＣ）等を備えている。
また、仲介機能付被管理装置１１については、仲介装置１０１の機能を実現するためにこれらのユニットを単に被管理装置１０に付加しても良いが、被管理装置１０に備えるＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェア資源を利用し、ＣＰＵに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置１０１の機能を実現することもできる。
【００４０】
以下、図１に示した管理装置のより具体的な例として、この発明による管理装置によって通信装置である画像形成装置の遠隔管理を行う、この発明による通信装置の遠隔管理システムである画像形成装置遠隔管理システムについて説明する。図３は、その画像形成装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像形成装置１００に、仲介機能付被管理装置１１を仲介機能付画像形成装置１１０に変更した点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。
画像形成装置１００は、コピー，ファクシミリ，スキャナ等の機能および外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像形成装置１１０は、画像形成装置１００に仲介装置１０１の機能を併せ持たせたものである。
【００４１】
このような画像形成装置１００の物理的構成について図４を用いて説明する。
図４は、画像形成装置１００内の物理的構成の一例を示すブロック図である。同図に示すように、画像形成装置１００は、コントローラボード２００，ＨＤＤ（ハードディスクドライブ）２０１，ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）２０２，ＰＩ（パーソナルインタフェース）ボード２０３，ＰＨＹ（物理メディアインタフェース）２０４，操作パネル２０５，プロッタ／スキャナエンジンボード２０６，電源ユニット２０７，フィニッシャ２０８，ＡＤＦ（自動原稿給送装置）２０９，給紙バンク２１０，その他周辺機２１１を備えている。これらのユニットは、それぞれがこの画像形成装置１００におけるハードウェア資源である。
【００４２】
ここで、コントローラボード２００は、制御手段に該当し、ＣＰＵ（コントローラＣＰＵ），ＲＯＭ，ＲＡＭ等を備え、ＰＣＩ−ＢＵＳ（Peripheral Components Interconnect-Bus）２１２を介して各機能を制御している。また、ＨＤＤ２０１は、記憶手段に該当する。また、ＮＶ−ＲＡＭ２０２は、記憶手段に該当し、不揮発性メモリであって、例えば、フラッシュメモリ等が該当する。
また、ＰＩボード２０３とＰＨＹ２０４は、通信手段に該当し、外部との通信を行うためのものであって、例えば通信ボード等が該当する。ＰＩボード２０３はＲＳ４８５規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このＰＩボード２０３を用いて画像形成装置１００と仲介装置１０１とを接続することも可能である。ＰＨＹ２０４は、ＬＡＮ等のネットワークを介して外部装置と通信を行うためのインタフェースである。
【００４３】
また、操作パネル２０５は、操作部（操作手段）および表示部（表示手段）に該当するユーザインタフェースである。操作部は、ユーザの操作により各種指示を入力することができる。表示部は、画像形成装置１００の設定状態や動作状態などを表示することができる
ここで、同図中のＥＮＧＲＤＹは、エンジンユニット（プロッタエンジン，スキャナエンジン）側の各種初期設定が完了して、コントローラボード２００とコマンドの送受信の準備ができたことをコントローラボード２００側に通知するための信号線である。また、ＰＷＲＣＴＬは、エンジンユニットへの電源供給をコントローラボード２００側から制御するための信号線である。これら信号線の動作に関しては後述する。
【００４４】
次に、画像形成装置１００におけるソフトウェア構成を図５を用いて説明する。
図５は、画像形成装置１００のソフトウェア構成の一例を示すブロック図である。
この画像形成装置１００のソフトウェア構成は、アプリケーションモジュール層，サービスモジュール層，汎用ＯＳ層からなる。そして、これらのソフトウェアを構成するプログラムはＨＤＤ２０１やコントローラボード２００上のＲＡＭに記憶され、必要に応じて読み出されてコントローラボード２００上のＣＰＵによって実行される。そして、そのＣＰＵは、これらのプログラムを必要に応じて実行し、装置の制御を行うことにより、この発明による各機能（異常通知手段，異常解消通知手段，電源ＯＮ通知手段としての機能）を実現することができる。
【００４５】
アプリケーションモジュール層のソフトウェアは、コントローラボード２００上のＣＰＵ（コントローラＣＰＵ）を、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、コントローラＣＰＵを、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段（処理実行手段）として機能させるためのプログラムによって構成される。
【００４６】
なお、コントローラＣＰＵの機能のうち、管理装置１０２との通信に係わる機能（通信手段としての機能）の実現方法は、画像形成装置１００と画像形成装置１１０とによって異なる。つまり、画像形成装置１１０の場合は、仲介装置１０１の機能を備えているため、コントローラＣＰＵが対応するプログラムを実行することにより、管理装置１０２との通信に係わる機能を実現することができる。画像形成装置１００の場合には、コントローラＣＰＵが対応するプログラムを実行すると共に、仲介装置１０１を利用することにより、管理装置１０２との通信に係わる機能を実現することができる。
また、画像形成装置１００は、スキャナエンジンおよびプロッタエンジンを含むエンジンユニット内にセンサ等からなる異常検出部（異常検出手段）を備えている。
【００４７】
サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００、エンジンコントロールサービス（ＥＣＳ）３０１、メモリコントロールサービス（ＭＣＳ）３０２、ネットワークコントロールサービス（ＮＣＳ）３０３、ファクスコントロールサービス（ＦＣＳ）３０４、システムコントロールサービス（ＳＣＳ）３０６、システムリソースマネージャ（ＳＲＭ）３０７、イメージメモリハンドラ（ＩＭＨ）３０８、デリバリーコントロールサービス（ＤＣＳ）３１６、ユーザコントロールサービス（ＵＣＳ）３１７を実装している。また、アプリケーションモジュール層には、ＮＲＳアプリ（以下単に「ＮＲＳ」という）３０５、ＣＳＳアプリ（以下単に「ＣＳＳ」という）３１５、コピーアプリ３０９、ファクスアプリ３１０、プリンタアプリ３１１、スキャナアプリ３１２、ネットファイルアプリ３１３、ウェブアプリ３１４を実装している。更に、汎用ＯＳ層には、汎用ＯＳ３２０を実装している。
【００４８】
これらを更に詳述する。
ＯＣＳ３００は、操作パネル２０５を制御するモジュールである。
ＥＣＳ３０１は、ハードウェアリソース等のエンジンユニットを制御するモジュールである。
ＭＣＳ３０２は、メモリ制御をするモジュールであり、例えば、画像メモリの取得および開放、ＨＤＤ２０１の利用等を行う。
ＮＣＳ３０３は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
ＦＣＳ３０４は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。
【００４９】
ＳＣＳ３０６は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理および終了管理を行うモジュールである。
ＳＲＭ３０７は、システムの制御およびリソースの管理を行うモジュールである。
ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。
ＣＳＳ３１５は、公衆回線を介してデータを送受信する際のデータの変換等をするモジュールであり、また公衆回線を介した遠隔管理に関する機能をまとめたモジュールである。
ＤＣＳ３１６は、ＨＤＤ２０１やコントローラボード２００上のメモリに記憶している（する）画像ファイル等をＳＭＴＰ（Simple Mail Transfer Protocol）やＦＴＰ（File Transfer Protocol）を用いて送受信するモジュールである。
ＵＣＳ３１７は、ユーザ（機器利用者）が登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
【００５０】
ＮＲＳ３０５およびＣＳＳ３１５はそれぞれ、互いに異なる方式による遠隔管理に関する機能（管理装置１０２との通信に係わる機能）をまとめたモジュールである。
コピーアプリ３０９は、コピーサービスを実現するためのアプリケーションプログラムである。
ファクスアプリ３１０は、ファクスサービスを実現するためのアプリケーションプログラムである。
プリンタアプリ３１１は、プリンタサービスを実現するためのアプリケーションプログラムである。
スキャナアプリ３１２は、スキャナサービスを実現するためのアプリケーションプログラムである。
【００５１】
ネットファイルアプリ３１３は、ネットファイルサービスを実現するためのアプリケーションプログラムである。
ウェブアプリ３１４は、ウェブサービスを実現するためのアプリケーションプログラムである。
汎用ＯＳ３２０は、ＵＮＩＸ（登録商標），Ｌｉｎｕｘ（登録商標），Ｗｉｎｄｏｗｓ（登録商標）等のオペレーティングシステムを使用することができる。オペレーティングシステムは、サービスモジュール層やアプリケーションモジュール層のプログラムなどを実行させる処理を司る。ここで、ＵＮＩＸやＬｉｎｕｘを用いれば、オープンソースゆえの安全性が担保され、ソースコード入手の容易性などの利点がある。
【００５２】
ここで、上述したＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号との動作について、図６を用いて説明する。
図６の（Ａ）は機器の立ち上がり時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。主電源スイッチ（ＡＣ−ＰＯＷＥＲ−ＳＷ）のＯＮにより、ＡＣ−ＰＯＷＥＲ（ＡＣ１００Ｖ）の電源部から電源ユニット（主電源）２０７へ給電される（ＡＣ電源がＯＮになる）と、電源ユニット２０７がＯＮ状態になり、電源ユニット２０７からコントローラボード２００を含む装置全体への給電が開始され、これと同時にＥＮＧＲＤＹ信号はＨｉｇｈになる。この状態ではエンジンユニット側との通信はできない。なぜなら、エンジンユニット側の初期設定が完了していないからである。そして、一定期間経過後にエンジンユニット側の初期設定が完了し、ＥＮＧＲＤＹ信号がＬｏｗになった段階でエンジンユニット側との通信が可能となる。
【００５３】
次に、同図（Ｂ）は省エネモードに移行した時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。電源ユニット２０７がＯＮ状態の時（電源ユニット２０７から装置全体への給電中）に、例えば操作パネル２０５上の図示しないソフト電源キーの操作により、ハードユニットであるエンジンユニットへの給電停止が指示されると、省エネモードに移行するため、コントローラボード２００によりＰＷＲＣＴＬ信号をＯＦＦにする。これと同時に、電源ユニット２０７からエンジンユニットへの給電が停止する。これに伴って、ＥＮＧＲＤＹ信号は、Ｈｉｇｈとなり省エネモードに移行する。次に、省エネモードから復帰する場合を同図（Ｃ）に示す。
【００５４】
同図（Ｃ）は、省エネモードから復帰する時のＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号の動作の一例を示している。上記（Ｂ）の省エネモードから復帰する際には、例えばソフト電源キーの操作によってエンジンユニットへの給電停止の解除が指示され、コントローラボード２００によりＰＷＲＣＴＬ信号をＯＮにする。これと同時に、電源ユニット２０７からエンジンユニットへの給電停止が解除される。しかし、上記の（Ａ）で示したように、エンジンユニット側の初期設定が完了するまで、ＥＮＧＲＤＹ信号はＨｉｇｈの状態であり、初期設定が完了するとエンジンユニット側との通信が可能となり、Ｌｏｗとなる。
【００５５】
次に、上述した画像形成装置１００のソフトウェアの構成に含まれるＮＲＳモジュールの内部構成について、図７を用いて更に説明する。
図７は、ＮＲＳ３０５の構成の一例を示す機能ブロック図である。同図に示すように、ＮＲＳ３０５は、ＳＣＳ３０６とＮＣＳ３０３との間で処理を行っている。ウェブサーバ機能部５００は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるＸＭＬ（Extensible Markup Language）形式で記載された、ＳＯＡＰ（Simple Object Access Protocol）によるＳＯＡＰリクエストであることが考えられる。ウェブクライアント機能部５０１は、外部への要求を発行する処理を行う。ｌｉｂｓｏａｐ５０２は、ＳＯＡＰを処理するライブラリであり、ｌｉｂｘｍｌ５０３は、ＸＭＬ形式で記載されたデータを処理するライブラリである。また、ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。
【００５６】
次に、管理装置１０２の物理的構成について、図８を参照して説明する。
図８は、管理装置１０２の概略構成例を示すブロック図である。
この管理装置１０２は、モデム６０１，通信端末６０２，プロキシ（Ｐｒｏｘｙ）サーバ６０３，操作者端末６０４，データベース６０５，制御装置６０６等からなる。
モデム６０１は、公衆回線を介して機器利用者側（例えば画像形成装置を利用しているユーザ先）の仲介装置１０１（又は画像形成装置１１０）やラインアダプタとの通信を司るものであり、送受信するデータを変復調する。このモデム６０１と後述する通信端末６０３により通信手段としての機能を果たす。
通信端末６０２は、モデム６０１による通信を制御するものである。
【００５７】
プロキシサーバ６０３は、インタネット１０３を介してユーザ（機器利用者）側の仲介装置１０１との通信（データ送受信）およびセキュリティ管理を行う。このプロキシサーバ６０３も、通信手段としての機能を果たす。
操作者端末６０４は、サービスセンタの管理者であるセンタオペレータが操作する端末であり、各種データの入力をセンタオペレータによるキーボードやポインティングデバイス（マウス等）等の入力部上の操作により受け付けたり、センタオペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各ユーザ側の仲介装置１０１又は画像形成装置１１０が管理装置１０２へ通信する際に使用するＩＰアドレスや発呼先電話番号等の顧客情報がある。
【００５８】
データベース６０５は、図示しないサーバのＨＤＤ（ハードディスク装置）等の記憶装置に存在し、各ユーザ側の仲介装置１０１および画像形成装置１１０のＩＰアドレスや電話番号、それらの装置から受信した異常情報等のデータ、操作者端末６０４から入力されたデータ、後述する機種データベースや顧客データベース、およびこの発明に係るプログラム等の各種データを記憶する。
制御装置６０６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、上記プログラムを必要に応じて実行すると共に、モデム６０１，通信端末６０２，プロキシサーバ６０３，操作者端末６０４，又はデータベース６０５を利用することにより、この発明による機能（通信手段，異常情報管理手段，異常通知手段，その他の手段としての機能）を実現することができる。
【００５９】
上述した構成を踏まえて、図３の画像形成装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例について、図９を用いて説明する。なお、以下に示すＳＣＳ３０６およびＮＲＳ３０５による処理は、実際にはコントローラＣＰＵがそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。以後も、プログラムが何らかの処理を行うものとして説明を行う場合には、同様とする。
図９は、図３に示した管理装置１０２，仲介装置１０１，および画像形成装置１００間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
【００６０】
この例においては、まず、仲介装置１０１は、インタネット１０３経由で管理装置１０２に対してポーリング（送信要求があるかどうかの問い合わせ）を行う（Ｓ６０１）。つまり、自己の識別情報である識別子を付加したポーリング用のＳＯＡＰメッセージを生成し（ポーリング情報を構造化言語形式であるＸＭＬ形式に変換し）、そのＳＯＡＰメッセージに基づいてそれを含むＨＴＴＰメッセージを生成し、それをインタネット１０３経由で管理装置１０２へ送信する。図３に示したように、仲介装置１０１と管理装置１０２との間にはファイアウォール１０４を設けているため、管理装置１０２から仲介装置１０１に向けて通信セッションを張ることができないので、管理装置１０２から仲介装置１０１（あるいは仲介装置１０１を介して画像形成装置１００）に要求を送信したい場合でも、このように仲介装置１０１からのポーリング（送信要求があるかどうかの問い合わせ）を待つ必要があるのである。なお、ファイアウォール１０４がなければ、ポーリングを行う必要はない。
【００６１】
管理装置１０２は、仲介装置１０１から上記ＨＴＴＰメッセージ（ＨＴＴＰリクエスト）を受信すると、課金カウンタ（カウンタ情報）取得要求を示す情報のＳＯＡＰメッセージを含むＨＴＴＰメッセージ（ＨＴＴＰレスポンス）を生成し、それをインタネット１０３経由で該当する仲介装置１０１（受信したＳＯＡＰメッセージの送信元）へ、ポーリングに対する応答として送信する（Ｓ６０２）。このとき、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいて該当する仲介装置１０１を認識する。このように、ファイアウォール１０４の内側からの通信（ＨＴＴＰリクエスト）に対する応答（ＨＴＴＰレスポンス）であれば、ファイアウォール１０４の外側から内側に対してデータを送信することができる。
【００６２】
仲介装置１０１は、管理装置１０２から上記ＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてそのパケット上の課金カウンタ取得要求を示す情報のＳＯＡＰメッセージを生成し、それをネットワーク経由で自己に接続されている画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ６０３）。
ＮＲＳ３０５は、仲介装置１０１から受信したＳＯＡＰメッセージに記述されている課金カウンタ取得要求をＳＣＳ３０６へ通知する（Ｓ６０４）。
ＳＣＳ３０６は、ＮＲＳ３０５から課金カウンタ取得要求の通知を受けると、ＮＶ−ＲＡＭ２０２（又はＨＤＤ２０１）に格納されている課金カウンタのデータを読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータ（応答データ）をＮＲＳ３０５へ引き渡す（Ｓ６０６）。
【００６３】
ＮＲＳ３０５は、ＳＣＳ３０６から課金カウンタのデータ（カウンタ値を示すカウンタ情報）を受け取る（取得する）と、その内容を示す課金カウンタ用のＳＯＡＰメッセージを生成し（受け取ったデータを構造化言語形式であるＸＭＬ形式に変換し）、それをネットワーク経由で仲介装置１０１へ送信する（Ｓ６０７）。
仲介装置１０１は、ＮＲＳ３０５から課金カウンタ用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに基づいてそれを含むＨＴＴＰメッセージを生成し、それをインタネット１０３経由で管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。
【００６４】
次に、上記図９と異なり、画像形成装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について、図１０を参照して説明する。
図１０は、画像形成装置１００から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、ＯＣＳ３００は、操作パネル２０５上の図示しないユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
ＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をＮＲＳ３０５へ通知する（Ｓ７０２）。
【００６５】
ＮＲＳ３０５は、ＳＣＳ３０６からユーザコール要求の通知を受けると、ユーザコールを知らせるユーザコール情報であるユーザコール用のＳＯＡＰメッセージを生成し、それをネットワーク経由で仲介装置１０１へ送信する（Ｓ７０３）。
仲介装置１０１は、ＮＲＳ３０５からユーザコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である識別子を付加し、更にそのＳＯＡＰメッセージに基づいてそれを含むＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対してユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由で管理装置１０２へ通報する（Ｓ７０４）。この場合には、ファイアウォール１０４の内側から外側に向けての送信であるので、仲介装置１０１が自ら管理装置１０２に向けてセッションを張ってデータを送信することができる。
ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。
【００６６】
まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合には、その旨（ユーザコールが成功した旨）のコール結果を、正常に終了しなかった（異常に終了した）場合には、その旨（ユーザコールが失敗した旨）のコール結果を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、それを応答としてインタネット１０３経由で通報元の仲介装置１０１へ送信する（Ｓ７０５）。
仲介装置１０１は、管理装置１０２からコール結果を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてそのパケット上のコール結果を示すＳＯＡＰメッセージを生成し、それをネットワーク経由でユーザコールキーが押下された画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ７０６）。
【００６７】
ＮＲＳ３０５は、仲介装置１０１からコール結果を示すＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージが示すコール結果を解釈（判定）し、それをＳＣＳ３０６へ通知する（Ｓ７０７）。
ＳＣＳ３０６は、コール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７０８）。
【００６８】
次に（Ｂ）において、仲介装置１０１は、規定時間（予め設定された所定時間）が経っても管理装置１０２から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すＳＯＡＰメッセージを生成し、それをＮＲＳ３０５へ送信する（Ｓ７０９）。
ＮＲＳ３０５は、失敗した旨のコール結果を示すＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに記述されている失敗した旨のコール結果を解釈し、それをＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
【００６９】
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１１）。
次に（Ｃ）において、ＮＲＳ３０５は、規定時間が経っても仲介装置１０１から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をＳＣＳ３０６へ通知する（Ｓ７１２）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１３）。
【００７０】
なお、ここでは管理装置１０２からファイアウォール１０４を越えて仲介装置１０１（あるいは仲介装置１０１を介して画像形成装置１００）にデータを送信するために、仲介装置１０１からのＨＴＴＰリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール１０４を越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
【００７１】
次に、このような基本的な機能を有する図３に示した画像形成装置遠隔管理システムにおけるこの発明の特徴に係る動作である、管理装置（管理装置１０２）が被管理装置（画像形成装置１００）から異常通知（ＳＣコール）を受信して管理する動作およびそのために必要な構成について説明する。
この遠隔管理システムにおける被管理装置である画像形成装置１００には、上述したように、公衆回線に対応した通信手段とネットワーク通信に対応した通信手段の双方を設けている。
【００７２】
そして、画像形成装置１００は、仲介装置１０１および公衆回線を介して管理装置１０２と通信するＣＳＳ方式による遠隔管理（リモートサービス：ＲＳ）と、仲介装置１０１およびインタネット１０３を介して管理装置１０２と通信するＮＲＳ方式による遠隔管理の対象となり得るように構成している。画像形成装置１１０は、仲介装置１０１の機能を備えているため、公衆回線を介して管理装置１０２と通信するＣＳＳ方式による遠隔管理と、インタネット１０３を介して管理装置１０２と通信するＮＲＳ方式による遠隔管理の対象となり得るように構成している。
【００７３】
ここで、画像形成装置１００および仲介機能付画像形成装置１１０は、自己のエンジンユニットの状態等の情報を送信したり、自己のエンジンユニット等に異常が発生した場合に管理装置に通知（通報）したり等するためのプログラムとして、上記のＣＳＳ方式に対応したＣＳＳ３１５と、上記のＮＲＳ方式に対応したＮＲＳ３０５とを設けている。
以下、説明の都合上、画像形成装置１００がＮＲＳ３０５を使用する場合の動作について説明する。なお、画像形成装置１００がＣＳＳ３１５を使用することによってもこの発明に関わる制御を行うことができる。また、画像形成装置１１０がＮＲＳ３０５又はＣＳＳ３１５を使用することによってもこの発明に関わる制御を行うことができる。
【００７４】
図１１は、この遠隔管理システムにおいて管理装置１０２が画像形成装置１００の管理に必要な情報を画像形成装置１００から受信する際の通信シーケンスを示すシーケンス図である。
画像形成装置１００では、エンジンユニット内にセンサ等の異常検出手段による異常検出部を備えており、エンジンユニット内で異常が発生すると、対応する異常検出部がその異常を例えばＳＣ（サービスマンコール）として検出し、ＳＣ（異常）が発生した旨をコントローラボード２００のＳＣＳ３０６へ通知する（Ｓ８０１）。
ＳＣＳ３０６は、エンジンユニットからＳＣが発生した旨の通知を受けると、エンジンユニット内でＳＣが発生したと判定し、ＮＲＳ３０５に対してＳＣコール（異常を通知する異常情報の自動通報）の送信要求を発行する（Ｓ８０２）。
【００７５】
ＮＲＳ３０５は、ＳＣＳ３０６からＳＣコールの送信要求を受けると、ＳＣコールを開始する旨をＳＣＳ３０６へ通知する（Ｓ８０３）と共に、ＳＣコール用のＳＯＡＰメッセージを異常を通知する異常情報として生成して仲介装置１０１へ送信する（Ｓ８０４）。
ＳＣＳ３０６は、ＳＣコールを開始する旨の通知を受けると、操作パネル２０５上の文字表示器に、ＳＣコールを管理装置１０２に送信した旨のメッセージを表示する。
【００７６】
仲介装置１０１は、ＮＲＳ３０５からＳＣコール用のＳＯＡＰメッセージを受信すると、コール受付ＯＫをＮＲＳ３０５へ通知する（Ｓ８０５）と共に、そのＳＯＡＰメッセージに自己の識別情報である識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対してＳＣコールを行う（Ｓ８０６）。つまり、自己の識別子を付加したＳＣコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由で管理装置１０２へ自動通報（自動送信）する。
ここでは、特にＳ８０２とＳ８０４の処理において、画像形成装置１００のコントローラボード２００に備えたＣＰＵ（以後「画像形成装置のＣＰＵ」と言った場合にはこのＣＰＵを指すものとする）が、ＳＣＳ３０６とＮＲＳ３０５とを実行することにより、異常通知手段として機能する。
【００７７】
なお、ＳＣＳ３０６は、操作パネル２０５上のキー操作等によってＳＣコールを行わない設定がなされていた場合には、エンジンユニットからＳＣが発生した旨の通知を受けても、ＳＣが発生した旨をＳＣＳ３０６へ通知しない。そして、その場合には、操作パネル２０５上の文字表示器に故障が発生した旨のメッセージを表示し、ユーザにサービスセンタへの連絡等の対応を促す。
【００７８】
一方、管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から送信されたＳＣコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合には、その旨（ＳＣコールに対する処理が成功した旨）のコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいてインタネット１０３経由で送信元の仲介装置１０１（ＳＣコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する（Ｓ８０７）。
【００７９】
また、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージから必要な情報（ＳＣ情報）を抽出してデータベース６０５の異常情報キューに格納して記憶し、そのＳＣ情報に係る異常が解消されたものと判断するまでキューイングしてその異常情報を管理する。
ここでは、管理装置１０２の制御装置６０６に備えるＣＰＵ（以後「管理装置のＣＰＵ」と言った場合にはこのＣＰＵを指すものとする）が所要のプログラムを実行することにより、管理装置１０２の各部を制御して異常情報管理手段として機能する。
【００８０】
また、この時点で受信したＳＣ情報の内容を操作者端末６０４の表示部に表示してセンタオペレータに知らせるようにしてもよいが、従来の技術の項で述べたように異常が発生した場合でも管理センタ側で何ら対応を要さない場合もあるので、後述のように対応が必要と判断した場合に初めてセンタオペレータに通知するようにするとよい。ＳＣコールを受信した時点でＳＣ情報の内容を通知する場合には、対応が必要と判断した場合に、表示の色を変えたり警告音を鳴らしたりして特にセンタオペレータの注意を喚起するようにするとよい。
いずれかの機器利用者側の仲介装置１０１から送信されたＳＯＡＰメッセージを含むＨＴＴＰメッセージの受信が正常に終了しなかった場合（異常に終了した場合）には、その旨（ＳＣコールに対する処理が失敗した旨）のコール結果を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいてインタネット１０３経由で通報元の仲介装置１０１へ送信する。
【００８１】
仲介装置１０１は、管理装置１０２へのＳＣコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報に対して、その管理装置１０２からそのＨＴＴＰメッセージの受信が正常に終了した旨のコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコール結果（ＯＫ）を示すＳＯＡＰメッセージを生成し、該当する（ＳＣが発生した）画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ８０８）。
そのＮＲＳ３０５は、仲介装置１０１からコール結果（ＯＫ）を示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へＳＣコールが正常に終了した旨を通知する（Ｓ８０９）。
【００８２】
ＳＣＳ３０６は、ＮＲＳ３０５からＳＣコール（ＳＣコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの送信）が正常に終了した旨の通知を受けると、操作パネル２０５上の文字表示器にＳＣコールが成功した旨のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２上のＳＣコールの成功を示すＳＣコール済みフラグ（異常送信済み状態）を“１”にセット（設定）する（Ｓ８１０）。ＳＣコール済みフラグは、ＳＣの種類（コード）毎に設けても、コードによらず１つのフラグとしてもよいが、ここではコード毎に設けるものとする。
【００８３】
その後、エンジンユニットの異常検出部は、異常が解消したか否かも含め、異常の監視を続ける。そして、従来の技術の項で述べたように、電源の再投入のみで異常が解消される場合もしばしばある。
図１１のＳ８１１以降は、電源のＯＦＦ／ＯＮ（電源の再投入）によって画像形成装置の異常が解消し、それによってＳＣが解除された場合のシーケンスを示している。なお、以降のシーケンスにおいて、ＳＣコールの場合のＳ８０３やＳ８０５に相当する通知は示していないが、同様な通知を行うようにしてもよい。通知（コール）が正常に行われなかった場合の処理についても同様である。
画像形成装置１００の電源がＯＮされ、システムの初期化が完了して通信が可能になると、ＳＣＳ３０６は、まずＮＲＳ３０５に対して電源がＯＮされたことを示す電源ＯＮ通知の送信要求を発行する（Ｓ８１１）。
ＮＲＳ３０５は、ＳＣＳ３０６からの電源ＯＮ通知の送信要求を受けると、電源ＯＮ通知用のＳＯＡＰメッセージを生成して仲介装置１０１へ送信する（Ｓ８１２）。
【００８４】
仲介装置１０１は、ＮＲＳ３０５から電源ＯＮ通知用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対して電源ＯＮ通知を送信する（Ｓ８１３）。つまり、自己の識別子を付加した電源ＯＮ通知用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由で管理装置１０２へ自動送信する。
ここでは、特にＳ８１１とＳ８１２の処理において、画像形成装置のＣＰＵが、ＳＣＳ３０６とＮＲＳ３０５とを実行することにより、電源ＯＮ通知手段として機能する。
【００８５】
なお、ＳＣＳ３０６は、起動時に図１２のフローチャートに示す初期化処理を行うものとし、所要の初期化動作後、ＳＣコールによる異常の自動通報モードがＯＮ（有効）になっている場合のみ電源ＯＮ通知を行うようにしている。後述するように、電源ＯＮ通知は管理装置１０２側で画像形成装置１００の異常の解消の有無を判断するために用いる通知であるので、自動通報を行わない場合には特に意味の無い通知になってしまうからである。
また、ＳＣコール済みフラグがＯＮでない場合も、電源ＯＮ通知を行わないようにしてもよい。後述のように、電源ＯＮ通知は、管理装置１０２が管理している異常情報の送信元からの送信された場合のみ、管理装置１０２における管理動作に有効に利用されるからである。
これらのように、不要な場合に電源ＯＮ通知を省略することにより、システムにおける処理負担や通信トラフィックを低減することができる。
【００８６】
一方、管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から送信された電源ＯＮ通知用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合には、その旨（電源ＯＮ通知に対する処理が成功した旨）のコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいてインタネット１０３経由で送信元の仲介装置１０１（電源ＯＮ通知用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する（Ｓ８０７）。
ここでは、管理装置１０２のＣＰＵが所要のプログラムを実行することにより、管理装置１０２の各部を制御して電源ＯＮ通知受信手段として機能する。また、制御装置６０６は受信したＨＴＴＰメッセージ内の電源ＯＮ通知の情報を抽出し、異常情報の管理動作に反映させるが、その詳細は後述する。
【００８７】
仲介装置１０１は、管理装置１０２から電源ＯＮ通知に係るＨＴＴＰメッセージの受信が正常に終了した旨のコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコール結果（ＯＫ）を示すＳＯＡＰメッセージを生成し、該当する（ＳＣが発生した）画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ８１５）。
そのＮＲＳ３０５は、仲介装置１０１からコール結果（ＯＫ）を示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へ電源ＯＮ通知が正常に終了した旨を通知する（Ｓ８１６）。
【００８８】
一方、電源がＯＮされると、エンジンユニットも初期化処理を行うと共に、異常検出部によって各部の状態をチェックし、その状態をＳＣＳ３０６に通知する。ここでは異常は解消しているので、ＳＣＳ３０６にレディを通知する（Ｓ８１７）。ＳＣＳ３０６はそれらの通知を受けることによりＳＣがないことを確認できる。そして、その場合に、ＳＣコール済みフラグの状態をチェックし（Ｓ８１８）、ＳＣコール済みフラグが“１”にセットされていることを確認できた場合に、ＮＲＳ３０５に対してＳＣ解除コール（異常の解消を知らせる異常解消情報の自動通報）の送信要求を発行する（Ｓ８１９）。
なお、エンジンの各部に設けた各種センサが個々にＳＣＳ３０６にレディを通知するようにすれば、ＳＣＳ３０６は装置のどの部分が異常でどの部分が正常であるかを認識することができる。従って、全体としては異常な箇所が残っている場合でも、一部の箇所について異常が解消した場合にその旨のＳＣ解除コールを送信するようにすることも可能である。
【００８９】
ＮＲＳ３０５は、ＳＣＳ３０６からＳＣ解除コールの送信要求を受けると、ＳＣ解除コール用のＳＯＡＰメッセージを異常の解消を通知する異常解消情報として生成して仲介装置１０１へ送信する（Ｓ８２０）。
仲介装置１０１は、ＮＲＳ３０５からＳＣ解除コール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対してＳＣ解除コールを送信する（Ｓ８２１）。つまり、自己の識別子を付加したＳＣ解除コール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由で管理装置１０２へ自動送信する。
ここでは、特にＳ８１９とＳ８２０の処理において、画像形成装置のＣＰＵが、ＳＣＳ３０６とＮＲＳ３０５とを実行することにより、異常解消通知手段として機能する。
【００９０】
管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から通報されたＳＣ解除コール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合に、その旨（ＳＣ解除コールに対する処理が成功した旨）のコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいてインタネット１０３経由で通報元の仲介装置１０１（ＳＣ解除コール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する（Ｓ８２２）。
ここでは、管理装置１０２のＣＰＵが所要のプログラムを実行することにより、管理装置１０２の各部を制御して異常解消情報受信手段として機能する。また、制御装置６０６は受信したＨＴＴＰメッセージ内の異常解消情報を抽出し、異常情報の管理動作に反映させ、例えば所定の場合にＳＣ情報を異常情報キューから自動削除するが、その詳細は後述する。
【００９１】
仲介装置１０１は、管理装置１０２へのＳＣ解除コール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報に対して、その管理装置１０２からコール結果（ＯＫ）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコール結果（ＯＫ）を示すＳＯＡＰメッセージを生成し、該当する画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ８２３）。
そのＮＲＳ３０５は、仲介装置１０１からコール結果（ＯＫ）を示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へＳＣ解除コールが正常に終了した旨を通知する（Ｓ８２４）。
ＳＣＳ３０６は、ＮＲＳ３０５からＳＣ解除コールが正常に終了した旨の通知を受けると、ＮＶ−ＲＡＭ２０２上のＳＣコール済みフラグを“０”にリセット（解除）する（Ｓ８２５）。
【００９２】
図３に示した画像形成装置の遠隔管理システムにおいては、以上のようなシーケンスで画像形成装置１００から管理装置１０２に送信されるＳＣコール（異常情報），電源ＯＮ通知，ＳＣ解除コール（異常解消情報）を用いて管理装置１０２側で画像形成装置１００についての異常情報を管理する。
なお、ＳＣ解除コールは、必ずしも電源の再投入があった後に送信されるわけではなく、異常検出手段が異常の解消を検出した場合には、電源の操作とは関係なくＳＣ解除コールを行う。
【００９３】
ところで、上述したＨＴＴＰメッセージ内のＳＣコール用，電源ＯＮ通知用，ＳＣ解除コール用のＳＯＡＰメッセージは、例えば構造化言語によるＸＭＬ形式で記述することができるが、このＳＯＡＰメッセージ（仲介装置１０１の識別子は除く）のフォーマット例について、図１３乃至図１８を参照してそれぞれ簡単に説明する。
【００９４】
まず、図１３にＨＴＴＰメッセージ内のＳＣコール用のＳＯＡＰメッセージのフォーマット例を、図１４にその主要部分（データ）の構成をそれぞれ示す。
これらの図を見て分かるように、ＳＣコール用のＳＯＡＰメッセージは、そのコールがＳＣコールであることを示すコール種別情報、ＳＣが発生した画像形成装置１００の識別情報である機番情報、コールの番号を示すコールＩＤ、後述するＳＣコールのタイプを示すＳＣタイプ情報、ＳＣの種類を示すＳＣコード情報を含む。そして、その他付加情報として、ＳＣが発生した画像形成装置１００のジャムやＳＣ，ステータス（状態），カウンタのそれぞれの値およびログ（履歴情報）等の情報を含めることもできる。異常（ＳＣ）の種類毎にＳＣコード情報は異なるため、ＳＣコール用のＳＯＡＰメッセージは、異常の種類毎に異なる情報となる。
なお、ＳＣタイプ情報については、管理装置１０２側にＳＣコード情報とＳＣタイプ情報との対応関係を記憶させておき、ＳＣコード情報をキーとして取得できるようにしておけば、必ずしもＳＣコール用のＳＯＡＰメッセージに含める必要はない。また、機番情報には、必要に応じて画像形成装置１００の機種を示す情報も含めて機種機番情報とする。
【００９５】
次に、図１５にＨＴＴＰメッセージ内の電源ＯＮ通知用のＳＯＡＰメッセージのフォーマット例を、図１６にその主要部分（データ）の構成をそれぞれ示す。
これらの図を見て分かるように、電源ＯＮ通知用のＳＯＡＰメッセージは、そのコールが電源ＯＮ通知であることを示すコール種別情報、電源ＯＮ通知を行う画像形成装置１００の識別情報である機番情報、コールの番号を示すコールＩＤを含む。そして、ＳＣコールの場合と同様にその他付加情報を含めることもできる。
【００９６】
さらに、図１７にＨＴＴＰメッセージ内のＳＣ解除コール用のＳＯＡＰメッセージのフォーマット例を、図１８にその主要部分（データ）の構成をそれぞれ示す。
これらの図を見て分かるように、ＳＣ解除コールのＳＯＡＰメッセージは、そのコールがＳＣ解除コールであることを示すコール種別情報、ＳＣ解除コールを行う画像形成装置１００の識別情報である機番情報、コールの番号を示すコールＩＤ、解消したＳＣの種類を示すＳＣコード情報を含む。そして、ＳＣコールの場合と同様にその他付加情報を含めることもできる。ＳＣコード情報はＳＣコールの場合と同様なコード体系を用いるものとし、従ってＳＣ解除コールは、ＳＣコールに対応して、解消された異常の種類毎に異なる情報となる。
【００９７】
管理装置１０２による、以上のようなＳＣコール，電源ＯＮ通知，ＳＣ解除コールを用いた異常情報の管理は、概ね図１９乃至図２１に示す手順で行う。なお、これらの図においては、画像形成装置１００内部の処理及び画像形成装置１００と管理装置１０２との間のデータ転送経路の図示は省略している。
まず、図１９に、画像形成装置においてＳＣ発生後、電源の再投入によってＳＣが解消した場合の例を示す。
画像形成装置１００で異常（ＳＣ）が発生した場合（Ｓ９０１）、画像形成装置１００はこの異常の情報をＳＣコールとして管理装置１０２に通知し（Ｓ９０２）、管理装置１０２はその応答結果を返す（Ｓ９０３）と共に、そのＳＣコールに含まれるＳＣ情報をデータベース６０５の異常情報キューに記憶させる（Ｓ９０４）ことは、図１１を用いて説明した通りである。
【００９８】
図２２に異常情報キューにおけるＳＣ情報（異常情報）の記憶形式の例を示す。これらの情報のうち、機種機番、ＳＣのコード（発生ＳＣ）、ＳＣのタイプはＳＣコールに含まれるデータから抽出し、ＳＣ受信日時は制御装置６０６の内部タイマから取得する。また、電源ＯＮフラグ（電源ＯＦＦ／ＯＮ）は、図１９乃至図２１では処理の図示を省略しているが、ＳＣ情報を記憶させた後で電源ＯＮ通知を受信した場合にセットする。管理装置１０２がＳＣコールを受信した場合、これらの情報を抽出あるいは取得して異常情報キューに記憶させる。
しかし、この時点では操作者端末６０４の表示部への表示等によるセンタオペレータへの通知は行わず、ＳＣコールと対応するＳＣ解除コールあるいはＳＣコールの送信元からの電源ＯＮ通知の受信を待つ。
【００９９】
一方、画像形成装置１００側で電源の再投入が行われると、画像形成装置１００は管理装置１０２に対して電源ＯＮ通知を送信し（Ｓ９０６）、管理装置１０２はこれに対する応答を返す（Ｓ９０７）。
この電源の再投入によって異常が解消した場合には、画像形成装置１００は管理装置１０２に対してＳＣ解除コールを送信し（Ｓ９０８）、管理装置１０２はこれに対する応答を返す（Ｓ９０８）。
【０１００】
ここで、画像形成装置１００で後述するタイプＡの異常が発生した場合の制御について、簡単に説明しておく。
画像形成装置１００で後述するタイプＡの異常が発生した場合、その異常は電源の再投入によっても解消できない。
画像形成装置１００のコントローラＣＰＵ（コントローラボード２００のＣＰＵ）は、装置内で異常が発生すると、その異常のタイプを判定し、そのタイプを示すタイプ情報を不揮発性メモリであるＮＶ−ＲＡＭ２０２（又はＨＤＤ２０１）に記憶する。それによって、タイプＡの異常が発生した場合には、その異常に対応する状態（異常状態）を維持することができる。
【０１０１】
画像形成装置１００のコントローラＣＰＵは、電源が再投入されると、コントローラボード２００の初期化（内部初期化）を行った後、動作状態で電源ＯＮ通知を管理装置１０２へ送信した後、装置全体の状態を再度確認し、異常がなければ通常はＳＣ解除コールを管理装置１０２へ送信する。しかし、ＮＶ−ＲＡＭ２０２にタイプＡを示すタイプ情報が記憶されている場合には、ＳＣ解除コールを管理装置１０２へ送信しない。
【０１０２】
管理装置１０２は、ＳＣコールの受信から第１の所定時間である所定時間ｔ１以内にそのＳＣコールの送信元からの電源ＯＮ通知を受信し、かつその受信から第２の所定時間である所定時間ｔ２以内にＳＣコールと対応するＳＣ解除コールを受信した場合、画像形成装置１００において、ユーザが電源の再投入を行うことによってそのＳＣコールに係る異常は解消されたものと判断し、異常情報キューに記憶させたそのＳＣコールの情報を削除する。この処理には、センタオペレータによる指示は必要なく、所定の期間内にユーザ側で対処できた異常については、センタオペレータは何ら作業を行う必要はない。
なお、電源の再投入を行わなくても異常が解消する場合も考えられるので、電源ＯＮ通知を受信しない場合でも、ＳＣコールの受信から所定時間ｔ１以内にそのＳＣコールと対応するＳＣ解除コールを受信した場合には、同様にそのＳＣコールに係る異常は解消されたものと判断し、異常情報キューに記憶させたそのＳＣコールの情報を削除する。
【０１０３】
ここで、所定時間ｔ１は、ＳＣコールの受信後、センタオペレータに異常の発生を通知せずに電源ＯＮ通知やＳＣ解除コールの受信を待つ期間、所定時間ｔ２は、電源ＯＮ通知の受信後、ＳＣ解除コールの受信を待つ期間としてそれぞれ設定するものである。ＳＣコールの受信から所定時間ｔ１経過するまでにＳＣ解除コールを受信しなかった場合でも、電源ＯＮ通知を受信していれば、その後所定時間ｔ２以内にはＳＣ解除コールを受信する可能性があるため、このように二段階の待機時間を設けるとよい。所定時間の設定の詳細については後述する。
【０１０４】
次に、図２０に、画像形成装置においてＳＣ発生後、ＳＣが解消しなかった場合の例を示す。
この場合、Ｓ９０４までの処理は図１９の場合と同様であるが、ＳＣコールの受信から所定時間ｔ１を経過しても当然ＳＣコールと対応するＳＣ解除コールの受信がないので、ＳＣコールに係る異常が解消されたとは判断しない。そして、この時点までユーザ側で異常に対処できていないことから、管理センタからのサポートが必要であると判断し、センタオペレータにＳＣコールに係る異常の発生を通知してユーザへの連絡を指示する（Ｓ９１１）。この通知は、操作者端末６０４の表示部にその異常の情報を表示したり、警告音を鳴らしたりすることによって行うことができる。そして、センタオペレータは、この通知を受けると、電話等によってユーザと連絡を取り、異常の詳しい状況の聞き取りや、対処法の教示、保守員の手配等の対応を行う。
【０１０５】
なお、この通知の際には、ユーザ側で電源の再投入による対応を試みていないこともセンタオペレータに通知するようにするとよい。このようにすれば、異常の内容によってはセンタオペレータがユーザにとりあえず電源の再投入を行うよう指示し、これで異常が解消すれば、対応を速やかに完了することができる。
【０１０６】
また、所定時間ｔ１は、常に一定でもよいが、ユーザの状況に応じた値に定めるとよい。図２０の説明からわかるように、このケースでは、所定時間ｔ１は異常の発生からユーザに連絡が行くまでの時間と概ね一致する。そして、画像形成装置１００のユーザには、多少の異常ならサポートを要さずに対処できるユーザ、簡単な異常でもサポートが必要なユーザ、速やかなサポートを希望するユーザ、頻繁な連絡は却って煩わしいと感じるユーザ、契約内容や日頃の関係により速やかな対応が必要なユーザやそうでないユーザ等、様々な状況が考えられるが、その状況に応じて、異常発生から連絡を行うまでの時間として適切な時間が異なるので、これに対応することができるようにするためである。
このような所定時間ｔ１の設定は、例えばデータベース６０５をユーザ情報記憶手段として機能させて顧客データベースを記憶させ、ここに含まれるユーザ情報を参照して行うようにすればよい。
【０１０７】
図２４に顧客データベースの例を示すが、顧客データベースには通常、顧客の連絡先等の他、この顧客の使用する画像形成装置１００の機種機番情報も記憶させる。そこで、この顧客データベースに顧客毎に設定すべき所定時間ｔ１も記憶させれば、ＳＣコールを受信した時点で、ＳＣコール用のＳＯＡＰメッセージに含まれる機番情報をキーとして顧客データベースからこれと対応するユーザについての所定時間ｔ１の情報を取得し、この値を設定するようにすることができる。
【０１０８】
次に、図２１には、画像形成装置においてＳＣ発生後、電源の再投入はしたがＳＣが解消しなかった場合の例を示す。
この場合、Ｓ９０７までの処理は、Ｓ９１２で異常が解消していないことを除き図１９の場合と同様であるが、電源ＯＮ通知の受信から所定時間ｔ２を経過してもＳＣコールと対応するＳＣ解除コールの受信がないので、そのＳＣコールに係る異常が解消されたとは判断しない。また、このことにより、その異常は、電源の再投入では解消しない異常であると判断する。
【０１０９】
そこで、管理センタからのサポートが必要であると判断し、センタオペレータにＳＣコールに係る異常の発生を通知してユーザへの連絡を指示する（Ｓ９１３）。この通知は、図２０の場合と同様に行うことができ、センタオペレータは、この通知を受けると、電話等によってユーザと連絡を取り、異常の詳しい状況の聞き取りや、対処法の教示、保守員の手配等の対応を行う。また、この通知の際には、ユーザ側で電源の再投入による対応を試みたが異常が解消しなかったこともセンタオペレータに通知するようにするとよい。電源の再投入で異常が解消することがしばしばあるため、センタオペレータはまずこの操作を指示することが多いが、このようにすれば、ユーザが既に試みて効果がなかった電源の再投入を指示して無駄な時間を費やしたり、これによってユーザの心証を害したりすることを防止できる。
【０１１０】
なお、ここでは電源ＯＮ通知の受信を基準に所定時間ｔ２をカウントしているので、ＳＣコールの受信後速やかに電源ＯＮ通知を受信した場合には、ＳＣコールの受信から所定時間ｔ１を経過する前に電源ＯＮ通知の受信から所定時間ｔ２を経過してしまう場合もある。このような場合には、ＳＣコールの受信から所定時間ｔ１経過するまで待機してからセンタオペレータに異常を通知するようにしてもよい。しかし、電源の再投入で異常が解消していないので、ユーザ側では容易に対処できないことが予想されるため、ここでは、それまで待たずに電源ＯＮ通知の受信から所定時間ｔ２経過した時点で通知を行うようにするとよい。
【０１１１】
ここで、所定時間ｔ２としては、常に一定の時間を設定してもよいが、機種毎に適当な時間が異なるため、画像形成装置１００において異常が解消した場合に、電源ＯＮ通知を送信してからＳＣ解除コールを送信するまでに要する時間を設定するとよい。そして、この時間は、概ねＳＣＳ３０６の初期化処理に要する時間とエンジンユニットの初期化に要する時間の差であるが、環境によって異なることも考えられるので、通常考えられる時間よりも若干長めに設定するとよい。このようにすれば、画像形成装置１００の機種毎に、適切な待機時間を設定し、電源の再投入で異常が解消しない場合に速やかにユーザに連絡を行えるようにすることができる。
そして、このような所定時間ｔ２の設定は、例えばデータベース６０５に機種データベースを記憶させ、ここに含まれる機器情報を参照して行うようにすればよい。
【０１１２】
図２３に機種データベースの例を示すが、このように、機種データベースとして、機種毎に機種番号と適当な所定時間ｔ２を記憶させておき、ＳＣコールを受信した時点で、ＳＣコール用のＳＯＡＰメッセージに含まれる機番情報中の機種番号をキーとして機種データベースからこれと対応する所定時間ｔ２の情報を取得し、この値を設定するようにすることができる。ＳＣコードとタイプの対応については後述する。
以上のような管理動作は、例えば以下の各図に示す処理によって行うことができる。次に、これらの処理について説明するが、まず、説明を簡単にするために、１台の画像形成装置で異常が発生した場合、これが解消するまでに新たな異常は発生しないものとして説明する。複数の異常が重複して発生する場合に対応するための処理の変形については、その後で説明する。
【０１１３】
図２５は、この発明に係る管理の処理のうち、画像形成装置から受信する情報に対応して行う処理を示すフローチャートである。この図において、この発明に係る管理の動作と直接関係無い部分については図示を省略している。
管理装置１０２のＣＰＵは、画像形成装置１００の管理を行っている間は、所要のプログラムを実行することにより、常に図２５のフローチャートに示す処理を行っている。便宜上ＳＴＡＲＴを示したが、ＥＮＤを示していないのはこのためである。
【０１１４】
この処理においては、まずステップＳ１１でいずれかの画像形成装置１００から（仲介装置１０１を介して）メッセージを受信するまで待機する。ここでいうメッセージとは、何らかのコール，通知，コマンド等に対応したＳＯＡＰメッセージのことであり、仲介装置１０１からはこのＳＯＡＰメッセージを含むＨＴＴＰメッセージとして送信されてくるものである。
ステップＳ１１でメッセージを受信すると、ステップＳ１２で応答を返し、ステップＳ１３でそのメッセージの種類を判断する。
そして、これがＳＣコールであれば、ステップＳ１４に進み、ＳＣコール用のＳＯＡＰメッセージに含まれる機種番号とＳＣコードとから、データベース６０５の機種データベースを参照し、ＳＣのタイプ情報を取得する。
【０１１５】
ここで、ＳＣのタイプについて、図３６を参照して説明する。ＳＣ（サービスマンコール）のタイプとは、発生した異常を、その緊急度や装置の動作に及ぼす影響等の観点から分類したものである。
図３６は、ＳＣ（異常）のタイプの一例を示す説明図である。
【０１１６】
「タイプＡ」は、操作パネル２０５にＳＣ表示を行って使用禁止（使用不可）とするもののうち、ユーザ（機器利用者）が解除できないＳＣである。このタイプＡのＳＣは、管理装置１０２からの「ＳＣリセット」もできない。例えば、定着系のＳＣなどである。「タイプＡ」は画像形成装置１００（機器）側のメインスイッチ（主電源スイッチ）のＯＦＦ／ＯＮによる主電源のＯＦＦ／ＯＮもしくはソフト電源キーの操作によるエンジンユニットへの給電停止／解除によっては復旧できない。
【０１１７】
「タイプＢ」は、異常が検出（検知）された特定の機能のみが使用できないＳＣである。通常使用時には操作パネル２０５上にＳＣ表示を行わないが、異常が検出されている機能が選択された時だけ、その操作パネル２０５にＳＣ表示を行う。例えば、両面ユニット（両面トレイ）異常時に両面モードが選択された場合が該当する。
「タイプＣ」は、異常発生時にも操作パネル２０５へのＳＣ表示は行わず、内部的にＳＣの発生のロギングのみを行うものである。例えば、通信が不能になった場合が該当する。
【０１１８】
「タイプＤ」は、操作パネル２０５上にＳＣ表示を行って使用禁止とするが、画像形成装置１００側のメインスイッチのＯＦＦ／ＯＮによる主電源のＯＦＦ／ＯＮもしくはソフト電源キーの操作によるエンジンユニットへの給電停止／解除によって解除するＳＣである。但し、主電源ＯＮ（電源投入）後あるいはエンジンユニットへの給電停止／解除後に、再度異常を検出して、見かけ上解除されない場合もある。例えば、モータ異常がそれに該当する。
【０１１９】
このようなタイプとＳＣの種類を示すＳＣコードの対応関係は、画像形成装置１００のＮＶ−ＲＡＭ２０２（ＨＤＤ２０１でもよい）の所定の格納領域（所定領域）に格納しておき、画像形成装置１００側でもタイプに応じて異なる対応を行うことも考えられる。このような場合には、ＳＣコール用のＳＯＡＰメッセージにタイプ情報を含めることができるので、管理装置１０２側でこれを直接参照してタイプ情報を取得することができる。
しかしここでは、画像形成装置１００がこのような機能を持たない場合にも対応できるよう、機種データベースに、機種毎にＳＣコードとタイプとの対応関係を記憶させ、ＳＣコードをキーとして対応するタイプ情報を取得するようにしている。
【０１２０】
図３７は、画像形成装置１００におけるＳＣ（異常）発生時の処理の一例を示すフローチャートである。
画像形成装置１００は、プロッタエンジンや操作パネル２０５を含む各ハードウェア資源を制御するＣＰＵ（コントローラＣＰＵ）が、その各ハードウェア資源の状態を監視し、いずれかのハードウェア資源で異常が発生すると、その異常をＳＣとして検出し、図３７の処理ルーチンを開始する。そしてまず、そのＳＣのタイプを判定し、そのタイプによって異なる処理を行う。
【０１２１】
すなわち、判定したＳＣタイプが「タイプＣ」の場合には、そのまま処理を終了し、他の処理ルーチンでＳＣ発生のロギングを行う。
判定したＳＣタイプが「タイプＡ」の場合には、ＮＶ−ＲＡＭ２０２内の所定領域に記憶してある通報状態を「タイプＡコール中（タイプＡのＳＣコール中）」とし、管理装置１０２に対してタイプＡのＳＣコールを行った後、その通報状態をリセット（無しに）する。
判定したＳＣタイプが「タイプＢ」の場合には、そのＳＣは電源ＯＮ（電源投入）後初めて発生したどうかをチェックし、そうでなければそのまま処理を終了する。なお、電源ＯＮとは、画像形成装置１００のメインスイッチのＯＮによる主電源のＯＮの他に、メインスイッチのＯＦＦ／ＯＮによる主電源のＯＦＦ／ＯＮ（再投入）や、ソフト電源キーの操作によるエンジンユニットへの給電停止／解除を含むものとする。
【０１２２】
判定したＳＣタイプが「タイプＢ」のＳＣは電源ＯＮ後初めて発生したと判断した場合、あるいは判定したＳＣタイプが「タイプＤ」の場合には、ＳＣの発生回数をカウント（計数）する図示しないＳＣ回数カウンタをカウントアップ（＋１）した後、そのカウント値（ＳＣ発生回数）が「２（３以上の値でもよい）」になったか否かをチェックし、「２」になっていなければそのまま処理を終了するが、「２」になっていればＮＶ−ＲＡＭ２０２内の所定領域に記憶してある通報状態を「タイプＢｏｒＤコール中（タイプＢ又はＤのＳＣコール中）」とし、管理装置１０２に対してタイプＢ又はＤのＳＣコールを行った後、その通報状態をリセットし、ＳＣ回数カウンタをリセットして処理を終了する。
【０１２３】
なお、図３７には図示を省略したが、通報状態が「タイプＡコール中」「タイプＢコール中」又は「タイプＤコール中」であればその通報状態を示すメッセージを操作パネル２０５上に表示する。
その後、タイプＡのＳＣコールが正常に終了した場合には「タイプＡコール成功」を示すメッセージを、正常に終了しなかった場合には「タイプＡコール失敗」を示すメッセージをそれぞれ操作パネル２０５上に表示する。
【０１２４】
タイプＢのＳＣコールが正常に終了した場合には「タイプＢコール成功」を示すメッセージを、正常に終了しなかった場合には「タイプＢコール失敗」を示すメッセージをそれぞれ操作パネル２０５上に表示する。但し、それらの表示は、「タイプＢ」のＳＣが検出された機能が選択された場合にのみ行う。
タイプＤのＳＣコールが正常に終了した場合には「タイプＤコール成功」を示すメッセージを、正常に終了しなかった場合には「タイプＤコール失敗」を示すメッセージをそれぞれ操作パネル２０５上に表示する。
タイプＣのＳＣが発生した場合には、ＳＣコールを行わない。
【０１２５】
図３８は、画像形成装置１００における電源ＯＮ時の処理の一例を示すフローチャートである。
画像形成装置１００のＣＰＵ（コントローラＣＰＵ）は、電源ＯＮ時に図３８の処理を行う。
【０１２６】
すなわち、ＮＶ−ＲＡＭ２０２に記憶してある通報状態をチェックし、「タイプＢｏｒＤコール中」であれば図３７の処理ルーチンに移行し、管理装置１０２に対してタイプＢ又はＤのＳＣコールを行った後、上記通報状態をリセットし、ＳＣ回数カウンタを「０」にリセットして処理を終了する。「タイプＡコール中」であれば図３７の処理ルーチンに移行し、管理装置１０２に対してタイプＡのＳＣコールを行った後、ＳＣ回数カウンタを「０」にリセットして処理を終了する。ＮＶ−ＲＡＭ２０２に記憶してある通報状態が「タイプＢｏｒＤコール中」「タイプＡコール中」のいずれでもない場合には、そのまま処理を終了する。
【０１２７】
図３９は、画像形成装置１００におけるコピー管理処理の一例を示すフローチャートである。なお、この処理は画像形成装置１００が複写機の場合に対応するものであるが、プリンタやファクシミリ装置等の他の画像形成装置であれば、図３９の「コピー」を「画像形成」に置き換えればよい。
画像形成装置１００のＣＰＵは、コピー終了後に図３９の処理を行う。
すなわち、正常にコピーできたかどうかをチェックし、正常にコピーできなかった場合にはそのまま処理を終了する。正常にコピーできた場合には、ＳＣ回数カウンタを「０」にリセットし、処理を終了する。
【０１２８】
ここで、画像形成装置１００における上述したタイプ別のＳＣに対応する制御をまとめると、以下のようになる。
（１）タイプＡ
ＳＣ（異常）が発生する度に必ずＳＣコール（ＳＣ通報）を行う。ＳＣコールが完了する前に電源が遮断（ＯＦＦ）された場合は、電源再投入後にＳＣコールをやり直す。なお、「電源再投入後のＳＣコールのやり直し」とは、改めて先頭のデータから送出を開始し直すもので、中断された送出データ以降からの継続ではない。以下のタイプＢおよびＤのＳＣについても同様である。
【０１２９】
（２）タイプＢ
タイプＤのＳＣの発生の場合と合わせてＳＣ発生回数をＳＣ回数カウンタによって計数（カウント）し、１枚分の画像形成（コピー等）も行われることなく、ＳＣが２回発生する毎にＳＣコールを行う。電源が遮断された場合でもＳＣ発生回数を継続して計数し、電源断の前後で連続してＳＣが発生した場合にはＳＣコールを行う。また、ＳＣコール開始後、ＳＣコールが完了する前に電源が遮断された場合には、電源再投入後にＳＣコールをやり直す。
ＳＣコール終了後は、その成功／失敗を問わず、ＳＣ回数発生の計数は最初から行う。
タイプＢのＳＣの検出は発生した全てのＳＣを計数対象とするのではなく、電源投入後から再度電源が投入されるまでの間に、ＳＣの種類ごとに１度しか行わないようにする。
【０１３０】
（３）タイプＣ
ＳＣコールの対象としない。エラーアラームの対象としてのみ扱う。
（４）タイプＤ
１枚分の画像形成も行われることなく、ＳＣが２回連続して発生する毎にＳＣコールを行う。電源が遮断された場合でもＳＣ発生回数を継続して計数し、電源断の前後で連続してＳＣが発生した場合はＳＣコールを行う。また、ＳＣコール開始後、ＳＣコールが完了する前に電源が遮断された場合は、電源再投入後にＳＣコールをやり直す。
ＳＣコールの終了後は、その成功／失敗を問わず、ＳＣ発生回数の計数を最初から行う。ＳＣが２回を超えて連続して発生した場合は、２回の発生毎にＳＣコールを行うことになる。
【０１３１】
図２５の説明に戻る。
管理装置１０２のＣＰＵは、図２５のステップＳ１４の処理が終わると、ステップＳ１５に進み、内部タイマからＳＣコールの受信時刻として用いるための時刻情報を取得する。そして、ステップＳ１６で、ＳＣコールとして受信したＳＣ（異常）の情報を、機種機番、タイプ、受信時刻の情報と共に、データベース６０５の異常情報キューに格納して記憶し、この情報を管理対象とする。
次のステップＳ１７では、ＳＣのタイプを判断し、タイプＡでなければ、ステップＳ１８に進み、顧客データベースに含まれるユーザ情報を参照し、受信したＳＣコールに対応する画像形成装置のユーザについての所定時間ｔ１を第１のタイマに設定すると共に、図２６に示す監視処理を開始する。なお、この監視処理は、受信したＳＣコールに係る画像形成装置毎に別々に行うものとする。
また、ステップＳ１７でタイプＡであった場合には、ユーザ側での対処を待つ処理には適さない異常であるので、ステップＳ１９に進み、直ちにセンタオペレータに異常の発生を通知し、保守員の手配を指示する。
ステップＳ１８又はステップＳ１９の終了後は、ステップＳ１１に戻って再度メッセージの受信を待つ。
【０１３２】
一方、ステップＳ１３でＳＣ解除コールであった場合には、ステップＳ２０に進み、異常が解消されたものと判断して、対応する異常情報キューから対応するＳＣ情報をクリアする。これに伴って、対応する監視処理を行っている場合にこれが終了することは後述する通りであるが、このステップＳ２０の処理は監視処理とは独立のものであり、どのようなタイミングでＳＣ解除コールを受信した場合も行う。
すなわち、図１９を用いて説明したようなタイミングでＳＣ解除コールを受信した場合には、センタオペレータが何ら対応することなくＳＣの情報が削除されることになるが、図２０及び図２１を用いて説明したように、センタオペレータに異常の通知がなされ、センタオペレータによる指示や保守員による修理によって異常が解消された後にＳＣ解除コールを受信した場合でも、異常が解消されたという点では何ら変わりがないため、同じようにＳＣ情報をクリアするのである。電源ＯＮ通知の受信から所定時間ｔ２以内にＳＣ解除コールを受信したか否かという点も、この処理には特に関係ない。
なお、ＳＣ情報をクリアせず、異常が解消した旨の情報を付加した上で引き続き記憶しておくようにしてもよい。
ステップＳ２０の後は、ステップＳ１１に戻って再度メッセージの受信を待つ。
【０１３３】
また、ステップＳ１３で電源ＯＮ通知であった場合には、ステップＳ２１に進み、電源ＯＮ通知用のＳＯＡＰメッセージに含まれる機種機番と対応するＳＣ情報が異常情報キューに記憶されているか否か判断する。
記憶されていれば、ステップＳ２２に進み、対応する機種機番のＳＣ情報について電源ＯＮフラグをセットする。そして、ステップＳ２３で、そのＳＣ情報についての監視処理が行われていれば、第１のタイマをタイムアウトさせると共に、機種データベースを参照して第２のタイマに設定時間ｔ２を設定する。
なお、センタオペレータへの異常発生の通知を、ＳＣコールの受信から所定時間ｔ１経過まで待ってから行うようにする場合には、第１のタイマのタイムアウトを行わないようにすればよい。
ステップＳ２３の終了後、あるいはステップＳ２１で対応するＳＣ情報がなかった場合には、ステップＳ１１に戻って再度メッセージの受信を待つ。
ステップＳ１３でメッセージがその他のものであった場合には、メッセージに含まれるコマンド（コール，通知の場合もある）に対応する処理を行い、ステップＳ１１に戻って再度メッセージの受信を待つ。
【０１３４】
次に、図２６のフローチャートに示す監視処理について説明する。
この監視処理が、図２５のステップＳ１８の処理によって開始されることは既に述べたが、この処理も、管理装置１０２のＣＰＵが所要のプログラムを実行することにより行うものである。
この処理においては、まずステップＳ３１で、第１のタイマがタイムアウトしたか否か判断する。そして、タイムアウトしていない場合には、ステップＳ３８に進んでＳＣコールに係る異常が解消されたか否か判断し、異常が解消されていない場合にはステップＳ３１に戻って処理を繰り返す。すなわち、第１のタイマがタイムアウトするか異常が解消されるまでステップＳ３１とＳ３８の処理を繰り返しながら待機する。なお、異常が解消されたか否かは、監視処理と対応するＳＣ情報が異常情報キューに残っているか否かによって判断することができる。従って、ＳＣ解除コールを受信して図２５のステップＳ２０でＳＣ情報がクリアされた場合には、異常が解消されたと判断することができる。
【０１３５】
第１のタイマがタイムアウトするまでに異常が解消された場合、すなわちＳＣコールの受信から所定時間ｔ１以内にＳＣ解除コールを受信し、異常が解消されたと判断した場合には、ステップＳ３８からＳ３９に進み、タイマをクリアして処理を終了する。この場合には、センタオペレータに異常の発生を通知することはない。
【０１３６】
一方、異常が解消される前に第１のタイマがタイムアウトした場合（図２５のステップＳ２３の処理においてタイムアウトにされた場合も含む）には、ステップＳ３１からＳ３２に進み、ステップＳ３８の場合と同様にＳＣコールに係る異常が解消されたか否か判断する。そして、最初にこのステップＳ３２に進んだ時点では当然解消されていないので、ステップＳ３３に進む。
ステップＳ３３では、第２のタイマが動作中であるか否か判断する。そして、動作中である場合にはステップＳ３１に戻り、ステップＳ３１乃至Ｓ３３の処理を繰り返す。動作中でない場合には、ステップＳ３４に進む。なお、この第２のタイマは、電源ＯＮ通知を受信した場合に図２５のステップＳ２３の処理でスタートされるものであるので、タイムアウトした場合の他、第１のタイマのタイムアウトまでに電源ＯＮ通知の受信がなく、第２のタイマの動作が開始されていない場合も、動作中でないものとして取り扱う。すなわち、電源ＯＮ通知の受信から所定時間ｔ２の間だけ第２のタイマが動作中となり、ステップＳ３３の処理は、この間待機するためのものである。
【０１３７】
ステップＳ３１乃至Ｓ３３の処理を繰り返している間に、すなわち電源ＯＮ通知の受信から所定時間ｔ２が経過するまでにＳＣ解除コールを受信し、異常が解消されたと判断した場合には、ステップＳ３２からＳ３９に進み、タイマをクリアして処理を終了する。この場合にも、センタオペレータに異常の発生を通知することはない。
ステップＳ３３の判断がＮＯとなりステップＳ３４に進んだ場合には、ＳＣコールの受信から所定時間ｔ１以内または、ＳＣコールの受信後所定時間ｔ１以内に電源ＯＮ通知を受信してかつその受信から所定時間ｔ２以内に、異常が解消されたものと判断しなかったことになるが、この場合はステップＳ３４でセンタオペレータに対して対応するＳＣコール（ＳＣ情報）に係る異常の発生を通知する。
【０１３８】
そしてステップＳ３５で、そのＳＣ情報に係る電源ＯＮフラグがＯＮであるか否か判断する。ここで電源ＯＮフラグがＯＮであることは、ＳＣコールの受信後所定時間ｔ１以内に電源ＯＮ通知を受信してかつその受信から所定時間ｔ２以内に、異常が解消されたものと判断しなかった（ＳＣ解除コールを受信しなかった）ことを意味するので、そのＳＣコールに係る異常は電源の再投入では解消しない異常であると判断し、ステップＳ３６に進んで、センタオペレータにその旨を通知して処理を終了する。表現としては、ユーザが既に電源の再投入を試みている旨を通知すればよい。
【０１３９】
一方、ステップＳ３５で電源ＯＮフラグがＯＮでなかった場合には、ＳＣコールの受信後所定時間ｔ１以内に電源ＯＮ通知を受信していないことを意味するので、ステップＳ３７に進んで、センタオペレータにユーザがまだ電源の再投入を試みていない旨を通知して処理を終了する。
以上のような図２５及び図２６に示す処理を行うことにより、図１９乃至図２１を用いて説明したような管理動作を行うことができる。
【０１４０】
図２７乃至図３０に、このような管理動作の具体例を示す。これらの図において、「管理装置」の欄には、管理装置１０２が受信するメッセージと送信する応答のタイミングを、「センタオペレータ」の欄には管理装置１０２から異常の発生の通知を受けてセンタオペレータがサポート対応を行うタイミングを、「データベース」の欄には、ＳＣ情報を異常情報キューに保持する期間を示している。
【０１４１】
まず、図２７には、異常発生後、特に対応がなされず、異常が解消しなかった場合の例を示す。この場合には、管理装置１０２は、ＳＣコールを受信してから所定時間ｔ１以内に電源ＯＮ通知もＳＣ解除コールも受信しないので、この時点でセンタオペレータに異常の発生を通知する。そして、センタオペレータはこれに応じて電話連絡や修理の手配等のサポート対応を行う。これによって修理が完了すると、画像形成装置１００からＳＣ解除コールが送信され、管理装置１０２はこれを受信した時点で異常が解消されたものとして異常情報キューに記憶しているＳＣ情報を消去する。
【０１４２】
図２８及び図２９には、異常発生後、電源の再投入によって異常が解消された場合の例を示す。図２８の場合には、管理装置１０２が、電源ＯＮ通知とＳＣ解除コールの双方をＳＣコールの受信から所定時間ｔ１以内に受信しているので、異常の発生をセンタオペレータに通知することなくＳＣ情報を消去する。図２９の場合には、管理装置１０２は、ＳＣコールの受信から所定時間ｔ１以内にＳＣ解除コールを受信していないが、この期間内に電源ＯＮ通知は受信している。従って、電源再投入によって異常が解消していれば、電源ＯＮ通知の受信から所定時間ｔ２以内にＳＣ解除コールを受信することが考えられる。そこで、この期間はセンタオペレータに異常の発生を通知せずにＳＣ解除コールの受信を待ち、この例の場合にはこの期間内にＳＣ解除コールを受信しているので、異常の発生をセンタオペレータに通知することなくＳＣ情報を消去する。
【０１４３】
図３０には、電源の再投入によっても異常が解消されなかった場合の例を示す。この場合には、管理装置１０２は、ＳＣコールの受信から所定時間ｔ１以内に電源ＯＮ通知を受信しているので、電源ＯＮ通知の受信から所定時間ｔ２経過するまでＳＣ解除コールの受信を待つことは、図２９の場合と同様である。しかし、この例の場合にはこの期間内にＳＣ解除コールを受信しないので、この期間の経過した時点でセンタオペレータに異常の発生を通知する。そして、センタオペレータはこれに応じてサポート対応を行う。これによって修理が完了すると、画像形成装置１００からＳＣ解除コールが送信され、管理装置１０２はこれを受信した時点で異常が解消されたものとして異常情報キューに記憶しているＳＣ情報を消去する。
【０１４４】
以上が、異常が発生した場合、これが解消するまでに同じ画像形成装置で新たな異常は発生しないものとした場合の処理例であるが、次に、複数の異常が重複して発生し得る場合に対応するための処理の変形について説明する。
図３１にこの場合の管理動作の第１の例を示す。この例は、初めのＳＣコールに係る異常が解消する前に同じ画像形成装置から別の異常に係るＳＣコールを受信した場合に、それぞれのＳＣコールに対応して図２６に示した管理処理を別々に行うものである。
【０１４５】
図３１に示した例では、管理装置１０２はＳＣコード１０１についてのＳＣコール（ＳＣ１０１コール）を受信した時点でこのＳＣコールに係るＳＣ情報を異常情報キューに記憶させる。そして、その後所定時間ｔ１以内に対応するＳＣ解除コール（ＳＣ１０１解除）を受信しているので、ＳＣコード１０１についての異常の発生をセンタオペレータに通知することなくＳＣ情報を消去する。また、ＳＣコード３０１についてのＳＣコール（ＳＣ３０１コール）を受信した時点で、このＳＣコールに係るＳＣ情報を、ＳＣ１０１についてのＳＣ情報とは別に異常情報キューに記憶させる。そして、その後所定時間ｔ１以内に対応するＳＣ解除コール（ＳＣ１０３解除）を受信しているので、ＳＣコード３０１についての異常の発生もセンタオペレータに通知することなくＳＣ情報を消去する。ＳＣ３０１コールの受信後所定時間ｔ１以内にＳＣ１０３解除を受信しなかったとすると、この時点でセンタオペレータにＳＣコード３０１についての異常の発生を通知する。
図２２に例を示したように異常情報キューに機種機番とＳＣコードを記憶させるようにすれば、このような管理を行うことは容易である。ただし、図２５のステップＳ２２において、対応する機番のＳＣ情報が複数あった場合にはその全てに電源ＯＮフラグをセットし、ステップＳ２３の処理も、その全てのＳＣ情報と対応する管理処理について行う。
【０１４６】
図３２には、管理動作の第２の例を示す。この例は、図２６に示した管理処理は画像形成装置毎に行い、全ての異常が解消された場合に初めて図２６のステップＳ２２あるいはＳ２８で異常が解消したと判断するようにするものである。そして、この場合には、図２５に示した処理において、ステップＳ１７とＳ１８の間に、図３３に示すようにステップＳＡの処理を追加することになる。すなわち、受信したＳＣコールに対応する画像形成装置についての監視処理が既に開始されている場合には、新たに監視処理を開始せず、それまでの監視処理を継続するようにするのである。
【０１４７】
このような図３２に示す例でも、ＳＣ１０１コール及びＳＣ３０１コールを受信した時点でそれぞれＳＣ情報を異常情報キューに記憶させることは、図３１に示す例の場合と同様である。しかし、ＳＣ１０１コールの受信後所定時間ｔ１以内にＳＣ１０１解除を受信した時点で、ＳＣコード１０１についての異常の発生をセンタオペレータに通知することなくＳＣ情報を消去するものの、このタイミングではＳＣコード３０１についての異常は解消されていないので、タイマのカウントは続行する。
【０１４８】
そして、その後ＳＣ１０１コールの受信から所定時間ｔ１経過した時点でもＳＣ３０１解除を受信していないので、ＳＣ３０１コールの受信から所定時間ｔ１経過する前であっても、この時点でセンタオペレータに異常の発生を通知する。ただし、この時通知する異常は、通知の時点で残っているＳＣコード３０１についての異常のみである。
その後センタオペレータのサポート対応によって修理が完了すると、画像形成装置１００からＳＣ３０１解除が送信され、管理装置１０２はこれをに応じて異常情報キューに記憶しているＳＣ情報を消去する点は、図２７に示した例の場合と同様である。
【０１４９】
異常の種類が途中で変わる場合でも、ユーザ側としては画像形成装置の異常が継続していることに変わりがないので、装置毎に異常解消の有無を判断するこのような処理も有効である。この場合にも、図２５のステップＳ２２において、対応する機番のＳＣ情報が複数あった場合にはその全てに電源ＯＮフラグをセットするが、ステップＳ２３の処理は、ＳＣ情報に係る画像形成装置と対応する１つの管理処理について行う。
【０１５０】
なお、装置毎に異常解消の有無を判断する場合には、ＳＣ解除コールをＳＣコールと対応させて行う必要はなく、全ての異常が解消された時点でこのことを示す１回のＳＣ解除コールを行うようにしてもよい。この例を示したのが図３４である。
この場合、ＳＣコード１０１とＳＣコード３０１に係る異常がどのようなタイミングで解消したかは関係無く、全ての異常が解消された時点で画像形成装置１００からＳＣ解除コールが送信される。そして、初めのＳＣコール（ＳＣ１０１コール）から所定時間ｔ１以内にＳＣ解除コールを受信した場合には、全ての異常について、異常の発生をセンタオペレータに通知することなくＳＣ情報を消去する。
このようにすれば、ＳＣ解除コールの送信回数を減らし、通信トラフィックや処理負担を低減することができる。
図３１乃至図３４に示した例では、電源ＯＮ通知についての説明を省略したが、それ以前に説明した例の場合と同様に電源ＯＮ通知を活用した管理も行うことができることは、もちろんである。
【０１５１】
以上の説明から明らかなように、画像形成装置１００から受信するＳＣコール（異常情報）とＳＣ解除コール（異常解消情報）とを用いて異常情報を管理するようにすれば、画像形成装置１００と管理装置１０２との間にファイアウォール１０４が設けられている場合でも、管理装置１０２側で各画像形成装置１００における異常の発生とその解消の状況をリアルタイムに把握することができ、適切かつ効率的な管理を行うことができる。
ＳＣコールを受信した場合でも対応するＳＣ解除コールを受信した場合にそのＳＣコールに係る異常は解消されたものと判断することにより、上記のような管理を容易に行うことができる。
ＳＣコールやＳＣ解除コールの内容を異常の種類に応じて異なるものにすれば、異常の種類毎にその解消の有無を判断し、きめ細かい対応が可能になる。
【０１５２】
図１９乃至図２１を用いて説明した適切なタイミングで異常の発生をセンタオペレータに通知するようにすれば、センタオペレータが適切なタイミングで顧客に連絡し、異常に対処することができる。また、この通知より前にはセンタオペレータに異常の発生を通知しないようにすれば、それまでに異常が解消された場合にはセンタオペレータはいかなる作業も行う必要がなく、管理に要する労力をさらに低減することができる。
管理動作に電源ＯＮ通知も用い、ＳＣコールの送信元の画像形成装置から電源ＯＮ通知を受信し、その後所定時間ｔ２以内にＳＣ解除コールを受信しない場合に異常が電源の再投入では解消されないものであると判断するようにすれば、異常の状態を予めある程度認識して管理センタからのサポートを行うことができる。これをセンタオペレータに通知するようにすれば、顧客に連絡する際に無駄のない適切な対応をすることができる。
【０１５３】
さらに、所定時間ｔ１をユーザ情報に従って定めるようにすれば、ユーザ毎の事情に合った対応が可能なる。
所定時間ｔ２を画像形成装置の機種に従って定めるようにすれば、機種毎の起動時間に合った対応が可能なる。
ＳＣコール，電源ＯＮ通知，ＳＣ解除コールを構造化言語形式で記載するようにすれば、データの汎用性を高め、データ形式の設計や改変を容易に行うことができる。
【０１５４】
なお、異常情報の管理は、図２２に示したようなキュー形式ではなく、図３５に示すような形式で行うようにしてもよい。この例の場合、画像形成装置毎にテーブルを用意し、ヘッダに機種機番，状態情報（異常発生中か否か），電源ＯＮフラグの情報を記憶させると共に、ＳＣコード毎のランク，受信日時及び解除日時を記憶するようにしている。このような管理を行うようにすれば、各画像形成装置における異常の種類毎の発生状況の管理が容易になる。
また、ここでは、異常の発生の通知はセンタオペレータ（管理装置１０２の操作者端末６０４）に対して行う例について説明したが、管理装置１０２を保守員の拠点に備えた端末や、保守員が携帯する携帯通信端末等と通信可能とし、異常の発生をこれらの端末を通して保守員に対して行うようにしてもよい。このようにすれば、ユーザが異常に対処できないと思われる場合に、速やかに保守員を派遣することができる。
【０１５５】
また、以上の実施例においては、被管理装置とする通信装置の例として通信機能を備えた画像形成装置について主に説明したが、この発明はこれに限られるものではなく、通信機能を備えたネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置を被管理装置とする場合に適用可能である。さらに、通信装置の遠隔管理システムについても、通信装置，遠隔管理仲介装置，管理装置の構成及びこれらの接続形式は、以上の実施例に限られるものではない。通信装置と管理装置との間の通信も、有線，無線を問わず、ネットワークを構築可能な各種通信回線（通信経路）を用いて行うことができる。
【０１５６】
例えば、図１に示した遠隔管理システムにおいて、上述した各種電子装置を被管理装置とし、図４０に示すような遠隔管理システムを構成することが考えられる。この図４０においては、仲介装置１０１を別途設ける被管理装置の例として、テレビ受像機１２ａや冷蔵庫１２ｂのようなネットワーク家電、医療機器１２ｃ，自動販売機１２ｄ，計量システム１２ｅ，空調システム１２ｆを挙げている。そして、仲介装置１０１の機能を併せ持つ被管理装置の例として、自動車１３ａや航空機１３ｂを挙げている。また、自動車１３ａや航空機１３ｂのように広範囲を移動する装置においては、ファイアウォール（ＦＷ）１０４の機能も併せ持つようにすることが好ましい。
【０１５７】
また、この発明によるプログラムは、自身の異常を検出した場合に異常情報を送信する異常通知手段と、自身の異常解消を検出した場合に異常解消情報を送信する異常解消通知手段とを有する被管理装置をネットワークを介して遠隔管理する管理装置を制御するコンピュータに、この発明による各機能（通信手段，異常情報管理手段，異常通知手段，その他の手段としての機能）を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
【０１５８】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【産業上の利用可能性】
【０１５９】
この発明を、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置（被管理装置）を管理する管理装置、およびその管理装置と被管理装置とからなる遠隔管理システムに適用可能である。
【図面の簡単な説明】
【０１６０】
【図１】この発明による遠隔管理システムの構成例を示す概念図である。
【図２】その遠隔管理システムにおけるデータ送受モデルを示す概念図である。
【図３】この発明による遠隔管理システムである画像形成装置遠隔管理システムの構成例を示す概念図である。
【図４】その画像形成装置遠隔管理システムを構成する通信装置である画像形成装置のハードウェア構成例を示すブロック図である。
【図５】その画像形成装置のソフトウェア構成例を示すブロック図である。
【０１６１】
【図６】その画像形成装置におけるＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号について説明するための図である。
【図７】その画像形成装置におけるＮＲＳモジュールの構成例を示す機能ブロック図である。
【図８】図３に示した管理装置１０２の概略構成例を示すブロック図である。
【図９】図３に示した画像形成装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
【図１０】図３に示した画像形成装置から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
【０１６２】
【図１１】図３に示した遠隔管理システムにおいて管理装置が画像形成装置の管理に必要な情報を画像形成装置から受信する際の通信シーケンスを示すシーケンス図である。
【図１２】図３に示した画像形成装置１００においてＳＣＳが行う初期化処理を示すフローチャートである。
【図１３】ＨＴＴＰメッセージ内のＳＣコール用のＳＯＡＰメッセージのフォーマット例を示す図である。
【図１４】そこに含まれる主要な情報について説明するための図である。
【図１５】ＨＴＴＰメッセージ内の電源ＯＮ通知用のＳＯＡＰメッセージのフォーマット例を示す図である。
【０１６３】
【図１６】そこに含まれる主要な情報について説明するための図である。
【図１７】ＨＴＴＰメッセージ内のＳＣ解除コール用のＳＯＡＰメッセージのフォーマット例を示す図である。
【図１８】そこに含まれる主要な情報について説明するための図である。
【図１９】図３に示した遠隔管理システムにおいて、画像形成装置においてＳＣ発生後、電源の再投入によってＳＣが解消した場合の処理シーケンス例を示す図である。
【図２０】同じく、画像形成装置においてＳＣ発生後、ＳＣが解消しなかった場合の例を示す図である。
【０１６４】
【図２１】同じく、画像形成装置においてＳＣ発生後、電源の再投入はしたがＳＣが解消しなかった場合の例を示す図である。
【図２２】異常情報キューにおける異常情報の記憶形式の例を示す図である。
【図２３】機種データベースの例を示す図である。
【図２４】顧客データベースの例を示す図である。
【図２５】この発明に係る管理の処理のうち、画像形成装置から受信する情報に対応して行う処理を示すフローチャートである。
【０１６５】
【図２６】図２５のステップＳ１８で開始する管理処理を示すフローチャートである。
【図２７】図３に示した遠隔管理システムにおいて、画像形成装置において異常発生後、特に対応がなされず、異常が解消しなかった場合の管理動作の例を示す図である。
【図２８】同じく、異常発生後、電源の再投入によって異常が解消された場合の例を示す図である。
【図２９】同じく、異常発生後、電源の再投入によって異常が解消された場合の別の例を示す図である。
【図３０】同じく、電源の再投入によっても異常が解消されなかった場合の例を示す図である。
【０１６６】
【図３１】同じく、複数の異常が重複して発生する場合に対応した場合の管理動作の第１の例を示す図である。
【図３２】同じく、複数の異常が重複して発生する場合に対応した場合の管理動作の第２の例を示す図である。
【図３３】図３２に示す管理動作を行う場合における、図２５に示す処理の変更点を示す図である。
【図３４】全ての異常が解消した時点で１回のＳＣ解除コールを行うようにした場合の管理動作の例を示す図である。
【図３５】異常情報管理のための、図２２に示した例とは別の記憶形式について説明するための図である。
【０１６７】
【図３６】ＳＣ（異常）のタイプの一例を示す説明図である。
【図３７】図４に示した画像形成装置１００におけるＳＣ（異常）発生時の処理の一例を示すフロー図である。
【図３８】同じく、電源ＯＮ時の処理の一例を示すフロー図である。
【図３９】同じく、コピー管理処理の一例を示すフロー図である。
【図４０】図１に示した遠隔管理システムの別の構成例を示す図である。
【０１６８】
【図４１】従来の遠隔管理システムにおける画像形成装置に異常が発生した場合の処理シーケンス例を示す図である。
【図４２】図３６に示した処理における通信シーケンスを、異常が解消していない場合について詳細に示したシーケンス図である。
【図４３】同じく、異常が解消した場合について示したシーケンス図である。
【符号の説明】
【０１６９】
１０：被管理装置    １１：仲介機能付被管理装置    １００：画像形成装置    １０１：仲介装置    １０２：管理装置    １０３：インタネット    １０４：ファイアウォール    １１０：仲介機能付画像形成装置    ２００：コントローラボード  ２０１：ＨＤＤ    ２０２：ＮＶ−ＲＡＭ    ２０３：ＰＩボード    ２０４：ＰＨＹ    ２０５：操作パネル    ２０６：プロッタ／スキャナエンジンボード    ２０７：電源ユニット    ２１２：ＰＣＩ−ＢＵＳ    ３００：ＯＣＳ    ３０１：ＥＣＳ    ３０２：ＭＣＳ    ３０３：ＮＣＳ    ３０４：ＦＣＳ    ３０５：ＮＲＳ    ３０６：ＳＣＳ    ３０７：ＳＲＭ    ３０８：ＩＭＨ    ３０９：コピーアプリ    ３１０：ファクスアプリ    ３１１：プリンタアプリ    ３１２：スキャナアプリ    ３１３：ネットファイルアプリ    ３１４：ウェブアプリ    ３１５：ＣＳＳ    ３１６：ＤＣＳ    ３１７：ＵＣＳ    ３２０：汎用ＯＳ    ６０１：モデム      ６０２：通信端末    ６０３：プロキシサーバ    ６０４：操作者端末    ６０５：データベース    ６０６：制御装置
【図１】
2004248256.tif 000003
【図２】
2004248256.tif 000004
【図３】
2004248256.tif 000005
【図４】
2004248256.tif 000006
【図５】
2004248256.tif 000007
【図６】
2004248256.tif 000008
【図７】
2004248256.tif 000009
【図８】
2004248256.tif 000010
【図９】
2004248256.tif 000011
【図１０】
2004248256.tif 000012
【図１１】
2004248256.tif 000013
【図１２】
2004248256.tif 000014
【図１３】
2004248256.tif 000015
【図１４】
2004248256.tif 000016
【図１５】
2004248256.tif 000017
【図１６】
2004248256.tif 000018
【図１７】
2004248256.tif 000019
【図１８】
2004248256.tif 000020
【図１９】
2004248256.tif 000021
【図２０】
2004248256.tif 000022
【図２１】
2004248256.tif 000023
【図２２】
2004248256.tif 000024
【図２３】
2004248256.tif 000025
【図２４】
2004248256.tif 000026
【図２５】
2004248256.tif 000027
【図２６】
2004248256.tif 000028
【図２７】
2004248256.tif 000029
【図２８】
2004248256.tif 000030
【図２９】
2004248256.tif 000031
【図３０】
2004248256.tif 000032
【図３１】
2004248256.tif 000033
【図３２】
2004248256.tif 000034
【図３３】
2004248256.tif 000035
【図３４】
2004248256.tif 000036
【図３５】
2004248256.tif 000037
【図３６】
2004248256.tif 000038
【図３７】
2004248256.tif 000039
【図３８】
2004248256.tif 000040
【図３９】
2004248256.tif 000041
【図４０】
2004248256.tif 000042
【図４１】
2004248256.tif 000043
【図４２】
2004248256.tif 000044
【図４３】
2004248256.tif 000045