JP2004234650A

JP2004234650A - 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム

Info

Publication number: JP2004234650A
Application number: JP2004005962A
Authority: JP
Inventors: Katsuhiko Sasaki; 勝彦佐々木
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2003-01-10
Filing date: 2004-01-13
Publication date: 2004-08-19

Abstract

【目的】画像形成装置等の通信装置が、異常事前事象等の送信要因となる事象が発生してその事象を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、外部装置側でその事象情報を容易に把握できるようにする。
【構成】
【解決手段】画像形成装置１００は、トナーニアエンド（異常事前事象）の発生によりそのトナーニアエンドを検出したとき、そのトナーニアエンド（トナーボトルの発注）を知らせるトナーサプライコール情報（事前事象情報）を管理装置１０２へ送信するが、その際に、その送信を識別するコールＩＤを生成し、それをそのトナーサプライコール情報に付加する。
【選択図】図３

Description

この発明は、外部装置と通信する機能を備えた通信装置と、この通信装置とこれをネットワークを介して遠隔管理する管理装置とによって構成された遠隔管理システム、および上記通信装置における送信要因発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能（この発明に係わる機能）を実現させるためのプログラムに関する。

従来から、通信機能を備えたプリンタ，ファクシミリ（ＦＡＸ）装置，デジタル複写機，スキャナ装置，デジタル複合機等の画像処理装置を始め、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた電子装置（通信装置）を被管理装置とし、サービスセンタ（管理センタ）の管理装置が公衆回線やインタネット等のネットワーク経由でこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。

あるいは、被管理装置が通信機能を持たない場合、その被管理装置にネットワーク経由で通信手段（通信機能）を有する仲介装置を接続し、管理装置がネットワークおよび仲介装置経由で被管理装置を遠隔管理する遠隔管理システムも提案されている。
ここで、例えば被管理装置を画像形成装置とし、その画像形成装置について簡単に説明する。
画像形成装置としては、既知の感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル（異常）が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。

この保守管理を充実させる目的で、画像形成装置の遠隔管理システムとして、画像形成装置の内部又は外部に通信手段を設け、画像形成装置とサービスセンタに設置された管理装置とを公衆回線（電話回線）を介して接続し、画像形成装置の異常事象（自己診断異常）又は異常事前事象（センサの規格レベルへの到達など、予防保全を必要とする事前警告）等の通報要因となる事象が発生した場合に、その事象をセンサ等からなる事象検出手段によって検出し、その事象の発生を知らせる事象情報等を通信手段によって管理装置（外部装置）へ送信させるようにしたものが既に開発され（例えば特許文献１参照）、市販されている。管理装置への事象情報の送信としては、自己診断異常の発生による自己診断異常情報の通報であるサービスマンコールや、事前警告の発生による事前警告情報の通報であるアラームコール（例えばサプライコール）がある。
特開２００２−６６９３号公報

このような画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象（事前警告）発生時の制御について、図３４〜図３８を参照して詳細に説明する。
図３４，図３５は、従来の画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象発生時の通信シーケンスの異なる例を示す図である。
画像形成装置は、プロッタエンジン内にセンサ等からなる事象検出部（事象検出手段）を備えており、その事象検出部が、プロッタエンジンの状態を監視し、例えば異常事前事象としてトナーニアエンドが発生した場合（トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合）、そのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラ内のＣＰＵへ通知する。

そのコントローラ内のＣＰＵは、プロッタエンジンからトナーニアエンドが発生した旨が通知されると、そのプロッタエンジン内でトナーニアエンドが発生したと判定して、ＮＶ−ＲＡＭ（不揮発性メモリ）内のトナーサプライコール済みフラグ（コール済みフラグ）およびトナーサプライコール後通紙枚数カウンタ（コール後通紙枚数カウンタ）の値をそれぞれチェックし（調べ）、トナーサプライコール済みフラグが“０”にリセットされ、且つコール後通紙枚数カウンタの値が「１０００」以上になっている（但し機器が一度もトナーサプライコールを行っていない場合には本条件を無視する）場合には、トナーサプライコール発行条件を満足しているものと判定する。

そして、ＮＶ−ＲＡＭ内のトナーサプライコールリトライ回数カウンタ（リトライ回数カウンタ）に「３」をセットした後、トナーサプライコール（トナーニアエンドの発生つまりトナーボトルの発注を知らせるトナーサプライコール情報の自動通報）用のメッセージをラインアダプタ（仲介装置）へ通知する。
また、操作部上の文字表示器に「トナーサプライコール中」のメッセージを表示する。

ラインアダプタは、コントローラからトナーサプライコール用のメッセージを受信すると、公衆回線経由でサービスセンタの管理装置に対してトナーサプライコールを行う。つまり、トナーボトルの発注を知らせるトナーサプライコール情報（事前事象情報）を公衆回線経由でサービスセンタの管理装置へ自動通報する。
サービスセンタの管理装置は、機器利用者（この例では画像形成装置を利用しているユーザ）側に設置されているラインアダプタから通報されたトナーサプライコール情報を受信し、その受信が正常に終了すると、その旨（トナーサプライコールに対する処理が成功した旨）のコール結果（ＯＫ）を公衆回線経由で通報元のラインアダプタへ送信する。

また、受信したトナーサプライコール情報をキュー（例えばハードディスク装置内のデータベース）に格納し、管理装置のオペレータ（以下「センタオペレータ」という）によって対応する処理、つまりトナーボトルの受注作業が行われるまでキューイング（保持）する。
さらに、受信したトナーサプライコール情報を表示部に表示してセンタオペレータに知らせる。
センタオペレータは、管理装置の表示部の表示内容を見て通報元のラインアダプタに接続されている画像形成装置のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元のラインアダプタの設置場所にトナーボトルを届けさせる。

通報元のラインアダプタは、サービスセンタの管理装置へのトナーサプライコールの結果（トナーサプライコール情報の送信結果）として、その管理装置からコールＯＫ（トナーサプライコール情報の受信が正常に終了した旨の送信結果）を受信すると、そのコールＯＫを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラ内のＣＰＵは、ラインアダプタからコールＯＫの通知を受けると、管理装置へのトナーサプライコールが成功したと判断し、操作部上の文字表示器に「トナーサプライコール成功」のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２内のトナーサプライコールの成功を示すトナーサプライコール済みフラグを“１”にセットすると共に、ＮＶ−ＲＡＭ内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「０」にリセットし、「０」からカウント動作を行えるようにする。

画像形成装置のプロッタエンジン内のトナーボトルが交換され、トナーフルが発生した場合（トナーボトル内のトナー量が満杯になった場合）、事象検出部が、そのトナーフルを検出し、トナーフルが発生した旨をコントローラへ通知する。
そのコントローラ内のＣＰＵは、プロッタエンジンからトナーフルが発生した旨の通知を受けると、ＮＶ−ＲＡＭ内のコール済みフラグを“０”にリセットし、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「１０００」にならないと、サプライコールを行うことはない。

一方、通報元のラインアダプタは、サービスセンタの管理装置へのトナーサプライコールの結果（トナーサプライコール情報の送信結果）として、その管理装置からコールＯＫ（トナーサプライコール情報の受信が正常に終了した旨の送信結果）を予め設定された所定時間が経過しても受信できなかった場合、コールＮＧを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラのＣＰＵは、ラインアダプタからコールＮＧを受けると、管理装置へのトナーサプライコールが失敗したと判断し、操作部上の文字表示器に「トナーサプライコール失敗」のメッセージを表示する。

また、ＮＶ−ＲＡＭ内のリトライ回数カウンタをデクリメント（−１）した後、そのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一のトナーサプライコール情報の通報回数が予め設定された所定回数である３回に達していない場合）に、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知する。なお、ここでの初回通報とは、同一のトナーサプライコール情報の１回目の通報のことをさす。
ラインアダプタは、コントローラから初回通報時と同一のトナーサプライコール用のメッセージを受信すると、公衆回線経由でサービスセンタの管理装置に対して再びトナーサプライコールを行わせる。つまり、初回通報時と同一のトナーサプライコール情報を再び公衆回線経由でサービスセンタの管理装置へ自動通報させる。

その後、サービスセンタの管理装置へのトナーサプライコールの結果として、その管理装置からコールＯＫを予め設定された所定時間が経過しても受信できなかった場合、再びコールＮＧを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラ内のＣＰＵは、ラインアダプタから再びコールＮＧを受けると、管理装置へのトナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ内のリトライ回数カウンタをデクリメント（−１）した後、そのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合に、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知し、以後上述と同様の制御を行う。

その後、ラインアダプタから再びコールＮＧを受けると、管理装置へのトナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ内のリトライ回数カウンタをデクリメント（−１）した後、そのリトライ回数カウンタの値をチェックすると、その値が「０」になっている（同一のトナーサプライコール情報の通報回数が３回に達した）ため、初回通報時と同一のトナーサプライコール用のメッセージのラインアダプタへの通知（リトライ）を中止（停止）する。

図３６は、画像形成装置のコントローラ内のＣＰＵによるトナーニアエンド発生時の処理（制御）の概略例を示すフローチャートである。
画像形成装置のコントローラのＣＰＵは、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図３６の処理を開始し、まずステップＳ１０１でＮＶ−ＲＡＭ内のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“０”にリセットされていることを確認できた場合にステップＳ１０２へ進み、画像形成装置納入後、初めてサプライコールを行うか否かを判断する。

そして、画像形成装置納入後、初めてサプライコールを行うのであれば（トナーニアエンドが発生した場合には）そのままステップＳ１０４へ進むが、初めてサプライコールを行うのでなければステップＳ１０３でＮＶ−ＲＡＭ内のコール後通紙枚数カウンタの値（前回通報時の転写紙通紙枚数）が「１０００」に達したか否かを判断し、「１０００」に達していればステップＳ１０４へ進む。この判断は、ドアオープン等によるトナーニアエンドの誤検出に対応するものである。
ステップＳ１０４では、ＮＶ−ＲＡＭ内のリトライ回数カウンタに「３」をセット（設定）する。

そして、ステップＳ１０５でトナーサプライコール用のメッセージをラインアダプタへ通知し、公衆回線経由でサービスセンタの管理装置に対してトナーサプライコールを行わせる。
その後、ラインアダプタからの通知を待ち、ラインアダプタからコールＯＫの通知を受けた場合には、ステップＳ１０６で管理装置へのトナーサプライコールが成功したと判断してステップＳ１０７へ移行し、後述する処理を行う。
また、ラインアダプタからコールＮＧの通知を受けた場合には、ステップＳ１０６で管理装置へのトナーサプライコールが失敗したと判断してステップＳ１１０へ移行し、次の処理を行う。

すなわち、ステップＳ１１０でＮＶ−ＲＡＭ内のリトライ回数カウンタをデクリメント（−１）した後、ステップＳ１１１でそのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一のトナーサプライコール情報の通報回数が３回に達していない場合）にステップＳ１０５へ戻り、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知し、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「０」になったら、図３６の処理を終了する。

リトライ回数カウンタの値が「０」になる前に、ステップＳ１０６で管理装置へのトナーサプライコールが成功したと判断すると、ステップＳ１０７でＮＶ−ＲＡＭ内のトナーサプライコール済みフラグを“１”にセットした後、ステップＳ１０８でＮＶ−ＲＡＭ内のコール後通紙枚数カウンタの値を、ステップＳ１０９でリトライ回数カウンタの値をそれぞれ「０」にリセットし、図３６の処理を終了する。

図３７は、画像形成装置のコントローラ内のＣＰＵによる転写紙正常排紙時の処理の概略例を示すフローチャートである。
画像形成装置のコントローラのＣＰＵは、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、コール後通紙枚数カウンタをインクリメント（＋１）する。
図３８は、画像形成装置のコントローラ内のＣＰＵによるトナーフル時の処理の概略例を示すフローチャートである。
画像形成装置のコントローラのＣＰＵは、トナーボトルの交換によりトナーフルが発生し、そのトナーフルが事象検出部によって検出されると、ＮＶ−ＲＡＭ内のトナーサプライコール済みフラグを“０”にリセットする。

しかしながら、このような画像形成装置遠隔管理システムでは、機器利用者側の画像形成装置が、仲介装置（ラインアダプタ）を用いて又は単独で（この場合仲介装置としての機能を有する）管理装置への異常事前事象情報又は異常事象情報等の事象情報の通報の実行中に、自己の主電源が機器利用者の操作等によってＯＦＦ／ＯＮされた場合（一旦遮断されて再び投入された場合）、その実行中の通報が中断されるため、以後同じ事象が再び発生しない限りは、実行中だった通報を再開することができないという問題がある。例えば、上述したトナーサプライコールの実行中に、上記主電源が機器利用者の操作等によってＯＦＦ／ＯＮされた場合、そのトナーサプライコールが中断されるため、トナーニアエンドが発生しない限りは、実行中だったトナーサプライコールを直ちに再開することができない。機器のトナー残量検知機構によっては、一度トナーニアエンドになった後、メインカバーの開閉や主電源のＯＦＦ／ＯＮにより、トナーニアエンド状態が解除される場合がある。また、主電源ＯＦＦ中にトナーボトルが交換される場合も考えられる。そのような場合、主電源のＯＦＦ／ＯＮにより、トナーニアエンド状態が解除されてしまうため、トナーニアエンドが発生したという状態が継続しない場合がありうる。なお、機器利用者は、主電源のＯＦＦ／ＯＮによって異常事象等の事象が解除される場合があることを知っているため、異常事象等の事象の検出によって操作部上に対応するエラーメッセージが表示されるような場合には、主電源をＯＦＦ／ＯＮさせるための操作を行う場合が多い。

管理装置では、仲介装置又は画像形成装置からの事象情報の通報が中断された場合、その事象情報を正常に受信していない場合がある。例えば、サプライコールが中断された場合、サプライコール情報を正常に受信していない場合がある。その場合、サプライの発注が行われないことになる。
一方、仲介装置又は画像形成装置からの事象情報の通報が中断された場合でも、その事象情報を正常に受信している場合がある。例えば、サプライコールが中断された場合でも、サプライコール情報を正常に受信している場合がある。その場合、サプライの発注が行われることになる。

ところが、事象情報を正常に受信した後、画像形成装置側で同じ事象が再び発生し、その事象の発生を知らせる事象情報を受信すると、同じ事象情報を重複して受信することになる。例えば、同一のサプライコール情報を重複して受信することになり、同じサプライの２重発注が行われることになる。
この発明は、上記の問題点に鑑みてなされたものであり、画像形成装置等の通信装置が、異常事象又は異常事前事象等の送信要因（通報要因）となる事象が発生してその事象の発生を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、その外部装置側でその事象情報を容易に把握できるようにすることを目的とする。

この発明は、上記の目的を達成するため、通信装置と、その遠隔管理システム、および上記通信装置の送信要因発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能を実現させるためのプログラムを提供する。

請求項１の発明による通信装置は、外部装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報を上記通信手段によって上記外部装置へ送信させる事象情報送信手段とを有する通信装置であって、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成手段を設け、上記事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して上記通信手段によって上記外部装置へ送信させる手段としたものである。

請求項２の発明による通信装置は、請求項１の通信装置において、上記事象情報送信手段による上記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記事象情報送信手段に、上記送信結果判断手段によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。

請求項３の発明による通信装置は、請求項２の通信装置において、上記事象情報送信手段による上記再送信が停止した後、上記外部装置への事象情報の送信が失敗した旨を示す情報に、上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項４の発明による通信装置は、請求項３の通信装置において、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。

請求項５の発明による通信装置は、請求項４の通信装置において、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項６の発明による通信装置は、請求項２〜５のいずれかの通信装置において、時間計測を行なう時間計測手段を設け、上記事象情報送信手段に、上記再送信を停止した後、上記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、上記再送信制御を再度行う手段を備えたものである。

請求項７の発明による通信装置は、請求項１の通信装置において、上記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、上記事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象種判別手段によって判別された事象の種類を示す情報および上記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して上記通信手段によって上記外部装置へ送信させる手段としたものである。

請求項８の発明による通信装置は、請求項７の通信装置において、上記事象情報送信手段による上記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記事象情報送信手段に、上記送信結果判断手段によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。

請求項９の発明による通信装置は、請求項８の通信装置において、上記事象情報送信手段による上記再送信が停止した後、上記外部装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。

請求項１０の発明による通信装置は、請求項９の通信装置において、上記送信失敗報知手段によって上記外部装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたものである。

請求項１１の発明による通信装置は、請求項１０の通信装置において、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項１２の発明による通信装置は、請求項１〜１１のいずれかの通信装置において、上記事象情報送信手段に、上記通信手段によって上記外部装置へ送信すべき情報を構造化言語形式に変換する手段を備えたものである。

請求項１３の発明による遠隔管理システムは、管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、上記複数の通信装置にそれぞれ、上記管理装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に自己の識別情報を付加して上記通信手段によって上記管理装置へ送信させる事象情報送信手段と、該手段によって上記管理装置へ事象情報が送信される際に、該事象情報の送信中を示す事象情報送信中状態に設定する事象情報送信中状態設定手段とを設け、上記管理装置に、上記複数の通信装置と通信する通信手段と、該手段によっていずれかの通信装置から事象情報を受信し、該受信が正常に終了した場合に、その旨の送信結果を該事象情報に付加された識別情報に基づいて該事象情報を送信した通信装置へ上記通信手段によって送信させる送信結果送信手段とを設けたものである。

請求項１４の発明による遠隔管理システムは、請求項１３の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記各通信装置の事象情報送信手段に、上記送信結果判断手段によって上記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同じ事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記管理装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。

請求項１５の発明による遠隔管理システムは、請求項１４の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記再送信が停止した後、上記管理装置への事象情報の送信が失敗した旨を示す情報に、上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項１６の発明による遠隔管理システムは、請求項１５の遠隔管理システムにおいて、上記の通信装置にそれぞれ、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。

請求項１７の発明による遠隔管理システムは、請求項１６の遠隔管理システムにおいて、上記の通信装置にそれぞれ、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたものである。

請求項１８の発明による遠隔管理システムは、請求項１４〜１７のいずれかの遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、時間計測を行なう時間計測手段を設け、上記各通信装置の事象情報送信手段に、上記再送信を停止した後、上記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、上記再送信制御を再度行う手段を備えたものである。

請求項１９の発明による遠隔管理システムは、請求項１３の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、上記各通信装置の事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象種判別手段によって判別された事象の種類を示す情報，上記事象情報送信情報生成手段によって生成された事象情報送信情報，および自己の識別情報を付加して上記通信手段によって上記管理装置へ送信させる手段としたものである。

請求項２０の発明による遠隔管理システムは、請求項１９の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記各通信装置の事象情報送信手段に、上記送信結果判断手段によって上記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記管理装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。

請求項２１の発明による遠隔管理システムは、請求項２０の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記再送信が停止した後、上記管理装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。

請求項２２の発明による遠隔管理システムは、請求項２１の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記送信失敗報知手段によって上記管理装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたものである。

請求項２３の発明による遠隔管理システムは、請求項２２の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたものである。

請求項２４の発明による送信要因発生時の制御方法は、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信する通信装置における送信要因発生時の制御方法であって、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成し、該事象情報に該事象情報送信情報を付加して上記外部装置へ送信するものである。

請求項２５の発明による送信要因発生時の制御方法は、請求項２４の送信要因発生時の制御方法において、上記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断し、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には該事象情報を再び上記外部装置へ送信し、該事象情報の送信回数が上記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行い、この再送信制御時に上記再送信すべき同一の事象情報には上記生成した同一の事象情報送信情報を繰り返し付加するものである。

請求項２６の発明によるプログラムは、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信するようにした通信装置を制御するコンピュータに、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成機能と、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報に上記事象情報送信情報生成機能によって生成された事象情報送信情報を付加して上記外部装置へ送信する事象情報送信機能とを実現させるためのプログラムである。

請求項２７によるプログラムは、請求項２６のプログラムにおいて、上記コンピュータに、上記事象情報送信機能による上記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する機能と、該機能によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信し、該事象情報の送信回数が上記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行う機能と、該機能によって再送信される同一の事象情報には上記事象情報送信情報生成機能によって生成された同一の事象情報送信情報を繰り返し付加する機能とを実現させるためのプログラムも含むプログラムである。

この発明によれば、画像形成装置等の通信装置が、異常事象又は異常事前事象等の送信要因となる事象が発生してその事象を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、その外部装置（管理装置）側でその事象情報を容易に把握することができる。

以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
まず、この発明による通信装置を被管理装置とする遠隔管理システムの構成例について説明する。
図１は、その遠隔管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される通信装置（電子装置）を説明の便宜上「被管理装置」と云う。

この遠隔管理システムは、プリンタ，ＦＡＸ装置，デジタル複写機，デジタル複合機等の画像形成装置やスキャナ装置などの画像処理装置、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システムなどに通信機能を持たせた通信装置（電子装置）を被管理装置１０（１０ａ，１０ｂ，１０ｃ，１０ｄ，１０ｅ，１０ｆ）とする管理システムである。そして、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）等のネットワークによって接続された遠隔管理仲介装置である仲介装置１０１（１０１ａ，１０１ｂ，１０１ｃ）、更に仲介装置１０１とインタネット１０３（公衆回線等の他のネットワークでもよい）を介して接続されるサーバ装置として機能する管理装置１０２を備え、当該管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。被管理装置１０および仲介装置１０１は機器利用者（ユーザ）側のオフィス等に、管理装置１０２はサービスセンタ（管理センタ）にそれぞれ設置されている。

ここで、管理装置１０２が新たな方式を用いて遠隔管理するサービス（ＮＲＳ）を実現するために、機器利用者側のＬＡＮ等のネットワークに、ＮＲＳに対応するソフトウェアを実装した仲介装置１０１および被管理装置１０が接続されている。その仲介装置１０１および被管理装置１０には、管理装置１０２が従来の方式を用いて遠隔管理するサービス（ＣＳＳ）も実現するために、ＣＳＳに対応するソフトウェアも実装している。ＮＲＳを実現するためには、ＣＳＳを実現する場合と同様に、仲介装置１０１および被管理装置１０を初期設置すればよい。
公衆回線（又は専用回線）としては、アナログ回線，ＡＤＳＬ回線，デジタル回線（ＩＳＤＮ回線），光ファイバー利用回線等の固定電話回線や、携帯電話回線，ＰＨＳ回線等の移動電話回線がある。
なお、仲介装置１０１と被管理装置１０との接続は、ネットワークに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（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）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。

ここで、画像形成装置１００は、自己のエンジンユニット内で異常事象又は異常事前事象等の通報要因となる事象が発生した場合、その事象を検出し、その事象の種類によって異なる処理を行う。よって、事象の種類を判定するための基準となる情報が必要であり、図１１の例は異常事象（異常）の種類を判定するための基準となる情報の一例を示すテーブルのデータ構造を示している。ここで、「ＳＣ（サービスマンコール）」は「異常事象」に相当するものである。同図に示すように、検出されたＳＣによって種類（タイプ）が判定される。そこで、それぞれの種類について説明する。

「タイプＡ」のＳＣは、操作パネル２０５にＳＣ表示を行って使用禁止（使用不可）とするもののうち、ユーザ（機器利用者）が解除できないＳＣである。このタイプＡのＳＣは、管理装置１０２からの「ＳＣリセット」もできない。例えば、定着系のＳＣなどである。「タイプＡ」は画像形成装置１００（機器）側のメインスイッチ（主電源スイッチ）のＯＦＦ／ＯＮによる主電源のＯＦＦ／ＯＮもしくはソフト電源キーの操作によるエンジンユニットへの給電停止／解除によっては復旧できない。

「タイプＢ」は、異常が検出（検知）された特定の機能のみが使用できないＳＣである。通常使用時には操作パネル２０５上にＳＣ表示を行わないが、異常が検出されている機能が選択された時だけ、その操作パネル２０５上にＳＣ表示を行う。例えば、両面ユニット（両面トレイ）異常時に両面モードが選択された場合が該当する。
「タイプＣ」は、異常発生時にも操作パネル２０５へのＳＣ表示は行わず、内部的にＳＣの発生のロギングのみを行うものである。例えば、通信が不能になった場合が該当する。

「タイプＤ」は、操作パネル２０５上にＳＣ表示を行って使用禁止とするが、画像形成装置１００側のメインスイッチのＯＦＦ／ＯＮによる主電源のＯＦＦ／ＯＮもしくはソフト電源キーの操作によるエンジンユニットへの給電停止／解除によって解除できるＳＣである。但し、主電源ＯＮ（電源投入）後もしくはエンジンユニットへの給電停止／解除後に、再度異常を検出して、見かけ上解除されない場合もある。例えば、モータ異常がそれに該当する。
上記判定の基準情報は、上述したＮＶ−ＲＡＭ２０２（又はＨＤＤ２０１）の所定の格納領域に格納されていることが考えられる。なお、スキャナエンジンのＳＣ，プロッタエンジンのＳＣのように、ユニット別の事象も種類の異なる事象として扱うものとする。

次に、上述した画像形成装置および画像形成装置遠隔管理システムにおける実施例、つまりこの発明の特徴となる動作（画像形成装置での通報要因発生時の制御）およびその動作を実現するための構成について説明する。
この画像形成装置には、上述したように、公衆回線に対応した通信手段とインタネット通信に対応した通信手段の双方を設けている。
そして、画像形成装置１００は、仲介装置１０１および公衆回線を介して管理装置１０２と通信するＣＳＳ方式による遠隔管理（リモートサービス：ＲＳ）と、仲介装置１０１およびインタネット１０３を介して管理装置１０２と通信するＮＲＳ方式による遠隔管理の対象となり得るように構成している。画像形成装置１１０は、仲介装置１０１の機能を備えているため、公衆回線を介して管理装置と通信するＣＳＳ方式による遠隔管理と、インタネット１０３を介して管理装置１０２と通信するＮＲＳ方式による遠隔管理の対象となり得るように構成している。

ここで、画像形成装置１００および画像形成装置１１０は、自己のエンジンユニットの状態を示す情報を送信したり、自己のエンジンユニット等に異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、その事象の発生を知らせる事象情報等を管理装置へ通報したりするためのプログラムとして、上記のＣＳＳ方式に対応したＣＳＳ３１５と、上記のＮＲＳ方式に対応したＮＲＳ３０５とを設けている。

以下、説明の都合上、画像形成装置１００がＮＲＳ３０５を使用する場合のこの発明に係わる制御について説明する。但し、エンジンユニットに相当するものがスキャナエンジンおよびプロッタエンジンしかないものとする。
なお、画像形成装置１００がＣＳＳ３１５を使用することによってもこの発明に係わる制御を行うことができる。また、画像形成装置１１０がＮＲＳ３０５又はＣＳＳ３１５を使用することによってもこの発明に係わる制御を行うことができる。

〔第１実施例〕
図１２は、この画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド（異常事前事象）発生時の通信シーケンスの第１例（トナーサプライコール成功例）を示す図である。
画像形成装置１００では、スキャナエンジンおよびプロッタエンジン内の各部にそれぞれ事象検出部を備えており、例えば図１２に示すように、プロッタエンジン内でトナーボトルのトナーニアエンドが発生した場合（トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合）、対応する事象検出部がそのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラボード２００のＳＣＳ３０６へ通知する（Ｓ１００１）。

ＳＣＳ３０６は、プロッタエンジンからトナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内でトナーニアエンドが発生したと判定して、ＮＶ−ＲＡＭ（不揮発性メモリ）２０２内のトナーサプライコール済みフラグ（コール済みフラグ）およびトナーサプライコール後通紙枚数カウンタ（コール後通紙枚数カウンタ）の値をそれぞれチェックし（Ｓ１００２，Ｓ１００３）、トナーサプライコール済みフラグ（コール済みフラグ）が“０”にリセットされ、且つコール後通紙枚数カウンタの値が「１０００」以上になっている（但し機器が一度もトナーサプライコールを行っていない場合には本条件を無視する）場合には、トナーサプライコール発行条件を満足しているものと判定する。

そして、ＮＶ−ＲＡＭ２０２内のメール送信済みフラグを“０”にリセットした後（Ｓ１００４）、ＮＶ−ＲＡＭ内のトナーサプライコールリトライ回数カウンタ（リトライ回数カウンタ）に「３」をセットし（Ｓ１００５）、トナーサプライコール（トナーニアエンドの発生つまりトナーボトルの発注を知らせるトナーサプライコール情報の自動通報）を識別するコールＩＤ（事象情報送信情報）を生成して（Ｓ１００６）、そのコールＩＤをＮＶ−ＲＡＭ２０２に保存し（Ｓ１００７）、トナーサプライコールの実行中を示すサプライコール実行中フラグ（事象情報送信中状態）を“１”にセット（設定）した後（Ｓ１００８）、トナーサプライコール要求をＮＲＳ３０５へ通知する（Ｓ１００９）。このとき、そのトナーサプライコール要求に、画像形成装置１００の識別情報である機番情報およびＮＶ−ＲＡＭ２０２に保存したコールＩＤを付加する。また、操作パネル２０５上の文字表示器には、「トナーサプライコール中」のメッセージを表示する。

ＮＲＳ３０５は、トナーサプライコール要求の通知を受けると、トナーボトルの発注（トナーニアエンドの発生）を知らせるトナーサプライコール情報であるトナーサプライコール用のＳＯＡＰメッセージ（トナーサプライコール要求に付加された機番情報およびコールＩＤを含む）を生成して、それを仲介装置１０１へ送信する（Ｓ１０１０）。
仲介装置１０１は、ＮＲＳ３０５からトナーサプライコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対してトナーサプライコールを行う（Ｓ１０１１）。つまり、自己の仲介装置識別子を付加したトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報（自動送信）する。

ここで、ＨＴＴＰメッセージ内のトナーサプライコール用のＳＯＡＰメッセージ（仲介装置識別子は除く）のフォーマット例について、図３１および図３２を参照して簡単に説明する。
図３１はＨＴＴＰメッセージ内のトナーサプライコール用のＳＯＡＰメッセージのフォーマット例を、図３２はその主要部分（データ）の構成をそれぞれ示す説明図である。

これらの図を見て分かるように、トナーサプライコール用のＳＯＡＰメッセージは、トナーニアエンドが発生した画像形成装置１００の識別情報である機番情報と、トナーサプライコールを識別する任意のコールＩＤと、コールタイプ（第１実施例ではトナーサプライコールの種類を示す情報は含まないものとする）と、コールの詳細を示す情報とからなる。このトナーサプライコール用のＳＯＡＰメッセージには、付加情報としてトナーニアエンドが発生した画像形成装置１００のジャムやＳＣ，ステータス（状態），カウンタのそれぞれの値およびログ（履歴情報）を付加することもできる。

管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から通報されたトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合に、その受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された機番情報および仲介装置識別子に基づいて、そのＨＴＴＰメッセージの受信が正常に終了した旨（トナーサプライコールに対する処理が成功した旨）のコール結果であるコールＯＫを示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、インタネット１０３経由で通報元の仲介装置１０１（トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する（Ｓ１０１２）。

また、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージ（トナーサプライコール情報）をキュー（データベース６０５）に格納し、センタオペレータによって対応する処理、つまりトナーボトルの受注作業が行われるまでキューイング（保持）する。
さらに、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージの内容を操作者端末６０４の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末６０４の表示部の表示内容を見て通報元の仲介装置１０１に接続されている画像形成装置１００のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置１０１の設置場所にトナーボトルを届けさせる。

仲介装置１０１は、管理装置１０２へのトナーサプライコール（トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報）の結果として、その管理装置１０２からコールＯＫ（上記ＨＴＴＰメッセージの受信が正常に終了した旨のコール結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコールＯＫを示すＳＯＡＰメッセージを生成し、それを該当する（トナーニアエンドが発生した）画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ１０１３）。
そのＮＲＳ３０５は、仲介装置１０１からコールＯＫを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＯＫ（トナーサプライコールが正常に終了した旨）を通知する（Ｓ１０１４）。

ＳＣＳ３０６は、ＮＲＳ３０５からコールＯＫの通知を受けると、管理装置１０２へのトナーサプライコールが成功したと判断し、操作パネル２０５上の文字表示器に「トナーサプライコール成功」のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２内のサプライコール実行中フラグを“０”にリセット（解除）し（Ｓ１０１５）、ＮＶ−ＲＡＭ２０２内のトナーサプライコールの成功を示すトナーサプライコール済みフラグ（事象送信済み状態）を“１”にセットする（Ｓ１０１６）。
さらに、ＮＶ−ＲＡＭ２０２内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「０」にリセットし（Ｓ１０１７，Ｓ１０１８）、「０」からカウント動作を行えるようにする。

画像形成装置１００のプロッタエンジン内のトナーボトルが交換され、トナーフルが発生した場合（トナーボトル内のトナー量が満杯になった場合）、対応する事象検出部が、そのトナーフルを検出し、トナーフルが発生した旨をＳＣＳ３０６へ通知する（Ｓ１０１９）。
ＳＣＳ３０６は、プロッタエンジンからトナーフルが発生した旨の通知を受けると、ＮＶ−ＲＡＭ２０２内のコール済みフラグを“０”にリセットし（Ｓ１０２０）、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「１０００」にならないと、サプライコールを行うことはない。

図１３および図１４は、この画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第２例（トナーサプライコール失敗例）を示す図である。なお、ステップＳ２００１〜Ｓ２０１１の制御は図１２のステップＳ１００１〜Ｓ１０１１の制御と同様なので、その説明を省略する。
一方、通報元の仲介装置１０１は、例えば図１３に示すように、ステップＳ２０１１のサービスセンタの管理装置１０２へのトナーサプライコール（トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報）の結果として、その管理装置１０２からコールＯＫ（上記ＨＴＴＰメッセージの受信が正常に終了した旨のコール結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを規定時間（予め設定された所定時間）が経過しても受信できなかった場合、そのＨＴＴＰメッセージに基づいてコールＮＧを示すＳＯＡＰメッセージを生成し、それを該当する画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ２０１２）。
そのＮＲＳ３０５は、仲介装置１０１からコールＮＧを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＮＧ（トナーサプライコールが正常に終了しなかった旨）を通知する（Ｓ２０１３）。

ＳＣＳ３０６は、ＮＲＳ３０５からコールＮＧの通知を受けると、管理装置１０２へのトナーサプライコールが失敗したと判断し、操作パネル２０５上の文字表示器に「トナーサプライコール失敗」のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）し（Ｓ２０１４）、初回コール（初回通報）時と同一のトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを再通報するために、リトライ（再通報）制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一のトナーサプライコールの回数が予め設定された所定回数である３回に達していない場合）に、再び初回コール時と同一のトナーサプライコール要求をＮＲＳ３０５へ通知する（Ｓ２０１５）。このとき、そのトナーサプライコール要求に、ＮＶ−ＲＡＭ２０２に保存しておいた初回コール時と同一のコールＩＤを付加する。なお、ここでの初回コールとは、同一のトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの１回目の通報のことをさす。

ＮＲＳ３０５は、ＳＣＳ３０６から初回コール時と同一のトナーサプライコール要求の通知を受けると、初回コール時と同一のトナーサプライコール用のＳＯＡＰメッセージを生成して、それを仲介装置１０１へ送信する（Ｓ２０１６）。
仲介装置１０１は、ＮＲＳ３０５から初回コール時と同一のトナーサプライコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに再び自己の仲介装置識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対してトナーサプライコールを行う（Ｓ２０１７）。つまり、自己の識別子を付加したトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報する。

その後、サービスセンタの管理装置１０２へのトナーサプライコールの結果として、その管理装置１０２からコールＯＫを示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを規定時間が経過しても受信できなかった場合、再びそのＨＴＴＰメッセージに基づいてコールＮＧを示すＳＯＡＰメッセージを生成し、それを該当する画像形成装置１００のＮＲＳ３０５へ送信する（Ｓ２０１８）。
そのＮＲＳ３０５は、仲介装置１０１から再びコールＮＧを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＮＧを通知する（Ｓ２０１９）。

ＳＣＳ３０６は、ＮＲＳ３０５から再びコールＮＧの通知を受けると、管理装置１０２へのトナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後（Ｓ２０２０）、そのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合に、再び初回コール時と同一のトナーサプライコール要求をＮＲＳ３０５へ通知する（Ｓ２０２１）。それによってＮＲＳ３０５および仲介装置１０１が上述と同様の処理（制御）を行う（Ｓ２０２２，Ｓ２０２３）。
その後、ＮＲＳ３０５から再びコールＮＧの通知を受けると（Ｓ２０２５）、管理装置１０２へのトナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後（Ｓ２０２６）、そのリトライ回数カウンタの値をチェックすると、その値が「０」になっている（同一のトナーサプライコールの回数が３回に達した）ため、上述したリトライ（再送信）を停止し、以下に示す処理を行う。

すなわち、ＮＶ−ＲＡＭ２０２内のメール送信済みフラグの状態をチェックし（Ｓ２０２７）、そのメール送信済みフラグが“０”になっていると確認できた場合に、管理装置１０２へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知する（Ｓ２０２８）。このとき、その電子メール送信要求に、画像形成装置１００の機番情報および初回コール時と同一のコールＩＤを付加する。そして、その電子メール送信要求をＤＣＳ３１６へ通知した後、ＮＶ−ＲＡＭ２０２内のメール送信済みフラグを“１”にセットした後（Ｓ２０２９）、図示しない２４Ｈ（２４時間）タイマ（時間計測手段）を起動（開始）させる（Ｓ２０３０）。
ＤＣＳ３１６は、ＳＣＳ３０６から電子メール送信要求の通知を受けると、管理装置１０２へのトナーサプライコールが失敗した旨を報知するための電子メールをＬＡＮ経由で図示しないサプライ管理端末（パーソナルコンピュータ等）へ送信する。

ここで、管理装置１０２へのトナーサプライコール（トナーサプライの発注）が失敗した旨を報知するための電子メールについて、図１６を参照して簡単に説明する。
図１６は、その電子メールの内容の一例を示す説明図である。
この電子メールは、画像形成装置１００のシステム初期設定等によって予め設定されたアドレス（[email protected]）へ通報される。この例では、サプライを管理するためのサプライ管理端末へ通報される。そのサプライ管理端末装置は、サプライ管理担当者によって使用される。

この電子メールには、画像形成装置１００の識別情報である機器識別ＩＤ（機番情報）および初回コール時と同一のコールＩＤを組にしたＩＤ（先頭１１桁が機器識別ＩＤで、後の１０桁がコールＩＤ）の他に、サプライの名称（この例では黒トナーボトル）やサービスセンタの電話番号である連絡先電話番号を添付（付加）する。なお、この第１実施例では、１色（黒）のトナーボトルしか備えていないものとしているため、サプライの名称は単にトナーボトルとしてもよい。後述する第２実施例では、複数色のトナーボトルを備えているものとするため、サプライの名称を黒トナーボトルや赤トナーボトルというようにする。つまり、電子メールにトナーボトルの種類を示す情報を添付する。
この電子メールを受信したサプライ管理端末装置を使用しているサプライ管理担当者は、その電子メールに記載された連絡先電話番号へ電話するが、その際にサプライの名称とＩＤを連絡する。
サービスセンタ側では、トナーサプライの２重発注を防ぐために、以下の（１）（２）に示す作業を行う。

（１）機器利用者側からの電話連絡後、上記電子メールを送信した画像形成装置１００から仲介装置１０１経由で同一のＩＤのトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージ（トナーサプライコール情報）がインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報され（電話連絡後にＮＲＳ通信が正常復帰し)、管理装置１０２でそのＨＴＴＰメッセージの受信が正常に終了した場合、そのトナーサプライコール（トナーサプライコールの発注コール）情報を無視する。そのため、管理装置１０２は、電話連絡によって通知されたＩＤを登録しておき、その後そのＩＤと同一のＩＤの発注コール情報を受信した場合には、それを受注対象外コール情報として自動破棄する処理を行う。この場合、電話連絡により、センタオペレータがトナーサプライの発注業務を開始することになる。

（２）既に同一のＩＤの発注コール情報が通報された後、電話連絡があった場合（電話連絡前にＮＲＳ通信が正常復帰した場合)には、センタオペレータがその電話連絡時に同一のＩＤによるトナーサプライの発注の有無を調査する。そして、電話連絡されたＩＤと同一ＩＤの発注履歴が存在した場合には、既にＮＲＳ通信にて発注業務が開始されているため、電話連絡による発注業務は実施しない。
なお、コールＩＤは、画像形成装置１００の納入時に、「０」にリセットされる。

トナーニアエンドが発生した画像形成装置１００のコントローラボード２００のＳＣＳ３０６は、２４Ｈタイマを起動させた後（Ｓ２０３０）、例えば図１４に示すように、その２４Ｈタイマによる計測時間が２４時間を経過すると（Ｓ２０３１）、再びリトライ回数カウンタに「３」をセットした後（Ｓ２０３２）、初回コール時と同一のトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを再通報するために、再び上述と同様のリトライ制御を行う（Ｓ２０３３）。

このリトライ制御（１回目のリトライ制御）を行っても、管理装置１０２へのトナーサプライコールが失敗した場合（ＮＲＳ３０５から再びコールＮＧの通知を受けた場合）には（Ｓ２０３７）、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）して（Ｓ２０３８）、再び上述と同様のリトライ制御（２回目のリトライ制御）を行い（Ｓ２０３９）、それでも管理装置１０２へのトナーサプライコールが失敗した場合には（Ｓ２０４３）、リトライ回数カウンタをデクリメント（−１）して（Ｓ２０４４）、再び上述と同様のリトライ制御（３回目のリトライ制御）を行う（Ｓ２０４５）。

３回目のリトライ制御を行なっても、管理装置１０２へのトナーサプライコールが失敗した場合には（Ｓ２０４９）、リトライ回数カウンタをデクリメント（−１）すると（Ｓ２０５０）、リトライ回数カウンタの値が「０」になっている（同一のトナーサプライコールの回数が３回に達した）ため、上述したリトライ（再送信）を再度停止し、ＮＶ−ＲＡＭ２０２内のメール送信済みフラグの状態をチェックする（Ｓ２０５１）が、この場合にはメール送信済みフラグが既に“１”にセットされているため、管理装置１０２へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知しない（電子メール送信の通知を禁止する）。しかし、２４Ｈ（２４時間）タイマは再起動させ（Ｓ２０５２）、以後管理装置１０２へのトナーサプライコールが成功するまで上述と同様の制御を繰り返す。

図１５は、この画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第３例（トナーサプライコール中の主電源ＯＦＦ／ＯＮ時の例）を示す図である。
ところで、管理装置１０２へのトナーサプライコールの実行中に、本体主電源（電源ユニット２０７）がＯＦＦ／ＯＮした場合（本体主電源が一旦遮断した後再投入された場合）には、例えば図１５に示すような制御を行う。
すなわち、ＮＶ−ＲＡＭ２０２内のサプライコール実行中フラグの状態をチェックし（Ｓ３００１）、そのサプライコール実行中フラグが“０”にリセットされていると確認できた場合には何もしないが、“１”にセットされていると確認できた場合には、管理装置１０２へのトナーサプライコールの実行中に本体主電源がＯＦＦ／ＯＮし、そのトナーサプライコールが成功していないため、再びリトライ回数カウンタに「３」をセットした後（Ｓ３００２）、上述と同様のリトライ制御を行う（Ｓ３００３）。

以後、図１４と略同様の制御を行う。異なるのは、もし３回目のリトライ制御を行っても、管理装置１０２へのトナーサプライコールが失敗した場合には、リトライ回数カウンタをデクリメント（−１）すると（Ｓ３０１１）、リトライ回数カウンタの値が「０」になっているため、上述したリトライ（再送信）を再度停止した後、ＮＶ−ＲＡＭ２０２内のメール送信済みフラグの状態をチェックする（Ｓ３０１２）が、メール送信済みフラグが“１”にセットされていないため、管理装置１０２へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知する（Ｓ３０１３）ことである。

図１７および図１８は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６によるトナーニアエンド発生時の処理の概略例を示すフローチャートである。
画像形成装置１００のＳＣＳ３０６は、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図１７および図１８の処理ルーチンを開始し、まずステップＳ１でＮＶ−ＲＡＭ２０２のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“０”にリセットされていると確認できた場合にステップＳ２へ進み、画像形成装置１００の納入後、初めてトナーサプライコールを行うか否かを判断する。

そして、画像形成装置１００の納入後、初めてトナーサプライコールを行うのであれば（初めてトナーニアエンドが発生した場合には）そのままステップＳ４へ進むが、初めてトナーサプライコールを行うのでなければステップＳ３でＮＶ−ＲＡＭ２０２内のコール後通紙枚数カウンタの値が「１０００」に達したか否かを判断し、「１０００」に達していればステップＳ４へ進み、コールＩＤを生成する。このコールＩＤとしては、前回生成したものと異なるものを生成する。例えば、前回生成したコールＩＤが「０００００００００１」であった場合、今回生成するコールＩＤを「０００００００００２」とする。リトライ制御時には、同一のコールＩＤを繰り返し使用する。

次に、ステップＳ５で生成したコールＩＤをＮＶ−ＲＡＭ２０２に保存（セット）し、ステップＳ６でＮＶ−ＲＡＭ２０２内のサプライコール実行中フラグを“１”にセットし、ステップＳ７でＮＶ−ＲＡＭ２０２内のメール送信済みフラグを“０”にリセットし、ステップＳ８でＮＶ−ＲＡＭ２０２内のリトライ回数カウンタに「３」をセットした後、ステップＳ９でトナーサプライコール要求に画像形成装置１００の機番情報およびＮＶ−ＲＡＭ２０２に保存したコールＩＤを付加してＮＲＳ３０５へ通知する。
その後、ステップＳ１０でＮＲＳ３０５からの通知の有無をチェックし、ＮＲＳ３０５からコールＯＫの通知を受けた場合には、管理装置１０２へのトナーサプライコールが成功したと判断してステップＳ１１へ移行し、後述する処理を行う。

ＮＲＳ３０５からコールＮＧの通知を受けた場合には、管理装置１０２へのトナーサプライコールが失敗したと判断してステップＳ１５へ移行し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後、ステップＳ１６でそのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一のトナーサプライコールの回数が３回に達していない場合）にステップＳ９へ戻り、再び初回コール時と同一のトナーサプライコール要求をＮＲＳ３０５へ通知し（そのトナーサプライコール要求に画像形成装置１００の機番情報およびＮＶ−ＲＡＭ２０２に保存しておいた初回コール時と同一のコールＩＤを付加する）、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「０」になったら、次の処理を行う。

すなわち、図１８のステップＳ１７でＮＶ−ＲＡＭ２０２内のメール送信済みフラグの状態をチェックし、そのメール送信済みフラグが“１”にセットされていると確認できた場合にはそのままステップＳ２０へ移行するが、“０”にリセットされていると確認できた場合にはステップＳ１８で管理装置１０２へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知する。このとき、その電子メール送信要求に、画像形成装置１００の機番情報および初回コール時と同一のコールＩＤを付加する。そして、その電子メール送信要求をＤＣＳ３１６へ通知した後、ステップＳ１９でＮＶ−ＲＡＭ２０２内のメール送信済みフラグを“１”にセットした後、ステップＳ２０で２４時間タイマを起動させ、その２４時間タイマによる計測時間が２４時間経過するのを待って、図１７のステップＳ８へ戻り、上述と同様の処理を繰り返す。

リトライ回数カウンタの値が「０」になる前に、ステップＳ１０で管理装置１０２へのトナーサプライコールが成功したと判断した場合には、ステップＳ１１でＮＶ−ＲＡＭ２０２内のトナーサプライコール済みフラグを“１”にセットし、ステップＳ１２でＮＶ−ＲＡＭ２０２内のコール後通紙枚数カウンタの値を、ステップＳ１３でリトライ回数カウンタの値をそれぞれ「０」にリセットした後、ステップＳ１４でＮＶ−ＲＡＭ２０２内のサプライコール実行中フラグを“０”にリセットし、図１７，図１８の処理を終了する。

図１９は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による主電源ＯＮ時の処理例の一部を示すフローチャートである。
画像形成装置１００のＳＣＳ３０６は、主電源ＯＮ時にＮＶ−ＲＡＭ２０２内のサプライコール実行中フラグの状態をチェックし、そのサプライコール実行中フラグが“１”にセットされていると確認できた場合にのみ、図１７のステップＳ８以降の処理と同様の処理を行う。
なお、ＳＣＳ３０６による転写紙正常排紙時の処理およびトナーフル時の処理はそれぞれ、図３７，図３８によって説明した処理と同様なので、その図示および説明は省略する。

第１実施例によれば、以下の（１）〜（１０）にそれぞれ示す作用効果を得ることができる。
（１）画像形成装置１００（又は１１０）が、自己でのトナーニアエンド（異常事前事象）の発生によってそのトナーニアエンドを検出した場合に、そのトナーニアエンドの発生（トナーボトルの発注）を知らせるトナーサプライコール情報（事前事象情報）を管理装置１０２へ送信（通報）するが、その際にトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“１”にセットする（事象情報送信中状態に設定する）ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、トナーサプライコール情報の送信の実行中に自己の主電源がＯＦＦになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びＯＮになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。

（２）画像形成装置１００が、トナーサプライコール情報を管理装置１０２へ送信する際に、その送信を識別するコールＩＤを生成し、それをそのトナーサプライコール情報に付加することにより、管理装置１０２側で画像形成装置１００から重複送信（例えば２重送信）された同一のトナーサプライコール情報を容易に把握できるため、トナーボトルの重複発注を防止することもできる。
（３）画像形成装置１００が、管理装置１０２へのトナーサプライコール情報の送信結果として、管理装置１０２からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、サプライコール実行中フラグを“０”にリセットする（事象情報送信中状態を解除する）ことにより、以後そのＳＣコール済みフラグの状態を参照すれば、トナーサプライコール情報の送信が完了したことを確認することができる。

（４）画像形成装置１００が、管理装置１０２へのトナーサプライコール情報の送信結果として、管理装置１０２からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、そのトナーサプライコール情報の送信が失敗したと判断し、その場合にそのトナーサプライコール情報と同一のトナーサプライコール情報の送信回数が予め設定された所定回数に達していない場合には、そのトナーサプライコール情報を再び管理装置１０２へ送信させ、そのトナーサプライコール情報の送信回数が上記所定回数に達した場合に、そのトナーサプライコール情報の再送信を停止する再送信（リトライ）制御を行うことにより、トナーサプライコール情報の送信の実行中に通信上のトラブルが発生した場合でも、そのトナーサプライコール情報の送信を完了させることが可能になる。

（５）画像形成装置１００が、再送信制御によって再送信する同一のトナーサプライコール情報に、同一のコールＩＤ（そのサプライコール情報の初回送信時に生成したコールＩＤ）を繰り返し付加することにより、同一のトナーサプライコール情報を送信する毎に異なるコールＩＤを生成する処理を行わなくて済むため、その分だけ処理効率が向上する。
（６）画像形成装置１００が、再送信制御によってトナーサプライコール情報の再送信を停止した後、管理装置１０２へのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する（操作パネル２０５上への表示や用紙への画像形成によって報知してもよい）ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、トナーサプライコール情報（トナーボトルの発注）の内容を電話によってセンタオペレータに伝えることができる。つまり、トナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。

（７）画像形成装置１００が、管理装置１０２へのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知した後、その旨を示すメール送信済みフラグを“１”にセットし（報知済み状態に設定し）、その報知を禁止することにより、その報知の重複を回避でき、その分だけ処理効率が向上する。
（８）画像形成装置１００が、メール送信済みフラグを“１”にセットした後、新たにトナーニアエンドを検出した場合には、メール送信済みフラグを“０”にリセットし（報知済み状態を解除し）、上記報知の禁止を解除することにより、再び管理装置１０２へのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、トナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。

（９）画像形成装置１００が、２４Ｈタイマ（２４時間が予め設定されている）に時間計測を開始させ、２４Ｈタイマによる計測時間が２４時間（予め設定された所定時間）を経過した場合に、上述と同様の再送信制御を再度行うことにより、トナーサプライコール情報をセンタオペレータにより一層確実に伝えることができる。なお、２４Ｈタイマ以外のタイマ（２４時間以外の所定時間が予め設定されている）を利用することもできる。

（１０）画像形成装置１００が、主電源ＯＮ（電源投入）時にサプライコール実行中フラグの状態（セットの有無）を調べ、そのサプライコール実行中フラグが“１”にセットされていると確認できた場合に、管理装置１０２へのトナーサプライコール情報の送信が成功していないと判断し、その場合にも上述と同様の再送信制御を行うことにより、管理装置１０２へのトナーサプライコール情報の送信実行中に自己の主電源がＯＦＦになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びＯＮになった時に、その実行中だったトナーサプライコール情報の送信を自動的に再開することができる。よって、トナーサプライコール情報の内容を最速で確実にセンタオペレータに伝えることができる。

なお、主電源ＯＮ時にサプライコール実行中フラグの状態を調べ、そのサプライコール実行中フラグが“１”にセットされていると確認できた場合に、管理装置１０２へのトナーサプライコール情報の送信が成功していないと判断し、その旨を操作パネル２０５上への表示や用紙への画像形成等によって報知することもできる。そして、この報知を行う場合、例えば操作パネル２０５上の操作等により、実行中だったトナーサプライコール情報の送信を再開させることもできる。

〔第２実施例〕
図２０は、この画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第３例を示す図である。図２１は、ＮＶ−ＲＡＭ２０２内の２種類のサプライコール実行中フラグの状態を示す説明図である。なお、図２０の黒トナーコール処理および赤トナーコール処理はいずれも、第１実施例で説明した処理と略同様なので、内容の詳細は省略する。異なる点は、各種フラグやカウンタ等がトナー色別に存在し、そのトナー色別に処理を行うことである。
画像形成装置１００のプロッタエンジン内で黒トナーボトルのトナーニアエンド（黒トナーニアエンド）が発生した場合（黒トナーサプライである黒トナーボトル内のトナー量が所定量以下になった場合）、対応する事象検出部が黒トナーニアエンドを検出し、黒トナーニアエンドが発生した旨をコントローラボード２００のＳＣＳ３０６へ通知する。

ＳＣＳ３０６は、プロッタエンジンから黒トナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内で黒トナーニアエンドが発生したと判定して（つまりトナーニアエンドが発生したと判定すると共にそのトナーニアエンドの種類を判別して）、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコール済みフラグおよび黒トナーサプライコール後通紙枚数カウンタ（黒トナーコール後通紙枚数カウンタ）の値をそれぞれチェックし、黒トナーサプライコール済みフラグが“０”にリセットされ、且つ黒トナーコール後通紙枚数カウンタの値が「１０００」以上になっている（但し機器が一度も黒トナーサプライコールを行っていない場合には本条件を無視する）場合には、黒トナーサプライコール発行条件を満足しているものと判定する。

そして、ＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグを“０”にリセットした後、ＮＶ−ＲＡＭ内のトナーサプライコールリトライ回数カウンタ（リトライ回数カウンタ）に「３」をセットし、黒トナーサプライコール（黒トナーニアエンドの発生つまりトナーボトルの発注を知らせる黒トナーサプライコール情報の自動通報）を識別するコールＩＤを生成して、そのコールＩＤをＮＶ−ＲＡＭ２０２に保存し、黒トナーサプライコールの実行中を示す黒トナーサプライコール実行中フラグ（事象情報送信中状態）を“１”にセット（設定）した後、黒トナーサプライコール要求をＮＲＳ３０５へ通知する。このとき、トナーサプライコール要求に、画像形成装置１００の識別情報である機番情報，ＮＶ−ＲＡＭ２０２に保存したコールＩＤ，および判別したトナーニアエンド（又はそれに対応するトナーサプライコール）の種類を示す情報（コールタイプ）を付加する。また、操作パネル２０５上の文字表示器には、「黒トナーサプライコール中」のメッセージを表示する。

ＮＲＳ３０５は、黒トナーサプライコール要求の通知を受けると、黒トナーボトルの発注（黒トナーニアエンドの発生）を知らせる黒トナーサプライコール情報である黒トナーサプライコール用のＳＯＡＰメッセージ（黒トナーサプライコール要求に付加された機番情報，コールＩＤ，コールタイプを含む）を生成して、それを仲介装置１０１へ送信する。
仲介装置１０１は、ＮＲＳ３０５から黒トナーサプライコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対して黒トナーサプライコールを行う。つまり、自己の仲介装置識別子を付加した黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報する。

管理装置１０２は、いずれかの機器利用者側の仲介装置１０１から通報された黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信し、その受信が正常に終了した場合に、その受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージに付加された機番情報および仲介装置識別子に基づいて、そのＨＴＴＰメッセージの受信が正常に終了した旨（黒トナーサプライコールに対する処理が成功した旨）のコール結果であるコールＯＫを示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを生成し、インタネット１０３経由で通報元の仲介装置１０１（黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを送信した仲介装置１０１）へ送信する。

また、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージ（黒トナーサプライコール情報）をキューに格納し、センタオペレータによって対応する処理、つまり黒トナーボトルの受注作業が行われるまでキューイングする。
さらに、受信したＨＴＴＰメッセージ内のＳＯＡＰメッセージの内容を操作者端末６０４の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末６０４の表示部の表示内容を見て通報元の仲介装置１０１に接続されている画像形成装置１００のプロッタエンジン内で黒トナーニアエンドが発生し、黒トナーボトルが発注されたことを認識すると、黒トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置１０１の設置場所に黒トナーボトルを届けさせる。

仲介装置１０１は、管理装置１０２への黒トナーサプライコール（黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報）の結果として、その管理装置１０２からコールＯＫ（上記ＨＴＴＰメッセージの受信が正常に終了した旨のコール結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを受信すると、そのＨＴＴＰメッセージに基づいてコールＯＫを示すＳＯＡＰメッセージを生成し、それを該当する（黒トナーニアエンドが発生した）画像形成装置１００のＮＲＳ３０５へ送信する。
そのＮＲＳ３０５は、仲介装置１０１からコールＯＫを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＯＫ（黒トナーサプライコールが正常に終了した旨）を通知する。

ＳＣＳ３０６は、ＮＲＳ３０５からコールＯＫの通知を受けると、管理装置１０２への黒トナーサプライコールが成功したと判断し、操作パネル２０５上の文字表示器に「黒トナーサプライコール成功」のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコール実行中フラグを“０”にリセット（解除）し、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコールの成功を示す黒トナーサプライコール済みフラグ（事象送信済み状態）を“１”にセットする。
さらに、ＮＶ−ＲＡＭ２０２内の黒トナーコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「０」にリセットし、「０」からカウント動作を行えるようにする。

画像形成装置１００のプロッタエンジン内の黒トナーボトルが交換され、黒トナーフルが発生した場合（黒トナーボトル内のトナー量が満杯になった場合）、対応する事象検出部が、黒トナーフルを検出し、黒トナーフルが発生した旨をＳＣＳ３０６へ通知する。
ＳＣＳ３０６は、プロッタエンジンから黒トナーフルが発生した旨の通知を受けると、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコール済みフラグを“０”にリセットし、次の黒トナーニアエンドでサプライコールを行えるようにする。但し、黒トナーコール後通紙枚数カウンタの値が「１０００」にならないと、黒トナーサプライコールを行うことはない。

一方、通報元の仲介装置１０１は、サービスセンタの管理装置１０２への黒トナーサプライコール（黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージの自動通報）の結果として、その管理装置１０２からコールＯＫ（上記ＨＴＴＰメッセージの受信が正常に終了した旨のコール結果）を示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを規定時間が経過しても受信できなかった場合、そのＨＴＴＰメッセージに基づいてコールＮＧを示すＳＯＡＰメッセージを生成し、それを該当する画像形成装置１００のＮＲＳ３０５へ送信する。
そのＮＲＳ３０５は、仲介装置１０１からコールＮＧを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＮＧ（黒トナーサプライコールが正常に終了しなかった旨）を通知する。

ＳＣＳ３０６は、ＮＲＳ３０５からコールＮＧの通知を受けると、管理装置１０２への黒トナーサプライコールが失敗したと判断し、操作パネル２０５上の文字表示器に「黒トナーサプライコール失敗」のメッセージを表示する。
また、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）し、初回コール（初回通報）時と同一のトナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを再通報するために、リトライ（再通報）制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一の黒トナーサプライコールの回数が予め設定された所定回数である３回に達していない場合）に、再び初回コール時と同一の黒トナーサプライコール要求をＮＲＳ３０５へ通知する。このとき、その黒トナーサプライコール要求に、ＮＶ−ＲＡＭ２０２に保存しておいた初回コール時と同一のコールＩＤを付加する。

ＮＲＳ３０５は、ＳＣＳ３０６から初回コール時と同一の黒トナーサプライコール要求の通知を受けると、初回コール時と同一の黒トナーサプライコール用のＳＯＡＰメッセージを生成して、それを仲介装置１０１へ送信する。
仲介装置１０１は、ＮＲＳ３０５から初回コール時と同一の黒トナーサプライコール用のＳＯＡＰメッセージを受信すると、そのＳＯＡＰメッセージに再び自己の仲介装置識別子を付加し、更にそのＳＯＡＰメッセージに基づいてＨＴＴＰメッセージを生成し、インタネット１０３経由で管理装置１０２に対して黒トナーサプライコールを行う。つまり、自己の識別子を付加した黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージをインタネット１０３経由でサービスセンタの管理装置１０２へ自動通報する。

その後、サービスセンタの管理装置１０２への黒トナーサプライコールの結果として、その管理装置１０２からコールＯＫを示すＳＯＡＰメッセージを含むＨＴＴＰメッセージを規定時間が経過しても受信できなかった場合、再びそのＨＴＴＰメッセージに基づいてコールＮＧを示すＳＯＡＰメッセージを生成し、それを該当する画像形成装置１００のＮＲＳ３０５へ送信する。
そのＮＲＳ３０５は、仲介装置１０１から再びコールＮＧを示すＳＯＡＰメッセージを受信すると、ＳＣＳ３０６へコールＮＧを通知する。

ＳＣＳ３０６は、ＮＲＳ３０５から再びコールＮＧの通知を受けると、管理装置１０２への黒トナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後、そのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合に、再び初回コール時と同一の黒トナーサプライコール要求をＮＲＳ３０５へ通知し、以後上述と同様の処理を行う。
その後、ＮＲＳ３０５から再びコールＮＧの通知を受けると、管理装置１０２への黒トナーサプライコールが失敗したと判断し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後、そのリトライ回数カウンタの値をチェックすると、その値が「０」になっている（同一の黒トナーサプライコールの回数が３回に達した）ため、上述したリトライ（再送信）を停止し、以下に示す処理を行う。

すなわち、ＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグの状態をチェックし、その黒トナーメール送信済みフラグが“０”になっていると確認できた場合に、管理装置１０２への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知する。このとき、その電子メール送信要求に、画像形成装置１００の機番情報，初回コール時と同一のコールＩＤ，およびコールタイプを付加する。そして、その電子メール送信要求をＤＣＳ３１６へ通知した後、ＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグを“１”にセットした後、２４Ｈタイマを起動させる。
ＤＣＳ３１６は、ＳＣＳ３０６から電子メール送信要求の通知を受けると、管理装置１０２への黒トナーサプライコールが失敗した旨を報知するための電子メールをＬＡＮ経由で図示しないサプライ管理端末へ送信する。

黒トナーニアエンドが発生した画像形成装置１００のコントローラボード２００のＳＣＳ３０６は、２４Ｈタイマを起動させた後、その２４Ｈタイマによる計測時間が２４時間を経過すると、再びリトライ回数カウンタに「３」をセットした後、初回コール時と同一の黒トナーサプライコール用のＳＯＡＰメッセージを含むＨＴＴＰメッセージを再通報するために、再び上述と同様のリトライ制御を行う。

このリトライ制御を行っても、管理装置１０２への黒トナーサプライコールが３回失敗した場合には、再びリトライを停止し、ＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグの状態をチェックするが、この場合には黒トナーメール送信済みフラグが既に“１”にセットされているため、管理装置１０２への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知しない（電子メール送信の通知を禁止する）。しかし、２４Ｈタイマは再起動させ、以後管理装置１０２への黒トナーサプライコールが成功するまで上述と同様の制御を繰り返す。

ところで、管理装置１０２への黒トナーサプライコールの実行中に、本体主電源がＯＦＦ／ＯＮした場合（本体主電源が一旦遮断した後再投入された場合）には、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコール実行中フラグの状態をチェックし、その黒トナーサプライコール実行中フラグが“０”にリセットされていると確認できた場合には何もしないが、“１”にセットされていると確認できた場合には、管理装置１０２への黒トナーサプライコールの実行中に本体主電源がＯＦＦ／ＯＮし、そのトナーサプライコールが成功していないため、上述と同様のリトライ制御を行う。
そして、このリトライ制御を行っても、管理装置１０２への黒トナーサプライコールが３回失敗した場合には、リトライを停止し、ＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグの状態をチェックし、そのチェック結果に応じて上述と同様の制御を行う。

一方、画像形成装置１００のプロッタエンジン内で赤トナーボトルのトナーニアエンド（赤トナーニアエンド）が発生した場合（赤トナーサプライである赤トナーボトル内のトナー量が所定量以下になった場合）、対応する事象検出部が赤トナーニアエンドを検出し、赤トナーニアエンドが発生した旨をコントローラボード２００のＳＣＳ３０６へ通知する。
ＳＣＳ３０６は、プロッタエンジンから赤トナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内で赤トナーニアエンドが発生したと判定する（つまりトナーニアエンドが発生したと判定すると共にそのトナーニアエンドの種類を判別する）。
以後、画像形成装置１００，仲介装置１０１，および管理装置１０２は、黒トナーニアエンドが発生した場合と略同様の処理を行うため、その説明を省略する。

図２２〜図２５は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６によるトナーニアエンド発生時の処理の他の概略例を示すフローチャートである。
画像形成装置１００のＳＣＳ３０６は、プロッタエンジンから黒又は赤トナーニアエンドが発生した旨の通知を受けると、トナーニアエンドが発生したと判定して図２２〜図２５の処理ルーチンを開始し、まずステップＳ３１でそのトナーニアエンドの種類を判別する。

そして、発生したトナーニアエンドが黒トナーニアエンドであると確認できた場合には、ステップＳ３２でＮＶ−ＲＡＭ２０２の黒トナーサプライコール済みフラグの状態をチェックし、その黒トナーサプライコール済みフラグが“０”にリセットされていると確認できた場合にステップＳ３３へ進み、画像形成装置１００の納入後、初めて黒トナーサプライコールを行うか否かを判断し、そうであれば（初めて黒トナーニアエンドが発生した場合には）そのままステップＳ３５へ進むが、初めて黒トナーサプライコールを行うのでなければステップＳ３４でＮＶ−ＲＡＭ２０２内の黒トナーコール後通紙枚数カウンタの値が「１０００」に達したか否かを判断し、「１０００」に達していればステップＳ３５へ進み、コールＩＤを生成する。

次に、ステップＳ３６で生成したコールＩＤをＮＶ−ＲＡＭ２０２に保存し、ステップＳ３７でＮＶ−ＲＡＭ２０２内の黒トナーサプライコール実行中フラグを“１”にセットし、ステップＳ３８でＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグを“０”にリセットし、ステップＳ３９でＮＶ−ＲＡＭ２０２内のリトライ回数カウンタに「３」をセットした後、ステップＳ４０でトナーサプライコール要求に画像形成装置１００の機番情報，ＮＶ−ＲＡＭ２０２に保存したコールＩＤ，および判別したトナーニアエンド（又はそれに対応するトナーサプライコール）の種類を付加して、黒トナーサプライコール要求とし、それをＮＲＳ３０５へ通知する。
その後、ステップＳ１０でＮＲＳ３０５からの通知の有無をチェックし、ＮＲＳ３０５からコールＯＫの通知を受けた場合には、管理装置１０２への黒トナーサプライコールが成功したと判断してステップＳ４２へ移行し、後述する処理を行う。

ＮＲＳ３０５からコールＮＧの通知を受けた場合には、管理装置１０２への黒トナーサプライコールが失敗したと判断してステップＳ４６へ移行し、ＮＶ−ＲＡＭ２０２内のリトライ回数カウンタをデクリメント（−１）した後、ステップＳ４７でそのリトライ回数カウンタの値をチェックし、その値が「０」になっていない場合（同一の黒トナーサプライコールの回数が３回に達していない場合）にステップＳ４０へ戻り、再び初回コール時と同一の黒トナーサプライコール要求をＮＲＳ３０５へ通知し（トナーサプライコール要求に画像形成装置１００の機番情報，ＮＶ−ＲＡＭ２０２に保存しておいた初回コール時と同一のコールＩＤ，判別したトナーニアエンドの種類を付加して黒トナーサプライコール要求とする）、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「０」になったら、次の処理を行う。

すなわち、図２４のステップＳ４８でＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグの状態をチェックし、その黒トナーメール送信済みフラグが“１”にセットされていると確認できた場合にはそのままステップＳ５１へ移行するが、“０”にリセットされていると確認できた場合にはステップＳ４９で管理装置１０２への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をＤＣＳ３１６へ通知する。このとき、その電子メール送信要求に、画像形成装置１００の機番情報，初回コール時と同一のコールＩＤ，判別したトナーニアエンド（又はそれに対応するトナーサプライコール）の種類を付加する。そして、その電子メール送信要求をＤＣＳ３１６へ通知した後、ステップＳ５０でＮＶ−ＲＡＭ２０２内の黒トナーメール送信済みフラグを“１”にセットした後、ステップＳ２０で２４時間タイマを起動させ、その２４時間タイマによる計測時間が２４時間経過するのを待って、図２２のステップＳ３９へ戻り、上述と同様の処理を繰り返す。

リトライ回数カウンタの値が「０」になる前に、ステップＳ４１で管理装置１０２への黒トナーサプライコールが成功したと判断した場合には、ステップＳ４２でＮＶ−ＲＡＭ２０２内の黒トナーサプライコール済みフラグを“１”にセットし、ステップＳ４３でＮＶ−ＲＡＭ２０２内の黒トナーコール後通紙枚数カウンタの値を、ステップＳ４４でリトライ回数カウンタの値をそれぞれ「０」にリセットした後、ステップＳ４５でＮＶ−ＲＡＭ２０２内の黒トナーサプライコール実行中フラグを“０”にリセットし、図２２〜図２５の処理を終了する。

一方、発生したトナーニアエンドが赤トナーニアエンドであると確認できた場合には、ステップＳ５２でＮＶ−ＲＡＭ２０２の赤トナーサプライコール済みフラグの状態をチェックし、その赤トナーサプライコール済みフラグが“０”にリセットされていると確認できた場合にステップＳ５３へ進み、画像形成装置１００の納入後、初めて赤トナーサプライコールを行うか否かを判断し、そうであれば（初めて赤トナーニアエンドが発生した場合には）そのままステップＳ５５へ進むが、初めて赤トナーサプライコールを行うのでなければステップＳ５４でＮＶ−ＲＡＭ２０２内の赤トナーコール後通紙枚数カウンタの値が「１０００」に達したか否かを判断し、「１０００」に達していればステップＳ５５へ進み、コールＩＤを生成する。
以後、ステップ５６〜Ｓ７１で、前述したステップ３６〜Ｓ５１と略同様の処理を行う（但しフラグやカウンタが異なる）ため、その説明を省略する。

図２６は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による転写紙正常排紙時の処理の概略例を示すフローチャートである。
ＳＣＳ３０６は、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、図２６の処理ルーチンを開始し、転写紙への画像形成（プリント）に赤トナーを使用した場合には赤トナーコール後通紙枚数カウンタを、転写紙への画像形成に黒トナーを使用した場合には黒トナーコール後通紙枚数カウンタをそれぞれインクリメント（＋１）する。

図２７は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による黒トナーフル時の処理の概略例を示すフローチャートである。
ＳＣＳ３０６は、トナーボトルの交換により黒トナーフルが発生し、その黒トナーフルが対応する事象検出部によって検出されて、黒トナーフルが発生した旨の通知を受けた場合に、ＮＶ−ＲＡＭ２０２内の黒トナーサプライコール済みフラグを“０”にリセットする。
図２８は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による赤トナーフル時の処理の概略例を示すフローチャートである。
ＳＣＳ３０６は、トナーボトルの交換により赤トナーフルが発生し、その赤トナーフルが対応する事象検出部によって検出されて、赤トナーフルが発生した旨の通知を受けた場合に、ＮＶ−ＲＡＭ２０２内の赤トナーサプライコール済みフラグを“０”にリセットする。

図２９は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による主電源ＯＮ時の他の処理例の一部を示すフローチャートである。
画像形成装置１００のＳＣＳ３０６は、主電源ＯＮ時にＮＶ−ＲＡＭ２０２内の黒トナーサプライコール実行中フラグの状態をチェックし、その黒トナーサプライコール実行中フラグが“１”にセットされていると確認できた場合にのみ、図２２のステップＳ３９以降の処理と同様の処理を行う。
図３０は、画像形成装置１００のコントローラボード２００のＳＣＳ３０６による主電源ＯＮ時の更に他の処理例の一部を示すフローチャートである。
画像形成装置１００のＳＣＳ３０６は、主電源ＯＮ時にＮＶ−ＲＡＭ２０２内の赤トナーサプライコール実行中フラグの状態をチェックし、その赤トナーサプライコール実行中フラグが“１”にセットされていると確認できた場合にのみ、図２３のステップＳ５９以降の処理と同様の処理を行う。

第２実施例によれば、以下の（１）〜（１０）にそれぞれ示す作用効果を得ることができる。
（１）画像形成装置１００（又は１１０）が、自己でのトナーニアエンド（異常事前事象）の発生によってそのトナーニアエンドを検出した場合に、その種類を判別し、そのトナーニアエンドの発生（トナーボトルの発注）を知らせるトナーサプライコール情報（事前事象情報）にそのトナーニアエンドの種類を示す情報を付加して管理装置１０２へ送信（通報）するが、その際に対応するトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“１”にセットする（事象情報送信中状態に設定する）ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信の実行中に自己の主電源がＯＦＦになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びＯＮになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。

（２）画像形成装置１００が、いずれかのトナーサプライコール情報を管理装置１０２へ送信する際に、その送信を識別するコールＩＤを生成し、それをそのトナーサプライコール情報に付加することにより、管理装置１０２側で画像形成装置１００から重複送信（例えば２重送信）された同一のトナーサプライコール情報をトナーの種類別に容易に把握できるため、黒トナーボトル又は赤トナーボトルの重複発注を防止することもできる。
（３）画像形成装置１００が、管理装置１０２へのいずれかのトナーサプライコール情報の送信結果として、管理装置１０２からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、対応するサプライコール実行中フラグを“０”にリセットする（事象情報送信中状態を解除する）ことにより、以後そのＳＣコール済みフラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信が完了したことを確認することができる。

（４）画像形成装置１００が、管理装置１０２へのいずれかのトナーサプライコール情報の送信結果として、管理装置１０２からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、そのトナーサプライコール情報の送信が失敗したと判断し、その場合にそのトナーサプライコール情報と同一のトナーサプライコール情報の送信回数が予め設定された所定回数に達していない場合には、そのトナーサプライコール情報を再び管理装置１０２へ送信させ、そのトナーサプライコール情報の送信回数が上記所定回数に達した場合に、そのトナーサプライコール情報の再送信を停止する再送信（リトライ）制御を行うことにより、いずれかのトナーサプライコール情報の送信の実行中に通信上のトラブルが発生した場合でも、そのトナーサプライコール情報の送信を完了させることが可能になる。

（５）画像形成装置１００が、再送信制御によって再送信する同一のトナーサプライコール情報に、同一のコールＩＤ（そのサプライコール情報の初回送信時に生成したコールＩＤ）を繰り返し付加することにより、同一のトナーサプライコール情報を送信する毎に異なるコールＩＤを生成する処理を行わなくて済むため、その分だけ処理効率が向上する。
（６）画像形成装置１００が、再送信制御によっていずれかのトナーサプライコール情報の再送信を停止した後、管理装置１０２へのそのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する（操作パネル２０５上への表示や用紙への画像形成によって報知してもよい）ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、そのトナーサプライコール情報（黒トナーボトル又は赤トナーボトルの発注）の内容を電話によってセンタオペレータに伝えることができる。つまり、いずれかのトナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。

（７）画像形成装置１００が、管理装置１０２へのいずれかのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知した後、その旨を示すいずれかのメール送信済みフラグを“１”にセットし（報知済み状態に設定し）、その報知を禁止することにより、その報知の重複を回避でき、その分だけ処理効率が向上する。
（８）画像形成装置１００が、メール送信済みフラグを“１”にセットした後、新たに前回と同じトナーニアエンドを検出した場合には、対応するメール送信済みフラグを“０”にリセットし（報知済み状態を解除し）、上記報知の禁止を解除することにより、再び管理装置１０２へのいずれかのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、そのトナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。

（９）画像形成装置１００が、２４Ｈタイマ（２４時間が予め設定されている）に時間計測を開始させ、２４Ｈタイマによる計測時間が２４時間（予め設定された所定時間）を経過した場合に、上述と同様の再送信制御を再度行うことにより、いずれかのトナーサプライコール情報をセンタオペレータにより一層確実に伝えることができる。なお、２４Ｈタイマ以外のタイマ（２４時間以外の所定時間が予め設定されている）を利用することもできる。

（１０）画像形成装置１００が、主電源ＯＮ（電源投入）時に対応するサプライコール実行中フラグの状態（セットの有無）を調べ、そのサプライコール実行中フラグが“１”にセットされていると確認できた場合に、管理装置１０２への対応するトナーサプライコール情報の送信が成功していないと判断し、その場合にも上述と同様の再送信制御を行うことにより、管理装置１０２へのいずれかのトナーサプライコール情報の送信の実行中に主電源がＯＦＦになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びＯＮになった時に、その実行中だったトナーサプライコール情報の送信を自動的に再開することができる。よって、トナーサプライコール情報の内容をトナーの種類別に最速で確実にセンタオペレータに伝えることができる。

なお、第２実施例では、画像形成装置が、プロッタエンジンに黒トナーボトルと赤トナーボトルの２色のトナーボトルを備え、そのいずれかでのトナーニアエンド（異常事前事象）を検出した場合に、そのトナーニアエンドの発生（又はそれに対応するトナーボトルの発注）を知らせるトナーサプライコール情報（異常事前事象情報）を管理装置１０２へ送信するようにしたが、Ｃ（シアン）トナーボトル，Ｍ（マゼンタ）トナーボトル，Ｙ（イエロー）トナーボトル，Ｋ（ブラック）トナーボトルの４色（フルカラー）のトナーボトルあるいは他の複数色のトナーボトルを備え、いずれかでのトナーニアエンドを検出した場合に、そのトナーニアエンドの発生（又はそれに対応するトナーボトルの発注）を知らせるトナーサプライコール情報を管理装置１０２へ送信するようにすることもできる。

また、上述した第１，第２実施例では、画像形成装置が、トナーニアエンドを検出した場合に、そのトナーニアエンドの発生を知らせるトナーサプライコール情報を管理装置１０２へ送信するようにしたが、トナーニアエンド以外の異常事前事象あるいはＳＣ（サービスマンコール）等の異常事象等の通報要因となる事象を検出し、その事象の発生を知らせる事象情報を管理装置１０２へ送信するようにすることも勿論できる。

例えば、トナーニアエンド以外の異常事前事象としては、ステープル針のニアエンド（針数が所定数以下になったことを示す）やスタンプインクのニアエンド（インク量が所定量以下になったことを示す）があり、ステープル針のニアエンドを検出した場合にはそのニアエンド（又はそれに対応するステープル針の発注）を、スタンプインクのニアエンドを検出した場合にはそのニアエンドの発生（又はそれに対応するスタンプインクの発注）をそれぞれ知らせる情報を管理装置１０２へ送信する。ステープル針やスタンプインクの種類が複数種類ある場合には、いずれかのステープル針のニアエンドを検出した場合にはそのニアエンド（又はそれに対応するステープル針の発注）を、いずれかのスタンプインクのニアエンドを検出した場合にはそのニアエンドの発生（又はそれに対応するスタンプインクの発注）をそれぞれ知らせる情報を管理装置１０２へ送信する。

また、通信装置（電子装置）の例として通信機能（仲介機能）を持つ画像形成装置１１０および通信機能を果たす仲介装置１０１を接続した画像形成装置１００について説明したが、この発明はこれらに限られるものではなく、通信機能を持つか、通信機能を果たす仲介装置を接続したネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置に適用可能である。また、これらの装置を被管理装置とした場合にも、遠隔管理システムを上述した場合と同様に動作させることができる。さらに、通信装置の遠隔管理システムについても、通信装置，遠隔管理仲介装置，管理装置の構成及びこれらの接続形式は、以上の実施例に限られるものではない。

例えば、図１に示した遠隔管理システムにおいて、上述した各種電子装置を被管理装置とし、図３３に示すような遠隔管理システムを構成することが考えられる。この図３３においては、仲介装置１０１を別途設ける被管理装置の例として、テレビ受像機１２ａや冷蔵庫１２ｂのようなネットワーク家電、医療機器１２ｃ，自動販売機１２ｄ，計量システム１２ｅ，空調システム１２ｆを挙げている。そして、仲介装置１０１の機能を併せ持つ被管理装置の例として、自動車１３ａや航空機１３ｂを挙げている。また、自動車１３ａや航空機１３ｂのように広範囲を移動する装置においては、ファイアウォール（ＦＷ）１０４の機能も併せ持つようにすることが好ましい。

また、この発明によるプログラムは、外部装置と通信を行う通信手段を備えた上述の画像形成装置等の通信装置を制御するコンピュータに、この発明による各機能（事象情報送信情報生成手段，事象情報送信手段，事象情報送信中状態設定手段，送信結果判断手段，事象情報送信中状態解除手段，送信失敗報知手段，報知済み状態設定手段，報知禁止手段，報知済み状態解除手段，報知禁止解除手段，時間計測手段，事象種判別手段としての機能）を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。

このようなプログラムは、はじめからコンピュータに備えるＲＯＭあるいはＨＤＤ等の記憶手段に格納しておいてもよいが、記録媒体であるＣＤ−ＲＯＭあるいはフレキシブルディスク，ＳＲＡＭ，ＥＥＰＲＯＭ，メモリカード等の不揮発性記録媒体（メモリ）に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてＣＰＵに実行させるか、ＣＰＵにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。

この発明を、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種通信装置（被管理装置）、その通信装置とそれを管理する管理装置とからなる遠隔管理システムに適用可能である。

この発明による通信装置の遠隔管理システムの構成例を示す概念図である。その遠隔管理システムにおけるデータ送受モデルを示す概念図である。この発明による通信装置の管理システムである画像形成装置遠隔管理システムの構成例を示す概念図である。図３の画像形成装置の物理的構成例を示すブロック図である。その画像形成装置のソフトウェア構成例を示すブロック図である。

その画像形成装置におけるＥＮＧＲＤＹ信号とＰＷＲＣＴＬ信号について説明するための図である。図５のＮＲＳ３１６の構成例を示す機能ブロック図である。図３の管理装置１０２の物理的構成例を示すブロック図である。図３に示した画像形成装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例を示す図である。図３の画像形成装置から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。

異常事象の種類を判定するための基準となる情報のテーブルの一例を示す説明図である。図３に示した画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第１例を示す図である。図３に示した画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第２例を示す図である。その続きを示す図である。図３に示した画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第３例を示す図である。

図５のＤＣＳ３１６によって送信する電子メールの内容の一例を示す説明図である。図５のＳＣＳ３０６によるトナーニアエンド発生時の処理の概略例を示すフロー図である。その続きの処理を示すフロー図である。図５のＳＣＳ３０６による主電源ＯＮ時の処理例の一部を示すフロー図である。図３に示した画像形成装置遠隔管理システムにおける画像形成装置１００でのトナーニアエンド発生時の通信シーケンスの第３例を示す図である。

図４のＮＶ−ＲＡＭ２０２内の２種類のサプライコール実行中フラグの状態を示す説明図である。図５のＳＣＳ３０６によるトナーニアエンド発生時の処理の他の概略例を示すフロー図である。その残りの処理の一部を示すフロー図である。その残りの処理の他の一部を示すフロー図である。その残りの処理の更に他の一部を示すフロー図である。

図５のＳＣＳ３０６による転写紙正常排紙時の処理の概略例を示すフロー図である。同じく黒トナーフル時の処理の概略例を示すフロー図である。同じく赤トナーフル時の処理の概略例を示すフロー図である。同じく主電源ＯＮ時の他の処理例の一部を示すフロー図である。同じく主電源ＯＮ時の更に他の処理例の一部を示すフローチャートである。

ＨＴＴＰメッセージ内のトナーサプライコール用のＳＯＡＰメッセージのフォーマット例を示す説明図である。その主要部分の構成を示す説明図である。図１に示した遠隔管理システムの別の構成例を示す図である。従来の画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象発生時の通信シーケンスの一例を示す図である。同じく異常事前事象発生時の通信シーケンスの他の例を示す図である。従来の画像形成装置のコントローラ内のＣＰＵによるトナーニアエンド発生時の処理（制御）の概略例を示すフロー図である。

同じく転写紙正常排紙時の処理の概略例を示すフロー図である。同じくトナーフル時の処理の概略例を示すフロー図である。

符号の説明

１０：被管理装置１１：仲介機能付被管理装置１００：画像形成装置１０１：仲介装置１０２：管理装置１０３：インタネット１０４：ファイアウォール１１０：仲介機能付画像形成装置２００：コントローラボード２０１：ＨＤＤ２０２：ＮＶ−ＲＡＭ２０３：ＰＩボード２０４：ＰＨＹ２０５：操作パネル２０６：プロッタ／スキャナエンジンボード２０７：電源ユニット２１２：ＰＣＩ−ＢＵＳ３００：ＯＣＳ３０１：ＥＣＳ３０２：ＭＣＳ３０３：ＮＣＳ３０４：ＦＣＳ３０５：ＮＲＳ３０６：ＳＣＳ３０７：ＳＲＭ３０８：ＩＭＨ３０９：コピーアプリ３１０：ファクスアプリ３１１：プリンタアプリ３１２：スキャナアプリ３１３：ネットファイルアプリ３１４：ウェブアプリ３１５：ＣＳＳ３１６：ＤＣＳ３１７：ＵＣＳ３２０：汎用ＯＳ６０１：モデム６０２：通信端末６０３：プロキシサーバ６０４：操作者端末６０５：データベース６０６：制御装置

Claims

外部装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報を前記通信手段によって前記外部装置へ送信させる事象情報送信手段とを有する通信装置であって、
前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成手段を設け、
前記事象情報送信手段が、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して前記通信手段によって前記外部装置へ送信させる手段であることを特徴とする通信装置。
請求項１記載の通信装置において、
前記事象情報送信手段による前記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記事象情報送信手段は、前記送信結果判断手段によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする通信装置。
請求項２記載の通信装置において、
前記事象情報送信手段による前記再送信が停止した後、前記外部装置への事象情報の送信が失敗した旨を示す情報に、前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする通信装置。
請求項３記載の通信装置において、
前記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、
該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたことを特徴とする通信装置。
請求項４記載の通信装置において、
前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする通信装置。
請求項２乃至５のいずれか一項に記載の通信装置において、
時間計測を行なう時間計測手段を設け、
前記事象情報送信手段は、前記再送信を停止した後、前記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、前記再送信制御を再度行う手段を有することを特徴とする通信装置。
請求項１記載の通信装置において、
前記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、
前記事象情報送信手段は、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象種判別手段によって判別された事象の種類を示す情報および前記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して前記通信手段によって前記外部装置へ送信させる手段であることを特徴とする通信装置。
請求項７記載の通信装置において、
前記事象情報送信手段による前記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記事象情報送信手段は、前記送信結果判断手段によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする通信装置。
請求項８記載の通信装置において、
前記事象情報送信手段による前記再送信が停止した後、前記外部装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする通信装置。
請求項９記載の通信装置において、
前記送信失敗報知手段によって前記外部装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、
該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたことを特徴とする通信装置。
請求項１０記載の通信装置において、
前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする通信装置。
請求項１乃至１１のいずれか一項に記載の通信装置において、
前記事象情報送信手段は、前記通信手段によって前記外部装置へ送信すべき情報を構造化言語形式に変換する手段を有することを特徴とする通信装置。
管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、
前記複数の通信装置にそれぞれ、前記管理装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に自己の識別情報を付加して前記通信手段によって前記管理装置へ送信させる事象情報送信手段と、該手段によって前記管理装置へ事象情報が送信される際に、該事象情報の送信中を示す事象情報送信中状態に設定する事象情報送信中状態設定手段とを設け、
前記管理装置に、前記複数の通信装置と通信する通信手段と、該手段によっていずれかの通信装置から事象情報を受信し、該受信が正常に終了した場合に、その旨の送信結果を該事象情報に付加された識別情報に基づいて該事象情報を送信した通信装置へ前記通信手段によって送信させる送信結果送信手段とを設けたことを特徴とする遠隔管理システム。
請求項１３記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記各通信装置の事象情報送信手段は、前記送信結果判断手段によって前記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同じ事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記管理装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする遠隔管理システム。
請求項１４記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記再送信が停止した後、前記管理装置への事象情報の送信が失敗した旨を示す情報に、前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする遠隔管理システム。
請求項１５記載の遠隔管理システムにおいて、
前記の通信装置にそれぞれ、前記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたことを特徴とする遠隔管理システム。
請求項１６記載の遠隔管理システムにおいて、
前記の通信装置にそれぞれ、前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする遠隔管理システム。
請求項１４乃至１７のいずれか一項に記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、時間計測を行なう時間計測手段を設け、
前記各通信装置の事象情報送信手段は、前記再送信を停止した後、前記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、前記再送信制御を再度行う手段を有することを特徴とする遠隔管理システム。
請求項１３記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、
前記各通信装置の事象情報送信手段は、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象種判別手段によって判別された事象の種類を示す情報，前記事象情報送信情報生成手段によって生成された事象情報送信情報，および自己の識別情報を付加して前記通信手段によって前記管理装置へ送信させる手段であることを特徴とする遠隔管理システム。
請求項１９記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記各通信装置の事象情報送信手段は、前記送信結果判断手段によって前記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記管理装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする遠隔管理システム。
請求項２０記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記再送信が停止した後、前記管理装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする遠隔管理システム。
請求項２１記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記送信失敗報知手段によって前記管理装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたことを特徴とする遠隔管理システム。
請求項２２記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする遠隔管理システム。
異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信する通信装置における送信要因発生時の制御方法であって、
通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成し、該事象情報に該事象情報送信情報を付加して前記外部装置へ送信することを特徴とする送信要因発生時の制御方法。
請求項２４記載の送信要因発生時の制御方法において、
前記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断し、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には該事象情報を再び前記外部装置へ送信し、該事象情報の送信回数が前記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行い、この再送信制御時に前記再送信すべき同一の事象情報には前記生成した同一の事象情報送信情報を繰り返し付加することを特徴とする送信要因発生時の制御方法。
異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信するようにした通信装置を制御するコンピュータに、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成機能と、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報に前記事象情報送信情報生成機能によって生成された事象情報送信情報を付加して前記外部装置へ送信する事象情報送信機能とを実現させるためのプログラム。
請求項２６記載のプログラムにおいて、
前記コンピュータに、前記事象情報送信機能による前記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する機能と、該機能によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信し、該事象情報の送信回数が前記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行う機能と、該機能によって再送信される同一の事象情報には前記事象情報送信情報生成機能によって生成された同一の事象情報送信情報を繰り返し付加する機能とを実現させるためのプログラムも含むプログラム。