JP2004234650A - 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム - Google Patents
通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム Download PDFInfo
- Publication number
- JP2004234650A JP2004234650A JP2004005962A JP2004005962A JP2004234650A JP 2004234650 A JP2004234650 A JP 2004234650A JP 2004005962 A JP2004005962 A JP 2004005962A JP 2004005962 A JP2004005962 A JP 2004005962A JP 2004234650 A JP2004234650 A JP 2004234650A
- Authority
- JP
- Japan
- Prior art keywords
- event
- event information
- transmission
- information
- call
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Accessory Devices And Overall Control Thereof (AREA)
Abstract
【目的】 画像形成装置等の通信装置が、異常事前事象等の送信要因となる事象が発生してその事象を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、外部装置側でその事象情報を容易に把握できるようにする。
【構成】
【解決手段】 画像形成装置100は、トナーニアエンド(異常事前事象)の発生によりそのトナーニアエンドを検出したとき、そのトナーニアエンド(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)を管理装置102へ送信するが、その際に、その送信を識別するコールIDを生成し、それをそのトナーサプライコール情報に付加する。
【選択図】 図3
【構成】
【解決手段】 画像形成装置100は、トナーニアエンド(異常事前事象)の発生によりそのトナーニアエンドを検出したとき、そのトナーニアエンド(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)を管理装置102へ送信するが、その際に、その送信を識別するコールIDを生成し、それをそのトナーサプライコール情報に付加する。
【選択図】 図3
Description
この発明は、外部装置と通信する機能を備えた通信装置と、この通信装置とこれをネットワークを介して遠隔管理する管理装置とによって構成された遠隔管理システム、および上記通信装置における送信要因発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能(この発明に係わる機能)を実現させるためのプログラムに関する。
従来から、通信機能を備えたプリンタ,ファクシミリ(FAX)装置,デジタル複写機,スキャナ装置,デジタル複合機等の画像処理装置を始め、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム等に通信機能を持たせた電子装置(通信装置)を被管理装置とし、サービスセンタ(管理センタ)の管理装置が公衆回線やインタネット等のネットワーク経由でこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。
あるいは、被管理装置が通信機能を持たない場合、その被管理装置にネットワーク経由で通信手段(通信機能)を有する仲介装置を接続し、管理装置がネットワークおよび仲介装置経由で被管理装置を遠隔管理する遠隔管理システムも提案されている。
ここで、例えば被管理装置を画像形成装置とし、その画像形成装置について簡単に説明する。
画像形成装置としては、既知の感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル(異常)が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
ここで、例えば被管理装置を画像形成装置とし、その画像形成装置について簡単に説明する。
画像形成装置としては、既知の感光体静電プロセスを用いて普通紙に画像形成するものが一般的であるが、このような感光体静電プロセスを行う機構からは、トラブル(異常)が発生する割合も高く、更に性能維持のための定期的なオーバホールの必要性から、保守管理のサービス体制を採っている。
この保守管理を充実させる目的で、画像形成装置の遠隔管理システムとして、画像形成装置の内部又は外部に通信手段を設け、画像形成装置とサービスセンタに設置された管理装置とを公衆回線(電話回線)を介して接続し、画像形成装置の異常事象(自己診断異常)又は異常事前事象(センサの規格レベルへの到達など、予防保全を必要とする事前警告)等の通報要因となる事象が発生した場合に、その事象をセンサ等からなる事象検出手段によって検出し、その事象の発生を知らせる事象情報等を通信手段によって管理装置(外部装置)へ送信させるようにしたものが既に開発され(例えば特許文献1参照)、市販されている。管理装置への事象情報の送信としては、自己診断異常の発生による自己診断異常情報の通報であるサービスマンコールや、事前警告の発生による事前警告情報の通報であるアラームコール(例えばサプライコール)がある。
特開2002−6693号公報
このような画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象(事前警告)発生時の制御について、図34〜図38を参照して詳細に説明する。
図34,図35は、従来の画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象発生時の通信シーケンスの異なる例を示す図である。
画像形成装置は、プロッタエンジン内にセンサ等からなる事象検出部(事象検出手段)を備えており、その事象検出部が、プロッタエンジンの状態を監視し、例えば異常事前事象としてトナーニアエンドが発生した場合(トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合)、そのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラ内のCPUへ通知する。
図34,図35は、従来の画像形成装置遠隔管理システムにおける画像形成装置での異常事前事象発生時の通信シーケンスの異なる例を示す図である。
画像形成装置は、プロッタエンジン内にセンサ等からなる事象検出部(事象検出手段)を備えており、その事象検出部が、プロッタエンジンの状態を監視し、例えば異常事前事象としてトナーニアエンドが発生した場合(トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合)、そのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラ内のCPUへ通知する。
そのコントローラ内のCPUは、プロッタエンジンからトナーニアエンドが発生した旨が通知されると、そのプロッタエンジン内でトナーニアエンドが発生したと判定して、NV−RAM(不揮発性メモリ)内のトナーサプライコール済みフラグ(コール済みフラグ)およびトナーサプライコール後通紙枚数カウンタ(コール後通紙枚数カウンタ)の値をそれぞれチェックし(調べ)、トナーサプライコール済みフラグが“0”にリセットされ、且つコール後通紙枚数カウンタの値が「1000」以上になっている(但し機器が一度もトナーサプライコールを行っていない場合には本条件を無視する)場合には、トナーサプライコール発行条件を満足しているものと判定する。
そして、NV−RAM内のトナーサプライコールリトライ回数カウンタ(リトライ回数カウンタ)に「3」をセットした後、トナーサプライコール(トナーニアエンドの発生つまりトナーボトルの発注を知らせるトナーサプライコール情報の自動通報)用のメッセージをラインアダプタ(仲介装置)へ通知する。
また、操作部上の文字表示器に「トナーサプライコール中」のメッセージを表示する。
また、操作部上の文字表示器に「トナーサプライコール中」のメッセージを表示する。
ラインアダプタは、コントローラからトナーサプライコール用のメッセージを受信すると、公衆回線経由でサービスセンタの管理装置に対してトナーサプライコールを行う。つまり、トナーボトルの発注を知らせるトナーサプライコール情報(事前事象情報)を公衆回線経由でサービスセンタの管理装置へ自動通報する。
サービスセンタの管理装置は、機器利用者(この例では画像形成装置を利用しているユーザ)側に設置されているラインアダプタから通報されたトナーサプライコール情報を受信し、その受信が正常に終了すると、その旨(トナーサプライコールに対する処理が成功した旨)のコール結果(OK)を公衆回線経由で通報元のラインアダプタへ送信する。
サービスセンタの管理装置は、機器利用者(この例では画像形成装置を利用しているユーザ)側に設置されているラインアダプタから通報されたトナーサプライコール情報を受信し、その受信が正常に終了すると、その旨(トナーサプライコールに対する処理が成功した旨)のコール結果(OK)を公衆回線経由で通報元のラインアダプタへ送信する。
また、受信したトナーサプライコール情報をキュー(例えばハードディスク装置内のデータベース)に格納し、管理装置のオペレータ(以下「センタオペレータ」という)によって対応する処理、つまりトナーボトルの受注作業が行われるまでキューイング(保持)する。
さらに、受信したトナーサプライコール情報を表示部に表示してセンタオペレータに知らせる。
センタオペレータは、管理装置の表示部の表示内容を見て通報元のラインアダプタに接続されている画像形成装置のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元のラインアダプタの設置場所にトナーボトルを届けさせる。
さらに、受信したトナーサプライコール情報を表示部に表示してセンタオペレータに知らせる。
センタオペレータは、管理装置の表示部の表示内容を見て通報元のラインアダプタに接続されている画像形成装置のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元のラインアダプタの設置場所にトナーボトルを届けさせる。
通報元のラインアダプタは、サービスセンタの管理装置へのトナーサプライコールの結果(トナーサプライコール情報の送信結果)として、その管理装置からコールOK(トナーサプライコール情報の受信が正常に終了した旨の送信結果)を受信すると、そのコールOKを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラ内のCPUは、ラインアダプタからコールOKの通知を受けると、管理装置へのトナーサプライコールが成功したと判断し、操作部上の文字表示器に「トナーサプライコール成功」のメッセージを表示する。
また、NV−RAM202内のトナーサプライコールの成功を示すトナーサプライコール済みフラグを“1”にセットすると共に、NV−RAM内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし、「0」からカウント動作を行えるようにする。
画像形成装置のコントローラ内のCPUは、ラインアダプタからコールOKの通知を受けると、管理装置へのトナーサプライコールが成功したと判断し、操作部上の文字表示器に「トナーサプライコール成功」のメッセージを表示する。
また、NV−RAM202内のトナーサプライコールの成功を示すトナーサプライコール済みフラグを“1”にセットすると共に、NV−RAM内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし、「0」からカウント動作を行えるようにする。
画像形成装置のプロッタエンジン内のトナーボトルが交換され、トナーフルが発生した場合(トナーボトル内のトナー量が満杯になった場合)、事象検出部が、そのトナーフルを検出し、トナーフルが発生した旨をコントローラへ通知する。
そのコントローラ内のCPUは、プロッタエンジンからトナーフルが発生した旨の通知を受けると、NV−RAM内のコール済みフラグを“0”にリセットし、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「1000」にならないと、サプライコールを行うことはない。
そのコントローラ内のCPUは、プロッタエンジンからトナーフルが発生した旨の通知を受けると、NV−RAM内のコール済みフラグを“0”にリセットし、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「1000」にならないと、サプライコールを行うことはない。
一方、通報元のラインアダプタは、サービスセンタの管理装置へのトナーサプライコールの結果(トナーサプライコール情報の送信結果)として、その管理装置からコールOK(トナーサプライコール情報の受信が正常に終了した旨の送信結果)を予め設定された所定時間が経過しても受信できなかった場合、コールNGを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラのCPUは、ラインアダプタからコールNGを受けると、管理装置へのトナーサプライコールが失敗したと判断し、操作部上の文字表示器に「トナーサプライコール失敗」のメッセージを表示する。
画像形成装置のコントローラのCPUは、ラインアダプタからコールNGを受けると、管理装置へのトナーサプライコールが失敗したと判断し、操作部上の文字表示器に「トナーサプライコール失敗」のメッセージを表示する。
また、NV−RAM内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一のトナーサプライコール情報の通報回数が予め設定された所定回数である3回に達していない場合)に、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知する。なお、ここでの初回通報とは、同一のトナーサプライコール情報の1回目の通報のことをさす。
ラインアダプタは、コントローラから初回通報時と同一のトナーサプライコール用のメッセージを受信すると、公衆回線経由でサービスセンタの管理装置に対して再びトナーサプライコールを行わせる。つまり、初回通報時と同一のトナーサプライコール情報を再び公衆回線経由でサービスセンタの管理装置へ自動通報させる。
ラインアダプタは、コントローラから初回通報時と同一のトナーサプライコール用のメッセージを受信すると、公衆回線経由でサービスセンタの管理装置に対して再びトナーサプライコールを行わせる。つまり、初回通報時と同一のトナーサプライコール情報を再び公衆回線経由でサービスセンタの管理装置へ自動通報させる。
その後、サービスセンタの管理装置へのトナーサプライコールの結果として、その管理装置からコールOKを予め設定された所定時間が経過しても受信できなかった場合、再びコールNGを画像形成装置のコントローラへ通知する。
画像形成装置のコントローラ内のCPUは、ラインアダプタから再びコールNGを受けると、管理装置へのトナーサプライコールが失敗したと判断し、NV−RAM内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合に、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知し、以後上述と同様の制御を行う。
画像形成装置のコントローラ内のCPUは、ラインアダプタから再びコールNGを受けると、管理装置へのトナーサプライコールが失敗したと判断し、NV−RAM内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合に、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知し、以後上述と同様の制御を行う。
その後、ラインアダプタから再びコールNGを受けると、管理装置へのトナーサプライコールが失敗したと判断し、NV−RAM内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックすると、その値が「0」になっている(同一のトナーサプライコール情報の通報回数が3回に達した)ため、初回通報時と同一のトナーサプライコール用のメッセージのラインアダプタへの通知(リトライ)を中止(停止)する。
図36は、画像形成装置のコントローラ内のCPUによるトナーニアエンド発生時の処理(制御)の概略例を示すフローチャートである。
画像形成装置のコントローラのCPUは、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図36の処理を開始し、まずステップS101でNV−RAM内のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“0”にリセットされていることを確認できた場合にステップS102へ進み、画像形成装置納入後、初めてサプライコールを行うか否かを判断する。
画像形成装置のコントローラのCPUは、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図36の処理を開始し、まずステップS101でNV−RAM内のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“0”にリセットされていることを確認できた場合にステップS102へ進み、画像形成装置納入後、初めてサプライコールを行うか否かを判断する。
そして、画像形成装置納入後、初めてサプライコールを行うのであれば(トナーニアエンドが発生した場合には)そのままステップS104へ進むが、初めてサプライコールを行うのでなければステップS103でNV−RAM内のコール後通紙枚数カウンタの値(前回通報時の転写紙通紙枚数)が「1000」に達したか否かを判断し、「1000」に達していればステップS104へ進む。この判断は、ドアオープン等によるトナーニアエンドの誤検出に対応するものである。
ステップS104では、NV−RAM内のリトライ回数カウンタに「3」をセット(設定)する。
ステップS104では、NV−RAM内のリトライ回数カウンタに「3」をセット(設定)する。
そして、ステップS105でトナーサプライコール用のメッセージをラインアダプタへ通知し、公衆回線経由でサービスセンタの管理装置に対してトナーサプライコールを行わせる。
その後、ラインアダプタからの通知を待ち、ラインアダプタからコールOKの通知を受けた場合には、ステップS106で管理装置へのトナーサプライコールが成功したと判断してステップS107へ移行し、後述する処理を行う。
また、ラインアダプタからコールNGの通知を受けた場合には、ステップS106で管理装置へのトナーサプライコールが失敗したと判断してステップS110へ移行し、次の処理を行う。
その後、ラインアダプタからの通知を待ち、ラインアダプタからコールOKの通知を受けた場合には、ステップS106で管理装置へのトナーサプライコールが成功したと判断してステップS107へ移行し、後述する処理を行う。
また、ラインアダプタからコールNGの通知を受けた場合には、ステップS106で管理装置へのトナーサプライコールが失敗したと判断してステップS110へ移行し、次の処理を行う。
すなわち、ステップS110でNV−RAM内のリトライ回数カウンタをデクリメント(−1)した後、ステップS111でそのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一のトナーサプライコール情報の通報回数が3回に達していない場合)にステップS105へ戻り、再び初回通報時と同一のトナーサプライコール用のメッセージをラインアダプタへ通知し、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「0」になったら、図36の処理を終了する。
リトライ回数カウンタの値が「0」になる前に、ステップS106で管理装置へのトナーサプライコールが成功したと判断すると、ステップS107でNV−RAM内のトナーサプライコール済みフラグを“1”にセットした後、ステップS108でNV−RAM内のコール後通紙枚数カウンタの値を、ステップS109でリトライ回数カウンタの値をそれぞれ「0」にリセットし、図36の処理を終了する。
図37は、画像形成装置のコントローラ内のCPUによる転写紙正常排紙時の処理の概略例を示すフローチャートである。
画像形成装置のコントローラのCPUは、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、コール後通紙枚数カウンタをインクリメント(+1)する。
図38は、画像形成装置のコントローラ内のCPUによるトナーフル時の処理の概略例を示すフローチャートである。
画像形成装置のコントローラのCPUは、トナーボトルの交換によりトナーフルが発生し、そのトナーフルが事象検出部によって検出されると、NV−RAM内のトナーサプライコール済みフラグを“0”にリセットする。
画像形成装置のコントローラのCPUは、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、コール後通紙枚数カウンタをインクリメント(+1)する。
図38は、画像形成装置のコントローラ内のCPUによるトナーフル時の処理の概略例を示すフローチャートである。
画像形成装置のコントローラのCPUは、トナーボトルの交換によりトナーフルが発生し、そのトナーフルが事象検出部によって検出されると、NV−RAM内のトナーサプライコール済みフラグを“0”にリセットする。
しかしながら、このような画像形成装置遠隔管理システムでは、機器利用者側の画像形成装置が、仲介装置(ラインアダプタ)を用いて又は単独で(この場合仲介装置としての機能を有する)管理装置への異常事前事象情報又は異常事象情報等の事象情報の通報の実行中に、自己の主電源が機器利用者の操作等によってOFF/ONされた場合(一旦遮断されて再び投入された場合)、その実行中の通報が中断されるため、以後同じ事象が再び発生しない限りは、実行中だった通報を再開することができないという問題がある。例えば、上述したトナーサプライコールの実行中に、上記主電源が機器利用者の操作等によってOFF/ONされた場合、そのトナーサプライコールが中断されるため、トナーニアエンドが発生しない限りは、実行中だったトナーサプライコールを直ちに再開することができない。機器のトナー残量検知機構によっては、一度トナーニアエンドになった後、メインカバーの開閉や主電源のOFF/ONにより、トナーニアエンド状態が解除される場合がある。また、主電源OFF中にトナーボトルが交換される場合も考えられる。そのような場合、主電源のOFF/ONにより、トナーニアエンド状態が解除されてしまうため、トナーニアエンドが発生したという状態が継続しない場合がありうる。なお、機器利用者は、主電源のOFF/ONによって異常事象等の事象が解除される場合があることを知っているため、異常事象等の事象の検出によって操作部上に対応するエラーメッセージが表示されるような場合には、主電源をOFF/ONさせるための操作を行う場合が多い。
管理装置では、仲介装置又は画像形成装置からの事象情報の通報が中断された場合、その事象情報を正常に受信していない場合がある。例えば、サプライコールが中断された場合、サプライコール情報を正常に受信していない場合がある。その場合、サプライの発注が行われないことになる。
一方、仲介装置又は画像形成装置からの事象情報の通報が中断された場合でも、その事象情報を正常に受信している場合がある。例えば、サプライコールが中断された場合でも、サプライコール情報を正常に受信している場合がある。その場合、サプライの発注が行われることになる。
一方、仲介装置又は画像形成装置からの事象情報の通報が中断された場合でも、その事象情報を正常に受信している場合がある。例えば、サプライコールが中断された場合でも、サプライコール情報を正常に受信している場合がある。その場合、サプライの発注が行われることになる。
ところが、事象情報を正常に受信した後、画像形成装置側で同じ事象が再び発生し、その事象の発生を知らせる事象情報を受信すると、同じ事象情報を重複して受信することになる。例えば、同一のサプライコール情報を重複して受信することになり、同じサプライの2重発注が行われることになる。
この発明は、上記の問題点に鑑みてなされたものであり、画像形成装置等の通信装置が、異常事象又は異常事前事象等の送信要因(通報要因)となる事象が発生してその事象の発生を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、その外部装置側でその事象情報を容易に把握できるようにすることを目的とする。
この発明は、上記の問題点に鑑みてなされたものであり、画像形成装置等の通信装置が、異常事象又は異常事前事象等の送信要因(通報要因)となる事象が発生してその事象の発生を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、その外部装置側でその事象情報を容易に把握できるようにすることを目的とする。
この発明は、上記の目的を達成するため、通信装置と、その遠隔管理システム、および上記通信装置の送信要因発生時の制御方法、並びに上記通信装置を制御するコンピュータに必要な機能を実現させるためのプログラムを提供する。
請求項1の発明による通信装置は、外部装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報を上記通信手段によって上記外部装置へ送信させる事象情報送信手段とを有する通信装置であって、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成手段を設け、上記事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して上記通信手段によって上記外部装置へ送信させる手段としたものである。
請求項2の発明による通信装置は、請求項1の通信装置において、上記事象情報送信手段による上記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記事象情報送信手段に、上記送信結果判断手段によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。
請求項3の発明による通信装置は、請求項2の通信装置において、上記事象情報送信手段による上記再送信が停止した後、上記外部装置への事象情報の送信が失敗した旨を示す情報に、上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項4の発明による通信装置は、請求項3の通信装置において、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。
請求項4の発明による通信装置は、請求項3の通信装置において、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。
請求項5の発明による通信装置は、請求項4の通信装置において、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項6の発明による通信装置は、請求項2〜5のいずれかの通信装置において、時間計測を行なう時間計測手段を設け、上記事象情報送信手段に、上記再送信を停止した後、上記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、上記再送信制御を再度行う手段を備えたものである。
請求項6の発明による通信装置は、請求項2〜5のいずれかの通信装置において、時間計測を行なう時間計測手段を設け、上記事象情報送信手段に、上記再送信を停止した後、上記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、上記再送信制御を再度行う手段を備えたものである。
請求項7の発明による通信装置は、請求項1の通信装置において、上記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、上記事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象種判別手段によって判別された事象の種類を示す情報および上記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して上記通信手段によって上記外部装置へ送信させる手段としたものである。
請求項8の発明による通信装置は、請求項7の通信装置において、上記事象情報送信手段による上記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記事象情報送信手段に、上記送信結果判断手段によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。
請求項9の発明による通信装置は、請求項8の通信装置において、上記事象情報送信手段による上記再送信が停止した後、上記外部装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項10の発明による通信装置は、請求項9の通信装置において、上記送信失敗報知手段によって上記外部装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたものである。
請求項11の発明による通信装置は、請求項10の通信装置において、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項12の発明による通信装置は、請求項1〜11のいずれかの通信装置において、上記事象情報送信手段に、上記通信手段によって上記外部装置へ送信すべき情報を構造化言語形式に変換する手段を備えたものである。
請求項12の発明による通信装置は、請求項1〜11のいずれかの通信装置において、上記事象情報送信手段に、上記通信手段によって上記外部装置へ送信すべき情報を構造化言語形式に変換する手段を備えたものである。
請求項13の発明による遠隔管理システムは、管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、上記複数の通信装置にそれぞれ、上記管理装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に自己の識別情報を付加して上記通信手段によって上記管理装置へ送信させる事象情報送信手段と、該手段によって上記管理装置へ事象情報が送信される際に、該事象情報の送信中を示す事象情報送信中状態に設定する事象情報送信中状態設定手段とを設け、上記管理装置に、上記複数の通信装置と通信する通信手段と、該手段によっていずれかの通信装置から事象情報を受信し、該受信が正常に終了した場合に、その旨の送信結果を該事象情報に付加された識別情報に基づいて該事象情報を送信した通信装置へ上記通信手段によって送信させる送信結果送信手段とを設けたものである。
請求項14の発明による遠隔管理システムは、請求項13の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記各通信装置の事象情報送信手段に、上記送信結果判断手段によって上記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同じ事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記管理装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。
請求項15の発明による遠隔管理システムは、請求項14の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記再送信が停止した後、上記管理装置への事象情報の送信が失敗した旨を示す情報に、上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項16の発明による遠隔管理システムは、請求項15の遠隔管理システムにおいて、上記の通信装置にそれぞれ、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。
請求項16の発明による遠隔管理システムは、請求項15の遠隔管理システムにおいて、上記の通信装置にそれぞれ、上記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたものである。
請求項17の発明による遠隔管理システムは、請求項16の遠隔管理システムにおいて、上記の通信装置にそれぞれ、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項18の発明による遠隔管理システムは、請求項14〜17のいずれかの遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、時間計測を行なう時間計測手段を設け、上記各通信装置の事象情報送信手段に、上記再送信を停止した後、上記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、上記再送信制御を再度行う手段を備えたものである。
請求項19の発明による遠隔管理システムは、請求項13の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、上記各通信装置の事象情報送信手段を、上記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に上記事象種判別手段によって判別された事象の種類を示す情報,上記事象情報送信情報生成手段によって生成された事象情報送信情報,および自己の識別情報を付加して上記通信手段によって上記管理装置へ送信させる手段としたものである。
請求項20の発明による遠隔管理システムは、請求項19の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、上記各通信装置の事象情報送信手段に、上記送信結果判断手段によって上記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記管理装置へ送信させ、該事象情報の送信回数が上記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には上記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを備えたものである。
請求項21の発明による遠隔管理システムは、請求項20の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記事象情報送信手段による上記再送信が停止した後、上記管理装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および上記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたものである。
請求項22の発明による遠隔管理システムは、請求項21の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記送信失敗報知手段によって上記管理装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって上記報知済み状態が設定された場合に、上記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたものである。
請求項23の発明による遠隔管理システムは、請求項22の遠隔管理システムにおいて、上記複数の通信装置にそれぞれ、上記報知済み状態設定手段によって上記報知済み状態が設定された後、上記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって上記報知済み状態が解除された場合に、上記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたものである。
請求項24の発明による送信要因発生時の制御方法は、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信する通信装置における送信要因発生時の制御方法であって、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成し、該事象情報に該事象情報送信情報を付加して上記外部装置へ送信するものである。
請求項25の発明による送信要因発生時の制御方法は、請求項24の送信要因発生時の制御方法において、上記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断し、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には該事象情報を再び上記外部装置へ送信し、該事象情報の送信回数が上記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行い、この再送信制御時に上記再送信すべき同一の事象情報には上記生成した同一の事象情報送信情報を繰り返し付加するものである。
請求項26の発明によるプログラムは、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信するようにした通信装置を制御するコンピュータに、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成機能と、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報に上記事象情報送信情報生成機能によって生成された事象情報送信情報を付加して上記外部装置へ送信する事象情報送信機能とを実現させるためのプログラムである。
請求項27によるプログラムは、請求項26のプログラムにおいて、上記コンピュータに、上記事象情報送信機能による上記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する機能と、該機能によって上記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び上記外部装置へ送信し、該事象情報の送信回数が上記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行う機能と、該機能によって再送信される同一の事象情報には上記事象情報送信情報生成機能によって生成された同一の事象情報送信情報を繰り返し付加する機能とを実現させるためのプログラムも含むプログラムである。
この発明によれば、画像形成装置等の通信装置が、異常事象又は異常事前事象等の送信要因となる事象が発生してその事象を知らせる同一の事象情報を重複して外部装置へ送信した場合でも、その外部装置(管理装置)側でその事象情報を容易に把握することができる。
以下、この発明を実施するための最良の形態を図面に基づいて具体的に説明する。
まず、この発明による通信装置を被管理装置とする遠隔管理システムの構成例について説明する。
図1は、その遠隔管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される通信装置(電子装置)を説明の便宜上「被管理装置」と云う。
まず、この発明による通信装置を被管理装置とする遠隔管理システムの構成例について説明する。
図1は、その遠隔管理システムの構成の一例を示す概念図である。なお、ここでは、通信機能を持ち、管理装置によって管理される通信装置(電子装置)を説明の便宜上「被管理装置」と云う。
この遠隔管理システムは、プリンタ,FAX装置,デジタル複写機,デジタル複合機等の画像形成装置やスキャナ装置などの画像処理装置、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システムなどに通信機能を持たせた通信装置(電子装置)を被管理装置10(10a,10b,10c,10d,10e,10f)とする管理システムである。そして、この被管理装置10と接続される(被管理装置側から見た)外部装置として、被管理装置10とLAN(ローカルエリアネットワーク)等のネットワークによって接続された遠隔管理仲介装置である仲介装置101(101a,101b,101c)、更に仲介装置101とインタネット103(公衆回線等の他のネットワークでもよい)を介して接続されるサーバ装置として機能する管理装置102を備え、当該管理装置102が、仲介装置101を介して各被管理装置10を集中的に遠隔管理できるようにしたものである。被管理装置10および仲介装置101は機器利用者(ユーザ)側のオフィス等に、管理装置102はサービスセンタ(管理センタ)にそれぞれ設置されている。
ここで、管理装置102が新たな方式を用いて遠隔管理するサービス(NRS)を実現するために、機器利用者側のLAN等のネットワークに、NRSに対応するソフトウェアを実装した仲介装置101および被管理装置10が接続されている。その仲介装置101および被管理装置10には、管理装置102が従来の方式を用いて遠隔管理するサービス(CSS)も実現するために、CSSに対応するソフトウェアも実装している。NRSを実現するためには、CSSを実現する場合と同様に、仲介装置101および被管理装置10を初期設置すればよい。
公衆回線(又は専用回線)としては、アナログ回線,ADSL回線,デジタル回線(ISDN回線),光ファイバー利用回線等の固定電話回線や、携帯電話回線,PHS回線等の移動電話回線がある。
なお、仲介装置101と被管理装置10との接続は、ネットワークに限らず、RS−485規格等に準拠したシリアル接続や、SCSI(Small Computer System Interface)規格等に準拠したパラレル接続等によって行ってもよい。例えば、RS−485規格の場合には、仲介装置101に直列に5台までの被管理装置10を接続することができる。
公衆回線(又は専用回線)としては、アナログ回線,ADSL回線,デジタル回線(ISDN回線),光ファイバー利用回線等の固定電話回線や、携帯電話回線,PHS回線等の移動電話回線がある。
なお、仲介装置101と被管理装置10との接続は、ネットワークに限らず、RS−485規格等に準拠したシリアル接続や、SCSI(Small Computer System Interface)規格等に準拠したパラレル接続等によって行ってもよい。例えば、RS−485規格の場合には、仲介装置101に直列に5台までの被管理装置10を接続することができる。
仲介装置101および被管理装置10は、その利用環境に応じて多様な階層構造を成す。
例えば、図1に示す設置環境Aでは、管理装置102とHTTP(Hyper Text Transfer Protocol)による直接的なコネクションを確立できる仲介装置101aが被管理装置10aおよび10bを従える単純な階層構造になっているが、同図に示す設置環境Bでは、4台の被管理装置10を設置するため、1台の仲介装置101を設置しただけでは負荷が大きくなる。そのため、管理装置102とHTTPによる直接的なコネクションを確立できる仲介装置101bが、被管理装置10cおよび10dだけでなく、他の仲介装置101cを従え、この仲介装置101cが被管理装置10eおよび10fを更に従えるという階層構造を形成している。この場合、被管理装置10eおよび10fを遠隔管理するために管理装置102から発せられた情報は、仲介装置101bとその下位のノードである仲介装置101cとを経由して、被管理装置10e又は10fに到達することになる。
例えば、図1に示す設置環境Aでは、管理装置102とHTTP(Hyper Text Transfer Protocol)による直接的なコネクションを確立できる仲介装置101aが被管理装置10aおよび10bを従える単純な階層構造になっているが、同図に示す設置環境Bでは、4台の被管理装置10を設置するため、1台の仲介装置101を設置しただけでは負荷が大きくなる。そのため、管理装置102とHTTPによる直接的なコネクションを確立できる仲介装置101bが、被管理装置10cおよび10dだけでなく、他の仲介装置101cを従え、この仲介装置101cが被管理装置10eおよび10fを更に従えるという階層構造を形成している。この場合、被管理装置10eおよび10fを遠隔管理するために管理装置102から発せられた情報は、仲介装置101bとその下位のノードである仲介装置101cとを経由して、被管理装置10e又は10fに到達することになる。
また、設置環境Cのように、被管理装置10に仲介装置101の機能を併せ持たせた仲介機能付被管理装置(以下単に「被管理装置」ともいう)11a,11bを、別途仲介装置101を介さずにインタネット103によって管理装置102に接続するようにしてもよい。
図示はしていないが、仲介機能付被管理装置11の下位に更に被管理装置10を接続することもできる。
なお、各設置環境A,B,Cには、セキュリティ面を考慮し、ファイアウォール104(104a,104b,104c)を設置する。このファイアウォール104は、プロキシサーバによって構成する。
また、各被管理装置10,11に、ネットワーク経由でパーソナルコンピュータ等の端末装置や他の電子装置(外部装置)を接続することもできる。
図示はしていないが、仲介機能付被管理装置11の下位に更に被管理装置10を接続することもできる。
なお、各設置環境A,B,Cには、セキュリティ面を考慮し、ファイアウォール104(104a,104b,104c)を設置する。このファイアウォール104は、プロキシサーバによって構成する。
また、各被管理装置10,11に、ネットワーク経由でパーソナルコンピュータ等の端末装置や他の電子装置(外部装置)を接続することもできる。
このような遠隔管理システムにおいて、仲介装置101は、これに接続された被管理装置10の制御管理のためのアプリケーションプログラムを実装している。
管理装置102は、各仲介装置101の制御管理、更にはこの仲介装置101を介した被管理装置10の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置10も含め、この遠隔管理システムにおけるこれら各ノードは、RPC(remote procedure call)により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
管理装置102は、各仲介装置101の制御管理、更にはこの仲介装置101を介した被管理装置10の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置10も含め、この遠隔管理システムにおけるこれら各ノードは、RPC(remote procedure call)により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「要求」を送信し、この依頼された処理の結果である「応答」を取得することができるようになっている。
すなわち、仲介装置101又はこれと接続された被管理装置10では、管理装置102への要求を生成してこれを管理装置102へ引き渡し、この要求に対する応答を取得できる一方で、管理装置102は、上記仲介装置101側への要求を生成してこれを仲介装置101側へ引き渡し、この要求に対する応答を取得できるようになっている。この要求には、仲介装置101に被管理装置10に対して各種要求を送信させ、被管理装置10からの応答を仲介装置101を介して取得することも含まれる。
なお、RPCを実現するために、SOAP(Simple Object Access Protocol),HTTP,FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
なお、RPCを実現するために、SOAP(Simple Object Access Protocol),HTTP,FTP(File Transfer Protocol),COM(Component Object Model),CORBA(Common Object Request Broker Architecture)等の既知のプロトコル(通信規格),技術,仕様などを利用することができる。
この送受信のデータ送受モデルを図2の概念図に示す。
(A)は、被管理装置10で管理装置102に対する要求が発生したケースである。このケースでは、被管理装置10が被管理装置側要求aを生成し、これを仲介装置101を経由して受け取った管理装置102がこの要求に対する応答aを返すというモデルになる。同図に示す仲介装置101は複数であるケースも想定できる(上記図1に示す設置環境B)。なお、(A)では、応答aだけでなく応答遅延通知a′を返信するケースが表記されている。これは、管理装置102を、仲介装置101を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し(通信可能状態を解除し)、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
(A)は、被管理装置10で管理装置102に対する要求が発生したケースである。このケースでは、被管理装置10が被管理装置側要求aを生成し、これを仲介装置101を経由して受け取った管理装置102がこの要求に対する応答aを返すというモデルになる。同図に示す仲介装置101は複数であるケースも想定できる(上記図1に示す設置環境B)。なお、(A)では、応答aだけでなく応答遅延通知a′を返信するケースが表記されている。これは、管理装置102を、仲介装置101を経由して被管理装置側要求を受け取って、当該要求に対する応答を即座に返せないと判断したときには、応答遅延通知を通知して一旦接続状態を切断し(通信可能状態を解除し)、次回の接続の際に上記要求に対する応答を改めて引き渡す構成としているためである。
(B)は、管理装置102で被管理装置10に対する要求が発生したケースである。このケースでは、管理装置102が管理装置側要求bを生成し、これを仲介装置101を経由して受け取った被管理装置10が、当該要求に対する応答bを返すというモデルになっている。なお、(B)のケースでも、応答を即座に返せないときに応答遅延通知b′を返すことは(A)のケースと同様である。
次に、図1に示す管理装置102の物理的構成について簡単に説明すると、当該管理装置102は、CPU,ROM,RAM等からなる制御装置や、データベース,モデム,プロキシ(Proxy)サーバ等によって構成されている。その構成については、追って詳細に説明する。
さらに、図1に示す仲介装置101における物理的構成について簡単に説明すると、当該仲介装置101は、CPU,ROM,RAM,不揮発性メモリ,ネットワークインタフェース(NIC)等によって構成されている。
また、仲介機能付被管理装置11については、仲介装置101の機能を実現するためにこれらのユニットを単に被管理装置10に付加しても良いが、被管理装置10に備えるCPU,ROM,RAM等のハードウェア資源を利用し、CPUに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置101の機能を実現することもできる。
さらに、図1に示す仲介装置101における物理的構成について簡単に説明すると、当該仲介装置101は、CPU,ROM,RAM,不揮発性メモリ,ネットワークインタフェース(NIC)等によって構成されている。
また、仲介機能付被管理装置11については、仲介装置101の機能を実現するためにこれらのユニットを単に被管理装置10に付加しても良いが、被管理装置10に備えるCPU,ROM,RAM等のハードウェア資源を利用し、CPUに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置101の機能を実現することもできる。
以下、図1に示した遠隔管理システムのより具体的な例として、この発明による通信装置である画像形成装置を被管理装置とする遠隔管理システムである画像形成装置遠隔管理システム(画像形成装置管理システム)について説明する。図3は、その画像形成装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置10を画像形成装置100に、仲介機能付被管理装置11を仲介機能付画像形成装置(以下単に「画像形成装置」ともいう)110に変更した点が図1と相違するのみであるので、システムの全体構成についての説明は省略する。
画像形成装置100は、コピー,プリンタ,ファクシミリ,スキャナ等の機能および外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像形成装置110は、画像形成装置100に仲介装置101の機能を併せ持たせたものである。
画像形成装置100は、コピー,プリンタ,ファクシミリ,スキャナ等の機能および外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、仲介機能付画像形成装置110は、画像形成装置100に仲介装置101の機能を併せ持たせたものである。
このような画像形成装置100(又は110)の物理的構成について、図4を用いて具体的に説明する。
図4は、画像形成装置100内の物理的構成の一例を示すブロック図である。同図に示すように、画像形成装置100は、コントローラボード200,HDD(ハードディスクドライブ)201,NV−RAM(不揮発性RAM)202,PI(パーソナルインタフェース)ボード203,PHY(物理メディアインタフェース)204,操作パネル205,プロッタ/スキャナエンジンボード206,電源ユニット207,フィニッシャ208,ADF(自動原稿給送装置)209,給紙バンク210,その他周辺機211を備えている。これらのユニットは、それぞれがこの画像形成装置100におけるハードウェア資源である。
図4は、画像形成装置100内の物理的構成の一例を示すブロック図である。同図に示すように、画像形成装置100は、コントローラボード200,HDD(ハードディスクドライブ)201,NV−RAM(不揮発性RAM)202,PI(パーソナルインタフェース)ボード203,PHY(物理メディアインタフェース)204,操作パネル205,プロッタ/スキャナエンジンボード206,電源ユニット207,フィニッシャ208,ADF(自動原稿給送装置)209,給紙バンク210,その他周辺機211を備えている。これらのユニットは、それぞれがこの画像形成装置100におけるハードウェア資源である。
ここで、コントローラボード200は、制御手段に該当し、CPU,ROM,RAM等を備え、PCI−BUS(Peripheral Components Interconnect-Bus)212を介して各機能を制御している。また、HDD201は、記憶手段に該当する。また、NV−RAM202は、記憶手段に該当する不揮発性メモリであって、例えばフラッシュメモリ等が該当する。
また、PIボード203とPHY204は、通信手段に該当し、外部との通信を行うためのものであって、例えば通信ボード等が該当する。PIボード203はRS485規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このPIボード203を用いて画像形成装置100と仲介装置101とを接続することも可能である。PHY204は、LAN等のネットワークを介して外部装置と通信を行うためのインタフェースである。
また、PIボード203とPHY204は、通信手段に該当し、外部との通信を行うためのものであって、例えば通信ボード等が該当する。PIボード203はRS485規格に準拠したインタフェースを備え、ラインアダプタを介して公衆回線に接続している。なお、上述したように、このPIボード203を用いて画像形成装置100と仲介装置101とを接続することも可能である。PHY204は、LAN等のネットワークを介して外部装置と通信を行うためのインタフェースである。
また、操作パネル205は、操作部(操作手段)および表示部(表示手段)に該当するユーザインタフェースである。操作部は、ユーザの操作により各種指示を入力することができる。表示部は、画像形成装置100の設定状態や動作状態などを表示することができる。
ここで、同図中のENGRDYは、エンジンユニット(プロッタエンジン,スキャナエンジン)側の各種初期設定が完了して、コントローラボード200とコマンドの送受信の準備ができたことをコントローラボード200側に通知するための信号線である。また、PWRCTLは、エンジンユニットへの電源供給をコントローラボード200側から制御するための信号線である。これら信号線の動作に関しては後述する。
ここで、同図中のENGRDYは、エンジンユニット(プロッタエンジン,スキャナエンジン)側の各種初期設定が完了して、コントローラボード200とコマンドの送受信の準備ができたことをコントローラボード200側に通知するための信号線である。また、PWRCTLは、エンジンユニットへの電源供給をコントローラボード200側から制御するための信号線である。これら信号線の動作に関しては後述する。
次に、画像形成装置100(又は110)のソフトウェア構成について、図5を参照して具体的に説明する。
図5は、画像形成装置100のソフトウェア構成の一例を示すブロック図である。
この画像形成装置100のソフトウェア構成は、アプリケーションモジュール層,サービスモジュール層,汎用OS層からなる。そして、これらのソフトウェアを構成するプログラムはHDD201やコントローラボード200上のRAMに記憶され、必要に応じて読み出されてコントローラボード200上のCPUによって実行される。そして、そのCPUは、これらのプログラムを必要に応じて実行し、装置の制御を行うことにより、この発明による各機能(事象情報送信情報生成手段,事象情報送信手段,事象情報送信中状態設定手段,送信結果判断手段,事象情報送信中状態解除手段,送信失敗報知手段,報知済み状態設定手段,報知禁止手段,報知済み状態解除手段,報知禁止解除手段,時間計測手段,事象種判別手段としての機能)を実現することができる。
図5は、画像形成装置100のソフトウェア構成の一例を示すブロック図である。
この画像形成装置100のソフトウェア構成は、アプリケーションモジュール層,サービスモジュール層,汎用OS層からなる。そして、これらのソフトウェアを構成するプログラムはHDD201やコントローラボード200上のRAMに記憶され、必要に応じて読み出されてコントローラボード200上のCPUによって実行される。そして、そのCPUは、これらのプログラムを必要に応じて実行し、装置の制御を行うことにより、この発明による各機能(事象情報送信情報生成手段,事象情報送信手段,事象情報送信中状態設定手段,送信結果判断手段,事象情報送信中状態解除手段,送信失敗報知手段,報知済み状態設定手段,報知禁止手段,報知済み状態解除手段,報知禁止解除手段,時間計測手段,事象種判別手段としての機能)を実現することができる。
アプリケーションモジュール層のソフトウェアは、コントローラボード200上のCPU(コントローラCPU)を、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、コントローラCPUを、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付,その動作要求の調停,およびその動作要求に基づく動作の実行制御を行うサービス制御手段(処理実行手段)として機能させるためのプログラムによって構成される。
なお、コントローラCPUの機能のうち、管理装置102との通信に係わる機能(通信手段としての機能)の実現方法は、画像形成装置100と画像形成装置110とによって異なる。つまり、画像形成装置110の場合は、仲介装置101の機能を備えているため、コントローラCPUが対応するプログラムを実行することにより、管理装置102との通信に係わる機能を実現することができる。画像形成装置100の場合には、コントローラCPUが対応するプログラムを実行すると共に、仲介装置101を利用することにより、管理装置102との通信に係わる機能を実現することができる。
また、画像形成装置100は、スキャナエンジンおよびプロッタエンジンを含むエンジンユニット内にセンサ等からなる事象検出部(事象検出手段)を備えている。
また、画像形成装置100は、スキャナエンジンおよびプロッタエンジンを含むエンジンユニット内にセンサ等からなる事象検出部(事象検出手段)を備えている。
サービスモジュール層には、オペレーションコントロールサービス(OCS)300、エンジンコントロールサービス(ECS)301、メモリコントロールサービス(MCS)302、ネットワークコントロールサービス(NCS)303、ファクスコントロールサービス(FCS)304、システムコントロールサービス(SCS)306、システムリソースマネージャ(SRM)307、イメージメモリハンドラ(IMH)308、デリバリーコントロールサービス(DCS)316、ユーザコントロールサービス(UCS)317を実装している。また、アプリケーションモジュール層には、NRSアプリ(以下単に「NRS」という)305、CSSアプリ(以下単に「CSS」という)315、コピーアプリ309、ファクスアプリ310、プリンタアプリ311、スキャナアプリ312、ネットファイルアプリ313、ウェブアプリ314を実装している。更に、汎用OS層には、汎用OS320を実装している。
これらを更に詳述する。
OCS300は、操作パネル205を制御するモジュールである。
ECS301は、ハードウェアリソース等のエンジンユニットを制御するモジュールである。
MCS302は、メモリ制御をするモジュールであり、例えば、画像メモリの取得および開放、HDD201の利用等を行う。
NCS303は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
FCS304は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。
OCS300は、操作パネル205を制御するモジュールである。
ECS301は、ハードウェアリソース等のエンジンユニットを制御するモジュールである。
MCS302は、メモリ制御をするモジュールであり、例えば、画像メモリの取得および開放、HDD201の利用等を行う。
NCS303は、ネットワークとアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。
FCS304は、ファクシミリ送受信、ファクシミリ読み取り、ファクシミリ受信印刷等を行うモジュールである。
SCS306は、コマンドの内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理および終了管理を行うモジュールである。
SRM307は、システムの制御およびリソースの管理を行うモジュールである。
IMH308は、一時的に画像データを入れておくメモリを管理するモジュールである。
DCS316は、HDD201やコントローラボード200上のメモリに記憶している(する)画像ファイル等をSMTP(Simple Mail Transfer Protocol)やFTP(File Transfer Protocol)を用いて送受信するモジュールである。
UCS317は、ユーザ(機器利用者)が登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
SRM307は、システムの制御およびリソースの管理を行うモジュールである。
IMH308は、一時的に画像データを入れておくメモリを管理するモジュールである。
DCS316は、HDD201やコントローラボード200上のメモリに記憶している(する)画像ファイル等をSMTP(Simple Mail Transfer Protocol)やFTP(File Transfer Protocol)を用いて送受信するモジュールである。
UCS317は、ユーザ(機器利用者)が登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
NRS305およびCSS315はそれぞれ、互いに異なる方式による遠隔管理に関する機能(管理装置102との通信に係わる機能)をまとめたモジュールである。
コピーアプリ309は、コピーサービスを実現するためのアプリケーションプログラムである。
ファクスアプリ310は、ファクスサービスを実現するためのアプリケーションプログラムである。
プリンタアプリ311は、プリンタサービスを実現するためのアプリケーションプログラムである。
スキャナアプリ312は、スキャナサービスを実現するためのアプリケーションプログラムである。
コピーアプリ309は、コピーサービスを実現するためのアプリケーションプログラムである。
ファクスアプリ310は、ファクスサービスを実現するためのアプリケーションプログラムである。
プリンタアプリ311は、プリンタサービスを実現するためのアプリケーションプログラムである。
スキャナアプリ312は、スキャナサービスを実現するためのアプリケーションプログラムである。
ネットファイルアプリ313は、ネットファイルサービスを実現するためのアプリケーションプログラムである。
ウェブアプリ314は、ウェブサービスを実現するためのアプリケーションプログラムである。
汎用OS320は、UNIX(登録商標),Linux(登録商標),Windows(登録商標)等のオペレーティングシステムを使用することができる。オペレーティングシステムは、サービスモジュール層やアプリケーションモジュール層のプログラムなどを実行させる処理を司る。ここで、UNIXやLinuxを用いれば、オープンソースゆえの安全性が担保され、ソースコード入手の容易性などの利点がある。
ウェブアプリ314は、ウェブサービスを実現するためのアプリケーションプログラムである。
汎用OS320は、UNIX(登録商標),Linux(登録商標),Windows(登録商標)等のオペレーティングシステムを使用することができる。オペレーティングシステムは、サービスモジュール層やアプリケーションモジュール層のプログラムなどを実行させる処理を司る。ここで、UNIXやLinuxを用いれば、オープンソースゆえの安全性が担保され、ソースコード入手の容易性などの利点がある。
ここで、上述したENGRDY信号とPWRCTL信号との動作について、図6を用いて具体的に説明する。
図6の(A)は機器の立ち上がり時のENGRDY信号とPWRCTL信号の動作の一例を示している。主電源スイッチ(AC−POWER−SW)のONにより、AC−POWER(AC100V)の電源部から電源ユニット(主電源)207へ給電される(AC電源がONになる)と、電源ユニット207がON状態になり、電源ユニット207からコントローラボード200を含む装置全体への給電(電源供給)が開始され、これと同時にENGRDY信号はHighになる。この状態ではエンジンユニット側との通信はできない。なぜなら、エンジンユニット側の初期設定が完了していないからである。そして、一定期間経過後にエンジンユニット側の初期設定が完了し、ENGRDY信号がLowになった段階でエンジンユニット側との通信が可能となる。
図6の(A)は機器の立ち上がり時のENGRDY信号とPWRCTL信号の動作の一例を示している。主電源スイッチ(AC−POWER−SW)のONにより、AC−POWER(AC100V)の電源部から電源ユニット(主電源)207へ給電される(AC電源がONになる)と、電源ユニット207がON状態になり、電源ユニット207からコントローラボード200を含む装置全体への給電(電源供給)が開始され、これと同時にENGRDY信号はHighになる。この状態ではエンジンユニット側との通信はできない。なぜなら、エンジンユニット側の初期設定が完了していないからである。そして、一定期間経過後にエンジンユニット側の初期設定が完了し、ENGRDY信号がLowになった段階でエンジンユニット側との通信が可能となる。
次に、同図(B)は省エネモードに移行した時のENGRDY信号とPWRCTL信号の動作の一例を示している。電源ユニット207がON状態の時(電源ユニット207から装置全体への給電中)に、例えば操作パネル205上の図示しないソフト電源キーの操作により、ハードユニットであるエンジンユニットへの給電停止が指示されると、省エネモードに移行するため、コントローラボード200によりPWRCTL信号をOFFにする。これと同時に、電源ユニット207からエンジンユニットへの給電が停止する。これに伴って、ENGRDY信号は、Highとなり省エネモードに移行する。次に、省エネモードから復帰する場合を同図(C)に示す。
同図(C)は、省エネモードから復帰する時のENGRDY信号とPWRCTL信号の動作の一例を示している。上記(B)の省エネモードから復帰する際には、例えばソフト電源キーの操作によってエンジンユニットへの給電停止の解除が指示され、コントローラボード200によりPWRCTL信号をONにする。これと同時に、電源ユニット207からエンジンユニットへの給電停止が解除される。しかし、上記の(A)で示したように、エンジンユニット側の初期設定が完了するまで、ENGRDY信号はHighの状態であり、初期設定が完了するとエンジンユニット側との通信が可能となり、Lowとなる。
次に、上述した画像形成装置100のソフトウェアの構成に含まれるNRS305の内部構成について、図7を用いて更に説明する。
図7は、NRS305の構成の一例を示す機能ブロック図である。同図に示すように、NRS305は、SCS306とNCS303との間で処理を行っている。ウェブサーバ機能部500は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるXML(Extensible Markup Language)形式で記載された、SOAP(Simple Object Access Protocol)によるSOAPリクエストであることが考えられる。ウェブクライアント機能部501は、外部への要求を発行する処理を行う。libsoap502は、SOAPを処理するライブラリであり、libxml503は、XML形式で記載されたデータを処理するライブラリである。また、libgwww504は、HTTPを処理するライブラリであり、libgw_ncs505は、NCS303との間の処理をするライブラリである。
図7は、NRS305の構成の一例を示す機能ブロック図である。同図に示すように、NRS305は、SCS306とNCS303との間で処理を行っている。ウェブサーバ機能部500は、外部から受信した要求に関する応答処理を行う。ここでの要求は、例えば、構造化言語であるXML(Extensible Markup Language)形式で記載された、SOAP(Simple Object Access Protocol)によるSOAPリクエストであることが考えられる。ウェブクライアント機能部501は、外部への要求を発行する処理を行う。libsoap502は、SOAPを処理するライブラリであり、libxml503は、XML形式で記載されたデータを処理するライブラリである。また、libgwww504は、HTTPを処理するライブラリであり、libgw_ncs505は、NCS303との間の処理をするライブラリである。
次に、管理装置102の物理的構成について、図8を参照して具体的に説明する。
図8は、管理装置102の物理的構成の一例を示すブロック図である。
この管理装置102は、モデム601,通信端末602,プロキシ(Proxy)サーバ603,操作者端末604,データベース605,制御装置606等からなる。
モデム601は、公衆回線を介して機器利用者側(例えば画像形成装置を利用しているユーザ先)の仲介装置101又は画像形成装置110と通信を司るものであり、送受信するデータを変復調する。このモデム601と後述する通信端末602により通信手段としての機能を果たす。
通信端末602は、モデム601による通信を制御するものである。
図8は、管理装置102の物理的構成の一例を示すブロック図である。
この管理装置102は、モデム601,通信端末602,プロキシ(Proxy)サーバ603,操作者端末604,データベース605,制御装置606等からなる。
モデム601は、公衆回線を介して機器利用者側(例えば画像形成装置を利用しているユーザ先)の仲介装置101又は画像形成装置110と通信を司るものであり、送受信するデータを変復調する。このモデム601と後述する通信端末602により通信手段としての機能を果たす。
通信端末602は、モデム601による通信を制御するものである。
プロキシサーバ603は、インタネット103を介してユーザ(機器利用者)側の仲介装置101又は画像形成装置110との通信(データ送受信)およびセキュリティ管理を行う。このプロキシサーバ603も、通信手段としての機能を果たす。
操作者端末604は、サービスセンタの管理者であるセンタオペレータが操作する端末であり、各種データの入力をセンタオペレータによるキーボードやポインティングデバイス(マウス等)等の入力部上の操作により受け付けたり、センタオペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各ユーザ側の仲介装置101又は画像形成装置110が管理装置102へ通信する際に使用するIPアドレスや電話番号(発呼先電話番号)等の顧客情報がある。
操作者端末604は、サービスセンタの管理者であるセンタオペレータが操作する端末であり、各種データの入力をセンタオペレータによるキーボードやポインティングデバイス(マウス等)等の入力部上の操作により受け付けたり、センタオペレータに通知すべき情報を表示部に表示したりする。入力されるデータとしては、例えば、各ユーザ側の仲介装置101又は画像形成装置110が管理装置102へ通信する際に使用するIPアドレスや電話番号(発呼先電話番号)等の顧客情報がある。
データベース605は、図示しないサーバのHDD(ハードディスク装置)等の記憶装置に存在し、各ユーザ側の仲介装置101および画像形成装置110のIPアドレスや電話番号、それらの装置から受信したデータ(情報)、操作者端末604から入力されたデータ、機種データベースや顧客データベース、およびこの発明に係るプログラム等の各種データを記憶する。
制御装置606は、図示しないCPU,ROM,RAM等からなるマイクロコンピュータを備えており、管理装置102全体を統括的に制御する。そのCPUが、上記プログラムに従って動作する(上記プログラムを必要に応じて実行する)と共に、モデム601,通信端末602,プロキシサーバ603,操作者端末604,又はデータベース605を必要に応じて選択的に使用することにより、この発明による機能(送信結果送信手段としての機能)を実現することができる。
制御装置606は、図示しないCPU,ROM,RAM等からなるマイクロコンピュータを備えており、管理装置102全体を統括的に制御する。そのCPUが、上記プログラムに従って動作する(上記プログラムを必要に応じて実行する)と共に、モデム601,通信端末602,プロキシサーバ603,操作者端末604,又はデータベース605を必要に応じて選択的に使用することにより、この発明による機能(送信結果送信手段としての機能)を実現することができる。
上述した構成を踏まえて、図3の画像形成装置遠隔管理システム内で行われるデータ送受信の際の通信シーケンスの一例について、図9を用いて具体的に説明する。なお、以下に示すSCS306およびNRS305による処理は、実際には画像形成装置100のCPU(コントローラCPU)がそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。以後も、プログラムが何らかの処理を行うものとして説明を行う場合には、同様とする。
図9は、図3に示した管理装置102,仲介装置101,および画像形成装置100間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
図9は、図3に示した管理装置102,仲介装置101,および画像形成装置100間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。
この例においては、まず、仲介装置101は、インタネット103経由で管理装置102に対してポーリング(送信要求があるかどうかの問い合わせ)を行う(S601)。つまり、自己の識別情報である識別子を付加したポーリング用のSOAPメッセージを生成し(ポーリング情報を構造化言語形式であるXML形式に変換し)、そのSOAPメッセージに基づいてそれを含むHTTPメッセージを生成し、それをインタネット103経由で管理装置102へ送信する。図3に示したように、仲介装置101と管理装置102との間にはファイアウォール104を設けているため、管理装置102から仲介装置101に向けて通信セッションを張ることができないので、管理装置102から仲介装置101(あるいは仲介装置101を介して画像形成装置100)に要求を送信したい場合でも、このように仲介装置101からのポーリング(送信要求があるかどうかの問い合わせ)を待つ必要があるのである。なお、ファイアウォール104がなければ、ポーリングを行う必要はない。
管理装置102は、仲介装置101から上記HTTPメッセージ(HTTPリクエスト)を受信すると、課金カウンタ(カウンタ情報)取得要求を示す情報のSOAPメッセージを含むHTTPメッセージ(HTTPレスポンス)を生成し、それをインタネット103経由で該当する仲介装置101(受信したSOAPメッセージの送信元)へ、ポーリングに対する応答として送信する(S602)。このとき、受信したHTTPメッセージ内のSOAPメッセージに付加された識別子に基づいて該当する仲介装置101を認識する。このように、ファイアウォール104の内側からの通信(HTTPリクエスト)に対する応答(HTTPレスポンス)であれば、ファイアウォール104の外側から内側に対してデータを送信することができる。
仲介装置101は、管理装置102から上記HTTPメッセージを受信すると、そのHTTPメッセージに基づいてそのパケット上の課金カウンタ取得要求を示す情報のSOAPメッセージを生成し、それをネットワーク経由で自己に接続されている画像形成装置100のNRS305へ送信する(S603)。
NRS305は、仲介装置101から受信したSOAPメッセージに記述されている課金カウンタ取得要求をSCS306へ通知する(S604)。
SCS306は、NRS305から課金カウンタ取得要求の通知を受けると、NV−RAM202(又はHDD201)に格納されている課金カウンタのデータを読み取る(S605)。そして、その読み取った課金カウンタのデータ(応答データ)をNRS305へ引き渡す(S606)。
NRS305は、仲介装置101から受信したSOAPメッセージに記述されている課金カウンタ取得要求をSCS306へ通知する(S604)。
SCS306は、NRS305から課金カウンタ取得要求の通知を受けると、NV−RAM202(又はHDD201)に格納されている課金カウンタのデータを読み取る(S605)。そして、その読み取った課金カウンタのデータ(応答データ)をNRS305へ引き渡す(S606)。
NRS305は、SCS306から課金カウンタのデータ(カウンタ値を示すカウンタ情報)を受け取る(取得する)と、そのデータのSOAPメッセージを生成し(受け取ったデータを構造化言語形式であるXML形式に変換し)、それをネットワーク経由で仲介装置101へ送信する(S607)。
仲介装置101は、NRS305から課金カウンタのデータのSOAPメッセージを受信すると、そのSOAPメッセージに基づいてそれを含むHTTPメッセージを生成し、それをインタネット103経由で管理装置102へ送信する(S608)。
このように、上記通信シーケンスにより、データの送受信が行われる。
仲介装置101は、NRS305から課金カウンタのデータのSOAPメッセージを受信すると、そのSOAPメッセージに基づいてそれを含むHTTPメッセージを生成し、それをインタネット103経由で管理装置102へ送信する(S608)。
このように、上記通信シーケンスにより、データの送受信が行われる。
次に、上記図9と異なり、画像形成装置100から仲介装置101を経て管理装置102へデータを送信する場合の通信シーケンスの一例について、図10を参照して具体的に説明する。
図10は、画像形成装置100から管理装置102へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、OCS300は、操作パネル205上の図示しないユーザコールキーが押下された旨をSCS306へ通知する(S701)。
SCS306は、OCS300からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をNRS305へ通知する(S702)。
図10は、画像形成装置100から管理装置102へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、OCS300は、操作パネル205上の図示しないユーザコールキーが押下された旨をSCS306へ通知する(S701)。
SCS306は、OCS300からユーザコールキーが押下された旨の通知を受けると、ユーザコール要求をNRS305へ通知する(S702)。
NRS305は、SCS306からユーザコール要求の通知を受けると、ユーザコールを知らせるユーザコール情報であるユーザコール用のSOAPメッセージを生成し、それをネットワーク経由で仲介装置101へ送信する(S703)。
仲介装置101は、NRS305からユーザコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である識別子を付加し、更にそのSOAPメッセージに基づいてそれを含むHTTPメッセージを生成し、インタネット103経由で管理装置102に対してユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由で管理装置102へ通報する(S704)。この場合には、ファイアウォール104の内側から外側に向けての送信であるので、仲介装置101が自ら管理装置102に向けてセッションを張ってデータを送信することができる。
ここで、ステップS704の処理後のパターンを以下の(A)から(C)に分けて説明する。
仲介装置101は、NRS305からユーザコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である識別子を付加し、更にそのSOAPメッセージに基づいてそれを含むHTTPメッセージを生成し、インタネット103経由で管理装置102に対してユーザコールを行う。つまり、自己の識別子を付加したユーザコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由で管理装置102へ通報する(S704)。この場合には、ファイアウォール104の内側から外側に向けての送信であるので、仲介装置101が自ら管理装置102に向けてセッションを張ってデータを送信することができる。
ここで、ステップS704の処理後のパターンを以下の(A)から(C)に分けて説明する。
まず、(A)において、管理装置102は、ユーザ先の仲介装置101からユーザコール用のSOAPメッセージを含むHTTPメッセージを受信し、その受信が正常に終了した場合には、その旨(ユーザコールが成功した旨)のコール結果を、正常に終了しなかった(異常に終了した)場合には、その旨(ユーザコールが失敗した旨)のコール結果を示すSOAPメッセージを含むHTTPメッセージを生成し、それを応答としてインタネット103経由で通報元の仲介装置101へ送信する(S705)。
仲介装置101は、管理装置102からコール結果を示すSOAPメッセージを含むHTTPメッセージを受信すると、そのHTTPメッセージに基づいてそのパケット上のコール結果を示すSOAPメッセージを生成し、それをネットワーク経由でユーザコールキーが押下された画像形成装置100のNRS305へ送信する(S706)。
仲介装置101は、管理装置102からコール結果を示すSOAPメッセージを含むHTTPメッセージを受信すると、そのHTTPメッセージに基づいてそのパケット上のコール結果を示すSOAPメッセージを生成し、それをネットワーク経由でユーザコールキーが押下された画像形成装置100のNRS305へ送信する(S706)。
NRS305は、仲介装置101からコール結果を示すSOAPメッセージを受信すると、そのSOAPメッセージが示すコール結果を解釈(判定)し、それをSCS306へ通知する(S707)。
SCS306は、コール結果を受け取ると、それをOCS300へ引き渡す。
OCS300は、SCS306からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル205上の文字表示器に表示する(S708)。
SCS306は、コール結果を受け取ると、それをOCS300へ引き渡す。
OCS300は、SCS306からコール結果を受け取ると、その内容つまりユーザコールが成功したか失敗したかを示すメッセージを操作パネル205上の文字表示器に表示する(S708)。
次に(B)において、仲介装置101は、規定時間(予め設定された所定時間)が経っても管理装置102から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果を示すSOAPメッセージを生成し、それをNRS305へ送信する(S709)。
NRS305は、失敗した旨のコール結果を示すSOAPメッセージを受信すると、そのSOAPメッセージに記述されている失敗した旨のコール結果を解釈し、それをSCS306へ通知する(S710)。
SCS306は、NRS305からコール結果を受け取ると、それをOCS300へ引き渡す。
NRS305は、失敗した旨のコール結果を示すSOAPメッセージを受信すると、そのSOAPメッセージに記述されている失敗した旨のコール結果を解釈し、それをSCS306へ通知する(S710)。
SCS306は、NRS305からコール結果を受け取ると、それをOCS300へ引き渡す。
OCS300は、SCS306からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル205上の文字表示器に表示する(S711)。
次に(C)において、NRS305は、規定時間が経っても仲介装置101から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をSCS306へ通知する(S712)。
SCS306は、NRS305からコール結果を受け取ると、それをOCS300へ引き渡す。
OCS300は、SCS306からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル205上の文字表示器に表示する(S713)。
次に(C)において、NRS305は、規定時間が経っても仲介装置101から応答がないと判断した場合には、ユーザコールが失敗した旨のコール結果をSCS306へ通知する(S712)。
SCS306は、NRS305からコール結果を受け取ると、それをOCS300へ引き渡す。
OCS300は、SCS306からコール結果を受け取ると、その内容つまりユーザコールが失敗した旨を示すメッセージを操作パネル205上の文字表示器に表示する(S713)。
なお、ここでは管理装置102からファイアウォール104を越えて仲介装置101(あるいは仲介装置101を介して画像形成装置100)にデータを送信するために、仲介装置101からのHTTPリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール104を越える手段はこれに限られるものではなく、例えば、SMTP(Simple Mail Transfer Protocol)を利用して、送信したいデータを記載あるいは添付したメールを管理装置102から仲介装置101に送信することも考えられる。ただし、信頼性の面ではHTTPが優れている。
ここで、画像形成装置100は、自己のエンジンユニット内で異常事象又は異常事前事象等の通報要因となる事象が発生した場合、その事象を検出し、その事象の種類によって異なる処理を行う。よって、事象の種類を判定するための基準となる情報が必要であり、図11の例は異常事象(異常)の種類を判定するための基準となる情報の一例を示すテーブルのデータ構造を示している。ここで、「SC(サービスマンコール)」は「異常事象」に相当するものである。同図に示すように、検出されたSCによって種類(タイプ)が判定される。そこで、それぞれの種類について説明する。
「タイプA」のSCは、操作パネル205にSC表示を行って使用禁止(使用不可)とするもののうち、ユーザ(機器利用者)が解除できないSCである。このタイプAのSCは、管理装置102からの「SCリセット」もできない。例えば、定着系のSCなどである。「タイプA」は画像形成装置100(機器)側のメインスイッチ(主電源スイッチ)のOFF/ONによる主電源のOFF/ONもしくはソフト電源キーの操作によるエンジンユニットへの給電停止/解除によっては復旧できない。
「タイプB」は、異常が検出(検知)された特定の機能のみが使用できないSCである。通常使用時には操作パネル205上にSC表示を行わないが、異常が検出されている機能が選択された時だけ、その操作パネル205上にSC表示を行う。例えば、両面ユニット(両面トレイ)異常時に両面モードが選択された場合が該当する。
「タイプC」は、異常発生時にも操作パネル205へのSC表示は行わず、内部的にSCの発生のロギングのみを行うものである。例えば、通信が不能になった場合が該当する。
「タイプC」は、異常発生時にも操作パネル205へのSC表示は行わず、内部的にSCの発生のロギングのみを行うものである。例えば、通信が不能になった場合が該当する。
「タイプD」は、操作パネル205上にSC表示を行って使用禁止とするが、画像形成装置100側のメインスイッチのOFF/ONによる主電源のOFF/ONもしくはソフト電源キーの操作によるエンジンユニットへの給電停止/解除によって解除できるSCである。但し、主電源ON(電源投入)後もしくはエンジンユニットへの給電停止/解除後に、再度異常を検出して、見かけ上解除されない場合もある。例えば、モータ異常がそれに該当する。
上記判定の基準情報は、上述したNV−RAM202(又はHDD201)の所定の格納領域に格納されていることが考えられる。なお、スキャナエンジンのSC,プロッタエンジンのSCのように、ユニット別の事象も種類の異なる事象として扱うものとする。
上記判定の基準情報は、上述したNV−RAM202(又はHDD201)の所定の格納領域に格納されていることが考えられる。なお、スキャナエンジンのSC,プロッタエンジンのSCのように、ユニット別の事象も種類の異なる事象として扱うものとする。
次に、上述した画像形成装置および画像形成装置遠隔管理システムにおける実施例、つまりこの発明の特徴となる動作(画像形成装置での通報要因発生時の制御)およびその動作を実現するための構成について説明する。
この画像形成装置には、上述したように、公衆回線に対応した通信手段とインタネット通信に対応した通信手段の双方を設けている。
そして、画像形成装置100は、仲介装置101および公衆回線を介して管理装置102と通信するCSS方式による遠隔管理(リモートサービス:RS)と、仲介装置101およびインタネット103を介して管理装置102と通信するNRS方式による遠隔管理の対象となり得るように構成している。画像形成装置110は、仲介装置101の機能を備えているため、公衆回線を介して管理装置と通信するCSS方式による遠隔管理と、インタネット103を介して管理装置102と通信するNRS方式による遠隔管理の対象となり得るように構成している。
この画像形成装置には、上述したように、公衆回線に対応した通信手段とインタネット通信に対応した通信手段の双方を設けている。
そして、画像形成装置100は、仲介装置101および公衆回線を介して管理装置102と通信するCSS方式による遠隔管理(リモートサービス:RS)と、仲介装置101およびインタネット103を介して管理装置102と通信するNRS方式による遠隔管理の対象となり得るように構成している。画像形成装置110は、仲介装置101の機能を備えているため、公衆回線を介して管理装置と通信するCSS方式による遠隔管理と、インタネット103を介して管理装置102と通信するNRS方式による遠隔管理の対象となり得るように構成している。
ここで、画像形成装置100および画像形成装置110は、自己のエンジンユニットの状態を示す情報を送信したり、自己のエンジンユニット等に異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、その事象の発生を知らせる事象情報等を管理装置へ通報したりするためのプログラムとして、上記のCSS方式に対応したCSS315と、上記のNRS方式に対応したNRS305とを設けている。
以下、説明の都合上、画像形成装置100がNRS305を使用する場合のこの発明に係わる制御について説明する。但し、エンジンユニットに相当するものがスキャナエンジンおよびプロッタエンジンしかないものとする。
なお、画像形成装置100がCSS315を使用することによってもこの発明に係わる制御を行うことができる。また、画像形成装置110がNRS305又はCSS315を使用することによってもこの発明に係わる制御を行うことができる。
なお、画像形成装置100がCSS315を使用することによってもこの発明に係わる制御を行うことができる。また、画像形成装置110がNRS305又はCSS315を使用することによってもこの発明に係わる制御を行うことができる。
〔第1実施例〕
図12は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド(異常事前事象)発生時の通信シーケンスの第1例(トナーサプライコール成功例)を示す図である。
画像形成装置100では、スキャナエンジンおよびプロッタエンジン内の各部にそれぞれ事象検出部を備えており、例えば図12に示すように、プロッタエンジン内でトナーボトルのトナーニアエンドが発生した場合(トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合)、対応する事象検出部がそのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラボード200のSCS306へ通知する(S1001)。
図12は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド(異常事前事象)発生時の通信シーケンスの第1例(トナーサプライコール成功例)を示す図である。
画像形成装置100では、スキャナエンジンおよびプロッタエンジン内の各部にそれぞれ事象検出部を備えており、例えば図12に示すように、プロッタエンジン内でトナーボトルのトナーニアエンドが発生した場合(トナーサプライであるトナーボトル内のトナー量が所定量以下になった場合)、対応する事象検出部がそのトナーニアエンドを検出し、トナーニアエンドが発生した旨をコントローラボード200のSCS306へ通知する(S1001)。
SCS306は、プロッタエンジンからトナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内でトナーニアエンドが発生したと判定して、NV−RAM(不揮発性メモリ)202内のトナーサプライコール済みフラグ(コール済みフラグ)およびトナーサプライコール後通紙枚数カウンタ(コール後通紙枚数カウンタ)の値をそれぞれチェックし(S1002,S1003)、トナーサプライコール済みフラグ(コール済みフラグ)が“0”にリセットされ、且つコール後通紙枚数カウンタの値が「1000」以上になっている(但し機器が一度もトナーサプライコールを行っていない場合には本条件を無視する)場合には、トナーサプライコール発行条件を満足しているものと判定する。
そして、NV−RAM202内のメール送信済みフラグを“0”にリセットした後(S1004)、NV−RAM内のトナーサプライコールリトライ回数カウンタ(リトライ回数カウンタ)に「3」をセットし(S1005)、トナーサプライコール(トナーニアエンドの発生つまりトナーボトルの発注を知らせるトナーサプライコール情報の自動通報)を識別するコールID(事象情報送信情報)を生成して(S1006)、そのコールIDをNV−RAM202に保存し(S1007)、トナーサプライコールの実行中を示すサプライコール実行中フラグ(事象情報送信中状態)を“1”にセット(設定)した後(S1008)、トナーサプライコール要求をNRS305へ通知する(S1009)。このとき、そのトナーサプライコール要求に、画像形成装置100の識別情報である機番情報およびNV−RAM202に保存したコールIDを付加する。また、操作パネル205上の文字表示器には、「トナーサプライコール中」のメッセージを表示する。
NRS305は、トナーサプライコール要求の通知を受けると、トナーボトルの発注(トナーニアエンドの発生)を知らせるトナーサプライコール情報であるトナーサプライコール用のSOAPメッセージ(トナーサプライコール要求に付加された機番情報およびコールIDを含む)を生成して、それを仲介装置101へ送信する(S1010)。
仲介装置101は、NRS305からトナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対してトナーサプライコールを行う(S1011)。つまり、自己の仲介装置識別子を付加したトナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報(自動送信)する。
仲介装置101は、NRS305からトナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対してトナーサプライコールを行う(S1011)。つまり、自己の仲介装置識別子を付加したトナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報(自動送信)する。
ここで、HTTPメッセージ内のトナーサプライコール用のSOAPメッセージ(仲介装置識別子は除く)のフォーマット例について、図31および図32を参照して簡単に説明する。
図31はHTTPメッセージ内のトナーサプライコール用のSOAPメッセージのフォーマット例を、図32はその主要部分(データ)の構成をそれぞれ示す説明図である。
図31はHTTPメッセージ内のトナーサプライコール用のSOAPメッセージのフォーマット例を、図32はその主要部分(データ)の構成をそれぞれ示す説明図である。
これらの図を見て分かるように、トナーサプライコール用のSOAPメッセージは、トナーニアエンドが発生した画像形成装置100の識別情報である機番情報と、トナーサプライコールを識別する任意のコールIDと、コールタイプ(第1実施例ではトナーサプライコールの種類を示す情報は含まないものとする)と、コールの詳細を示す情報とからなる。このトナーサプライコール用のSOAPメッセージには、付加情報としてトナーニアエンドが発生した画像形成装置100のジャムやSC,ステータス(状態),カウンタのそれぞれの値およびログ(履歴情報)を付加することもできる。
管理装置102は、いずれかの機器利用者側の仲介装置101から通報されたトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを受信し、その受信が正常に終了した場合に、その受信したHTTPメッセージ内のSOAPメッセージに付加された機番情報および仲介装置識別子に基づいて、そのHTTPメッセージの受信が正常に終了した旨(トナーサプライコールに対する処理が成功した旨)のコール結果であるコールOKを示すSOAPメッセージを含むHTTPメッセージを生成し、インタネット103経由で通報元の仲介装置101(トナーサプライコール用のSOAPメッセージを含むHTTPメッセージを送信した仲介装置101)へ送信する(S1012)。
また、受信したHTTPメッセージ内のSOAPメッセージ(トナーサプライコール情報)をキュー(データベース605)に格納し、センタオペレータによって対応する処理、つまりトナーボトルの受注作業が行われるまでキューイング(保持)する。
さらに、受信したHTTPメッセージ内のSOAPメッセージの内容を操作者端末604の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末604の表示部の表示内容を見て通報元の仲介装置101に接続されている画像形成装置100のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置101の設置場所にトナーボトルを届けさせる。
さらに、受信したHTTPメッセージ内のSOAPメッセージの内容を操作者端末604の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末604の表示部の表示内容を見て通報元の仲介装置101に接続されている画像形成装置100のプロッタエンジン内でトナーニアエンドが発生し、トナーボトルが発注されたことを認識すると、トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置101の設置場所にトナーボトルを届けさせる。
仲介装置101は、管理装置102へのトナーサプライコール(トナーサプライコール用のSOAPメッセージを含むHTTPメッセージの自動通報)の結果として、その管理装置102からコールOK(上記HTTPメッセージの受信が正常に終了した旨のコール結果)を示すSOAPメッセージを含むHTTPメッセージを受信すると、そのHTTPメッセージに基づいてコールOKを示すSOAPメッセージを生成し、それを該当する(トナーニアエンドが発生した)画像形成装置100のNRS305へ送信する(S1013)。
そのNRS305は、仲介装置101からコールOKを示すSOAPメッセージを受信すると、SCS306へコールOK(トナーサプライコールが正常に終了した旨)を通知する(S1014)。
そのNRS305は、仲介装置101からコールOKを示すSOAPメッセージを受信すると、SCS306へコールOK(トナーサプライコールが正常に終了した旨)を通知する(S1014)。
SCS306は、NRS305からコールOKの通知を受けると、管理装置102へのトナーサプライコールが成功したと判断し、操作パネル205上の文字表示器に「トナーサプライコール成功」のメッセージを表示する。
また、NV−RAM202内のサプライコール実行中フラグを“0”にリセット(解除)し(S1015)、NV−RAM202内のトナーサプライコールの成功を示すトナーサプライコール済みフラグ(事象送信済み状態)を“1”にセットする(S1016)。
さらに、NV−RAM202内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし(S1017,S1018)、「0」からカウント動作を行えるようにする。
また、NV−RAM202内のサプライコール実行中フラグを“0”にリセット(解除)し(S1015)、NV−RAM202内のトナーサプライコールの成功を示すトナーサプライコール済みフラグ(事象送信済み状態)を“1”にセットする(S1016)。
さらに、NV−RAM202内のコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし(S1017,S1018)、「0」からカウント動作を行えるようにする。
画像形成装置100のプロッタエンジン内のトナーボトルが交換され、トナーフルが発生した場合(トナーボトル内のトナー量が満杯になった場合)、対応する事象検出部が、そのトナーフルを検出し、トナーフルが発生した旨をSCS306へ通知する(S1019)。
SCS306は、プロッタエンジンからトナーフルが発生した旨の通知を受けると、NV−RAM202内のコール済みフラグを“0”にリセットし(S1020)、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「1000」にならないと、サプライコールを行うことはない。
SCS306は、プロッタエンジンからトナーフルが発生した旨の通知を受けると、NV−RAM202内のコール済みフラグを“0”にリセットし(S1020)、次のトナーニアエンドでサプライコールを行えるようにする。但し、コール後通紙枚数カウンタの値が「1000」にならないと、サプライコールを行うことはない。
図13および図14は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド発生時の通信シーケンスの第2例(トナーサプライコール失敗例)を示す図である。なお、ステップS2001〜S2011の制御は図12のステップS1001〜S1011の制御と同様なので、その説明を省略する。
一方、通報元の仲介装置101は、例えば図13に示すように、ステップS2011のサービスセンタの管理装置102へのトナーサプライコール(トナーサプライコール用のSOAPメッセージを含むHTTPメッセージの自動通報)の結果として、その管理装置102からコールOK(上記HTTPメッセージの受信が正常に終了した旨のコール結果)を示すSOAPメッセージを含むHTTPメッセージを規定時間(予め設定された所定時間)が経過しても受信できなかった場合、そのHTTPメッセージに基づいてコールNGを示すSOAPメッセージを生成し、それを該当する画像形成装置100のNRS305へ送信する(S2012)。
そのNRS305は、仲介装置101からコールNGを示すSOAPメッセージを受信すると、SCS306へコールNG(トナーサプライコールが正常に終了しなかった旨)を通知する(S2013)。
一方、通報元の仲介装置101は、例えば図13に示すように、ステップS2011のサービスセンタの管理装置102へのトナーサプライコール(トナーサプライコール用のSOAPメッセージを含むHTTPメッセージの自動通報)の結果として、その管理装置102からコールOK(上記HTTPメッセージの受信が正常に終了した旨のコール結果)を示すSOAPメッセージを含むHTTPメッセージを規定時間(予め設定された所定時間)が経過しても受信できなかった場合、そのHTTPメッセージに基づいてコールNGを示すSOAPメッセージを生成し、それを該当する画像形成装置100のNRS305へ送信する(S2012)。
そのNRS305は、仲介装置101からコールNGを示すSOAPメッセージを受信すると、SCS306へコールNG(トナーサプライコールが正常に終了しなかった旨)を通知する(S2013)。
SCS306は、NRS305からコールNGの通知を受けると、管理装置102へのトナーサプライコールが失敗したと判断し、操作パネル205上の文字表示器に「トナーサプライコール失敗」のメッセージを表示する。
また、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)し(S2014)、初回コール(初回通報)時と同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、リトライ(再通報)制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一のトナーサプライコールの回数が予め設定された所定回数である3回に達していない場合)に、再び初回コール時と同一のトナーサプライコール要求をNRS305へ通知する(S2015)。このとき、そのトナーサプライコール要求に、NV−RAM202に保存しておいた初回コール時と同一のコールIDを付加する。なお、ここでの初回コールとは、同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージの1回目の通報のことをさす。
また、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)し(S2014)、初回コール(初回通報)時と同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、リトライ(再通報)制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一のトナーサプライコールの回数が予め設定された所定回数である3回に達していない場合)に、再び初回コール時と同一のトナーサプライコール要求をNRS305へ通知する(S2015)。このとき、そのトナーサプライコール要求に、NV−RAM202に保存しておいた初回コール時と同一のコールIDを付加する。なお、ここでの初回コールとは、同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージの1回目の通報のことをさす。
NRS305は、SCS306から初回コール時と同一のトナーサプライコール要求の通知を受けると、初回コール時と同一のトナーサプライコール用のSOAPメッセージを生成して、それを仲介装置101へ送信する(S2016)。
仲介装置101は、NRS305から初回コール時と同一のトナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに再び自己の仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対してトナーサプライコールを行う(S2017)。つまり、自己の識別子を付加したトナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
仲介装置101は、NRS305から初回コール時と同一のトナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに再び自己の仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対してトナーサプライコールを行う(S2017)。つまり、自己の識別子を付加したトナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
その後、サービスセンタの管理装置102へのトナーサプライコールの結果として、その管理装置102からコールOKを示すSOAPメッセージを含むHTTPメッセージを規定時間が経過しても受信できなかった場合、再びそのHTTPメッセージに基づいてコールNGを示すSOAPメッセージを生成し、それを該当する画像形成装置100のNRS305へ送信する(S2018)。
そのNRS305は、仲介装置101から再びコールNGを示すSOAPメッセージを受信すると、SCS306へコールNGを通知する(S2019)。
そのNRS305は、仲介装置101から再びコールNGを示すSOAPメッセージを受信すると、SCS306へコールNGを通知する(S2019)。
SCS306は、NRS305から再びコールNGの通知を受けると、管理装置102へのトナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後(S2020)、そのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合に、再び初回コール時と同一のトナーサプライコール要求をNRS305へ通知する(S2021)。それによってNRS305および仲介装置101が上述と同様の処理(制御)を行う(S2022,S2023)。
その後、NRS305から再びコールNGの通知を受けると(S2025)、管理装置102へのトナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後(S2026)、そのリトライ回数カウンタの値をチェックすると、その値が「0」になっている(同一のトナーサプライコールの回数が3回に達した)ため、上述したリトライ(再送信)を停止し、以下に示す処理を行う。
その後、NRS305から再びコールNGの通知を受けると(S2025)、管理装置102へのトナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後(S2026)、そのリトライ回数カウンタの値をチェックすると、その値が「0」になっている(同一のトナーサプライコールの回数が3回に達した)ため、上述したリトライ(再送信)を停止し、以下に示す処理を行う。
すなわち、NV−RAM202内のメール送信済みフラグの状態をチェックし(S2027)、そのメール送信済みフラグが“0”になっていると確認できた場合に、管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知する(S2028)。このとき、その電子メール送信要求に、画像形成装置100の機番情報および初回コール時と同一のコールIDを付加する。そして、その電子メール送信要求をDCS316へ通知した後、NV−RAM202内のメール送信済みフラグを“1”にセットした後(S2029)、図示しない24H(24時間)タイマ(時間計測手段)を起動(開始)させる(S2030)。
DCS316は、SCS306から電子メール送信要求の通知を受けると、管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メールをLAN経由で図示しないサプライ管理端末(パーソナルコンピュータ等)へ送信する。
DCS316は、SCS306から電子メール送信要求の通知を受けると、管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メールをLAN経由で図示しないサプライ管理端末(パーソナルコンピュータ等)へ送信する。
ここで、管理装置102へのトナーサプライコール(トナーサプライの発注)が失敗した旨を報知するための電子メールについて、図16を参照して簡単に説明する。
図16は、その電子メールの内容の一例を示す説明図である。
この電子メールは、画像形成装置100のシステム初期設定等によって予め設定されたアドレス([email protected])へ通報される。この例では、サプライを管理するためのサプライ管理端末へ通報される。そのサプライ管理端末装置は、サプライ管理担当者によって使用される。
図16は、その電子メールの内容の一例を示す説明図である。
この電子メールは、画像形成装置100のシステム初期設定等によって予め設定されたアドレス([email protected])へ通報される。この例では、サプライを管理するためのサプライ管理端末へ通報される。そのサプライ管理端末装置は、サプライ管理担当者によって使用される。
この電子メールには、画像形成装置100の識別情報である機器識別ID(機番情報)および初回コール時と同一のコールIDを組にしたID(先頭11桁が機器識別IDで、後の10桁がコールID)の他に、サプライの名称(この例では黒トナーボトル)やサービスセンタの電話番号である連絡先電話番号を添付(付加)する。なお、この第1実施例では、1色(黒)のトナーボトルしか備えていないものとしているため、サプライの名称は単にトナーボトルとしてもよい。後述する第2実施例では、複数色のトナーボトルを備えているものとするため、サプライの名称を黒トナーボトルや赤トナーボトルというようにする。つまり、電子メールにトナーボトルの種類を示す情報を添付する。
この電子メールを受信したサプライ管理端末装置を使用しているサプライ管理担当者は、その電子メールに記載された連絡先電話番号へ電話するが、その際にサプライの名称とIDを連絡する。
サービスセンタ側では、トナーサプライの2重発注を防ぐために、以下の(1)(2)に示す作業を行う。
この電子メールを受信したサプライ管理端末装置を使用しているサプライ管理担当者は、その電子メールに記載された連絡先電話番号へ電話するが、その際にサプライの名称とIDを連絡する。
サービスセンタ側では、トナーサプライの2重発注を防ぐために、以下の(1)(2)に示す作業を行う。
(1)機器利用者側からの電話連絡後、上記電子メールを送信した画像形成装置100から仲介装置101経由で同一のIDのトナーサプライコール用のSOAPメッセージを含むHTTPメッセージ(トナーサプライコール情報)がインタネット103経由でサービスセンタの管理装置102へ自動通報され(電話連絡後にNRS通信が正常復帰し)、管理装置102でそのHTTPメッセージの受信が正常に終了した場合、そのトナーサプライコール(トナーサプライコールの発注コール)情報を無視する。そのため、管理装置102は、電話連絡によって通知されたIDを登録しておき、その後そのIDと同一のIDの発注コール情報を受信した場合には、それを受注対象外コール情報として自動破棄する処理を行う。この場合、電話連絡により、センタオペレータがトナーサプライの発注業務を開始することになる。
(2)既に同一のIDの発注コール情報が通報された後、電話連絡があった場合(電話連絡前にNRS通信が正常復帰した場合)には、センタオペレータがその電話連絡時に同一のIDによるトナーサプライの発注の有無を調査する。そして、電話連絡されたIDと同一IDの発注履歴が存在した場合には、既にNRS通信にて発注業務が開始されているため、電話連絡による発注業務は実施しない。
なお、コールIDは、画像形成装置100の納入時に、「0」にリセットされる。
なお、コールIDは、画像形成装置100の納入時に、「0」にリセットされる。
トナーニアエンドが発生した画像形成装置100のコントローラボード200のSCS306は、24Hタイマを起動させた後(S2030)、例えば図14に示すように、その24Hタイマによる計測時間が24時間を経過すると(S2031)、再びリトライ回数カウンタに「3」をセットした後(S2032)、初回コール時と同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、再び上述と同様のリトライ制御を行う(S2033)。
このリトライ制御(1回目のリトライ制御)を行っても、管理装置102へのトナーサプライコールが失敗した場合(NRS305から再びコールNGの通知を受けた場合)には(S2037)、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)して(S2038)、再び上述と同様のリトライ制御(2回目のリトライ制御)を行い(S2039)、それでも管理装置102へのトナーサプライコールが失敗した場合には(S2043)、リトライ回数カウンタをデクリメント(−1)して(S2044)、再び上述と同様のリトライ制御(3回目のリトライ制御)を行う(S2045)。
3回目のリトライ制御を行なっても、管理装置102へのトナーサプライコールが失敗した場合には(S2049)、リトライ回数カウンタをデクリメント(−1)すると(S2050)、リトライ回数カウンタの値が「0」になっている(同一のトナーサプライコールの回数が3回に達した)ため、上述したリトライ(再送信)を再度停止し、NV−RAM202内のメール送信済みフラグの状態をチェックする(S2051)が、この場合にはメール送信済みフラグが既に“1”にセットされているため、管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知しない(電子メール送信の通知を禁止する)。しかし、24H(24時間)タイマは再起動させ(S2052)、以後管理装置102へのトナーサプライコールが成功するまで上述と同様の制御を繰り返す。
図15は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド発生時の通信シーケンスの第3例(トナーサプライコール中の主電源OFF/ON時の例)を示す図である。
ところで、管理装置102へのトナーサプライコールの実行中に、本体主電源(電源ユニット207)がOFF/ONした場合(本体主電源が一旦遮断した後再投入された場合)には、例えば図15に示すような制御を行う。
すなわち、NV−RAM202内のサプライコール実行中フラグの状態をチェックし(S3001)、そのサプライコール実行中フラグが“0”にリセットされていると確認できた場合には何もしないが、“1”にセットされていると確認できた場合には、管理装置102へのトナーサプライコールの実行中に本体主電源がOFF/ONし、そのトナーサプライコールが成功していないため、再びリトライ回数カウンタに「3」をセットした後(S3002)、上述と同様のリトライ制御を行う(S3003)。
ところで、管理装置102へのトナーサプライコールの実行中に、本体主電源(電源ユニット207)がOFF/ONした場合(本体主電源が一旦遮断した後再投入された場合)には、例えば図15に示すような制御を行う。
すなわち、NV−RAM202内のサプライコール実行中フラグの状態をチェックし(S3001)、そのサプライコール実行中フラグが“0”にリセットされていると確認できた場合には何もしないが、“1”にセットされていると確認できた場合には、管理装置102へのトナーサプライコールの実行中に本体主電源がOFF/ONし、そのトナーサプライコールが成功していないため、再びリトライ回数カウンタに「3」をセットした後(S3002)、上述と同様のリトライ制御を行う(S3003)。
以後、図14と略同様の制御を行う。異なるのは、もし3回目のリトライ制御を行っても、管理装置102へのトナーサプライコールが失敗した場合には、リトライ回数カウンタをデクリメント(−1)すると(S3011)、リトライ回数カウンタの値が「0」になっているため、上述したリトライ(再送信)を再度停止した後、NV−RAM202内のメール送信済みフラグの状態をチェックする(S3012)が、メール送信済みフラグが“1”にセットされていないため、管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知する(S3013)ことである。
図17および図18は、画像形成装置100のコントローラボード200のSCS306によるトナーニアエンド発生時の処理の概略例を示すフローチャートである。
画像形成装置100のSCS306は、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図17および図18の処理ルーチンを開始し、まずステップS1でNV−RAM202のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“0”にリセットされていると確認できた場合にステップS2へ進み、画像形成装置100の納入後、初めてトナーサプライコールを行うか否かを判断する。
画像形成装置100のSCS306は、プロッタエンジン内でトナーニアエンドが発生し、対応する事象検出部によってそのトナーニアエンドが検出されることにより、トナーニアエンドが発生した旨の通知を受けると、図17および図18の処理ルーチンを開始し、まずステップS1でNV−RAM202のトナーサプライコール済みフラグの状態をチェックし、そのトナーサプライコール済みフラグが“0”にリセットされていると確認できた場合にステップS2へ進み、画像形成装置100の納入後、初めてトナーサプライコールを行うか否かを判断する。
そして、画像形成装置100の納入後、初めてトナーサプライコールを行うのであれば(初めてトナーニアエンドが発生した場合には)そのままステップS4へ進むが、初めてトナーサプライコールを行うのでなければステップS3でNV−RAM202内のコール後通紙枚数カウンタの値が「1000」に達したか否かを判断し、「1000」に達していればステップS4へ進み、コールIDを生成する。このコールIDとしては、前回生成したものと異なるものを生成する。例えば、前回生成したコールIDが「0000000001」であった場合、今回生成するコールIDを「0000000002」とする。リトライ制御時には、同一のコールIDを繰り返し使用する。
次に、ステップS5で生成したコールIDをNV−RAM202に保存(セット)し、ステップS6でNV−RAM202内のサプライコール実行中フラグを“1”にセットし、ステップS7でNV−RAM202内のメール送信済みフラグを“0”にリセットし、ステップS8でNV−RAM202内のリトライ回数カウンタに「3」をセットした後、ステップS9でトナーサプライコール要求に画像形成装置100の機番情報およびNV−RAM202に保存したコールIDを付加してNRS305へ通知する。
その後、ステップS10でNRS305からの通知の有無をチェックし、NRS305からコールOKの通知を受けた場合には、管理装置102へのトナーサプライコールが成功したと判断してステップS11へ移行し、後述する処理を行う。
その後、ステップS10でNRS305からの通知の有無をチェックし、NRS305からコールOKの通知を受けた場合には、管理装置102へのトナーサプライコールが成功したと判断してステップS11へ移行し、後述する処理を行う。
NRS305からコールNGの通知を受けた場合には、管理装置102へのトナーサプライコールが失敗したと判断してステップS15へ移行し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後、ステップS16でそのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一のトナーサプライコールの回数が3回に達していない場合)にステップS9へ戻り、再び初回コール時と同一のトナーサプライコール要求をNRS305へ通知し(そのトナーサプライコール要求に画像形成装置100の機番情報およびNV−RAM202に保存しておいた初回コール時と同一のコールIDを付加する)、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「0」になったら、次の処理を行う。
すなわち、図18のステップS17でNV−RAM202内のメール送信済みフラグの状態をチェックし、そのメール送信済みフラグが“1”にセットされていると確認できた場合にはそのままステップS20へ移行するが、“0”にリセットされていると確認できた場合にはステップS18で管理装置102へのトナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知する。このとき、その電子メール送信要求に、画像形成装置100の機番情報および初回コール時と同一のコールIDを付加する。そして、その電子メール送信要求をDCS316へ通知した後、ステップS19でNV−RAM202内のメール送信済みフラグを“1”にセットした後、ステップS20で24時間タイマを起動させ、その24時間タイマによる計測時間が24時間経過するのを待って、図17のステップS8へ戻り、上述と同様の処理を繰り返す。
リトライ回数カウンタの値が「0」になる前に、ステップS10で管理装置102へのトナーサプライコールが成功したと判断した場合には、ステップS11でNV−RAM202内のトナーサプライコール済みフラグを“1”にセットし、ステップS12でNV−RAM202内のコール後通紙枚数カウンタの値を、ステップS13でリトライ回数カウンタの値をそれぞれ「0」にリセットした後、ステップS14でNV−RAM202内のサプライコール実行中フラグを“0”にリセットし、図17,図18の処理を終了する。
図19は、画像形成装置100のコントローラボード200のSCS306による主電源ON時の処理例の一部を示すフローチャートである。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内のサプライコール実行中フラグの状態をチェックし、そのサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図17のステップS8以降の処理と同様の処理を行う。
なお、SCS306による転写紙正常排紙時の処理およびトナーフル時の処理はそれぞれ、図37,図38によって説明した処理と同様なので、その図示および説明は省略する。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内のサプライコール実行中フラグの状態をチェックし、そのサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図17のステップS8以降の処理と同様の処理を行う。
なお、SCS306による転写紙正常排紙時の処理およびトナーフル時の処理はそれぞれ、図37,図38によって説明した処理と同様なので、その図示および説明は省略する。
第1実施例によれば、以下の(1)〜(10)にそれぞれ示す作用効果を得ることができる。
(1)画像形成装置100(又は110)が、自己でのトナーニアエンド(異常事前事象)の発生によってそのトナーニアエンドを検出した場合に、そのトナーニアエンドの発生(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)を管理装置102へ送信(通報)するが、その際にトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“1”にセットする(事象情報送信中状態に設定する)ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、トナーサプライコール情報の送信の実行中に自己の主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。
(1)画像形成装置100(又は110)が、自己でのトナーニアエンド(異常事前事象)の発生によってそのトナーニアエンドを検出した場合に、そのトナーニアエンドの発生(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)を管理装置102へ送信(通報)するが、その際にトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“1”にセットする(事象情報送信中状態に設定する)ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、トナーサプライコール情報の送信の実行中に自己の主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。
(2)画像形成装置100が、トナーサプライコール情報を管理装置102へ送信する際に、その送信を識別するコールIDを生成し、それをそのトナーサプライコール情報に付加することにより、管理装置102側で画像形成装置100から重複送信(例えば2重送信)された同一のトナーサプライコール情報を容易に把握できるため、トナーボトルの重複発注を防止することもできる。
(3)画像形成装置100が、管理装置102へのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、サプライコール実行中フラグを“0”にリセットする(事象情報送信中状態を解除する)ことにより、以後そのSCコール済みフラグの状態を参照すれば、トナーサプライコール情報の送信が完了したことを確認することができる。
(3)画像形成装置100が、管理装置102へのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、サプライコール実行中フラグを“0”にリセットする(事象情報送信中状態を解除する)ことにより、以後そのSCコール済みフラグの状態を参照すれば、トナーサプライコール情報の送信が完了したことを確認することができる。
(4)画像形成装置100が、管理装置102へのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、そのトナーサプライコール情報の送信が失敗したと判断し、その場合にそのトナーサプライコール情報と同一のトナーサプライコール情報の送信回数が予め設定された所定回数に達していない場合には、そのトナーサプライコール情報を再び管理装置102へ送信させ、そのトナーサプライコール情報の送信回数が上記所定回数に達した場合に、そのトナーサプライコール情報の再送信を停止する再送信(リトライ)制御を行うことにより、トナーサプライコール情報の送信の実行中に通信上のトラブルが発生した場合でも、そのトナーサプライコール情報の送信を完了させることが可能になる。
(5)画像形成装置100が、再送信制御によって再送信する同一のトナーサプライコール情報に、同一のコールID(そのサプライコール情報の初回送信時に生成したコールID)を繰り返し付加することにより、同一のトナーサプライコール情報を送信する毎に異なるコールIDを生成する処理を行わなくて済むため、その分だけ処理効率が向上する。
(6)画像形成装置100が、再送信制御によってトナーサプライコール情報の再送信を停止した後、管理装置102へのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する(操作パネル205上への表示や用紙への画像形成によって報知してもよい)ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、トナーサプライコール情報(トナーボトルの発注)の内容を電話によってセンタオペレータに伝えることができる。つまり、トナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。
(6)画像形成装置100が、再送信制御によってトナーサプライコール情報の再送信を停止した後、管理装置102へのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する(操作パネル205上への表示や用紙への画像形成によって報知してもよい)ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、トナーサプライコール情報(トナーボトルの発注)の内容を電話によってセンタオペレータに伝えることができる。つまり、トナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。
(7)画像形成装置100が、管理装置102へのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知した後、その旨を示すメール送信済みフラグを“1”にセットし(報知済み状態に設定し)、その報知を禁止することにより、その報知の重複を回避でき、その分だけ処理効率が向上する。
(8)画像形成装置100が、メール送信済みフラグを“1”にセットした後、新たにトナーニアエンドを検出した場合には、メール送信済みフラグを“0”にリセットし(報知済み状態を解除し)、上記報知の禁止を解除することにより、再び管理装置102へのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、トナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。
(8)画像形成装置100が、メール送信済みフラグを“1”にセットした後、新たにトナーニアエンドを検出した場合には、メール送信済みフラグを“0”にリセットし(報知済み状態を解除し)、上記報知の禁止を解除することにより、再び管理装置102へのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、トナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。
(9)画像形成装置100が、24Hタイマ(24時間が予め設定されている)に時間計測を開始させ、24Hタイマによる計測時間が24時間(予め設定された所定時間)を経過した場合に、上述と同様の再送信制御を再度行うことにより、トナーサプライコール情報をセンタオペレータにより一層確実に伝えることができる。なお、24Hタイマ以外のタイマ(24時間以外の所定時間が予め設定されている)を利用することもできる。
(10)画像形成装置100が、主電源ON(電源投入)時にサプライコール実行中フラグの状態(セットの有無)を調べ、そのサプライコール実行中フラグが“1”にセットされていると確認できた場合に、管理装置102へのトナーサプライコール情報の送信が成功していないと判断し、その場合にも上述と同様の再送信制御を行うことにより、管理装置102へのトナーサプライコール情報の送信実行中に自己の主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった時に、その実行中だったトナーサプライコール情報の送信を自動的に再開することができる。よって、トナーサプライコール情報の内容を最速で確実にセンタオペレータに伝えることができる。
なお、主電源ON時にサプライコール実行中フラグの状態を調べ、そのサプライコール実行中フラグが“1”にセットされていると確認できた場合に、管理装置102へのトナーサプライコール情報の送信が成功していないと判断し、その旨を操作パネル205上への表示や用紙への画像形成等によって報知することもできる。そして、この報知を行う場合、例えば操作パネル205上の操作等により、実行中だったトナーサプライコール情報の送信を再開させることもできる。
〔第2実施例〕
図20は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド発生時の通信シーケンスの第3例を示す図である。図21は、NV−RAM202内の2種類のサプライコール実行中フラグの状態を示す説明図である。なお、図20の黒トナーコール処理および赤トナーコール処理はいずれも、第1実施例で説明した処理と略同様なので、内容の詳細は省略する。異なる点は、各種フラグやカウンタ等がトナー色別に存在し、そのトナー色別に処理を行うことである。
画像形成装置100のプロッタエンジン内で黒トナーボトルのトナーニアエンド(黒トナーニアエンド)が発生した場合(黒トナーサプライである黒トナーボトル内のトナー量が所定量以下になった場合)、対応する事象検出部が黒トナーニアエンドを検出し、黒トナーニアエンドが発生した旨をコントローラボード200のSCS306へ通知する。
図20は、この画像形成装置遠隔管理システムにおける画像形成装置100でのトナーニアエンド発生時の通信シーケンスの第3例を示す図である。図21は、NV−RAM202内の2種類のサプライコール実行中フラグの状態を示す説明図である。なお、図20の黒トナーコール処理および赤トナーコール処理はいずれも、第1実施例で説明した処理と略同様なので、内容の詳細は省略する。異なる点は、各種フラグやカウンタ等がトナー色別に存在し、そのトナー色別に処理を行うことである。
画像形成装置100のプロッタエンジン内で黒トナーボトルのトナーニアエンド(黒トナーニアエンド)が発生した場合(黒トナーサプライである黒トナーボトル内のトナー量が所定量以下になった場合)、対応する事象検出部が黒トナーニアエンドを検出し、黒トナーニアエンドが発生した旨をコントローラボード200のSCS306へ通知する。
SCS306は、プロッタエンジンから黒トナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内で黒トナーニアエンドが発生したと判定して(つまりトナーニアエンドが発生したと判定すると共にそのトナーニアエンドの種類を判別して)、NV−RAM202内の黒トナーサプライコール済みフラグおよび黒トナーサプライコール後通紙枚数カウンタ(黒トナーコール後通紙枚数カウンタ)の値をそれぞれチェックし、黒トナーサプライコール済みフラグが“0”にリセットされ、且つ黒トナーコール後通紙枚数カウンタの値が「1000」以上になっている(但し機器が一度も黒トナーサプライコールを行っていない場合には本条件を無視する)場合には、黒トナーサプライコール発行条件を満足しているものと判定する。
そして、NV−RAM202内の黒トナーメール送信済みフラグを“0”にリセットした後、NV−RAM内のトナーサプライコールリトライ回数カウンタ(リトライ回数カウンタ)に「3」をセットし、黒トナーサプライコール(黒トナーニアエンドの発生つまりトナーボトルの発注を知らせる黒トナーサプライコール情報の自動通報)を識別するコールIDを生成して、そのコールIDをNV−RAM202に保存し、黒トナーサプライコールの実行中を示す黒トナーサプライコール実行中フラグ(事象情報送信中状態)を“1”にセット(設定)した後、黒トナーサプライコール要求をNRS305へ通知する。このとき、トナーサプライコール要求に、画像形成装置100の識別情報である機番情報,NV−RAM202に保存したコールID,および判別したトナーニアエンド(又はそれに対応するトナーサプライコール)の種類を示す情報(コールタイプ)を付加する。また、操作パネル205上の文字表示器には、「黒トナーサプライコール中」のメッセージを表示する。
NRS305は、黒トナーサプライコール要求の通知を受けると、黒トナーボトルの発注(黒トナーニアエンドの発生)を知らせる黒トナーサプライコール情報である黒トナーサプライコール用のSOAPメッセージ(黒トナーサプライコール要求に付加された機番情報,コールID,コールタイプを含む)を生成して、それを仲介装置101へ送信する。
仲介装置101は、NRS305から黒トナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対して黒トナーサプライコールを行う。つまり、自己の仲介装置識別子を付加した黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
仲介装置101は、NRS305から黒トナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに自己の識別情報である仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対して黒トナーサプライコールを行う。つまり、自己の仲介装置識別子を付加した黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
管理装置102は、いずれかの機器利用者側の仲介装置101から通報された黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージを受信し、その受信が正常に終了した場合に、その受信したHTTPメッセージ内のSOAPメッセージに付加された機番情報および仲介装置識別子に基づいて、そのHTTPメッセージの受信が正常に終了した旨(黒トナーサプライコールに対する処理が成功した旨)のコール結果であるコールOKを示すSOAPメッセージを含むHTTPメッセージを生成し、インタネット103経由で通報元の仲介装置101(黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージを送信した仲介装置101)へ送信する。
また、受信したHTTPメッセージ内のSOAPメッセージ(黒トナーサプライコール情報)をキューに格納し、センタオペレータによって対応する処理、つまり黒トナーボトルの受注作業が行われるまでキューイングする。
さらに、受信したHTTPメッセージ内のSOAPメッセージの内容を操作者端末604の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末604の表示部の表示内容を見て通報元の仲介装置101に接続されている画像形成装置100のプロッタエンジン内で黒トナーニアエンドが発生し、黒トナーボトルが発注されたことを認識すると、黒トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置101の設置場所に黒トナーボトルを届けさせる。
さらに、受信したHTTPメッセージ内のSOAPメッセージの内容を操作者端末604の表示部に表示してセンタオペレータに知らせる。
センタオペレータは、操作者端末604の表示部の表示内容を見て通報元の仲介装置101に接続されている画像形成装置100のプロッタエンジン内で黒トナーニアエンドが発生し、黒トナーボトルが発注されたことを認識すると、黒トナーボトルの受注作業を行い、例えばサービスマンを手配して通報元の仲介装置101の設置場所に黒トナーボトルを届けさせる。
仲介装置101は、管理装置102への黒トナーサプライコール(黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージの自動通報)の結果として、その管理装置102からコールOK(上記HTTPメッセージの受信が正常に終了した旨のコール結果)を示すSOAPメッセージを含むHTTPメッセージを受信すると、そのHTTPメッセージに基づいてコールOKを示すSOAPメッセージを生成し、それを該当する(黒トナーニアエンドが発生した)画像形成装置100のNRS305へ送信する。
そのNRS305は、仲介装置101からコールOKを示すSOAPメッセージを受信すると、SCS306へコールOK(黒トナーサプライコールが正常に終了した旨)を通知する。
そのNRS305は、仲介装置101からコールOKを示すSOAPメッセージを受信すると、SCS306へコールOK(黒トナーサプライコールが正常に終了した旨)を通知する。
SCS306は、NRS305からコールOKの通知を受けると、管理装置102への黒トナーサプライコールが成功したと判断し、操作パネル205上の文字表示器に「黒トナーサプライコール成功」のメッセージを表示する。
また、NV−RAM202内の黒トナーサプライコール実行中フラグを“0”にリセット(解除)し、NV−RAM202内の黒トナーサプライコールの成功を示す黒トナーサプライコール済みフラグ(事象送信済み状態)を“1”にセットする。
さらに、NV−RAM202内の黒トナーコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし、「0」からカウント動作を行えるようにする。
また、NV−RAM202内の黒トナーサプライコール実行中フラグを“0”にリセット(解除)し、NV−RAM202内の黒トナーサプライコールの成功を示す黒トナーサプライコール済みフラグ(事象送信済み状態)を“1”にセットする。
さらに、NV−RAM202内の黒トナーコール後通紙枚数カウンタの値およびリトライ回数カウンタの値をいずれも「0」にリセットし、「0」からカウント動作を行えるようにする。
画像形成装置100のプロッタエンジン内の黒トナーボトルが交換され、黒トナーフルが発生した場合(黒トナーボトル内のトナー量が満杯になった場合)、対応する事象検出部が、黒トナーフルを検出し、黒トナーフルが発生した旨をSCS306へ通知する。
SCS306は、プロッタエンジンから黒トナーフルが発生した旨の通知を受けると、NV−RAM202内の黒トナーサプライコール済みフラグを“0”にリセットし、次の黒トナーニアエンドでサプライコールを行えるようにする。但し、黒トナーコール後通紙枚数カウンタの値が「1000」にならないと、黒トナーサプライコールを行うことはない。
SCS306は、プロッタエンジンから黒トナーフルが発生した旨の通知を受けると、NV−RAM202内の黒トナーサプライコール済みフラグを“0”にリセットし、次の黒トナーニアエンドでサプライコールを行えるようにする。但し、黒トナーコール後通紙枚数カウンタの値が「1000」にならないと、黒トナーサプライコールを行うことはない。
一方、通報元の仲介装置101は、サービスセンタの管理装置102への黒トナーサプライコール(黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージの自動通報)の結果として、その管理装置102からコールOK(上記HTTPメッセージの受信が正常に終了した旨のコール結果)を示すSOAPメッセージを含むHTTPメッセージを規定時間が経過しても受信できなかった場合、そのHTTPメッセージに基づいてコールNGを示すSOAPメッセージを生成し、それを該当する画像形成装置100のNRS305へ送信する。
そのNRS305は、仲介装置101からコールNGを示すSOAPメッセージを受信すると、SCS306へコールNG(黒トナーサプライコールが正常に終了しなかった旨)を通知する。
そのNRS305は、仲介装置101からコールNGを示すSOAPメッセージを受信すると、SCS306へコールNG(黒トナーサプライコールが正常に終了しなかった旨)を通知する。
SCS306は、NRS305からコールNGの通知を受けると、管理装置102への黒トナーサプライコールが失敗したと判断し、操作パネル205上の文字表示器に「黒トナーサプライコール失敗」のメッセージを表示する。
また、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)し、初回コール(初回通報)時と同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、リトライ(再通報)制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一の黒トナーサプライコールの回数が予め設定された所定回数である3回に達していない場合)に、再び初回コール時と同一の黒トナーサプライコール要求をNRS305へ通知する。このとき、その黒トナーサプライコール要求に、NV−RAM202に保存しておいた初回コール時と同一のコールIDを付加する。
また、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)し、初回コール(初回通報)時と同一のトナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、リトライ(再通報)制御を行う。
すなわち、まずリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一の黒トナーサプライコールの回数が予め設定された所定回数である3回に達していない場合)に、再び初回コール時と同一の黒トナーサプライコール要求をNRS305へ通知する。このとき、その黒トナーサプライコール要求に、NV−RAM202に保存しておいた初回コール時と同一のコールIDを付加する。
NRS305は、SCS306から初回コール時と同一の黒トナーサプライコール要求の通知を受けると、初回コール時と同一の黒トナーサプライコール用のSOAPメッセージを生成して、それを仲介装置101へ送信する。
仲介装置101は、NRS305から初回コール時と同一の黒トナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに再び自己の仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対して黒トナーサプライコールを行う。つまり、自己の識別子を付加した黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
仲介装置101は、NRS305から初回コール時と同一の黒トナーサプライコール用のSOAPメッセージを受信すると、そのSOAPメッセージに再び自己の仲介装置識別子を付加し、更にそのSOAPメッセージに基づいてHTTPメッセージを生成し、インタネット103経由で管理装置102に対して黒トナーサプライコールを行う。つまり、自己の識別子を付加した黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージをインタネット103経由でサービスセンタの管理装置102へ自動通報する。
その後、サービスセンタの管理装置102への黒トナーサプライコールの結果として、その管理装置102からコールOKを示すSOAPメッセージを含むHTTPメッセージを規定時間が経過しても受信できなかった場合、再びそのHTTPメッセージに基づいてコールNGを示すSOAPメッセージを生成し、それを該当する画像形成装置100のNRS305へ送信する。
そのNRS305は、仲介装置101から再びコールNGを示すSOAPメッセージを受信すると、SCS306へコールNGを通知する。
そのNRS305は、仲介装置101から再びコールNGを示すSOAPメッセージを受信すると、SCS306へコールNGを通知する。
SCS306は、NRS305から再びコールNGの通知を受けると、管理装置102への黒トナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合に、再び初回コール時と同一の黒トナーサプライコール要求をNRS305へ通知し、以後上述と同様の処理を行う。
その後、NRS305から再びコールNGの通知を受けると、管理装置102への黒トナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックすると、その値が「0」になっている(同一の黒トナーサプライコールの回数が3回に達した)ため、上述したリトライ(再送信)を停止し、以下に示す処理を行う。
その後、NRS305から再びコールNGの通知を受けると、管理装置102への黒トナーサプライコールが失敗したと判断し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後、そのリトライ回数カウンタの値をチェックすると、その値が「0」になっている(同一の黒トナーサプライコールの回数が3回に達した)ため、上述したリトライ(再送信)を停止し、以下に示す処理を行う。
すなわち、NV−RAM202内の黒トナーメール送信済みフラグの状態をチェックし、その黒トナーメール送信済みフラグが“0”になっていると確認できた場合に、管理装置102への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知する。このとき、その電子メール送信要求に、画像形成装置100の機番情報,初回コール時と同一のコールID,およびコールタイプを付加する。そして、その電子メール送信要求をDCS316へ通知した後、NV−RAM202内の黒トナーメール送信済みフラグを“1”にセットした後、24Hタイマを起動させる。
DCS316は、SCS306から電子メール送信要求の通知を受けると、管理装置102への黒トナーサプライコールが失敗した旨を報知するための電子メールをLAN経由で図示しないサプライ管理端末へ送信する。
DCS316は、SCS306から電子メール送信要求の通知を受けると、管理装置102への黒トナーサプライコールが失敗した旨を報知するための電子メールをLAN経由で図示しないサプライ管理端末へ送信する。
黒トナーニアエンドが発生した画像形成装置100のコントローラボード200のSCS306は、24Hタイマを起動させた後、その24Hタイマによる計測時間が24時間を経過すると、再びリトライ回数カウンタに「3」をセットした後、初回コール時と同一の黒トナーサプライコール用のSOAPメッセージを含むHTTPメッセージを再通報するために、再び上述と同様のリトライ制御を行う。
このリトライ制御を行っても、管理装置102への黒トナーサプライコールが3回失敗した場合には、再びリトライを停止し、NV−RAM202内の黒トナーメール送信済みフラグの状態をチェックするが、この場合には黒トナーメール送信済みフラグが既に“1”にセットされているため、管理装置102への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知しない(電子メール送信の通知を禁止する)。しかし、24Hタイマは再起動させ、以後管理装置102への黒トナーサプライコールが成功するまで上述と同様の制御を繰り返す。
ところで、管理装置102への黒トナーサプライコールの実行中に、本体主電源がOFF/ONした場合(本体主電源が一旦遮断した後再投入された場合)には、NV−RAM202内の黒トナーサプライコール実行中フラグの状態をチェックし、その黒トナーサプライコール実行中フラグが“0”にリセットされていると確認できた場合には何もしないが、“1”にセットされていると確認できた場合には、管理装置102への黒トナーサプライコールの実行中に本体主電源がOFF/ONし、そのトナーサプライコールが成功していないため、上述と同様のリトライ制御を行う。
そして、このリトライ制御を行っても、管理装置102への黒トナーサプライコールが3回失敗した場合には、リトライを停止し、NV−RAM202内の黒トナーメール送信済みフラグの状態をチェックし、そのチェック結果に応じて上述と同様の制御を行う。
そして、このリトライ制御を行っても、管理装置102への黒トナーサプライコールが3回失敗した場合には、リトライを停止し、NV−RAM202内の黒トナーメール送信済みフラグの状態をチェックし、そのチェック結果に応じて上述と同様の制御を行う。
一方、画像形成装置100のプロッタエンジン内で赤トナーボトルのトナーニアエンド(赤トナーニアエンド)が発生した場合(赤トナーサプライである赤トナーボトル内のトナー量が所定量以下になった場合)、対応する事象検出部が赤トナーニアエンドを検出し、赤トナーニアエンドが発生した旨をコントローラボード200のSCS306へ通知する。
SCS306は、プロッタエンジンから赤トナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内で赤トナーニアエンドが発生したと判定する(つまりトナーニアエンドが発生したと判定すると共にそのトナーニアエンドの種類を判別する)。
以後、画像形成装置100,仲介装置101,および管理装置102は、黒トナーニアエンドが発生した場合と略同様の処理を行うため、その説明を省略する。
SCS306は、プロッタエンジンから赤トナーニアエンドが発生した旨の通知を受けると、そのプロッタエンジン内で赤トナーニアエンドが発生したと判定する(つまりトナーニアエンドが発生したと判定すると共にそのトナーニアエンドの種類を判別する)。
以後、画像形成装置100,仲介装置101,および管理装置102は、黒トナーニアエンドが発生した場合と略同様の処理を行うため、その説明を省略する。
図22〜図25は、画像形成装置100のコントローラボード200のSCS306によるトナーニアエンド発生時の処理の他の概略例を示すフローチャートである。
画像形成装置100のSCS306は、プロッタエンジンから黒又は赤トナーニアエンドが発生した旨の通知を受けると、トナーニアエンドが発生したと判定して図22〜図25の処理ルーチンを開始し、まずステップS31でそのトナーニアエンドの種類を判別する。
画像形成装置100のSCS306は、プロッタエンジンから黒又は赤トナーニアエンドが発生した旨の通知を受けると、トナーニアエンドが発生したと判定して図22〜図25の処理ルーチンを開始し、まずステップS31でそのトナーニアエンドの種類を判別する。
そして、発生したトナーニアエンドが黒トナーニアエンドであると確認できた場合には、ステップS32でNV−RAM202の黒トナーサプライコール済みフラグの状態をチェックし、その黒トナーサプライコール済みフラグが“0”にリセットされていると確認できた場合にステップS33へ進み、画像形成装置100の納入後、初めて黒トナーサプライコールを行うか否かを判断し、そうであれば(初めて黒トナーニアエンドが発生した場合には)そのままステップS35へ進むが、初めて黒トナーサプライコールを行うのでなければステップS34でNV−RAM202内の黒トナーコール後通紙枚数カウンタの値が「1000」に達したか否かを判断し、「1000」に達していればステップS35へ進み、コールIDを生成する。
次に、ステップS36で生成したコールIDをNV−RAM202に保存し、ステップS37でNV−RAM202内の黒トナーサプライコール実行中フラグを“1”にセットし、ステップS38でNV−RAM202内の黒トナーメール送信済みフラグを“0”にリセットし、ステップS39でNV−RAM202内のリトライ回数カウンタに「3」をセットした後、ステップS40でトナーサプライコール要求に画像形成装置100の機番情報,NV−RAM202に保存したコールID,および判別したトナーニアエンド(又はそれに対応するトナーサプライコール)の種類を付加して、黒トナーサプライコール要求とし、それをNRS305へ通知する。
その後、ステップS10でNRS305からの通知の有無をチェックし、NRS305からコールOKの通知を受けた場合には、管理装置102への黒トナーサプライコールが成功したと判断してステップS42へ移行し、後述する処理を行う。
その後、ステップS10でNRS305からの通知の有無をチェックし、NRS305からコールOKの通知を受けた場合には、管理装置102への黒トナーサプライコールが成功したと判断してステップS42へ移行し、後述する処理を行う。
NRS305からコールNGの通知を受けた場合には、管理装置102への黒トナーサプライコールが失敗したと判断してステップS46へ移行し、NV−RAM202内のリトライ回数カウンタをデクリメント(−1)した後、ステップS47でそのリトライ回数カウンタの値をチェックし、その値が「0」になっていない場合(同一の黒トナーサプライコールの回数が3回に達していない場合)にステップS40へ戻り、再び初回コール時と同一の黒トナーサプライコール要求をNRS305へ通知し(トナーサプライコール要求に画像形成装置100の機番情報,NV−RAM202に保存しておいた初回コール時と同一のコールID,判別したトナーニアエンドの種類を付加して黒トナーサプライコール要求とする)、以後上述と同様の処理を繰り返す。そして、リトライ回数カウンタの値が「0」になったら、次の処理を行う。
すなわち、図24のステップS48でNV−RAM202内の黒トナーメール送信済みフラグの状態をチェックし、その黒トナーメール送信済みフラグが“1”にセットされていると確認できた場合にはそのままステップS51へ移行するが、“0”にリセットされていると確認できた場合にはステップS49で管理装置102への黒トナーサプライコールが失敗した旨を報知するための電子メール送信要求をDCS316へ通知する。このとき、その電子メール送信要求に、画像形成装置100の機番情報,初回コール時と同一のコールID,判別したトナーニアエンド(又はそれに対応するトナーサプライコール)の種類を付加する。そして、その電子メール送信要求をDCS316へ通知した後、ステップS50でNV−RAM202内の黒トナーメール送信済みフラグを“1”にセットした後、ステップS20で24時間タイマを起動させ、その24時間タイマによる計測時間が24時間経過するのを待って、図22のステップS39へ戻り、上述と同様の処理を繰り返す。
リトライ回数カウンタの値が「0」になる前に、ステップS41で管理装置102への黒トナーサプライコールが成功したと判断した場合には、ステップS42でNV−RAM202内の黒トナーサプライコール済みフラグを“1”にセットし、ステップS43でNV−RAM202内の黒トナーコール後通紙枚数カウンタの値を、ステップS44でリトライ回数カウンタの値をそれぞれ「0」にリセットした後、ステップS45でNV−RAM202内の黒トナーサプライコール実行中フラグを“0”にリセットし、図22〜図25の処理を終了する。
一方、発生したトナーニアエンドが赤トナーニアエンドであると確認できた場合には、ステップS52でNV−RAM202の赤トナーサプライコール済みフラグの状態をチェックし、その赤トナーサプライコール済みフラグが“0”にリセットされていると確認できた場合にステップS53へ進み、画像形成装置100の納入後、初めて赤トナーサプライコールを行うか否かを判断し、そうであれば(初めて赤トナーニアエンドが発生した場合には)そのままステップS55へ進むが、初めて赤トナーサプライコールを行うのでなければステップS54でNV−RAM202内の赤トナーコール後通紙枚数カウンタの値が「1000」に達したか否かを判断し、「1000」に達していればステップS55へ進み、コールIDを生成する。
以後、ステップ56〜S71で、前述したステップ36〜S51と略同様の処理を行う(但しフラグやカウンタが異なる)ため、その説明を省略する。
以後、ステップ56〜S71で、前述したステップ36〜S51と略同様の処理を行う(但しフラグやカウンタが異なる)ため、その説明を省略する。
図26は、画像形成装置100のコントローラボード200のSCS306による転写紙正常排紙時の処理の概略例を示すフローチャートである。
SCS306は、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、図26の処理ルーチンを開始し、転写紙への画像形成(プリント)に赤トナーを使用した場合には赤トナーコール後通紙枚数カウンタを、転写紙への画像形成に黒トナーを使用した場合には黒トナーコール後通紙枚数カウンタをそれぞれインクリメント(+1)する。
SCS306は、画像形成がなされた転写紙が機外に正常に排紙され、その排紙が事象検出部によって検出されると、図26の処理ルーチンを開始し、転写紙への画像形成(プリント)に赤トナーを使用した場合には赤トナーコール後通紙枚数カウンタを、転写紙への画像形成に黒トナーを使用した場合には黒トナーコール後通紙枚数カウンタをそれぞれインクリメント(+1)する。
図27は、画像形成装置100のコントローラボード200のSCS306による黒トナーフル時の処理の概略例を示すフローチャートである。
SCS306は、トナーボトルの交換により黒トナーフルが発生し、その黒トナーフルが対応する事象検出部によって検出されて、黒トナーフルが発生した旨の通知を受けた場合に、NV−RAM202内の黒トナーサプライコール済みフラグを“0”にリセットする。
図28は、画像形成装置100のコントローラボード200のSCS306による赤トナーフル時の処理の概略例を示すフローチャートである。
SCS306は、トナーボトルの交換により赤トナーフルが発生し、その赤トナーフルが対応する事象検出部によって検出されて、赤トナーフルが発生した旨の通知を受けた場合に、NV−RAM202内の赤トナーサプライコール済みフラグを“0”にリセットする。
SCS306は、トナーボトルの交換により黒トナーフルが発生し、その黒トナーフルが対応する事象検出部によって検出されて、黒トナーフルが発生した旨の通知を受けた場合に、NV−RAM202内の黒トナーサプライコール済みフラグを“0”にリセットする。
図28は、画像形成装置100のコントローラボード200のSCS306による赤トナーフル時の処理の概略例を示すフローチャートである。
SCS306は、トナーボトルの交換により赤トナーフルが発生し、その赤トナーフルが対応する事象検出部によって検出されて、赤トナーフルが発生した旨の通知を受けた場合に、NV−RAM202内の赤トナーサプライコール済みフラグを“0”にリセットする。
図29は、画像形成装置100のコントローラボード200のSCS306による主電源ON時の他の処理例の一部を示すフローチャートである。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内の黒トナーサプライコール実行中フラグの状態をチェックし、その黒トナーサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図22のステップS39以降の処理と同様の処理を行う。
図30は、画像形成装置100のコントローラボード200のSCS306による主電源ON時の更に他の処理例の一部を示すフローチャートである。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内の赤トナーサプライコール実行中フラグの状態をチェックし、その赤トナーサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図23のステップS59以降の処理と同様の処理を行う。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内の黒トナーサプライコール実行中フラグの状態をチェックし、その黒トナーサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図22のステップS39以降の処理と同様の処理を行う。
図30は、画像形成装置100のコントローラボード200のSCS306による主電源ON時の更に他の処理例の一部を示すフローチャートである。
画像形成装置100のSCS306は、主電源ON時にNV−RAM202内の赤トナーサプライコール実行中フラグの状態をチェックし、その赤トナーサプライコール実行中フラグが“1”にセットされていると確認できた場合にのみ、図23のステップS59以降の処理と同様の処理を行う。
第2実施例によれば、以下の(1)〜(10)にそれぞれ示す作用効果を得ることができる。
(1)画像形成装置100(又は110)が、自己でのトナーニアエンド(異常事前事象)の発生によってそのトナーニアエンドを検出した場合に、その種類を判別し、そのトナーニアエンドの発生(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)にそのトナーニアエンドの種類を示す情報を付加して管理装置102へ送信(通報)するが、その際に対応するトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“1”にセットする(事象情報送信中状態に設定する)ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信の実行中に自己の主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。
(1)画像形成装置100(又は110)が、自己でのトナーニアエンド(異常事前事象)の発生によってそのトナーニアエンドを検出した場合に、その種類を判別し、そのトナーニアエンドの発生(トナーボトルの発注)を知らせるトナーサプライコール情報(事前事象情報)にそのトナーニアエンドの種類を示す情報を付加して管理装置102へ送信(通報)するが、その際に対応するトナーサプライコール情報の送信の実行中を示すサプライコール実行中フラグを“1”にセットする(事象情報送信中状態に設定する)ことにより、以後そのサプライコール実行中フラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信の実行中に自己の主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった後、その実行中だったトナーサプライコール情報の送信を再開することが可能になる。
(2)画像形成装置100が、いずれかのトナーサプライコール情報を管理装置102へ送信する際に、その送信を識別するコールIDを生成し、それをそのトナーサプライコール情報に付加することにより、管理装置102側で画像形成装置100から重複送信(例えば2重送信)された同一のトナーサプライコール情報をトナーの種類別に容易に把握できるため、黒トナーボトル又は赤トナーボトルの重複発注を防止することもできる。
(3)画像形成装置100が、管理装置102へのいずれかのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、対応するサプライコール実行中フラグを“0”にリセットする(事象情報送信中状態を解除する)ことにより、以後そのSCコール済みフラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信が完了したことを確認することができる。
(3)画像形成装置100が、管理装置102へのいずれかのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信した場合に、そのトナーサプライコール情報の送信が成功したと判断して、対応するサプライコール実行中フラグを“0”にリセットする(事象情報送信中状態を解除する)ことにより、以後そのSCコール済みフラグの状態を参照すれば、いずれかのトナーサプライコール情報の送信が完了したことを確認することができる。
(4)画像形成装置100が、管理装置102へのいずれかのトナーサプライコール情報の送信結果として、管理装置102からそのトナーサプライコール情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、そのトナーサプライコール情報の送信が失敗したと判断し、その場合にそのトナーサプライコール情報と同一のトナーサプライコール情報の送信回数が予め設定された所定回数に達していない場合には、そのトナーサプライコール情報を再び管理装置102へ送信させ、そのトナーサプライコール情報の送信回数が上記所定回数に達した場合に、そのトナーサプライコール情報の再送信を停止する再送信(リトライ)制御を行うことにより、いずれかのトナーサプライコール情報の送信の実行中に通信上のトラブルが発生した場合でも、そのトナーサプライコール情報の送信を完了させることが可能になる。
(5)画像形成装置100が、再送信制御によって再送信する同一のトナーサプライコール情報に、同一のコールID(そのサプライコール情報の初回送信時に生成したコールID)を繰り返し付加することにより、同一のトナーサプライコール情報を送信する毎に異なるコールIDを生成する処理を行わなくて済むため、その分だけ処理効率が向上する。
(6)画像形成装置100が、再送信制御によっていずれかのトナーサプライコール情報の再送信を停止した後、管理装置102へのそのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する(操作パネル205上への表示や用紙への画像形成によって報知してもよい)ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、そのトナーサプライコール情報(黒トナーボトル又は赤トナーボトルの発注)の内容を電話によってセンタオペレータに伝えることができる。つまり、いずれかのトナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。
(6)画像形成装置100が、再送信制御によっていずれかのトナーサプライコール情報の再送信を停止した後、管理装置102へのそのトナーサプライコール情報の送信が失敗した旨を電子メールによってサプライ管理端末に報知する(操作パネル205上への表示や用紙への画像形成によって報知してもよい)ことにより、そのサプライ管理端末を使用しているサプライ管理担当者がその報知内容を参照すれば、そのトナーサプライコール情報(黒トナーボトル又は赤トナーボトルの発注)の内容を電話によってセンタオペレータに伝えることができる。つまり、いずれかのトナーサプライコール情報の内容を確実にセンタオペレータに伝えることができる。
(7)画像形成装置100が、管理装置102へのいずれかのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知した後、その旨を示すいずれかのメール送信済みフラグを“1”にセットし(報知済み状態に設定し)、その報知を禁止することにより、その報知の重複を回避でき、その分だけ処理効率が向上する。
(8)画像形成装置100が、メール送信済みフラグを“1”にセットした後、新たに前回と同じトナーニアエンドを検出した場合には、対応するメール送信済みフラグを“0”にリセットし(報知済み状態を解除し)、上記報知の禁止を解除することにより、再び管理装置102へのいずれかのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、そのトナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。
(8)画像形成装置100が、メール送信済みフラグを“1”にセットした後、新たに前回と同じトナーニアエンドを検出した場合には、対応するメール送信済みフラグを“0”にリセットし(報知済み状態を解除し)、上記報知の禁止を解除することにより、再び管理装置102へのいずれかのトナーサプライコール情報の送信が失敗した旨を電子メールによって報知することが可能になるため、そのトナーサプライコール情報の内容をより確実にセンタオペレータに伝えることができる。
(9)画像形成装置100が、24Hタイマ(24時間が予め設定されている)に時間計測を開始させ、24Hタイマによる計測時間が24時間(予め設定された所定時間)を経過した場合に、上述と同様の再送信制御を再度行うことにより、いずれかのトナーサプライコール情報をセンタオペレータにより一層確実に伝えることができる。なお、24Hタイマ以外のタイマ(24時間以外の所定時間が予め設定されている)を利用することもできる。
(10)画像形成装置100が、主電源ON(電源投入)時に対応するサプライコール実行中フラグの状態(セットの有無)を調べ、そのサプライコール実行中フラグが“1”にセットされていると確認できた場合に、管理装置102への対応するトナーサプライコール情報の送信が成功していないと判断し、その場合にも上述と同様の再送信制御を行うことにより、管理装置102へのいずれかのトナーサプライコール情報の送信の実行中に主電源がOFFになってその実行中のトナーサプライコール情報の送信が中断された場合でも、主電源が再びONになった時に、その実行中だったトナーサプライコール情報の送信を自動的に再開することができる。よって、トナーサプライコール情報の内容をトナーの種類別に最速で確実にセンタオペレータに伝えることができる。
なお、第2実施例では、画像形成装置が、プロッタエンジンに黒トナーボトルと赤トナーボトルの2色のトナーボトルを備え、そのいずれかでのトナーニアエンド(異常事前事象)を検出した場合に、そのトナーニアエンドの発生(又はそれに対応するトナーボトルの発注)を知らせるトナーサプライコール情報(異常事前事象情報)を管理装置102へ送信するようにしたが、C(シアン)トナーボトル,M(マゼンタ)トナーボトル,Y(イエロー)トナーボトル,K(ブラック)トナーボトルの4色(フルカラー)のトナーボトルあるいは他の複数色のトナーボトルを備え、いずれかでのトナーニアエンドを検出した場合に、そのトナーニアエンドの発生(又はそれに対応するトナーボトルの発注)を知らせるトナーサプライコール情報を管理装置102へ送信するようにすることもできる。
また、上述した第1,第2実施例では、画像形成装置が、トナーニアエンドを検出した場合に、そのトナーニアエンドの発生を知らせるトナーサプライコール情報を管理装置102へ送信するようにしたが、トナーニアエンド以外の異常事前事象あるいはSC(サービスマンコール)等の異常事象等の通報要因となる事象を検出し、その事象の発生を知らせる事象情報を管理装置102へ送信するようにすることも勿論できる。
例えば、トナーニアエンド以外の異常事前事象としては、ステープル針のニアエンド(針数が所定数以下になったことを示す)やスタンプインクのニアエンド(インク量が所定量以下になったことを示す)があり、ステープル針のニアエンドを検出した場合にはそのニアエンド(又はそれに対応するステープル針の発注)を、スタンプインクのニアエンドを検出した場合にはそのニアエンドの発生(又はそれに対応するスタンプインクの発注)をそれぞれ知らせる情報を管理装置102へ送信する。ステープル針やスタンプインクの種類が複数種類ある場合には、いずれかのステープル針のニアエンドを検出した場合にはそのニアエンド(又はそれに対応するステープル針の発注)を、いずれかのスタンプインクのニアエンドを検出した場合にはそのニアエンドの発生(又はそれに対応するスタンプインクの発注)をそれぞれ知らせる情報を管理装置102へ送信する。
また、通信装置(電子装置)の例として通信機能(仲介機能)を持つ画像形成装置110および通信機能を果たす仲介装置101を接続した画像形成装置100について説明したが、この発明はこれらに限られるものではなく、通信機能を持つか、通信機能を果たす仲介装置を接続したネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種電子装置に適用可能である。また、これらの装置を被管理装置とした場合にも、遠隔管理システムを上述した場合と同様に動作させることができる。さらに、通信装置の遠隔管理システムについても、通信装置,遠隔管理仲介装置,管理装置の構成及びこれらの接続形式は、以上の実施例に限られるものではない。
例えば、図1に示した遠隔管理システムにおいて、上述した各種電子装置を被管理装置とし、図33に示すような遠隔管理システムを構成することが考えられる。この図33においては、仲介装置101を別途設ける被管理装置の例として、テレビ受像機12aや冷蔵庫12bのようなネットワーク家電、医療機器12c,自動販売機12d,計量システム12e,空調システム12fを挙げている。そして、仲介装置101の機能を併せ持つ被管理装置の例として、自動車13aや航空機13bを挙げている。また、自動車13aや航空機13bのように広範囲を移動する装置においては、ファイアウォール(FW)104の機能も併せ持つようにすることが好ましい。
また、この発明によるプログラムは、外部装置と通信を行う通信手段を備えた上述の画像形成装置等の通信装置を制御するコンピュータに、この発明による各機能(事象情報送信情報生成手段,事象情報送信手段,事象情報送信中状態設定手段,送信結果判断手段,事象情報送信中状態解除手段,送信失敗報知手段,報知済み状態設定手段,報知禁止手段,報知済み状態解除手段,報知禁止解除手段,時間計測手段,事象種判別手段としての機能)を実現させるためのプログラムであり、このようなプログラムをコンピュータに実行させることにより、上述したような効果を得ることができる。
このようなプログラムは、はじめからコンピュータに備えるROMあるいはHDD等の記憶手段に格納しておいてもよいが、記録媒体であるCD−ROMあるいはフレキシブルディスク,SRAM,EEPROM,メモリカード等の不揮発性記録媒体(メモリ)に記録して提供することもできる。そのメモリに記録されたプログラムをコンピュータにインストールしてCPUに実行させるか、CPUにそのメモリからこのプログラムを読み出して実行させることにより、上述した各手順を実行させることができる。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
さらに、ネットワークに接続され、プログラムを記録した記録媒体を備える外部機器あるいはプログラムを記憶手段に記憶した外部機器からダウンロードして実行させることも可能である。
この発明を、ネットワーク家電,自動販売機,医療機器,電源装置,空調システム,ガス・水道・電気等の計量システム等や、ネットワークに接続可能なコンピュータ等も含め、通信機能を備えた各種通信装置(被管理装置)、その通信装置とそれを管理する管理装置とからなる遠隔管理システムに適用可能である。
10:被管理装置 11:仲介機能付被管理装置 100:画像形成装置 101:仲介装置 102:管理装置 103:インタネット 104:ファイアウォール 110:仲介機能付画像形成装置 200:コントローラボード 201:HDD 202:NV−RAM 203:PIボード 204:PHY 205:操作パネル 206:プロッタ/スキャナエンジンボード 207:電源ユニット 212:PCI−BUS 300:OCS 301:ECS 302:MCS 303:NCS 304:FCS 305:NRS 306:SCS 307:SRM 308:IMH 309:コピーアプリ 310:ファクスアプリ 311:プリンタアプリ 312:スキャナアプリ 313:ネットファイルアプリ 314:ウェブアプリ 315:CSS 316:DCS 317:UCS 320:汎用OS 601:モデム 602:通信端末 603:プロキシサーバ 604:操作者端末 605:データベース 606:制御装置
Claims (27)
- 外部装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報を前記通信手段によって前記外部装置へ送信させる事象情報送信手段とを有する通信装置であって、
前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成手段を設け、
前記事象情報送信手段が、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して前記通信手段によって前記外部装置へ送信させる手段であることを特徴とする通信装置。 - 請求項1記載の通信装置において、
前記事象情報送信手段による前記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記事象情報送信手段は、前記送信結果判断手段によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする通信装置。 - 請求項2記載の通信装置において、
前記事象情報送信手段による前記再送信が停止した後、前記外部装置への事象情報の送信が失敗した旨を示す情報に、前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする通信装置。 - 請求項3記載の通信装置において、
前記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、
該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたことを特徴とする通信装置。 - 請求項4記載の通信装置において、
前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする通信装置。 - 請求項2乃至5のいずれか一項に記載の通信装置において、
時間計測を行なう時間計測手段を設け、
前記事象情報送信手段は、前記再送信を停止した後、前記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、前記再送信制御を再度行う手段を有することを特徴とする通信装置。 - 請求項1記載の通信装置において、
前記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、
前記事象情報送信手段は、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象種判別手段によって判別された事象の種類を示す情報および前記事象情報送信情報生成手段によって生成された事象情報送信情報を付加して前記通信手段によって前記外部装置へ送信させる手段であることを特徴とする通信装置。 - 請求項7記載の通信装置において、
前記事象情報送信手段による前記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記事象情報送信手段は、前記送信結果判断手段によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする通信装置。 - 請求項8記載の通信装置において、
前記事象情報送信手段による前記再送信が停止した後、前記外部装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする通信装置。 - 請求項9記載の通信装置において、
前記送信失敗報知手段によって前記外部装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、
該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたことを特徴とする通信装置。 - 請求項10記載の通信装置において、
前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする通信装置。 - 請求項1乃至11のいずれか一項に記載の通信装置において、
前記事象情報送信手段は、前記通信手段によって前記外部装置へ送信すべき情報を構造化言語形式に変換する手段を有することを特徴とする通信装置。 - 管理装置によってネットワークを介して複数の通信装置を遠隔管理する遠隔管理システムであって、
前記複数の通信装置にそれぞれ、前記管理装置と通信する通信手段と、異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出する事象検出手段と、該手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に自己の識別情報を付加して前記通信手段によって前記管理装置へ送信させる事象情報送信手段と、該手段によって前記管理装置へ事象情報が送信される際に、該事象情報の送信中を示す事象情報送信中状態に設定する事象情報送信中状態設定手段とを設け、
前記管理装置に、前記複数の通信装置と通信する通信手段と、該手段によっていずれかの通信装置から事象情報を受信し、該受信が正常に終了した場合に、その旨の送信結果を該事象情報に付加された識別情報に基づいて該事象情報を送信した通信装置へ前記通信手段によって送信させる送信結果送信手段とを設けたことを特徴とする遠隔管理システム。 - 請求項13記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記各通信装置の事象情報送信手段は、前記送信結果判断手段によって前記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同じ事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記管理装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする遠隔管理システム。 - 請求項14記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記再送信が停止した後、前記管理装置への事象情報の送信が失敗した旨を示す情報に、前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする遠隔管理システム。 - 請求項15記載の遠隔管理システムにおいて、
前記の通信装置にそれぞれ、前記送信失敗報知手段による報知がなされた場合に、該報知を行った旨を示す報知済み状態に設定する報知済み状態設定手段と、該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による報知を禁止する報知禁止手段とを設けたことを特徴とする遠隔管理システム。 - 請求項16記載の遠隔管理システムにおいて、
前記の通信装置にそれぞれ、前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする遠隔管理システム。 - 請求項14乃至17のいずれか一項に記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、時間計測を行なう時間計測手段を設け、
前記各通信装置の事象情報送信手段は、前記再送信を停止した後、前記時間計測手段に時間計測を開始させ、該時間計測手段による計測時間が予め設定された所定時間を経過した場合に、前記再送信制御を再度行う手段を有することを特徴とする遠隔管理システム。 - 請求項13記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象検出手段によって検出された事象の種類を判別する事象種判別手段を設け、
前記各通信装置の事象情報送信手段は、前記事象検出手段によって通報要因となる事象が検出された場合に、該事象の発生を知らせる事象情報に前記事象種判別手段によって判別された事象の種類を示す情報,前記事象情報送信情報生成手段によって生成された事象情報送信情報,および自己の識別情報を付加して前記通信手段によって前記管理装置へ送信させる手段であることを特徴とする遠隔管理システム。 - 請求項19記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記管理装置への事象情報の送信結果として該管理装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該管理装置への事象情報の送信が失敗したと判断する送信結果判断手段を設け、
前記各通信装置の事象情報送信手段は、前記送信結果判断手段によって前記管理装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記管理装置へ送信させ、該事象情報の送信回数が前記所定回数に達した場合に、該事象情報の再送信を停止する再送信制御を行う手段と、該手段によって再送信される同一の事象情報には前記事象情報送信情報生成手段によって生成された同一の事象情報送信情報を繰り返し付加する手段とを有することを特徴とする遠隔管理システム。 - 請求項20記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記事象情報送信手段による前記再送信が停止した後、前記管理装置への事象情報の送信が失敗した旨を示す情報に、対応する事象の種類を示す情報および前記事象情報送信手段によって再送信された同一の事象情報に繰り返し付加された同一の事象情報送信情報を付加して報知する送信失敗報知手段を設けたことを特徴とする遠隔管理システム。 - 請求項21記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記送信失敗報知手段によって前記管理装置への事象情報の送信が失敗した旨が報知された場合に、該報知を行った旨を示す報知済み状態に該事象情報に付加された事象の種類を示す情報を対応付けて設定する報知済み状態設定手段と、該手段によって前記報知済み状態が設定された場合に、前記送信失敗報知手段による該報知済み状態に対応する報知を禁止する報知禁止手段とを設けたことを特徴とする遠隔管理システム。 - 請求項22記載の遠隔管理システムにおいて、
前記複数の通信装置にそれぞれ、前記報知済み状態設定手段によって前記報知済み状態が設定された後、前記事象検出手段によって該報知済み状態に対応する通報要因となる事象が検出された場合に、該報知済み状態を解除する報知済み状態解除手段と、該手段によって前記報知済み状態が解除された場合に、前記報知禁止手段による該報知済み状態に対応する報知禁止を解除する報知禁止解除手段とを設けたことを特徴とする遠隔管理システム。 - 異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信する通信装置における送信要因発生時の制御方法であって、
通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成し、該事象情報に該事象情報送信情報を付加して前記外部装置へ送信することを特徴とする送信要因発生時の制御方法。 - 請求項24記載の送信要因発生時の制御方法において、
前記外部装置への事象情報の送信結果として該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断し、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には該事象情報を再び前記外部装置へ送信し、該事象情報の送信回数が前記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行い、この再送信制御時に前記再送信すべき同一の事象情報には前記生成した同一の事象情報送信情報を繰り返し付加することを特徴とする送信要因発生時の制御方法。 - 異常事象又は異常事前事象等の通報要因となる事象が発生した場合に、該事象を検出し、該事象の発生を知らせる事象情報を外部装置へ送信するようにした通信装置を制御するコンピュータに、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報の送信を識別する事象情報送信情報を生成する事象情報送信情報生成機能と、通報要因となる事象を検出した場合に、該事象の発生を知らせる事象情報に前記事象情報送信情報生成機能によって生成された事象情報送信情報を付加して前記外部装置へ送信する事象情報送信機能とを実現させるためのプログラム。
- 請求項26記載のプログラムにおいて、
前記コンピュータに、前記事象情報送信機能による前記外部装置への事象情報の送信結果として該外部装置への事象情報の送信に対して該外部装置から事象情報の受信が正常に終了した旨の送信結果を受信できなかった場合に、該外部装置への事象情報の送信が失敗したと判断する機能と、該機能によって前記外部装置への事象情報の送信が失敗したと判断された場合に、該事象情報と同一の事象情報の送信回数が予め設定された所定回数に達していない場合には、該事象情報を再び前記外部装置へ送信し、該事象情報の送信回数が前記所定回数に達した場合に該事象情報の再送信を停止する再送信制御を行う機能と、該機能によって再送信される同一の事象情報には前記事象情報送信情報生成機能によって生成された同一の事象情報送信情報を繰り返し付加する機能とを実現させるためのプログラムも含むプログラム。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2004005962A JP2004234650A (ja) | 2003-01-10 | 2004-01-13 | 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2003005135 | 2003-01-10 | ||
JP2004005962A JP2004234650A (ja) | 2003-01-10 | 2004-01-13 | 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2004234650A true JP2004234650A (ja) | 2004-08-19 |
Family
ID=32964709
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004005962A Pending JP2004234650A (ja) | 2003-01-10 | 2004-01-13 | 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2004234650A (ja) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008243057A (ja) * | 2007-03-28 | 2008-10-09 | Brother Ind Ltd | クライアント装置、デバイス、およびクライアント装置用プログラム |
CN104780286A (zh) * | 2014-01-10 | 2015-07-15 | 柯尼卡美能达株式会社 | 图像形成装置、信息终端装置、图像形成*** |
-
2004
- 2004-01-13 JP JP2004005962A patent/JP2004234650A/ja active Pending
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008243057A (ja) * | 2007-03-28 | 2008-10-09 | Brother Ind Ltd | クライアント装置、デバイス、およびクライアント装置用プログラム |
US9292802B2 (en) | 2007-03-28 | 2016-03-22 | Brother Kogyo Kabushiki Kaisha | Client apparatus configured to communicate with device and server via network |
CN104780286A (zh) * | 2014-01-10 | 2015-07-15 | 柯尼卡美能达株式会社 | 图像形成装置、信息终端装置、图像形成*** |
JP2015133559A (ja) * | 2014-01-10 | 2015-07-23 | コニカミノルタ株式会社 | 画像形成装置、情報端末装置、画像形成システム、画像形成装置管理制御方法、画像形成装置制御プログラムおよび情報端末装置制御プログラム |
US9338325B2 (en) | 2014-01-10 | 2016-05-10 | Konica Minolta, Inc. | Image forming apparatus issuing a notification to a network-connected terminal in response to occurrence of an event, image forming apparatus management and control method, and non-transitory computer-readable recording medium storing image forming apparatus control program |
CN104780286B (zh) * | 2014-01-10 | 2018-04-20 | 柯尼卡美能达株式会社 | 图像形成装置、信息终端装置、图像形成*** |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7516450B2 (en) | Remote management system, intermediary apparatus therefor, and method of updating software in the intermediary apparatus | |
US8166153B2 (en) | Remote control system and controlled apparatus therein capable of sending e-mail if communication request fails | |
US7463833B2 (en) | Monitoring apparatus, processing method, program for implementing the processing method, and management apparatus, management method, and program for implementing the management method | |
JP2004222247A (ja) | 通信装置,通信装置の遠隔管理システム,通信装置の制御方法,およびプログラム | |
JPWO2001048615A1 (ja) | プリンタ装置及び制御方法並びにプリンタ制御プログラムを格納したコンピュータ可読の記憶媒体 | |
JP4318975B2 (ja) | 遠隔管理システムとその電子装置,異常発生時の制御方法,およびプログラム | |
US20040260704A1 (en) | User-requested remote assistance for printing devices | |
US20040168109A1 (en) | Efficient remote management of devices by accurately removing abnormal condition reports | |
JP4184247B2 (ja) | 管理装置、遠隔管理システム、およびプログラム | |
JP4381839B2 (ja) | 電子装置とその遠隔管理システムおよびログ管理方法並びにプログラム | |
JP4327541B2 (ja) | 遠隔管理システムとその被管理装置,およびプログラム | |
JP4163550B2 (ja) | 遠隔管理システムとその仲介装置,管理装置,秘密情報設定方法,およびプログラム | |
US20040158632A1 (en) | Recovery of interrupted communication for remote management of devices | |
JP4347645B2 (ja) | 遠隔管理システムとその通信装置,制御方法,およびプログラム | |
JP2004234650A (ja) | 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム | |
JP2004234639A (ja) | 通信装置とその遠隔管理システムおよび送信要因発生時の制御方法並びにプログラム | |
JP4809272B2 (ja) | 遠隔管理システムおよび管理情報取得制御方法 | |
JP4744808B2 (ja) | 通信装置とその遠隔管理システムおよびプログラム | |
JP4133579B2 (ja) | 画像処理装置管理システム | |
JP2004295866A (ja) | 電子装置とその遠隔管理システムおよびログ管理方法並びにプログラム | |
JP4298494B2 (ja) | 管理装置,遠隔管理システム,およびカウンタ監視型遠隔管理方法 | |
JP3958676B2 (ja) | 通信装置とその遠隔管理システムおよび異常送信時の制御方法並びにプログラム | |
JP4767036B2 (ja) | 画像形成装置及びコンピュータプログラム | |
JP4376811B2 (ja) | 遠隔管理システムとその管理装置 | |
JP2005229592A (ja) | 画像処理システムとその画像処理装置,処理回数処理方法,プログラム,および記録媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20061102 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20090106 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20090305 |
|
A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20090915 |