(57)【要約】【課題】処理負荷の増大を回避する通信装置を提供する。【解決手段】外部装置の状態を表す状態情報を記憶するアライブ情報記憶部１５０と、Ｗｈｏ−Ｉｓを外部装置から受信する要求受信部１１１と、次のＷｈｏ−Ｉｓを受信するまでの経過時間が時間閾値より大きい場合に、外部装置および通信装置に割り当てられた判定情報に基づいて、各装置がＷｈｏ−Ｉｓを送信する送信順位を決定する決定部１４１と、自装置の送信順位が順位閾値より小さい場合に、所定期間ごとにＷｈｏ−Ｉｓをネットワークに送信するＷｈｏ−Ｉｓ送信部１３０と、Ｗｈｏ−Ｉｓに対する応答であるＩ−Ａｍを外部装置から受信する応答受信部１１２と、Ｉ−Ａｍを受信できない外部装置の状態情報を、異常が生じたことを表す状態情報に更新する更新部１２１と、を備えた。【選択図】        図２
2010161507.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して接続される外部装置の状態を監視する通信装置であって、
前記外部装置の状態を表す状態情報を記憶する記憶部と、
正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、
前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、
前記通信装置の前記送信順位と順位閾値とを比較し、前記送信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、
前記確認要求に対する応答を前記外部装置から受信する応答受信部と、
前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、
を備えることを特徴とする通信装置。
【請求項２】
前記判定情報は、前記外部装置および前記通信装置をそれぞれ識別する識別番号であり、
前記決定部は、前記経過時間が前記時間閾値より大きい場合に、前記識別番号が小さいほど小さい前記送信順位を決定し、
前記通信部は、前記通信装置の前記送信順位が３位である前記順位閾値より小さい場合に、前記確認要求を前記ネットワークに送信すること、
を特徴とする請求項１に記載の通信装置。
【請求項３】
前記判定情報は、前記外部装置および前記通信装置の種別を表す情報であって優先順位が定められた装置種別と、前記外部装置および前記通信装置をそれぞれ識別する識別番号と、であり、
前記決定部は、前記経過時間が前記時間閾値より大きい場合に、前記装置種別の前記優先順位が小さく、かつ、前記識別番号が小さいほど小さい前記送信順位を決定し、
前記通信部は、前記通信装置の前記送信順位が３位である前記順位閾値より小さい場合に、前記確認要求を前記ネットワークに送信すること、
を特徴とする請求項１に記載の通信装置。
【請求項４】
前記通信部は、前記経過時間が大きいほど大きい前記順位閾値を決定し、前記通信装置の前記送信順位が決定した前記順位閾値より小さい場合に、前記確認要求を前記ネットワークに送信すること、
を特徴とする請求項１に記載の通信装置。
【請求項５】
前記通信部は、Ｓ＋Ｗ×ｎ≧Ｔを満たす最小のｎ（ただし、Ｓは前記時間閾値、Ｗは予め定められた待機時間、ｎは０以上の整数、Ｔは前記経過時間を表す）を求め、ｎ＋３を前記順位閾値として決定し、前記通信装置の前記送信順位が決定した前記順位閾値より小さい場合に、前記確認要求を前記ネットワークに送信すること、
を特徴とする請求項４に記載の通信装置。
【請求項６】
前記決定部は、前記経過時間と、予め定められた基準閾値に前記通信装置に割り当てられた識別番号を加算した値である前記時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記判定情報に基づいて前記送信順位を決定すること、
を特徴とする請求項１に記載の通信装置。
【請求項７】
前記通信部は、前記期間ごとに前記確認要求を前記ネットワークに送信する要求送信処理を開始した後、前記要求受信部によって、前記通信装置より前記送信順位が小さい前記外部装置から前記確認要求が受信された場合に、前記要求送信処理を停止すること、
を特徴とする請求項１に記載の通信装置。
【請求項８】
前記外部装置の起動を開始していることを表す起動通知を前記外部装置から受信する通知受信部をさらに備え、
前記通信部は、前記要求送信処理を開始した後、前記通知受信部によって前記起動通知が受信された場合は、前記要求受信部によって前記通信装置より前記送信順位が小さい前記外部装置からｍ回（ｍは２以上の整数）の前記確認要求が受信された場合に、前記要求送信処理を停止すること、
を特徴とする請求項７に記載の通信装置。
【請求項９】
前記通信部は、さらに、前記要求受信部によって、前記通信装置より前記送信順位が大きい前記外部装置から前記確認要求が受信された場合に、前記期間ごとに前記確認要求を前記ネットワークに送信すること、
を特徴とする請求項１に記載の通信装置。
【請求項１０】
前記要求受信部が前記確認要求を受信したときに、前記通信部は前記確認要求に対する応答を前記ネットワークに送信すること、
を特徴とする請求項１に記載の通信装置。
【請求項１１】
ネットワークを介して接続される外部装置の状態を監視する通信装置で実行される通信方法であって、
前記通信装置は、前記外部装置の状態を表す状態情報を記憶する記憶部を備え、
要求受信部が、正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信ステップと、
決定部が、前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定ステップと、
通信部が、前記通信装置の前記送信順位と順位閾値とを比較し、前記送信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する送信ステップと、
応答受信部が、前記確認要求に対する応答を前記外部装置から受信する応答受信ステップと、
更新部が、前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新ステップと、
を備えることを特徴とする通信方法。
【請求項１２】
コンピュータを、
ネットワークを介して接続される外部装置の状態を表す状態情報を記憶する記憶部と、
正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、
前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、
前記通信装置の前記送信順位と順位閾値とを比較し、前記送信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する通信部と、
前記確認要求に対する応答を前記外部装置から受信する応答受信部と、
前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、
として機能させるための通信プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、ネットワークを介して接続された他のデバイス（外部装置）を監視する装置、方法およびプログラムに関する。
【背景技術】
【０００２】
近年、大型のビルには、空調や照明などの設備機器を、ネットワークを介して監視制御するためのビル監視制御システムが導入されている。多くのビル監視制御システムで使われている通信プロトコルとして、ＢＡＣｎｅｔプロトコルが存在する。ＢＡＣｎｅｔプロトコルを使った監視制御システムでは、監視サーバやローカルコントロールサーバ（ＬＣＳ）などのデバイスがＢＡＣｎｅｔプロトコルに基づいて通信することで監視制御を実現する。電気設備学会が発行した非特許文献１は、ＢＡＣｎｅｔプロトコルを使用するシステムにおけるデバイスの相互接続のための標準機能を提案している。各ベンダがこの標準機能を実装することで、複数のベンダのデバイスが混在する場合でも、監視制御システムは正常に動作することができる。
【０００３】
非特許文献１では、標準機能の１つとして、デバイスのアライブチェック機能が提案されている。アライブチェック機能とは、監視制御システムに接続されている他のデバイスが正常な状態か否かを把握するための機能である。各ベンダが非特許文献１に基づいてアライブチェック機能を実装することで、複数のベンダのデバイスが混在する環境でも、アライブチェックを正しく行うことができる。
【０００４】
非特許文献１で提案されているアライブチェック機能では、３つの機能が定義されている。１つ目の機能はＷｈｏ−Ｉｓ送信機能である。このＷｈｏ−Ｉｓ送信機能を備えるデバイスは、ＢＡＣｎｅｔプロトコルで定義されるＷｈｏ−Ｉｓメッセージ（以下、単にＷｈｏ−ｉｓという場合がある）を一定周期（非特許文献１による推奨周期は６０秒）でブロードキャストする。以下、Ｗｈｏ−Ｉｓ送信機能を実行するデバイスのことをＷｈｏ−Ｉｓ送信デバイスと呼ぶ。
【０００５】
２つ目の機能はＷｈｏ−Ｉｓ監視機能である。このＷｈｏ−Ｉｓ監視機能を備えるデバイスは、Ｗｈｏ−Ｉｓ送信デバイスがブロードキャストするＷｈｏ−Ｉｓを監視する。そして、一定時間（非特許文献１による推奨時間は９０秒）以上、Ｗｈｏ−Ｉｓが送信されていない場合には、Ｗｈｏ−Ｉｓ送信デバイスに代わり、Ｗｈｏ−Ｉｓ送信を開始する。以下、Ｗｈｏ−Ｉｓ監視機能を実行するデバイスのことをＷｈｏ−Ｉｓ監視デバイスと呼ぶ。
【０００６】
３つ目の機能はＩ−Ａｍ監視機能である。ＢＡＣｎｅｔプロトコルでは、Ｗｈｏ−Ｉｓを受信したデバイスは、応答としてＩ−Ａｍメッセージ（以下、単にＩ−Ａｍという場合がある）をブロードキャストする。このＩ−Ａｍ監視機能を備えるデバイスは、Ｗｈｏ−Ｉｓに対して各デバイスがブロードキャストするＩ−Ａｍを監視する。そして、一定時間（非特許文献１による推奨時間は１５０秒）以上、Ｉ−Ａｍを送信しないデバイスを異常であると判定する。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＩＥＩＥＪ−Ｇ−０００６：２００６  ＢＡＣｎｅｔシステム  インターオペラビリティガイドライン
【発明の概要】
【発明が解決しようとする課題】
【０００８】
各デバイスの処理負荷の増加や、ネットワーク帯域の圧迫を避けるためには、Ｗｈｏ−Ｉｓ送信デバイスは１台のみであることが望ましい。一方、Ｗｈｏ−Ｉｓ送信デバイスが異常終了した際にも、監視制御システムでアライブチェック機能が継続実行されるためには、Ｗｈｏ−Ｉｓ監視デバイスが複数存在することが望ましい。
【０００９】
しかしながら、非特許文献１で提案されている方法では、Ｗｈｏ−Ｉｓ送信デバイスが異常終了し、かつ、Ｗｈｏ−Ｉｓ監視デバイスが複数存在した場合に、いずれのＷｈｏ−Ｉｓ監視デバイスがＷｈｏ−Ｉｓ送信を代行実行すべきかを一意に定めることができなかった。したがって、前回のＷｈｏ−Ｉｓが送信されてから９０秒経過した時点で、複数のＷｈｏ−Ｉｓ監視デバイスが一斉にＷｈｏ−Ｉｓをブロードキャストし、各デバイスの処理負荷の増大やネットワーク帯域の圧迫を引き起こすという問題があった。
【００１０】
本発明は、上記に鑑みてなされたものであって、他の装置を監視するためのメッセージを送信する装置に異常が発生した時に、当該メッセージの送信を代行する装置を適切に定めることにより、処理負荷の増大を回避することができる装置、方法およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１１】
上述した課題を解決し、目的を達成するために、本発明は、ネットワークを介して接続される外部装置の状態を監視する通信装置であって、前記外部装置の状態を表す状態情報を記憶する記憶部と、正常に動作していることを確認する確認要求を前記外部装置から受信する要求受信部と、前記確認要求を受信後、次の前記確認要求を受信するまでの経過時間と時間閾値とを比較し、前記経過時間が前記時間閾値より大きい場合に、前記外部装置および前記通信装置のそれぞれに割り当てられた判定情報に基づいて、前記外部装置および前記通信装置のそれぞれが前記確認要求を送信する送信順位を決定する決定部と、前記通信装置の前記送信順位と順位閾値とを比較し、前記送信装置の前記送信順位が前記順位閾値より小さい場合に、予め定められた期間ごとに前記確認要求を前記ネットワークに送信する送信部と、前記確認要求に対する応答を前記外部装置から受信する応答受信部と、前記応答を受信できない前記外部装置の前記状態情報を、異常が生じたことを表す状態情報に更新する更新部と、を備えることを特徴とする。
【００１２】
また、本発明は、上記装置で実行することができる方法およびプログラムである。
【発明の効果】
【００１３】
本発明によれば、他の装置を監視するためのメッセージを送信する装置に異常が発生した時に、当該メッセージの送信を代行する装置を適切に定めることにより、処理負荷の増大を回避することができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】第１の実施の形態にかかるビル監視制御システムの構成図である。
【図２】第１の実施の形態にかかる通信装置としてのデバイスのブロック図である。
【図３】従来手法にしたがって動作する各デバイスの動作を表す図である。
【図４】第１の実施の形態における起動開始処理の全体の流れを示すフローチャートである。
【図５】第１の実施の形態における監視処理の全体の流れを示すフローチャートである。
【図６】第１の実施の形態におけるデバイス群のアライブチェックの動作の具体例を示す図である。
【図７】第１の実施の形態で生じうる問題を説明するための図である。
【図８】第２の実施の形態にかかる通信装置としてのデバイスのブロック図である。
【図９】第２の実施の形態における監視処理の全体の流れを示すフローチャートである。
【図１０】第２の実施の形態におけるデバイス群のアライブチェックの動作の具体例を示す図である。
【図１１】第３の実施の形態にかかる通信装置としてのデバイスのブロック図である。
【図１２】第３の実施の形態における停止判定処理の全体の流れを示すフローチャートである。
【図１３】第１〜第３の実施の形態にかかる通信装置のハードウェア構成図である。
【発明を実施するための形態】
【００１５】
以下に添付図面を参照して、この発明にかかる装置、方法およびプログラムの最良な実施の形態を詳細に説明する。
【００１６】
（第１の実施の形態）
第１の実施の形態にかかる通信装置は、デバイス番号（またはデバイス番号とデバイス種別）からＷｈｏ−Ｉｓ送信順位を一意に決定し、決定したＷｈｏ−Ｉｓ送信順位からＷｈｏ−Ｉｓ送信を代替実行するかしないかを判断することにより、Ｗｈｏ−ＩｓとＩ−Ａｍのブロードキャストの多発を回避する。なお、Ｗｈｏ−Ｉｓ送信順位とは、Ｗｈｏ−Ｉｓ送信を実行する優先順位を意味している。
【００１７】
図１は、第１の実施の形態にかかるビル監視制御システムの構成図である。図１に示すように、ビル監視制御システムは、他のデバイス（外部装置）を監視するデバイス（通信装置）として、監視サーバ１、監視サーバ２、ＬＣＳ１１、および、ＬＣＳ１２を備えている。各デバイスは、相互に他のデバイスの状態を監視することができる。
【００１８】
第１の実施の形態にかかるビル監視制御システムでは、通信プロトコルとしてＢＡＣｎｅｔを使用する。監視サーバ１、監視サーバ２、ＬＣＳ１１、およびＬＣＳ１２は、ＢＡＣｎｅｔプロトコルにより通信する。ＢＡＣｎｅｔプロトコルにより通信するデバイスはそれぞれ固有のデバイス番号を持つ。本実施の形態では、監視サーバ１、監視サーバ２、ＬＣＳ１１、およびＬＣＳ１２のデバイス番号を、それぞれ１、２、１１、および１２とする。ネットワークとしては、イーサネット（登録商標）などが使用される。なお、適用可能なシステムおよび通信プロトコルは、それぞれビル監視制御システムおよびＢＡＣｎｅｔプロトコルに限られるものではない。また、ネットワークをイーサネット（登録商標）以外により構成してもよい。
【００１９】
図２は、図１の監視サーバ１、監視サーバ２、ＬＣＳ１１、および、ＬＣＳ１２それぞれに相当するデバイス１００の、アライブチェック機能にかかる機能構成を示すブロック図である。デバイス１００は、通信部１１０と、Ｉ−Ａｍ監視部１２０と、Ｗｈｏ−Ｉｓ送信部１３０と、Ｗｈｏ−Ｉｓ監視部１４０と、アライブ情報記憶部１５０とを備える。
【００２０】
アライブ情報記憶部１５０は、デバイス１００自身を含めたビル監視制御システムに参加している全デバイスのデバイス種別と、デバイス番号と、状態情報とを記憶する。デバイス種別とは、各デバイス（装置）の種別を表す情報（装置種別）であって、それぞれＷｈｏ−Ｉｓ送信の優先順位（デバイス種別の優先順位）が定められている。例えば、デバイス種別には、「監視サーバ」および「ＬＣＳ」が含まれ、「監視サーバ」に対して「ＬＣＳ」より大きい優先順位が定められる。デバイス種別や優先順位の決定方法はこれに限られるものではない。
【００２１】
デバイス番号とは、各デバイスを一意に識別する識別情報（識別番号）である。本実施の形態では、デバイス番号が小さいほどＷｈｏ−Ｉｓ送信順位（詳細は後述）が小さくなるように、各デバイスにデバイス番号を割り当てる。
【００２２】
状態情報とは、各デバイスの状態を表す情報である。例えば、デバイスが正常に動作しているか、デバイスに異常が生じているかを表す情報が、状態情報として記憶される。
【００２３】
なお、アライブ情報記憶部１５０は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
【００２４】
通信部１１０は、他のデバイスとの間で各種情報を送受信する。通信部１１０は、要求受信部１１１と、応答受信部１１２と、を備えている。要求受信部１１１は、正常に動作していることを確認するための確認要求であるＷｈｏ−Ｉｓを他のデバイスから受信する。応答受信部１１２は、Ｗｈｏ−Ｉｓに対する応答であるＩ−Ａｍを他のデバイスから受信する。
【００２５】
Ｉ−Ａｍ監視部１２０は、通信部１１０の応答受信部１１２が受信したＩ−Ａｍを監視する。Ｉ−Ａｍ監視部１２０は、監視結果に応じてアライブ情報記憶部１５０を更新する更新部１２１を備えている。例えば、更新部１２１は、Ｉ−Ａｍを受信したデバイスの状態情報を、正常に動作していることを表す状態情報に更新する。また、更新部１２１は、Ｉ−Ａｍを受信しなかったデバイスの状態情報を、異常が生じたことを表す状態情報に更新する。
【００２６】
また、Ｉ−Ａｍ監視部１２０は、通信部１１０の要求受信部１１１がＷｈｏ−Ｉｓを受信したときに、通信部１１０を介してＩ−Ａｍをブロードキャストする。
【００２７】
Ｗｈｏ−Ｉｓ監視部１４０は、通信部１１０が受信したＷｈｏ−Ｉｓを監視し、監視結果に応じてアライブ情報記憶部１５０を参照してＷｈｏ−Ｉｓ送信順位を計算する。Ｗｈｏ−Ｉｓ監視部１４０は、Ｗｈｏ−Ｉｓ送信順位を決定するための決定部１４１を備えている。具体的には、決定部１４１は、Ｗｈｏ−Ｉｓの受信間隔（Ｗｈｏ−Ｉｓを最後に受信してから次のＷｈｏ−Ｉｓを受信するまでの経過時間）が、所定の閾値（時間閾値）より大きい場合に、各デバイスに割り当てられた判定情報からＷｈｏ−Ｉｓ送信順位を決定する。判定情報とは、Ｗｈｏ−Ｉｓ送信順位を決定するために用いられる情報であり、本実施の形態では、デバイス番号およびデバイス種別を判定情報として用いる。決定部１４１によるＷｈｏ−Ｉｓ送信順位の決定方法の詳細は後述する。
【００２８】
Ｗｈｏ−Ｉｓ送信部１３０は、Ｗｈｏ−Ｉｓ送信順位が、Ｗｈｏ−Ｉｓ送信を代替実行するか否かを決定するための閾値（順位閾値）より小さいか否かを判断し、小さい場合に、通信部１１０を介して、一定周期でＷｈｏ−Ｉｓをブロードキャストする。
【００２９】
次に図３を用いて、従来手法の課題についてあらためて説明する。図３は、従来手法にしたがって動作する場合の監視サーバ１、監視サーバ２、ＬＣＳ１１、およびＬＣＳ１２の各デバイスの動作を表す図である。同図の横軸は時間の経過を表している。また、監視サーバ１がＷｈｏ−Ｉｓ送信機能を実行しており、その他のデバイスはＷｈｏ−Ｉｓ監視機能を実行しているものとする。また、全デバイスがＩ−Ａｍ監視機能を実行しているものとする。
【００３０】
時刻０の時点で、監視サーバ１がＷｈｏ−Ｉｓをブロードキャストし、それに対して他のデバイスがＩ−Ａｍを返す。これにより、全デバイスは、他の全デバイスが正常であると判断し、アライブ情報記憶部１５０の状態情報を更新する。次に、監視サーバ１が異常終了したとする。この場合、時刻９０の時点で、Ｗｈｏ−Ｉｓ監視機能を実行している監視サーバ２、ＬＣＳ１１、およびＬＣＳ１２は、Ｗｈｏ−Ｉｓ送信が９０秒途絶えたと判断し、Ｗｈｏ−Ｉｓをそれぞれブロードキャストする。ブロードキャストされたＷｈｏ−Ｉｓそれぞれに対して、全デバイスがＩ−Ａｍをそれぞれ返信するため、デバイスの処理負荷の増加や、ネットワーク帯域の圧迫が発生する。
【００３１】
次に、このように構成された第１の実施の形態にかかるデバイス１００による起動開始処理について図４を用いて説明する。起動開始処理とは、各デバイス１００が起動したときの動作を表す処理である。図４は、第１の実施の形態における起動開始処理の全体の流れを示すフローチャートである。
【００３２】
ビル監視制御システムの全デバイス１００は、起動するとＩ−Ａｍ監視機能を実行する（ステップＳ３１）。これは、全てのデバイス１００が、他の全てのデバイスの状態を把握することを意味する。
【００３３】
次に、デバイス１００の決定部１４１が、自身のＷｈｏ−Ｉｓ送信順位を計算する（ステップＳ３２）。決定部１４１は、アライブ情報記憶部１５０のデバイス種別とデバイス番号とからＷｈｏ−Ｉｓ送信順位を一意に決定する。本実施の形態では、デバイス種別が「監視サーバ」であるデバイスのほうが、「ＬＣＳ」であるデバイスよりも上位とする。また、デバイス番号が小さいデバイスのほうが上位とする。
【００３４】
なお、デバイス番号のみで順位を決定してもよい。また、デバイス番号は、上記のように値が小さいほど優先順位が上位となるように割り当てる必要はない。例えば、一意に識別可能な任意のデバイス番号を割り当て、このデバイス番号と、Ｗｈｏ−Ｉｓ送信順位を決定するための優先順位（デバイス番号の優先順位）とを対応づけて管理するように構成してもよい。すなわち、決定部１４１が、このようにして割り当てられた優先順位等を判定情報としてＷｈｏ−Ｉｓ送信順位を決定するように構成してもよい。
【００３５】
他デバイスのデバイス種別やデバイス番号は、任意の方法で取得できる。例えば、設定ファイルとして各デバイスに他デバイスの情報を与えておく方法や、ＢＡＣｎｅｔプロトコルに基づく通信を利用して他デバイスの情報を収集する方法などが適用可能である。
【００３６】
図１のデバイス群におけるＷｈｏ−Ｉｓ送信順位は、上位から順に監視サーバ１、監視サーバ２、ＬＣＳ１１、およびＬＣＳ１２となる。したがって、図１のデバイス群が起動した場合、監視サーバ１がＷｈｏ−Ｉｓ送信を実行し、その他のデバイスはＷｈｏ−Ｉｓ監視を実行する。また、前述のとおり、全てのデバイスがＩ−Ａｍ監視を実行する。なお、Ｗｈｏ−Ｉｓ送信を実行するデバイスは、自身で発信したＷｈｏ−Ｉｓに対してＩ−Ａｍを送信する。
【００３７】
図４に戻り、決定部１４１は、決定した自身のＷｈｏ−Ｉｓ送信順位が１位であるか否かを判断し（ステップＳ３２）、１位の場合（ステップＳ３２：ＹＥＳ）、Ｗｈｏ−Ｉｓ送信機能の実行を開始する（ステップＳ３３）。順位が１位でなければ（ステップＳ３２：ＮＯ）、Ｗｈｏ−Ｉｓ監視を開始する（ステップＳ３４）。
【００３８】
次に、このように構成された第１の実施の形態にかかるデバイス１００による監視処理について図５を用いて説明する。監視処理とは、Ｗｈｏ−Ｉｓ監視デバイスとして機能するデバイス１００がＷｈｏ−Ｉｓを受信したときの動作を表す処理である。図５は、第１の実施の形態における監視処理の全体の流れを示すフローチャートである。
【００３９】
Ｗｈｏ−Ｉｓ監視デバイスの決定部１４１は、前回Ｗｈｏ−Ｉｓを受信した時刻からの経過時間が時間閾値（例えば９０秒）より大きいか否かを判断する（ステップＳ４１）。すなわち、前回Ｗｈｏ−Ｉｓを受信した時刻から９０秒経過しているかどうかを判定する。９０秒経過していなければ（ステップＳ４１：ＮＯ）、所定の待機時間（例えば５秒）待機した後（ステップＳ４２）、再び９０秒経過しているかを判定する。
【００４０】
９０秒経過していた場合（ステップＳ４１：ＹＥＳ）、Ｗｈｏ−Ｉｓ送信部１３０は、自身のＷｈｏ−Ｉｓ送信順位が、アライブ情報記憶部１５０に正常に動作していることを表す状態情報が記憶されているデバイスの中で１位か２位であるか否かを判定する（ステップＳ４３）。すなわち、Ｗｈｏ−Ｉｓ送信部１３０は、順位閾値を３（位）とし、自身のＷｈｏ−Ｉｓ送信順位が順位閾値（３位）より小さいか否かを判定する。
【００４１】
１位か２位であれば（ステップＳ４３：ＹＥＳ）、Ｗｈｏ−Ｉｓ監視部１４０はＷｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信部１３０がＷｈｏ−Ｉｓ送信を開始する（ステップＳ４４）。３位以下であれば（ステップＳ４３：ＮＯ）、Ｗｈｏ−Ｉｓ監視部１４０はＷｈｏ−Ｉｓ監視を継続する（ステップＳ４２）。
【００４２】
次に図６を用いて、第１の実施の形態におけるデバイス群のアライブチェックの動作の具体例を説明する。全てのデバイスが起動した場合、デバイス種別とデバイス番号とから、監視サーバ１がＷｈｏ−Ｉｓ送信を実行し、他デバイスはＷｈｏ−Ｉｓ監視を実行する。時刻０の時点でＷｈｏ−ＩｓとＩ−Ａｍを送受信することで、全デバイスは、他の全デバイスが正常に動作していると判断する。
【００４３】
その後、監視サーバ１が異常終了したとすると、時刻９０の時点で、他のデバイスはＷｈｏ−Ｉｓが途絶えてから９０秒が経過したと判断する。ここで、本実施の形態のデバイスは、自身のＷｈｏ−Ｉｓ送信順位を判断する。この時点では、全てのデバイスは監視サーバ１が正常に動作していると判断する。なぜなら、デバイスが異常であると判断するためには、Ｉ−Ａｍが途絶えてから一定期間（非特許文献での推奨時間は１５０秒）経過する必要があるためである。
【００４４】
したがって、時刻９０の時点では、自身のＷｈｏ−Ｉｓ送信順位を、正常であると判断しているデバイスの中で１位か２位であると判断するのは監視サーバ２のみである。このため、監視サーバ２は、Ｗｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信を開始する。ＬＣＳ１１とＬＣＳ１２はＷｈｏ−Ｉｓ監視を継続する。
【００４５】
また、第１の実施の形態にかかるＷｈｏ−Ｉｓ送信デバイスは、自身よりもＷｈｏ−Ｉｓ送信順位が上位のデバイスからＷｈｏ−Ｉｓを受信した場合、Ｗｈｏ−Ｉｓ送信を停止し、Ｗｈｏ−Ｉｓ監視を開始する。また、第１の実施の形態にかかるＷｈｏ−Ｉｓ監視デバイスは、自身よりも下位のデバイスからＷｈｏ−Ｉｓを受信した場合、Ｗｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信を実行する。これにより、デバイスが異常終了と再起動を繰り返した場合でも、Ｗｈｏ−Ｉｓ送信順位が上位であるデバイスがＷｈｏ−Ｉｓ送信を実行することができる。
【００４６】
このように、第１の実施の形態にかかるデバイス（通信装置）によれば、デバイス種別とデバイス番号とから一意に定まるＷｈｏ−Ｉｓ送信順位に基づいて、Ｗｈｏ−Ｉｓ送信を代替実行するか否かを判断することで、Ｗｈｏ−ＩｓとＩ−Ａｍのブロードキャストが多発することを避けることができる。なお、Ｗｈｏ−Ｉｓが途絶えたと判断する時間である９０秒は推奨値であり、必ずしも９０秒である必要はない。待機時間（５秒）等についても同様である。
【００４７】
（第２の実施の形態）
第２の実施の形態は、第１の実施の形態で生じうる問題を解決可能にする。すなわち、第１の実施の形態では、Ｗｈｏ−Ｉｓが送信されてから９０秒以内に、Ｗｈｏ−Ｉｓ送信順位が１位と２位のデバイスが共に異常終了した場合に、第１の実施の形態の方法によるＷｈｏ−Ｉｓ送信の代替実行が行われず、ブロードキャストが多発するという問題が生じうる。
【００４８】
まず、図７を用いて、第１の実施の形態で生じうる問題の具体例について説明する。時刻０の時点でＷｈｏ−ＩｓとＩ−Ａｍの送受信が行われ、全デバイスは、他の全デバイスが正常に動作していると判断する。その後、Ｗｈｏ−Ｉｓ送信順位の１位と２位である監視サーバ１と監視サーバ２とが共に異常終了したとする。この場合、時刻９０の時点では、ＬＣＳ１１とＬＣＳ１２とは、監視サーバ２がＷｈｏ−Ｉｓ送信を代替実行すると判断し、Ｗｈｏ−Ｉｓ監視を継続する。なぜなら、ＬＣＳ１１およびＬＣＳ１２は、自身のＷｈｏ−Ｉｓ送信順位がそれぞれ３位および４位であると判断するからである。この結果、いずれのデバイスもＷｈｏ−Ｉｓを送信せず、いずれのデバイスからもＩ−Ａｍが送信されない状況になる。そして、時刻１５０の時点で、ＬＣＳ１１とＬＣＳ１２は、他の全デバイスからＩ−Ａｍが１５０秒送信されていないと判断し、自身以外の全デバイスを異常であると判断する。そして、Ｗｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信を実行する。この結果、ブロードキャストが多発し、処理負荷の増加や、ネットワーク帯域の圧迫が生じる。
【００４９】
第２の実施の形態にかかる通信装置（デバイス）は、Ｗｈｏ−Ｉｓが途絶えてから９０秒経過した後は、一定時間が経過するたびに、Ｗｈｏ−Ｉｓ送信を代替実行する権利を、Ｗｈｏ−Ｉｓ送信順位が下位のデバイスに段階的に与えていくことで、前述の第１の実施の形態で生じうる問題を解決する。
【００５０】
図８は、第２の実施の形態にかかる通信装置であるデバイス２００の構成を示すブロック図である。図８に示すように、デバイス２００は、通信部１１０と、Ｉ−Ａｍ監視部１２０と、Ｗｈｏ−Ｉｓ送信部２３０と、Ｗｈｏ−Ｉｓ監視部１４０と、アライブ情報記憶部１５０とを備える。
【００５１】
第２の実施の形態では、Ｗｈｏ−Ｉｓ送信部２３０の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるデバイス１００の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【００５２】
第１の実施の形態のＷｈｏ−Ｉｓ送信部１３０は、順位閾値を固定（３位）とし、自身のＷｈｏ−Ｉｓ送信順位が順位閾値より小さい１位か２位である場合に、Ｗｈｏ−Ｉｓ送信機能を開始していた。これに対し、第２の実施の形態のＷｈｏ−Ｉｓ送信部２３０は、時間閾値（例えば９０秒）を超えてからの経過時間に応じて、順位閾値を段階的に変更する点が第１の実施の形態のＷｈｏ−Ｉｓ送信部１３０と異なっている。
【００５３】
次に、このように構成された第２の実施の形態にかかるデバイス２００による監視処理について図９を用いて説明する。図９は、第２の実施の形態における監視処理の全体の流れを示すフローチャートである。
【００５４】
ステップＳ７１からステップＳ７２までは、第１の実施の形態にかかるデバイス１００におけるステップＳ４１からステップＳ４２までと同様の処理なので、その説明を省略する。
【００５５】
Ｗｈｏ−Ｉｓ監視デバイスのＷｈｏ−Ｉｓ送信部２３０は、Ｗｈｏ−Ｉｓが途絶えてから９０秒以上経過した場合は（ステップＳ７１：ＹＥＳ）、Ｓ＋Ｗ×ｎ≧Ｔを満たす最小のｎを計算する（ステップＳ７３）。ここで、Ｓは時間閾値（例えば９０秒）、Ｗは予め定められた待機時間（例えば５秒）、ｎは０以上の整数、Ｔは、前回Ｗｈｏ−Ｉｓを受信してから経過した時間（経過時間）を表す。時間閾値を９０秒とし、待機時間を５秒とする場合は、同図に示すようにＷｈｏ−Ｉｓ送信部２３０は、９０＋５ｎ≧Ｔを満たす最小のｎを計算する。
【００５６】
そして、Ｗｈｏ−Ｉｓ送信部２３０は、自身のＷｈｏ−Ｉｓ送信順位が、正常に動作していると判断しているデバイスの中で（ｎ＋３）位よりも上位であるか否かを判定する（ステップＳ７４）。すなわち、Ｗｈｏ−Ｉｓ送信部２３０は、順位閾値を（ｎ＋３）位とし、自身のＷｈｏ−Ｉｓ送信順位が順位閾値（ｎ＋３）位より小さいか否かを判定する。
【００５７】
（ｎ＋３）位よりも上位であれば（ステップＳ７４：ＹＥＳ）、Ｗｈｏ−Ｉｓ監視部１４０はＷｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信部２３０がＷｈｏ−Ｉｓ送信を実行する（ステップＳ７５）。（ｎ＋３）位よりも上位でなければ（ステップＳ７４：ＮＯ）、Ｗｈｏ−Ｉｓ監視部１４０はＷｈｏ−Ｉｓ監視を継続し、５秒後に再び判定する（ステップＳ７２）。
【００５８】
なお、例えば９０秒以上経過した場合は、デバイス番号に等しい秒数だけ待機して、その間にＷｈｏ−Ｉｓを受信しなければＷｈｏ−Ｉｓ送信を開始するということもできる。すなわち、例えば９０秒に固定した時間閾値を用いる代わりに、固定の閾値（例えば９０秒）を基準閾値とし、基準閾値にデバイス番号を加算した値を時間閾値として用いるように構成してもよい。
【００５９】
次に図１０を用いて、第２の実施の形態におけるデバイス群のアライブチェックの動作の具体例を説明する。時刻０の時点でＷｈｏ−ＩｓとＩ−Ａｍの送受信が行われ、全デバイスは、他の全デバイスが正常に動作していると判断する。その後、Ｗｈｏ−Ｉｓ送信順位の１位と２位である監視サーバ１と監視サーバ２とが共に異常終了したとする。時刻９０の時点で、ＬＣＳ１１およびＬＣＳ１２が、Ｗｈｏ−Ｉｓ代替実行の要否を判定する。この時点ではＴ＝９０であり、９０＋５ｎ≧Ｔを満たす最小のｎは０である。したがって、Ｗｈｏ−Ｉｓ送信順位が３位よりも上位であれば、Ｗｈｏ−Ｉｓ代替実行を実行する。ＬＣＳ１１は順位３位、ＬＣＳ１２は順位４位であるため、この時点では代替実行を実行しない。
【００６０】
５秒後、再びＬＣＳ１１およびＬＣＳ１２が、Ｗｈｏ−Ｉｓ代替実行の要否を判定する。この時点ではＴ＝９５であり、ｎは１となる。したがって、Ｗｈｏ−Ｉｓ送信順位が４位よりも上位であれば、Ｗｈｏ−Ｉｓ代替実行を実行する。ＬＣＳ１１は順位３位であるため、この時点でＷｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信の代替実行を開始する。仮にＬＣＳ１１も異常終了していた場合は、時刻１００の時点でＬＣＳ１２がＷｈｏ−Ｉｓ送信を代替実行する。
【００６１】
なお、第１の実施の形態と同様に、第２の実施の形態にかかるＷｈｏ−Ｉｓ送信デバイスは、自身よりもＷｈｏ−Ｉｓ送信順位が上位のデバイスからＷｈｏ−Ｉｓを受信した場合、Ｗｈｏ−Ｉｓ送信を停止し、Ｗｈｏ−Ｉｓ監視を開始する。また、第２の実施の形態にかかるＷｈｏ−Ｉｓ監視デバイスは、自身よりも下位のデバイスからＷｈｏ−Ｉｓを受信した場合、Ｗｈｏ−Ｉｓ監視を停止し、Ｗｈｏ−Ｉｓ送信を実行する。これにより、デバイスが異常終了と再起動を繰り返した場合でも、Ｗｈｏ−Ｉｓ送信順位が上位であるデバイスがＷｈｏ−Ｉｓ送信を実行することができる。
【００６２】
このように、第２の実施の形態にかかるデバイス（通信装置）によれば、Ｗｈｏ−Ｉｓが途絶えてから９０秒経過した後は、一定時間が経過するたびに、Ｗｈｏ−Ｉｓ代替実行の権利を、Ｗｈｏ−Ｉｓ送信順位が下位のデバイスに段階的に与えていくことで、Ｗｈｏ−ＩｓとＩ−Ａｍのブロードキャストが多発することを避けられる。なお、Ｗｈｏ−Ｉｓが途絶えたと判断する時間である９０秒や、Ｗｈｏ−Ｉｓ送信の代替実行を判定する周期である５秒は推奨値であり、必ずしもその値である必要はない。
【００６３】
（第３の実施の形態）
第１および第２の実施の形態のＷｈｏ−Ｉｓ送信デバイスは、自身よりもＷｈｏ−Ｉｓ送信順位が上位のデバイスからＷｈｏ−Ｉｓを受信した場合、Ｗｈｏ−Ｉｓ送信を停止し、Ｗｈｏ−Ｉｓ監視を開始する。これにより、Ｗｈｏ−Ｉｓ送信順位が上位のデバイスのみがＷｈｏ−Ｉｓ送信を実行することができ、ブロードキャストの多発を抑えることができる。例えば、図１における監視サーバ２がＷｈｏ−Ｉｓ送信を実行している最中に、監視サーバ１からＷｈｏ−Ｉｓを受信した場合、監視サーバ２はＷｈｏ−Ｉｓ送信を停止する。
【００６４】
監視サーバ２が、監視サーバ１からＷｈｏ−Ｉｓを受信する状況は２通り考えられる。１つ目の状況（状況１）は、ネットワークの障害により監視サーバ１がネットワークから切断され、監視サーバ２がＷｈｏ−Ｉｓ送信を代替実行し、その後、監視サーバ１がネットワークに接続された場合である。この場合、監視サーバ１自体には障害が発生していないため、監視サーバ１はその後も６０秒周期でＷｈｏ−Ｉｓをブロードキャストする。
【００６５】
２つ目の状況（状況２）は、監視サーバ１に異常が発生し、監視サーバ２がＷｈｏ−Ｉｓ送信を代替実行し、その後、監視サーバ１が再起動した場合である。非特許文献１にて提案されているデバイスの起動時の動作によれば、デバイスは起動直後にＢＡＣｎｅｔのＣＯＶＮｏｔｉｆｉｃａｔｉｏｎメッセージ（以下、単にＣＯＶＮｏｔｉｆｉｃａｔｉｏｎという場合がある）をブロードキャストすることで、自身の状態を他デバイスに通知する。その後、デバイスはＷｈｏ−Ｉｓをブロードキャストし、さらに監視制御に必要な情報を他デバイスから取得する初期化フェーズに移る。この場合、監視サーバ１はＷｈｏ−Ｉｓを１回送信した後、初期化フェーズに入るため、初期化にかかる時間によっては、６０秒後にＷｈｏ−Ｉｓを送信できない可能性がある。
【００６６】
したがって、監視サーバ２は、状況１であれば、Ｗｈｏ−Ｉｓ送信を停止してよい。しかし、状況２であれば、監視サーバ１の初期化処理が６０秒以上かかる（Ｗｈｏ−Ｉｓが６０秒後に送られてこない）可能性を考慮し、監視サーバ２はＷｈｏ−Ｉｓ送信を停止すべきではない。
【００６７】
第３の実施の形態にかかる通信装置は、このような状況を考慮し、上位のデバイスが初期化処理を実行しているか否かによってＷｈｏ−Ｉｓ送信の代替実行を停止するか否かを判断する。
【００６８】
図１１は、第３の実施の形態にかかるデバイス３００の構成を示すブロック図である。図１１に示すように、デバイス３００は、通信部３１０と、Ｉ−Ａｍ監視部１２０と、Ｗｈｏ−Ｉｓ送信部３３０と、Ｗｈｏ−Ｉｓ監視部１４０と、アライブ情報記憶部１５０とを備える。
【００６９】
第３の実施の形態では、通信部３１０に通知受信部３１３を追加したこと、および、Ｗｈｏ−Ｉｓ送信部３３０の機能が第１の実施の形態と異なっている。その他の構成および機能は、第１の実施の形態にかかるデバイス１００の構成を表すブロック図である図２と同様であるので、同一符号を付し、ここでの説明は省略する。
【００７０】
通知受信部３１３は、起動した他のデバイスからＣＯＶＮｏｔｉｆｉｃａｔｉｏｎを受信する。
【００７１】
Ｗｈｏ−Ｉｓ送信部３３０は、Ｗｈｏ−Ｉｓ送信順位が上位である他のデバイスからＷｈｏ−Ｉｓを受信した場合に、当該他のデバイスからＣＯＶＮｏｔｉｆｉｃａｔｉｏｎを受信しているか否かによって、Ｗｈｏ−Ｉｓ送信を継続するか停止するかを判定する機能が追加された点が、第１の実施の形態のＷｈｏ−Ｉｓ送信部１３０と異なっている。
【００７２】
次に、このように構成された第３の実施の形態にかかるデバイス３００による停止判定処理について図１２を用いて説明する。停止判定処理とは、Ｗｈｏ−Ｉｓ送信デバイスとして機能するデバイス３００が、Ｗｈｏ−Ｉｓ送信順位が上位である他のデバイスからＷｈｏ−Ｉｓを受信したときにＷｈｏ−Ｉｓ送信機能を停止するかを判定する処理である。図１２は、第３の実施の形態における停止判定処理の全体の流れを示すフローチャートである。
【００７３】
以下では、Ｗｈｏ−Ｉｓ送信機能を代替実行しているデバイスである監視サーバ２が、Ｗｈｏ−Ｉｓ送信順位が上位である監視サーバ１からＷｈｏ−Ｉｓを受信した場合を例に説明する。
【００７４】
すなわち、監視サーバ２がＷｈｏ−Ｉｓ送信を実行している最中に、監視サーバ１からＷｈｏ−Ｉｓを受信したとする（ステップＳ９１）。非特許文献１にて提案されているデバイスの起動時の動作によれば、起動デバイス（監視サーバ１）はＷｈｏ−Ｉｓ送信前に、ＣＯＶＮｏｔｉｆｉｃａｔｉｏｎメッセージをブロードキャストする。したがって、監視サーバ２のＷｈｏ−Ｉｓ送信部３３０は、監視サーバ１からＷｈｏ−Ｉｓを受信する直前に、監視サーバ１からＣＯＶＮｏｔｉｆｉｃａｔｉｏｎを受信しているか否かを判定する（ステップＳ９２）。
【００７５】
ＣＯＶＮｏｔｉｆｉｃａｔｉｏｎを受信していた場合（ステップＳ９２：ＹＥＳ）、Ｗｈｏ−Ｉｓ送信部３３０は、Ｗｈｏ−Ｉｓ送信を停止せず、再度監視サーバ１からＷｈｏ−Ｉｓを受信するまでＷｈｏ−Ｉｓ送信を継続する（ステップＳ９３）。ＣＯＶＮｏｔｉｆｉｃａｔｉｏｎを受信していなければ（ステップＳ９２：ＮＯ）、Ｗｈｏ−Ｉｓ送信部３３０はＷｈｏ−Ｉｓ送信を停止し、Ｗｈｏ−Ｉｓ監視部１４０がＷｈｏ−Ｉｓ監視を実行する（ステップＳ９４）。
【００７６】
なお、上記説明では、上位のデバイスからＷｈｏ−Ｉｓを２回受信した場合にＷｈｏ−Ｉｓ送信を停止していたが、Ｗｈｏ−Ｉｓの受信回数は２回に限られるものではない。例えば、初期化に必要な時間に応じて定められたｍ回（ｍは２以上の整数）のＷｈｏ−Ｉｓを受信した場合にＷｈｏ−Ｉｓ送信を停止するように構成してもよい。
【００７７】
このように、第３の実施の形態にかかるデバイス（通信装置）によれば、自身よりもＷｈｏ−Ｉｓ送信順位が上位のデバイスからＷｈｏ−Ｉｓを受信した場合でも、上位デバイスが初期化処理に移る場合にはＷｈｏ−Ｉｓ送信を継続することができる。これにより、Ｗｈｏ−Ｉｓの送信周期を一定に保つことができる。
【００７８】
次に、第１〜第３の実施の形態にかかる通信装置のハードウェア構成について図１３を用いて説明する。図１３は、第１〜第３の実施の形態にかかる通信装置のハードウェア構成図である。
【００７９】
第１〜第３の実施の形態にかかる通信装置は、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、各部を接続するバス６１を備えている。
【００８０】
第１〜第３の実施の形態にかかる通信装置で実行される通信プログラムは、ＲＯＭ５２等に予め組み込まれて提供される。
【００８１】
第１〜第３の実施の形態にかかる通信装置で実行される通信プログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成してもよい。
【００８２】
さらに、第１〜第３の実施の形態にかかる通信装置で実行される通信プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、第１〜第３の実施の形態にかかる通信装置で実行される通信プログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
【００８３】
第１〜第３の実施の形態にかかる通信装置で実行される通信プログラムは、上述した各部（通信部、Ｉ−Ａｍ監視部、Ｗｈｏ−Ｉｓ送信部、Ｗｈｏ−Ｉｓ監視部）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１が上記ＲＯＭ５２から通信プログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、各部が主記憶装置上に生成されるようになっている。
【産業上の利用可能性】
【００８４】
以上のように、本発明にかかる装置、方法およびプログラムは、ネットワークを介して接続された他のデバイスを監視する装置、方法およびプログラムに適している。
【符号の説明】
【００８５】
５１  ＣＰＵ
５２  ＲＯＭ
５３  ＲＡＭ
５４  通信Ｉ／Ｆ
６１  バス
１、２  監視サーバ
１１、１２  ＬＣＳ
１００、２００、３００  デバイス
１１０、３１０  通信部
１１１  要求受信部
１１２  応答受信部
１２０  Ｉ−Ａｍ監視部
１２１  更新部
１３０、２３０、３３０  Ｗｈｏ−Ｉｓ送信部
１４０  Ｗｈｏ−Ｉｓ監視部
１４１  決定部
１５０  アライブ情報記憶部
３１３  通知受信部
【図１】
2010161507.tif 000003
【図２】
2010161507.tif 000004
【図３】
2010161507.tif 000005
【図４】
2010161507.tif 000006
【図５】
2010161507.tif 000007
【図６】
2010161507.tif 000008
【図７】
2010161507.tif 000009
【図８】
2010161507.tif 000010
【図９】
2010161507.tif 000011
【図１０】
2010161507.tif 000012
【図１１】
2010161507.tif 000013
【図１２】
2010161507.tif 000014
【図１３】
2010161507.tif 000015