JP2005301999A

JP2005301999A - 遠隔管理システムとその被管理装置，通信制御方法，プログラム，および記録媒体

Info

Publication number: JP2005301999A
Application number: JP2005062507A
Authority: JP
Inventors: Katsumi Watai; 克己渡井
Original assignee: Ricoh Co Ltd
Current assignee: Ricoh Co Ltd
Priority date: 2004-03-19
Filing date: 2005-03-07
Publication date: 2005-10-27
Also published as: US20050243804A1; US8166153B2

Abstract

【課題】被管理装置がファイアウォール又は仲介装置の内側に配置されている場合でも、動作要求を確実に管理装置へ送信できるようにする。
【解決手段】画像形成装置１００ａ−ｆでは、ＸＭＬ形式で記載した動作要求（ＳＯＡＰリクエスト）を含む通信要求（ＨＴＴＰリクエスト）を仲介装置１０１ａ−ｃ又は管理装置１０２へ送信し、動作要求に対する正常な動作応答（ＳＯＡＰレスポンス）を受信できなかった場合に、その動作要求を送信に電子メールに含めて管理装置１０２へ送信する。また、動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールをユーザ（管理者，庶務担当，ＩＴ担当など）が所有するユーザメール端末へ送信してその表示部に表示させることもできる。
【選択図】図３

Description

この発明は、画像形成装置等の被管理装置、その被管理装置とそれを遠隔管理する管理装置とを備えた遠隔管理システム、上記被管理装置における通信制御方法、その被管理装置のコンピュータに実行させるプログラム、およびそのプログラムを記録したコンピュータ読み取り可能な録媒媒体に関する。

例えば、特許文献１に見られるように、ユーザのオフィス等に設置されたプリンタ，ファクシミリ装置（ＦＡＸ），デジタル複写機（コピー機），デジタル複合機等の画像形成装置やスキャナなどの画像処理装置を被管理装置とし、サービスセンタ（管理センタ）に設置されている管理装置がインタネット等のネットワークを介してこれらの被管理装置を遠隔管理する遠隔管理システムが提案されている。あるいは、被管理装置が管理装置と通信するための通信機能を備えていない場合には、その被管理装置に管理装置と通信可能な通信機能を有する仲介装置（遠隔管理仲介装置）を接続し、管理装置がネットワークおよび仲介装置を介して被管理装置を遠隔管理する遠隔管理システムも提案されている。

ところで、従来から、通信装置をネットワークを介して接続した通信システムにおいて、通信装置同士で互いにメッセージを交換させることにより、通信相手の装置に対して通知や要求を行わせることが行われている。そして、このようなシステムにおいて、ある装置から別の装置に動作要求としてコマンドを送信して動作を実行させ、送信相手から動作の実行結果を動作応答として返信させることも行われている。

このような技術は、例えば特許文献２に開示されており、この文献には、リモートプロセッサがローカルプロセッサに対して実行されるべきコマンドを指示するメッセージを送信し、そのコマンドに対する応答を受信することが記載されている。
また、この特許文献２には、ローカルプロセッサがファイアウォールの内側に配置されている場合において、ローカルプロセッサからファイアウォールの外側のリモートプロセッサに通信要求を送信し、リモートプロセッサがこの通信要求に対する応答としてローカルプロセッサに対してコマンドを送信するようにすることにより、ファイアウォールの外側から内側に向けてコマンドを送信できるようにする技術も開示されている。
特開２００４−３０６２５号公報特開２００１−２７３２１１号公報

このような遠隔管理システムにおいて、サービスセンタ内の管理装置と被管理装置や仲介装置との通信を実際に行えるかどうかは、ユーザサイトのネットワークの環境に依存している。通常は、被管理装置や仲介装置の外側にプロシキサーバ（ファイアウォール）が設置されていて、外部からの不正アクセスに対処しているが、被管理装置や仲介装置に各種パラメータ（プロキシサーバＩＰアドレス，プロキシサーバログイン名，プロキシサーバログインパスワード、センタＵＲＬなど）が正しく設定されている必要がある。

しかしながら、このような遠隔管理システムでは、被管理装置や仲介装置の設置後、プロキシサーバログイン名やプロキシサーバログインパスワードの設定ミスがあった場合、あるいはプロキシサーバがダウンした場合（例えば電源が遮断された場合）には、ＨＴＴＰで通信するコマンドが被管理装置や仲介装置から管理装置に届かなくなるケースがあった。

また、仲介装置が通信（ＨＴＴＰＳ）するために必要な証明書情報が壊れた場合にも、通信が失敗する。
さらに、仲介装置のＬＡＮ（ネットワーク）ケーブルが抜けているケース、仲介装置の電源がＯＦＦになっているケースといったように仲介装置のダウン状態が発生した場合にも、コマンドが被管理装置や仲介装置から管理装置まで届かないことになる。
そして、通信できない状態になると、管理装置から被管理装置や仲介装置の情報取得、被管理装置や仲介装置からのコール発信（異常通報）ができなくなる。

この発明は、このような問題点に鑑みてなされたものであり、被管理装置がファイアウォール又は仲介装置の内側に配置されている場合でも、動作要求を確実に管理装置へ送信できるようにすることを目的とする。

この発明は、上記の目的を達成するため、画像形成装置等の被管理装置、その被管理装置とそれを遠隔管理する管理装置とからなる遠隔管理システム、上記被管理装置における通信制御方法、その被管理装置のコンピュータに実行させるプログラム、およびそのプログラムを記録したコンピュータ読み取り可能な録媒媒体を提供する。

請求項１の発明による被管理装置は、管理装置によりネットワークを介して遠隔管理可能な被管理装置であって、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に（通信要求の送信を開始してから予め設定された所定時間を経過しても通信応答を受信できなかった場合、あるいは通信応答は受信したが、それに含まれている動作応答が正常なものでなかった場合）、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項２の発明による被管理装置は、管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置であって、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に（通信要求の送信を開始してから予め設定された所定時間を経過しても通信応答を受信できなかった場合、あるいは通信応答は受信したが、それに含まれている動作応答が正常なものでなかった場合）、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項３の発明による被管理装置は、管理装置によりネットワークおよび仲介装置を介して遠隔管理される被管理装置であって、上記管理装置に対する動作要求を含む通信要求を上記仲介装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項４の発明による被管理装置は、請求項１〜３のいずれかの被管理装置において、上記メール送信手段に、上記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を備えたものである。
請求項５の発明による被管理装置は、請求項４の被管理装置において、上記メール送信手段に、正常な動作応答を受信できなかった動作要求の種別に応じて上記電子メールの送信先を変更する手段を備えたものである。

請求項６の発明による被管理装置は、管理装置によりネットワークを介して遠隔管理される被管理装置であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合（ＨＴＴＰリクエストのの送信を開始してから予め設定された所定時間が経過するまでの間にＨＴＴＰレスポンスを受信できなかった場合、あるいはＨＴＴＰレスポンスは受信したが、それに含まれているＳＯＡＰレスポンスが正常なものでなかった場合）に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項７の発明による被管理装置は、管理装置によりネットワークおよびファイアウォールを介して遠隔管理される被管理装置であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合（ＨＴＴＰリクエストのの送信を開始してから予め設定された所定時間が経過するまでの間にＨＴＴＰレスポンスを受信できなかった場合、あるいはＨＴＴＰレスポンスは受信したが、それに含まれているＳＯＡＰレスポンスが正常なものでなかった場合）に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項８の発明による被管理装置は、管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを上記仲介装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設けたものである。

請求項９の発明による被管理装置は、請求項６〜８のいずれかの被管理装置において、上記メール送信手段に、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を備えたものである。
請求項１０の発明による被管理装置は、請求項９の被管理装置において、上記メール送信手段に、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて上記電子メールの送信先を変更する手段を備えたものである。

請求項１１の発明による遠隔管理システムは、管理装置によりネットワークを介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記管理装置に、上記被管理装置から上記通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信応答を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信応答をそれぞれ上記被管理装置へ送信する通信制御手段を設けたものである。

請求項１２の発明による遠隔管理システムは、管理装置によりネットワークおよびファイアウォールを介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記管理装置に、上記被管理装置から上記通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信応答を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信応答をそれぞれ上記被管理装置へ送信する通信制御手段を設けたものである。

請求項１３の発明による遠隔管理システムは、管理装置によりネットワークおよび仲介装置を介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対する動作要求を含む通信要求を上記仲介装置へ送信する通信要求送信手段と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記仲介装置に、上記被管理装置から受信した上記動作要求を含む通信要求を上記管理装置へ送信し、該動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す動作応答を含む通信応答を上記被管理装置へ送信する通信制御手段を設け、上記管理装置に、上記仲介装置から通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信要求を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信要求をそれぞれ上記仲介装置へ送信する通信制御手段を設けたものである。

請求項１４の発明による遠隔管理システムは、請求項１１〜１３のいずれかの遠隔管理システムにおいて、上記被管理装置のメール送信手段に、上記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を備えたものである。
請求項１５の発明による遠隔管理システムは、請求項１４の遠隔管理システムにおいて、上記被管理装置のメール送信手段に、正常な動作応答を受信できなかった動作要求の種別に応じて上記電子メールの送信先を変更する手段を備えたものである。

請求項１６の発明による遠隔管理システムは、管理装置によりネットワークを介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記管理装置に、上記被管理装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ上記被管理装置へ送信するＨＴＴＰ通信制御手段を設けたものである。

請求項１７の発明による遠隔管理システムは、管理装置によりネットワークおよびファイアウォールを介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記管理装置に、上記被管理装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ上記被管理装置へ送信するＨＴＴＰ通信制御手段を設けたものである。

請求項１８の発明による遠隔管理システムは、管理装置によりネットワークおよび仲介装置を介して被管理装置を遠隔管理する遠隔管理システムであって、上記被管理装置に、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを上記仲介装置へ送信するＨＴＴＰリクエスト送信手段と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信手段とを設け、上記仲介装置に、上記被管理装置から受信した上記ＳＯＡＰリクエストを含むＨＴＴＰリクエストを上記被管理装置へ送信し、該ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを上記被管理装置へ送信するＨＴＴＰ通信制御手段を設け、上記管理装置に、上記仲介装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰリクエストを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰリクエストをそれぞれ上記仲介装置へ送信するＨＴＴＰ通信制御手段を設けたものである。

請求項１９の発明による遠隔管理システムは、請求項１６〜１８のいずれかの遠隔管理システムにおいて、上記被管理装置のメール送信手段に、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を備えたものである。
請求項２０の発明による遠隔管理システムは、請求項１９の遠隔管理システムにおいて、上記被管理装置のメール送信手段に、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて上記電子メールの送信先を変更する手段を備えたものである。

請求項２１の発明による通信制御方法は、管理装置によりネットワークを介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信するステップと、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するステップとからなるものである。

請求項２２の発明による通信制御方法は、管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信するステップと、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するステップとからなるものである。

請求項２３の発明による通信制御方法は、管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対する動作要求を含む通信要求を上記仲介装置へ送信するステップと、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するステップとからなるものである。
請求項２４の発明による通信制御方法は、請求項２１〜２３のいずれかの通信制御方法において、上記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信するステップを追加したものである。

請求項２５の発明による通信制御方法は、管理装置によりネットワークを介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するステップと、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するステップとからなるものである。

請求項２６の発明による通信制御方法は、管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するステップと、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するステップとからなるものである。

請求項２７の発明による通信制御方法は、管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置における通信制御方法であって、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを上記仲介装置へ送信するステップと、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するステップとからなるものである。
請求項２８の発明による通信制御方法は、請求項２５〜２７のいずれかの被管理装置において、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信するステップを追加したものである。

請求項２９の発明によるプログラムは、管理装置によりネットワークを介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信機能と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３０の発明によるプログラムは、管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信機能と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３１の発明によるプログラムは、管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対する動作要求を含む通信要求を上記仲介装置へ送信する通信要求送信機能と、上記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３２の発明によるプログラムは、請求項２９〜３１のいずれかのプログラムにおいて、上記コンピュータに、上記メール送信機能を実現させるためのプログラムは、上記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する機能をも実現させるためのものである。
請求項３３の発明によるプログラムは、請求項３２のプログラムにおいて、上記コンピュータに、上記メール送信機能を実現させるためのプログラムは、正常な動作応答を受信できなかった動作要求の種別に応じて上記電子メールの送信先を変更する機能をも実現させるためのものである。

請求項３４の発明によるプログラムは、管理装置によりネットワークを介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信機能と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３５の発明によるプログラムは、管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信機能と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３６の発明によるプログラムは、管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置のコンピュータに、上記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを上記仲介装置へ送信するＨＴＴＰリクエスト送信機能と、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて上記管理装置へ送信するメール送信機能とを実現させるためのものである。

請求項３７の発明によるプログラムは、請求項３４〜３６のいずれかのプログラムにおいて、上記コンピュータに、上記メール送信機能を実現させるためのプログラムは、上記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する機能をも実現させるためのものである。

請求項３８の発明によるプログラムは、請求項３７のプログラムにおいて、上記コンピュータに、上記メール送信機能を実現させるためのプログラムは、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて上記電子メールの送信先を変更する機能をも実現させるためのものである。
請求項３９の発明による記録媒体は、請求項２９〜３８のいずれかのプログラムを記録したコンピュータ読み取り可能な記録媒体である。

この発明によれば、被管理装置がファイアウォール又は仲介装置の内側に配置されている場合でも、動作要求を確実に管理装置へ送信することができる。

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

この遠隔管理システムは、通信機能を有する電子装置を被管理装置１０（１０ａ，１０ｂ，１０ｃ，１０ｄ，１０ｅ，１０ｆ）とし、この被管理装置１０と接続される（被管理装置側から見た）外部装置として、被管理装置１０とＬＡＮ（ローカルエリアネットワーク）によって接続された遠隔管理仲介装置である仲介装置１０１（１０１ａ，１０１ｂ，１０１ｃ）、更に仲介装置１０１とインタネット１０３又は図示しない公衆回線等のネットワークを介して接続されるサーバ装置として機能する管理装置１０２を備え、その管理装置１０２が、仲介装置１０１を介して各被管理装置１０を集中的に遠隔管理できるようにしたものである。被管理装置１０および仲介装置１０１は機器利用者（ユーザ）側の設置環境（オフィス等）に、管理装置１０２はサービスセンタにそれぞれ設置されている。

なお、被管理装置１０としては、種々の電子装置に通信機能を設けた通信装置が考えられ、例えば、プリンタ，ＦＡＸ装置，デジタル複写機，デジタル複合機等の画像形成装置やスキャナ装置等の画像読取装置などの画像処理装置や、ネットワーク家電，自動販売機，医療機器，電源装置，空調システム，ガス・水道・電気等の計量システム等に通信機能を持たせた通信装置が考えられる。
ところで、この遠隔管理システムにおいて、設置環境Ａ，Ｂ内の仲介装置１０１と被管理装置１０は、互いにＬＡＮ（ローカルエリアネットワーク）によって接続し、これを介して通信可能としている。また、設置環境Ａ，Ｂ，Ｃには、セキュリティ面を考慮し、ファイアウォール１０４（１０４ａ，１０４ｂ，１０４ｃ）を設置する。このファイアウォール１０４は、プロキシサーバによって構成する。

ここで、管理装置１０２が新たな方式を用いて遠隔管理するサービス（ＮＲＳ）を実現するために、機器利用者側のＬＡＮに、ＮＲＳに対応するソフトウェアを実装した仲介装置１０１および被管理装置１０が接続されている。その仲介装置１０１および被管理装置１０には、管理装置１０２が従来の方式を用いて遠隔管理するサービス（ＣＳＳ）も実現するために、ＣＳＳに対応するソフトウェアも実装している。ＮＲＳを実現するためには、ＣＳＳを実現する場合と同様に、仲介装置１０１および被管理装置１０を初期設置すればよい。

公衆回線（又は専用回線）としては、アナログ回線，ＡＤＳＬ回線，デジタル回線（ＩＳＤＮ回線），光ファイバー利用回線等の固定電話回線や、携帯電話回線，ＰＨＳ回線等の移動電話回線がある。
なお、仲介装置１０１と被管理装置１０との接続は、ＬＡＮに限らず、ＲＳ−４８５規格等に準拠したシリアル接続や、ＳＣＳＩ（Small Computer System Interface）規格等に準拠したパラレル接続等によって行ってもよい。例えば、ＲＳ−４８５規格の場合には、仲介装置１０１に直列に５台までの被管理装置１０を接続することができる。

仲介装置１０１および被管理装置１０は、その利用環境に応じて多様な階層構造を成す。
例えば、図１に示す設置環境Ａでは、管理装置１０２とＨＴＴＰ（Hyper Text Transfer Protocol）による直接的なコネクションを確立できる仲介装置１０１ａが被管理装置１０ａおよび１０ｂを従える単純な階層構造になっているが、同図に示す設置環境Ｂでは、４台の被管理装置１０を設置するため、１台の仲介装置１０１を設置しただけでは負荷が大きくなる。

そのため、管理装置１０２とＨＴＴＰによる直接的なコネクションを確立できる仲介装置１０１ｂが、被管理装置１０ｃおよび１０ｄだけでなく、他の仲介装置１０１ｃを従え、この仲介装置１０１ｃが被管理装置１０ｅおよび１０ｆを更に従えるという階層構造を形成している。この場合、被管理装置１０ｅおよび１０ｆを遠隔管理するために管理装置１０２から発せられた情報は、仲介装置１０１ｂとその下位のノードである仲介装置１０１ｃとを経由して、被管理装置１０ｅ又は１０ｆに到達することになる。

また、設置環境Ｃのように、被管理装置１０に仲介装置１０１の機能を併せ持たせた仲介機能付被管理装置（以下単に「被管理装置」ともいう）１１ａ，１１ｂを、別途仲介装置１０１を介さずにインタネット１０３によって管理装置１０２に接続するようにしてもよい。
なお、図示はしていないが、仲介機能付被管理装置１１の下位に更に被管理装置１０を接続することもできる。
また、各被管理装置１０，１１に、ＬＡＮ経由でパーソナルコンピュータ等の端末装置や他の電子装置（外部装置）を接続することもできる。

このような遠隔管理システムにおいて、仲介装置１０１は、これに接続された被管理装置１０の制御管理のためのアプリケーションプログラムを実装している。
管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した被管理装置１０の制御管理を行うためのアプリケーションプログラムを実装している。そして、被管理装置１０も含め、この遠隔管理システムにおけるこれら各ノードは、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。

すなわち、管理装置１０２は、被管理装置１０や仲介装置１０１への動作要求（以下、管理装置側動作要求ともいう）を生成してこれを被管理装置１０や仲介装置１０１へ引き渡し、この動作要求に対する動作応答を取得できる一方で、被管理装置１０は、管理装置１０２への動作要求（以下、被管理装置側要求ともいう）を生成してこれを管理装置１０２へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。また、仲介装置１０１も、管理装置１０２への動作要求（以下、仲介装置側要求ともいう）を生成してこれを管理装置１０２へ引き渡し、この動作要求に対する動作応答を取得できるようになっている。

なお、ここではメソッドを、入力と出力の形式を規定した論理的な関数として定義するものとする。そしてこの場合、動作要求はこの関数を呼び出す関数呼び出し（Procedure Call）となり、動作応答はその関数呼び出しによって呼び出された関数の実行結果となる。動作要求による要求の内容には、意味のある実行結果を伴わない通知も含まれる。

図２に、これらの動作要求と動作応答の関係を示す。なお、この図においてはファイアウォール１０４の存在は考慮していない。
図２（Ａ）は、被管理装置１０で管理装置１０２に対する動作要求が発生したケースである。このケースでは、被管理装置１０が被管理装置側動作要求ａを生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこの動作要求に対する動作応答ａを返すというモデルになる。また、図に示す仲介装置１０１が複数であるケースも想定できる（例えば被管理装置が図１に示した被管理装置１０ｅ又は１０ｆである設置環境Ｂの場合）。なお、被管理装置側動作要求ａは、管理装置１０２に送信される動作要求であるから、管理装置「宛て」の動作要求と言うことができる。

また、図２（Ａ）では、応答ａだけでなく遅延通知ａ′を返信するケースも表記している。これは管理装置１０２が、接続してきた仲介装置１０１から被管理装置側動作要求ａを受け取って、これとの接続中にその動作要求に対する応答を返せないと判断したときには、応答が遅延する旨を通知して一旦接続状態を切断し（通信可能状態を解除し）、後の接続の際に上記動作要求に対する応答を改めて引き渡す構成になっているためである。

図２（Ｂ）は、仲介装置１０１で管理装置１０２に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が、例えば、仲介装置側動作要求ｂを生成し、これを受け取った管理装置１０２が、その動作要求に対する動作応答ｂを返すというモデルになる。なお、図２（Ｂ）のケースでも、応答を即座に返せないときに遅延通知ｂ′を返すことは図２（Ａ）のケースと同様である。

図２（Ｃ）は、管理装置１０２で、被管理装置１０に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求ｃを生成し、これを仲介装置１０１を経由して受け取った被管理装置１０が、その動作要求に対する動作応答ｃを返すというモデルになる。なお、被管理装置１０が使用する一般的な通信プロトコルは、遅延通知を返す機能を有していないが、仲介装置１０１が代わって遅延通知を行うことは考えられる（図示は省略した）。

図２（Ｄ）は、管理装置１０２で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求ｄを生成し、これを受け取った仲介装置１０１が、その動作要求に対する動作応答ｄを返すというモデルになる。なお、図２（Ｄ）のケースでは、図２（Ａ）のケースと同様に、応答を即座に返せないときに遅延通知ｄ′を返す。
なお、ここではＲＰＣによる引数並びに戻り値の受け渡しのプロトコルとしてＳＯＡＰ（Simple Object Access Protocol）を採用し、上記の動作要求や動作応答は、ここではＳＯＡＰメッセージとして記載するようにしている。

ここで、動作要求はユーザ側の被管理装置１０又は仲介装置１０１からのみ送信し、管理装置１０２はこの動作要求に対する動作応答のみを通信相手に送信する構成であっても、この発明を適用することができる。
そして、実際に動作要求や動作応答を転送するための通信プロトコルとしては、システムの構成に合わせて適当なものを採用することができ、例えばＨＴＴＰ（Hyper Text Transfer Protocol）やＳＭＴＰ（Simple Mail Transfer Protocol）を採用することができる。ここでは、通信プロトコルにＨＴＴＰを採用する場合の例を示す。

次に、図１に示す管理装置１０２の物理的構成について簡単に説明すると、当該管理装置１０２は、ＣＰＵ，ＲＯＭ，ＲＡＭ等からなる制御装置や、データベース，モデム，プロキシ（Ｐｒｏｘｙ）サーバ等によって構成されている。その構成については、追って詳細に説明する。
さらに、図１に示す仲介装置１０１における物理的構成について簡単に説明すると、当該仲介装置１０１は、ＣＰＵ，ＲＯＭ，ＲＡＭ，不揮発性メモリ，ＰＨＹ（物理メディアインタフェース）等によって構成されている。その構成についても、追って詳細に説明する。

また、仲介機能付被管理装置１１については、仲介装置１０１の機能を実現するためにこれらのユニットを単に被管理装置１０に付加しても良いが、被管理装置１０に備えるＣＰＵ，ＲＯＭ，ＲＡＭ等のハードウェア資源を利用し、ＣＰＵに適当なアプリケーションやプログラムモジュールを実行させることによって仲介装置１０１の機能を実現することもできる。

以下、図１に示した遠隔管理システムのより具体的な例として、この発明による画像形成装置を被管理装置とする遠隔管理システムである画像形成装置遠隔管理システムについて説明する。
図３は、その画像形成装置遠隔管理システムの構成の一例を示す概念図であるが、被管理装置１０を画像形成装置１００に、仲介機能付被管理装置１１を仲介機能付画像形成装置（以下単に「画像形成装置」ともいう）１１０に変更した点が図１と相違するのみであるので、システムの全体構成についての説明は省略する。
画像形成装置１００は、複写（コピー）機，プリンタ，ファクシミリ（ＦＡＸ）装置，スキャナ装置，文書管理装置等としての機能および外部装置と通信を行う機能を備えたデジタル複合機であり、それらの機能に係るサービスを提供するためのアプリケーションプログラムを実装しているものである。また、画像形成装置１１０は、画像形成装置１００に仲介装置１０１の機能を併せ持たせたものである。

また、図１に示した遠隔管理システムの場合と同様に、仲介装置１０１は、これに接続された画像形成装置１００の制御管理のためのアプリケーションプログラムを実装している。管理装置１０２は、各仲介装置１０１の制御管理、更にはこの仲介装置１０１を介した画像形成装置１００の制御管理を行うためのアプリケーションプログラムを実装している。そして、ＲＰＣ（remote procedure call）により、相互の実装するアプリケーションプログラムのメソッドに対する処理の依頼である「動作要求」を送信し、この依頼された処理の結果である「動作応答」を取得することができるようになっている。

図４に、これらの動作要求と動作応答の関係を示す。なお、この図においてもファイアウォール１０４の存在は考慮していない。
図４（Ａ）は、画像形成装置１００で管理装置１０２に対する動作要求が発生したケースである。このケースでは、画像形成装置１００が画像形成装置側動作要求ａ（以下「画像機器コマンド」とも呼ぶ）を生成し、これを仲介装置１０１を経由して受け取った管理装置１０２がこのコマンドに対する動作応答ａ（以下「コマンド応答」あるいは単に「応答」とも呼ぶ）を返すというモデルになる。また、図に示す仲介装置１０１が複数であるケースも想定できる。なお、応答を即座に返せないときに遅延通知ａ′を返信することは、図２（Ａ）のケースと同様である。
ただし、画像形成装置１００は遅延通知に対応していないため、遅延通知ａ′の送信は仲介装置１０１までとして、所定時間内に画像形成装置１００に動作応答ａを返せない場合には処理をタイムアウトさせるようにしている。

図４（Ｂ）は、仲介装置１０１で管理装置１０２に対する動作要求が発生したケースである。このケースでは、仲介装置１０１が、例えば、仲介装置側動作要求ｂ（以下「仲介装置コマンド」とも呼ぶ）を生成し、これを受け取った管理装置１０２が、そのコマンドに対する動作応答ｂを返すというモデルになる。応答を即座に返せないときに遅延通知ｂ′を返すことは、図２（Ａ）のケースと同様である。

図４（Ｃ）は、管理装置１０２で、画像形成装置１００に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求ｃ（以下「管理装置コマンド」とも呼ぶ）を生成し、これを仲介装置１０１を経由して受け取った画像形成装置１００が、その動作要求に対する動作応答ｃを返すというモデルになる。なお、画像形成装置１００が遅延通知を返す機能を有していないことは、図２（Ｃ）のケースと同様である。

図４（Ｄ）は、管理装置１０２で仲介装置１０１に対する動作要求が発生したケースである。このケースでは、管理装置１０２が管理装置側動作要求（管理装置コマンド）ｄを生成し、これを受け取った仲介装置１０１が、そのコマンドに対する動作応答ｄを返すというモデルになる。なお、図４（Ｄ）のケースでは、図２（Ａ）のケースと同様に、応答を即座に返せないときに遅延通知ｄ′を返す。
このように、動作要求及び動作応答は、ＲＰＣのレベルでは、画像形成装置１００と管理装置１０２との間および仲介装置１０１と管理装置１０２との間で対称に取り扱われるものである。しかし、通信のレベルでは対称ではない。

次に、この遠隔管理システムにおける通信シーケンスについて説明する。
まず、図５に画像形成装置１００と仲介装置１０１との間の通信シーケンスの例を示す。
この図に示すように、画像形成装置１００と仲介装置１０１とは、通信要求であるＨＴＴＰリクエストと、その通信要求に対する通信応答であるＨＴＴＰリクエストとを、互いに送受信することによって通信を行っている。そして、画像形成装置１００と仲介装置１０１との間にはファイアウォールがないため、画像形成装置１００と仲介装置１０１のどちらがＨＴＴＰリクエストを送信しても（通信サーバとして機能しても）通信を行うことができる。例えば、仲介装置１０１が送信したＨＴＴＰリクエストＸに対して画像形成装置１００がＨＴＴＰレスポンスＸを返すこともできるし、画像形成装置１００が送信したＨＴＴＰリクエストＺに対して仲介装置１０１がＨＴＴＰレスポンスＺを返すこともできるという具合である。

また、上述したように、画像形成装置１００は、管理装置コマンドを仲介装置１０１を経由して受け取るが、この場合、仲介装置１０１がＨＴＴＰリクエストに管理装置コマンドを記載して画像形成装置１００に送信する（ＨＴＴＰリクエストＸ，Ｙ）。そして、画像形成装置１００は、この管理装置コマンドに対する応答を、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する（ＨＴＴＰレスポンスＸ，Ｙ）。
また、逆に画像形成装置１００が画像機器コマンドを仲介装置１０１を介して管理装置１０２に送信する場合には、画像形成装置１００がＨＴＴＰリクエストに画像機器コマンドを記載して仲介装置１０１に送信し（ＨＴＴＰリクエストＺ）、仲介装置１０１は、この画像機器コマンドに対する応答を、そのＨＴＴＰリクエストに対するＨＴＴＰレスポンスに記載して送信する（ＨＴＴＰレスポンスＺ）。

なお、後者の場合には、仲介装置１０１が管理装置１０２に画像機器コマンドを転送し、処理を実行させて応答を受け取るまでに時間がかかることも考えられるので、以下のような手順とすることも考えられる。
すなわち、画像形成装置１００がＨＴＴＰリクエストに画像機器コマンドを記載して仲介装置１０１に送信し（ＨＴＴＰリクエストＺ′）、これに対して仲介装置１０１はＨＴＴＰレスポンスにコマンドの受付通知を記載して返信し（ＨＴＴＰレスポンスＺ）、コマンドを管理装置１０２に転送して応答を待つ。そして、画像機器コマンドに対する応答を管理装置１０２から受信すると、これをＨＴＴＰリクエストに記載して画像形成装置１００に送信する（ＨＴＴＰリクエストＷ）。これによって画像形成装置１００は画像機器コマンドに対する応答を取得でき、ＨＴＴＰレスポンスに応答の受信通知を記載して返信する（ＨＴＴＰレスポンスＷ）、という手順である。
しかし、以下の説明においては、上記のＨＴＴＰレスポンスＺに応答を記載する手順を採用した場合について説明する。

次に、図６に仲介装置１０１と管理装置１０２との間の通信シーケンスの例を示す。
仲介装置１０１と管理装置１０２との間には、ファイアウォール１０４があるため、この図に示すように、通信は常に、仲介装置１０１から通信要求としてＨＴＴＰリクエストを管理装置１０２に送信し、管理装置１０２からこの通信要求に対する通信応答としてＨＴＴＰレスポンスを仲介装置１０１に返すという手順で行われる。例えば、仲介装置１０１が送信したＨＴＴＰリクエストＸに対して管理装置１０２がＨＴＴＰレスポンスＸを返し、同じくＨＴＴＰリクエストＹに対してＨＴＴＰレスポンスＹを返すという具合である。

そして、ＨＴＴＰリクエストには、仲介装置１０１からの管理装置１０２宛ての動作要求である仲介装置コマンドと、画像形成装置１００からの管理装置１０２宛ての動作要求である画像機器コマンドと、管理装置１０２から仲介装置１０１に送信されてきた管理装置コマンドに対する応答（コマンド応答）と、管理装置１０２から画像形成装置１００に送信されてきた管理装置コマンドに対する応答とを記載して送信するようにしている。また、ＨＴＴＰレスポンスには、管理装置１０２からの仲介装置１０１宛て又は画像形成装置１００宛ての動作要求である管理装置コマンドと、仲介装置１０１からの管理装置１０２宛ての動作要求である仲介装置コマンドに対する応答と、画像形成装置１００からの管理装置１０２宛ての動作要求である画像機器コマンドに対する応答とを記載して送信するようにしている。なお、遅延通知を送信する場合には、上記コマンド応答に代えて遅延通知を記載してもよい。

例えば、画像機器コマンドＡおよび仲介装置コマンドＢは、ＨＴＴＰリクエストＸに記載して転送し、コマンド応答あるいは遅延通知をそのＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送することができる。しかし、管理装置コマンドＣおよびＤについては、ＨＴＴＰリクエストＸと対応するＨＴＴＰレスポンスＸに記載して転送し、そのコマンド応答あるいは遅延通知は次のＨＴＴＰリクエストであるＨＴＴＰリクエストＹに記載して転送することになる。
ここで、画像機器宛ての管理装置コマンドＤに対して仲介装置１０１が返す遅延通知は、画像形成装置１００が生成したものではなく、後述するように、仲介装置１０１が生成したものである。

また、上述した図４（Ａ）又は（Ｂ）のケースでは、仲介装置１０１が、画像機器コマンドを取得するか仲介装置コマンドを生成した後直ちに管理装置１０２とコネクションを確立し、ＨＴＴＰリクエストにこれを含めて引き渡すことができるが、図４（Ｃ）又は（Ｄ）のケースでは、仲介装置１０１側に設置されたファイアウォール１０４が管理装置１０２からのＨＴＴＰリクエストを遮断するため、管理装置１０２側から仲介装置１０１へアクセスして管理装置コマンドを直ちに引き渡すことができないことになる。

次に、図３の画像形成装置１００の物理的構成について、図７を用いて具体的に説明する。
図７は、画像形成装置１００のハードウェア構成例を示すブロック図である。
画像形成装置１００は、複写機，プリンタ，ファクシミリ装置，スキャナ装置，文書管理装置等としの機能を備えたデジタル複合機として構成しており、図７に示すように、ＣＰＵ２０１，ＡＳＩＣ（Application Specific Integrated Circuit）２０２，ＳＤＲＡＭ２０３，フラッシュメモリ（不揮発性メモリ）２０４，ＮＲＳ用メモリ２０５，ＰＨＹ（物理メディアインタフェース）２０６，ＮＶＲＡＭ（不揮発性メモリ）２０７，操作部２０９，ＨＤＤ（ハードディスクドライブ）２１０，モデム２１１，ＰＩ（パーソナルインタフェース）２１２，ＦＣＵ（ファックスコントロールユニット）２１３，ＵＳＢ（Universal Serial Bus）２１４，ＩＥＥＥ（Institute of Electrical and Electronic Engineers）１３９４＿２１５，エンジンインタフェース（Ｉ／Ｆ）２１６，およびエンジン部２１７を備えている。これらの構成が、画像読み取り，画像形成，画情報送信等の画像処理を行うためのハードウェア資源である。なお、エンジン部２１７を構成するプロッタエンジンおよびスキャナエンジンを含む複数のエンジンユニットはそれぞれ、内部に異常等の事象を検出するためのセンサを備えている。

ＣＰＵ２０１は、ＡＳＩＣ２０２を介してデータ処理（各機能の制御）を行う演算処理手段である。
ＡＳＩＣ２０２は、ＣＰＵインターフェース，ＳＤＲＡＭインターフェース，ローカルバスインタフェース，ＰＣＩインタフェース，ＭＡＣ（Media Access Controller）、ＨＤＤインタフェースなどからなる多機能デバイスボードであり、ＣＰＵ２０１の制御対象となるデバイスの共有化を図り、アーキテクチャの面からアプリ（アプリケーションソフト）や共通システムサービスの開発の高効率化を支援するものである。

このＡＳＩＣ２０２には、エンジン部２１７（各エンジンユニット）の操作命令等を受け付けるオペレーションパネル等による操作部２０９が直接的に接続されると共に、ＰＨＹ２０６も直接的に接続される。また、ＦＣＵ２１３やＵＳＢ２１４，ＩＥＥＥ１３９４＿２１５及びエンジンＩ／Ｆ２１６がＰＣＩバス２１８を介して接続され、必要に応じてモデム２１１やＰＩ２１２等が直接接続される。
ＳＤＲＡＭ２０３は、ＯＳ（オペレーティングシステム）を含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ２０１がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。なお、このＳＤＲＡＭ２０３の代わりに、ＤＲＡＭやＳＲＡＭを使用してもよい。

フラッシュメモリ２０４は、例えば、画像形成装置１００を起動させるブートローダ（ブートプログラム）やＯＳのファイルであるＯＳイメージ、種々のアプリ，サービス（サービスソフトウェア），ファームウェアを記憶するプログラムメモリ、種々の固定パラメータを記憶する固定パラメータメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このフラッシュメモリ２０４の代わりに、ＲＡＭと電池を利用したバックアップ回路を集積した不揮発性ＲＡＭや、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。また、ブートローダを記憶したＲＯＭを備えるようにしてもよい。

ＮＲＳ用メモリ２０５は、後述するＮＲＳアプリを記憶する不揮発性メモリであり、オプションでＮＲＳ機能を追加することができる。なお、このＮＲＳ用メモリ２０５を備えず、ＮＲＳをフラッシュメモリ２０４に記憶することも勿論できる。
ＰＨＹ２０６は、ＬＡＮを介して外部装置と通信を行うためのインタフェースであり、ＩＥＥＥ（Institute of Electrical and Electronic Engineers）８０２．１１ｂ規格（無線ＬＡＮ対応），ＩＥＥＥ１３９４規格，ＩＥＥＥ８０２．３規格（イーサネット（登録商標）対応）に準拠したインタフェース（通信手段）を用いることができる。

ＮＶＲＡＭ２０７は、例えば、この画像形成装置１００の識別情報である機種機番を記憶する機種機番メモリ、操作部２０９による操作上の初期値を記憶するメモリ、各アプリ（ＡＰＬ）の初期値を記憶するメモリ、各カウンタ情報（課金カウンタのデータ）を記憶するメモリ、自身や通信相手の設定状況、変更可能な種々のパラメータを記憶するメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。なお、このＮＶＲＡＭ２０７として、ＲＡＭと電池を利用したバックアップ回路を集積した不揮発性ＲＡＭや、ＥＥＰＲＯＭ，フラッシュメモリ等の不揮発性メモリを使用することができる。

操作部２０９は、エンジン部２１７に対する操作命令（コマンド）等の情報（データ）を入力するための各種の操作キー（操作スイッチ又は操作ボタンともいう）およびＬＣＤ又はＣＲＴの文字表示器を有する操作手段である。なお、文字表示器の表面に、例えばタッチパネルを備えることもできる。
ＨＤＤ２１０は、電源のオン・オフに関係なくデータを記憶保存する記憶手段（記録媒体）である。このＨＤＤ２１０に、上述したフラッシュメモリ２０４内のプログラムやそれ以外のデータ、あるいはＮＶＲＡＭ２０７内のデータを記憶しておくこともできる。また、定期的に収集，更新，送信等の処理を行う対象となるデータも、このＨＤＤ２１０に記憶させておくとよい。

モデム２１１は、変復調手段であり、管理装置１０２へ公衆回線経由でデータを送信する場合、そのデータを公衆回線に流せる形に変調する。また、管理装置１０２から送られてくる変調されたデータを受信した場合、そのデータを復調する。
ＰＩ２１２は、ＲＳ４８５規格に準拠したインタフェースを備え、図示しないラインアダプタを介して公衆回線に接続している。なお、このＰＩ２１２を用いて画像形成装置１００と仲介装置１０１とを接続することも可能である。
ＦＣＵ２１３は、ＦＡＸ装置又はモデム機能（ＦＡＸ通信機能）を有するデジタル複写機やデジタル複合機等の画像形成装置および管理装置１０２等の外部装置との通信を公衆回線経由で制御する。

ＵＳＢ２１４及びＩＥＥＥ１３９４＿２１５はそれぞれ、周辺機器と通信を行うための、ＵＳＢ規格及びＩＥＥＥ１３９４規格のインタフェースである。
エンジンＩ／Ｆ２１６は、エンジン部２１７をＰＣＩバスに接続するためのインタフェースである。
エンジン部２１７は、原稿の画像を読み取るスキャナエンジン（画像読取手段）、そのスキャナエンジンによって読み取られた画像データあるいは外部装置から受信したデータに基づいて用紙等の記録媒体上に画像形成を行うプロッタエンジン（画像形成手段）や、原稿をスキャナエンジンの画像読取位置へ自動給送する自動原稿給送装置（ＡＤＦ）、プロッタエンジンで画像形成された用紙に対してソート，穴開け，ステープル処理等の後処理を行う後処理装置装置などに相当する。

このような画像形成装置１００において、電源投入（電源オン）時には、ＣＰＵ２０１は、ＡＳＩＣ２０２経由でフラッシュメモリ２０４内のブートローダを起動させ、そのブートローダに従い、フラッシュメモリ２０４内のＯＳイメージを読み出し、それをＳＤＲＡＭ２０３にロードして使用可能なＯＳに展開する。そして、ＯＳの展開が完了すると、そのＯＳを起動させる。その後、必要に応じてフラッシュメモリ２０４内のアプリ等のプログラムあるいはＮＲＳ用メモリ２０５内のＮＲＳアプリを読み出し、それをＳＤＲＡＭ２０３にロードして展開し、起動させることにより、各種機能を実現することができる。

次に、画像形成装置１００のソフトウェア構成について、図８を用いて具体的に説明する。
図８は、画像形成装置１００のソフトウェア構成の一例を示すブロック図である。
この画像形成装置１００のソフトウェア構成は、アプリケーションモジュール層，サービスモジュール層，汎用ＯＳ層からなる。そして、これらのソフトウェアを構成するプログラムはフラッシュメモリ２０４やＮＲＳ用メモリ２０５に記憶され、必要に応じて読み出されてＣＰＵ２０１によって実行される。そしてＣＰＵ２０１は、これらのプログラムを必要に応じて実行することにより、この発明による通信要求送信手段（ＨＴＴＰリクエスト送信手段）およびメール送信手段としての機能を実現することができる。

アプリケーションモジュール層のソフトウェアは、ＣＰＵ２０１を、ハードウェア資源を動作させて所定の機能を実現させる複数のアプリケーション制御手段（処理実行手段）として機能させるためのプログラムによって構成され、サービスモジュール層のソフトウェアは、ＣＰＵ２０１を、ハードウェア資源と各アプリケーション制御手段との間に介在し、複数のアプリケーション制御手段からのハードウェア資源に対する動作要求の受付，その動作要求の調停，およびその動作要求に基づく動作の実行制御を行うサービス制御手段（処理実行手段）として機能させるためのプログラムによって構成される。

なお、それらの機能のうち、管理装置１０２との通信に係わる機能（通信手段としての機能）の実現方法は、画像形成装置１００と画像形成装置１１０とによって異なる。つまり、画像形成装置１１０の場合は、仲介装置１０１の機能を備えているため、ＣＰＵ２０１が対応するプログラムを実行することにより、管理装置１０２との通信に係わる機能を実現することができる。画像形成装置１００の場合には、ＣＰＵ２０１が対応するプログラムを実行すると共に、仲介装置１０１を利用することにより、管理装置１０２との通信に係わる機能を実現することができる。

サービスモジュール層には、オペレーションコントロールサービス（ＯＣＳ）３００，エンジンコントロールサービス（ＥＣＳ）３０１，メモリコントロールサービス（ＭＣＳ）３０２，ネットワークコントロールサービス（ＮＣＳ）３０３，ファクスコントロールサービス（ＦＣＳ）３０４，システムコントロールサービス（ＳＣＳ）３０６，システムリソースマネージャ（ＳＲＭ）３０７，イメージメモリハンドラ（ＩＭＨ）３０８，デリバリーコントロールサービス（ＤＣＳ）３１６，ユーザコントロールサービス（ＵＣＳ）３１７を実装している。また、アプリケーションモジュール層には、ＮＲＳアプリ（以下単に「ＮＲＳ」ともいう）３０５，ＣＳＳアプリ（以下単に「ＣＳＳ」という）３１５，コピーアプリ３０９，ファクスアプリ３１０，プリンタアプリ３１１，スキャナアプリ３１２，ネットファイルアプリ３１３，ウェブ（ｗｅｂ）アプリ３１４，メール通知アプリ３１８を実装している。更に、汎用ＯＳ層には、汎用ＯＳ３２０を実装している。

これらを更に詳述する。
ＯＣＳ３００は、操作部２０９を制御するモジュールである。
ＥＣＳ３０１は、ハードウェアリソース等のエンジン部２１７を制御するモジュールである。
ＭＣＳ３０２は、メモリ制御をするモジュールであり、例えば、画像メモリの取得および開放、ＨＤＤ２１０の利用等を行う。
ＮＣＳ３０３は、ＬＡＮ（ネットワーク）とアプリケーションモジュール層の各アプリケーションプログラムとの仲介処理を行わせるモジュールである。

ＦＣＳ３０４は、ファクシミリ送受信，ファクシミリ読み取り，ファクシミリ受信印刷等を行うモジュールである。
ＳＣＳ３０６は、コマンド（命令）の内容に応じたアプリケーションモジュール層の各アプリケーションプログラムの起動管理および終了管理を行うモジュールである。
ＳＲＭ３０７は、システムの制御およびリソースの管理を行うモジュールである。
ＩＭＨ３０８は、一時的に画像データを入れておくメモリを管理するモジュールである。

ＤＣＳ３１６は、ＨＤＤ２１０やＳＲＡＭ２０３，ＮＶＲＡＭ２０７に記憶している（する）画像ファイル等をＳＭＴＰ（Simple Mail Transfer Protocol）やＦＴＰ（File Transfer Protocol）を用いて送受信するモジュールである。
ＵＣＳ３１７は、ユーザ（機器利用者）が登録した宛先情報や宛名情報等のユーザ情報を管理するモジュールである。
コピーアプリ３０９は、コピーサービスを実現するためのアプリケーションプログラムである。
ファクスアプリ３１０は、ファクスサービスを実現するためのアプリケーションプログラムである。

プリンタアプリ３１１は、プリンタサービスを実現するためのアプリケーションプログラムである。
スキャナアプリ３１２は、スキャナサービスを実現するためのアプリケーションプログラムである。スキャナサービスとは、スキャナエンジンに原稿の画像を読み取らせ、その画像データをメモリ（ＳＤＲＡＭ２０３，ＮＶＲＡＭ２０７，又はＨＤＤ２１０）に記憶させるスキャン動作を制御することである。
ネットファイルアプリ３１３は、ネットファイルサービスを実現するためのアプリケーションプログラムである。

ウェブアプリ３１４は、ウェブサービスを実現するためのアプリケーションプログラムである。
メール通知アプリ３１８は、この発明によるメールサービスを実現するためのアプリケーションプログラムである。
ＮＲＳ３０５およびＣＳＳ３１５は、それぞれ異なる方式による遠隔管理に関する機能（管理装置１０２との通信に係わる機能）をまとめたモジュールである。
汎用ＯＳ３２０は、ＵＮＩＸ（登録商標），Ｌｉｎｕｘ（登録商標），Ｗｉｎｄｏｗｓ（登録商標）等のオペレーティングシステムを使用することができる。オペレーティングシステムは、サービスモジュール層やアプリケーションモジュール層のプログラムなどを実行させる処理を司る。ここで、ＵＮＩＸやＬｉｎｕｘを用いれば、オープンソースゆえの安全性が担保され、ソースコード入手の容易性などの利点がある。

次に、上述した画像形成装置１００のソフトウェアの構成に含まれるＮＲＳ３０５の内部構成について、図９を用いて更に説明する。
図９は、ＮＲＳ３０５の構成の一例を示す機能ブロック図である。同図に示すように、ＮＲＳ３０５は、ＳＣＳ３０６とＮＣＳ３０３との間で処理を行っている。ウェブサーバ機能部５００は、外部から受信した動作要求に関する応答処理を行う。

ここでの動作要求は、構造化言語であるＸＭＬ（Extensible Markup Language）形式で記載された、ＳＯＡＰ（Simple Object Access Protocol）によるＳＯＡＰリクエストである。
ウェブクライアント機能部５０１は、外部への動作要求を発行する処理を行う。
ｌｉｂｓｏａｐ５０２は、ＳＯＡＰを処理するライブラリであり、ｌｉｂｘｍｌ５０３は、ＸＭＬ形式で記載されたデータを処理するライブラリである。
ｌｉｂｇｗｗｗ５０４は、ＨＴＴＰを処理するライブラリであり、ｌｉｂｇｗ＿ｎｃｓ５０５は、ＮＣＳ３０３との間の処理をするライブラリである。

次に、仲介装置１０１の物理的構成について、図１０を参照して具体的に説明する。
図１０は、仲介装置１０１のハードウェア構成例を示すブロック図である。
この仲介装置１０１は、図１０に示すように、ＣＰＵ５２，ＳＤＲＡＭ５３，フラッシュメモリ５４（不揮発性メモリ），ＲＴＣ（内部時計であるリアルタイムクロック回路）５５，Ｏｐ−Ｐｏｒｔ（操作部接続ポート）５６，ＰＨＹ５７，モデム５８，ＨＤＤ制御部５９，拡張Ｉ／Ｆ６０，ＲＳ２３２Ｉ／Ｆ（インタフェース）６１，ＲＳ４８５Ｉ／Ｆ６２，ＨＤＤ６３等を備えている。

そして、ＣＰＵ５２は、フラッシュメモリ５４やＨＤＤ６３等の記憶手段から必要な制御プログラムを読み出し、ＳＤＲＡＭ５３等に展開して実行することにより、仲介装置１０１全体を制御し、この発明による通信制御手段（ＨＴＴＰ通信制御手段）としての機能を実現することができる。
ＳＤＲＡＭ５３は、ＯＳを含む各種プログラムを記憶するプログラムメモリや、ＣＰＵ５２がデータ処理を行う際に使用するワークメモリ等として使用するメインメモリである。

フラッシュメモリ５４は、例えば、仲介装置１０１を起動させるブートローダ（ブートプログラム）やＯＳのファイルであるＯＳイメージ及び後述する種々のプログラムを記憶するプログラムメモリ、種々の固定パラメータや、変更可能な種々のパラメータ（プロキシサーバＩＰアドレス，プロキシサーバログイン名，プロキシサーバログインパスワード、センタＵＲＬなど）を記憶するパラメータメモリ等として使用する不揮発性メモリ（記憶手段）であり、電源がオフになっても記憶内容を保持するようになっている。ＨＤＤ６３にも同様なデータを記憶させることができる。
ＲＴＣ５５は計時のための回路であり、Ｏｐ−Ｐｏｒｔ５６は図示しない操作部における操作を検出する回路である。

また、ＰＨＹ５７，モデム５８，ＲＳ４８５Ｉ／Ｆ６２は、それぞれＬＡＮ，公衆回線，ＲＳ４８５規格のシリアル通信によって通信を行うためのインタフェースである。
拡張Ｉ／Ｆ６０は、無線ＬＡＮボードや拡張メモリ等の拡張ボードを接続するためのＩ／Ｆである。
そして、この仲介装置１０１はＰＨＹ５７を介してＬＡＮ上の画像形成装置１００と接続され、またインタネット１０３に接続されている。また、画像形成装置１００とは、ＲＳ２３２Ｉ／Ｆ６１およびＲＳ４８５Ｉ／Ｆ６２を介しても接続可能である。なお、ＳＤＲＡＭ５３の代わりに、ＤＲＡＭやＳＲＡＭを使用してもよい。また、フラッシュメモリ５４の代わりに、ＥＥＰＲＯＭ等の他の不揮発性メモリを使用してもよい。

次に、管理装置１０２の物理的構成について、図１１を参照して具体的に説明する。
図１１は、管理装置１０２の概略構成例を示すブロック図である。
この管理装置１０２は、モデム１２１，通信端末１２２，プロキシ（Ｐｒｏｘｙ）サーバ１２３，操作者端末１２４，データベース１２５，および制御装置１２６等によって構成されている。

モデム１２１は、公衆回線を介して機器利用者側（例えば画像形成装置を利用しているユーザ先）の仲介装置１０１，ラインアダプタ，および画像形成装置１１０との通信を司るものであり、送受信するデータを変復調する。このモデム１２１と通信端末１２２により通信手段としての機能を果たす。
通信端末１２２は、モデム１２１による通信を制御するものである。
プロキシサーバ１２３は、インタネット１０３を介して機器利用者側の仲介装置１０１との通信（データ送受信）およびセキュリティ管理を行う。このプロキシサーバ１２３も、通信手段としての機能を果たす。

操作者端末１２４は、サービスセンタ内の管理装置１０２のオペレータであるセンタオペレータが操作する端末装置（パーソナルコンピュータ等）であり、各種データの入力をセンタオペレータによるキーボードやポインティングデバイス（マウス等）等の入力装置上の操作により受け付けたり、センタオペレータに通知すべき情報をＬＣＤ又はＣＲＴ等の表示部に表示したりする。入力されるデータとしては、例えば、各機器利用者側の仲介装置１０１，画像形成装置１１０，ラインアダプタと通信する際に使用するＩＰアドレスや発呼先電話番号等の顧客情報がある。
データベース１２５は、図示しないデータベースサーバのハードディスク装置等の記憶装置に存在し、仲介装置１０１，画像形成装置１１０等のＩＰアドレスや電話番号、それらの装置から受信した異常情報等のデータ、操作者端末１２４から入力されたデータ等の各種データを記憶する。

制御装置１２６は、図示しないＣＰＵ，ＲＯＭ，ＲＡＭ等からなるマイクロコンピュータを備えており、管理装置１０２全体を統括的に制御する。そのＣＰＵが、ＲＯＭ等に記憶している制御プログラムを必要に応じて実行すると共に、モデム１２１，通信端末１２２，プロキシサーバ１２３，操作者端末１２４，又はデータベース１２５を利用することにより、この発明による通信制御手段（ＨＴＴＰ通信制御手段）としての機能を実現することができる。
なお、管理装置１０２の構成はこれに限られることはなく、例えば１台のＰＣ（パーソナルコンピュータ）等の情報処理装置を用いて構成することもできる。

上述した構成を踏まえて、図３の画像形成装置遠隔管理システムで行われるデータ送受信の際の通信シーケンスの一例について説明する。なお、以下に示すＮＲＳ３０５等のプログラムによる処理は、実際にはＣＰＵ２０１がそれらのプログラムに従って動作することによって実行するが、説明の都合上、それらのプログラムが処理を実行するものとする。以後も、プログラムが何らかの処理を行うものとして説明を行う場合には、同様とする。
図１２は、図３に示した管理装置１０２，仲介装置１０１，および画像形成装置１００間で行われるデータ送受信の際の通信シーケンスの一例を示す図である。

この例においては、まず、仲介装置１０１は、インタネット１０３経由で管理装置１０２に対して定期的に所定のＨＴＴＰリクエスト（例えばＳＯＡＰリクエストが含まれていないもの）をインタネット１０３経由で管理装置１０２へ送信する。この所定のＨＴＴＰリクエストを定期ＨＴＴＰリクエストという。図３に示したように、仲介装置１０１と管理装置１０２との間にはファイアウォール１０４を設けているため、管理装置１０２から仲介装置１０１に向けて通信セッションを張ることができないので、管理装置１０２から仲介装置１０１（あるいは仲介装置１０１を介して画像形成装置１００）に要求を送信したい場合でも、このように仲介装置１０１からの定期ＨＴＴＰリクエストを待つ必要があるのである。なお、ファイアウォール１０４がなければ、あるいは外部からの通信を許可する設定を行っていれば、定期ＨＴＴＰリクエストを送信する必要はない。

管理装置１０２は、いずれかの画像形成装置１００の課金カウンタ（例えばトータルカウンタ値に相当する）を取得する場合、その課金カウンタの取得を要求する課金カウンタ取得要求のＳＯＡＰリクエストを含むＨＴＴＰレスポンスを生成する。このとき、課金カウンタ取得要求を構造化言語形式であるＸＭＬ形式に変換し、それをＳＯＡＰリクエストに記載する。そして、該当する仲介装置１０１（課金カウンタ取得先の画像形成装置１００が接続されている仲介装置１０１）から定期ＨＴＴＰリクエストを受信した時に、生成しておいた課金カウンタ取得要求のＳＯＡＰリクエストを含むＨＴＴＰレスポンスをインタネット１０３経由で該当する仲介装置１０１へ送信する（Ｓ６０２）。このように、ファイアウォール１０４の内側からのＨＴＴＰリクエストに対するＨＴＴＰレスポンスであれば、ファイアウォール１０４の外側から内側に対してデータを送信することができる。

仲介装置１０１は、管理装置１０２への定期ＨＴＴＰリクエストに対してその管理装置１０２から課金カウンタ取得要求のＳＯＡＰリクエストを含むＨＴＴＰレスポンスを受信すると、そのＳＯＡＰリクエストを含むＨＴＴＰリクエストを生成し、それをＬＡＮ経由で該当する画像形成装置１００（課金カウンタ取得先）へ送信する（Ｓ６０３）。
その画像形成装置１００のＮＲＳ３０５は、仲介装置１０１から課金カウンタ取得要求のＳＯＡＰリクエストを含むＨＴＴＰリクエストをＮＣＳ３０３によって受信する（ＮＣＳ３０３から課金カウンタ取得要求のＳＯＡＰリクエストを受け取る）と、そのＳＯＡＰリクエストに記述されている課金カウンタ取得要求をＳＣＳ３０６へ通知する（Ｓ６０４）。

ここで、ＮＣＳ３０３は、ＨＴＴＰクライアントおよびＨＴＴＰサーバとしての機能を有しており、仲介装置１０１から送られてくるＨＴＴＰリクエスト（又はＨＴＴＰレスポンス）を受信し、そのＨＴＴＰリクエストに含まれている（記載されている）ＳＯＡＰリクエスト（ＳＯＡＰレスポンス）をＮＲＳ３０５へ送る。また、ＮＲＳ３０５から送られてくるＳＯＡＰレスポンス（ＳＯＡＰリクエスト）を受け取ると、それをＨＴＴＰレスポンス（又はＨＴＴＰリクエスト）に変換して（ＨＴＴＰレスポンスに記載して）仲介装置１０１へ送信する。
ＳＣＳ３０６は、ＮＲＳ３０５から課金カウンタ取得要求を受け取ると、ＮＶＲＡＭ２０７（ＨＤＤ２１０でもよい）に格納されている課金カウンタのデータ（トータルカウンタ値）を読み取る（Ｓ６０５）。そして、その読み取った課金カウンタのデータを課金カウンタ取得応答としてＮＲＳ３０５へ引き渡す（Ｓ６０６）。

ＮＲＳ３０５は、ＳＣＳ３０６から課金カウンタ取得応答を受け取る（取得する）と、その課金カウンタ取得応答を含む課金カウンタ取得応答のＳＯＡＰレスポンスを生成する。つまり、課金カウンタ取得応答を構造化言語形式であるＸＭＬ形式に変換し、それをＳＯＡＰレスポンスに記載する。そして、生成した課金カウンタ取得応答のＳＯＡＰレスポンスをＮＣＳ３０３に送ってＨＴＴＰレスポンスに変換させ（課金カウンタ取得応答のＳＯＡＰレスポンスをＨＴＴＰレスポンスに記載させ）、それをＬＡＮ経由で仲介装置１０１へ送信させる（Ｓ６０７）。
仲介装置１０１は、該当する画像形成装置（自己に接続されている画像形成装置）１００から課金カウンタ取得応答のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信すると、そのＨＴＴＰレスポンスをインタネット１０３経由で管理装置１０２へ送信する（Ｓ６０８）。
このように、上記通信シーケンスにより、データの送受信が行われる。

次に、上記図１２と異なり、画像形成装置１００から仲介装置１０１を経て管理装置１０２へデータを送信する場合の通信シーケンスの一例について、図１３を参照して説明する。
図１３は、画像形成装置１００から管理装置１０２へデータを送信する場合の通信シーケンスの一例を示す図である。
この例においては、まず、画像形成装置１００のＯＣＳ３００は、操作部２０９上の図示しないユーザコールキーが押下された旨をＳＣＳ３０６へ通知する（Ｓ７０１）。
そのＳＣＳ３０６は、ＯＣＳ３００からユーザコールキーが押下された旨の通知を受けると、ユーザコールの発行要求（発行依頼）をＮＲＳ３０５へ通知する（Ｓ７０２）。このとき、ユーザコールの発行要求に、画像形成装置１００の識別情報である機種機番を付加する。同時に、ユーザコールの内容をＮＶＲＡＭ２０７（ＨＤＤ２１０でもよい）に保存（記憶）する。

ＮＲＳ３０５は、ＳＣＳ３０６からユーザコールの発行要求を受け取ると、ユーザコールのＳＯＡＰリクエストを生成し、それを含む送信処理の要求（依頼）をＮＣＳ３０３に通知してＨＴＴＰリクエストに変換させ、それ（ユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエスト）をＬＡＮ経由で仲介装置１０１へ送信させる（Ｓ７０３）
仲介装置１０１は、ユーザコールキーが押下された画像形成装置（該当する画像形成装置）１００からユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを受信すると、そのＳＯＡＰリクエストに自己の識別情報である識別子を付加して、そのＳＯＡＰリクエストを含むＨＴＴＰリクエストを生成し、インタネット１０３経由で管理装置１０２に対してユーザコールを行う（Ｓ７０４）。通常は、自己の識別子を付加したユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストはインタネット１０３経由で管理装置１０２へ通報される。

この場合には、ファイアウォール１０４の内側から外側に向けての送信であるので、仲介装置１０１が自ら管理装置１０２に向けてセッションを張ってデータを送信することができる。
ここで、ステップＳ７０４の処理後のパターンを以下の（Ａ）から（Ｃ）に分けて説明する。

まず、（Ａ）において、管理装置１０２は、ユーザ先の仲介装置１０１からユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを受信し、その受信が正常に終了した場合にはユーザコールが成功した旨を示すコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、正常に終了しなかった場合にはユーザコールが失敗した旨を示すコール結果（失敗理由を特定するための情報、例えば管理装置１０２の不具合を示す情報を付加する）のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ生成し、それをインタネット１０３経由で通報元の仲介装置１０１へ送信する（Ｓ７０５）。

仲介装置１０１は、管理装置１０２へユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを送信してから予め設定された所定時間を経過するまでの間に、管理装置１０２からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信した場合には、そのＨＴＴＰレスポンスをＬＡＮ経由で該当する画像形成装置１００へ送信する（Ｓ７０６）。なお、コール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信した場合でも、そのＳＯＡＰレスポンスがユーザコールが失敗した旨を示すものであれば、そのＳＯＡＰレスポンスは正常なレスポンスでないものとする。
該当する画像形成装置１００のＮＲＳ３０５は、仲介装置１０１からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをＮＣＳ３０３によって受信する（ＮＣＳ３０３からコール結果のＳＯＡＰレスポンスを受け取る）と、そのＳＯＡＰレスポンスに記述されているコール結果をＳＣＳ３０６へ通知する（Ｓ７０７）。

ＳＣＳ３０６は、コール結果を受け取ると、そのコール結果をＯＣＳ３００へ通知する（引き渡す）と共に、そのコール結果の内容をＮＶＲＡＭ２０７（ＨＤＤ２１０でもよい）の先に保存したユーザコールの内容に付加する。このとき、コール結果の内容がユーザコールの失敗を示すものであれば、その失敗の理由もＮＶＲＡＭ２０７に保存する。この場合のユーザコール失敗の理由は、コール結果の内容から特定（判断）できる。例えば、コール結果に付加されている失敗理由を特定するための情報がサービスセンタ内の管理装置１０２の不具合である旨を示す情報であった場合には、管理装置１０２の不具合が失敗理由と特定できる。
その不具合としては、例えば、プロキシサーバ１２３のダウンがある。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容を示すメッセージを操作部２０９上の文字表示器に表示する（Ｓ７０８）。

次に（Ｂ）において、仲介装置１０１は、ユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを管理装置１０２へ送信してから予め設定された所定時間が経過するまでの間に、管理装置１０２からＨＴＴＰレスポンスを受信できなかった場合（管理装置１０２へのユーザコールのＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に含まれる）には、タイムアウトを検出してユーザコールが失敗した旨を示すコール結果（失敗理由を特定するための情報、例えば仲介装置１０１でタイムアウト検出した旨を示す情報を付加する）のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを生成し、それをＬＡＮ経由で該当する画像形成装置（ユーザコールキーが押下された画像形成装置）１００へ送信する（Ｓ７０９）。

その画像形成装置１００のＮＲＳ３０５は、仲介装置１０１からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをＮＣＳ３０３によって受信すると、そのＳＯＡＰレスポンスに記述されているコール結果をＳＣＳ３０６へ通知する（Ｓ７１０）。
ＳＣＳ３０６は、ＮＲＳ３０５からコール結果を受け取ると、それをＯＣＳ３００へ通知すると共に、そのコール結果の内容をＮＶＲＡＭ２０７の先に保存したユーザコールの内容に付加する。このとき、コール結果の内容はユーザコールの失敗を示すものでなので、その失敗の理由もＮＶＲＡＭ２０７に保存する。この場合のユーザコール失敗の理由は、コール結果の内容から特定できる。例えば、コール結果に付加されている失敗理由を特定するための情報が仲介装置１０１でタイムアウト検出した旨を示す情報であった場合には、仲介装置１０１と管理装置１０２との間の通信路上の不具合あるいはセンタの営業時間外が失敗理由と特定できる。

その不具合としては、例えば、仲介装置１０１に対するプロキシ設定ミス（プロキシサーバログイン名やプロキシサーバログインパスワードの設定ミス）や、プロキシサーバ（ファイアウォール１０４）のダウンがある。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容を示すメッセージを操作部２０９上の文字表示器に表示する（Ｓ７１１）。

次に（Ｃ）において、ＮＲＳ３０５は、ＮＣＳ３０３によってユーザコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを送信させて（ＮＣＳ３０３へユーザコールのＳＯＡＰリクエストを通知して）から所定時間が経過するまでの間に、仲介装置１０１からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをＮＣＳ３０３によって受信できなかった場合（ＮＣＳ３０３からコール結果のＳＯＡＰレスポンスを受け取れなかった場合）には、タイムアウトを検出してユーザコールの失敗を認識し、その旨（失敗理由を特定するための情報、例えばＮＲＳ３０５でタイムアウト検出した旨を示す情報を付加する）をコール結果としてＳＣＳ３０６へ通知する（ステップＳ７１２）。

ＳＣＳ３０６は、そのコール結果を受けると、それをＯＣＳ３００へ通知すると共に、そのコール結果の内容をＮＶＲＡＭ２０７の先に保存したユーザコールの内容に付加する。このとき、コール結果の内容はユーザコールの失敗を示すものなので、その失敗の理由もＮＶＲＡＭ２０７に保存する。この場合のユーザコール失敗の理由も、コール結果の内容から特定できる。例えば、コール結果に付加されている失敗理由を特定するための情報がＮＲＳ３０５でタイムアウト検出した旨を示す情報であった場合には、画像形成装置１００と仲介装置１０１との間の通信路上の不具合が失敗理由と特定できる。
その不具合としては、例えば、画像形成装置１００と仲介装置１０１との間のＬＡＮケーブルの抜け、仲介装置１０１のダウンがある。

なお、仲介装置１０１が上述したタイムアウト検出機能を備えていない場合（ユーザコールが失敗した旨を示すコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを生成して該当する画像形成装置１００へ送信することができない場合）には、ＳＣＳ３０６は、画像形成装置１００と仲介装置１０１との間の通信路上の不具合がユーザコール失敗の理由と特定することはできない。この場合は、画像形成装置１００と管理装置１０２との間の通信路上の不具合が失敗理由と特定できる。
ＯＣＳ３００は、ＳＣＳ３０６からコール結果を受け取ると、その内容を示すメッセージを操作部２０９上の文字表示器に表示する（Ｓ７１３）。

ここでは、管理装置１０２からファイアウォール１０４を越えて仲介装置１０１（あるいは仲介装置１０１を介して画像形成装置１００）にデータを送信するために、仲介装置１０１からのＨＴＴＰリクエストに対するレスポンスという形で送信を行う例について説明したが、ファイアウォール１０４を越える手段はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）を利用して、送信したいデータを記載あるいは添付したメールを管理装置１０２から仲介装置１０１に送信することも考えられる。ただし、信頼性の面ではＨＴＴＰが優れている。
以上、ユーザコールに関する処理（制御）について説明したが、ＳＣコールやサプライコール等の他のコールに関する制御も略同様である。また、実際には、それらのコールに関する制御には後述するメール通知処理も含まれるが、それについては追って詳細に説明する。

ここで、画像形成装置１００は、エンジン部２１７や操作部２０９等の各ハードウェア資源を制御するＣＰＵ２０１が、その各ハードウェア資源の状態を監視し、いずれかのハードウェア資源で異常等の所定の事象が発生した場合、その事象を検出し、その事象の種類によって異なる処理を行う。よって、事象の種類を判定するための基準となる情報が必要であり、図１４の例は事象（異常）の種類を判定するための基準となる情報（基準情報）の一例を示すテーブルのデータ構造を示している。ここで、「ＳＣ（サービスマンコール）」は「異常」に相当するものである。同図に示すように、検出されたＳＣによって種類（タイプ）が判定される。そこで、それぞれの種類について説明する。

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

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

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

以下、画像形成装置１００，仲介装置１０１，および管理装置１０２におけるこの実施例の特徴となる処理およびデータについて、図１５〜図３０を参照して具体的に説明する。なお、画像形成装置１００と仲介装置１０１が行う処理は、仲介装置１０１としての機能を有する画像形成装置１１０でも行えるが、その説明は省略する。

図１５は、画像形成装置１００における各ソフトウェア（プログラム）とそれらによるＳＣコールに関する処理の流れの一例を示す図である。
図１６は、画像形成装置遠隔管理システムを構成する各装置とそれらによるＳＣコールに関する処理の流れの一例を示す図である。
なお、図１５，図１６における複数の丸付き数字は処理等の順番を示すステップ番号であり、その各丸付き数字の一部と後述する図１７における丸付き数字が対応している。
また、ここでは仲介装置１０１がタイムアウト検出機能を備えていないものとする。

画像形成装置１００では、図１５に示すように、エンジン部２１７を構成するプロッタエンジンおよびスキャナエンジンを含む各エンジンユニットのいずれかで異常（ＳＣ）が発生すると、対応するセンサ（異常検出部）によってそのＳＣを検出し、ＳＣが発生した旨をＳＣＳ３０６へ通知する（ステップＳ１）。
ＳＣＳ３０６は、いずれかのエンジンユニットからＳＣが発生した旨の通知を受けることにより、そのＳＣを検出（判定）し、その内容（ＳＣの種類や箇所に対応するＳＣ番号等）を判別して、ＳＣコールの発行依頼（発行要求）をＮＲＳ３０５へ通知する（ステップＳ２）。このとき、そのＳＣコールの発行依頼に、ＳＣの内容と画像形成装置１００の識別情報である機種機番を付加する。同時に、ＳＣコールの内容をＮＶＲＡＭ２０７（ＨＤＤ２１０でもよい）に保存する。

ここで、ＳＣコール（異常通報）発行時にＮＶＲＡＭ２０７に記憶されるＳＣコールの内容とそのコールの結果について、図１７を参照して説明する。
図１７は、ＳＣコール（異常通報）発行時にＮＶＲＡＭ２０７に記憶されるＳＣコールの内容とそのコールの結果の一例を示す図である。
この例では、コール種別が「ＳＣコール」、ＳＣ番号が「１２０」、コール結果が「センタ失敗」となっている。そのうち、コール種別「ＳＣコール」およびＳＣ番号「１２０」は、ＳＣコールの内容を示している。コール結果「センタ失敗」は、サービスセンタ内の管理装置１０２における何らかの不具合によってＳＣコールが失敗したことを示している。このコール結果は、ＳＣコールの発行直後ではなく、その後のコール結果判明時にＮＶＲＡＭ２０７に記憶される（先に記憶されたＳＣコールに付加される）が、これについては後述する。

また、サプライコール（サプライ発注）発行時にＮＶＲＡＭ２０７に記憶されるサプライコールの内容とそのコールの結果について、図１８を参照して説明する。
図１８は、サプライコール（サプライ発注）発行時にＮＶＲＡＭ２０７に記憶されるサプライコールの内容とそのコールの結果の一例を示す図である。
この例では、コール種別が「サプライコール」、サプライ種類が「トナー」、コール結果が「通信路失敗」となっている。そのうち、コール種別「サプライコール」およびサプライ種類「トナー」は、サプライコールの内容を示している。コール結果「通信路失敗」は、仲介装置１０１と管理装置１０２との間の通信路上の不具合あるいは画像形成装置１００と仲介装置１０１との間の通信路上の不具合によってサプライコールが失敗したことを示している。このコール結果も、上述と同様に、サプライコールの発行直後ではなく、その後のコール結果判明時にＮＶＲＡＭ２０７に記憶される。

図１５，図１６の説明に戻る。
ＮＲＳ３０５は、ＳＣＳ３０６からＳＣコールの発行依頼を受けると、そのＳＣコールのＳＯＡＰリクエスト（ＳＣコールの発行依頼に付加されたＳＣの内容と機番情報を含む）を生成し、それを含む送信処理の依頼をＮＣＳ３０３に通知してＨＴＴＰリクエストに変換させ、それ（ＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエスト）をＬＡＮ６００経由で仲介装置１０１へ送信させる（ステップＳ３，Ｓ４）。
仲介装置１０１は、ＳＣが発生した（該当する）画像形成装置１００からＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを受信すると、そのＳＯＡＰリクエストに自己の識別情報である識別子を付加して、そのＳＯＡＰリクエストを含むＨＴＴＰリクエストを生成し、インタネット１０３経由で管理装置１０２に対してユーザコールを行う。この場合、通常は、自己の識別子を付加したＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストは、例えば図２１に示すようなフォーマットでインタネット１０３経由で管理装置１０２へ通報される。

ここで、ＳＣコールのＳＯＡＰリクエスト（仲介装置１０１の識別子は除く）のフォーマットについて、図２１，図２２を参照して説明する。
図２１はＳＣコールのＳＯＡＰリクエスト（仲介装置１０１の識別子は除く）のフォーマット例を、図２２にその主要部分（データ）の構成をそれぞれ示す図である。
ＳＣコールのＳＯＡＰリクエストは、前述したように構造化言語によるＸＭＬ形式で記述することができる。

図２１，図２２を見て分かるように、ＳＣコールのＳＯＡＰリクエストは、該当する（ＳＣが発生した）画像形成装置１００の識別情報（識別子）である機種機番（デバイスＩＤ）、コールがＳＣコールであることを示すコール種別（コールタイプ）、コールの番号を示すコールＩＤ、コールの詳細を示すＳＣ番号（サプライコールの場合はトナー等を示すサプライ種類）の情報を含む。また、図示は省略するが、該当する画像形成装置１００のジャムやＳＣ，ステータス（状態），カウンタのそれぞれの値およびログ（履歴情報）等の情報を含めることもできる。異常（ＳＣ）の種類毎にＳＣ番号は異なるため、ＳＣコールのＳＯＡＰメッセージは、異常の種類毎に異なる情報となる。
なお、管理装置１０２側では、ＳＣ番号とＳＣタイプとの対応関係を記憶しておけば、ＳＣ番号をキーとしてＳＣタイプを判断することができるが、ＳＣコールのＳＯＡＰリクエストにＳＣタイプを含めてもよい。

再び図１５，図１６の説明に戻る。
管理装置１０２は、ユーザ先の仲介装置１０１からＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを受信し、その受信が正常に終了した場合にはＳＣコールが成功した旨を示すコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、正常に終了しなかった場合にはＳＣコールが失敗した旨を示すコール結果（失敗理由を特定するための情報を付加する）のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ生成し、それをインタネット１０３経由で通報元の仲介装置１０１へ送信する。

仲介装置１０１は、管理装置１０２へのＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストに対して、管理装置１０２からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信すると、そのＨＴＴＰレスポンスをＬＡＮ６００経由で該当する画像形成装置１００へ送信する。なお、コール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信した場合でも、そのＳＯＡＰレスポンスがＳＣコールが失敗した旨を示すものであれば、そのＳＯＡＰレスポンスは正常なレスポンスでないものとする。

該当する画像形成装置１００のＮＣＳ３０３は、仲介装置１０１からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信すると、そのＳＯＡＰレスポンスをＮＲＳ３０５へ通知する。
該当する画像形成装置１００のＮＲＳ３０５は、ＳＣコールのＳＯＡＰリクエストを含む送信処理依頼をＮＣＳ３０３へ通知してから所定時間を経過するまでの間に、ＮＣＳ３０３からコール結果のＳＯＡＰレスポンスを受け取ると、そのＳＯＡＰレスポンスに記述されているコール結果をＳＣＳ３０６へ通知する。このとき、ＮＣＳ３０３へ通知したＳＣコールのＳＯＡＰリクエストのＳＯＡＰボディに記載されているＳＣコールの内容をＳＯＡＰ電文のままＳＣＳ３０６へ通知する処理も行う。なお、そのＳＯＡＰ電文の通知は必ずしも行う必要はない。

しかし、例えばプロキシ設定ミスによる通信路の不具合により、ＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストがファイアウォール１０４（プロキシサーバ）で遮断される通信エラーが発生すると（ステップＳ５）、上記送信処理依頼をＮＣＳ３０３へ通知して所定時間を経過（タイムアウト）してもコール結果のＳＯＡＰレスポンスをＮＣＳ３０３から受け取ることはできない。その場合、タイムアウトを検出してＳＣコールの失敗を認識し、その旨（失敗理由を特定するための情報を付加する）をコール結果としてＳＣＳ３０６へ通知する（ステップＳ７）。このとき、ＮＣＳ３０３へ通知したＳＣコールのＳＯＡＰリクエストのＳＯＡＰボディに記載されているＳＣコールの内容をＳＯＡＰ電文のままＳＣＳ３０６へ通知する処理も行う。なお、仲介装置１０１のダウンや仲介装置１０１との間のＬＡＮケーブル外れによる通信路の不具合により、ＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストが仲介装置１０１で遮断される通信エラーが発生した場合でも、上述と同様にタイムアウトを検出できる。

なお、仲介装置１０１は、タイムアウト検出機能を備えている場合には、ＳＣコールのＳＯＡＰリクエストを含むＨＴＴＰリクエストを管理装置１０２へ送信してから所定時間を経過するまでの間に、管理装置１０２からＨＴＴＰレスポンスを受信できなかった場合（管理装置１０２へのユーザコールのＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合）に、タイムアウトを検出してＳＣコールの失敗を認識し、その旨（失敗理由を特定するための情報、例えば仲介装置１０１でタイムアウト検出した旨を示す情報を付加する）を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを生成し、それをＬＡＮ６００経由で該当する画像形成装置１００へ送信する。

その画像形成装置１００のＮＣＳ３０３は、仲介装置１０１からコール結果のＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを受信すると、そのＳＯＡＰレスポンスをＮＲＳ３０５へ通知する。
そのＮＲＳ３０５は、ＮＣＳ３０３からコール結果のＳＯＡＰレスポンスを受信すると、そのＳＯＡＰレスポンスに記述されているコール結果をＳＣＳ３０６へ通知する。このとき、ＮＣＳ３０３へ通知したＳＣコールのＳＯＡＰリクエストのＳＯＡＰボディに記載されているＳＣコールの内容をＳＯＡＰ電文のままＳＣＳ３０６へ通知するか、そのＳＯＡＰ電文に上記ＳＯＡＰレスポンスに記述されているコール結果を加えてＳＣＳ３０６へ通知する処理も行うが、そのＳＯＡＰ電文通知は必ずしも行う必要はない。

ＳＣＳ３０６は、ＮＲＳ３０５からコール結果およびＳＯＡＰ電文を受け取ると、そのコール結果であるＳＣコールの成功又は失敗を示す情報（失敗していれば失敗理由を特定するための情報から特定した失敗理由を加える）をＮＶＲＡＭ２０７の先に保存したＳＣコールの内容に付加した（図１７参照）うえで、そのＳＣコールの内容を読み出し、それをＳＯＡＰ電文と共にメール通知アプリ３１８へ通知する（ステップＳ８）。
そのメール通知アプリ３１８は、ＳＣＳ３０６からＳＣコールの内容とＳＯＡＰ電文を受け取ると、そのＳＣコールの内容に含まれているコール結果とＮＶＲＡＭ２０７内のデータ（メール通知に関する設定内容）とに基づいて、今回受け取ったＳＣコールの内容はメール通知対象か否かを判断する。

ここで、ＮＶＲＡＭ２０７に記憶（保存）されているメール通知に関する設定内容について、図２３，図２４を参照して説明する。
図２３は、ＮＶＲＡＭ２０７に記憶（保存）されているメール通知に関する設定内容（一部分）の一例を示す図である。
このメール通知に関する設定内容は、種々のメールイベントとメール通知の有効／無効の設定状態と宛先（メール通知先）とからなる。

この例では、メールイベントとして、ＳＣコール成功，ＳＣコール営業時間外，ＳＣコール失敗（センタ理由），ＳＣコール失敗（通信路理由），サプライコール成功，サプライコール失敗（センタ理由），サプライコール失敗（通信路理由），ライン外れがある。
その各メールイベントに対して、メール通知の有効／無効の設定と宛先（管理者，庶務担当，ＩＴ担当のうちのいずれか１つ又は複数）を独立して設定することができる。

但し、ＳＣコール営業時間外，ＳＣコール失敗（センタ理由），ＳＣコール失敗（通信路理由），サプライコール失敗（センタ理由），サプライコール失敗（通信路理由），ライン外れに対してはそれぞれ、通常はメール通知が行えるようにデフォルトでメール通知が有効と設定（登録）されている。また、各コール失敗およびライン外れのいずれかに対してメール通知が有効と設定された場合には、管理装置１０２に対して確実にメール通知が行われるように、宛先としてセンタ（管理装置１０２に相当する）のアドレスが設定される。
各メールイベントに対しては、複数の宛先グループを設定してその内容をＮＶＲＡＭ２０７に記憶することもできる。

図２４は、その複数の宛先グループの設定内容（ＮＶＲＡＭ２０７に記憶されているメール通知に関する設定内容の残りの部分）を示す図である。
各宛先グループはそれぞれ、宛先グループ番号と宛先グループ名称と宛先とからなる。それらのうち、宛先グループ名称は、デフォルト名称としてグループ１〜４が設定されるが、図２４に示すようにグループ１〜３を任意の名称（ここでは管理者，庶務担当，ＩＴ担当）に変更することができる。また、宛先グループ（管理者，庶務担当，ＩＴ担当）毎にそれぞれ複数の宛先のアドレスを入力することができる。但し、メール通知を行う際に使用できるアドレス（設定できるアドレス）は、宛先グループ毎に１つのみである。また、上述したように、各コール失敗およびライン外れに対してはそれぞれ、管理装置１０２に対して確実にメール通知が行われるように、ここでは宛先グループ「５」に対してセンタのアドレスがデフォルト設定されている。なお、そのデフォルト設定を他の宛先グループ番号に対して行っていてもよい。また、宛先グループを増やすこともできる。

図１５，図１６の説明に戻る。
ＳＣＳ３０６は、今回受け取ったＳＣコールの内容がメール通知対象（メール通知有効）であれば、次の処理を行う。
すなわち、メール本文を生成するため、ＳＣＳ３０６から受信したＳＣコールの内容に対応するメール本文をＨＴＴＰ・ＧＥＴでローカルホスト（local host）に相当するウェブアプリ３１４のメール本文生成用ＵＲＬから取得する（ステップＳ９）。
ここで、そのメール本文生成用ＵＲＬについて、図１９，図２０を参照して説明する。

図１９は、ＳＣコール失敗時にメール通知アプリ３１８がウェブアプリ（Ｗｅｂｓｙｓ）３１４からＥメール（以下単に「メール」ともいう）本文を取得するためのＵＲＬ（Uniform Resource Locator）であるメール本文生成用ＵＲＬの一例を示す図である。
このＵＲＬのうち、「127.0.0.1」はローカルホスト（local host）を示しており、メール通知アプリ３１８に予め設定されている。なお、「127.0.0.1」を「local host」としてもよい。「event_type=NRS_ML_SC_CENTER_FAILURE＆event_sc_no=120」は、図１７によって説明したＳＣコールの内容とそのコールの結果（センタ失敗）を示している。

図２０は、サプライコール失敗時にメール通知アプリ３１８がウェブアプリ３１４からメール本文を取得するためのＵＲＬの一例を示す図である。
このＵＲＬのうち、「NRS_ML_SUPPLY_COMMUNICATION_PATH_FAILURE＆event_supply_kind=TONER」は、図１８によって説明したサプライコールの内容とそのコールの結果（通信路失敗）を示している。

さらに、メール本文生成用ＵＲＬの取得処理（読み込み処理）について、もう少し詳しく説明する。
メール通知アプリ３１８は、ＳＣＳ３０６から受信したＳＣコールの内容（コール結果を含む）に基づいて図１９によって説明したようなメール本文生成用ＵＲＬを生成し、それをＨＴＴＰ・ＧＥＴコマンドでウェブアプリ３１４へ送信する。ウェブアプリ３１４は、ＨＴＴＰ・ＧＥＴコマンドでメール本文生成用ＵＲＬを受け取ると、そのＵＲＬから対応するページ情報をメール本文として取得し、それをメール通知アプリ３１８へ送信する。よって、メール通知アプリ３１８は、ＳＣＳ３０６から受信したＳＣコールの内容に対応するメール本文を取得することができる。

図２５は、テキスト形式のメール本文の一例を示す図である。
図２６は、ＸＭＬ形式のメール本文の一例を示す図である。
メール通知アプリ３１８は、ＳＣＳ３０６からＳＣコールの内容と共にＳＯＡＰ電文を受信している場合には、例えば図２６に示すように、そのＳＯＡＰ電文をＸＭＬ形式のメール本文に貼り付けることもできる。ＸＭＬ形式のメール本文は、管理装置１０２で処理できるため、管理装置１０２へ通知するとよい。

図１５，図１６の説明に戻る。
メール通知アプリ３１８は、ＳＣＳ３０６から受信したＳＣコールの内容に対応するページ情報をメール本文として取得した後、ＮＶＲＡＭ２０７から対応するメール通知先（宛先）のアドレスを取得し（ステップＳ１０）、メール通知（メール送信）依頼をＤＣＳ３１６へ通知する（ステップＳ１１）。このとき、そのメール通知依頼に、先に取得したメール通知先のアドレスとメール本文とを付加する。
ＤＣＳ３１６は、メール通知アプリ３１８からメール通知依頼を受けると、ＮＣＳ３０３に対してメール通知処理を行う（ステップＳ１２）。このとき、メール通知依頼に付加されているメール通知先のアドレスとメール本文とをＮＣＳ３０３へ通知する。
ＮＣＳ３０３は、ＤＣＳ３１６から受け取ったメール通知先のアドレスとメール本文とを含むＥメール（電子メール）をＬＡＮ６００経由でＳＭＴＰ(Simple Mail Transfer Protocol)サーバ６０１へ送信（通知）する。

ＳＭＴＰサーバ６０１に送られたＥメールは、メール通知依頼に付加されているメール通知先のアドレスが管理装置１０２のアドレスであれば、ＳＭＴＰサーバ６０１からＬＡＮ６００およびファイアウォール１０４を通り、更にインタネット１０３を通ってサービスセンタ１００へ送られる。そして、サービスセンタ１００内のファイアウォール７０１およびＬＡＮ７００を通ってＳＭＴＰサーバ７０２へ送られ、そこからＬＡＮ７００およびＰＯＰ(Post Office Protocol)サーバ７０３を通って管理装置１０２へ送られる。

また、ＳＭＴＰサーバ６０１に送られたＥメールは、メール通知先のアドレスがユーザ側の管理者，ＩＴ担当者，又は庶務担当等のユーザメール端末（パーソナルコンピュータ等の情報処理装置）６０３のアドレスであれば、ＬＡＮ６００経由でユーザ側のＳＭＴＰサーバ６０１に一旦送られ、そこからユーザ側のＰＯＰサーバ６０２およびＬＡＮ６００を通って上記ユーザメール端末６０３へ送られる。
なお、ＳＭＴＰサーバ６０１およびＰＯＰサーバ６０２は、画像形成装置１００とファイアウォール１０４との間ではなく、ファイアウォール１０４とインタネット１０３との間に設置されていてもよい。また、ＳＭＴＰサーバ７０２およびＰＯＰサーバ７０３は、ファイアウォール７０１と管理装置１０２との間ではなく、ファイアウォール７０１とインタネット１０３との間に設置されていてもよい。

図２７は、この画像形成装置１００の各ソフトウェアによるＳＣコールに関する処理の一例を示すフローチャートである。
なお、図２７の丸付き数字（ステップ番号）は、図１５〜図１７の丸付き数字に対応している。
画像形成装置１００では、エンジン部２１７で異常（ＳＣ）が発生すると、対応するセンサによってそのＳＣを検出し、ＳＣが発生した旨をＳＣＳ３０６へ通知する（ステップＳ１）。

ＳＣＳ３０６は、ＳＣが発生した旨の通知を受けることにより、そのＳＣを検出してその内容を判別し、ＳＣコールの発行をＮＲＳ３０５へ依頼すると同時に、そのＳＣコールの内容をＮＶＲＡＭ２０７に記憶（保存）する（ステップＳ２）。
ＮＲＳ３０５は、ＳＣＳ３０６からのＳＣコールの発行依頼により、そのＳＣコールのＳＯＡＰリクエストを生成し（ＳＣコールの発行依頼をＳＯＡＰリクエストに変換し）、それを含む送信処理をＮＣＳ３０３に依頼する（ステップＳ３）。
それによって、ＮＣＳ３０３は、ＳＣコールのＳＯＡＰリクエストをＨＴＴＰリクエストに変換させ、ＬＡＮ６００経由で示す仲介装置１０１へ送信してＳＣコールを行わせる（ステップＳ４）。

ＮＲＳ３０５は、送信処理依頼を行うと同時に図示しないタイマ・カウンタを用いて時間計測を開始し、その計測時間が所定時間（タイムアウト時間）を経過する前にＮＣＳ３０３からコール結果のＳＯＡＰレスポンス（応答）を受け取った場合には、そのＳＯＡＰレスポンスに記述されているコール結果（ＳＣコールの成功又は失敗）をＳＣＳ３０６へ通知する（ステップＳ７）。このとき、ＮＣＳ３０３へ通知したＳＣコールのＳＯＡＰリクエストのＳＯＡＰボディに記載されているＳＣコールの内容をＳＯＡＰ電文のままＳＣＳ３０６へ通知する処理も行う。

計測時間が所定時間を経過する前にＮＣＳ３０３からコール結果のＳＯＡＰレスポンスを受け取ることができなかった場合には、タイムアウトを検出してＳＣコールの失敗を認識し（ステップＳ６）、その旨をコール結果としてＳＣＳ３０６へ通知する（ステップＳ７）。このとき、ＮＣＳ３０３へ通知したＳＣコールのＳＯＡＰリクエストのＳＯＡＰボディに記載されているＳＣコールの内容をＳＯＡＰ電文のままＳＣＳ３０６へ通知する処理も行う。

ＳＣＳ３０６は、ＮＲＳ３０５からコール結果（応答結果）およびＳＯＡＰ電文を受け取ると、そのコール結果であるＳＣコールの成功又は失敗を示す情報をＮＶＲＡＭ２０７の先に保存したＳＣコールの内容に付加したうえで、そのＳＣコールの内容を読み出し、それをＳＯＡＰ電文と共にメール通知アプリ３１８へ通知する（ステップＳ８）。
メール通知アプリ３１８は、ＳＣＳ３０６からＳＣコールの内容とＳＯＡＰ電文を受け取ると、そのＳＣコールの内容に含まれているコール結果とＮＶＲＡＭ２０７内のデータとに基づいて、今回受け取ったＳＣコールの内容（イベント種別）はメール通知対象か否かを判断し、メール通知対象でなければ処理を終了する。

ＳＣＳ３０６から受け取ったＳＣコールの内容がメール通知対象の場合には、そのＳＣコールの内容に対応するページ情報をメール本文としてＨＴＴＰ・ＧＥＴでローカルホスト（local host）に相当するウェブアプリ３１４のメール本文生成用ＵＲＬから取得する（ステップＳ９）。このとき、先に受信したＳＯＡＰ電文をＸＭＬ形式のメール本文に貼り付ける処理も行う。
その後、ＮＶＲＡＭ２０７から対応するメール通知先（宛先）のアドレスを取得し（ステップＳ１０）、先に取得したメール通知先のアドレスとメール本文とを含むメール通知依頼をＤＣＳ３１６へ通知する（ステップＳ１１）。

ＤＣＳ３１６は、メール通知アプリ３１８からメール通知依頼を受けると、ＮＣＳ３０３に対してメール通知処理を行うことにより、そのメール通知依頼に付加されているメール通知先のアドレスとメール本文とをＮＣＳ３０３へ通知する（ステップＳ１２）。
ＮＣＳ３０３は、ＤＣＳ３１６から受け取ったメール通知先のアドレスとメール本文とを含むＥメールをＬＡＮ６００経由でＳＭＴＰサーバ６０１へ送信する。
以上、メール通知処理を含むＳＣコールに関する処理について説明したが、そのメール通知処理はサプライコールやユーザコール等の他のコールの発行時にも同様に行うことができる。

図２８は、ユーザメール端末６０３（ＬＡＮ６００上の他の端末装置でもよい）に表示できるメール通知に関する設定を行うためのＷｅｂページとしてのメール通知設定画面の一例を示す図である。
ユーザメール端末６０３（図１６）のＷｅｂブラウザ（ＣＰＵ）は、キーボード又はマウス（ポインティングデバイス）等の操作によって図２８に示すようなメール通知設定画面を表示部に表示することができる。

このメール通知設定画面は、図２３によって説明した各メールイベント（コール内容）毎にそれぞれ各メール通知（管理者，庶務担当，ＩＴ担当）の有効／無効を設定するための各チェックボックス８０１と、図２４によって説明した各宛先（メール通知先）グループ（管理者，庶務担当，ＩＴ担当，）毎にそれぞれ宛先のアドレスを入力（変更）するための各編集ボタン８０２（８０２ａ，８０２ｂ，８０２ｃ，８０２ｄ）と、各宛先グループ毎に設定可能（メール通知を行う際に使用可能）なアドレスを選択的に表示させるための各ダイアログボックス８０３（８０３ａ，８０３ｂ，８０３ｃ，８０３ｄ）と、当該画面に対する操作によって設定された内容を有効にするための適用ボタン８０４を備えている。

各メールイベント毎にそれぞれ各メール通知の有効／無効を設定する場合、マウス等によって各チェックボックス８０１に対して選択的にクリック操作を行うことにより、各メールイベント毎に各メール通知の有効／無効を選択的に設定することができる。
また、編集したい宛先グループ（通知先リスト）の編集ボタン８０２をマウス等でクリックして、宛先の名称および複数のアドレスを入力するためのボックスを表示させることにより、キーボード等で宛先の名称および複数のアドレスを変更可能に入力することができる。
さらに、各宛先グループ毎に設定可能な全アドレス（入力済みアドレス）をダイアログボックス８０３に対するクリック操作によって表示させ、いずれかのアドレスをクリックして選択することにより、そのアドレスを設定してダイアログボックス８０３に表示させることができる。

なお、宛先グループ「５」に対してセンタのアドレスがデフォルト設定されている。その宛先グループ「５」は、図２８のメール通知設定画面には表示されていないが、最初からデフォルト設定として表示することもできるし、所定の操作によって追加で表示することもできる。この場合、各メールイベント（コール結果）毎にそれぞれ管理装置１０２へのメール通知の有効／無効を設定するための各チェックボックスと、宛先グループ「５」（管理装置１０２）のアドレスを入力するための編集ボタンと、宛先グループ「５」に対して設定可能なアドレスを選択的に表示させるためのダイアログボックスとをメール通知設定画面に追加することが可能になり、管理装置１０２へのメール通知が行われないようにすることが可能になる。更に、他の宛先グループを増やすこともできる。
メール通知設定画面に対する操作によって設定された内容は、適用ボタン８０４をクリックすることによって有効となり、画像形成装置１００のＮＶＲＡＭ２０７に保存される。

図２９は、画像形成装置１００とユーザメール端末６０３におけるソフトウェアによるメール通知に関する設定処理（メール通知設定処理）の流れの一例を示す図である。
図３０は、この画像形成装置１００における各ソフトウェアによるメール通知設定処理の一例を示すフローチャートである。
なお、図２９，図３０における複数の丸付き数字は処理等の順番を示すステップ番号である。

ユーザメール端末６０３のＷｅｂプラウザは、キーボード又はマウス等の操作によって画像形成装置１００のＷｅｂページとしてのメール通知設定画面の表示指示があると、そのメール通知設定画面を表示させる（開く）ためのＵＲＬ（メール通知設定画面表示用ＵＲＬ）を生成し、それをＨＴＴＰ・ＧＥＴコマンドでＬＡＮ６００および画像形成装置１００のＮＣＳ３０３を介してウェブアプリ３１４へ通知する。なお、そのような通知を行ったり、その通知に対する応答を受けるなど、ウェブアプリ３１４とのやりとりを行う場合、ＳＯＡＰおよびＨＴＴＰのプロトコルを使用する必要があるが、ここではその説明を省略する。

画像形成装置１００のウェブアプリ３１４は、ユーザメール端末６０３のＷｅｂプラウザからＨＴＴＰ・ＧＥＴコマンドでメール通知設定画面（Ｗｅｂページ）表示用ＵＲＬを受け取ると、そのＵＲＬから対応するＨＴＭＬ形式のページ情報をメール通知設定画面情報として取得する。また、メール（Ｅメール）通知設定情報をメール通知アプリ３１８へ通知する。
メール通知アプリ３１８は、そのメール通知設定情報を受け取ると、ＮＶＲＡＭ２０７からメール通知に関する設定内容を読み出す。
ウェブアプリ３１４は、メール通知アプリ３１８によって読み出されたメール通知に関する設定内容を取得し、それを先に取得したメール通知設定画面情報に加え、そのメール通知設定画面情報を応答としてＮＣＳ３０３およびＬＡＮ６００経由でユーザメール端末６０３のＷｅｂプラウザへ通知する。

ユーザメール端末６０３のＷｅｂプラウザは、そのメール通知設定画面情報（Ｗｅｂページ情報）を受け取ると、その情報に基づいて表示部に図２８に示したようなメール通知設定画面を表示する（Ｗｅｂページを開く）。
そして、メール通知設定画面（Ｗｅｂページ）に対する操作（ユーザ操作）によって上述したようなメール通知に関する設定がなされ、最後に適用ボタン８０４がマウス等でクリックされると、その設定された内容を有効にして、そのメール通知に関する設定内容をＨＴＴＰ・ＰＯＳＴ（処理完了を知らせるための情報）としてＬＡＮ６００および画像形成装置１００のＮＣＳ３０３を介してウェブアプリ３１４へ通知する。

画像形成装置１００のウェブアプリ３１４は、ユーザメール端末６０３のＷｅｂプラウザからメール通知に関する設定内容を受け取ると、それをメール通知アプリ３１８へ通知する。
メール通知アプリ３１８は、そのメール通知に関する通知内容を受け取ると、それをＮＶＲＡＭ２０７に保存する。このとき、いままで保存されていた古い設定内容は上書きによって消去され、新たな設定内容に更新されることになる。
このメール通知アプリ３１８は、メール通知に関する通知内容の保存が終了すると、図示は省略するが、メール通知に関する設定が完了した旨を示す情報（メール通知設定完了情報）をウェブアプリ３１４へ通知する。

ウェブアプリ３１４は、メール通知アプリ３１８から受けたメール通知設定完了情報を応答としてＮＣＳ３０３およびＬＡＮ６００経由でユーザメール端末６０３のＷｅｂプラウザへ通知する。
ユーザメール端末６０３のＷｅｂプラウザは、そのメール通知設定完了情報を受け取ると、それをメール通知設定画面に表示して、操作者に対してメール通知に関する設定が完了した旨を知らせる。

この実施例の画像形成装置によれば、（１）〜（４）に示す作用効果を得ることができる。
（１）動作要求（ＳＯＡＰリクエスト）を含む通信要求（ＨＴＴＰリクエスト）を仲介装置又は管理装置へ送信し、動作要求に対する正常な動作応答（ＳＯＡＰレスポンス）を受信できなかった場合（通信失敗時）に、その動作要求を送信にＨＴＴＰではなくＳＭＴＰ等の他のプロトコルを用いる電子メール（Ｅメール）に含めて管理装置へ送信することにより、画像形成装置がファイアウォールや仲介装置の内側に配置されている場合でも、動作要求を確実に管理装置へ送信することができる。
（２）動作要求をＸＭＬ形式で記載することにより、その動作要求（ＳＯＡＰ電文）をメール本文とすることができるため、管理装置では、画像形成装置から動作要求がＨＴＴＰおよび電子メールのいずれで送られてきた場合でも、その各動作要求を同様に扱う（処理する）ことができる。よって、処理負担を軽減することができる。

（３）動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールをユーザ（管理者，庶務担当，ＩＴ担当など）が所有するユーザメール端末へ送信してその表示部に表示させるようにすれば、その機器利用者も動作要求の内容を認識することができるため、管理装置からその動作要求に対する動作応答が送られてこなかった場合に、その動作要求を電話又はＦＡＸ装置等を用いて管理装置のオペレータ（センタオペレータ）に伝えることができることにより、動作要求をより確実に管理装置へ送信することができる。
（４）正常な動作応答を受信できなかった動作要求（コール結果）の種別に応じて上記電子メールの送信先を変更可能にすれば、通信失敗時の対処を効率良く行うことができる。

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

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

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

この発明は、画像形成装置等の被管理装置や、その被管理装置のコンピュータ、その被管理装置と管理装置とを備えた遠隔管理システムに適用可能である。

この発明による被管理装置の遠隔管理システムの構成の一例を示す概念図である。図１に示した遠隔管理システムにおける動作要求と動作応答との関係を示す図である。この発明による被管理装置の管理システムの一例である画像形成装置遠隔管理システムの構成の一例を示す概念図である。図３に示した画像形成装置遠隔管理システムにおける動作要求と動作応答との関係を示す図である。同じく画像形成装置と仲介装置との間の通信シーケンスの例を示す図である。

同じく仲介装置と管理装置との間の通信シーケンスの例を示す図である。図３の画像形成装置のハード構成例を示すブロック図である。その画像形成装置のソフトウェア構成例を示すブロック図である。図８のＮＲＳの構成の一例を示す機能ブロック図である。図３の仲介装置のハードウェア構成例を示すブロック図である。

図３の管理装置の概略構成例を示すブロック図である。図３に示した画像形成装置遠隔管理システム内で行われるデータ送受信について説明するための通信シーケンスの一例を示す図である。その他の通信シーケンスの一例を示す図である。異常（ＳＣ）の種類を判定するための基準となる情報のテーブルの一例を示す説明図である。図３の画像形成装置における各ソフトウェアとそれらによるＳＣコールに関する処理の流れの一例を示す図である。

図３の画像形成装置遠隔管理システムを構成する各装置とそれらによるＳＣコールに関する処理の流れの一例を示す図である。図３の画像形成装置におけるＳＣコール発行時にＮＶＲＡＭに記憶されるＳＣコールの内容とそのコールの結果の一例を示す図である。同じくサプライコール発行時にＮＶＲＡＭ２０７に記憶されるサプライコールの内容とそのコールの結果の一例を示す図である。同じくＳＣコール失敗時にメール通知アプリがウェブアプリ（Ｗｅｂｓｙｓ）からメール本文を取得するためのＵＲＬの一例を示す図である。同じくサプライコール失敗時にメール通知アプリがウェブアプリからメール本文を取得するためのＵＲＬ）の一例を示す図である。

ＳＣコールのＳＯＡＰリクエストのフォーマット例を示す図である。その主要部分の構成をそれぞれ示す図である。図７のＮＶＲＡＭに記憶されているメール通知に関する設定内容（一部）の一例を示す図である。その設定内容の残りの部分を示す図である。テキスト形式のメール本文の一例を示す図である。

ＸＭＬ形式のメール本文の一例を示す図である。図３の画像形成装置における各ソフトウェアによるＳＣコールに関する処理の一例を示すフロー図である。ＬＡＮ上のユーザメール端末に表示できるメール通知設定画面の一例を示す図である。図３の画像形成装置とユーザメール端末におけるソフトウェアによるメール通知設定処理の流れの一例を示す図である。図３の画像形成装置における各ソフトウェアによるメール通知設定処理の一例を示すフロー図である。図１に示した遠隔管理システムの別の構成例を示す図である。

符号の説明

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

Claims

管理装置によりネットワークを介して遠隔管理可能な被管理装置であって、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置であって、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
管理装置によりネットワークおよび仲介装置を介して遠隔管理される被管理装置であって、
前記管理装置に対する動作要求を含む通信要求を前記仲介装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
請求項１乃至３のいずれか一項に記載の被管理装置において、
前記メール送信手段は、前記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を有することを特徴とする被管理装置。
請求項４記載の被管理装置において、
前記メール送信手段は、正常な動作応答を受信できなかった動作要求の種別に応じて前記電子メールの送信先を変更する手段を有することを特徴とする被管理装置。
管理装置によりネットワークを介して遠隔管理される被管理装置であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理される被管理装置であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを前記仲介装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設けたことを特徴とする被管理装置。
請求項６乃至８のいずれか一項に記載の被管理装置において、
前記メール送信手段は、前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を有することを特徴とする被管理装置。
請求項９記載の被管理装置において、
前記メール送信手段は、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて前記電子メールの送信先を変更する手段を有することを特徴とする被管理装置。
管理装置によりネットワークを介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記管理装置に、
前記被管理装置から前記通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信応答を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信応答をそれぞれ前記被管理装置へ送信する通信制御手段
を設けたことを特徴とする遠隔管理システム。
管理装置によりネットワークおよびファイアウォールを介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記管理装置に、
前記被管理装置から前記通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信応答を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信応答をそれぞれ前記被管理装置へ送信する通信制御手段
を設けたことを特徴とする遠隔管理システム。
管理装置によりネットワークおよび仲介装置を介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対する動作要求を含む通信要求を前記仲介装置へ送信する通信要求送信手段と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記仲介装置に、
前記被管理装置から受信した前記動作要求を含む通信要求を前記管理装置へ送信し、該動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す動作応答を含む通信応答を前記被管理装置へ送信する通信制御手段
を設け、
前記管理装置に、
前記仲介装置から通信要求を受信し、該受信が正常に終了した場合にはその旨を示す動作応答を含む通信要求を、該受信が正常に終了しなかった場合にはその旨を示す動作応答を含む通信要求をそれぞれ前記仲介装置へ送信する通信制御手段
を設けたことを特徴とする遠隔管理システム。
請求項１１乃至１３のいずれか一項に記載の遠隔管理システムにおいて、
前記被管理装置のメール送信手段は、前記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を有することを特徴とする遠隔管理システム。
請求項１４記載の遠隔管理システムにおいて、
前記被管理装置のメール送信手段は、正常な動作応答を受信できなかった動作要求の種別に応じて前記電子メールの送信先を変更する手段を有することを特徴とする遠隔管理システム。
管理装置によりネットワークを介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記管理装置に、
前記被管理装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ前記被管理装置へ送信するＨＴＴＰ通信制御手段
を設けたことを特徴とする遠隔管理システム。
管理装置によりネットワークおよびファイアウォールを介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記管理装置に、
前記被管理装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスをそれぞれ前記被管理装置へ送信するＨＴＴＰ通信制御手段
を設けたことを特徴とする遠隔管理システム。
管理装置によりネットワークおよび仲介装置を介して被管理装置を遠隔管理する遠隔管理システムであって、
前記被管理装置に、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを前記仲介装置へ送信するＨＴＴＰリクエスト送信手段と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信手段と
を設け、
前記仲介装置に、
前記被管理装置から受信した前記ＳＯＡＰリクエストを含むＨＴＴＰリクエストを前記被管理装置へ送信し、該ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示すＳＯＡＰレスポンスを含むＨＴＴＰレスポンスを前記被管理装置へ送信するＨＴＴＰ通信制御手段
を設け、
前記管理装置に、
前記仲介装置から上記ＨＴＴＰリクエストを受信し、該受信が正常に終了した場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰリクエストを、該受信が正常に終了しなかった場合にはその旨を示すＳＯＡＰレスポンスを含むＨＴＴＰリクエストをそれぞれ前記仲介装置へ送信するＨＴＴＰ通信制御手段
を設けたことを特徴とする遠隔管理システム。
請求項１６乃至１８のいずれか一項に記載の遠隔管理システムにおいて、
前記被管理装置のメール送信手段は、前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する手段を有することを特徴とする遠隔管理システム。
請求項１９記載の遠隔管理システムにおいて、
前記被管理装置のメール送信手段は、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて前記電子メールの送信先を変更する手段を有することを特徴とする遠隔管理システム。
管理装置によりネットワークを介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信するステップと、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信するステップと、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対する動作要求を含む通信要求を前記仲介装置へ送信するステップと、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
請求項２１乃至２３のいずれか一項に記載の通信制御方法において、
前記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信するステップを追加したことを特徴とする通信制御方法。
管理装置によりネットワークを介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するステップと、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するステップと、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置における通信制御方法であって、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを前記仲介装置へ送信するステップと、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するステップと
からなることを特徴とする通信制御方法。
請求項２５乃至２７のいずれか一項に記載の通信制御方法において、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信するステップを追加したことを特徴とする被管理装置。
管理装置によりネットワークを介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信機能と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対する動作要求を含む通信要求を該管理装置へ送信する通信要求送信機能と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対する動作要求を含む通信要求を前記仲介装置へ送信する通信要求送信機能と、
前記動作要求に対する正常な動作応答を受信できなかった場合に、該動作要求を電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
請求項２９乃至３１のいずれか一項に記載のプログラムにおいて、
前記コンピュータに、前記メール送信機能を実現させるためのプログラムは、前記動作要求に対する正常な動作応答を受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する機能をも実現させるためのプログラム。
請求項３２記載のプログラムにおいて、
前記コンピュータに、前記メール送信機能を実現させるためのプログラムは、正常な動作応答を受信できなかった動作要求の種別に応じて前記電子メールの送信先を変更する機能をも実現させるためのプログラム。
管理装置によりネットワークを介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信機能と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
管理装置によりネットワークおよびファイアウォールを介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを該管理装置へ送信するＨＴＴＰリクエスト送信機能と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
管理装置によりネットワークおよび仲介装置を介して遠隔管理可能な被管理装置のコンピュータに、
前記管理装置に対するＳＯＡＰリクエストを含むＨＴＴＰリクエストを前記仲介装置へ送信するＨＴＴＰリクエスト送信機能と、
前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、該ＳＯＡＰリクエストを電子メールに含めて前記管理装置へ送信するメール送信機能と
を実現させるためのプログラム。
請求項３４乃至３６のいずれか一項に記載のプログラムにおいて、
前記コンピュータに、前記メール送信機能を実現させるためのプログラムは、前記ＳＯＡＰリクエストに対する正常なＳＯＡＰレスポンスを受信できなかった場合に、その旨を示す電子メールを当該被管理装置の利用者が所有する端末装置へ送信する機能をも実現させるためのプログラム。
請求項３７記載のプログラムにおいて、
前記コンピュータに、前記メール送信機能を実現させるためのプログラムは、正常なＳＯＡＰレスポンスを受信できなかったＳＯＡＰリクエストの種別に応じて前記電子メールの送信先を変更する機能をも実現させるためのプログラム。
請求項２９乃至３８のいずれか一項に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。