JP4852226B2 - デバイス監視システム - Google Patents

Description

本発明は、ネットワーク上の複数のデバイスを少なくとも１台のデバイス管理サーバで管理するようにしたデバイス監視システム、監視プログラム及び監視方法並びにデバイスに関するものである。

一般に、ネットワーク上の複数のデバイスを一台もしくは数台のデバイス管理サーバで管理するようにした形態のネットワークシステムにあっては、デバイス管理サーバから定期的に、あるいは随時各デバイス毎に問い合わせを行い、それら各デバイス毎の応答の有無を確認することで各デバイスの稼働状態等のステータス状態の監視を行うようになっている。
特開２００１−６７３３４号公報 特開２００２−５７６８０号公報

しかしながら、このような問い合わせ・応答型の監視方式では以下に示すような問題点がある。
すなわち、問い合わせ・応答型の監視方式では、各デバイス毎に問い合わせと応答を繰り返し行っているため、ネットワークの規模が大きくなってデバイスの数が増大すると、その増加分に比例してデバイス管理サーバの負荷やネットワークトラフィックが増大することになる。この結果、ハイスペックなサーバや広帯域のバックボーンを用意しなければならず、そのためのコストが大幅に増大してしまうおそれがある。

また、デバイス管理サーバから問い合わせを行わない限り各デバイスの状態を知ることができないため、トラフィック削減等のために問い合わせ間隔を長くした場合にはその異常の検出に時間が掛かり、迅速な対応ができないといった不都合を招くことも考えられる。
そこで、本発明はこのような課題を有効に解決するために案出されたものであり、その主な目的は、デバイス管理サーバの負荷やネットワークトラフィックの増大を招くことなく、各デバイスの監視を確実に実施することができる新規なデバイス監視システム、監視プログラム及び監視方法並びにデバイスを提供するものである。

〔発明１〕前記課題を解決するために発明１のデバイス監視システムは、
複数のデバイスをネットワークで相互に接続したデバイス監視システムであって、前記複数のデバイスのうち各々のデバイスは、自己デバイスとは異なる他デバイスを監視して当該他デバイスの状態の変化を当該他デバイスとは異なるさらに他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。

これによって、各デバイスに対してネットワークを介した定期的な問い合わせを行わなくとも、その状態の変化が発生したときにそれを監視したデバイスが直ぐにその旨を他のデバイスに知らせることができるため、従来方式のように問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避することが可能となる。
また、全てのデバイスはいずれか１つあるいは２つ以上のデバイスで監視されるようになるため、その状態の変化が発生したときはその旨を確実に他のデバイスに通知することができる。尚、本発明でいう「他デバイス」とは、原則として「自己デバイス」の監視対象となるデバイスをいい、「他のデバイス」とは、その「他デバイス」の状態を通知する対象であるデバイスをいうものとする（以下、同じ）。

〔発明２〕発明２のデバイス監視システムは、
複数のデバイスをネットワークで相互に接続したデバイス監視システムであって、前記複数のデバイスのうち各々のデバイスは、自己デバイスとは異なる他デバイスを監視して当該他デバイスに異常が発生した際に前記異常の状態を当該他デバイスとは異なるさらに他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。

これによって、発明１と同様に定期的な問い合わせを行わなくとも、いずれかのデバイスに異常が発生したときにそれを監視したデバイスが直ぐにその旨を他のデバイスに知らせることができるため、従来方式のように問い合わせに要するデバイス管理サーバの負荷やネットワークトラフィックの増大を回避することができる。
しかも、本発明は監視対象となるデバイスに「異常」が発生したときにその旨を他のデバイスに知らせるようになっているため、前記発明１のようにデバイスの状態変化があってもそれが異常な状態でなければわざわざその旨が通知されなくなるため、発明１よりも通知の頻度が減って通知に要する負荷やネットワークトラフィックのさらなる低減を達成することが可能となる。

尚、本発明で規定する、「異常が発生した際」の「異常」の認識レベルとしては、特に限定するものではないが、一般的なデバイスであれば、ネットワークが確立されないといったネットワーク異常が代表的なものであり、また、デバイスとしてプリンタを利用した場合は、紙詰まり、トナー（インク）切れ等、デバイス本来の機能を発揮できず、緊急に補修・点検、補充等が必要な状態をいうものとする。

これに対し、前記発明１でいう「状態の変化」とは、このような「異常」な状態をも含む包括的な意味であり、後に詳細に例示するようにデバイスの消耗品の残量やデバイスの起動時間等、稼働時間の経過に伴って変化するあらゆる状態を含むものとする（以下、同じ）。
〔発明３〕発明３のデバイス監視システムは、
ネットワークに接続された複数のデバイスと、前記複数のデバイスを管理するデバイス管理サーバとを備えたデバイス監視システムであって、前記複数のデバイスのうち各々のデバイスは、自己デバイスとは異なる他デバイスを監視して当該他デバイスの状態の変化を前記デバイス管理サーバ又は当該他デバイスとは異なるさらに他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。

これによって、発明１と同様に問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避したり、その状態の変化が発生したときはその旨を確実に他のデバイスに通知することができる。
しかも、本発明は監視対象となるデバイスの他にデバイス管理サーバを備え、このデバイス管理サーバに対して監視対象となるデバイスの状態の変化を通知するようにすれば、その状態変化の通知や受信に要する各デバイスの負荷を低減することが可能となる。

〔発明４〕発明４のデバイス監視システムは、
ネットワークに接続された複数のデバイスと、前記複数のデバイスを管理するデバイス管理サーバとを備えたデバイス監視システムであって、前記複数のデバイスのうち各々のデバイスは、自己デバイスとは異なる他デバイスを監視して当該他デバイスに異常が発生した際に当該他デバイスの状態を前記デバイス管理サーバ又は当該他デバイスとは異なるさらに他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。

これによって、発明１と同様に問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避したり、監視対象のデバイスに異常が発生したときはその旨を確実に他のデバイスに通知することができる。
また、発明２と同様に、通知するのは監視対象となるデバイスに「異常」が発生したときにその旨を他のデバイスに知らせるようになっているため、通知の頻度が減って通知に要する負荷やネットワークトラフィックのさらなる低減を達成することが可能となる。

さらに発明３のように、デバイスの他にデバイス管理サーバを備え、このデバイス管理サーバに対して監視対象となるデバイスの異常の発生を通知するようにすれば、その通知や受信に要する各デバイスの負荷を低減することが可能となる。
〔発明５〕発明５のデバイス監視システムは、
発明１〜４のいずれかに記載のデバイス監視システムにおいて、前記他デバイス監視機能は、前記複数のデバイスのうち、一部のデバイスに備えられていることを特徴とするものである。

すなわち、前記他デバイス監視機能は前記発明１〜４のように全てのデバイスに備えても良いが、本発明はその一部のデバイス、例えばグループ化された複数のデバイスのうちその一部のデバイスに前記他デバイス監視機能を設けるようにしたものである。
この結果、そのデバイスが他の複数のデバイスを代表して監視し、異常が発生したときにその代表のデバイスが他のデバイスやデバイス管理サーバにその旨を通知するようにすれば、全てのデバイスに他デバイス監視機能を設けた場合に比較して個々のデバイスの製作コストを安価にすることが可能となる。

〔発明６〕発明６のデバイス監視システムは、
発明１〜５のいずれかに記載のデバイス監視システムにおいて、前記他デバイス監視機能は、ネットワークに接続された自己デバイスとは異なる他デバイスの存在を認識するデバイス検知手段と、前記認識した他デバイスの中から監視対象となるデバイスを特定するデバイス管理テーブルを作成するデバイス管理テーブル作成手段と、作成した前記デバイス管理テーブルを記憶するデバイス管理テーブル記憶手段と、自己デバイスのステータス情報を検知するステータス情報検知手段と、前記自己及び他デバイスのステータス情報を前記自己及び他デバイスとは異なる他のデバイス又は前記デバイス管理サーバへ通知するステータス情報通知手段と、自己デバイスを除く少なくともいずれかのデバイスからステータス情報を受信するステータス情報受信手段と、を備えたことを特徴とするものである。

このような構成を採用することにより、ネットワーク上の全てのデバイスを効率良く監視することが可能となり、また、各デバイスは取得・検知したステータス情報を確実に取得・通知することができる。
〔発明７〕発明７のデバイス監視システムは、
発明１〜６のいずれかに記載のデバイス監視システムにおいて、前記デバイスは、プリンタであることを特徴とするものである。

これによって、ネットワークで相互に接続されたプリンタが各々他のプリンタの状態変化や異常を相互に監視して通知し合うことができる。
〔発明８〕発明８のデバイス監視プログラムは、
発明１〜７のいずれかに記載のデバイス監視システムで用いられるデバイス監視プログラムであって、コンピュータに、前記請求項１〜６のいずれかに記載のデバイス監視システムの他デバイス監視機能を実現させることを特徴とするものである。

これによって、前記発明１〜６と同様な効果を得ることができると共に、汎用のコンピュータ、あるいは元来からデバイス自体に備えられたコンピュータの機能の一部をそのまま用いてソフトウェア上で他デバイス監視機能として実現させることが可能となるため、ハードウェアによって当該機能を実現する場合に比較して同じ機能を容易且つ経済的に実現することができる。

〔発明９〕発明９のデバイス監視プログラムは、
デバイス監視システムで用いられるデバイス監視プログラムであって、コンピュータに、複数のデバイスのうち各々のデバイスは、自己デバイスとは異なる他デバイスを監視して当該他デバイスに異常が発生した際に前記異常の状態を当該他デバイスとはさらに異なる他のデバイスに通知する他デバイス監視機能を実現させることを特徴とするものである。

これによって、前記発明８と同様な効果を得ることができると共に、汎用のコンピュータ、あるいは元来からデバイス自体に備えられたコンピュータの機能の一部をそのまま用いてソフトウェア上で他デバイス監視機能として実現させることが可能となるため、ハードウェアによって当該機能を実現する場合に比較して同じ機能を容易且つ経済的に実現することができる。

〔発明１０〕発明１０のデバイス監視プログラムは、
ネットワークに接続された複数のデバイスにそれぞれ備えられたコンピュータを、前記コンピュータが備えられた複数のデバイスのうち当該デバイスとは異なる他のデバイスの存在を認識するデバイス検知手段と、認識した他デバイスの中から監視対象となるデバイスを特定するデバイス管理テーブルを作成するデバイス管理テーブル作成手段と、作成した前記デバイス管理テーブルを記憶するデバイス管理テーブル記憶手段と、自己デバイスのステータス情報を検知するステータス情報検知手段と、自己及び他デバイスのステータス情報を前記自己及び他デバイスとは異なる他のデバイス又は前記デバイス管理サーバへ通知するステータス情報通知手段と、自己デバイスを除く少なくともいずれかのデバイスからステータス情報を受信するステータス情報受信手段と、して実行させることを特徴とするものである。

これにより、発明８と同様な効果が得られると共に、発明９と同様に汎用のコンピュータ、あるいは元来からデバイス自体に備えられたコンピュータの機能の一部をそのまま用いてソフトウェア上で他デバイス監視機能として実現させることが可能となり、ハードウェアによって当該機能を実現する場合に比較して同じ機能を容易且つ経済的に実現することができる。

〔発明１１〕発明１１のデバイス監視方法は、
ネットワークに複数のデバイスを備え、前記複数のデバイス同士で互いの状態を定期的にあるいは随時監視して監視対象のデバイスに状態の変化があったときに、当該状態の変化を発見したデバイスが他のデバイス又はデバイス管理サーバにそれを通知するようにしたことを特徴とするものである。

これによって、発明１と同様に問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避したり、その状態の変化が発生したときはその旨を確実に他のデバイスに通知することができる。
〔発明１２〕発明１２のデバイス監視方法は、
ネットワーク上に複数のデバイスを備え、前記複数のデバイス同士で互いの状態を定期的にあるいは随時監視して監視対象のデバイスに異常が発生したときに、当該異常を発見したデバイスが他のデバイス又はデバイス管理サーバにそれを通知するようにしたことを特徴とするものである。

これによって、発明１と同様に問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避したり、その状態の変化が発生したときはその旨を確実に他のデバイスに通知することができる。
しかも、発明２と同様に、通知するのは監視対象となるデバイスに「異常」が発生したときにその旨を他のデバイスに知らせるようになっているため、通知の頻度が減って通知に要する負荷やネットワークトラフィックのさらなる低減を達成することが可能となる。

〔発明１３〕発明１３のデバイス監視方法は、
発明１１又は１２に記載のデバイス監視方法において、前記通知には、その監視対象となるデバイスのログ情報が含まれていることを特徴とするものである。
これにより、異常等が発生したデバイスを特定できるだけでなく、その異常等が起こった時刻等の稼働履歴も同時に知ることができる。

〔発明１４〕発明１４のデバイス監視方法は、
発明１１〜１３のいずれかに記載のデバイス監視方法において、前記各デバイスの監視対象デバイスは、倫理的又は物理的近傍にあるデバイスを選択することを特徴とするものである。
すなわち、倫理的近傍にあるデバイスとは、機能的に同種のものであったり、カテゴリが同一のもの、例えばプリンタ同士又はプリンタとスキャナ等の関係をいい、物理的近傍にあるデバイスとは、文字通り設置されている距離が近いデバイス、例えば、同じ台所にある電子レンジと冷蔵庫等の関係をいう（以下、同じ）。

そして、このように監視対象デバイスを選定するに際して倫理的又は物理的近傍にあるデバイスを選択するようにすれば、両方とも電源が入っていて同時に稼働状態になっているケースが多いため、いずれかのデバイスに障害が発生した場合にはそれを直ちに認識することができる。
〔発明１５〕発明１５のデバイス監視方法は、
発明１１〜１４のいずれかに記載のデバイス監視方法において、前記各デバイスの監視対象デバイスは、機能的に同種のデバイスを選択することを特徴とするものである。

すなわち、倫理的又は物理的近傍にあるデバイスと同様に同種のデバイスは同時に稼働している場合が多いため、発明１２と同様に、いずれかのデバイスに障害が発生した場合にはそれを直ちに認識することができる。
〔発明１６〕発明１６のデバイス監視方法は、
発明１１〜１５のいずれかに記載のデバイス監視方法において、前記各デバイスの監視対象デバイスは、製造時期が互いにある一定期間以上離れているデバイスを選択することを特徴とするものである。

すなわち、製造時期が同じ時期のデバイス同士を監視対象として選定した場合、古い時期に製作されたデバイス同士が組み合わされてしまうと、最悪の場合、両方のデバイスに同時にダウンして、その障害の発生がデバイス管理サーバに全く通知されなくなることが考えられる。
そのため、本発明のように製造時期が互いにある一定期間以上離れているデバイス、すなわち、製造日が古いデバイスと新しいデバイスとを監視対象として組み合わせれば、両方のデバイスが同時にダウンしてしまう可能性が殆どなくなり、その障害の発生をデバイス管理サーバに確実に通知することができる。

〔発明１７〕発明１７のデバイス監視方法は、
発明１１〜１６のいずれかに記載のデバイス監視方法において、前記各デバイスの監視対象デバイスは、親デバイスが作成したデバイス管理テーブルに従って決定するようにしたことを特徴とするものである。
これにより、各デバイスの監視対象がスムーズに決定されると共に、監視対象漏れのデバイスが発生することがなくなるため、効率的で信頼性の高いデバイス監視システムを実現できる。

〔発明１８〕発明１８のデバイス監視方法は、
発明１７に記載のデバイス監視方法において、前記親デバイスが作成するデバイス管理テーブルは、前記デバイス管理サーバから取得するデバイス管理方法プロパティに従って作成することを特徴とするものである。
これにより、各デバイスは同一ネットワーク上にある他のデバイスの数や種類等をその都度把握しなくとも、容易にデバイス管理サーバを作成することができる。

〔発明１９〕発明１９のデバイス監視方法は、
発明１７又は１８に記載のデバイス監視方法において、前記親デバイスは、ネットワーク上の複数のデバイスのうち、最初に起動したデバイスがなることを特徴とするものである。
このように親デバイスを「最初に起動したデバイスがなる」というように固定的に決定するより、機動的に決定するようにすれば、親デバイスが直ぐに決定されるため、スムーズにシステム運用を実施することができる。

〔発明２０〕発明２０のデバイス監視方法は、
発明１７〜１９のいずれかに記載のデバイス監視方法において、前記親デバイスが稼働停止した際は、その稼働停止を発見したデバイスをこの親デバイスに代わって親デバイスとして機能させることを特徴とするものである。
これにより、親デバイスが稼働していなかったりダウンしてしまった場合でも直ぐに他のデバイスが親デバイスとして機能するため、前記発明１７と同様に、スムーズにシステム運用を続行することができる。

〔発明２１〕発明２１のデバイス監視方法は、
発明１７〜２０のいずれかに記載のデバイス監視方法において、前記親デバイスから稼働終了したときは、最初にその親デバイスから稼働終了通知を受けたデバイスをこの親デバイスに代わって親デバイスとして機能させることを特徴とするものである。
これにより、発明２０と同様に親デバイスが稼働しなくなっても直ぐに他のデバイスが親デバイスとして機能するため、スムーズにシステム運用を続行することができる。

〔発明２２〕発明２２のデバイス監視方法は、
発明１５〜１９のいずれかに記載のデバイス監視方法において、前記デバイス相互の通信手段及びデバイスとデバイス管理サーバとの通信手段に使用するデータ記述形式として、ＸＭＬプロトコルを用いることを特徴とするものである。
このようなインターネット等で用いられている標準的なプロトコルを用いれば、同種デバイス間は勿論、異種デバイス間や他社デバイス間でも容易且つ確実にデータ交換が可能となる。

〔発明２３〕発明２３のデバイス監視方法は、
発明１７〜２１のいずれかに記載のデバイス監視方法において、前記デバイスとしてプリンタを用いることを特徴とするものである。
これによって、発明７と同様にネットワークで相互に接続されたプリンタが各々他のプリンタの状態変化や異常を相互に監視して通知し合うことができる。

〔発明２４〕発明２４のデバイスは、
他デバイスを監視して当該デバイスの状態の変化を当該他デバイスとは異なる他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。
これによって、発明１と同様に問い合わせに要するデバイス管理サーバ等の負荷やネットワークトラフィックの増大を回避したり、その状態の変化が発生したときはその旨を確実に他のデバイスに通知することができる。

〔発明２５〕発明２５のデバイスは、
他デバイスを監視して当該デバイスに異常が発生した際に前記異常の状態を当該他デバイスとは異なる他のデバイスに通知する他デバイス監視機能を備えたことを特徴とするものである。
これによって、発明１と同様に定期的な問い合わせを行わなくとも、いずれかのデバイスに異常が発生したときにそれを監視したデバイスが直ぐにその旨を他のデバイスに知らせることができるため、従来方式のように問い合わせに要するデバイス管理サーバの負荷やネットワークトラフィックの増大を回避することができる。

〔発明２６〕発明２６のプリンタは、
発明２４又は２５に記載のデバイスであって、前記デバイスがプリンタであることを特徴とするものである。
これによって、発明７と同様にネットワークで相互に接続されたプリンタが各々他のプリンタの状態変化や異常を相互に監視して通知し合うことができる。

以下、本発明を実施するための最良の形態を添付図面を参照しながら詳述する。
図１は、本発明のデバイス監視システムに係るネットワークの最小構成を示したものであり、ネットワークＮ上に接続された少なくとも２つ以上のデバイス１０，１０…に対して少なくとも１つ以上のデバイス管理サーバ１２を備えたものである。
ここで、本発明を構成するデバイス１０としては、ネットワーク接続可能なものであってネットワークＮを介してデバイス管理サーバ１２によって通信可能なものであれば特に限定されるものではなく、例えば、プリンタやスキャナ、複写機、ファクシミリ、プロジェクタ、デジカメ、ＰＣ、オーディオ、テレビ、ビデオ、冷蔵庫、電子レンジ、加湿器、エアコン、洗濯機、扇風機等のデジタル家電及び携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ（Ｄａｔａ） Ａｓｓｉｓｔａｎｔｓ）、電子ペーパ等の携帯端末等、ネットワークカード、ゲートウェイ（ホームゲートウェイを含む）、ルータ、ブリッジ、ＨＵＢ等のネットワーク接続可能なデバイス全般が挙げられる。

ここで、「ネットワーク接続可能」なデバイスとは、具体的に、各デバイス１０，１０…が以下のようなネットワーク接続可能な通信インターフェースを備えていることをいう。
１０ＢＡＳＥ−２、１０ＢＡＳＥ−５、１０ＢＡＳＥ−１０等のＥｔｈｅｒｎｅｔ（登録商標）、１００ＢＡＳＥ−ＦＸ、１００ＢＡＳＥ−ＴＸ等のＦａｓｔ Ｅｔｈｅｒｎｅｔ（登録商標）、１０００ＢＡＳＥ−ＳＸ、１０００ＢＡＳＥ−ＬＸ等のＧｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）、１０Ｇｉｇａｂｉｔ Ｅｔｈｅｒｎｅｔ（登録商標）、ＦＤＤＩ（Ｆｉｂｅｒ−Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ）、ＴｏｋｅｎＲｉｎｇ、ＩＥＥＥ１３９４、ＩＥＥＥ８０２．１１ａ、ＩＥＥＥ８０２．１１ｂ等の無線ＬＡＮ、ＵＳＢ１．１、ＵＳＢ２．０（ＨＩ−ＳＰＥＥＤ ＵＳＢ）等のＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）、Ｂｌｕｅｔｏｏｔｈ、ＩｒＤＡ（Ｉｎｆｒａｒｅｄ Ｄａｔａ Ａｓｓｏｃｉａｔｉｏｎ）等の赤外線通信等。

そして、このデバイス１０には、それぞれのデバイス特有の機能に加え、図２に示すような構成をした他デバイス監視機能２０が備えられている。
この他デバイス監視機能２０は、自己以外のいずれかの他のデバイス１０を定期的にあるいは随時監視してそのステータス情報を取得すると共に、必要に応じてネットワークＮを介して前記デバイス管理サーバ１２に通知するものであり、図示するように、デバイス検知手段２１と、デバイス管理テーブル作成手段２２と、デバイス管理テーブル記憶手段２３と、ステータス情報検知手段２４と、ステータス情報通知手段２５と、ステータス情報受信手段２６と、ステータス情報記憶手段２７と、通信手段２８と、データベース２９とから主に構成されている。

このデバイス検知手段２１は、ネットワークＮ上に存在するデバイス同士がお互いの存在を認識し合うためのものであり、また、新規デバイスが追加された際もその存在を認識する機能を有している。
また、デバイス管理テーブル作成手段２２は、ネットワークＮ上に存在するデバイス１０，１０同士がお互いを監視する監視組み合わせを決定するテーブルを作成するためのものであり、作成されたデバイス管理テーブルはデバイス管理テーブル記憶手段２３によってデータベース２９に記憶されるようになっている。

例えば、図４に示すように、２つのデバイスＡ、Ｂを１つのデバイス管理サーバで管理するような最小構成をした形態のネットワークＮにあっては、図５（Ａ）に示すように、そのデバイス管理テーブル１００は、一方のデバイスＡが他方のデバイスＢを、また、他方のデバイスＢが一方のデバイスＡをそれぞれ管理（監視）することを規定しており、また、図５（Ｂ）に示すようにそのステータス情報は互いに通知して共有するようになっている。

ステータス情報検知手段２４は、自己のステータス情報、例えばデバイス各部に設けられたセンサー等から得られる、エラーや故障、アイドル状態等の情報を定期的に検知するようになっている。
また、ステータス情報通知手段２５は、ステータス情報検知手段２４で検知された自己のステータス情報を前記デバイス管理テーブルで定められた他のデバイスに通知すると共に、通知された他のデバイスのステータス情報及び自己のステータス情報をデバイス管理サーバ又は他のデバイスに通知するようになっている。

また、ステータス情報受信手段２６は、他のデバイスから送られてきたステータス情報を取得するものであり、ステータス情報検知手段２４で得られた自己のステータス情報と共にステータス情報記憶手段２７によってデータベース２９に記憶されるようになっている。
通信手段２８は、デバイス管理サーバ１２及び他のデバイスとの通信機能を提供するものであり、ネットワークＮとのインタフェースを構成すると共に、主にステータス情報の送受信を行っている。

一方、デバイス管理サーバ１２は、ネットワークＮを介して各デバイス１０，１０…を集中管理等する機能の他に、図３に示すような構成をしたステータス情報処理機能３０を有している。
図示するように、このステータス情報処理機能３０は、デバイス管理サーバ１２と一体的に設けられており、ステータス情報受信手段３１と、ステータス情報記憶手段３２と、ステータス情報解析手段３３と、ステータス利用手段３４と、通信手段３５と、データベース３６とから主に構成されている。

このステータス情報受信手段３１は、前記各デバイス１０、１０…から通知されるステータス情報を受信するものであり、図４の例でいえば、デバイスＡからステータス情報が通知される場合、そのステータス情報はデバイスＡのみでなく、デバイスＢのステータス情報も同時に受信されるようになっている。また、デバイスＢのステータス情報が通知される場合にもそのステータス情報はデバイスＢのみでなく、デバイスＡのステータス情報も同時に受信されるようになっている。

また、ステータス情報記憶手段３２は、そのステータス情報をデータベース３６に記憶し、ステータス情報解析手段３３はそのステータス情報を解析し、ステータス利用手段３４はそのステータス情報の解析結果を利用するようになっている。
通信手段３５は、各デバイス１０、１０…との通信機能を提供するものであり、ネットワークＮとのインタフェースを構成すると共に、各デバイス１０、１０…から送られるステータス情報の受信を行っている。

尚、このデバイス管理サーバ１２としては、ステータス管理サーバやＰＣ、ワークステーション等の他にＰＤＡ、携帯電話等のステータス情報受信可能機器であれば良く、特に限定されるものではなく、また、必ずしも全てのデバイスから独立している必要はなくいずれかのデバイスと共に又はデバイス内に一体的に組み込まれたような構成であっても良く、その構成は本実施の形態に限定されるものでない。

また、これらデバイス１０に備えられる他デバイス監視機能２０、及びデバイス管理サーバ１２に備えられるステータス情報処理機能３０等の各処理機能は、具体的には中央演算処理装置や主記憶装置等からなるハードウェアと、図８〜図１６等に示す各種専用のソフトウェア（処理プログラム）とからなるコンピュータシステムによって実現されるようになっている。

すなわち、これら各機能２０や３０等を実現するためのコンピュータシステムは、例えば、図６に示すように、各種制御や演算処理を担う中央演算処理装置であるＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）４０と、主記憶装置（Ｍａｉｎ Ｓｔｒａｇｅ）に用いられるＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）４１と、読み出し専用の記憶装置であるＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）４２と、ハードディスクドライブ装置（ＨＤＤ）や半導体メモリ等の補助記憶装置（Ｓｅｃｏｎｄａｒｙ Ｓｔｏｒａｇｅ）４３、及びモニタ（ＬＣＤ（液晶ディスプレイ）やＣＲＴ（陰極線管））等からなる出力装置４４及びキーボードやマウス等からなる入力装置４５と、ネットワークＮと、これらの入出力インターフェース（Ｉ／Ｆ）４６等との間を、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ）バスやＩＳＡ（Ｉｎｄｕｓｔｒｉａｌ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ；アイサ）バス等からなるプロセッサバス、メモリバス、システムバス、入出力バス等の各種内外バス４７によってバス接続したものである。

そして、例えば、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、フロッピー（登録商標）ディスク等の記憶媒体、あるいは前述した通信ネットワークＮを介して供給される各種専用の制御プログラムやデータ等を補助記憶装置４３等にインストールすると共にそのプログラムやデータを必要に応じて主記憶装置４１にロードし、その主記憶装置４１にロードされたプログラムに従ってＣＰＵ４０が各種リソースを駆使して所定の制御及び演算処理を行い、その処理結果（処理データ）をバス４７を介して出力装置４４に出力して表示すると共に、そのデータを必要に応じて補助記憶装置４３によって形成されるデータベースに適宜記憶、保存（更新）処理するようになっている。

また、各種制御プログラム用の記憶媒体としては、前記のようなＣＤ−ＲＯＭやＤＶＤ−ＲＯＭ、フレキシブルディスク等の他に、ＭＤ（Ｍｉｎｉ−Ｄｉｓｋ）等の磁気記憶型記憶媒体、ＬＤ（Ｌａｓｅｒ Ｄｉｓｃ）等の光学的読取方式記憶媒体、ＭＯ（Ｍａｇｎｅｔｏ−Ｏｐｔｉｃ）等の磁気・光学的記憶媒体等のコンピュータ読み取り可能な媒体等が適用可能となっている。

次に、このような構成をした本発明のデバイス監視システムの動作を説明する。
先ず、図８に示すようにネットワークＮ上のあるデバイスが起動されると、そのデバイスは同じネットワークＮ上の他のデバイスを検知しそのデバイスに対してデバイス管理方法を知っているかどうかを問い合わせる（ステップＳ１００）。
問い合わせの結果（ステップＳ１０２）、最新のデバイス管理方法を知らない場合（Ｎｏ）には、デバイス管理サーバから最新のデバイス管理方法プロパティを取得し（ステップＳ１０４）、自己が所持している場合（Ｙｅｓ）は処理を行わずにそのままそのデバイス管理方法プロパティをデバイス管理テーブルの作成に反映する（ステップＳ１０６）。

このデバイス管理方法プロパティとしては、例えば、図７に示すデバイス管理方法プロパティ１０２のように、自己が監視するデバイスの個数やデバイス監視間隔等が挙げられる。
次に、ネットワークＮ上のデバイスのうち、親デバイスとなるデバイスを決定し、この親デバイスが代表してデバイス管理方法プロパティを取得してデバイス管理テーブルを作成し、これらを他のデバイスに配布するようにすれば、デバイス毎にデバイス管理方法プロパティを取得したりデバイス管理テーブルを作成する必要がなくなり、ネットワークトラフィックを大幅に削減することが可能となる。

そして、この場合の親デバイスの決定方法としては、原則としてネットワークＮ上で最初に起動したデバイスを親デバイスとすることが最も効率的であるが、他のデバイスは定期的に親デバイスの存在を確認し、その存在が認められなかったり、親デバイスからの稼働終了の通知があった場合には、自己が代わって親デバイスに昇格することになる。
すなわち、各デバイスは自己が親デバイスでないときは定期的に及び稼働し始めたときは稼働した際に、図９に示すように親デバイスの存在を確認し（ステップＳ２００、Ｓ２０２）、親デバイスの存在が認められないとき（Ｎｏ）は、そのまま自己が親デバイスに昇格し（ステップＳ２０４）、親デバイスが存在すると認められたとき（ステップＳ２０４）は、そのまま通常のデバイスとして機能し、所定の時刻になったら再び親デバイスの存在を確認する処理を繰り返すことになる。

ここで、「最初に起動したデバイス」の判断方法としては、特に限定されるものではないが、例えば、以下に示すような方法が考えられる。
すなわち、先ず考えられる方法としては、あるデバイスがネットワーク上で起動した場合、ネットワーク上の他のデバイスに対して、ブロードキャストで「起動」した旨を伝える方法であり、次の方法としては、他のデバイスから既に起動している旨のＡＣＫ（ＡＣＫｎｏｗｌｅｄｇｅｍｅｎｔ）が返ってきた場合には、自己デバイスの起動時刻とＡＣＫ情報から他のデバイスの起動時刻を比較することで、どちらが最初に起動したかを判断する方法である。そして、自己デバイスと他デバイスの起動時刻が同時刻を指していた際には、例えば、ランダム関数ｒ（０〜１の値をランダムにとる）等を利用して、０≦ｒ＜０．５であれば、自己デバイスが先に起動したものとし、０．５≦ｒ＜１であれば、他デバイスが先に起動したものとする等の定義を行うことで、最初に起動したデバイスを決定する。また、別方法としては、同時刻を指していた際には、時刻を問い合わせたデバイスを最初に起動したデバイスとしても良い。尚、この時刻の同期方法としては、コンピュータ内部時計をネットワークを介して正しく調整するためのプロトコルであるＮＴＰ（Ｎｅｔｗｏｒｋ Ｔｉｍｅ Ｐｒｏｔｏｃｏｌ）を用い、デバイス管理サーバがＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）等を利用して正しい時刻を得た後、各デバイスがそのデバイス管理サーバに定期的に問い合わせることで全てのデバイスが同じ時刻に同期させることができる。

一方、親デバイスでない他のデバイス（以下、子デバイスという）は、図１０に示すように、親デバイスからの稼働終了通知を受け取ったか否かを常時監視し（ステップＳ２０６）、通知があったとき（Ｙｅｓ）は、さらにネットワークＮ上に親デバイスとなったデバイスが存在するか否かを確認し（ステップＳ２０８）、親デバイスが存在しないとき（Ｎｏ）は、そのまま親デバイスに昇格（ステップＳ２１０）し、存在するとき（Ｙｅｓ）及びステップＳ２０６において親デバイスからの稼働終了通知がなかったとき（Ｎｏ）は、それぞれその通知があるまでそのまま子デバイスとして機能することになる。

また、図１１に示すように、親デバイスは定期的にデバイス管理サーバへアクセスして最新のデバイス管理方法を問い合わせ（ステップＳ３００，Ｓ３０２）、取得した最新のデバイス管理方法プロパティをネットワークＮ上の全てのデバイスに通知することになる（ステップＳ３０４）。尚、デバイス管理サーバから定期的に親デバイスにデバイス管理方法を通知するようにしても良い。

ここで、親デバイスが停止してその機能を失う場合は、その停止前に子デバイスに「停止」する旨を通知し、その通知した子デバイスに新たに親デバイスになってもらうことになる。これに対し、親デバイスが終了処理をせずに突然停止した場合は、子デバイスはそのことを知らないことから、親デバイスは、稼働時には定期的に子デバイスに対し、「親デバイス通知」を行い、ネットワーク上で、唯一の親デバイスであることを示しておくことが望ましい。そして、子デバイスは、定期的に「親デバイス通知」を受け取り、ネットワーク上に「親デバイス」が存在することを確認し、ある一定期間「親デバイス通知」がこなくなった場合には、「親デバイス通知」を受け取らなかったと判断したデバイスが、親に昇格することを主張するための「親デバイス昇格通知」を発行し、ネットワーク上の他のデバイスに対し、新たな親デバイスになることを宣言する等の手法を取り入れておく必要がある。

次に、親デバイスは、このデバイス管理方法プロパティを用いてデバイス管理テーブルを作成する。
すなわち、親デバイスは、図１２に示すようにデバイス管理サーバから最新のデバイス管理方法プロパティを読み込み（ステップＳ４００）、この最新のデバイス管理方法プロパティ用いてネットワークＮに存在するデバイスを認識（ステップＳ４０２）した後、「デバイス管理テーブル」を作成する（ステップＳ４０４）。

次いで、親デバイスはその「デバイス管理テーブル」を自己のデバイス管理テーブル記憶手段２３に記憶（ステップＳ４０６）すると共に、その「デバイス管理テーブル」をネットワークＮ上の他の全てのデバイスに送付することになる（ステップＳ４０８）。
次に、図１３に示すように各デバイスはステータス情報検知手段２４を用いて定期的に自己のデバイスステータスを検査して（ステップＳ５００，Ｓ５０２）、そのデバイスステータス情報をステータス情報記憶手段２７により自己のデータベース２９へ記憶する（ステップＳ５０４）。

また、各デバイスは、この自己のデバイスステータス情報の記憶と共に図１４に示すように、定期的に自己のデバイスステータス情報を読み込み（ステップＳ５０６，Ｓ５０８）、これを先のデバイス管理テーブルに従い、ステータス情報通知手段２５を用いて他のデバイスに通知する（ステップＳ５１０，Ｓ５１２）。
一方、図１５に示すように各デバイスは監視対象となるデバイスから通知を監視し、定時になってもステータス情報が通知されない場合は（ステップＳ６００、Ｓ６０２）、デバイス管理テーブルに従い、監視対象となるデバイスにそのステータス情報を問い合わせる（ステップＳ６０４）。

問い合わせの結果、そのデバイスから応答がない場合にはそのデバイスに障害が発生したとみなし（ステップＳ６０６，Ｓ６０８）、そのデバイスの「稼働履歴」や「障害発生時間」を付加して（ステップＳ６１０）デバイス管理サーバへその旨を通知する（ステップＳ６１２）。
尚、定時になってもステータス情報が通知されない場合、その通知を受ける筈のデバイスが、そのデバイスにそのステータス情報を問い合わせることなく、そのままそのデバイスに障害が発生したとみなしてデバイス管理サーバへその旨を通知するケースもある。

そして、これら各デバイスのうちいずれかが正常に稼働停止する際は、図１６に示すように、そのデバイスがデバイス管理サーバに対して終了依頼（電源オフ依頼）をする（ステップＳ７００）と共に、自己のデバイス管理テーブルを読み込み（ステップＳ７０２）、監視対象同士となっている他のデバイスに対して稼働終了通知を行う（ステップＳ７０４）ことで稼働停止処理が終了することになる。

尚、この通知を受けた他のデバイスはその稼働停止したデバイスの監視を取り止めると共に、自己のデバイス管理テーブルに応じて、あるいはデバイス管理サーバから新たに取得したプロパティに基づいて作成された新規なデバイス管理テーブルに基づいて他のデバイスのステータス情報を監視することになる。
次に、本発明のデバイス監視方法の具体的な実施の形態を説明する。

図１７及び図１８は従来の典型的なデバイス監視方法、図１９及び図２０は本発明のデバイス監視方法を示したものである。
先ず、図１７に示すように、１つのネットワークＮには４つのデバイスＡ、Ｂ、Ｃ、Ｄが接続され、これらはデバイスＡ、Ｂ、Ｃ、Ｄは、１つのデバイス管理サーバで管理されているものとする。

このような形態のネットワークにあっては、デバイス管理サーバが各デバイスＡ、Ｂ、Ｃ、Ｄのステータス情報、例えば正常に稼働しているか否か認識するためには、各デバイスＡ、Ｂ、Ｃ、Ｄ毎にそれぞれ問い合わせを行い、各デバイスＡ、Ｂ、Ｃ、Ｄ毎に応答があったか否かを確認することで各デバイスＡ、Ｂ、Ｃ、Ｄが正常に稼働しているか否か認識している。そのため、このような管理方法では、デバイス管理サーバは少なくとも４回の問い合わせ（１．３．５．７）と４回の応答確認（２．４．６．８）を行わなければならず、合計８回の通信処理回数を要することになる。

そして、これら各問い合わせ及び応答に関してそれぞれ１ずつのパケットとサーバの通信処理が必要であるとすると、以下の表１に示すように少なくともそのパケット数及びサーバの通信処理回数はそれぞれ「８」回となる。

また、このような従来の典型的なデバイス監視方法において、いずれか１つのデバイス、例えばデバイスＢに障害が発生してシステムダウンした場合には、図１８に示すように、デバイス管理サーバは同じように全てのデバイスＡ、Ｂ、Ｃ、Ｄに対して問い合わせを行い、デバイスＢからのみ応答がないことがわかった時点でそのデバイスＢがシステムダウンしたことを認識することになる。

このため、以下の表２に示すように、いずれか１つのデバイスがシステムダウンした場合にはそのパケット数及びサーバの通信処理回数は１つ少ない、それぞれ「７」回となる。尚、デバイス管理サーバはデバイスＢからの応答がない場合に、デバイスＢに障害が発生したとして認識する。
このように従来の典型的なデバイス監視方法では、正常時は勿論、障害が発生してシステムダウンした場合でも多くのパケットがネットワーク上を流れるため、ネットワークトラフィック及びデバイス管理サーバの情報処理量が多くなるといった欠点がある。

これに対し、本発明のデバイス監視方法は、図１９に示すように各デバイスＡ、Ｂ、Ｃ、Ｄが互いに監視し合い、隣接するデバイスに対して自己のステータス情報を定期的に通知し、その通知が不可になった時点でそれを検知したデバイスがデバイス管理サーバに通知するようにしたものである。
例えば、図２０に示すように、４つのデバイスＡ、Ｂ、Ｃ、Ｄのうち、デバイスＢに障害が発生してそれがシステムダウンした場合は、デバイスＢに対して自己のステータス状態通知が届けられないデバイスＡがデバイス管理サーバに通知（５）、又は所定時間が経過してもデバイスＢからステータス情報が通知されないデバイスＤが状態確認（６）を行い、デバイスＢのシステムダウンを確認してからデバイス管理サーバに通知（７）することになる。

この結果、以下の表３に示すように、通常時におけるネットワークを流れるパケット数も「４」つと半減され、また、以下の表４及び表５に示すようにシステムダウン発生時でもデバイス管理サーバは１回の通信処理回数でそれを認識することが可能となる。
尚、通知を受けたデバイス管理サーバは確認のためにそのデバイスに対して確認の問い合わせを行う場合もあるが、この問い合わせの回数を含めてもその処理回数は従来のそれよりも大幅に減少することになる。

すなわち、１台のデバイス管理サーバに対してＮ台のデバイスを備えたネットワーク環境においてサーバ−デバイス間の問い合わせパケット、応答パケット数は、従来方式では、各デバイス毎に問い合わせと応答を行うことから、以下の表６に示すようにパケット数及びサーバの通信処理数は、デバイスの数Ｎ×２となり、Ｎが増えるに従ってそのパケット数及びサーバの通信処理数が飛躍的に増えることになる。

また、以下の表７に示すように、このうち１台のデバイス（デバイス２）が稼働不能状態となった場合は、そのデバイスからの応答がなくなることになるため、パケット数及びサーバの通信処理数は、２Ｎ−１となり、同様に多くのパケット及び通信処理が必要となる。

これに対し、本発明に係るデバイス監視方法にあっては、以下の表８に示すようにデバイスが正常稼働しているときは、ネットワークを流れるパケット量がデバイスの数Ｎだけであり、従来方式の半分で済むことになる。

また、以下の表９に示すように、そのデバイスのうち１つのデバイス（デバイスＫ）が稼働不能状態となってその手前のデバイス（Ｋ−１）がエラー通知を行う場合は、（デバイスＫ）の状態通知が減って、そのデバイス（Ｋ−１）の通知の数が増えた結果、そのパケット総数は変わることなく、Ｎであり、ネットワークトラフィック量は増えることがない。また、サーバの処理回数もデバイス（Ｋ−１）からのエラー通知に対する処理の１回であり、従来方式に比べて飛躍的に減少することができる。

また、このサーバに対するエラー通知を行うデバイスが稼働不能状態となったデバイス（Ｋ）から状態通知を受ける側のデバイス（Ｋ＋１）の場合は、以下の表１０に示すように、デバイス（Ｋ＋１）からの状態確認と、デバイス（Ｋ＋１）からサーバに対するエラー通知といった２つのパケットが増えるだけで、その総パケット数も僅かに１つ増えるだけ済む。また、サーバの処理回数もデバイス（Ｋ＋１）からのエラー通知に対する処理の１回であり、同じく従来方式に比べて飛躍的に減少することができる。

このように本発明によれば、デバイス管理サーバから各デバイスに対して定期的な問い合わせやそれに対するデバイスからの応答が不要となるため、ネットワークの規模が大きくなってデバイスの数が増大してもデバイス管理サーバの負荷やネットワークトラフィックが増大することがない。
このため、ハイスペックなサーバや広帯域のバックボーンを用意する必要がなくなり、既存のＰＣや通信インフラをそのまま利用することができ、優れた経済性を発揮することができる。

また、デバイス管理サーバから問い合わせを行わなくとも、異常が発生したときにそれを監視したデバイスが直ぐにその旨をデバイス管理サーバに知らせるようになっているため、デバイス管理サーバがデバイスの異常発生を直ぐに知ることができる。この結果、異常やシステムダウンを起こしているデバイスの修理や交換などの適当な対応を迅速に採ることが可能となり、システム全体の信頼性向上に大きく貢献することができる。

尚、本発明において、デバイス相互及びデバイスとデバイス管理サーバとの存在確認や状態確認などを行う際に用いられる通信プロトコルとしては特に限定されるものではないが、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）、ＦＴＰ（Ｆｉｌｅ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）をはじめとしたＴＣＰ／ＩＰ準拠の通信プロトコルを用いれば、後述する形態のようにインターネットを介したネットワークでもそのまま使用することができ、優れた汎用性を発揮することが可能であり、また、そのデータ形式としてＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）プロトコルを用いることにより、ネットワークＮ上のデバイス１０及びデバイス管理サーバ１２に搭載されたＯＳやアプリケーションに依存しないデータ交換が可能になる。

また、本実施の形態でいうデバイスの「ステータス情報」とは、デバイスの状態を示す情報であれば特に限定されるものではなく、例えば、電源のＯＮ／ＯＦＦ状態、デバイスを起動してからの時間、標準時間（ＧＭＴ（Ｇｒｅｅｎｗｉｃｈ Ｍｅａｎ Ｔｉｍｅ）、日本標準時等）、消費電力、製造年月日、製品シリアル番号、ネットワーク設定、ＩＰアドレス、サブネットマスク、デフォルトゲートウェイ、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）、ＷＩＮＳ（Ｗｉｎｄｏｗｓ(登録商標）Ｉｎｔｅｒｎｅｔ Ｎａｍｅ Ｓｅｒｖｉｃｅ）、ＮｅｔＢＩＯＳ（Ｎｅｔｗｏｒｋ ＢＩＯＳ）名等、ファームウェアのバージョン情報、メモリサイズ（使用メモリサイズ、空きメモリサイズ、ＨＤＤサイズ、使用ＨＤＤサイズ、空きＨＤＤサイズ）、不具合情報等であり、また、デバイスとしてプリンタを適用した場合は、プリンタ固有の状態を示す情報である、トナー消費量（％：ＣＭＹＫ）、トナー残量（％：ＣＭＹＫ）、起動してからの印刷枚数（Ａ４、Ａ３、Ｂ５等）、出荷されてからのトータル印刷枚数（Ａ４、Ａ３、Ｂ５等）、用紙トレイ、カバー状態（オープン／クローズ）、両面ユニット装着有無、製品シリアル番号、プリンタ内部温度、紙詰まり有無等、不具合情報、等である。

次に、図２１〜図３１は本発明の他の実施の形態を示したものである。
先ず、図２１及び図２２の実施の形態は、前記のように自己のステータス情報のみならず、各デバイスの履歴を示すログ情報も同時に通知し合うようにしたものであり、このような構成とすれば、システムダウンしたデバイスを瞬時に特定できるだけでなく、そのログ情報も取得して最適な対応を実施することが可能となる。

すなわち、図２１に示すように同一ネットワーク上に３つのデバイスＡ、Ｂ、Ｃがあったとすると、デバイスＡは、自己のログ情報を自己のステータス情報と共にデバイスＢに対して通知し、デバイスＢは自己のログ情報を自己のステータス情報と共にデバイスＣに対して通知し、デバイスＣは自己のログ情報を自己のステータス情報と共にデバイスＡに対して通知するようにすれば、図示するように、各デバイスＡ、Ｂ、Ｃは自己のログ情報に加えて他のデバイスのログ情報の２つの情報を有することになる。

このため、図２２に示すように、そのうちの１つのデバイスである、デバイスＢが稼働停止した場合には（１）、デバイスＢからデバイスＣへのステータス情報及びログの通知が停止する（２）ため、これを検知したデバイスＣがデバイスＢに対して「稼働問い合わせ」（３）を行い、デバイスＢから応答がなければ、デバイスＢのシステムがダウンしたものと判断し、デバイス管理サーバへデバイスＢが停止した時間及びデバイスＣが保持しているデバイスＢのログ情報を付加して、サーバに通知を行うことになる（４）。これにより、デバイス管理サーバはデバイスＢがシステムダウンしたとの情報を迅速に得られるだけでなく、デバイスＣから送られてきたデバイスＢのログ情報から有益な情報を収集（５）し、有効利用することが可能となる。

次に、図２３〜図２９は、本発明に適用可能なネットワークの様々な形態を示したものである。
先ず、本発明を適用可能なネットワークはＬＡＮ等の同一屋内等のネットワークに限られるものでなく、図２３に示すように、インターネットなどの広域ネットワークを通じてデバイス管理サーバと接続したり、図２４に示すようにデバイス及びデバイス管理サーバの全てがインターネットで接続されたものであっても良い。

また、図２５に示すように、デバイス、デバイス管理サーバがゲートウェイとインターネットを介して接続された形態、また、図２６に示すようにデバイス、デバイス管理サーバの接続が全てインターネットとゲートウェイを通して行われる形態、さらに、図２７に示すようにさらにデバイス管理サーバを複数台設置するような形態であっても良い。
さらに、図２８及び図２９に示すように、遠隔地にあるネットワーク１，２のデバイス同士が互いに監視し合うようにすれば、一方のネットワークがダウンした場合、一方のネットワークのデバイスが全てダウンした場合及びゲートウェイがダウンした場合などに他方のネットワークのデバイスがこれを検知し、デバイス管理サーバに通知を行うことも可能となる。

次に、図３２〜図３４は、デバイスの監視対象の選択方法の一例を示したものである。
すなわち、監視対象を選択する基準として、先ず考えられるのは、物理的に近接しているデバイス、例えば同じ部屋や家屋に設置されているデバイスや、論理的に近接してデバイス、例えばカテゴリの近いデバイス同士（プリンタとスキャナ、冷蔵庫と電子レンジ）を監視対象として選択すれば、お互いの関係が深い（連携して使用される）デバイス同士が監視関係を結ぶことで同一カテゴリのデバイスを連続して使用する環境を提供することができる。

この他に図３２〜図３４に示すように、デバイス相互の製造年月日を考慮し、製造年月日が一定期間以上離れているもの、つまり、製造年月日が新しいものと古いもの同士が監視し合うような組み合わせとすれば、両方のデバイスが同時にシステムダウンしてお互いにその状態がサーバに通知されないなどといった不都合を未然に回避することが可能となる。

例えば、図３２に示すように同一ネットワーク上に４つのデバイスＡ、Ｂ、Ｃ、Ｄがあり、それぞれのデバイスの製造年月日がデバイスＡからデバイスＤになるに従って新しくなるものとする。
このような場合に図３３のデバイス監視テーブルに示すように、最も製造年月日が古いデバイスＡが最も製造年月日が新しいデバイスＤを監視し、最も製造年月日が新しいデバイスＤが次に製造年月日が古いデバイスＢを監視する…等のようにすれば、古いものほど故障が発生しやすいとの一般的な前提に基づけば、故障の発生する可能性の合計がそれぞれの組み合わせで大きく差がつくことがなくなり、効果的なエラー通知を実施することが可能となる。

また、さらにこのように製造年月日が広範囲に渡るデバイスの組み合わせにあっては、図３４に示すように、製造年月日が古いデバイスに情報を通知する場合は、そのデバイスのみでなく、他のデバイスにも重複して通知するようにすれば、通知の信頼性も向上させることが可能となる。
その他の組み合わせとしては、例えば常時稼働を前提としたデバイスであれば、同種のデバイス同士又は異種のデバイス同士が監視関係を結ぶことで、エラーへの対処の信頼性を保つことができる。

また、一方で常時稼働しないデバイス同士が監視関係を結んでも十分な監視効果が発揮できないため、常時稼働デバイスと非常時稼働デバイスあるいは異なるデバイス同士が監視関係を持つように構成すれば、監視システムの信頼性がより向上する。
また、監視対象は全てのデバイスが１対１になっているものに限られず、図３０及び図３１に示すように、全てのデバイスが２つ以上のデバイスを監視するようすれば、ネットワークを流れるパケット数はやや増加するものの監視の信頼性は大幅に向上する。

尚、図３０の例は、３つのデバイスＡ、Ｂ、Ｃの全てが他のデバイスを監視するようにしたものであり、また、図３１の例は、Ｎ個のデバイス全てが２つのデバイスを監視するようにしたものである。
図３５〜図４１は、前記図３２〜図３４で示した、製造時期が相互に一定期間以上離れている場合の２つのデバイスが監視し合う組み合わせ方法のいくつかをより詳しく説明したものである。

先ず、図３５、図３６は、デバイス組み合わせの最初の例を示したものである。
図示するように、監視範囲となるネットワーク上には５つのデバイス１〜５があり、それぞれのデバイス１〜５について製造日が明らかとなって場合、それら各デバイス１〜５の新しさを示す指標である各稼働期間Ｘ１〜Ｘ５は、現在日（例えば２００３年１０月１日）からそれぞれの製造日を差し引くことで算出することができる。例えば、デバイス１は、製造日が２００３年３月１日であることから、デバイス１の稼働期間Ｘ１は７ヶ月、また、デバイス２は、製造日が２００２年７月１日であることから、デバイス１の稼働期間Ｘ２は１５ヶ月…、デバイス５は、製造日が２０００年１月１日であることから、デバイス５の稼働期間Ｘ５は４５ヶ月…ということになり、稼働期間Ｘ１〜Ｘ５はデバイス１から５にいくに従って長くなっている。

さらに、稼働時間Ｘ１を基準としてＸ１とＸ２との差をＹ１と、また、Ｘ１とＸ３との差をＹ２と、さらにＸ１とＸ４との差をＹ３、Ｘ１とＸ５との差をＹ４として、それぞれの差を算出すると、Ｙ１＝（１５−７）＝８ヶ月となり、また、同様にＹ２は２６ヶ月、Ｙ３は３２ヶ月、Ｙ４は３９ヶ月となる。
そして、このように算出されたＹ１〜Ｙ４のうち、値の大きいものを選択し、デバイス同士の監視の組み合わせを決定する。すなわち、図３５に示す例では、Ｙ４の値が最も大きいので、デバイス１とデバイス４が相互に監視の組み合わせ対象となる。

また、同様に、残りのデバイス２〜４についてもＹ'２＝Ｙ３−Ｙ２＝６、Ｙ'３＝Ｙ４−Ｙ２＝１３のように計算を行うと、Ｙ'２よりもＹ'３の値のほうが大きいことから、デバイス２とデバイス４が相互に監視の組み合わせ対象となる。
従って、図３５の例では、図３６に示すようにデバイス１とデバイス４とが、また、デバイス２とデバイス４とが相互に監視対象となる組み合わせとなり、また、残ったデバイス３に関しては、最も新しいデバイス１が監視することになる。

次の組み合わせ例としては、図３７、図３８に示すように各デバイス１〜５の製品寿命（Ｌ１〜Ｌ５）を考慮する方法である。
すなわち、本方法は、先ず各デバイス特有の製品寿命Ｌからそれぞれ現在までの稼働期間Ｘを引いた値Ｙを算出する。例えば、図３８に示すように、デバイス１の製品寿命は１２ヶ月であることから、デバイス１のＹ１は、「１２ヶ月」から「７ヶ月」を差し引いた「５ヶ月」ということになる。同様にデバイス２のＹ２は「９ヶ月」、デバイス３のＹ３は「−２０ヶ月」（このようにマイナスになることもある。）、デバイス４のＹ４は「−２ヶ月」、デバイス５のＹ５は「−３３ヶ月」ということになる。

次に、このようにして求めたＹ１〜Ｙ５からＹ１を基準としてＹ１とＹ２〜Ｙ５との差をそれぞれＺ１〜Ｚ４として算出する。図３８の例では、Ｚ１＝Ｙ２−Ｙ１であることから、Ｚ１は「９ヶ月」から「５ヶ月」を差し引いた「４ヶ月」ということになり、また、Ｚ２はＹ３からＹ１を差し引いた「−２５ヶ月」、Ｚ３は「−７ヶ月」、Ｚ４は「−３８ヶ月」ということになる。

そして、このようにして算出されたＺ１とＺ２〜Ｚ４とを比較し、最も小さい値を持つものを判定し、確率的に同時期に製品寿命を迎えない組み合わせを決定する。図３８の例では、Ｚ４が最も小さい値を持つことから、最初の決定されるデバイスの組み合わせは、図３９に示すようにデバイス１と５ということになる。
その後、このようにして組み合わせが決定したデバイス１と５を除く、残りのデバイス２〜３についてもさらに前記と同様にしてＺ'２及びＺ'３を算出し、全てのデバイスの監視組み合わせを決定し、余ったデバイスは製造日が最も新しいデバイスが監視することになる。図３８の例では、Ｚ'３よりもＺ'２のほうが値が小さいことから、図３９に示すように残りのデバイス２〜４のうち、デバイス２とデバイス３が相互に監視する組み合わせとなり、余ったデバイス４については、製造日が最も新しいデバイス１が監視することになる。

さらに、他の組み合わせ例としては、図４０及び図４１に示すように、各デバイス１〜５が製造日に従って相互に他のデバイスを監視対象とするようにした方法もある。
すなわち、図４０に示するように５つのデバイス１〜５があって、デバイス５からデバイス１にいくに従って新しくなっている場合では、図４１に示すように（１）製造日が最も新しいデバイス１は、製造日が最も古いデバイス５を監視し、（２）そのデバイス５は、製造日が２番目に新しいデバイス２を監視する。（３）また、そのデバイス２は、製造日が４番目に新しいデバイス４を監視し、（４）そのデバイス４は、製造日が３番目に新しいデバイス３を監視し、（５）そのデバイス３は製造日が最も新しいデバイス１を監視することになる。

このように各デバイスの製造時期に基づいて各デバイスの監視対象やその組み合わせを決定するようにすれば、監視側のデバイスと監視対象となるデバイスとがほぼ同時に寿命に達してその監視及び通知機能を喪失するような不都合を効果的に回避することができ、信頼性の高いシステムを構築することが可能となる。尚、このように相互に組み合わされる監視対象デバイスは、製造時期が互いにある一定期間以上離れていることが望ましくその具体的な期間は、各デバイスの寿命（耐用年数）やシステムの信頼度等に応じて適宜、設定されるものであって特に限定されるものでないが、例えば、プリンタ等のように、平均寿命が数年程度のデバイスであれば、互いの製造時期は、少なくとも数ヶ月以上離れていることが望ましい。

次に、図４２はデバイスの終了処理の一例を示したものであり、前記実施の形態で示したように稼働履歴等のログ情報を取得した場合にはその稼働履歴を他のデバイスに引き継ぐ場合のフローを示したものである。
すなわち、デバイスを終了するデバイスはデバイス終了依頼があるか否かを判断し（ステップＳ８００）、終了依頼があったとき（Ｙｅｓ）は、そのデバイス管理テーブルを読み込み（ステップＳ８０２）、そのデバイス管理テーブルに規定された監視対象の他のデバイスに対して自己デバイスと自己が取得した他のデバイスの稼働履歴を送付する（ステップＳ８０４）ことで有益な稼働履歴を失うことなく終了処理を行うことができる。

また、既存のネットワーク上に新規なデバイスが追加された場合は、図４３に示すように、親デバイスがその新規デバイスを検知し（ステップＳ９００）、デバイス管理テーブルを再度作成する（ステップＳ９０２）ことで、新規なデバイスに対して監視対象となるデバイスが直ちに選択されることになる。

デバイス監視システムに係るネットワーク構成を示す図である。 デバイスに備えられた他デバイス監視機能の構成を示す図である。 デバイス管理サーバのステータス情報処理機能の構成を示す図である。 デバイス監視システムの最小構成を示す図である。 デバイス監視テーブル及びステータス通知方向の一例を示す図である。 本発明システムを実現するためのハードウェア構成を示す構成図である。 デバイス管理プロパティの一例を示す図である。 デバイス管理方法の取得を示すフローチャート図である。 親デバイスの決定方法を示すフローチャート図である。 親デバイスの他の決定方法を示すフローチャート図である。 サーバからのデバイス管理方法の取得を示すフローチャート図である。 デバイス管理テーブルの作成方法を示すフローチャート図である。 ステータス情報検知、記憶方法の流れを示すフローチャート図である。 ステータス情報の通知方法の流れを示すフローチャート図である。 ステータス問い合わせ方法等の流れを示すフローチャート図である。 デバイス稼働終了通知方法の流れを示すフローチャート図である。 従来方式に係るサーバ−デバイス間における正常時のパケットの流れを示す図である。 従来方式に係るサーバ−デバイス間における異常時のパケットの流れを示す図である。 本発明に係るサーバ−デバイス間における正常時のパケットの流れを示す図である。 本発明に係るサーバ−デバイス間における異常時のパケットの流れを示す図である。 デバイス同士のログ情報の持ち合い例を示す図である。 一部のデバイスが稼働停止した際の情報の流れを示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 本発明が適用可能なネットワーク構成の他の例を示す図である。 デバイス監視テーブル及びステータス通知方向の一例を示す図である。 デバイス監視テーブル及びステータス通知方向の一例を示す図である。 デバイスの製造年月日の例を示す図である。 デバイス管理テーブルの一例を示す図である。 デバイス管理テーブルの一例を示す図である。 デバイスの製造日等に関する情報の一例を示す図である。 製造時期等に基づいたデバイスの監視組み合わせ例を示す図である。 デバイスの寿命等に関する情報の一例を示す図である。 デバイスの製造日等に関する情報の一例を示す図である。 製造時期等に基づいたデバイスの監視組み合わせ例を示す図である。 デバイスの製造日等に関する情報の一例を示す図である。 製造時期等に基づいたデバイスの監視組み合わせ例を示す図である。 稼働履歴を譲渡する場合の流れを示すフローチャート図である。 新規デバイス参加時の流れを示すフローチャート図である。

符号の説明

１０…デバイス、１２…デバイス管理サーバ、２０…他デバイス監視機能、２１…デバイス検知手段、２２…デバイス管理テーブル作成手段、２３…デバイス管理テーブル記憶手段、２４…ステータス情報検知手段、２５…ステータス情報通知手段、２６…ステータス情報受信手段、２７…ステータス情報記憶手段、２８…通信手段、３０…ステータス情報処理機能、３１…ステータス情報受信手段、３２…ステータス情報記憶手段、３３…ステータス情報解析手段、３４…ステータス利用手段、３５…通信手段、２９、３６…データベース、４０…ＣＰＵ、４１…ＲＡＭ、４２…ＲＯＭ、４３…補助記憶装置、４４…出力装置４４、４５…入力装置、４６…入出力インターフェース（Ｉ／Ｆ）、４７…バス、Ｎ…ネットワーク、１００…デバイス管理テーブル、１０２…デバイス管理方法プロパティ。

Claims (1)

1. ネットワークに接続された複数のデバイスと、前記複数のデバイスを管理するデバイス管理サーバとを備えたデバイス監視システムであって、
   前記複数のデバイスのうち各々のデバイスは、
   デバイス管理テーブルに基づいて自己デバイスとは異なる他デバイスを監視して当該他デバイスの状態の変化を前記デバイス管理サーバに通知する他デバイス監視機能を備え、
   前記他デバイス監視機能を備えたデバイスのうち、最初に起動したデバイスが、親デバイスとして前記デバイス管理テーブルを作成して当該デバイス管理テーブルを前記他デバイス監視機能を備えた他のデバイスに配布すると共に、他のデバイスに自デバイスが親デバイスであることを示す親デバイス通知を定期的に発行し、
   前記親デバイスが稼働停止したときは、前記親デバイス通知を一定期間受け取らなかったことにより、その稼働停止を最初に発見した前記他デバイス監視機能を備えた他のデバイスが、前記親デバイスに代わって新たな親デバイスとして機能することを特徴とするデバイス監視システム。

Images