JP2007293470A - 被監視デバイスおよび被監視デバイスの制御方法 - Google Patents

Abstract

【課題】簡便な構成により冗長な監視を実現する。
【解決手段】繰り返し問い合わせを行うことによりデバイスを監視する第１および第２の監視装置と接続される被監視デバイスは、受信部と、応答部と、を備える。受信部は、第１の監視装置からの第１の問い合わせ、および、第２の監視装置からの第２の問い合わせを受信する。応答部は、第１の問い合わせに応じて、被監視デバイスに関する属性情報を第１の監視装置に通知する。さらに、応答部は、最後の第１の問い合わせから所定時間が経過した後に、第２の問い合わせを受けた場合に、第２の問い合わせに応じて属性情報を第２の監視装置に通知し、最後の第１の問い合わせから所定時間が経過する前に、第２の問い合わせを受けた場合に、属性情報を第２の監視装置に通知しない。
【選択図】図７

Description

本発明は、被監視デバイスに関し、特に、複数の監視装置と接続される被監視デバイスに関する。

ローカルエリアネットワークをはじめとするネットワークに接続して使用されるネットワークデバイス、例えば、ネットワークプリンタを、ネットワーク上の監視装置を用いて監視することが行われている。ネットワークデバイスは、自発的にあるいは監視装置からの要求に応じて、ネットワークデバイスの動作状態などの属性情報を、監視装置に送信する。

かかる場合、例えば、監視装置に障害が発生したときに、ネットワークデバイスの監視が中断してしまうことを抑制するために、ネットワークデバイスを含むネットワークシステムに複数の監視装置を導入する、いわゆる冗長な監視を行うシステムが知られている。

このようなネットワークシステムにおいて、ネットワークデバイスが、常時、複数の監視装置に対して属性情報を送信していたのでは、ネットワークデバイスの負荷やネットワークトラフィックが大きくなってしまう。このため、ネットワークデバイスが、定期的に自分を監視している監視装置に対して監視信号を送信することによって、監視装置における障害の有無を監視する技術が知られている（例えば、特許文献１）。この技術において、ネットワークデバイスは、自分を監視している監視装置の障害を検出すると、他の監視装置を探索し、新たに自分を監視する監視装置を決定する。そして、ネットワークデバイスは、新たに決定した監視装置に対して代替監視要求を送信し、以後、新たな監視装置に対して属性情報を送信する。

特開２００２−３３０１３２号公報 特開２００３−５１８２２号公報

しかしながら、上記ネットワークシステムでは、ネットワークデバイスの負荷が大きいという問題があった。ネットワークデバイスは、属性情報の送信に加えて、定期的な監視装置の監視、障害時における新たな監視装置の探索・決定、代替監視要求の送信など、多くの処理を行う必要があるからである。このため、例えば、リソースの少ないネットワークデバイスおよび監視装置を用いるネットワークシステムなどのために、監視装置の負荷をあげることなく、ネットワークデバイスの負荷を低減可能なより簡便な仕組みが望まれていた。

本発明は、上記課題を解決するためになされたものであり、複数の監視装置と被監視デバイスを含むシステムにおいて、簡便な構成により冗長な監視を実現することを目的とする。

上記課題の少なくとも一部を解決するため、本発明の第１の態様は、繰り返し問い合わせを行うことによりデバイスを監視する第１および第２の監視装置と接続される被監視デバイスを提供する。第１の態様に係る被監視デバイスは、受信部と、応答部と、を備える。前記受信部は、前記第１の監視装置からの第１の問い合わせ、および、前記第２の監視装置からの第２の問い合わせを受信する。前記応答部は、前記第１の問い合わせに応じて、前記被監視デバイスに関する属性情報を前記第１の監視装置に通知する。さらに、前記応答部は、最後の前記第１の問い合わせから所定時間が経過した後に、前記第２の問い合わせを受けた場合に、前記第２の問い合わせに応じて前記属性情報を前記第２の監視装置に通知し、最後の前記第１の問い合わせから所定時間が経過する前に、前記第２の問い合わせを受けた場合に、前記属性情報を前記第２の監視装置に通知しない。

第１の態様に係る被監視デバイスによれば、第１の監視装置からの問い合わせに対しては、属性情報を通知する。そして、第１の監視装置から所定時間に亘って問い合わせがない場合に限って、第２の監視装置からの問い合わせに対して属性情報を通知する。この結果、第１の監視装置や第１の監視装置との通信経路に障害が発生した場合には第２の監視装置に対して属性情報が通知される冗長な監視が実現される。さらに、第１の監視装置が正常な場合、すなわち、定期的に第１の監視装置からの問い合わせが受信されている場合には、第２の監視装置に対して、属性情報が通知されないので、ネットワークトラフィックを抑制することができる。さらに、被監視デバイスは、監視装置からの問い合わせがあった場合に、属性情報の通知・非通知の処理を行うだけでよいので、被監視デバイスの負荷が抑制される。また、第１および第２の監視装置は、被監視デバイスに対して、繰り返し問い合わせを行い、その属性情報を受け取るだけなので、これらの監視装置の負荷が大きくなることもない。

第１の態様に係る被監視デバイスにおいて、前記第１の監視装置は、所定の周期で、前記第１の問い合わせを繰り返し送信し、前記所定時間は、前記所定の周期より長くても良い。こうすれば、被監視デバイスは、第１の監視装置や第１の監視装置との通信経路に障害が発生した場合に限り、第２の監視装置に対して属性情報を通知することを、精度良く行うことができる。

第１の態様に係る被監視デバイスにおいて、前記第１の監視装置は、前記被監視デバイスに対して先に問い合わせを行った監視装置であり、前記第２の監視装置は、前記被監視デバイスに対して後に問い合わせを行った監視装置であっても良い。こうすれば、被監視デバイスは、問い合わせの順序に応じて、優先する監視装置を決定できる。

第１の態様に係る被監視デバイスにおいて、前記応答部は、最後の前記第１の問い合わせから所定時間が経過する前に、前記第２の問い合わせを受けた場合に、前記第２の監視装置に対して前記属性情報を含まないパケットを送信する。こうすれば、第２の監視装置は、パケットを受信することにより、被監視デバイスが第２の問い合わせを受信したことを認識することができる。また、このパケットは、属性情報を含まないため、サイズが小さく、ネットワークトラフィックを増加させることもない。

本発明の第２の態様は、繰り返し問い合わせを行うことによりデバイスを監視する複数の監視装置と接続される被監視デバイスを提供する。第２の態様に係る被監視デバイスは、記憶部と、受信部と、判断部と、応答部とを備える。前記記憶部は、前記複数の監視装置の優先順位を記憶する。前記受信部は、前記複数の監視装置からの問い合わせを受信する。前記判断部は、第１の問い合わせが受信された時より所定時間前から、前記第１の問い合わせが受信された時までの期間に、前記第１の問い合わせを行った監視装置より優先順位が高い他の監視装置からの第２の問い合わせが受信されたか否かを判断する。前記応答部は、前記期間に前記第２の問い合わせが受信されていないと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記被監視デバイスに関する属性情報を通知し、前記期間に前記第２の問い合わせが受信されたと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記属性情報を通知しない。

第２の態様に係る被監視デバイスによれば、優先順位が最も高い監視装置からの問い合わせに対しては、常に属性情報を通知する。一方で、それ以外の監視装置からの問い合わせに対しては、優先順位の高い他の監視装置からの問い合わせが所定時間以上ない場合に限り、属性情報を通知する。この結果、優先順位の高い監視装置やその監視装置との通信経路に障害が発生した場合には、優先順位の低い監視装置に対して属性情報が通知される冗長な監視が実現される。さらに、優先順位の高い監視装置が正常な場合、優先順位の低い他の監視装置に対して、属性情報が通知されないので、ネットワークトラフィックを抑制することができる。さらに、被監視デバイスは、監視装置からの問い合わせがあった場合に、属性情報の通知・非通知の処理を行うだけでよいので、被監視デバイスの負荷が抑制される。また、第１および第２の監視装置は、被監視デバイスに対して、繰り返し問い合わせを行い、その属性情報を受け取るだけなので、これらの監視装置の負荷が大きくなることもない。

第２の態様に係る被監視デバイスにおいて、前記複数の監視装置は、所定の周期で、前記問い合わせを繰り返し送信し、前記所定時間は、前記所定の周期より長くても良い。こうすれば、被監視デバイスは、優先順位の高い監視装置やその監視装置との通信経路に障害が発生した場合に限り、優先順位の低い監視装置に対して属性情報を通知することを、精度良く行うことができる。

第２の態様に係る被監視デバイスにおいて、前記複数の監視装置の優先順位は、各監視装置からの最初の問い合わせが受信された順番であっても良い。こうすれば、被監視デバイスは、容易に複数の監視装置の優先順位を決定することができる。

第２の態様に係る被監視デバイスにおいて、前記複数の監視装置の優先順位は、ユーザにより前記記憶部に記憶されても良い。こうすれば、複数の監視装置の優先順位をユーザが自由に設定することができる。

第２の態様に係る被監視デバイスにおいて、前記応答部は、前記期間に前記第２の問い合わせが受信されたと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記属性情報を含まないパケットを送信しても良い。こうすれば、第２の問い合わせを行った監視装置は、パケットを受信することにより、被監視デバイスが第２の問い合わせを受信したことを認識することができる。また、このパケットは、属性情報を含まないため、サイズが小さく、ネットワークトラフィックを増加させることもない。

なお、本発明は、種々の態様で実現することが可能であり、例えば、複数の監視装置と、被監視デバイスを備えるシステムとして実現することができる。さらに本発明は、繰り返し問い合わせを行うことによりデバイスを監視する複数の監視装置と接続される被監視デバイスの制御方法のような方法発明として実現することができる。あるいは、かかる装置、システムまたは方法を構築するためのコンピュータプログラム、そのコンピュータプログラムを記録した記録媒体、そのコンピュータプログラムを含み搬送波内に具現化されたデータ信号、等の態様で実現することができる。

以下、本発明について、図面を参照しつつ、実施例に基づいて説明する。

Ａ．第１実施例：
・ネットワークシステムの構成：
図１は、第１実施例におけるネットワークシステムの概略構成図である。ネットワークシステム１０００は、図１に示すように、クライアントとしての計算機（以下、単にクライアントという。）ＣＬ１〜ＣＬ３と、監視装置としての計算機ＡＧ１〜ＡＧ３（以下、単に監視装置という。）と、ネットワークデバイスとしてのプリンタＰＲＴ１〜ＰＲＴ８と、サーバＳＶと、を含む。クライアントＣＬ１〜ＣＬ３と、監視装置ＡＧ１〜ＡＧ３と、プリンタＰＲＴ１〜ＰＲＴ８とは、ローカルエリアネットワークＬＡＮ１を介して互いに接続されている。一方、サーバＳＶは、他のローカルエリアネットワークＬＡＮ２に接続されている。そのローカルエリアネットワークＬＡＮ１は、ファイアウォールＦＷを介してインターネットＩＮＴに接続されている。また、サーバＳＶは、ローカルエリアネットワークＬＡＮ２に接続されており、そのローカルエリアネットワークＬＡＮ２は、インターネットＩＮＴに接続されている。なお、以下の説明において、各クライアントＣＬ１〜ＣＬ３、各監視装置ＡＧ１〜ＡＧ３、および、各プリンタＰＲＴ１〜ＰＲＴ８を区別する必要がない場合には、符号の末尾の数字を省略し、それぞれ、クライアントＣＬ、監視装置ＡＧ、プリンタＰＲＴと表記する。

ファイアウォールＦＷは、ローカルエリアネットワークＬＡＮ１に接続された機器が、インターネットＩＮＴ経由で不正にアクセスされるのを避けるため、インターネットＩＮＴ経由で受信するこれら機器への接続要求を破棄するように設定されている。このため、ローカルエリアネットワークＬＡＮ１に接続された機器とサーバＳＶとの間で通信を行うためには、ローカルエリアネットワークＬＡＮ１に接続された機器からサーバＳＶに接続要求を送って、サーバＳＶとの間の接続を確立する必要がある。

クライアントＣＬは、中央演算装置（ＣＰＵ）と記憶装置（ＲＯＭ、ＲＡＭなど）を備える周知の計算機である。クライアントＣＬのユーザは、クライアントＣＬからローカルエリアネットワークＬＡＮ１を介して印刷ジョブを送信することによって、ローカルエリアネットワークＬＡＮ１上のプリンタＰＲＴに印刷を実行させることができる。

サーバＳＶは、中央演算装置（ＣＰＵ）と記憶装置（ＲＯＭ、ＲＡＭなど）を備える周知の計算機であり、ローカルエリアネットワークＬＡＮ１に接続されたプリンタＰＲＴ１〜ＰＲＴ８の稼働状況を管理する管理サーバとして機能する。サーバＳＶは、後述するように、ローカルエリアネットワークＬＡＮ１に接続された監視装置ＡＧ１〜ＡＧ３からプリンタＰＲＴ１〜ＰＲＴ８の属性情報を受信することにより、プリンタＰＲＴ１〜ＰＲＴ８の管理を行う。

図２〜図５を参照して、監視装置ＡＧ、および、プリンタＰＲＴについて説明する。図２は、第１実施例における監視装置ＡＧおよびプリンタＰＲＴの内部構成を示すブロック図である。図３は、収集情報ファイルの内容を概念的に示す説明図である。図４は、監視設定ファイルの内容を概念的に示す説明図である。図５は、エージェント管理テーブルの内容を概念的に示す説明図である。

監視装置ＡＧは、周知の計算機であり、図２に示すように、ＣＰＵ１１０と、ＲＡＭなどの内部記憶装置１２０と、ハードディスクなどの外部記憶装置１８０と、を備えている。監視装置ＡＧは、さらに、表示部１６０と、キーボードやマウスなどの操作部１７０と、通信インターフェース部（Ｉ／Ｆ部）１９０と、を備えている。通信Ｉ／Ｆ部１９０は、ローカルエリアネットワークＬＡＮ１に接続されており、ネットワーク上の他の機器との通信を実行する。

監視装置ＡＧの内部記憶装置１２０には、種々のプログラムやデータが格納されるが、図２においては、本実施例における処理に必要な構成を選択的に図示し、本明細書においては、図示された構成について説明する。内部記憶装置１２０には、エージェントプログラム１３０と、収集情報ファイル１４０と、監視設定ファイル１５０とが、格納されている。エージェントプログラム１３０がＣＰＵ１１０によって実行されることにより、プリンタＰＲＴから属性情報を収集し、サーバＳＶに送信するプリンタ監視機能が監視装置ＡＧにおいて実現される。

エージェントプログラム１３０は、問い合わせ部１３２と、応答受信部１３４と、収集情報送信部１３６とを含んでいる。問い合わせ部１３２は、プリンタＰＲＴ１〜ＰＲＴ８のうち、監視対象であるプリンタに、そのプリンタの属性情報を問い合わせる。応答受信部１３４は、問い合わせ部１３２による問い合わせに対して、問い合わせ先のプリンタから送信されてくる応答を受信する。応答に含まれるプリンタの属性情報は、収集情報ファイル１４０に記録される。収集情報送信部１３６は、収集情報ファイル１４０に記録されたプリンタの属性情報を、サーバＳＶに対して送信する。属性情報の問い合わせ、および、その応答の受信は、例えば、ＳＮＭＰ（Simple Network Management Protocol）に従って実行される。属性情報のサーバＳＶに対する送信は、例えば、ＨＴＴＰ（Hyper Text Transfer Protocol）に従って、実行される。

収集情報ファイル１４０は、上述したように監視装置ＡＧが問い合わせによって、監視対象のプリンタから収集されたプリンタの属性情報が格納されている。プリンタの属性情報は、各プリンタにおいてＭＩＢ(Management Information Base)として記録されている。ＭＩＢには、各種の属性情報がオブジェクトとして格納されている。ＭＩＢの各オブジェクトは、ツリー構造で管理され、それぞれにオブジェクトＩＤ（以下、ＯＩＤと呼ぶ。）が割り振られ、識別できるようになっている。このＯＩＤは、「１．４．２．２．１．３」のようにピリオドで区切られた数字となっている。

収集情報ファイル１４０には、図３に示すように、各監視対象のプリンタから収集した属性情報が、その属性情報に対応するＯＩＤ、その収集先のプリンタのプリンタＩＤ、および、その属性情報が収集された時刻と関連付けて、記録されている。

監視設定ファイル１５０は、監視装置ＡＧのエージェントプログラム１３０が、監視対象のプリンタから属性情報を収集する際に参照する情報が設定されたファイルである。監視設定ファイル１５０は、プリンタリスト１５０ａと、属性情報リスト１５０ｂを含んでいる。プリンタリスト１５０ａは、監視装置ＡＧが監視対象とするプリンタのプリンタＩＤが、ＩＰアドレスと関連付けて記録されている。例えば、図４に示す監視設定ファイル１５０のプリンタリスト１５０ａには、プリンタＰＲＴ１〜ＰＲＴ８全てが記録されているので、この監視設定ファイル１５０を格納する監視装置ＡＧは、プリンタＰＲＴ１〜ＰＲＴ８全てを監視対象としていることが解る。ここで、各監視装置ＡＧ１〜ＡＧ３は、必ずしもプリンタＰＲＴ１〜ＰＲＴ８全てを監視対象とする必要はないが、プリンタＰＲＴ１〜ＰＲＴ８のそれぞれが監視装置ＡＧ１〜ＡＧ３のうちの２以上の監視装置から監視対象とされることが好ましい。こうすることによって、各プリンタＰＲＴ１〜ＰＲＴ８について冗長な監視が行われ、監視装置のいずれかが故障した場合などにおいても、監視漏れを防止または抑制することができる。

属性情報リスト１５０ｂは、監視対象のプリンタから収集すべき属性情報の項目を特定するための情報である。具体的には、属性情報リスト１５０ｂは、図４に示すように、属性情報を識別するＯＩＤが、その属性情報を収集する収集周期と関連付けて記録されている。３０秒ごとに収集される属性情報は、例えば、紙詰まりなどプリンタのエラー状態を示すエラー情報や、印刷枚数などプリンタの印刷実績を示す実績情報を含む。また、１時間ごとに収集される属性情報は、例えば、プリンタのトナー残量などの消耗品情報などを含む。１日ごとに収集される属性情報は、例えば、プリンタにインストールされたファームウエアのバージョン、プリンタに搭載されたネットワークボードの種類、プリンタの機種などの構成情報を含む。

監視設定ファイル１５０は、ネットワーク管理者により各監視装置ＡＧに格納されても良いし、エージェントプログラム１３０がサーバＳＶに取得要求を送信することにより、サーバＳＶから取得されても良い。

図２に示すように、プリンタＰＲＴは、プリンタ本体ＰＲＢと、ネットワークボードＮＢと、を備えている。

プリンタ本体ＰＲＢは、プリンタコントローラ２６０とプリンタエンジン２７０とを備えている。プリンタエンジン２７０は、画像の印刷を実行する機構部分である。プリンタコントローラ２６０は、ネットワークボードＮＢから与えられた実行対象の印刷ジョブに従って、プリンタエンジン２７０に印刷を実行させる。プリンタコントローラ２６０は、印刷ジョブを格納するプリンタバッファ２６２と、自らの属性情報を記録した上述したＭＩＢを格納するＭＩＢ格納部２６４と、を備えている。

ネットワークボードＮＢは、ＣＰＵとＲＯＭやＲＡＭなどのメモリとを備えるコンピュータである。ネットワークボードＮＢは、通信制御部２１０と、ジョブ処理部２３０と、被監視処理部２４０、エージェント管理テーブル２５０とを含んでいる。各機能部２１０、２３０、２４０の機能は、図示しないメモリに格納されたファームウエアをＣＰＵが実行することによって実現される。

ジョブ処理部２３０は、クライアントＣＬから送信された印刷ジョブをプリンタコントローラ２６０に渡す。被監視処理部２４０は、プリンタＰＲＴの被監視デバイスとしての機能を実現する機能部である。通信制御部２１０は、ジョブ処理部２３０および被監視処理部２４０の下位層にある通信プロトコル、例えば、ＴＣＰ／ＩＰを解釈して、ジョブ処理部２３０および被監視処理部２４０と外部の機器との通信を実現する。

被監視処理部２４０は、受信部２４２と、判断部２４４と、応答部２４６とを含む。受信部２４２は、監視装置ＡＧからの問い合わせを受信する。判断部２４４は、監視装置ＡＧからの問い合わせに対して、属性情報を通知するか否かを判断する。応答部２４６は、監視装置ＡＧからの問い合わせに対する応答を、監視装置ＡＧに対して送信する。応答部２４６は、判断部２４４が属性情報を通知すると判断した場合に、応答に属性情報を含ませることにより、監視装置ＡＧに対して属性情報を通知する。なお、被監視処理部２４０における処理については、さらに後述する。

エージェント管理テーブル２５０は、プリンタＰＲＴが、自身を監視する監視装置ＡＧを管理するためのテーブルである。エージェント管理テーブル２５０には、図５に示すように、そのプリンタＰＲＴを監視している監視装置ＡＧのＩＰアドレスが、優先順位と関連付けられて記録されている。また、エージェント管理テーブル２５０には、記録されている監視装置ＡＧごとに、問い合わせ受信時刻を記録する欄が設けられている。この欄には、各監視装置ＡＧから送信された最後の問い合わせの受信時刻が記録される。エージェント管理テーブル２５０については、問い合わせに対する応答処理を説明する際にさらに説明する。

・監視装置ＡＧにおける処理：
図６を参照して監視装置ＡＧのエージェントプログラム１３０が実行する監視処理について説明する。図６は、監視処理の処理ルーチンを示すフローチャートである。監視処理は、監視対象であるプリンタに対して繰り返し問い合わせを行うことにより、プリンタを監視する処理である。監視処理は、監視装置ＡＧが起動されている間は、常に実行されている。

エージェントプログラム１３０の問い合わせ部１３２は、問い合わせ時刻になったか否かを判断する（ステップＳ１０２）。問い合わせ部１３２は、上述した監視設定ファイル１５０を参照することにより、監視周期を認識して、監視周期に応じて問い合わせ時刻を設定している。問い合わせ部１３２は、設定された問い合わせ時刻になったと判断すると（ステップＳ１０２：ＹＥＳ）、問い合わせ先のプリンタＰＲＴを特定する（ステップＳ１０４）。具体的には、問い合わせ部１３２は、監視設定ファイル１５０のプリンタリスト１５０ａを参照して、問い合わせ先となる１または複数の監視対象プリンタを特定する。

監視対象プリンタが特定されると、問い合わせ部１３２は、問い合わせ項目を特定する（ステップＳ１０６）。問い合わせ部１３２は、監視設定ファイル１５０の属性情報リスト１５０ｂを参照して、収集対象である属性情報のＯＩＤを取得することにより、問い合わせ項目を特定する。

問い合わせ先、および、問い合わせ項目が特定されると、問い合わせ部１３２は、一の問い合わせ先、すなわち、ステップＳ１０４において問い合わせ先として特定された監視対象プリンタの一つに対して、問い合わせを行う（ステップＳ１０８）。具体的には、問い合わせ部１３２は、監視対象プリンタのＩＰアドレスを送信先ＩＰアドレスとし、ＳＮＭＰプロトコルに従った情報要求を送信する。情報要求には、問い合わせ項目として取得されたＯＩＤが記述される。

問い合わせが行われると、問い合わせ先の監視対象プリンタから応答が送信されてくるので、エージェントプログラム１３０の応答受信部１３４は、かかる応答を取得する（ステップＳ１１０）。応答受信部１３４は、応答を取得すると、その応答に属性情報が含まれているか否かを判断する（ステップＳ１１２）。後述するように、問い合わせ先からの応答には、問い合わせにおいて指定したＯＩＤに対応する属性情報が含まれる場合と、含まれていない場合がある。応答受信部１３４は、応答に属性情報が含まれている場合には（ステップＳ１１２：ＹＥＳ）、属性情報を取得して、収集情報ファイル１４０に記録する（ステップＳ１１４）。

応答に属性情報が含まれていない場合（ステップＳ１１２：ＮＯ）、あるいは、属性情報が収集情報ファイル１４０に記録された後、問い合わせ部１３２は、ステップＳ１０４において問い合わせ先として特定された全ての監視対象プリンタに対して、問い合わせが終了したか否かを判断する（ステップＳ１１６）。問い合わせ部１３２は、全ての問い合わせ先に対して問い合わせが終了していないと判断すると（ステップＳ１１６：ＮＯ）、ステップＳ１０８に戻って、問い合わせが行われていない問い合わせ先（監視対象プリンタ）に対する問い合わせを実行する。一方、問い合わせ部１３２は、全ての問い合わせ先に対して問い合わせが終了したと判断すると（ステップＳ１１６：ＹＥＳ）、ステップＳ１０２にリターンする。

ステップＳ１０２において、問い合わせ部１３２が設定された問い合わせ時刻になっていないと判断すると（ステップＳ１０２：ＮＯ）、エージェントプログラム１３０の収集情報送信部１３６は、サーバ送信時刻になったか否かを判断する（ステップＳ１１８）。サーバ送信時刻は、例えば、予め定められた周期（例えば、３時間）で定期的に設定される。収集情報送信部１３６は、サーバ送信時刻になったと判断すると（ステップＳ１１８：ＹＥＳ）、サーバＳＶに対して、収集情報ファイル１４０を送信する。具体的には、収集情報送信部１３６は、サーバＳＶに対して接続要求を送信して、監視装置ＡＧとサーバＳＶ間のコネクションを確立し、そのコネクションを介して収集情報ファイル１４０をサーバＳＶにアップロードする。

収集情報ファイル１４０がサーバＳＶに送信されると、収集情報送信部１３６は、収集情報ファイル１４０を更新する（ステップＳ１２２）。例えば、収集情報送信部１３６は、送信済みの収集情報ファイル１４０をバックアップとして保存し、新たな収集情報ファイル１４０を、以降に収集された属性情報を格納するために用意する。収集情報ファイル１４０が更新されると、本処理は、ステップＳ１０２にリターンされる。

ステップＳ１１８において、サーバ送信時刻になっていないと判断されると（ステップＳ１１８：ＮＯ）、本処理は、ステップＳ１０２にリターンされる。

以上説明した監視処理が、複数の監視装置ＡＧ１〜ＡＧ３において、それぞれ独立して実行される。これにより、複数の監視装置ＡＧ１〜ＡＧ３において、それぞれの監視対象であるプリンタＰＲＴの属性情報が定期的に収集され、収集された属性情報は、定期的にサーバＳＶにアップロードされる。

・プリンタＰＲＴにおける処理：
図７を参照して、各プリンタＰＲＴ１〜ＰＲＴ８の被監視処理部２４０が実行する被監視処理について説明する。図７は、被監視処理の処理ルーチンを示すフローチャートである。被監視処理は、監視装置ＡＧからの問い合わせを受けた場合に実行される。

問い合わせが監視装置ＡＧから送信されてくると、被監視処理部２４０の受信部２４２は、当該問い合わせを受信する（ステップＳ３０２）。問い合わせが受信されると、被監視処理部２４０は、問い合わせ元の監視装置ＡＧを特定する（ステップＳ３０４）。ＩＰアドレスは、監視装置ＡＧごとに異なるので、被監視処理部２４０は、問い合わせ（本実施例では、ＳＮＭＰに従った情報要求）のヘッダ、例えば、ＴＣＰ／ＩＰヘッダに含まれる送信元ＩＰアドレスあるいはＭＡＣアドレスを参照することにより、問い合わせ元を特定することができる。

被監視処理部２４０は、次いで、特定された問い合わせ元の監視装置ＡＧがエージェント管理テーブル２５０に登録済みであるか否かを判断する（ステップＳ３０６）。被監視処理部２４０は、問い合わせ元の監視装置ＡＧがエージェント管理テーブル２５０に登録済みでないと判断すると（ステップＳ３０６：ＮＯ）、当該問い合わせ元の監視装置ＡＧをエージェント管理テーブル２５０に登録する。具体的には、被監視処理部２４０は、当該監視装置ＡＧを特定するための情報、本実施例では、ＩＰアドレスをエージェント管理テーブル２５０に登録する（図５）。その際、被監視処理部２４０は、新たに登録された監視装置ＡＧに優先順位を割り当て、その優先順位を監視装置ＡＧに関連付けてエージェント管理テーブル２５０に記録する（図５）。本実施例では、エージェント管理テーブル２５０に登録された順番に、すなわち、監視装置ＡＧからの最初の問い合わせを受信した順番に、各監視装置ＡＧの優先順位が割り当てられる。なお、図５に示すエージェント管理テーブル２５０には、３台の監視装置ＡＧが登録されていることが解る。

被監視処理部２４０は、問い合わせ元の監視装置ＡＧがエージェント管理テーブル２５０に登録済みであると判断した場合（ステップＳ３０６：ＹＥＳ）、あるいは、問い合わせ元の監視装置ＡＧをエージェント管理テーブル２５０に登録した後、当該問い合わせが受信された時刻（問い合わせ受信時刻）を、エージェント管理テーブル２５０に記録する（ステップＳ３１０：図５参照）。問い合わせ受信時刻は、他の機器にとって意味のある時刻である必要はなく、当該プリンタＰＲＴ内部で管理されている時刻であっても良い。本実施例では、問い合わせ受信時刻は、プリンタＰＲＴの電源投入からの経過時間を用いる。ここで、被監視処理部２４０は、問い合わせ受信時刻を記録する際、既に記録欄に以前の問い合わせ受信時刻が記録されている場合には、以前に記録した時刻を消去して、新たな問い合わせ受信時刻に更新する。この結果、エージェント管理テーブル２５０の問い合わせ受信時刻の記録欄には、登録済み監視装置ＡＧごとに、その監視装置ＡＧからの最後の問い合わせが受信された時刻が記録されていることになる。

次いで、被監視処理部２４０の判断部２４４は、問い合わせ元の監視装置ＡＧより優先順位の高い他の監視装置ＡＧが、エージェント管理テーブル２５０に登録されているか否かを判断する（ステップＳ３１２）。判断部２４４は、問い合わせ元より優先順位が高い他の監視装置ＡＧがエージェント管理テーブル２５０に登録されている場合（ステップＳ３１２：ＹＥＳ）、当該優先順位の高い他の監視装置ＡＧからの問い合わせが、所定期間中にあったか否かを判断する（ステップＳ３１４）。所定期間は、現在時刻（処理中の問い合わせの受信時刻）より判断時間Ｔ１分だけ前の時点から、現在時刻までの期間である。この判断は、エージェント管理テーブル２５０に記録されている各登録済みＡＧの問い合わせ受信時刻を参照することにより、実行される。

本実施例では、判断時間Ｔ１＝７５（秒）とされている。例えば、現在処理中の問い合わせが、受信時刻ｔ＝１２５７０（秒）に受信され、優先順位が３番目の監視装置ＡＧからの問い合わせであるとする。この場合、判断部２４４は、時刻１２４９５から時刻１２５７０（現在時刻）までの期間に、優先順位１番目または２番目の監視装置ＡＧから問い合わせがあったか否かを判断する。

判断部２４４が、所定期間内に優先順位の高い他の監視装置ＡＧから問い合わせが有ったと判断すると（ステップＳ３１４：ＹＥＳ）、被監視処理部２４０の応答部２４６は、現在処理中の問い合わせの問い合わせ元である監視装置ＡＧに対して、空パケットを応答として送信し（ステップＳ３１６）、本処理を終了する。空パケットは、処理中の問い合わせが要求する属性情報を含まないパケットを意味し、極力サイズを小さくすることが望ましい。

一方、問い合わせ元より優先順位が高い他の監視装置ＡＧがエージェント管理テーブル２５０に登録されていない場合（ステップＳ３１２：ＮＯ）、または、判断部２４４が、所定期間内に優先順位の高い他の監視装置ＡＧから問い合わせがなかったと判断した場合（ステップＳ３１４：ＮＯ）には、応答部２４６は、問い合わせに応じて、問い合わせが要求する属性情報を取得する（ステップＳ３１８）。具体的には、判断部２４４は、現在処理中の問い合わせに含まれているＯＩＤに対応する属性情報を、ＭＩＢ格納部２６４に格納されているＭＩＢにアクセスして取得する。応答部２４６は、問い合わせ元である監視装置ＡＧに対して、取得された属性情報を、応答として送信し（ステップＳ３２０）、本処理を終了する。

ここで、上述した判断時間Ｔ１の長さは、監視装置ＡＧにおける最も短い問い合わせ周期より長く設定される。本実施例では、３０秒、１時間、１日の３種類の周期が設定されているため最も短い周期は、３０秒である（図４参照）。本実施例では、上述したように判断時間Ｔ１は、３０秒より長い７５秒に設定されている。

以上説明した監視装置ＡＧにおける監視処理（図５）およびプリンタＰＲＴにおける被監視処理（図６）が行われた結果、ネットワークシステム１０００において行われる問い合わせとその応答の様子を、図８および図９を参照して説明する。図８は、監視装置ＡＧからの問い合わせと、問い合わせに対するプリンタＰＲＴの応答を概念的に示す第１の説明図である。図９は、監視装置ＡＧからの問い合わせと、問い合わせに対するプリンタＰＲＴの応答を概念的に示す第２の説明図である。

図８および図９に示すように、あるプリンタＰＲＴに対して、３つの監視装置ＡＧ１〜ＡＧ３が、監視対象として周期的な問い合わせを行っているとする（図６）。３つの監視装置ＡＧ１〜ＡＧ３は、最初の問い合わせを行った順番に従って、それぞれ優先順位を割り当てられプリンタＰＲＴにおいて、エージェント管理テーブル２５０に記録される（図７：ステップＳ３０８）。ここで、図８および図９においてかっこ書きで示すように、優先順位は、監視装置ＡＧ２が１番目、監視装置ＡＧ１が２番目、監視装置ＡＧ３が３番目であるとする。

図８および図９において、横軸は時間の経過を示し、矢印は矢印の始点に対応する監視装置ＡＧからプリンタＰＲＴへの問い合わせを示す。また、矢印の終点に示す丸印およびバツ印は、その矢印が示す問い合わせに対するプリンタＰＲＴの応答の態様を示す。丸印は、応答が属性情報を含むこと、すなわち、図７：ステップＳ３２０によって行われる応答であることを示す。バツ印は、応答が属性を含まない空パケットであること、すなわち、図７：ステップＳ３１６によって行われる応答であることを示す。さらに、各監視装置ＡＧに対応する横線のうち実線部分は、その監視装置ＡＧが正常な状態であることを示し、破線部分はその監視装置ＡＧが障害状態であることを示す。ここで、監視装置ＡＧが正常であるとは、監視装置ＡＧが正常に監視処理を実行しており、かつ、監視装置ＡＧとプリンタＰＲＴとの間の通信が可能な状態であることを意味する。監視装置ＡＧが障害状態であるとは、監視装置自体の障害により監視処理が行われなくなった状態と共に、監視装置ＡＧとプリンタＰＲＴとの間の回線の障害などにより通信ができない状態を含む。

まず、図８および図９から解るように、優先順位が最も高い監視装置ＡＧ２は、行った問い合わせに対して必ず属性情報を含む応答が送信されることにより、属性情報が通知される。一方、優先順位が低い監視装置ＡＧ１および監視装置ＡＧ３は、優先順位が最も高い監視装置ＡＧ２が正常である期間には、行った問い合わせに対して空パケットが応答として送信され、属性情報が通知されない。これは、判断時間Ｔ１が、監視装置ＡＧ２の問い合わせ周期である３０秒より長い７５秒に設定されているため、監視装置ＡＧ２が３０秒周期で問い合わせを繰り返している間は、監視装置ＡＧ１および監視装置ＡＧ３が行った問い合わせに対する被監視処理（図７）におけるステップＳ３１４において、必ず、所定期間中に優先順位の高い監視装置から問い合わせが有ったと判断されるからである。

ここで、最も優先順位が高い監視装置ＡＧ２に障害が発生し、問い合わせができなくなった場合を考える。かかる場合には、監視装置ＡＧ２の障害発生前の最後の問い合わせから判断時間Ｔ１を経過した後に、２番目の優先順位を持つ監視装置ＡＧ１の問い合わせに対して、空パケットに代えて、属性情報を含む応答が送信される（図８）。この結果、プリンタＰＲＴの監視は、障害の発生した監視装置ＡＧ２に代わって、監視装置ＡＧ１が行うことになる。一方で、３番目の優先順位を持つ監視装置ＡＧ３の問い合わせに対しては、空パケットが送信され続ける。

ここで、さらに、２番目の優先順位を持つ監視装置ＡＧ１に障害が発生すると、最も優先順位が高い監視装置ＡＧ２に障害が発生した場合と同様の経過を経て、３番目の優先順位を持つ監視装置ＡＧ３に、プリンタＰＲＴの監視が引き継がれる。すなわち、監視装置ＡＧ１の障害発生前の最後の問い合わせから判断時間Ｔ１を経過した後に、３番目の優先順位を持つ監視装置ＡＧ１の問い合わせに対して、空パケットに代えて、属性情報を含む応答が送信される（図８）。

図９には、障害が発生した監視装置が復旧して、正常な監視処理を開始した場合におけるプロセスが示されている。監視装置ＡＧ１および監視装置ＡＧ２に障害が発生し、３番目の優先順位を持つ監視装置ＡＧ１に属性情報が通知されている状態において、２番目の優先順位を持つ監視装置ＡＧ１が障害から復旧し、プリンタＰＲＴに対して問い合わせを開始した場合には、速やかに、復旧した２番目の優先順位を持つ監視装置ＡＧ１にプリンタＰＲＴの監視が引き継がれる。すなわち、２番目の優先順位を持つ監視装置ＡＧ１からの問い合わせに対して属性情報が通知され、監視装置ＡＧ１からの復旧後における最初の問い合わせ後に、監視装置ＡＧ３からの問い合わせに対しては、空パケットが送信される（図９）。

さらに、最も優先順位が高い監視装置ＡＧ２が復旧して、正常な監視処理を開始すると、監視装置ＡＧ２からの問い合わせに対して、属性情報が通知され、他の監視装置ＡＧ１、ＡＧ３からの問い合わせに対しては、空パケットが送信される（図９）。

以上説明した第１実施例に係る被監視デバイスとしてのプリンタＰＲＴによれば、複数の監視装置ＡＧから繰り返し問い合わせを受けることのより監視対象とされている場合において、最も優先順位が高い監視装置ＡＧからの問い合わせに対しては、常に属性情報を通知する。一方で、それ以外の監視装置ＡＧからの問い合わせに対しては、優先順位の高い他の監視装置ＡＧからの問い合わせが判断時間Ｔ１以上ない場合に限り、属性情報を通知する。この結果、優先順位の高い監視装置ＡＧに何等かの障害が発生した場合には、優先順位の低い監視装置ＡＧに対して属性情報が通知される冗長な監視が実現される。

さらに、優先順位の高い監視装置ＡＧが正常に周期的な問い合わせを行っている場合、優先順位の低い他の監視装置ＡＧに対して、属性情報が通知されないので、ローカルエリアネットワークＬＡＮ１のトラフィックを抑制することができる。

さらに、各プリンタＰＲＴは、監視装置ＡＧからの問い合わせがあった場合に、被監視処理（図７）を行うだけで良い。すなわち、各プリンタＰＲＴは、被監視デバイスとしての他の処理、例えば、従来技術のように、監視装置を監視するためのヘルスチェック信号を監視装置に送信したり、一つの監視装置に障害が発生した場合に代替監視装置を選択したりする必要がないので、プリンタＰＲＴの負荷が抑制される。

また、複数の監視装置ＡＧは、プリンタＰＲＴに対して、互いに独立に繰り返し問い合わせを行い、その属性情報または空パケットを受け取るだけなので、例えば、複数の監視装置ＡＧ間で何等かの連携処理を行う必要がなく、これらの監視装置ＡＧの負荷が大きくなることもない。また、監視装置ＡＧを障害状態から復旧させる時に、監視処理を再開させるだけでよく、代行を行っている他の監視装置ＡＧやプリンタＰＲＴの再設定などを行う必要がない。さらに、ネットワークシステム１０００に新たな監視装置ＡＧを追加／削除する場合においても、他の監視装置ＡＧやプリンタＰＲＴに特別な設定などを行う必要がなく容易である。

さらに、複数の監視装置ＡＧからの収集情報ファイル１４０の送信を受け付け、プリンタＰＲＴの属性情報を管理するサーバＳＶには、複数の監視装置ＡＧから送信された属性情報が、時間的に重複することがない。このためサーバＳＶに不要な重複情報が送信されることがなく、サーバＳＶにおいて属性情報の取捨選択を行う必要がない。従って、さらに、ローカルエリアネットワークＬＡＮ１やインターネットＩＮＴのネットワークトラフィックを抑制できる共に、サーバＳＶの処理負荷も低減することができる。

Ｂ．第２実施例：
第１実施例において、監視処理は、独立した計算機である監視装置ＡＧによって実行されているが、これに限られない。例えば、監視処理を実行するエージェントプログラム１３０は、クライアントＣＬの一部または全部に実装されても良い。かかる場合には、クライアントＣＬが、第１実施例におけるクライアントとしての機能と共に、監視装置としての機能を備えることとなる。

また、エージェントプログラム１３０は、被監視デバイスとしてのプリンタＰＲＴの全部または一部に実装されても良い。図１０および図１１を参照して、監視処理を実行するエージェントプログラム１３０をプリンタに実装する態様を、第２実施例として説明する。図１０は、第２実施例におけるネットワークシステムの概略構成図である。図１１は、第２実施例における第１のプリンタＰＲＴａと第２のプリンタＰＲＴｂの内部構成を示すブロック図である。

第２実施例におけるネットワークシステム１０００ｂには、第１実施例におけるネットワークシステム１０００のような独立した監視装置ＡＧは備えられていない。ネットワークシステム１０００ｂは、第１実施例と異なり、２種類のプリンタ、すなわち、第１のプリンタＰＲＴａ１およびＰＲＴａ２と、第２のプリンタＰＲＴｂ１〜ＰＲＴｂ６とを備えている。第２実施例におけるネットワークシステム１０００ｂの他の構成は、第１実施例におけるネットワークシステム１０００と同一であるので、図１０において、同一の構成について図１と同一の符号を付し、その説明を省略する。また、以下の説明において、各第１のプリンタＰＲＴａ１およびＰＲＴａ２、各第２のプリンタＰＲＴｂ１〜ＰＲＴｂ６を区別する必要がない場合には、符号の末尾の数字を省略し、それぞれ、第１のプリンタＰＲＴａ、第２のプリンタＰＲＴｂと表記する。

第１のプリンタＰＲＴａは、プリンタ本体ＰＲＢと、カスタムネットワークボードＣＮＢと、を備えている。一方、第２のプリンタＰＲＴｂは、プリンタ本体ＰＲＢと、ネットワークボードＮＢを備えている。第１のプリンタＰＲＴａは、ネットワークボードＮＢに代えて、カスタムネットワークボードＣＮＢを備える点で、第１実施例におけるプリンタＰＲＴと異なり、他の構成については、第１実施例におけるプリンタＰＲＴと同一である。第２のプリンタＰＲＴｂは、第１実施例におけるプリンタＰＲＴと同一である。第１実施例と同一の構成については、その説明を省略する。

図１１に示すように、カスタムネットワークボードＣＮＢは、ネットワークボードＮＢが備える全構成要素、すなわち、通信制御部２１０、ジョブ処理部２３０、被監視処理部２４０、エージェント管理テーブル２５０を備える。カスタムネットワークボードＣＮＢは、さらに、第１実施例において監視装置ＡＧが備える監視処理のために必要な構成要素、すなわち、エージェントプログラム１３０、収集情報ファイル１４０、監視設定ファイル１５０を全て備える。

この結果、第１のプリンタＰＲＴａは、被監視デバイスとしての機能と、監視装置としての機能を備えることになる。例えば、図１０における第１のプリンタＰＲＴａ１のエージェントプログラム１３０は、第１のプリンタＰＲＴａ１自身を含むネットワークシステム１０００ｂ内のプリンタＰＲＴａ、ＰＲＴｂの全部または一部を監視対象として監視処理（図６）を実行する。さらに、第１のプリンタＰＲＴａ１は、第１のプリンタＰＲＴａ１自身、あるいは、第１のプリンタＰＲＴａ２のエージェントプログラム１３０からの問い合わせに対して応答するための被監視処理（図７）を実行する。

第１のプリンタＰＲＴａのエージェントプログラム１３０からみて、第１のプリンタＰＲＴａおよび第２のプリンタＰＲＴｂは、全て等価であり、エージェントプログラム１３０は、エージェントプログラム１３０自体が搭載されている第１のプリンタＰＲＴａについても、他のプリンタについても区別なく扱うことができる。

以上説明した第２実施例におけるネットワークシステム１０００ｂにおいても、第１実施例におけるネットワークシステム１０００と同様の作用・効果を奏することができる。また、ネットワークシステム１０００ｂでは独立した監視装置ＡＧを用意する必要がないため、簡易で小型のネットワークシステムを実現することができる。

Ｃ．変形例：
・第１変形例：
上記実施例において、プリンタＰＲＴの被監視デバイスとしての機能は、さらに、簡便な構成としても良い。例えば、プリンタＰＲＴは、各監視装置について優先順位を付けることなく、電源が投入された後、最初に受信された問い合わせの問い合わせ元のＩＰアドレスを記憶することとする。そして、以後、プリンタＰＲＴは、記憶されたＩＰアドレスを問い合わせ元とする問い合わせに対しては、常に、属性情報を通知する。一方、プリンタＰＲＴは、記憶されたＩＰアドレス以外のＩＰアドレスを問い合わせ元とする問い合わせに対しては、記憶されたＩＰアドレスを問い合わせ元とする問い合わせが、判断時間Ｔ１以上の期間に亘って受信されない場合に限り、属性情報を通知することとしても良い。

このような簡略化された構成であっても、特に、一台のプリンタＰＲＴに対する監視装置ＡＧが２台までであるシンプルなネットワークシステムにおいて、第１実施例と同様の作用・効果を実現することができる。また、さらにプリンタＰＲＴの処理負荷を低減することができる。

・第２変形例：
上記第１実施例においては、複数の監視装置ＡＧの優先順位は、最初の問い合わせが行われた順序に従って、プリンタＰＲＴが自動的に各監視装置ＡＧに付与しているが、これに代えて、ユーザが優先順位を設定してエージェント管理テーブル２５０に記述しても良い。こうすれば、ユーザの意図に応じたシステム構成を実現することができる。ただし、実施例のように自動的に優先順位を付与する場合には、ユーザの設定負担を軽減できる利点がある。

・第３変形例：
上記第１実施例においては、判断時間Ｔ１の長さは、７５秒に設定されているが、これに限られない。判断時間Ｔ１の長さは、監視装置ＡＧの問い合わせ周期、特に、優先順位が最低ではない監視装置ＡＧの問い合わせ周期を考慮して、適切な値に定められる。判断時間Ｔ１は、優先順位が最低ではない監視装置ＡＧにおける最も短い問い合わせ周期より長く設定するのが好ましい。そうでない場合には、優先順位が高い監視装置ＡＧが正常に問い合わせを繰り返しているにも関わらず、より優先順位が低い監視装置ＡＧからの問い合わせに対して、属性情報を通知してしまう場合があるからである。

また、監視装置ＡＧの負荷や、監視装置ＡＧとプリンタＰＲＴとの間の通信負荷などによって、監視装置ＡＧが正常であっても、問い合わせ周期が変動することもあり得るので、このような周期変動を考慮して、判断時間Ｔ１の長さを定めることが好ましい。こうすることにより、プリンタＰＲＴは、優先順位が高い監視装置ＡＧに以上が発生した場合に限り、優先順位の低い監視装置ＡＧからの問い合わせに対して、属性情報を通知することを、精度良く実行できる。

さらに、判断時間Ｔ１が長すぎると、図８を参照すると解るように、優先順位の高い監視装置ＡＧに障害が発生し、優先順位の低い監視装置ＡＧにプリンタＰＲＴの監視が引き継がれる時に、優先順位の高い監視装置ＡＧにおける障害発生から優先順位の低い監視装置ＡＧに最初に属性情報が通知されるまでの期間（引き継ぎ期間）が長くなる不都合がある。引き継ぎ期間が長くなると、属性情報がどの監視装置ＡＧに対しても送られない、いわゆる監視漏れが増加するおそれがある。

以上を考慮して、判断時間Ｔ１は、例えば、実施例のように各監視装置が同じ周期（実施例では、３０秒）で問い合わせを行う場合、その周期の２倍〜４倍程度に設定され得る。

・第４変形例：
上記第１実施例において、プリンタＰＲＴは、監視装置ＡＧからの問い合わせに対して属性情報を通知しない場合には、空パケットを監視装置ＡＧに対する応答として送信しているが、監視装置ＡＧに対して何も送信しないこととしても良い。ただし、実施例のように空パケットを送信することとすれば、監視装置ＡＧは、空パケットを受信することによって、自身が行った問い合わせがプリンタＰＲＴにおいて受信されたことを認識することができる利点がある。例えば、監視装置ＡＧは、自身が行った問い合わせに対する応答が所定のタイムアウト期間内に無いときは、問い合わせが送信先に届かなかったと認識して、再び問い合わせを繰り返す仕様とされる場合がある。かかる場合には、プリンタＰＲＴから空パケットが送信されてくることによって、不要な再問い合わせが行われることを抑制できる。

・第５変形例：
上記第１実施例では、プリンタＰＲＴにおいて、問い合わせ元の監視装置ＡＧを特定するための識別情報として、ＩＰアドレスを使用しているが、識別情報は各監視装置ＡＧによって異なる任意の情報とすることができる。例えば、監視装置ＡＧの通信Ｉ／Ｆ部１９０毎に別個の値が設定されるＭＡＣアドレスを使用しても良いし、ＡｐｐｌｅＴａｌｋ（登録商標）のノードＩＤなどの識別子（ネットワーク識別子）を使用するものとしても良い。いずれの識別情報を用いる場合であっても、監視装置ＡＧからの問い合わせのボディあるいはヘッダに、使用する識別情報を含まれていれば良い。

・その他の変形例：
上記実施例では、被監視デバイスとしてプリンタＰＲＴが用いられているが、他の種類のデバイスを用いても良い。例えば、スキャナＳＣＮ、複合機ＭＦＤ、ファクシミリ、コピー機を、被監視デバイスとして用いても良い。あるいは、ルータ、スイッチを始めとするネットワーク中継装置を被監視デバイスとしても良い。

上記実施例において、ハードウエアによって実現されていた構成の一部をソフトウエアに置き換えても良く、逆にソフトウエアによって実現されていた構成の一部をハードウエアに置き換えても良い。

以上、実施例、変形例に基づき本発明について説明してきたが、上記した発明の実施の形態は、本発明の理解を容易にするためのものであり、本発明を限定するものではない。本発明は、その趣旨並びに特許請求の範囲を逸脱することなく、変更、改良され得ると共に、本発明にはその等価物が含まれる。

第１実施例におけるネットワークシステムの概略構成図。 第１実施例における監視装置およびプリンタの内部構成を示すブロック図。 収集情報ファイルの内容を概念的に示す説明図。 監視設定ファイルの内容を概念的に示す説明図。 エージェント管理テーブルの内容を概念的に示す説明図。 監視処理の処理ルーチンを示すフローチャート。 被監視処理の処理ルーチンを示すフローチャート。 監視装置からの問い合わせと問い合わせに対するプリンタの応答を概念的に示す第１の説明図。 監視装置からの問い合わせと問い合わせに対するプリンタの応答を概念的に示す第２の説明図。 第２実施例におけるネットワークシステムの概略構成図。 第２実施例における第１のプリンタと第２のプリンタの内部構成を示すブロック図。

符号の説明

１１０…ＣＰＵ
１２０…内部記憶装置
１３０…エージェントプログラム
１３２…問い合わせ部
１３４…応答受信部
１３６…収集情報送信部
１４０…収集情報ファイル
１５０…監視設定ファイル
１５０ａ…プリンタリスト
１５０ｂ…属性情報リスト
１６０…表示部
１７０…操作部
１８０…外部記憶装置
１９０…通信Ｉ／Ｆ部
２１０…通信制御部
２３０…ジョブ処理部
２４０…被監視処理部
２４２…受信部
２４４…判断部
２４６…応答部
２５０…エージェント管理テーブル
２６０…プリンタコントローラ
２６２…プリンタバッファ
２６４…ＭＩＢ格納部
２７０…プリンタエンジン
１０００、１０００ｂ…ネットワークシステム
１０００ｂ…ネットワークシステム
ＰＲＴ、ＰＲＴａ、ＰＲＴｂ…プリンタ
ＮＢ…ネットワークボード
ＡＧ…監視装置
ＣＬ…クライアント
ＳＶ…サーバ

Claims (11)

1. 繰り返し問い合わせを送信することによりデバイスを監視する第１および第２の監視装置と接続される被監視デバイスであって、
   前記第１の監視装置からの第１の問い合わせ、および、前記第２の監視装置からの第２の問い合わせを受信する受信部と、
   前記第１の問い合わせに応じて、前記被監視デバイスに関する属性情報を前記第１の監視装置に通知すると共に、最後の前記第１の問い合わせから所定時間が経過した後に、前記第２の問い合わせを受けた場合に、前記第２の問い合わせに応じて前記属性情報を前記第２の監視装置に通知し、最後の前記第１の問い合わせから所定時間が経過する前に、前記第２の問い合わせを受けた場合に、前記属性情報を前記第２の監視装置に通知しない応答部と、
   を備える、被監視デバイス。
2. 請求項１に記載の被監視デバイスにおいて、
   前記第１の監視装置は、所定の周期で、前記第１の問い合わせを繰り返し送信し、
   前記所定時間は、前記所定の周期より長い、被監視デバイス。
3. 請求項１または請求項２に記載の被監視デバイスにおいて、
   前記第１の監視装置は、前記被監視デバイスに対して先に問い合わせを行った監視装置であり、
   前記第２の監視装置は、前記被監視デバイスに対して後に問い合わせを行った監視装置である、被監視デバイス。
4. 請求項１ないし請求項３のいずれかに記載の被監視デバイスにおいて、
   前記応答部は、最後の前記第１の問い合わせから所定時間が経過する前に、前記第２の問い合わせを受けた場合に、前記第２の監視装置に対して前記属性情報を含まないパケットを送信する、被監視デバイス。
5. 繰り返し問い合わせを送信することによりデバイスを監視する複数の監視装置と接続される被監視デバイスであって、
   前記複数の監視装置の優先順位を記憶する記憶部と、
   前記複数の監視装置からの問い合わせを受信する受信部と、
   第１の問い合わせが受信された時より所定時間前から、前記第１の問い合わせが受信された時までの期間に、前記第１の問い合わせを行った監視装置より優先順位が高い他の監視装置からの第２の問い合わせが受信されたか否かを判断する判断部と、
   前記期間に前記第２の問い合わせが受信されていないと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記被監視デバイスに関する属性情報を通知し、前記期間に前記第２の問い合わせが受信されたと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記属性情報を通知しない応答部と、
   を備える、被監視デバイス。
6. 請求項５に記載の被監視デバイスにおいて、
   前記複数の監視装置は、所定の周期で、前記問い合わせを繰り返し送信し、
   前記所定時間は、前記所定の周期より長い、被監視デバイス。
7. 請求項５または請求項６に記載の被監視デバイスにおいて、
   前記複数の監視装置の優先順位は、各監視装置からの最初の問い合わせが受信された順番である、被監視デバイス。
8. 請求項５または請求項６に記載の被監視デバイスにおいて、
   前記複数の監視装置の優先順位は、ユーザにより前記記憶部に記憶される、被監視デバイス。
9. 請求項５ないし請求項８のいずれかに記載の被監視デバイスにおいて、
   前記応答部は、前記期間に前記第２の問い合わせが受信されたと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記属性情報を含まないパケットを送信する、被監視デバイス。
10. 繰り返し問い合わせを送信することによりデバイスを監視する第１および第２の監視装置と接続される被監視デバイスの制御方法であって、
    前記第１の監視装置からの第１の問い合わせ、および、前記第２の監視装置からの第２の問い合わせを受信し、
    前記第１の問い合わせに応じて、前記被監視デバイスに関する属性情報を前記第１の監視装置に通知し、
    最後の前記第１の問い合わせから所定時間が経過した後に、前記第２の問い合わせを受けた場合に、前記第２の問い合わせに応じて前記属性情報を前記第２の監視装置に通知し、
    最後の前記第１の問い合わせから所定時間が経過する前に、前記第２の問い合わせを受けた場合に、前記属性情報を前記第２の監視装置に通知しない、制御方法。
11. 繰り返し問い合わせを送信することによりデバイスを監視する複数の監視装置と接続される被監視デバイスの制御方法であって、
    前記複数の監視装置の優先順位を取得し、
    前記複数の監視装置からの問い合わせを受信し、
    第１の問い合わせが受信された時より所定時間前から、前記第１の問い合わせが受信された時までの期間に、前記第１の問い合わせを行った監視装置より優先順位が高い他の監視装置からの第２の問い合わせが受信されたか否かを判断し、
    前記期間に前記第２の問い合わせが受信されていないと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記被監視デバイスに関する属性情報を通知し、
    前記期間に前記第２の問い合わせが受信されたと判断された場合に、前記第１の問い合わせを行った監視装置に対して前記属性情報を通知しない、制御方法。

Images