JP2004163891A - 遠隔管理システムとその電子装置，異常発生時の制御方法，およびプログラム - Google Patents

Abstract

【課題】画像形成装置等の電子装置における異常発生時の通信コストを低減させる。
【解決手段】画像形成装置１００のコントローラＣＰＵは、発生したＳＣのタイプを判別し、そのタイプのＳＣが当該画像形成装置１００の機器利用者によって解消できないタイプＡのＳＣである場合に、発生したＳＣを管理装置１０２へ通報する。判別したタイプのＳＣが当該画像形成装置１００の機器利用者によって解消可能なタイプＤのＳＣである場合に、タイプＤ用ＳＣ発生回数カウンタにアップカウントを行わせ、そのタイプＤ用ＳＣ発生回数カウンタのカウント値が所定値に達していない場合にはＳＣ発生中を知らせるメッセージを操作パネル上に表示し、所定値に達した場合には発生したＳＣを管理装置１０２へ通報する。
【選択図】 図３

Description

【０００１】
【発明の属する技術分野】
この発明は、外部装置と通信する機能を備えた電子装置と、この電子装置とこれを通信回線（ネットワーク）経由で遠隔管理する管理装置とによって構成された遠隔管理システム、および上記通信装置における異常発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラムに関する。
【０００２】
【従来の技術】
従来から、通信機能を備えたプリンタ，ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能（通信手段）を持たせた電子装置を被管理装置とし、サービスセンタ（管理センタ）の管理装置（外部装置）が公衆回線又はインタネット等の通信回線（ネットワーク）経由でこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。
【０００３】
あるいは、被管理装置が通信機能を備えていない場合や、通信機能を備えていてもその機能が管理装置と通信するための機能を持っていない場合には、その被管理装置に管理装置と通信可能な通信機能を有する仲介装置を通信回線経由で接続し、管理装置が通信回線および仲介装置経由で被管理装置を遠隔管理する遠隔管理システムも提案されている。
ここで、例えば被管理装置を画像形成装置とし、その画像形成装置について簡単に説明する。
画像形成装置としては、既知の感光体静電プロセス（電子写真プロセス）を用いて普通紙（用紙）等の記録媒体上に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル（異常）が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
【０００４】
この保守管理を充実させる目的で、画像形成装置の遠隔管理システムとして、画像形成装置の内部又は外部に仲介装置（通信装置）を設け、画像形成装置とサービスセンタに設置された管理装置とを公衆回線（電話回線）又はインタネットを介して接続し、画像形成装置内で異常が発生した場合に、その異常をセンサ等からなる異常検出手段によって検出し、その異常を仲介装置によって管理装置へ通知（通報）させるようにしたものが既に開発され（例えば特許文献１参照）、市販されている。
【０００５】
【特許文献１】
特開２００２−６６９３号公報
【０００６】
【発明が解決しようとする課題】
このような遠隔管理システムにおける画像形成装置では、異常が発生する度に、その異常をタイプ（種類）に関係なく全て管理装置へ通知するようにしている。つまり、単純操作による画像形成装置の再起動（リセット）により解消可能な異常（管理装置への通知の必要性が少ない異常）まで管理装置へ通知するようにしている。よって、通信コストが膨大になるという不都合を生じていた。また、異常発生中は停止しているため、稼動率が低下するという不都合も生じていた。
この発明は、上記の問題点に鑑みてなされたものであり、画像形成装置等の電子装置における異常発生時の通信コストを低減させることを目的とする。また、稼動率を向上させることも目的とする。
【０００７】
【課題を解決するための手段】
この発明は、上記の目的を達成するため、電子装置と、その遠隔管理システム、および上記電子装置の異常発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能を実現させるためのプログラムを提供する。
請求項１の発明による電子装置は、異常が発生した場合に、該異常を検出する異常検出手段と、該手段によって異常が検出された場合に、該異常を外部装置へ通知する異常通知手段とを有する電子装置であって、上記異常検出手段によって検出された異常のタイプを判別する異常タイプ判別手段を設け、上記異常通知手段を、上記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって（所定操作による電子装置の再起動によって）解消できない異常である場合に、該異常を上記外部装置へ通知する手段としたものである。
【０００８】
請求項２の発明による電子装置は、請求項１の電子装置において、各種機能の使用要求を受け付ける使用要求受付手段と、上記異常タイプ判別手段によって判別されたタイプの異常が所定の機能の異常である場合に、該所定の機能の使用要求が上記使用要求受付手段によって受け付けられた場合にのみ、該異常が発生している旨を表示する異常表示手段とを設けたものである。
請求項３の発明による電子装置は、請求項１又は２の電子装置において、不揮発性記憶手段と、上記異常タイプ判別手段によって判別されたタイプの異常が履歴保存のみが必要な異常である場合に、該異常の履歴を上記不揮発性記憶手段に書き込む異常履歴書込手段とを設けたものである。
【０００９】
請求項４の発明による電子装置は、請求項１〜３のいずれかの電子装置において、異常の発生回数をカウントする異常回数カウント手段と、上記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、上記異常回数カウント手段にアップカウントを行わせる異常回数カウント制御手段とを設け、上記異常通知手段に、上記異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を上記外部装置へ通知する手段を備えたものである。
請求項５の発明による電子装置は、請求項４の電子装置において、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、異常が発生している旨を表示する手段を設けたものである。
【００１０】
請求項６の発明による電子装置は、請求項４又は５の電子装置において、上記異常回数カウント手段のカウント値が上記所定値に達した場合に、そのカウント値をリセットするリセット手段を設けたものである。
請求項７の発明による電子装置は、請求項４〜６のいずれかの電子装置において、記録媒体上に画像を形成する画像形成手段を有し、上記異常検出手段により、当該電子装置の機器利用者によって解消可能な異常が検出されてから該異常が再び検出されるまでの上記画像形成手段による画像形成枚数をカウントする画像形成枚数カウント手段と、該手段のカウント値が上記所定値に達した場合に、上記異常回数カウント手段のカウント値をリセットする手段とを設けたものである。
【００１１】
請求項８の発明による電子装置は、請求項４〜７のいずれかの電子装置において、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、当該電子装置の再起動を行わせる手段を設けたものである。
請求項９の発明による電子装置は、請求項８の電子装置において、上記再起動を行わせる前に、その旨を表示する手段を設けたものである。
【００１２】
請求項１０の発明による遠隔管理システムは、管理装置により通信回線経由で複数の電子装置を遠隔管理する遠隔管理システムであって、上記複数の電子装置にそれぞれ、異常が発生した場合に、該異常を検出する異常検出手段と、該手段によって異常が検出された異常のタイプを判別する異常タイプ判別手段と、該手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消できない異常である場合に、該異常を当該電子装置の識別情報と共に上記管理装置へ通知する異常通知手段とを設けたものである。
【００１３】
請求項１１の発明による遠隔管理システムは、請求項１０の遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、異常の発生回数をカウントする異常回数カウント手段と、上記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、上記異常回数カウント手段にアップカウントを行わせる異常回数カウント制御手段とを設け、上記各電子装置の異常通知手段に、上記異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を当該電子装置の識別情報と共に上記管理装置へ通知する手段を備えたものである。
【００１４】
請求項１２の発明による遠隔管理システムは、請求項１１の遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、異常が発生している旨を表示する手段を設けたものである。
請求項１３の発明による遠隔管理システムは、請求項１１又は１２の遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、上記異常回数カウント手段のカウント値が上記所定値に達した場合に、そのカウント値をリセットするリセット手段を設けたものである。
【００１５】
請求項１４の発明による遠隔管理システムは、請求項１１〜１３のいずれかの遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、記録媒体上に画像を形成する画像形成手段と、上記異常検出手段により、当該電子装置の機器利用者によって解消可能な異常が検出されてから該異常が再び検出されるまでの上記画像形成手段による画像形成枚数をカウントする画像形成枚数カウント手段と、該手段のカウント値が上記所定値に達した場合に、上記異常回数カウント手段のカウント値をリセットする手段とを設けたものである。
【００１６】
請求項１５の発明による遠隔管理システムは、請求項１１〜１４のいずれかの遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、当該電子装置の再起動を行わせる手段を設けたものである。
請求項１６の発明による遠隔管理システムは、請求項１５の遠隔管理システムにおいて、上記複数の電子装置にそれぞれ、上記再起動を行わせる前に、その旨を表示する手段を設けたものである。
【００１７】
請求項１７の発明による異常発生時の制御方法は、異常が発生した場合に、該異常を検出して外部装置へ通知する電子装置における異常発生時の制御方法であって、上記検出した異常のタイプを判別し、そのタイプの異常が当該電子装置の機器利用者によって解消できない異常である場合に、該異常を上記外部装置へ通知するものである。
請求項１８の発明による異常発生時の制御方法は、請求項１７の異常発生時の制御方法において、上記判別したタイプの異常が所定の機能の異常である場合に、該所定の機能の使用要求を受け付けた場合にのみ、該異常が発生している旨を表示するものである。
【００１８】
請求項１９の発明による異常発生時の制御方法は、請求項１７又は１８の異常発生時の制御方法において、上記判別したタイプの異常が履歴保存のみが必要な異常である場合に、該異常の履歴を不揮発性記憶手段に書き込むものである。
請求項２０の発明による異常発生時の制御方法は、請求項１７〜１９のいずれかの異常発生時の制御方法において、上記判別したタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、異常回数カウント手段にアップカウントを行わせ、該異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を上記外部装置へ通知するものである。
【００１９】
請求項２１の発明による異常発生時の制御方法は、請求項２０の異常発生時の制御方法において、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、異常が発生している旨を表示するものである。
請求項２２の発明による異常発生時の制御方法は、請求項２０又は２１の異常発生時の制御方法において、上記異常回数カウント手段のカウント値が上記所定値に達した場合に、そのカウント値をリセットするものである。
【００２０】
請求項２３の発明による異常発生時の制御方法は、請求項２０〜２２のいずれかの異常発生時の制御方法において、上記異常回数カウント手段のカウント値が上記所定値に達していない場合には、当該電子装置の再起動を行わせるものであるものである。
請求項２４の発明による異常発生時の制御方法は、請求項２３の異常発生時の制御方法において、上記再起動を行わせる前に、その旨を表示するものである。
請求項２５の発明によるプログラムは、異常が発生した場合に、該異常を検出して該異常を外部装置へ通知する電子装置を制御するコンピュータに、請求項１〜９のいずれかの電子装置を構成する各手段としての機能を実現させるためのものである。
【００２１】
【発明の実施の形態】
以下、この発明の実施形態を図面に基づいて具体的に説明する。
まず、この発明による電子装置を被管理装置とする遠隔管理システムの構成例について説明する。
図１は、その遠隔管理システムの構成の一例を示す概念図である。
【００２２】
この遠隔管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置（電子装置）を被管理装置１０（１０ａ，１０ｂ，１０ｃ，１０ｄ，１０ｅ，１０ｆ）とする遠隔管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）によって接続された遠隔管理仲介装置である仲介装置１０１（１０１ａ，１０１ｂ，１０１ｃ）、更に仲介装置１０１とインタネット１０３（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。当該仲介装置１０１及び被管理装置１０は、その利用環境に応じて多様な階層構造を成す。
【００２３】
例えば、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Hyper TextTransfer 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）によるＳＯＡＰリクエストであることが考えられる。ウェブクライアント機能部５０１は、外部への要求を発行する処理を行う。ｌｉｂｓｏａｐ５０２は、ＳＯＡＰを処理するライブラリであり、ｌｉｂｘｍｌ５０３は、ＸＭＬ形式で記載されたデータを処理するライブラリである。また、ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。
【００４８】
次に、仲介装置１０１の物理的構成について、図８を参照して説明する。
図８は、仲介装置１０１の物理的構成例を示すブロック図である。
この仲介装置１０１は、ＣＰＵ３１，ＤＲＡＭ３２，フラッシュＲＯＭ３３，カードメモリコントローラ３４，カードメモリ３５，画像形成装置Ｉ／Ｆ３６，リアルタイムクロック回路（ＲＴＣ）３７，モデム３８，ＮＣＵ（網制御装置）３９，ＮＩＣ４０，４１，および電源回路４２によって構成されている。
【００４９】
ＣＰＵ３１は、ＤＲＡＭ３２内のＯＳ（オペレーションシステム）を含む各種プログラムに基づいて、仲介装置１０１に接続されている画像形成装置１００を制御したり、ＮＣＵ３９又はＮＩＣ４０，４１等により、公衆回線又はインタネット１０３経由で管理装置１０２に対する各種データ（又は信号）の送受信を制御したり、画像形成装置１００からのデータにより公衆回線経由で管理装置１０２に対して発呼を行ったり、回線を画像形成装置１００側に接続するか、外部通信機器である一般電話器（ＴＥＬ）又はファクシミリ装置（ＦＡＸ）側に接続するかの切り替え制御（回線切り替えタイミングの制御を含む）を行うなど、この仲介装置１０１全体を統括的に制御する中央処理装置である。
【００５０】
ＤＲＡＭ３２は、ＯＳを含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ３１がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このＤＲＡＭ３２の代わりに、ＳＲＡＭを使用してもよい。
フラッシュＲＯＭ３３は、ブート・プログラムを記憶するプログラムメモリや、管理装置１０２および各画像形成装置１００の一方から他方への送信データ、秘密パラメータ（秘密情報）を含む回線パラメータ（回線情報）などを記憶するデータベース（ＤＢ）として使用する不揮発性メモリ（不揮発性記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このフラッシュＲＯＭ３３の代わりに、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。
【００５１】
カードメモリコントローラ３４は、カードメモリ３５に対する各種データの読み書きを制御するものである。
カードメモリ３５は、ＳＤメモリ等の記録媒体（不揮発性記憶手段）であり、ＯＳ，ドライバ，アプリケーション等の各種プログラムを記録している。このプログラムは、フラッシュＲＯＭ３３に記憶するようにしてもよい。また、ＨＤＤを設け、それに記憶するようにしてもよい。
【００５２】
画像形成装置Ｉ／Ｆ３６は、遠隔管理対象となる図示しない画像形成装置を接続する画像形成装置接続手段である。
リアルタイムクロック回路３７は、時刻情報を発生するものであり、ＣＰＵ３１がそれを読み込むことによって現在の時刻を知ることができる。
モデム３８は、変復調手段であり、管理装置１０２へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置１０２から送られてくる変調されたデータを受信した場合、そのデータを復調する。
【００５３】
ＮＣＵ３９は、公衆回線経由で管理装置１０２を含む各種外部装置あるいは外部通信機器（一般電話器又はファクシミリ装置）との通信（データの送受信）を制御するものである。よって、外部通信機器接続手段としての機能を実現できる。
ＮＩＣ４０，４１は、ＬＡＮ（他のネットワークでもよい）上の遠隔管理対象となる各画像形成装置１００，ファイアウォール１０４，又は図示しないパーソナルコンピュータ等を用いた管理用端末を含む各種の外部装置（電子装置）との通信を制御したり、ファイアウォール１０４およびインタネット１０３を介して管理装置１０２を含む各種の外部装置と通信を制御するものである。よって、画像形成装置接続手段としての機能を実現できる。
電源回路４２は、ＡＣアダプタ４３からのＡＣ電源（商用電源）をＤＣ電源に変換して仲介装置１０１内の上述した各部に供給するものである。
【００５４】
ここで、モデム３８とＣＰＵ３１とは、送信データ（ＴＸ），受信データ（ＲＸ）のデータ線、および送信可能信号（ＣＴＳ），送信要求信号（ＲＴＳ），データセットレディ信号（ＤＳＲ），キャリア検出信号（ＤＣＤ）の信号線によって接続されており、モデム３８はＣＰＵ３１からの送信要求信号（ＲＴＳ）およびキャリア検出信号（ＤＣＤ）に従って制御する。
また、ＮＣＵ３９とモデム３８とは、受信データ（ＲＸＤ）および送信データ（ＴＸＤ）の信号線によって接続されている。受信データ（ＲＸＤ）は管理装置１０２のモデムにより変調されたアナログ信号、送信データ（ＴＸＤ）はモデム３８によって変調されたアナログ信号である。
【００５５】
また、ＣＰＵ３１は、電源ＯＮ（電源回路４２からの電源投入）時に、フラッシュＲＯＭ３３内のブート・プログラムに従い、カードメモリコントローラ３４を制御してカードメモリ３５内のＯＳを含む各種プログラムを読み出し、ＤＲＡＭ３２のプログラムメモリにインストールする。そして、その各種プログラムに従って動作する（その各種プログラムを必要に応じて選択的に実行する）と共に、リアルタイムクロック回路３７，モデム３８，ＮＣＵ（網制御装置）３９，ＮＩＣ４０，４１を必要に応じて選択的に使用することにより、各種機能を実現することができる。
【００５６】
次に、管理装置１０２の物理的構成について、図９を参照して説明する。
図９は、管理装置１０２の物理的構成例を示すブロック図である。
この管理装置１０２は、モデム６０１，通信端末６０２，プロキシ（Ｐｒｏｘｙ）サーバ６０３，操作者端末６０４，データベース６０５，制御装置６０６等からなる。
【００５７】
モデム６０１は、図示しない公衆回線を介して機器利用者側（例えば画像形成装置を利用しているユーザ先）の仲介装置１０１又は画像形成装置１１０と通信するものであり、送受信するデータを変復調する。このモデム６０１と後述する通信端末６０２により通信手段としての機能を果たす。
通信端末６０２は、モデム６０１による通信を制御するものである。
プロキシサーバ６０３は、インタネット１０３を介して機器利用者側の仲介装置１０１又は画像形成装置１１０との通信およびセキュリティ管理を行う。このプロキシサーバ６０３も、通信手段としての機能を果たす。
操作者端末６０４は、各種データの入力をオペレータによるキーボードやポインティングデバイス（マウス等）等の入力部上の操作により受け付ける。
【００５８】
データベース６０５は、図示しないサーバのハードディスク装置等の記憶装置に存在し、各機器利用者側の仲介装置１０１および画像形成装置１１０から受信したデータ、操作者端末６０４から入力されたデータ、およびプログラム等の各種データを記憶する。このデータベース６０５の所定領域には、パラメータ記憶エリアを備え、回線パラメータを含む各種パラメータを記憶する。
制御装置６０６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、上記プログラムに従って動作する（上記プログラムを必要に応じて実行する）と共に、モデム６０１，通信端末６０２，又はプロキシサーバ６０３を必要に応じて選択的に使用することにより、各種機能を実現することができる。
【００５９】
上述した構成を踏まえて、図３の画像形成装置管理システム内で行われるデータ送受信の際の通信シーケンスの一例について図１０を用いて説明する。なお、以下に示すＳＣＳ３０６およびＮＲＳ３０５による処理は、実際にはコントローラＣＰＵがそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。
図１０は、管理装置１０２，仲介装置１０１，および画像形成装置１００間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
【００６０】
この例においては、まず、仲介装置１０１は、インタネット１０３経由で管理装置１０２に対してポーリング（送信要求があるかどうかの問い合わせ）を行う（Ｓ６０１）。つまり、自己の識別情報である識別子を付加したポーリング用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、それをインタネット１０３経由で管理装置１０２へ送信する。
管理装置１０２は、仲介装置１０１から上記ＨＴＴＰメッセージを受信すると、課金カウンタ取得要求を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、それをインタネット１０３経由で該当する仲介装置１０１（受信したＳＯＡＰメッセージの送信元）へ送信する（Ｓ６０２）。このとき、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいて該当する仲介装置１０１を認識する。
【００６１】
仲介装置１０１は、管理装置１０２から上記ＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいて課金カウンタ取得要求を示すＳＯＡＰメッセージを生成し、それをＬＡＮ経由で自己に接続されている画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ６０３）。
ＮＲＳ３０５は、仲介装置１０１から受信したＳＯＡＰメッセージに記述されている課金カウンタ取得要求をＳＣＳ３０６へ通知する（Ｓ６０４）。
ＳＣＳ３０６は、ＮＲＳ３０５から課金カウンタ取得要求の通知を受けると、ＮＶ−ＲＡＭ２０２に格納されている課金カウンタのデータを読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータ（応答データ）をＮＲＳ３０５へ引き渡す（Ｓ６０６）。
【００６２】
ＮＲＳ３０５は、ＳＣＳ３０６から課金カウンタのデータを受け取る（取得する）と、その内容を示す課金カウンタ用のＳＯＡＰメッセージを生成し（受け取ったデータを構造化言語形式であるＸＭＬ形式に変換し）、それをＬＡＮ経由で仲介装置１０１へ送信する（Ｓ６０７）。
仲介装置１０１は、ＮＲＳ３０５から課金カウンタ用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、それをインタネット１０３経由で管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。
【００６３】
次に、上記図１０と異なり、画像形成装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について図１１を用いて説明する。
図１１は、画像形成装置１００から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、ＯＣＳ３００は、操作パネル２０５上の図示しないユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
ＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をＮＲＳ３０５へ通知する（Ｓ７０２）。
【００６４】
ＮＲＳ３０５は、ＳＣＳ３０６からユーザコール要求の通知を受けると、ユーザコールを知らせるユーザコール情報であるユーザコール用のＳＯＡＰメッセージを生成し、それをＬＡＮ経由で仲介装置１０１へ送信する（Ｓ７０３）。
仲介装置１０１は、ＮＲＳ３０５からユーザコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、それをインタネット１０３経由で管理装置１０２に対してユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由で管理装置１０２へ通報する（Ｓ７０４）。ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。
【００６５】
まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合には、その旨（ユーザコールが成功した旨）のコール結果を、正常に終了しなかった（異常に終了した）場合には、その旨（ユーザコールが失敗した旨）のコール結果を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、それをインタネット１０３経由で通報元の仲介装置１０１へ送信する（Ｓ７０５）。
仲介装置１０１は、管理装置１０２からコール結果を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコール結果を示すＳＯＡＰメッセージを生成し、それをＬＡＮ経由でユーザコールキーが押下された画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ７０６）。
【００６６】
ＮＲＳ３０５は、仲介装置１０１からコール結果を示すＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージが示すコール結果を解釈（判定）し、ＳＣＳ３０６へ通知する（Ｓ７０７）。
ＳＣＳ３０６は、コール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７０８）。
【００６７】
次に（Ｂ）において、仲介装置１０１は、規定時間（予め設定された所定時間）が経っても管理装置１０２から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すＳＯＡＰメッセージを生成し、それをＮＲＳ３０５へ送信する（Ｓ７０９）。
ＮＲＳ３０５は、失敗した旨のコール結果を示すＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに記述されている失敗した旨のコール結果を解釈し、ＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
【００６８】
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１１）。
次に（Ｃ）において、ＮＲＳ３０５は、規定時間が経っても仲介装置１０１から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をＳＣＳ３０６へ通知する（Ｓ７１２）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ引き渡す。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル２０５上の文字表示器に表示する（Ｓ７１３）。
【００６９】
ここで、画像形成装置１００は、プロッタエンジンや操作パネル２０５等の各ハードウェア資源を制御するコントローラＣＰＵが、その各ハードウェア資源の状態を監視し、いずれかのハードウェア資源で異常等の所定の事象が発生した場合、その事象を検出（検知）し、その事象の種類によって異なる処理を行う。よって、事象の種類を判定するための基準となる情報が必要であり、図１２の例は異常の種類を判定するための基準となる情報（基準情報）の一例を示すテーブルのデータ構造を示している。ここで、「ＳＣ（サービスマンコール）」は「異常」に相当するものである。同図に示すように、検出されたＳＣによって種類（タイプ）が判定される。そこで、それぞれの種類について説明する。
「タイプＡ」は、操作パネル２０５上の文字表示器（表示部）にＳＣ表示を行って使用禁止とするもののうち、機器利用者（ユーザ）によって解消（解除）できないものであり、管理装置１０２からの「ＳＣリセット」もできないものである。例えば、定着系のＳＣなどである。
【００７０】
「タイプＢ」は、異常が検出された特定（所定）の機能のみが使用できないＳＣである。通常使用時には操作パネル２０５上の文字表示器にＳＣ表示を行わないが、操作パネル２０５上のキー操作によって異常が検出されている特定の機能が選択された場合（操作パネル２０５から異常が検出されている機能の使用要求を受け付けた場合）だけ、その文字表示器にＳＣ表示を行う。例えば、両面ユニット異常時に両面モードを選択した場合が該当する。
「タイプＣ」は、ＳＣ発生時にも操作パネル２０５上の文字表示器への表示は行わず、内部的にＳＣの発生のロギング（履歴保存）のみを行うものである。例えば、通信が不能になった場合が該当する。
【００７１】
また、「タイプＤ」は、操作パネル２０５上の文字表示器にＳＣ表示を行って使用禁止とするが、主電源（電源ユニット２０７）のＯＦＦ／ＯＮ（一旦ＯＦＦにし、再びＯＮにする操作）あるいはソフト電源キーやリブートキーの操作によってＳＣを解消するものである。主電源ＯＮ（電源投入）後に再度ＳＣを検出して、見かけ上解消されない場合もある。例えば、モータ異常がそれに該当する。上記判定の基準情報は、上述したＮＶ−ＲＡＭ２０２（又はＨＤＤ２０１）の所定の格納領域に格納されていることが考えられる。なお、スキャナエンジンのＳＣ，プロッタエンジンのＳＣのように、ユニット別の事象も種類の異なる事象として扱うものとする。
【００７２】
次に、上述した画像形成装置１００および画像形成装置管理システムにおける実施形態、つまりこの発明の特徴となる処理（画像形成装置１００による異常発生時の制御）について、具体的に説明する。なお、画像形成装置１１０でも、この発明の特徴となる処理を行うが、画像形成装置１００と同様なので、ここでは説明を省略する。
この画像形成装置１００には、上述したように、公衆回線に対応した通信手段とインタネット通信に対応した通信手段の双方を設けている。
【００７３】
そして、画像形成装置１００は、仲介装置１０１および公衆回線を介して管理装置１０２と通信するカスタマー・サポート・システム方式による遠隔管理（リモートサービス：ＲＳ）と、仲介装置１０１およびインタネット１０３を介して管理装置１０２と通信するニュー・リモート・サービス方式による遠隔管理の対象となり得るように構成している。画像形成装置１１０は、仲介装置１０１の機能を備えているため、公衆回線を介して管理装置と通信するカスタマー・サポート・システム方式による遠隔管理と、インタネット１０３を介して管理装置１０２と通信するニュー・リモート・サービス方式による遠隔管理の対象となり得るように構成している。
【００７４】
ここで、画像形成装置１００および画像形成装置１１０は、自己のエンジンユニットの状態を示す情報を送信したり、自己のエンジンユニット等のハードウェア資源で通報要因となる事象が発生した場合に、その事象を知らせる事象情報等を管理装置へ通報したりするためのプログラムとして、上記のカスタマー・サポート・システム方式に対応したＣＳＳ３１５と、上記のニュー・リモート・サービス方式に対応したＮＲＳ３０５とを設けている。
以下、説明の都合上、画像形成装置１００がＮＲＳ３０５を使用する場合のこの発明の特徴となる処理について説明する。なお、画像形成装置１００がＣＳＳ３１５を使用することによってもこの発明の特徴となる処理を行うことができる。また、画像形成装置１１０がＮＲＳ３０５又はＣＳＳ３１５を使用することによってもこの発明の特徴となる処理を行うことができる。
【００７５】
まず、画像形成装置１００におけるエンジンユニット（スキャナエンジン又はプロッタエンジン）で図１２におけるタイプＡのＳＣ（異常）が発生した場合の処理について説明する。
図１３は、画像形成装置１００のエンジンユニットでタイプＡのＳＣが発生した場合の通信シーケンスの一例を示す図である。なお、以下に示す各アプリ（アプリケーション），ＳＣＳ３０６，ＮＲＳ３０５，およびＯＳＣ３００による処理は、実際にはコントローラボード２００内のＣＰＵであるコントローラＣＰＵがそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。
【００７６】
図１４は、画像形成装置１００におけるＳＣ発生時に操作パネル２０５の文字表示器に表示される各表示画面の一例を示す説明図である。これらの表示画面は、例えばＨＤＤ２０１又はＮＶ−ＲＡＭ２０２の所定記憶領域にデータとして記憶されている。
図１５はＨＴＴＰメッセージ内のＳＣ通報用のＳＯＡＰメッセージのフォーマット例を、図１６はそのＨＴＴＰメッセージの主要部分（データ）の構成をそれぞれ示す説明図である
【００７７】
図１３のシーケンス図に戻る。画像形成装置１００では、エンジンユニットでタイプＡのＳＣ（異常）が発生した場合、そのＳＣをエンジンユニットのＣＰＵであるエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨をコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ９０１）。
そのＳＣＳ３０６は、エンジンＣＰＵからＳＣが発生した旨の通知を受けると、そのＳＣのタイプを図１２に示した基準情報（基準データ）に基づいて判別する。この例では、今回発生したＳＣのタイプを当該画像形成装置１００の機器利用者によって解消できないタイプＡと判別するため、そのＳＣが発生した旨を各アプリへ通知した後（Ｓ９０２）、ＮＲＳ３０５へも通知する（Ｓ９０３）。このとき、その通知データに、画像形成装置１００の識別情報である機番情報を付加する。
【００７８】
ＮＲＳ３０５は、タイプＡのＳＣが発生した旨の通知を受けると、ＳＣ通報が必要か否か（要否）を判定するが、最初は必要と判定するので、ＳＣ通報を開始する旨をＳＣＳ３０６へ通知する（引き渡す）と共に（Ｓ９０４）、ＳＣ通報用のＳＯＡＰメッセージ（ＳＣの通知データに付加された機番情報を含む）を生成して（受け取ったＳＣの通知データを構造化言語形式であるＸＭＬ形式に変換し）、それをＬＡＮ経由で仲介装置１０１へ送信する（Ｓ９０５）。
ＳＣＳ３０６は、ＳＣ通報を開始する旨の通知を受けると、ＳＣ通報中の表示要求をＯＣＳ３００へ通知する（Ｓ９０７）。
ＯＣＳ３００は、ＳＣＳ３０６からＳＣ通報中の表示要求を受けると、例えば図１４の（１）に示すようなＳＣ通報中を知らせるメッセージの画面を操作パネル２０５上の文字表示器に表示する。この画面には、ＳＣのタイプ等の情報が表示される。
【００７９】
仲介装置１０１は、ＮＲＳ３０５からＳＣ通報用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由でサービスセンタの管理装置１０２に対してＳＣ通報を行う（Ｓ９０６）。つまり、自己の仲介装置識別子を付加したＳＣ通報用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報（自動送信）する。
【００８０】
ここで、ＨＴＴＰメッセージ内のＳＣ通報用のＳＯＡＰメッセージ（仲介装置１０１の識別子は除く）のフォーマット例について、図１５および図１６を参照して簡単に説明する。
これらの図を見て分かるように、ＳＣ通報用のＳＯＡＰメッセージは、ＳＣが発生した画像形成装置１００の識別情報である機番情報と、ＳＣコール（ＳＣ通報）を示す任意のコールＩＤと、コールタイプ（ＳＣのタイプ）と、コールの詳細を示す情報とからなる。このＳＣ通報用のＳＯＡＰメッセージには、付加情報としてＳＣが発生した画像形成装置１００のジャムやＳＣ，ステータス（状態），カウンタのそれぞれの値およびログ（履歴情報）を付加することもできる。
【００８１】
サービスセンタの管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から通報されたＳＣ通報用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合に、その受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された機番情報および仲介装置識別子に基づいて、そのＨＴＴＰメッセージの通報であるＳＣ通報が成功した旨（通報結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、インタネット１０３経由で通報元の仲介装置１０１（ＳＣ通報用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する（Ｓ９０８）。
【００８２】
また、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージをキュー（データベース６０５）に格納し、センタオペレータによって対応する処理が行われるまでキューイングする。
さらに、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージの内容を操作者端末６０４の表示部に表示してセンタオペレータに知らせる。
いずれかの機器利用者側の仲介装置１０１から通報されたＳＯＡＰメッセージを含むＨＴＴＰメッセージの受信が正常に終了しなかった場合（異常に終了した場合）には、そのＨＴＴＰメッセージの通報であるＳＣ通報が失敗した旨（通報結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された識別子に基づいてインタネット１０３経由で通報元の仲介装置１０１へ送信する。
【００８３】
仲介装置１０１は、管理装置１０２へのＳＣ通報用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報に対して、その管理装置１０２からそのＨＴＴＰメッセージの通報が成功した旨を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてＳＣ通報が成功した旨を示すＳＯＡＰメッセージを生成し、該当する（ＳＣが発生した）画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ９０９）。
そのＮＲＳ３０５は、仲介装置１０１からＳＣ通報が成功した旨を示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へＳＣ通報が成功した旨を通知する（Ｓ９１０）。
【００８４】
ＳＣＳ３０６は、ＮＲＳ３０５からＳＣ通報が成功した旨の通知を受けると、ＳＣ通報が成功した旨の表示要求をＯＣＳ３００へ通知する（Ｓ９１１）。
ＯＣＳ３００は、ＳＣＳ３０６からＳＣ通報が成功した旨の表示要求を受けると、例えば図１４の（５）に示すようなＳＣ通報が成功した旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。この画面にも、ＳＣのタイプ等の情報が表示される。
その後、主電源のＯＦＦ／ＯＮ（ソフト電源キーのＯＦＦ／ＯＮでもよい）による当該画像形成装置１００のリブート（再起動）によっても、エンジンユニットが動作可能にならない場合、つまりそのエンジンユニットが正常状態に戻っていないにもかかわらず、主電源のＯＦＦ／ＯＮごとに毎回管理装置１０２へＳＣ通報がなされてしまうのは、通信リソースの無駄であるため、下記のような処理を行う。
【００８５】
すなわち、当該画像形成装置１００のリブート後、エンジンユニットで再びタイプＡのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨を再びコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ９１２）。
そのＳＣＳ３０６は、エンジンＣＰＵから再びＳＣが発生した旨の通知を受けると、そのＳＣのタイプをタイプＡと判別し、そのＳＣが発生した旨を再び各アプリへ通知した後（Ｓ９１３）、ＮＲＳ３０５へも通知する（Ｓ９１４）。このとき、その通知データに、画像形成装置１００の識別情報である機番情報を付加する。
【００８６】
ＮＲＳ３０５は、タイプＡのＳＣが発生した旨の通知を再び受けると、そのＳＣ通報は必要ないと判定し、ＳＣ通報を行わない旨をＳＣＳ３０６へ通知する（Ｓ９１５）。
ＳＣＳ３０６は、ＳＣ通報を行わない旨の通知を受けると、ＳＣ発生中の表示要求をＯＣＳ３００へ通知する（Ｓ９１６）。
ＯＣＳ３００は、ＳＣＳ３０６からＳＣ発生中の表示要求を受けると、例えば図１４の（４）に示すようなＳＣ発生中を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。この画面には、ＳＣのタイプや連絡先等の情報も表示される。
【００８７】
なお、仲介装置１０１は、管理装置１０２へのＳＣ通報用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報に対して、その管理装置１０２からそのＨＴＴＰメッセージの通報が失敗した旨を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてＳＣ通報が失敗した旨を示すＳＯＡＰメッセージを生成し、該当する画像形成装置１００のＮＲＳ３０５へ送信する。
そのＮＲＳ３０５は、仲介装置１０１からＳＣ通報が失敗した旨を示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へＳＣ通報が失敗した旨を通知する。あるいは、仲介装置１０１へのＳＣ通報用のＳＯＡＰメッセージの送信に対して、所定時間内にその仲介装置１０１から通報結果を（ＳＣ通報が成功又は失敗した旨）を示すＳＯＡＰメッセージを受信できなかった場合にも、ＳＣＳ３０６へＳＣ通報が失敗した旨を通知する。
【００８８】
ＳＣＳ３０６は、ＮＲＳ３０５からＳＣ通報が失敗した旨の通知を受けると、ＳＣ通報が失敗した旨の表示要求をＯＣＳ３００へ通知する。
ＯＣＳ３００は、ＳＣＳ３０６からＳＣ通報が失敗した旨の表示要求を受けると、例えば図１４の（６）に示すようなＳＣ通報が失敗した旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。この画面にも、ＳＣのタイプや連絡先等の情報が表示される。
【００８９】
次に、画像形成装置１００におけるエンジンユニットで図１２におけるタイプＤのＳＣが発生した場合の処理の一例について説明する。
図１７は、画像形成装置１００のエンジンユニットでタイプＤの異常が発生した場合の通信シーケンスの一例を示す図である。
画像形成装置１００では、エンジンユニットでタイプＤのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨をコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ１００１）。
【００９０】
そのＳＣＳ３０６は、エンジンＣＰＵからＳＣが発生した旨の通知を受けると、そのＳＣのタイプを図１２に示した基準情報に基づいて判別する。この例では、今回発生したＳＣのタイプを当該画像形成装置１００の機器利用者によって解消可能なタイプＤであると判別するため、そのＳＣが発生した旨を各アプリへ通知した後（Ｓ１００２）、ＮＲＳ３０５へも通知する（Ｓ１００３）。このとき、その通知データに、画像形成装置１００の識別情報である機番情報を付加する。
ＮＲＳ３０５は、タイプＤのＳＣが発生した旨の通知を受けると、異常回数カウント手段であるタイプＤ用ＳＣ発生回数カウンタ（ＨＤＤ２０１又はＮＶ−ＲＡＭ２０２の所定記憶領域に設けている）のカウント値を読み出し、タイプＤのＳＣ発生回数を確認（判定）する（Ｓ１００４）。
【００９１】
ここで、タイプＤ用ＳＣ発生回数カウンタは、タイプＤのＳＣが発生する毎にアップカウント（＋１）するＮＲＳ／ＣＳＳ専用に用意されたカウンタである。なお、このカウンタとは別に、タイプ別ＳＣ発生回数カウンタも用意されている。そのタイプ別ＳＣ発生回数カウンタは、ＮＲＳ／ＣＳＳの制御とは一切関連がないカウンタであり、当該画像形成装置１００の納入直後からのタイプ別のＳＣの発生回数をそのままカウントする（積算する）ようになっている。
【００９２】
そして、タイプＤのＳＣ発生回数に基づいてＳＣ通報が必要か否かを判定するが、最初はタイプＤのＳＣ発生回数（タイプＤ用ＳＣ発生回数カウンタのカウント値）が所定回数（所定値）に達していないため、ＳＣ通報は必要ないと判定し、ＳＣ通報を行わない旨をＳＣＳ３０６へ通知する（Ｓ１００５）。
ＳＣＳ３０６は、ＳＣ通報を行わない旨の通知を受けると、ＳＣ発生中の表示要求をＯＣＳ３００へ通知する（Ｓ１００６）。
ＯＣＳ３００は、ＳＣＳ３０６からＳＣ発生中の表示要求を受けると、例えば図１４の（４）に示すようなＳＣ発生中を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。
【００９３】
その後、主電源のＯＦＦ／ＯＮ（ソフト電源キーのＯＦＦ／ＯＮでもよい）による当該画像形成装置１００のリブートによっても、エンジンユニットが動作可能にならず、再びタイプＤのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨を再びコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ１００７）。
以後、ＳＣＳ３０６，ＮＲＳ３０５，ＯＣＳ３００はそれぞれ、上述と同様の処理を行う（Ｓ１００８〜Ｓ１０１２）。この処理は、タイプＤのＳＣが解消しない場合、タイプＤのＳＣ発生回数が所定回数（この例では「３」）に達するまで繰り返し行うことになるが、その所定回数に達する場合には、以下の処理を行う。
【００９４】
すなわち、主電源のＯＦＦ／ＯＮ（ソフト電源キーのＯＦＦ／ＯＮでもよい）による当該画像形成装置１００のリブートによっても、エンジンユニットで再びタイプＤのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨を再びコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ１０１３）。
そのＳＣＳ３０６は、エンジンＣＰＵから再びＳＣが発生した旨の通知を受けると、そのＳＣのタイプを当該画像形成装置１００の機器利用者によって解消可能なタイプＤであると判別し、そのＳＣが発生した旨を各アプリへ通知した後（Ｓ１０１４）、ＮＲＳ３０５へも通知する（Ｓ１０１５）。
【００９５】
ＮＲＳ３０５は、タイプＤのＳＣが発生した旨の通知を再び受けると、タイプＤ用ＳＣ発生回数カウンタのカウント値を読み出し、タイプＤのＳＣ発生回数を確認する（Ｓ１０１６）。
そして、タイプＤのＳＣ発生回数に基づいてＳＣ通報が必要か否かを判定するが、今回はタイプＤのＳＣ発生回数が所定回数「３」に達するため、ＳＣ通報は必要あると判定し、ＳＣ通報を開始する旨をＳＣＳ３０６へ通知すると共に（Ｓ１０１７）、ＳＣ通報用のＳＯＡＰメッセージ（ＳＣの通知データに付加された機番情報を含む）を生成して、それを仲介装置１０１へ送信する（Ｓ１０１８）。
以後、ＳＣＳ３０６，ＮＲＳ３０５，ＯＣＳ３００，仲介装置１０１，管理装置１０２はそれぞれ、ステップＳ１０１９〜Ｓ１０２４の処理を行う。これらの処理は、図１３によって説明したステップＳ９０６〜Ｓ９１１の処理と略同様なので、説明を省略する。
【００９６】
次に、上述したＮＲＳ３０５による処理の詳細例を図１８を参照して説明する。
図１８は、ＮＲＳ３０５によるＳＣ発生時の処理の一例を示すフローチャートである。
ＮＲＳ３０５は、ＳＣＳ３０６よりＳＣが発生した旨の通知を受けると、図１８の処理ルーチンを開始し、まずそのＳＣのタイプがタイプＡの場合、既にタイプＡのＳＣが発生済みであるか否かをチェックする（Ｓ１１００）。
【００９７】
ここで、ＳＣが発生する毎に、その旨を示す情報をＳＣのタイプ別にＨＤＤ２０１又はＮＶ−ＲＡＭ２０２に記憶するようにしているため、前回（直前に）発生したＳＣが今回発生したＳＣと同一のタイプＡのＳＣで、且つ前回のＳＣ発生時点から課金カウンタ（画像形成済み用紙の正常排紙枚数をカウントするもの）がアップカウントしていない場合に、タイプＡのＳＣが発生済みであるとみなす。
タイプＡのＳＣが発生済みでないと判定した場合には、ＳＣ通報が必要と判定するので、ＳＣ通報を開始する旨をＳＣＳ３０６へ通知し（Ｓ１１０１）、ＳＣ通報処理を行う（Ｓ１１０２）。つまり、ＳＣ通報用のＳＯＡＰメッセージ（ＳＣの通知データに付加された機番情報を含む）を生成し、それを仲介装置１０１へ送信する。
【００９８】
次に、ＨＤＤ２０１又はＮＶ−ＲＡＭ２０２におけるＳＣ通報中を示すＳＣ通報中フラグを“１”にセットすると共に、通報タイムアウトタイマに所定時間（通報結果受信のタイムアウト時間であり、例えば５分）をセットして時間計測を開始（スタート）させ（Ｓ１１０３）、処理を終了する。
その後、再びＳＣＳ３０６よりＳＣが発生した旨の通知を受けて図１８の処理ルーチンを開始し、そのＳＣのタイプがタイプＡの場合には、タイプＡのＳＣが発生済みであると判定するため、ＳＣ通報を行わない旨をＳＣＳ３０６へ通知し（Ｓ１１０４）、処理を終了する。
【００９９】
一方、ＮＲＳ３０５は、ＳＣＳ３０６よりＳＣが発生した旨の通知を受けて図１８の処理ルーチンを開始し、そのＳＣのタイプがタイプＤの場合、前回のタイプＤのＳＣが発生した時からプロッタエンジンより画像形成済み用紙（用紙以外の記録媒体でもよい）が所定枚数以上正常に排紙されたか否かをその排紙枚数をカウントする排紙枚数カウンタ（画像形成枚数カウント手段）を参照して判断する（Ｓ１１０５）。なお、前回のタイプＤのＳＣが発生した時からプロッタエンジンによる画像形成枚数が所定枚数に達したか否かをその画像形成枚数をカウントする画像形成枚数カウンタを参照して判断してもよい。
【０１００】
そして、前回のタイプＤのＳＣが発生した時からプロッタエンジンより画像形成済み用紙が所定枚数（この例では１０枚）以上正常に排紙された場合（排紙枚数カウンタのカウント値が所定値に達した場合）にのみ、タイプＤ用ＳＣ発生回数カウンタを“０”にリセットする（Ｓ１１０９）。この処理を行うのは、所定枚数の排紙が正常に行われていれば、ＳＣが解消したものとみなせるためである。
次に、タイプＤ用ＳＣ発生回数カウンタをアップカウント（＋１）し（Ｓ１１０６）、そのカウンタ値を読み出してタイプＤのＳＣ発生回数を確認し、そのＳＣ発生回数に基づいてＳＣ通報が必要か否かを判定する。つまり、タイプＤのＳＣ発生回数（タイプＤ用ＳＣ発生回数カウンタのカウント値）が所定回数（所定値）である３回に達しているか否かを判定し、３回に達していなければＳＣ通報が必要ないと判定してステップＳ１１０４へ移行する（Ｓ１１０７）。なお、その所定回数は３回に限らない。
【０１０１】
タイプＤのＳＣ発生回数が３回に達した場合には、タイプＤ用ＳＣ発生回数カウンタを「０」にリセットした後（Ｓ１１０８）、ステップＳ１１０１へ移行する。
ＳＣＳ３０６よりＳＣが発生した旨の通知を受けて図１８の処理ルーチンを開始し、そのＳＣのタイプがタイプＢの場合にはステップＳ１１０１へ、タイプＣの場合にはステップＳ１１０４へそれぞれ移行する。
【０１０２】
次に、画像形成装置１００におけるエンジンユニットで図１２におけるタイプＤのＳＣが発生した場合の処理の他の例について説明する。
図１９は、画像形成装置１００のエンジンユニットでタイプＤの異常が発生した場合の通信シーケンスの他の例を示す図である。
画像形成装置１００では、エンジンユニットでタイプＤのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨をコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ１２０１）。
【０１０３】
そのＳＣＳ３０６は、エンジンＣＰＵからＳＣが発生した旨の通知を受け、そのＳＣのタイプを当該画像形成装置１００の機器利用者によって解消可能なタイプＤであると判別すると、そのＳＣが発生した旨を各アプリへ通知した後（Ｓ１２０２）、ＮＲＳ３０５へも通知する（Ｓ１２０３）。
ＮＲＳ３０５は、タイプＤのＳＣが発生した旨の通知を受けると、タイプＤ用ＳＣ発生回数カウンタのカウント値を読み出してタイプＤのＳＣ発生回数を確認し（Ｓ１２０４）、そのＳＣ発生回数に基づいてＳＣ通報が必要か否かを判定するが、最初はタイプＤのＳＣ発生回数が所定回数に達していないため、ＳＣ通報は必要ないと判定し、当該画像形成装置１００（機器）のＳＣをリセットする旨（機器リブート）をＳＣＳ３０６へ通知する（Ｓ１２０５）。
【０１０４】
ＳＣＳ３０６は、当該画像形成装置１００のＳＣをリセットする旨の通知を受けると、その旨の表示要求をＯＣＳ３００へ通知した後（Ｓ１２０６）、所定時間内にリブートキーが押下されるか、リブートキーが押下される前に所定時間が経過した（タイムアウトした）場合に、当該画像形成装置１００をリブート（再起動）させる。
ＯＣＳ３００は、ＳＣＳ３０６から当該画像形成装置１００のＳＣをリセットする旨の表示要求を受けると、例えば図１４の（３）に示すような当該画像形成装置１００のＳＣをリセットする旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。この画面の下方には、ＳＣリセット（リブート）の進捗状況を把握するための表示がある。
【０１０５】
当該画像形成装置１００のリブートによっても、エンジンユニットが動作可能にならず、再びタイプＤのＳＣが発生した場合、そのＳＣをエンジンＣＰＵがセンサを用いて検出し、ＳＣが発生した旨を再びコントローラボード２００側のＳＣＳ３０６へ通知する（Ｓ１２０７）。
以後、ＳＣＳ３０６，ＮＲＳ３０５，ＯＣＳ３００はそれぞれ、上述と同様の処理を行う（Ｓ１２０８〜Ｓ１２１２）。この処理は、タイプＤのＳＣが解消しない場合、タイプＤのＳＣ発生回数が所定回数（この例では「３」）に達するまで繰り返し行うことになるが、その所定回数に達する場合には、当該画像形成装置１００のリブートにより、エンジンユニットで再びタイプＤのＳＣが発生し、ＳＣが発生した旨がエンジンＣＰＵから通知されることにより（Ｓ１２１３）、ステップＳ１２１４〜Ｓ１２２４の処理を行う。これらの処理は、図１７によって説明したステップＳ１０１４〜Ｓ１０２４の処理と略同様なので、説明を省略する。
【０１０６】
次に、上述したＮＲＳ３０５の処理の他の詳細例を図２０を参照して説明する。なお、この処理は、図１８の処理とほとんど同じなので、異なる部分のみを説明する。
図２０は、ＮＲＳ３０５によるＳＣ発生時の処理の他の例を示すフローチャートである。
ＮＲＳ３０５は、タイプＤのＳＣ発生回数（タイプＤ用ＳＣ発生回数カウンタのカウント値）が所定回数である３回に達していない場合に、ＳＣ通報が必要ないと判定して破線で囲んで示すステップＳ１３０１へ移行する（Ｓ１１０７）。
ステップＳ１３０１では、当該画像形成装置１００のＳＣをリセットする旨（機器ＳＣリセット）をＳＣＳ３０６へ通知する。
【０１０７】
次に、ＮＲＳ３０５によるＳＣ通報結果受信処理の詳細例を図２１を参照して説明する。
図２１は、ＮＲＳ３０５によるＳＣ通報結果受信処理の一例を示すフローチャートである。
ＮＲＳ３０５は、仲介装置１０１へのＳＣ通報用のＳＯＡＰメッセージに対して、仲介装置１０１からＳＣ通報結果（ＳＣ通報が成功又は失敗した旨）を示すＳＯＡＰメッセージを受信すると、ＨＤＤ２０１又はＮＶ−ＲＡＭ２０２におけるＳＣ通報中フラグをチェックし（Ｓ１４０１）、そのＳＣ通報中フラグが“０”にリセットされていればそのまま処理を終了する。
【０１０８】
ＳＣ通報中フラグが“１”にセットされている場合には、受信したＳＣ通報結果を示すＳＯＡＰメッセージからＳＣ通報が成功したか失敗したかを判断し（Ｓ１４０２）、ＳＣ通報が成功した場合（ＳＣ通報が成功した旨を示すＳＯＡＰメッセージを受信した場合）にはＳＣ通報が成功した旨を、ＳＣ通報が失敗した場合（ＳＣ通報が失敗した旨を示すＳＯＡＰメッセージを受信した場合）にはＳＣ通報が失敗した旨をそれぞれＳＣＳ３０６へ通知した後（Ｓ１４０３，Ｓ１４０５）、ＳＣ通報中フラグおよび通報タイムアウトタイマをそれぞれ“０”にリセットして処理を終了する（Ｓ１４０４）。
【０１０９】
次に、ＮＲＳ３０５による通報タイムアウト処理の詳細例を図２２を参照して説明する。
図２２は、ＮＲＳ３０５による通報タイムアウト処理の一例を示すフローチャートである。
ＮＲＳ３０５は、通報タイムアウトタイマによる計測時間が所定時間に達した時（タイムアウト時）に該通報タイムアウトタイマから出力される信号により図２２の処理ルーチンを開始し、仲介装置１０１へのＳＣ通報用のＳＯＡＰメッセージに対して、仲介装置１０１からＳＣ通報結果を示すＳＯＡＰメッセージを受信できなかったため、ＳＣ通報が失敗したと判断してその旨をＳＣＳ３０６通知した後（Ｓ１５０１）、ＨＤＤ２０１又はＮＶ−ＲＡＭ２０２におけるＳＣ通報中フラグおよびおよび通報タイムアウトタイマをそれぞれ“０”にリセットして処理を終了する（Ｓ１５０２）。
【０１１０】
次に、図１９に示した通信シーケンスにおいて、ＳＣＳ３０６がＮＲＳ３０５から当該画像形成装置１００のＳＣをリセットする旨の通知を受けた場合の詳細例を図２３および図２４を参照して説明する。
図２３および図２４は、ＳＣＳ３０６が当該画像形成装置１００のＳＣをリセットする旨の通知を受けた場合の通信シーケンスの異なる例を示す図である。
ＳＣＳ３０６は、図１９によって説明したように、当該画像形成装置１００のＳＣをリセットする旨の通知を受けると、その旨の表示要求をＯＣＳ３００へ通知する（Ｓ１２０６）。
【０１１１】
また、リブート開始タイマに所定時間（リブートキーによるリブート開始のタイムアウト時間）をセットして時間計測を開始させる（Ｓ２００１）。
ＯＣＳ３００は、ＳＣＳ３０６から当該画像形成装置１００のＳＣをリセットする旨の表示要求を受けると、図１４の（３）に示したような当該画像形成装置１００のＳＣをリセットする旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示して機器利用者に知らせる。そして、その表示を見た機器利用者によって操作パネル２０５上のリブートキーが押下されると、図２３に示すように、その旨をＳＣＳ３０６へ通知する（Ｓ２００２）。
【０１１２】
ＳＣＳ３０６は、リブート開始タイマによる計測時間がリブート開始のタイムアウト時間を経過する前にＯＣＳ３００からリブートキーが押下された旨の通知を受けると、リブート開始タイマをキャンセル（「０」にリセット）した後（Ｓ２００３）、各アプリに対して動作中止の命令であるアプリオフラインの問い合わせをし（Ｓ２００４）、それに対して各アプリからアプリオフラインの応答（ＯＫ）を受け取ると（Ｓ２００５）、各アプリに対してアプリオフライン確定を通知した（引き渡した）後（Ｓ２００６）、操作パネル２０５との通信を停止する旨をＯＣＳ３００へ通知する（Ｓ２００７）。
【０１１３】
続いて、エンジンユニットへエンジンリセット要求を通知し（Ｓ２００８）、そのエンジンリセット要求に対する応答を受け取った後（Ｓ２００９）、ＨＤＤ２０１へアクセスを停止する旨を通知し（Ｓ２０１０）、それからエンジンユニット，操作パネル２０５，およびＨＤＤ２０１への給電を停止（電源ＯＦＦ）させた後（Ｓ２０１１）、その給電停止を解除（電源ＯＮ）させる（Ｓ２０１２）。更に、コントローラボード２００もリブートさせる（Ｓ２０１３）。
【０１１４】
一方、ＳＣＳ３０６は、ＯＣＳ３００からリブートキーが押下された旨の通知を受ける前に、リブート開始タイマによる計測時間がリブート開始のタイムアウト時間を経過した（タイムアウトした）場合には、図２４に示すように、そのリブート開始タイマからタイムアウト通知を受けるため（Ｓ２０２０）、その時点で各アプリに対して動作中止の命令であるアプリオフラインの問い合わせをし（Ｓ２００４）、以後上述と同様の処理を行う。
【０１１５】
なお、ＳＣＳ３０６は、発生（判別）したＳＣのタイプが図１２におけるタイプＢであり、そのＳＣが所定の機能のＳＣである場合には、操作パネル２０５上のキー操作によってＳＣが検出されている所定の機能が選択された場合（操作パネル２０５から異常が検出されている機能の使用要求を受け付けた場合）だけ、そのＳＣ発生中を知らせるメッセージを操作パネル２０５上の文字表示器に表示する。また、発生したＳＣのタイプがタイプＣである場合には、そのＳＣの履歴をＨＤＤ２０１又はＮＶ−ＲＡＭ２０２に書き込む。
【０１１６】
この実施形態によれば、以下の（１）〜（１１）に示す作用効果を得ることができる。
（１）画像形成装置１００のコントローラＣＰＵが、発生したＳＣのタイプを判別し、そのタイプのＳＣが当該画像形成装置１００の機器利用者によって解消できないタイプＡのＳＣである場合に、発生したＳＣを管理装置１０２へ通報（通知）するので、当該画像形成装置１００におけるＳＣ発生時の通信コストを低減することができる。
【０１１７】
（２）画像形成装置１００のコントローラＣＰＵが、管理装置１０２へのＳＣ通報に対して、その管理装置１０２からその通報結果を受信するので、タイプＡのＳＣが発生する毎にそのＳＣを管理装置１０２へ通報する必要がなくなり、当該画像形成装置１００におけるＳＣ発生時の通信コストをより低減することができる。
（３）画像形成装置１００のコントローラＣＰＵが、管理装置１０２へのＳＣ通報に対する通報結果受信のタイムアウト時間を設定し、そのタイムアウト時間内に管理装置１０２から通報結果を受信できなかった場合に、ＳＣ通報が失敗した旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示するので、いつまでも応答（通報結果の受信）を待つ必要がなくなるため、処理効率が向上する。
【０１１８】
（４）画像形成装置１００のコントローラＣＰＵが、判別したタイプのＳＣが所定の機能の異常であるタイプＢのＳＣである場合に、操作パネル２０５からその所定の機能の使用要求を受け付けた場合にのみ、そのＳＣ発生中を知らせるメッセージを操作パネル２０５上の文字表示器に表示して機器利用者に知らせるので、その機器利用者はＳＣが検出されていない機能を通常通り使用することができる。
（５）画像形成装置１００のコントローラＣＰＵが、判別したタイプのＳＣが履歴保存のみが必要なタイプＣのＳＣ（例えば通信異常）である場合には、そのＳＣの履歴をＨＤＤ２０１又はＮＶ−ＲＡＭ２０２に書き込むので、機器利用者が必要に応じて操作パネル２０５上を操作してＳＣの履歴を文字表示器に表示させることができる。
【０１１９】
（６）画像形成装置１００のコントローラＣＰＵが、判別したタイプのＳＣが当該画像形成装置１００の機器利用者によって解消可能なタイプＤのＳＣである場合に、タイプＤ用ＳＣ発生回数カウンタにアップカウントを行わせ、そのタイプＤ用ＳＣ発生回数カウンタのカウント値が所定値に達した場合に、発生したＳＣを管理装置１０２へ通報するので、当該画像形成装置１００におけるＳＣ発生時の通信コストをより低減することができる。
（７）画像形成装置１００のコントローラＣＰＵが、タイプＤ用ＳＣ発生回数カウンタのカウント値が所定値に達していない場合に、そのＳＣ発生中を知らせるメッセージを操作パネル２０５上の文字表示器に表示して機器利用者に知らせることにより、発生したＳＣを管理装置１０２へ通報することなく、機器利用者による主電源のＯＦＦ／ＯＮあるいはソフト電源キーやリブートキーの操作によってＳＣを解消することが可能になるため、当該画像形成装置１００の稼働率を向上させることができる。
【０１２０】
（８）画像形成装置１００のコントローラＣＰＵが、タイプＤ用ＳＣ発生回数カウンタのカウント値が所定値に達た場合に、そのカウント値をリセットすることにより、管理装置１０２へのＳＣ通報が的確に行われたことを知り、再度のＳＣ発生に備えることができる。
（９）画像形成装置１００のコントローラＣＰＵが、タイプＤのＳＣが検出されてから該ＳＣが再び検出されるまでの画像形成枚数（正常排紙枚数）を課金カウンタにカウントさせ、そのカウント値が所定値に達した場合に、タイプＤ用ＳＣ発生回数カウンタのカウント値をリセットすることにより、正常に機能していることになり、通信コストをより一層低減することができる。
【０１２１】
（１０）画像形成装置１００のコントローラＣＰＵが、タイプＤ用ＳＣ発生回数カウンタのカウント値が所定値に達していない場合に、当該画像形成装置１００のリブート（再起動）を自動的に行わせることにより、機器利用者による主電源のＯＦＦ／ＯＮあるいはソフト電源キーやリブートキーの操作が行われなくても、ＳＣを解消することが可能になるため、当該画像形成装置１００の稼働率をより向上させることができる。
（１１）画像形成装置１００のコントローラＣＰＵが、当該画像形成装置１００のリブート（リセット）を自動的に行わせる前に、当該画像形成装置１００のＳＣをリセットする旨を知らせるメッセージを操作パネル２０５上の文字表示器に表示して機器利用者に知らせることにより、当該画像形成装置１００の利用中のリブートを回避することが可能になる。
【０１２２】
なお、電子装置の例として通信機能（仲介機能）を持つ画像形成装置１１０および通信機能を果たす仲介装置１０１を接続した画像形成装置１００について説明したが、この発明はこれらに限られるものではなく、通信機能を持つか、通信機能を果たす仲介装置を接続したネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置に適用可能である。また、これらの装置を被管理装置とした場合にも、遠隔管理システムを上述した場合と同様に動作させることができる。さらに、電子装置の遠隔管理システムについても、電子装置，遠隔管理仲介装置，管理装置の構成及びこれらの接続形式は、以上の実施形態に限られるものではない。
【０１２３】
また、この発明によるプログラムは、外部装置と通信を行う通信手段を備えた上述の画像形成装置等の通信装置を制御するコンピュータに、この発明による各機能、つまり異常検出手段，異常通知手段，異常タイプ判別手段，使用要求受付手段，異常表示手段，異常履歴書込手段，異常回数カウント手段，異常回数カウント制御手段，リセット手段，画像形成枚数カウント手段としての機能を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
【０１２４】
このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。図７は、カードメモリ３５にこの発明による各機能を実現させるためのプログラムを格納した例である。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
【０１２５】
【発明の効果】
以上説明してきたように、この発明によれば、画像形成装置等の電子装置における異常発生時の通信コストを低減させることができる。また、稼動率を向上させることもできる。
【図面の簡単な説明】
【図１】この発明による電子装置を被管理装置とする遠隔管理システムの構成例を示す概念図である。
【図２】その遠隔管理システムにおけるデータ送受モデルを示す概念図である。
【図３】この発明による電子装置を画像形成装置とする画像形成装置遠隔管理システムの構成例を示す概念図である。
【図４】図３の画像形成装置１００のハードウェア構成例を示すブロック図である。
【図５】図３の画像形成装置１００のソフトウェア構成例を示すブロック図である。
【図６】図４，図５に示した画像形成装置１００におけるＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号について説明するための図である。
【図７】図５のＮＲＳ３０５の構成例を示す機能ブロック図である。
【図８】図３の仲介装置１０１の物理的構成例を示すブロック図である。
【図９】図３の管理装置１０２の概略構成例を示すブロック図である。
【図１０】図３に示した画像形成装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
【図１１】図３の画像形成装置１００から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
【図１２】異常の種類（タイプ）を判定するための基準となる情報のテーブルの一例を示す説明図である。
【図１３】図３の画像形成装置１００のエンジンユニットでタイプＡのＳＣが発生した場合の通信シーケンスの一例を示す図である。
【図１４】図３の画像形成装置１００におけるＳＣ発生時に操作パネルの文字表示器に表示される各表示画面の一例を示す説明図である。
【図１５】ＨＴＴＰメッセージ内のＳＣ通報用のＳＯＡＰメッセージのフォーマット例を示す説明図である。
【図１６】そのＨＴＴＰメッセージの主要部分（データ）の構成をそれぞれ示す説明図である。
【図１７】図３の画像形成装置１００のエンジンユニットでタイプＤの異常が発生した場合の通信シーケンスの一例を示す図である。
【図１８】図７のＮＲＳ３０５によるＳＣ発生時の処理の一例を示すフロー図である。
【図１９】図３の画像形成装置１００のエンジンユニットでタイプＤの異常が発生した場合の通信シーケンスの他の例を示す図である。
【図２０】図７のＮＲＳ３０５によるＳＣ発生時の処理の他の例を示すフロー図である。
【図２１】図７のＮＲＳ３０５によるＳＣ通報結果受信処理の一例を示すフロー図である。
【図２２】図７のＮＲＳ３０５による通報タイムアウト処理の一例を示すフロー図である。
【図２３】図５のＳＣＳ３０６が当該画像形成装置のＳＣをリセットする旨の通知を受けた場合の通信シーケンスの一例を示す図である。
【図２４】図５のＳＣＳ３０６が当該画像形成装置のＳＣをリセットする旨の通知を受けた場合の通信シーケンスの他の例を示す図である。
【符号の説明】
１０：被管理装置 １１：仲介機能付被管理装置
１００：画像形成装置 １０１：仲介装置
１０２：管理装置 １０３：インタネット
１０４：ファイアウォール
１１０：仲介機能付画像形成装置
２００：コントローラボード ２０１：ＨＤＤ
２０２：ＮＶ−ＲＡＭ ２０３：ＰＩボード
２０４：ＰＨＹ ２０５：操作パネル
２０６：プロッタ／スキャナエンジンボード
２０７：電源ユニット ２１２：ＰＣＩ−ＢＵＳ
３００：ＯＣＳ ３０１：ＥＣＳ
３０２：ＭＣＳ ３０３：ＮＣＳ
３０４：ＦＣＳ ３０５：ＮＲＳ
３０６：ＳＣＳ ３０７：ＳＲＭ
３０８：ＩＭＨ ３０９：コピーアプリ
３１０：ファクスアプリ ３１１：プリンタアプリ
３１２：スキャナアプリ
３１３：ネットファイルアプリ ３１４：ウェブアプリ
６０１：モデム ６０２：通信端末
６０３：プロキシサーバ ６０４：操作者端末
６０５：データベース ６０６：制御装置

Claims (25)

1. 異常が発生した場合に、該異常を検出する異常検出手段と、該手段によって異常が検出された場合に、該異常を外部装置へ通知する異常通知手段とを有する電子装置であって、
   前記異常検出手段によって検出された異常のタイプを判別する異常タイプ判別手段を設け、
   前記異常通知手段は、前記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消できない異常である場合に、該異常を前記外部装置へ通知する手段であることを特徴とする電子装置。
2. 請求項１記載の電子装置において、
   各種機能の使用要求を受け付ける使用要求受付手段と、
   前記異常タイプ判別手段によって判別されたタイプの異常が所定の機能の異常である場合に、該所定の機能の使用要求が前記使用要求受付手段によって受け付けられた場合にのみ、該異常が発生している旨を表示する異常表示手段と
   を設けたことを特徴とする電子装置。
3. 請求項１又は２記載の電子装置において、
   不揮発性記憶手段と、
   前記異常タイプ判別手段によって判別されたタイプの異常が履歴保存のみが必要な異常である場合に、該異常の履歴を前記不揮発性記憶手段に書き込む異常履歴書込手段と
   を設けたことを特徴とする電子装置。
4. 請求項１乃至３のいずれか一項に記載の電子装置において、
   異常の発生回数をカウントする異常回数カウント手段と、
   前記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、前記異常回数カウント手段にアップカウントを行わせる異常回数カウント制御手段とを設け、
   前記異常通知手段は、前記異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を前記外部装置へ通知する手段を有することを特徴とする電子装置。
5. 請求項４記載の電子装置において、
   前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、異常が発生している旨を表示する手段を設けたことを特徴とする電子装置。
6. 請求項４又は５記載の電子装置において、
   前記異常回数カウント手段のカウント値が前記所定値に達した場合に、そのカウント値をリセットするリセット手段を設けたことを特徴とする電子装置。
7. 請求項４乃至６のいずれか一項に記載の電子装置において、
   記録媒体上に画像を形成する画像形成手段を有し、
   前記異常検出手段により、当該電子装置の機器利用者によって解消可能な異常が検出されてから該異常が再び検出されるまでの前記画像形成手段による画像形成枚数をカウントする画像形成枚数カウント手段と、
   該手段のカウント値が前記所定値に達した場合に、前記異常回数カウント手段のカウント値をリセットする手段と
   を設けたことを特徴とする電子装置。
8. 請求項４乃至７のいずれか一項に記載の電子装置において、
   前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、当該電子装置の再起動を行わせる手段を設けたことを特徴とする電子装置。
9. 請求項８記載の電子装置において、
   前記再起動を行わせる前に、その旨を表示する手段を設けたことを特徴とする電子装置。
10. 管理装置により通信回線経由で複数の電子装置を遠隔管理する遠隔管理システムであって、
    前記複数の電子装置にそれぞれ、異常が発生した場合に、該異常を検出する異常検出手段と、該手段によって異常が検出された異常のタイプを判別する異常タイプ判別手段と、該手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消できない異常である場合に、該異常を当該電子装置の識別情報と共に前記管理装置へ通知する異常通知手段とを設けたことを特徴とする遠隔管理システム。
11. 請求項１０記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、異常の発生回数をカウントする異常回数カウント手段と、前記異常タイプ判別手段によって判別されたタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、前記異常回数カウント手段にアップカウントを行わせる異常回数カウント制御手段とを設け、
    前記各電子装置の異常通知手段は、前記異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を当該電子装置の識別情報と共に前記管理装置へ通知する手段を有することを特徴とする遠隔管理システム。
12. 請求項１１記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、異常が発生している旨を表示する手段を設けたことを特徴とする遠隔管理システム。
13. 請求項１１又は１２記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、前記異常回数カウント手段のカウント値が前記所定値に達した場合に、そのカウント値をリセットするリセット手段を設けたことを特徴とする遠隔管理システム。
14. 請求項１１乃至１３のいずれか一項に記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、記録媒体上に画像を形成する画像形成手段と、前記異常検出手段により、当該電子装置の機器利用者によって解消可能な異常が検出されてから該異常が再び検出されるまでの前記画像形成手段による画像形成枚数をカウントする画像形成枚数カウント手段と、該手段のカウント値が前記所定値に達した場合に、前記異常回数カウント手段のカウント値をリセットする手段とを設けたことを特徴とする遠隔管理システム。
15. 請求項１１乃至１４のいずれか一項に記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、当該電子装置の再起動を行わせる手段を設けたことを特徴とする遠隔管理システム。
16. 請求項１５記載の遠隔管理システムにおいて、
    前記複数の電子装置にそれぞれ、前記再起動を行わせる前に、その旨を表示する手段を設けたことを特徴とする遠隔管理システム。
17. 異常が発生した場合に、該異常を検出して外部装置へ通知する電子装置における異常発生時の制御方法であって、
    前記検出した異常のタイプを判別し、そのタイプの異常が当該電子装置の機器利用者によって解消できない異常である場合に、該異常を前記外部装置へ通知することを特徴とする異常発生時の制御方法。
18. 請求項１７記載の異常発生時の制御方法において、
    前記判別したタイプの異常が所定の機能の異常である場合に、該所定の機能の使用要求を受け付けた場合にのみ、該異常が発生している旨を表示することを特徴とする異常発生時の制御方法。
19. 請求項１７又は１８記載の異常発生時の制御方法において、
    前記判別したタイプの異常が履歴保存のみが必要な異常である場合に、該異常の履歴を不揮発性記憶手段に書き込むことを特徴とする異常発生時の制御方法。
20. 請求項１７乃至１９のいずれか一項に記載の異常発生時の制御方法において、
    前記判別したタイプの異常が当該電子装置の機器利用者によって解消可能な異常である場合に、異常回数カウント手段にアップカウントを行わせ、該異常回数カウント手段のカウント値が所定値に達した場合に、対応する異常を前記外部装置へ通知することを特徴とする異常発生時の制御方法。
21. 請求項２０記載の異常発生時の制御方法において、
    前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、異常が発生している旨を表示することを特徴とする異常発生時の制御方法。
22. 請求項２０又は２１記載の異常発生時の制御方法において、
    前記異常回数カウント手段のカウント値が前記所定値に達した場合に、そのカウント値をリセットすることを特徴とする異常発生時の制御方法。
23. 請求項２０乃至２２のいずれか一項に記載の異常発生時の制御方法において、
    前記異常回数カウント手段のカウント値が前記所定値に達していない場合には、当該電子装置の再起動を行わせることを特徴とする異常発生時の制御方法。
24. 請求項２３記載の異常発生時の制御方法において、
    前記再起動を行わせる前に、その旨を表示することを特徴とする異常発生時の制御方法。
25. 異常が発生した場合に、該異常を検出して該異常を外部装置へ通知する電子装置を制御するコンピュータに、請求項１乃至９のいずれか一項に記載の電子装置を構成する各手段としての機能を実現させるためのプログラム。

Images