(57)【特許請求の範囲】
【請求項１】
監視サーバとネットワークを介して通信可能なネットワークデバイスであって、
前記ネットワークデバイスの設定の入力を受け付ける設定入力受付手段と、
前記監視サーバに対して、所定の通信方式に従い、第１の送信データを送信する第１の送信手段と、
設定入力受付手段で受け付けた入力に基づき変更され得る前記設定の内容を取得する取得手段と、
前記監視サーバに対して、前記所定の通信方式に従い、取得された前記設定の内容を含む第２の送信データを送信する第２の送信手段と、
前記ネットワークデバイスの状態または障害を検出する検出手段と、
前記監視サーバに対して、前記所定の通信方式に従い、検出された状態または障害を示す第３のデータを送信する第３の送信手段と、
前記ネットワークデバイスにおける処理を制御する制御手段と、を有し、
前記制御手段は、前記ネットワークデバイスにおける処理の制御として、
前記設定入力受付手段が前記設定の入力を受け付け、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制し、
前記設定入力受付手段が前記設定の入力を受け付け、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に成功した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させ、
さらに、前記制御手段は、前記ネットワークデバイスにおける処理の制御として、
前記検出手段が状態または障害を検出し、かつ、前記第３の送信手段が当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制し、
前記検出手段が状態または障害を検出し、かつ、前記第３の送信手段が当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に成功した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させる
ことを特徴とするネットワークデバイス。
【請求項２】
前記第３の送信手段が検出された前記状態の情報または前記障害の情報を含む第３の送信データを送信する際には、前記第１の送信手段による第１の送信データの送信を省略して、前記第３の送信データの送信の結果に基づき、前記制御手段が前記ネットワークデバイスにおける処理の制御をする
ことを特徴とする請求項１に記載のネットワークデバイス。
【請求項３】
前記制御手段は、前記ネットワークデバイスにおける処理の制御として、
通信テストが要求され、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制し、
通信テストが要求され、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に成功した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させる
ことを特徴とする請求項１または２に記載のネットワークデバイス。
【請求項４】
前記ネットワークデバイスは、前記監視サーバを含む複数のサーバと前記ネットワークを介して通信可能であり、
前記第１の送信データの送信先を、複数のサーバのなかから決定する決定手段をさらに有し、
前記第１の送信手段は、送信先として決定されたサーバの種類に対応する前記第１の送信データを送信する
ことを特徴とする請求項１乃至３のいずれか１項に記載のネットワークデバイス。
【請求項５】
前記制御手段は、前記ネットワークデバイスにおける処理の制御として、
前記検出手段が状態または障害を検出し、かつ、前記第３の送信手段が当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制した後に、
前記第１の送信手段に前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信を行わせ、当該第１の送信データの送信に成功した場合に、前記取得手段による前記設定の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させる
ことを特徴とする請求項１乃至４のいずれか１項に記載のネットワークデバイス。
【請求項６】
前記制御手段は、前記第２の送信手段が前記第２の送信データの送信に失敗した場合に、記憶手段に当該第２の送信データをキャッシュさせる
ことを特徴とする請求項１乃至５いずれか１項に記載のネットワークデバイス。
【請求項７】
前記所定の通信方式に従い送信されるデータは、ＸＭＬ形式で記述され、ＳＯＡＰ規約に準拠したデータである
ことを特徴とする請求項１乃至６いずれか１項に記載のネットワークデバイス。
【請求項８】
前記第１の送信手段による、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信は、前記監視サーバに実行させる処理を指示するメソッドを実行するための要求である
ことを特徴とする請求項１乃至７いずれか１項に記載のネットワークデバイス。
【請求項９】
前記メソッドは、ＨＴＴＰ規約に準拠している
ことを特徴とする請求項８に記載のネットワークデバイス。
【請求項１０】
前記メソッドは、前記監視サーバに時刻情報の取得処理を指示するメソッド、または、前記監視サーバにＵＲＬ情報の取得処理を指示するメソッドである
ことを特徴とする請求項９に記載のネットワークデバイス。
【請求項１１】
監視サーバとネットワークを介して通信可能なネットワークデバイスにおける制御方法であって、
前記ネットワークデバイスの設定の入力を受け付ける設定入力受付ステップと、
前記監視サーバに対して、所定の通信方式に従い、第１の送信データを送信する第１の送信ステップと、
設定入力受付ステップで受け付けた入力に基づき変更され得る前記設定の内容を取得する取得ステップと、
前記監視サーバに対して、前記所定の通信方式に従い、取得された前記設定の内容を含む第２の送信データを送信する第２の送信ステップと、
前記ネットワークデバイスの状態または障害を検出する検出ステップと、
前記監視サーバに対して、前記所定の通信方式に従い、検出された状態または障害を示す第３のデータを送信する第３の送信ステップと、
前記ネットワークデバイスにおける処理を制御する制御ステップと、を有し、
前記制御ステップでは、
前記設定入力受付ステップで前記設定の入力が受け付けられ、かつ、前記第１の送信ステップで、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に失敗した場合に、前記取得ステップでの前記設定の内容の取得、および、前記第２の送信ステップでの前記設定の内容を含む第２の送信データの送信が抑制され、
前記設定入力受付ステップで前記設定の入力が受け付けられ、かつ、前記第１の送信ステップで、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に成功した場合に、前記取得ステップでの前記設定の内容の取得、および、前記第２の送信ステップでの前記設定の内容を含む第２の送信データの送信が実行され、
さらに、前記制御ステップでは、
前記検出ステップで状態または障害が検出され、かつ、前記第３の送信ステップで、当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に失敗した場合に、前記取得ステップでの前記設定の内容の取得、および、前記第２の送信ステップでの前記設定の内容を含む第２の送信データの送信が抑制され、
前記検出ステップで状態または障害が検出され、かつ、前記第３の送信ステップで、当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に失敗した場合に、前記取得ステップでの前記設定の内容の取得、および、前記第２の送信ステップでの前記設定の内容を含む第２の送信データの送信が実行される
ことを特徴とする制御方法。
【請求項１２】
コンピュータを、請求項１乃至１０のいずれか１項に記載のネットワークデバイスとして機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続され、監視サーバとネットワークを介して相互に通信可能なネットワークデバイス、制御方法、およびプログラムに関する。より詳細には、監視サーバの監視対象となるネットワークデバイスからの監視サーバに対する通信制御の技術に関する。
【背景技術】
【０００２】
従来より、監視サーバとその監視対象となるネットワークデバイスとをネットワークを介して相互に通信可能に接続し、監視サーバがネットワークデバイスから取得したデバイス情報に基づいて遠隔監視を行うシステムが知られている（特許文献１）。
【０００３】
このようなネットワークデバイスの遠隔監視を行うシステムにおいて、監視サーバが取得するネットワークデバイスの情報には、種々の情報が用いられる。例えば、ネットワークデバイスには、ユーザが操作可能なユーザモードの他に、デバイスの保守を担当するサービスマンだけが操作可能なサービスモードが設けられている。サービスモードでは、ネットワークデバイスの状態や設定を示すサービスモード情報がネットワークデバイス自身によって取得される。さらに、トリガとなるイベントが発生すると、ネットワークデバイスは取得したサービスモード情報をネットワーク経由で監視サーバに送信する。
【０００４】
ところで、このような遠隔監視システムにおいて、監視サーバに障害が発生していてネットワークデバイスとの通信ができない状況にある場合、ネットワークデバイスが自身のサービスモード情報を取得することは、無駄な処理となる。また、監視サーバとネットワークデバイスとの通信ができない状況にある場合に、ネットワークデバイスがサービスモード情報を送信してしまうと、ネットワークに不必要な通信負荷をかけてしまうことになる。
【０００５】
特許文献１に記載のシステムでは、デバイスが送信すべきパケットを宛先に送信する前に、通信確認要求としてｐｉｎｇパケットを宛先に送信して、デバイスと宛先とが事前に通信確認を行う技術が開示されている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−０８６７２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、宛先となる監視サーバがＨＴＴＰサーバなどであって、ｐｉｎｇパケットの受信に対応していない場合、監視サーバがネットワークデバイスからの通信確認要求を受信できないという状況が生じていた。
【０００８】
そのため、ネットワークデバイスが通信確認要求としてｐｉｎｇパケットを監視サーバに送信する手法を用いることができず、結果としてネットワークデバイス内でサービスモード情報を取得するための無駄な処理が発生する場合があった。あるいはまた、ネットワークデバイスが通信確認要求を監視サーバに送信することなくサービスモード情報を送信していたため、監視サーバに障害が発生していた場合に、ネットワークに不必要な通信負荷をかけてしまうことがあった。
【課題を解決するための手段】
【０００９】
本発明に係るネットワークデバイスは、監視サーバとネットワークを介して通信可能なネットワークデバイスであって、前記ネットワークデバイスの設定の入力を受け付ける設定入力受付手段と、前記監視サーバに対して、所定の通信方式に従い、第１の送信データを送信する第１の送信手段と、設定入力受付手段で受け付けた入力に基づき変更され得る前記設定の内容を取得する取得手段と、前記監視サーバに対して、前記所定の通信方式に従い、取得された前記設定の内容を含む第２の送信データを送信する第２の送信手段と、前記ネットワークデバイスの状態または障害を検出する検出手段と、前記監視サーバに対して、前記所定の通信方式に従い、検出された状態または障害を示す第３のデータを送信する第３の送信手段と、前記ネットワークデバイスにおける処理を制御する制御手段と、を有し、前記制御手段は、前記ネットワークデバイスにおける処理の制御として、前記設定入力受付手段が前記設定の入力を受け付け、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制し、前記設定入力受付手段が前記設定の入力を受け付け、かつ、前記第１の送信手段が、前記第２の送信データの送信よりも通信負荷が軽い第１の送信データの送信に成功した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させ、さらに、前記制御手段は、前記ネットワークデバイスにおける処理の制御として、前記検出手段が状態または障害を検出し、かつ、前記第３の送信手段が当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に失敗した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を抑制し、前記検出手段が状態または障害を検出し、かつ、前記第３の送信手段が当該検出された前記状態の情報または前記障害の情報を含む第３の送信データの送信に成功した場合に、前記取得手段による前記設定の内容の取得、および、前記第２の送信手段による前記設定の内容を含む第２の送信データの送信を実行させることを特徴とする。
【発明の効果】
【００１０】
本発明は上述の課題に鑑みてなされたものである。すなわち、宛先となる監視サーバがＨＴＴＰサーバなどであって、ｐｉｎｇパケットの受信に対応していない場合であっても、監視サーバと確実に通信確認を行うことが可能なネットワークデバイスを提供する。
【００１１】
本発明におけるネットワークデバイスでは、監視サーバと確実に通信確認を行うことができるため、ネットワークデバイスに無駄な処理負荷や、ネットワークに不必要な通信負荷をかけることなく、監視サーバに必要な情報を送信することができる。
【図面の簡単な説明】
【００１２】
【図１】実施形態における監視システムの全体構成を示す図である。
【図２】実施形態におけるデバイスのハードウェア構成を示すブロック図である。
【図３】実施形態におけるデバイスのソフトウェア機能構成を示すブロック図である。
【図４】実施形態におけるサービスモード情報の内容の一例を示す図である。
【図５】実施形態における送信データの内容の一例を示す図である。
【図６】図６（ａ）は従来技術の監視システムにおける通信シーケンス６１０を示す図であり、図６（ｂ）は本実施形態の監視システムにおける通信シーケンス６２０を示す図である。
【図７】実施形態におけるサービスモード情報の送信処理の内容を示すフローチャートである。
【図８】実施形態２における監視システムの全体構成を示す図である。
【図９】実施形態２における送信データの内容の一例を示す図である。
【図１０】実施形態２における監視システムの通信シーケンスを示す図である。
【図１１】実施形態２におけるサービスモード情報の送信処理の内容を示すフローチャートである。
【図１２】実施形態３におけるサービスモード情報の送信処理の内容を示すフローチャートである。
【発明を実施するための形態】
【００１３】
［実施形態１］
以下、本発明を実施するための形態について図面を参照して説明する。ただし、この実施形態に記載されている構成要素はあくまで例示であり、本発明の範囲をそれらに限定する趣旨のものではない。
【００１４】
図１は、本実施形態における監視システム１００の全体構成を示す図である。
【００１５】
監視システム１００は、ネットワークデバイスとなるデバイス２００と、プロキシサーバ３００と、ＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）４００と、監視サーバ５００とを備え、各ネットワークを介して相互に通信可能に接続されている。デバイス２００と、ＰＣ４００と、監視サーバ５００とは、プロキシサーバ３００とインターネット１１０とを介して相互に通信可能に接続されている。さらに、デバイス２００と、ＰＣ４００と、監視サーバ５００は、それぞれプロキシサーバ３００とＬＡＮ１２０（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）を介して相互に通信可能に接続されている。
【００１６】
デバイス２００は、所定のイベントが発生すると、デバイス２００の設定の内容を示すサービスモード情報を監視サーバ５００に送信する。監視サーバ５００は、デバイス２００から受信したサービスモード情報に基づいて、デバイス２００の監視を行う。ＰＣ４００は、Ｗｅｂブラウザを介して監視サーバ５００へのアクセスを行うことができ、監視サーバ５００に記憶されたデバイス２００の監視情報等を閲覧することができる。
【００１７】
なお、本実施形態においては、インターネット１１０を含むシステム構成を示しているが、ＬＡＮ１２０のみを含むシステム構成であってもよい。また、本実施形態においては、プロキシサーバ３００を含むシステム構成を示しているが、プロキシサーバ３００を含まないシステム構成であってもよい。また、ネットワークに通信可能に接続されるデバイス２００の数およびＰＣ４００の数は、本実施形態のものに限定されない。
【００１８】
なお、本実施例では、デバイス２００の例として、プリント機能やスキャナ機能などの少なくとも何れかを有するような画像処理装置を挙げて説明しているが、本発明は、監視対象となり得るネットワークデバイスとしてはそれ以外の機器も適用可能である。具体的には、ネットワークカメラやデジタル医療機器、３Ｄプリンタなどがある。また、ネットワーク接続された家電製品（テレビや空調機器など）や車載器（カーナビなど）も、本発明を適用可能なネットワークデバイスと言える。
【００１９】
図２は、本実施形態におけるデバイス２００のハードウェア構成を示すブロック図である。
【００２０】
制御部２０１はＣＰＵ２０２を含み、デバイス２００全体の動作を制御する。ＣＰＵ２０２は、ＲＯＭ２０４に記憶された制御プログラムを読み出して通信制御などの各種制御を実行する。ＲＡＭ２０３は、ＣＰＵ２０２の主メモリ、ワークエリア等の一時記憶領域として用いられる。ＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）２０５は、データや各種プログラム、あるいは各種情報をテーブル形式に記憶するためなどの補助記憶領域として用いられる。なお、図７、図１１および図１２に示されるフローチャートによる処理は、ＨＤＤ２０５に記憶されたプログラムコードがＲＡＭ２０３に展開され、ＣＰＵ２０２によって実行される。
【００２１】
プリンタインターフェース（以下「インターフェース」は「Ｉ／Ｆ」と記載）２０６は、プリンタ２０７と制御部２０１とをバス２１３を介して通信可能に接続する。プリンタ２０７は、プリンタＩ／Ｆ２０６を介して入力された印刷データに基づいて、不図示の給紙カセットから給紙された印刷用紙等に印刷処理を実行する。本実施形態において、プリンタ２０７はインクジェット方式または電子写真方式など、あらゆる形態のプリンタを適用することができる。
【００２２】
スキャナＩ／Ｆ２０８は、スキャナ２０９と制御部２０１とをバス２１３を介して通信可能に接続する。スキャナ２０９は、デバイス２００に設けられた不図示の読取装置に載置された原稿を読み取り、画像データを生成する。スキャナ２０９が生成した画像データは、ＣＰＵ２０２の制御によりプリンタ２０７で印刷することができる。あるいはまた、ＨＤＤ２０５に記憶され、ネットワークＩ／Ｆ２１２を介してデバイス２００に接続される各種外部装置に送信されることができる。
【００２３】
操作パネルＩ／Ｆ２１０は、操作パネル２１１と制御部２０１とをバス２１３を介して通信可能に接続する。
【００２４】
ネットワークＩ／Ｆ２１２は、デバイス２００と各種外部装置とを通信可能に接続するためのインターフェースを提供する。ネットワークＩ／Ｆ２１２には、不図示のＬＡＮケーブルが接続され、外部装置と通信を実行する。デバイス２００は、ネットワークＩ／Ｆ２１２を介して、外部装置から印刷データを受信し、受信した印刷データに基づいてプリンタ２０７が印刷処理を実行することができる。あるいはまた、スキャナ２０９によって生成された画像データを、ネットワークＩ／Ｆ２１２を介して外部装置に送信することもできる。
【００２５】
本実施形態においては、デバイス２００は、１つのＣＰＵ２０２に、１つのＲＡＭ２０３に展開されたプログラムコードを実行させることにより後述するフローチャートによる処理を実行する態様について説明するが、他の態様であっても構わない。例えば、デバイス２００が、複数のＣＰＵおよび複数のメモリを協働させて後述するフローチャートによる処理を実行する態様であってもよい。
【００２６】
図３は、デバイス２００のソフトウェア機能構成を示すブロック図である。
【００２７】
検出部２２０は、デバイス２００の状態または障害を検出する。ここで、デバイス２００の状態とは、デバイス内の温度または湿度を示す情報や、デバイス２００に備えられた各種センサから取得した情報が例示される。上記デバイス２００の状態は、主に監視サーバ５００がデバイス２００を遠隔監視する際に用いられる。また、デバイスの障害とは、デバイス内で発生した各種の不具合を示す情報のことをいい、デバイス内の部品の故障や、トナーやインクカートリッジ切れを示す情報が例示される。
【００２８】
サービスモード情報取得部２２１は、デバイス２００の設定を示すサービスモード情報を、プリンタサービスモード情報管理部２２５およびスキャナサービスモード情報管理部２２６から取得する。ここで、デバイス２００の設定とは、デバイス２００が画像処理を実行する際に参照される情報が例示される。
【００２９】
上記デバイス２００の設定は、例えば主にサービスマンがデバイス２００のメンテナンスサービスを提供する際に、プリンタ２０７やスキャナ２０９が出力する画像を微調整するために設定可能な情報である。上記デバイス２００の設定は、デバイス２００の操作パネル２１１が各種の設定の入力を受け付け、または操作パネル２１１が各種の設定の変更を受け付け、ＲＡＭ２０３やＨＤＤ２０５に記憶される。あるいは、ネットワークＩ／Ｆ２１２がネットワークを介して設定の情報を受信し、ＲＡＭ２０３やＨＤＤ２０５に記憶される。このとき、操作パネル２１１またはネットワークＩ／Ｆ２１２は、本発明における設定入力受付手段の機能を担う。
【００３０】
本実施形態におけるデバイス２００では、サービスモード情報取得部２２１が、プリンタサービスモード情報管理部２２５およびスキャナサービスモード情報管理部２２６にアクセスするときの通信速度は非常に低速度なものとなっている。そのため、サービスモード情報に含まれる項目数が多ければ多いほど、サービスモード情報取得部２２１は、デバイス２００のサービスモード情報の取得に時間を要する。そのため、サービスモード情報取得部２２１は、サービスモード情報のから優先度の高い項目から取得し、デバイス全体の処理時間を短縮することもできる。
【００３１】
サービスモード情報管理部２２２は、サービスモード情報取得部２２１が取得したサービスモード情報をＲＡＭ２０３またはＨＤＤ２０５に格納して管理する。具体的には、サービスモード情報管理部２２２は、サービスモード情報を、サービスモードの項目と、それぞれの項目に対応する値を対応付けてＲＡＭ２０３またはＨＤＤ２０５に格納して管理する。サービスモード情報を構成するサービスモードの項目と、それぞれの項目に対応する値については、図４で詳細に説明する。
【００３２】
プリンタサービスモード情報管理部２２５は、サービスモード情報管理部２２２と同様に、プリンタ２０７のサービスモード情報を、サービスモードの項目と、それぞれの項目に対応する値を対応付けてＲＡＭ２０３またはＨＤＤ２０５に格納して管理する。
【００３３】
スキャナサービスモード情報管理部２２６は、サービスモード情報管理部２２２と同様に、スキャナ２０９のサービスモード情報を、サービスモードの項目と、それぞれの項目に対応する値を対応付けてＲＡＭ２０３またはＨＤＤ２０５に格納して管理する。
【００３４】
送信データ生成部２２３は、サービスモード情報管理部２２２によって管理されるサービスモード情報から、監視サーバ５００に送信する送信データを生成する。本実施形態において、送信データ生成部２２３は、監視サーバ５００とデバイス２００とが相互に送受信可能なデータ構造での送信データを生成する。データ構造の一例としては、後述のＸＭＬ形式で記述され、ＳＯＡＰ規約に準拠したデータ構造が例示される。データ構造の例については、図５で詳細に説明する。
【００３５】
通信部２２４は、ネットワークＩ／Ｆ２１２が行う通信を制御し、本発明における送信手段および受信手段の機能を担う。送信データ生成部２２３が生成した送信データを、監視サーバ５００などに送信する処理を実行する。あるいはまた、監視サーバ５００などからの送信データを受信する処理を実行する。
【００３６】
図４は、本実施形態におけるサービスモード情報の内容の一例を示す図である。
【００３７】
本実施形態におけるサービスモード情報は、サービスモード情報管理部２２５によって、サービスモードの項目と、それぞれの項目に対応する値とが対応付けられてＲＡＭ２０３またはＨＤＤ２０５に格納される。
【００３８】
符号２３０は、サービスモード情報の内容の一例を示す。サービスモード情報には、サービスモード情報の項目２３１，２３２，２３３と、値２３４とが対応付けられている。本実施形態では、「ＴＩＥＲ−１」「ＴＩＥＲ−２」「ＴＩＥＲ−３」が、それぞれサービスモード情報の大項目２３１，中項目２３２，小項目２３３に相当する。図４に示される通り、「ＴＩＥＲ−１」「ＴＩＥＲ−２」「ＴＩＥＲ−３」は階層構造となっており、下位の項目になるに従ってより具体的な情報が対応付けられる。
【００３９】
例えば、図４を参照して説明すると、「ＴＩＥＲ−１」でデバイス２００内のユニットを特定する情報として「ＣＯＰＹ」が記録される。次に「ＴＩＥＲ−２」では「ＣＯＰＹ」の設定を特定する情報として「ＡＤＪＵＳＴＭＥＮＴ」が記録される。次に、「ＴＩＥＲ−３」では、「ＡＤＪＵＳＴＭＥＮＴ」の設定を特定する情報として、例えばコピーユニット（不図示）に設定されている輝度を特定する情報として「ＢＲＩＧＨＴＮＥＳＳ」が記録される。
【００４０】
そして、これら項目と、値２３４とが対応付けて記憶される。本実施形態では、図４に示される通り、項目「ＣＯＰＹ」「ＡＤＪＵＳＴＭＥＮＴ」「ＢＲＩＧＨＴＮＥＳＳ」に対応する値として、「９０」が対応付けられている。これは、デバイス２００内のコピーユニット（不図示）の輝度設定が９０であることを示す。
【００４１】
値２３４は、監視サーバ５００によって項目別に参照される。あるいはまた、値２３４は、デバイス２００を設定するために監視サーバ５００またはデバイス２００の操作パネル２１１を介して調整される。図４において説明した各項目の内容はあくまで一例であり、上記に限定されるものではない。
【００４２】
図５は、本実施形態における送信データの内容の一例を示す図である。
【００４３】
前述の通り、本実施形態における送信データは、監視サーバ５００とデバイス２００とが相互に送受信可能なデータ構造で生成される。データ構造の一例としては、ＸＭＬ形式で記述され、ＳＯＡＰ規約に準拠したデータ構造（以下、当該データ構造を「ＸＭＬ／ＳＯＡＰデータ」と記す）が例示される。本実施形態におけるＸＭＬ／ＳＯＡＰデータにおいては、監視サーバ５００が実行する処理を指示するメソッドを、ＸＭＬ／ＳＯＡＰデータ内に含めることができる。かかる構成により、ＸＭＬ／ＳＯＡＰデータは、所定の通信方式に従い、ネットワークを介して送受信することができる。また、本実施形態においては、ＸＭＬ／ＳＯＡＰデータに含まれる各種のメソッドは、ＨＴＴＰ規約に準拠したものとなっている。
【００４４】
ＸＭＬ／ＳＯＡＰデータ５０１には、デバイス２００が監視サーバ５００に対して時刻情報の取得処理を指示するためのメソッドである、ｇｅｔＣｌｏｃｋが記述されている。ＸＭＬ／ＳＯＡＰデータ５０２には、メソッドｇｅｔＣｌｏｃｋによって指示され、監視サーバ５００による時刻情報の取得処理の処理結果である、ｇｅｔＣｌｏｃｋＲｅｓｐｏｎｓｅが含まれる。このようなメソッドｇｅｔＣｌｏｃｋは、監視サーバ５００に対して、いわば監視サーバ５００の状態または設定を示す情報の取得処理を指示するメソッドといえる。
【００４５】
ＸＭＬ／ＳＯＡＰデータ５０３には、デバイス２００が監視サーバ５００に対してサービスモード情報を提供するためのメソッドである、ｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅが記述されている。ＸＭＬ／ＳＯＡＰデータ５０４には、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅによって指示され、監視サーバ５００による受信処理の処理結果である、ｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅＲｅｓｐｏｎｓｅが含まれる。
【００４６】
上述の通り、本実施形態においては、Ｗｅｂサービスの提供に適しているとされるＸＭＬ／ＳＯＡＰデータをデータ構造として用いる例について説明した。しかし、実施形態はこれに限られず、異機種間でのデータ通信環境や、インターネット１１０を経由するデータ通信環境下でデータ交換が可能なデータ構造であれば、データ構造はＸＭＬ／ＳＯＡＰデータ以外のものも用いてもよい。
【００４７】
図６は、監視システムにおける通信シーケンスの一例を示す図である。図６において、図６（ａ）は従来技術の監視システムにおける通信シーケンス６１０を示す図であり、図６（ｂ）は本実施形態の監視システムにおける通信シーケンス６２０を示す図である。
【００４８】
図６（ａ）および図６（ｂ）の監視システム共に、デバイス２００は、所定のタイミングで監視サーバ５００にサービスモード情報の送信を行う。
【００４９】
このとき、図６（ａ）に示される従来技術の監視システムでは、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅの送信に先立ち、通信確認要求としてｐｉｎｇパケットが、デバイス２００から監視サーバ５００に送信される（Ｓ６１１）。
【００５０】
デバイス２００は、監視サーバ５００からｐｉｎｇ応答を受信すると（Ｓ６１２）、デバイス２００と監視サーバ５００との間の通信が可能な状態であると認識する。その後、デバイス２００は、ｐｉｎｇ応答の受信に応じて、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを監視サーバ５００に送信する（Ｓ６１３）。
【００５１】
しかしながら、監視サーバ５００がＨＴＴＰサーバなどであって、ｐｉｎｇパケットの受信に対応していない場合、デバイス２００と監視サーバ５００との間でｐｉｎｇパケットによる通信確認を行うことができなかった。このような状況下では、デバイス２００はｐｉｎｇパケットを監視サーバ５００に送信することなく、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを監視サーバ５００に送信（Ｓ６１３）していた。そのため、監視サーバ５００に障害が発生していて、デバイス２００からのメソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅが受信できない場合にあっては、ネットワークに不必要な通信負荷をかけてしまうという状況が発生していた。
【００５２】
一方、図６（ｂ）に示される本実施形態の監視システムでは、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅの送信に先立ち、メソッドｇｅｔＣｌｏｃｋが、デバイス２００から監視サーバ５００に送信される（Ｓ６２１）。監視サーバ５００がメソッドｇｅｔＣｌｏｃｋを受信すると、ＸＭＬ／ＳＯＡＰデータで記述されるｇｅｔＣｌｏｃｋＲｅｓｐｏｎｓｅが、監視サーバ５００からデバイス２００に対して送信される（Ｓ６２２）。
【００５３】
デバイス２００は、ｇｅｔＣｌｏｃｋＲｅｓｐｏｎｓｅを受信すると、通信確認要求に対する応答があったものと判断し、デバイス２００と監視サーバ５００との間の通信が可能な状態であると認識する。その後、デバイス２００は、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを監視サーバ５００に送信する（Ｓ６２３）。
【００５４】
一方、デバイス２００は、ｇｅｔＣｌｏｃｋＲｅｓｐｏｎｓｅを受信しなかった場合、通信確認要求に対する応答がなかったものと判断し、デバイス２００と監視サーバ５００との間の通信が不可能な状態であると認識する。その後、デバイス２００の制御部２０１は、サービスモード情報取得部２２１が、サービスモード情報を取得すること、および通信部２２４がサービスモード情報を監視サーバ５００に送信することを抑制する（Ｓ６２３）。
【００５５】
次いで、監視サーバ５００がメソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを受信すると、ＸＭＬ／ＳＯＡＰデータで記述されるｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅＲｅｓｐｏｎｓｅが、監視サーバ５００からデバイス２００に対して送信される（Ｓ６２４）。
【００５６】
図３において説明した通り、本実施形態におけるデバイス２００では、サービスモード情報取得部２２１が、デバイス２００内の各サブデバイス（プリンタ２０７、スキャナ２０９など）からサービスモード情報を取得する。次いで、送信データ生成部２２３が、取得されたサービスモード情報から、監視サーバ５００に送信する送信データを生成する。さらに、図５および図６において説明した通り、送信データ生成部２２３は、サービスモード情報の送信データとして、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを含むＸＭＬ／ＳＯＡＰデータを生成する。
【００５７】
送信データ生成部２２３はまた、通信確認要求の送信データとして、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを生成する。このとき、デバイス２００の制御部２０１は、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを含むＸＭＬ／ＳＯＡＰデータを生成するよりも、低い処理負荷でメソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを生成する。つまり、デバイス２００の制御部２０１は、サービスモード情報の送信データを生成するよりも、より処理負荷の低い通信確認要求の送信データを生成することができる。そのため、サービスモード情報を送信するためのメソッドであるｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを送信する前に、処理負荷が軽い送信データであるｇｅｔＣｌｏｃｋを用いて、デバイス２００と監視サーバ５００との間の通信確認を行うことができる。
【００５８】
なお、本実施形態では通信確認要求の送信データを、時刻情報を要求するために送信されるメソッドｇｅｔＣｌｏｃｋを用いる態様で説明したが、これに限られない。メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを含むＸＭＬ／ＳＯＡＰデータを生成するよりも低い処理負荷で生成され、同じデータ構造であるものであれば、他の態様であってもよい。
【００５９】
なお、デバイス２００が監視サーバ５００に通信確認要求を送信するタイミング（Ｓ６２１）は、諸処の態様が採り得る。例えば、事前に設定された時刻に基づいて定期的に行われてもよく、デバイス２００の操作パネル２１１に対してサービスモード情報の送信指示が受け付けられたタイミングで行われてもよい。
【００６０】
図７は、本実施形態におけるサービスモード情報の送信処理の内容を示すフローチャートである。以下、図７を参照して、本実施形態におけるサービスモード情報の送信処理の動作を説明する。
【００６１】
Ｓ７０１において、デバイス２００の制御部は、サービスモード情報を送信するトリガとなるイベントを受信する。
【００６２】
Ｓ７０２において、デバイス２００の制御部は、受信したイベントの種別を判定する。イベントが、アラーム発生またはサービスコールの発生であった場合は、Ｓ７０３に移行する。ここで、アラームとは、例えば、検出部２２０がデバイス２００内の障害を検出することに応じて、ＲＡＭ２０３やＨＤＤ２０５に記憶される当該障害の内容を示す情報である。また、サービスコールとは、例えばサービスマンによって操作パネル２１１への設定または変更の入力が受け付けられ、検出部がデバイス２００内の状態を検出することに応じて、ＲＡＭ２０３やＨＤＤ２０５に記憶される当該状態の内容を示す情報である。
【００６３】
一方、Ｓ７０２において、イベントが通信テストまたはサービスモード情報更新であった場合は、Ｓ７０４に移行する。ここで、通信テストとは、例えばデバイス２００または監視サーバ５００などからの要求に応じて、デバイス２００と監視サーバ５００との間の通信が可能な状態であるかの確認を行うことをいう。また、サービスモード情報更新とは、例えばデバイス２００のサービスモード情報管理部２２２および監視サーバ５００が記憶するサービスモード情報を最新のものに更新することをいう。
【００６４】
Ｓ７０３において、デバイス２００の送信データ生成部２２３は、アラームまたはサービスコール情報を含むＸＭＬ／ＳＯＡＰデータを生成する。次いで、通信部２２４は、アラームまたはサービスコールのＸＭＬ／ＳＯＡＰデータを監視サーバ５００に送信する。
【００６５】
Ｓ７０４において、デバイス２００の送信データ生成部２２３は、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを生成する。次いで、通信部２２４は、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを監視サーバ５００に送信する。
【００６６】
Ｓ７０５において、デバイス２００の制御部２０１は、Ｓ７０３またはＳ７０４で生成したＸＭＬ／ＳＯＡＰデータの送信に成功したかを判定する。ＸＭＬ／ＳＯＡＰデータの送信に成功したと判定した場合（Ｓ７０５：Ｙｅｓ）、Ｓ７０３またはＳ７０４で送信された送信データが監視サーバ５００に到達し、かつ監視サーバからの応答があったものと判断し、Ｓ７０６に移行する。
【００６７】
一方、ＸＭＬ／ＳＯＡＰデータの送信に失敗したと判定した場合（Ｓ７０５：Ｎｏ）、デバイス２００の制御部２０１は、送信された送信データが監視サーバ５００に到達しなかったか、または監視サーバからの応答がなかったものと判断する。このとき、デバイス２００の制御部２０１は、サービスモード情報取得部２２１および通信部２２４が、それぞれＳ７０６およびＳ７０７の処理を行うことを抑制するといえる。
【００６８】
Ｓ７０６において、デバイス２００の制御部２０１は、サービスモード情報の取得を行う。前述の通り、本実施形態においては、サービスモード情報取得部２２１が、デバイス２００の設定を示すサービスモード情報を、サブデバイスであるプリンタおよびスキャナなどから取得する。次いで、送信データ生成部２２３は、取得したサービスモード情報から、監視サーバ５００に送信する送信データを生成する。
【００６９】
Ｓ７０７において、デバイス２００の通信部２２４は、サービスモード情報を監視サーバ５００に送信する処理を実行する。本実施形態においては、送信データ生成部２２３が生成した、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを含むＸＭＬ／ＳＯＡＰデータを、監視サーバ５００に送信する。Ｓ７０７の処理を終えると、本フローチャートを終了する。
【００７０】
以上説明した通り、本実施形態における監視システムにおいては、デバイス２００から監視サーバ５００に送信する通信確認要求を、サービスモード情報を送信するデータ構造と同じデータ構造とした。そのため、デバイス２００からの送信先である監視サーバ５００が、ＨＴＴＰサーバなどであって、ｐｉｎｇパケットの受信に対応していない場合であっても、デバイス２００と監視サーバ５００との通信確認を確実に行うことができる。これにより、デバイス２００がサービスモード情報を取得するための無駄な処理を回避させるとともに、ネットワークに不必要な通信負荷をかけることを回避することができる。
【００７１】
［実施形態２］
実施形態１においては、デバイス２００がサービスモード情報を直接監視サーバ５００に対して送信する態様について説明した。本実施形態における監視システム８００では、ＬＡＮ１２０以下に複数のデバイス２００，２５０が存在し、複数のデバイス２００，２５０それぞれからＬＡＮ内監視サーバ８１０に対して一旦サービスモード情報の送信を行う。そして、ＬＡＮ内監視サーバ８１０が複数のデバイス２００からのサービスモード情報を集約し、集約したサービスモード情報を監視サーバ５００に対してまとめて送信する。
【００７２】
本実施形態における監視システム８００では、ＬＡＮ１２０内に存在する複数のデバイス２００をまとめて管理する場合に好適に用いることができる。本実施形態における監視システム８００では、監視サーバ５００およびＬＡＮ内監視サーバ８１０は、デバイス２００との通信において、それぞれ異なるメソッドをサポートする。そのため、デバイス２００は、通信確認要求の送信先の監視サーバの種類に応じて、異なる種類のメソッドを含むＸＭＬ／ＳＯＡＰデータを送信データとして生成する必要が生じる。以下、本実施形態の説明において、上述の実施形態１と重複する説明は省略し、両実施形態における差異点のみについて説明する。
【００７３】
図８は、本実施形態における監視システム８００の全体構成を示す図である。
【００７４】
図１に示される監視システム１００と同一の符号を付与されている要素は、図８の監視システム８００においても同一の要素を示す。監視システム８００において、符号２００および２５０は、同一のＬＡＮ１２０に接続される複数のデバイス２００，２５０である。これらデバイス２００，２５０は、ＬＡＮ１２０を介してＬＡＮ内監視サーバ８１０と相互に通信可能に接続されている。ＬＡＮ内監視サーバ８１０は、デバイス２００，２５０からサービスモード情報を受信し、受信したサービスモード情報を集約した後、サービスモード情報を監視サーバ５００に送信する。
【００７５】
図９は、本実施形態における送信データの内容の一例を示す図である。
【００７６】
本実施形態における送信データは、デバイス２００と監視サーバ５００，８１０とが相互に送受信可能なデータ構造で生成される。データ構造の一例としては、実施形態１と同様に、ＸＭＬ／ＳＯＡＰデータが例示される。
【００７７】
ＸＭＬ／ＳＯＡＰデータ９０１には、デバイス２００がＬＡＮ内監視サーバ８１０に対して、ＬＡＮ内監視サーバ８１０のＵＲＬ情報の取得処理を指示するためのメソッドである、ｃｈｅｃｋＨｏｓｔが記述されている。ＸＭＬ／ＳＯＡＰデータ９０２は、メソッドｃｈｅｃｋＨｏｓｔによって指示され、監視サーバ５００によるＵＲＬ情報の取得処理の処理結果である、ｃｈｅｃｋＨｏｓｔＲｅｓｐｏｎｓｅが含まれる。
【００７８】
図１０は、本実施形態における監視システム８００における通信シーケンス１０００の一例を示す図である。
【００７９】
図８の監視システム８００において、デバイス２００は、所定のタイミングでＬＡＮ内監視サーバ８１０にサービスモード情報の送信を行う。本実施形態の監視システム８００では、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅの送信に先立ち、メソッドｃｈｅｃｋＨｏｓｔが、デバイス２００からＬＡＮ内監視サーバ８１０に送信される（Ｓ１００１）。ＬＡＮ内監視サーバ８１０がメソッドｃｈｅｃｋＨｏｓｔを受信すると、ＸＭＬ／ＳＯＡＰデータで記述されるｃｈｅｃｋＨｏｓｔＲｅｓｐｏｎｓｅが、ＬＡＮ内監視サーバ８１０からデバイス２００に対して送信される（Ｓ１００２）。
【００８０】
デバイス２００は、ｃｈｅｃｋＨｏｓｔＲｅｓｐｏｎｓｅを受信すると、通信確認要求に対する応答があったものと判断し、デバイス２００とＬＡＮ内監視サーバ８１０との間の通信が可能な状態であると認識する。その後、デバイス２００は、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅをＬＡＮ内監視サーバ８１０に送信する（Ｓ１００３）。
【００８１】
一方、デバイス２００は、ｃｈｅｃｋＨｏｓｔＲｅｓｐｏｎｓｅを受信しなかった場合、通信確認要求に対する応答がなかったものと判断し、デバイス２００とＬＡＮ内監視サーバ８１０との間の通信が不可能な状態であると認識する。その後、デバイス２００の制御部２０１は、サービスモード情報取得部２２１が、サービスモード情報を取得すること、および通信部２２４がサービスモード情報を監視サーバ５００に送信することを抑制する（Ｓ１００３）。
【００８２】
次いで、ＬＡＮ内監視サーバ８１０がメソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを受信すると、ＸＭＬ／ＳＯＡＰデータのｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅＲｅｓｐｏｎｓｅが、ＬＡＮ内監視サーバ８１０からデバイス２００に対して送信される（Ｓ１００４）。
【００８３】
その後、ＬＡＮ内監視サーバ８１０は、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを監視サーバ５００に送信する（Ｓ１００５）。次いで、監視サーバ５００がメソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを受信すると、ＸＭＬ／ＳＯＡＰデータのｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅＲｅｓｐｏｎｓｅが、監視サーバ５００からＬＡＮ内監視サーバ８１０に対して送信される（Ｓ１００６）。
【００８４】
図１１は、本実施形態におけるサービスモード情報の送信処理の内容を示すフローチャートである。以下、図１１を参照して、本実施形態におけるサービスモード情報の送信処理の動作を説明する。
【００８５】
Ｓ１１０１〜Ｓ１１０３の処理は、実施形態１における図７のＳ７０１〜７０３の処理と同じである。
【００８６】
Ｓ１１０４において、デバイス２００の制御部２０１は、動作モードを判定する。本実施形態における動作モードとは、サービスモード情報の送信先となる監視サーバの種類に基づいて規定される設定情報である。本実施形態においては、デバイス２００がサービスモード情報を直接監視サーバ５００に送信する直接送信モードと、サービスモード情報を一旦ＬＡＮ内監視サーバ８１０に送信する間接送信モードのいずれかに設定される。
【００８７】
デバイス２００の動作モードが直接送信モードであった場合、Ｓ１１０５に移行し、デバイス２００の送信データ生成部２２３は、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを生成する。次いで、通信部２２４は、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを監視サーバ５００に送信する。
【００８８】
一方、デバイス２００の動作モードが間接送信モードであった場合、Ｓ１１０６に移行し、デバイス２００の送信データ生成部２２３は、メソッドｃｈｅｃｋＨｏｓｔを含むＸＭＬ／ＳＯＡＰデータを生成する。次いで、通信部２２４は、メソッドｃｈｅｃｋＨｏｓｔを含むＸＭＬ／ＳＯＡＰデータを監視サーバ５００に送信する。
【００８９】
なお、本実施形態においては、デバイス２００の制御部２０１がＳ１１０４〜Ｓ１１０６の処理を行うことは、本発明における決定手段の機能を担う。
【００９０】
以降、Ｓ１１０７〜Ｓ１１０９の処理は、実施形態１における図７のＳ７０５〜Ｓ７０７の処理と同じである。
【００９１】
以上説明した通り、本実施形態における監視システム８００においては、実施形態１の態様に加えて、通信確認要求の送信先の監視サーバの種類に応じて、デバイス２００が異なる種類のメソッドを含むＸＭＬ／ＳＯＡＰデータを送信データとして生成する。かかる構成により、監視システム内に複数の監視サーバを備えるネットワーク構成であっても、デバイスはそれぞれ異なるメソッドをサポートする監視サーバに対して、通信確認要求を送信することができる。そのため、複数のデバイスそれぞれからサービスモード情報を一旦ＬＡＮ内の管理サーバに集約し、集約したサービスモード情報をＬＡＮ外の監視サーバにまとめて送信するという柔軟な運用を提供することができる。
【００９２】
［実施形態３］
本実施形態における監視システムでは、デバイス２００が通信確認要求やサービスモード情報の送信に失敗した場合に、監視サーバ５００に送信データを再度送信するリトライを実行する態様について説明する。以下、本実施形態の説明において、上述の実施形態１または実施形態２と重複する説明は省略し、両実施形態における差異点のみについて説明する。
【００９３】
図１２は、本実施形態におけるサービスモード情報の送信処理の内容を示すフローチャートである。以下、図１２を参照して、本実施形態におけるサービスモード情報の送信処理の動作を説明する。
【００９４】
Ｓ１２０１〜Ｓ１２０５の処理は、実施形態１における図７のＳ７０１〜７０５の処理と同じである。
【００９５】
Ｓ１２０６において、デバイス２００の制御部２０１は、受信したイベントの種別を判定する。イベントが、アラーム発生またはサービスコールの発生であった場合は、Ｓ１２０７に移行する。
【００９６】
Ｓ１２０７において、デバイス２００の制御部２０１は、サービスモード情報の取得を行う。前述の通り、本実施形態においては、サービスモード情報取得部２２１が、デバイス２００の設定を示すサービスモード情報を、サブデバイスであるプリンタおよびスキャナなどから取得する。
【００９７】
Ｓ１２０８において、デバイス２００の制御部２０１は、サービスモード情報取得部２２１が取得したサービスモード情報を、ＣＰＵ２０２またはＲＡＭ２０３のキャッシュ領域に保存するキャッシュ処理を行う。このとき、デバイス２００の制御部２０１がＳ１２０８の処理を行うことは、本発明におけるキャッシュ手段の機能を担う。本実施形態においては、イベントがアラーム発生またはサービスコール発生の場合は、イベント発生時のサービスモード情報を監視サーバ５００に送信することで、監視サーバ５００がイベント発生時のサービスモード情報を解析することができる。
【００９８】
Ｓ１２０９において、デバイス２００の制御部２０１は、リトライまでの時間が経過したかを判定し、リトライまでの時間が経過したと判定された場合（Ｓ１２０９：Ｙｅｓ）、Ｓ１２１０において、「リトライフラグ＝１」とする処理を実行する。リトライフラグとは、後述のＳ１２１４において、当該サービスモード情報の送信がリトライによるものかを判定するために用いられる。Ｓ１２１０の処理が終了すると、再びＳ１２０２の処理に移行する。
【００９９】
一方、Ｓ１２０６において、イベントが通信テストまたはサービスモード情報更新であった場合は、Ｓ１２０７〜Ｓ１２１０までの処理をスキップし、再びＳ１２０２に移行する。本実施形態においては、イベントが通信テストまたはサービスモード情報更新の場合は、デバイス２００が最新のサービスモード情報を送信するべきであるため、デバイス２００の制御部２０１は、Ｓ１２０８のキャッシュ処理を行わない。
【０１００】
Ｓ１２０５において、ＸＭＬ／ＳＯＡＰデータの送信に成功したと判定した場合（Ｓ１２０５：Ｎｏ）、Ｓ１２１１にてさらに、デバイス２００の制御部２０１は、ＣＰＵ２０２またはＲＡＭ２０３のキャッシュ領域にキャッシュが記憶されているかを判定する。キャッシュが存在すると判定した場合（Ｓ１２１１：Ｙｅｓ）、デバイス２００の制御部２０１は、ＣＰＵ２０２またはＲＡＭ２０３のキャッシュ領域からキャッシュされたサービスモード情報を取得する（Ｓ１２１３）。一方、キャッシュが存在しないと判定した場合（Ｓ１２１１：Ｎｏ）、デバイス２００の制御部２０１は、サービスモード情報の取得を行う（Ｓ１２１２）。
【０１０１】
Ｓ１２１４において、デバイス２００の制御部２０１は、今回のサービスモード情報の送信がリトライであるかを判定する。具体的には、Ｓ１２１０でリトライフラグが「１」であるかを判定し、リトライフラグが「１」となっている場合は、今回のサービスモード情報の送信がリトライであると判定する。このとき、デバイス２００の制御部２０１がＳ１２０９，Ｓ１２１０，Ｓ１２１４，Ｓ１２１９，Ｓ１２２０の各処理を行うことは、本発明における判定手段の機能を担う。
【０１０２】
リトライの場合（Ｓ１２１４：Ｙｅｓ）、デバイス２００の制御部２０１は、Ｓ１２１２またはＳ１２１３で取得したサービスモード情報のから優先度の高い項目を抽出する処理を実行する（Ｓ１２１５）。リトライが発生していると判定されている場合は、デバイス２００と監視サーバ５００との間の通信状況が不安定である可能性があるため、デバイス２００の制御部２０１は、サービスモード情報のから優先度の高い項目から監視サーバ５００に送信する。
【０１０３】
本実施形態においては、上記の構成により、デバイス２００が送信データを生成する処理負荷、およびデバイス２００から監視サーバ５００に送信データを送信するネットワーク負荷を低くし、送信データの送信成功の可能性を高くすることができる。その後、デバイス２００の制御部２０１は、サービスモード情報の優先度の高い項目についての送信データの送信が成功した場合は、優先度の低い項目を段階的に送信する分割送信を続けて実行してもよい。
【０１０４】
Ｓ１２１６において、送信データ生成部２２３は、取得したサービスモード情報から、監視サーバ５００に送信する送信データを生成する。次いで、デバイス２００の通信部２２４は、サービスモード情報を監視サーバ５００に送信する処理を実行する。本実施形態においては、送信データ生成部２２３が生成した、メソッドｐｏｓｔＳｅｒｖｉｃｅＭｏｄｅを含むＸＭＬ／ＳＯＡＰデータを、監視サーバ５００に送信する。
【０１０５】
Ｓ１２１７において、デバイス２００の制御部２０１は、ＸＭＬ／ＳＯＡＰデータの送信に成功したかを判定する。ＸＭＬ／ＳＯＡＰデータの送信に成功したと判定した場合（Ｓ１２１７：Ｙｅｓ）、Ｓ１２１６で送信された送信データが監視サーバ５００に到達し、かつ監視サーバからの応答があったものと判断し、Ｓ１２１８に移行する。
【０１０６】
一方、ＸＭＬ／ＳＯＡＰデータの送信に失敗したと判定した場合（Ｓ１２１７：Ｎｏ）、Ｓ１２１６で送信された送信データが監視サーバ５００に到達しなかったか、または監視サーバからの応答がなかったものと判断し、Ｓ１２１９に移行する。
【０１０７】
Ｓ１２１８において、デバイス２００の制御部２０１は、ＣＰＵ２０２またはＲＡＭ２０３のキャッシュ領域に記憶されているサービスモード情報に係るキャッシュを削除し、本フローチャートを終了する。
【０１０８】
一方、ＸＭＬ／ＳＯＡＰデータの送信に失敗したと判定した場合（Ｓ１２１７：Ｎｏ）、Ｓ１２１９において、デバイス２００の制御部２０１は、リトライまでの時間が経過したかを判定する。リトライまでの時間が経過したと判定された場合（Ｓ１２１９：Ｙｅｓ）、Ｓ１２２０において、「リトライフラグ＝１」とする処理を実行する。Ｓ１２１０の処理が終了すると、再びＳ１２０４の処理に移行する。
【０１０９】
本実施形態においては、サービスモード情報の監視サーバへの送信に失敗した場合、Ｓ１２０４において、デバイス２００の通信部２２４は、メソッドｇｅｔＣｌｏｃｋを含むＸＭＬ／ＳＯＡＰデータを監視サーバ５００に送信する。サービスモード情報の送信が失敗したと判定された場合、デバイス２００の処理負荷が過剰であるか、またはデバイス２００と監視サーバ５００との間の通信状況が不安定である可能性がある。そのため、デバイス２００の制御部２０１は、サービスモード情報の送信データを生成するよりも、より処理負荷の低い通信確認要求の送信データを生成して、通信確認要求を送信するためのデバイス２００への処理負荷またはネットワーク負荷を低くする。
【０１１０】
以上説明した通り、本実施形態における監視システムにおいては、実施形態１の態様に加えて、通信確認要求またはサービスモード情報の送信に失敗した場合、デバイス２００は監視サーバ５００への送信データの送信をリトライする。さらに、サービスモード情報にかかるキャッシュが記憶されている場合は、記憶されているキャッシュに基づいて送信データを監視サーバに送信する。また、デバイス２００は、リトライ時にサービスモード情報を送信するデータ構造と同じデータ構造の通信確認要求を、再度監視サーバ５００に送信する。
【０１１１】
本実施形態における監視システムを上記の通りに構成することにより、デバイス２００がサービスモード情報を取得するための無駄な処理を回避させるとともに、ネットワークに不必要な通信負荷をかけることを回避することができる。
【０１１２】
［応用例］
実施形態１において、図７のＳ７０２〜Ｓ７０３及びＳ７０７では、通信部２２４による通信確認を意図する“ｇｅｔＣｌｏｃｋ”を含むＸＭＬ／ＳＯＡＰデータの送信を省略して、サービスモード情報の送信を行っている。同様に、実施形態２において、図１１のＳ１１０２〜Ｓ１１０３及びＳ１１０９では、通信部２２４による通信確認を意図する“ｇｅｔＣｌｏｃｋ”を含むＸＭＬ／ＳＯＡＰデータの送信を省略して、サービスモード情報の送信を行っている。これは、サービスコールなどの通知を、サービスモード情報の送信と同様に、ＸＭＬ／ＳＯＡＰデータで送信しているので、その送信成功が通信確認の成功と同義とみなせるからである。
【０１１３】
ここで、サービスコールなどの通知が、ＸＭＬ／ＳＯＡＰデータ以外の送信方法であるなど、通信確認と同義と言えない場合も存在するかもしれない。もしくは、そういったサービスコールなどの通知に加えて、さらに、“ｇｅｔＣｌｏｃｋ”を含むＸＭＬ／ＳＯＡＰデータ以外の何らかの通信を行うことで、通信確認の成功と同義とみなせる場合もあり得る。
【０１１４】
本応用例では、上述の実施形態に加えて、サービスモード情報の送信が必要なイベント発生時の送信が成功した場合であっても、さらにその送信内容を識別した上で、“ｇｅｔＣｌｏｃｋ”を含むＸＭＬ／ＳＯＡＰデータを用いた送信制御を行ってもよい。また、その場合には、追加で行うメソッドとして、“ｇｅｔＣｌｏｃｋ”以外のメソッドを利用してもよい。よって、本応用例では、これらの送信に更に成功した場合にのみ、サービスモード情報の取得と送信を行うように制御する。
【０１１５】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【０１１６】
１００・・監視システム
１１０・・インターネット
１２０・・ＬＡＮ
２００・・デバイス
２０１・・制御部
２２１・・サービスモード情報取得部
２２２・・サービスモード情報管理部
２２３・・送信データ生成部
２２４・・通信部
２３０・・サービスモード情報
３００・・プロキシサーバ
４００・・ＰＣ
５００・・監視サーバ
【図１】
0006415261.tif 000002
【図２】
0006415261.tif 000003
【図３】
0006415261.tif 000004
【図４】
0006415261.tif 000005
【図５】
0006415261.tif 000006
【図６】
0006415261.tif 000007
【図７】
0006415261.tif 000008
【図８】
0006415261.tif 000009
【図９】
0006415261.tif 000010
【図１０】
0006415261.tif 000011
【図１１】
0006415261.tif 000012
【図１２】
0006415261.tif 000013