特許 7082447 ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2022-05-31

(45)【発行日】2022-06-08

(54)【発明の名称】ネットワーク機器管理環境、ネットワーク機器管理装置子機及びネットワーク機器管理装置親機

(51)【国際特許分類】

   G06F 1/26 20060101AFI20220601BHJP

   H04L 13/00 20060101ALI20220601BHJP

   H04L 41/00 20220101ALI20220601BHJP

   H04L 67/00 20220101ALI20220601BHJP

【ＦＩ】

G06F1/26 306

H04L13/00

H04L41/00

H04L67/00

【請求項の数】 22

(21)【出願番号】P 2020094244

(22)【出願日】2020-05-29

(65)【公開番号】P2021189735

(43)【公開日】2021-12-13

【審査請求日】2021-06-29

(73)【特許権者】

【識別番号】515139008

【氏名又は名称】バリューソリューション株式会社

(74)【代理人】

【識別番号】100147050

【弁理士】

【氏名又は名称】中原 亨

(72)【発明者】

【氏名】日野利信

(72)【発明者】

【氏名】宇城久仁子

(72)【発明者】

【氏名】福井威徳

【審査官】佐賀野 秀一

(56)【参考文献】

【文献】特開２０１６－１１５２７３（ＪＰ，Ａ）

【文献】特開２００４－２２１８６７（ＪＰ，Ａ）

【文献】特開２０１５－１０６３９３（ＪＰ，Ａ）

【文献】特開２０１９－０８４７６８（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｆ １／２６－ １／３２９６

Ｈ０４Ｌ １３／００

Ｈ０４Ｌ ４１／００

Ｈ０４Ｌ ６７／００

(57)【特許請求の範囲】

【請求項1】

アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視し、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対して状態監視コマンドを送信することを特徴とするネットワーク機器管理装置親機。

【請求項2】

アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視し、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対して生存確認コマンドを送信することを特徴とするネットワーク機器管理装置親機。

【請求項3】

アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するネットワーク機器管理装置親機であって、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視し、
該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機に対してアウトレットＯｎ・Ｏｆｆ指示コマンドを送信することを特徴とするネットワーク機器管理装置親機。

【請求項4】

請求項１乃至３のいずれか１記載のネットワーク機器管理装置親機において、
管理用ＰＣからの要求を受けた該ネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機から収集したアウトレット情報を前記管理用ＰＣに送り返すことを特徴とするネットワーク機器管理装置親機。

【請求項5】

ネットワーク機器に電源を供給するネットワーク機器管理装置子機と、
ネットワークを介して前記ネットワーク機器管理装置子機と通信を行うネットワーク機器管理装置親機と、を含むネットワーク機器管理システムであって、
前記ネットワーク機器管理装置子機は前記ネットワーク機器への電源供給を行うかを決定するスイッチを含み、
前記ネットワーク機器管理装置親機は、前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視することを特徴とするネットワーク機器管理システム。

【請求項6】

請求項５記載のネットワーク機器管理システムにおいて、
前記ネットワーク機器管理装置親機がコマンドを発行することで前記ネットワーク機器管理装置子機を制御することを特徴とするネットワーク機器管理システム。

【請求項7】

請求項６記載のネットワーク機器管理システムにおいて、
前記コマンドが前記ネットワーク機器管理装置子機の生存を確認する生存確認コマンドであることを特徴とするネットワーク機器管理システム。

【請求項8】

請求項６記載のネットワーク機器管理システムにおいて、
前記コマンドが前記ネットワーク機器管理装置子機のアウトレットに関する情報を取得する状態監視コマンドであることを特徴とするネットワーク機器管理システム。

【請求項9】

請求項６記載のネットワーク機器管理システムにおいて、
前記コマンドが前記ネットワーク機器管理装置子機のアウトレットを制御するアウトレットＯｎ・Ｏｆｆ指示コマンドであることを特徴とするネットワーク機器管理システム。

【請求項10】

請求項７記載のネットワーク管理システムにおいて、
前記コマンドに対する前記ネットワーク機器管理装置子機からのレスポンスで前記ネットワーク機器管理装置親機に前記ネットワーク機器管理装置子機が正常動作をしていることを通知することを特徴とするネットワーク機器管理システム。

【請求項11】

請求項８記載のネットワーク管理システムにおいて、
前記コマンドに対する前記ネットワーク機器管理装置子機からのレスポンスで前記ネットワーク機器管理装置親機が前記ネットワーク機器管理装置子機のアウトレット情報を更新することを特徴とするネットワーク機器管理システム。

【請求項12】

請求項９記載のネットワーク機器管理システムにおいて、
前記コマンドで前記ネットワーク機器管理装置子機の特定のアウトレットの電源供給をＯｎにすることを特徴とするネットワーク機器管理システム。

【請求項13】

請求項９記載のネットワーク機器管理システムにおいて、
前記コマンドで前記ネットワーク機器管理装置子機の特定のアウトレットの電源供給をＯｆｆにすることを特徴とするネットワーク機器管理システム。

【請求項14】

請求項１１記載のネットワーク機器管理システムにおいて、
更に監視用ＰＣを含み、
前記監視用ＰＣからの求めに応じて前記ネットワーク機器管理装置親機が前記監視用ＰＣに前記ネットワーク機器管理装置子機のアウトレット情報を提供することを特徴とするネットワーク機器管理システム。

【請求項15】

請求項５乃至１４記載のネットワーク機器管理システムにおいて、
前記ネットワーク機器管理装置親機が前記ネットワーク機器を管理することを特徴とするネットワーク機器管理システム。

【請求項16】

第１のネットワーク機器に電源を供給する第１のネットワーク機器管理装置子機と、
第２のネットワーク機器に電源を供給する第２のネットワーク機器管理装置子機と、
インターネットを介して前記各ネットワーク機器管理装置子機と通信を行うネットワーク機器管理装置親機と、を含むネットワーク機器管理システムであって、
前記各ネットワーク機器管理装置子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、
前記ネットワーク機器管理装置親機が前記ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視することを特徴とするネットワーク機器管理システム。

【請求項17】

請求項１６記載のネットワーク機器管理システムにおいて、
前記第１のネットワーク機器管理装置子機からのレスポンス及び前記第２のネットワーク機器管理装置子機からのレスポンスで前記ネットワーク機器管理装置親機が前記各ネットワーク機器管理装置子機のアウトレット情報を更新することを特徴とするネットワーク機器管理システム。

【請求項18】

請求項１７記載のネットワーク機器管理システムにおいて、
前記ネットワーク機器管理装置親機は１のテーブルで前記第１のネットワーク機器管理装置子機及び前記第２のネットワーク機器管理装置子機のアウトレット情報を管理することを特徴とするネットワーク機器管理システム。

【請求項19】

請求項１６乃至１８記載のネットワーク機器管理システムにおいて、
前記ネットワーク機器管理装置親機が前記第１のネットワーク機器及び前記第２のネットワーク機器を管理することを特徴とするネットワーク機器管理システム。

【請求項20】

ネットワーク機器に電源を供給するネットワーク機器管理装置子機と、
インターネットを介して前記子機と通信を行う第１のネットワーク機器管理装置親機と、前記インターネットを介して前記子機と通信を行う第２のネットワーク機器管理装置親機と、を含むネットワーク機器管理システムであって、
前記ネットワーク機器管理装置子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、
前記第１のネットワーク機器管理装置親機及び前記第２のネットワーク機器管理装置親機が前記ネットワーク機器管理装置子機を制御することを特徴とするネットワーク機器管理システム。

【請求項21】

請求項２０記載のネットワーク機器管理システムにおいて、
前記第１のネットワーク機器管理装置親機の機能と、前記第２のネットワーク機器管理装置親機の機能が同じであることを特徴とするネットワーク機器管理システム。

【請求項22】

請求項２０記載のネットワーク機器管理システムにおいて、
前記第１のネットワーク機器管理装置親機の機能と、前記第２のネットワーク機器管理装置親機の機能が異なることを特徴とするネットワーク機器管理システム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、ネットワークに接続された機器の監視装置、特に自動電源再起動機能を保持するものに関する。

【背景技術】

【0002】

ネットワーク及びインターネットに接続されたネットワーク通信機器（以下ネットワーク機器）の数は日々増大する一方である。ネットワークに接続された機器にフレキシブルな接続性を提供するためのＤＨＣＰ、ネットワークに接続する不特定多数に情報の提供を行うためのＨＴＴＰ、ネットワーク機器の監視に用いるＳＮＭＰ、ＴＣＰに対してセキュリティを付加するＳＳＬなどサービスの提供に供されるアプリケーションは日々増えるばかりである。

【0003】

従来のネットワーク機器の監視方法に関する文献としては、特開２００４―２２１８６７公開公報（引用文献１）が挙げられる。この文献には、ネットワーク機器電源制御装置の電源部にネットワーク機器を接続し、ネットワーク機器監視装置の電源部をリブートすることでこの電源部に接続されたネットワーク機器のリブートを行う技術が記載されている。

【先行技術文献】

【特許文献】

【0004】

【文献】特開２００４―２２１８６７公開公報

【発明の概要】

【発明が解決しようとする課題】

【0005】

しかし、ネットワーク機器監視装置の電源部にネットワーク機器を接続する必要があることから、ネットワーク機器電源制御装置の電源部とネットワーク機器との間の距離は接続に用いる電源ケーブルの長さに拘束される。従って、ネットワーク機器が１階、ネットワーク機器電源制御装置が１０階と言ったように物理的に距離がある場合には特許文献１記載の発明の適用は不可能である。

【0006】

また、特許文献１記載の発明では、ネットワーク機器電源制御装置の電源部がもつコンセントの数によって、最大管理台数が規定される。これでは、製造ライン等複数台の機器の管理を行う際に、一元的な管理を行うことができなくなる。すなわち、複数台のネットワーク機器電源制御装置が必要になる。

【0007】

本発明の目的は、電源ケーブルの長さやコンセントの数に拘束されることなく複数のネットワーク機器を管理可能な手段を提供することにある。

【0008】

本発明のさらに他の目的および利点は、以下の説明から明らかになろう。

【課題を解決するための手段】

【0009】

本発明に係るネットワーク機器管理環境は、ネットワーク機器に電源を供給する子機と、インターネットを介して子機と通信を行う親機と、を含み、子機はネットワーク機器への電源供給を行うか決定するスイッチを含み、親機が子機を制御することを特徴とする。

【0010】

このネットワーク機器管理環境は、親機がコマンドを発行することで子機を制御することを特徴としても良い。

【0011】

このネットワーク機器管理環境は、コマンドが子機の生存を確認する生存確認コマンドであることを特徴としても良い。

【0012】

このネットワーク機器管理環境は、コマンドが子機のアウトレットに関する情報を取得する状態監視コマンドであることを特徴としても良い。

【0013】

このネットワーク機器管理環境は、コマンドが子機の任意のアウトレットを制御するアウトレットＯｎ・Ｏｆｆ指示コマンドであることを特徴としても良い。

【0014】

このネットワーク機器管理環境は、コマンドがＨＴＴＰ通信プロトコルで送受信されることを特徴としても良い。

【0015】

このネットワーク機器管理環境は、コマンドに対する子機からのレスポンスで親機に子機が正常動作をしていることを通知することを特徴としても良い。

【0016】

このネットワーク機器管理環境は、コマンドに対する子機からのレスポンスで親機が子機のアウトレット情報を更新することを特徴としても良い。

【0017】

このネットワーク機器管理環境は、コマンドで子機の特定のアウトレットの電源供給をＯｎにすることを特徴としても良い。また、このネットワーク機器管理環境は、コマンドで子機の特定のアウトレットの電源供給をＯｆｆにすることを特徴としても良い。

【0018】

このネットワーク機器管理環境は、更に監視用ＰＣを含み、監視用ＰＣからの求めに応じて親機が監視用ＰＣに子機のアウトレット情報を提供することを特徴としても良い。

【0019】

このネットワーク機器管理環境は、さらに親機がネットワーク機器を管理することを特徴としても良い。

【0020】

本発明に係る別のネットワーク機器管理環境は、第１のネットワーク機器に電源を供給する第１の子機と、第２のネットワーク機器に電源を供給する第２の子機と、インターネットを介して子機と通信を行う親機と、を含み、各子機は前記ネットワーク機器への電源供給を行うか決定するスイッチを含み、親機が各子機を制御することを特徴とする。

【0021】

このネットワーク機器管理環境は、コマンドに対する第１の子機からのレスポンス及び第２の子機からのレスポンスで親機が各子機のアウトレット情報を更新することを特徴としても良い。

【0022】

このネットワーク機器管理環境は、親機は１のテーブルで第１の子機及び第２の子機のアウトレット情報を管理することを特徴としても良い。

【0023】

これらのネットワーク機器管理環境は、親機が第１のネットワーク機器及び第２のネットワーク機器を管理することを特徴としても良い。

【0024】

本発明に係る別のネットワーク機器管理環境は、ネットワーク機器に電源を供給する子機と、インターネットを介して子機と通信を行う第１の親機と、インターネットを介して子機と通信を行う第２の親機と、を含み、子機はネットワーク機器への電源供給を行うか決定するスイッチを含み、第１の親機及び第２の親機が子機を制御することを特徴とする。

【0025】

このネットワーク機器管理環境は、第１の親機の機能と、第２の親機の機能が同じであることを特徴としても良い。

【0026】

このネットワーク機器管理環境は、第１の親機の機能と、第２の親機の機能が異なることを特徴としても良い。

【0027】

本発明に係るネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、情報監視コマンドを受信したこのネットワーク機器管理装置子機は自身の持つアウトレットすべてに関するアウトレット情報を状態監視コマンドの送信元に返信することを特徴とする。

【0028】

本発明に係る別のネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、生存確認コマンドを受信したこのネットワーク機器管理装置子機は自身の生存を生存確認コマンド送信元に通知することを特徴とする。

【0029】

本発明に係る別のネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、アウトレットＯｎ・Ｏｆｆ指示コマンドを受信したこのネットワーク機器管理装置子機はアウトレットＯｎ・Ｏｆｆ指示コマンドで指定された自身の持つアウトレットの電源供給を制御することを特徴とする。

【0030】

このネットワーク機器管理装置子機において、制御結果をアウトレットＯｎ・Ｏｆｆ指示コマンド送信元に送信することを特徴としても良い。

【0031】

本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対して状態監視コマンドを送信することを特徴とする。

【0032】

本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対して生存確認コマンドを送信することを特徴とする。

【0033】

本発明に係るネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と協働するものであって、このネットワーク機器管理装置親機はネットワーク機器管理装置子機に対してアウトレットＯｎ・Ｏｆｆ指示コマンドを送信することを特徴とする。

【0034】

これらのネットワーク機器管理装置親機は、ネットワーク機器管理装置子機に接続されたネットワーク機器の状態を監視することを特徴としても良い。

【0035】

管理用ＰＣからの要求を受けたこのネットワーク機器管理装置親機は前記ネットワーク機器管理装置子機から収集したアウトレット情報を前記管理用ＰＣに送り返すことを特徴としても良い。

【0036】

本発明に係るネットワーク機器管理装置子機は、アウトレットを介してネットワーク機器に電力を供給するものであって、第１のＬＡＮ ＩＦ及び第２のＬＡＮ ＩＦを含むことを特徴としても良い。

【0037】

このネットワーク機器管理装置子機は、第１のＬＡＮ ＩＦは有線ＬＡＮであることを特徴としても良い。またこのネットワーク機器管理装置子機は、第１のＬＡＮ ＩＦは無線ＬＡＮであることを特徴としても良い。

【0038】

本発明に係る別のネットワーク機器管理装置親機は、アウトレットを介してネットワーク機器に電力を供給するネットワーク機器管理装置子機と通信を行うものであって、第１のＬＡＮ ＩＦ及び第２のＬＡＮ ＩＦを含むことを特徴とする。

【0039】

このネットワーク機器管理装置親機は、第１のＬＡＮ ＩＦは有線ＬＡＮであることを特徴としても良い。また、このネットワーク機器管理装置親機は、第１のＬＡＮ ＩＦは無線ＬＡＮであることを特徴としても良い。

【発明の効果】

【0040】

本発明に関わるネットワーク機器監視手段によって、物理的に離れた距離に存在するネットワーク機器の電源再起動を伴う管理を行うことが可能になる。
また本発明に関わるネットワーク機器監視手段によって、電源管理を実施するネットワーク機器の管理対象数を劇的に増やすことが可能になる。

【図面の簡単な説明】

【0041】

【図1】先行出願にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。

【図2】本発明の第１の実施の形態にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。

【図3】子機の一例の外観図（正面図）である。

【図4】本発明の親機と子機との間の通信方式に関する概念図である。

【図5】図４に係るテキストデータが、ＨＴＴＰリクエストの何処に含まれるかを説明する概念図である。

【図6】図４に係るテキストデータが、ＨＴＴＰレスポンスの何処に含まれるかを説明する概念図である。

【図7】「生存確認」時の親機と子機との間の通信方式に関する概念図である。

【図8】「状態監視」時の親機と子機との間の通信方式に関する概念図である。

【図9】「アウトレットＯｎ・Ｏｆｆ指示」時の親機と子機との間の通信方式に関する概念図である。

【図10】子機の物理的電気的構成を表す概念図である。

【図11】本発明に係るソフトウェアモジュールの構成を表す図である。

【図12】子機の状態監視モジュールの受信処理に関するフローチャートである。

【図13】子機のアウトレットＯｎ・Ｏｆｆ指示モジュールの受信処理に関するフローチャートである。

【図14】親機に電源を投入した時の動作を表すフローチャートである。

【図15】本発明の第２の実施の形態に係るトポロジの図である。

【発明を実施するための形態】

【0042】

以下本発明の実施の形態を図に基いて説明する。
（基礎となる技術）
まず、出願人が出願した特願２０１６－０４０９３３（先行出願）に係る技術について説明する。
図１は、先行出願にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。

【0043】

この動作環境は、ＬＡＮ７を挟んで監視用ＰＣ１、ネットワーク機器監視装置２、監視対象Ａ３、監視対象Ｂ４が接続されて構成される。

【0044】

監視用ＰＣ１は、ネットワーク機器監視装置２の状況をモニタするためのＰＣである。このＰＣ上ではブラウザが動作可能であることを想定する。また、この監視用ＰＣ１で動作するブラウザで表示可能なデータをネットワーク機器監視装置２は生成し出力する。

【0045】

ネットワーク機器監視装置２は、自身が電源供給する監視対象Ａ３、監視対象Ｂ４のハードウェア及びソフトウェアモジュールの状態を監視する監視装置である。ネットワーク機器監視装置２は電源供給用のコンセントを監視対象の台数分持つ。これらのコンセントはネットワーク機器監視装置２内の図示しないリレーで制御され、内部的に電源をＯｎ／Ｏｆｆできるように構成される。

【0046】

監視対象Ａ３は、ネットワーク機器監視装置２が監視する対象（ネットワーク機器）である。監視対象Ａ３上はルータ機能をユーザ等に提供する。監視対象Ａ３の電源ケーブルはネットワーク機器監視装置２のコンセントに接続される。これにより、ネットワーク機器監視装置２の制御により、監視対象Ａ３の電源をＯｎ／Ｏｆｆが可能に構成されている。

【0047】

監視対象Ｂ４は、ネットワーク機器監視装置２が監視する対象である。監視対象Ｂ４上はＨＴＴＰサーバ機能及び決済サーバ機能をユーザ等に提供する。監視対象Ｂ４の電源ケーブルはネットワーク機器監視装置２のコンセントに接続される。これにより、ネットワーク機器監視装置２の制御により、監視対象Ｂ４への電源供給をＯｎ・Ｏｆｆすることができるよう構成されている。

【0048】

通常、ユーザは、監視対象Ａ３上のＨＴＴＰサーバ機能が提供するＨＴＭＬ形式で記載されたホームページのデータから誘導されて決済サーバ機能のサービスを提供される受けることになる。このため、ＨＴＴＰサーバ機能がダウンしているときには、ユーザは決済サーバ機能の利用ができないことがほとんどである。よって決済サーバ機能のみが稼働しており、他のルータ機能、ＨＴＴＰサーバ機能が非稼働な状態では決済サーバ機能の動作の意義は低下する。この場合監視対象Ｂ４を再起動する意味は大きい。

【0049】

一方、ＨＴＴＰサーバ機能が生きていれば各種情報を配信することが可能になる。この時決済サーバ機能がダウンしていたとしても、ＨＴＴＰサーバ機能を継続して動作させる必要はいささかも衰えることは無い。そのようなときに監視対象Ｂ４を再起動するのは問題が生じる。

【0050】

上記の様なＨＴＴＰサーバ機能がダウンしているときと決済サーバ機能がダウンしているときとで動作を変更する、と言うのが先行出願にかかわるネットワーク機器監視装置に関する発明である。

【0051】

（第1の実施の形態）
しかし、先行技術においては各監視対象の電源ケーブルをネットワーク機器監視装置２の図示しないコンセントに接続する必要がある。従って、ネットワーク機器監視装置２からあまり物理的な距離を離すことができないという欠点があった。これはビルの上層階と下層階を一元管理したいといった要求に応じることができないことを意味する。

【0052】

また監視対象３Ａが提供するルータを越えてネットワーク外部の端末に接続する場合、接続用プロトコルが一部制限されるなどの問題も考えられる。

【0053】

上記の問題を鑑み、本明細書に係る発明を考案した。以下その内容について説明する。

【0054】

（第１の実施の形態）
（トポロジの説明）
図２は、本発明の第１の実施の形態にかかわるネットワーク機器監視装置の動作環境の一例を表す接続図である。

【0055】

本発明の特徴としては、先行出願のネットワーク機器監視装置２を親機２ａと子機２ｂ、２ｃに二分したことにある。

【0056】

本発明のネットワークトポロジは、インターネット９を挟んで接続されたローカルネットワーク７、８を中心に構成される。そしてローカルネットワーク７には監視用ＰＣ１と親機２ａが接続されている。またローカルネットワーク８には子機２ｂ、２ｃと監視対象Ａ３、監視対象Ｂ４が接続されている。子機２ｂには監視対象Ａ３の電源ケーブルが、子機２ｃには監視対象Ｂ４の電源ケーブルがそれぞれ接続されている。

【0057】

このネットワークトポロジは、インターネット９を挟んだ２つのローカルネットワーク７、８を含んで構成される。そして親機２ａはローカルネットワーク７に、子機２ｂ、２ｃはローカルネットワーク８にそれぞれ存在する。

【0058】

ローカルネットワーク７には、監視用ＰＣ１と親機２ａが通信可能なように接続されている。またローカルネットワーク８には、監視対象Ａ３及び監視対象Ｂ４と、子機２ｂと子機２ｃが接続されている。また図示しないルータなどによってインターネット９に接続される。

【0059】

本明細書におけるインターネット９は、ローカルネットワーク７とローカルネットワーク８を接続するための抽象的なネットワークである。通常インターネットとは「インターネット・プロトコル・スイートを使用し、複数のコンピュータネットワークを相互接続した、グローバルなネットワーク（地球規模の情報通信網）のこと」と定義される（Ｗｉｋｉｐｅｄｉａ）。しかし本明細書におけるインターネット９は、所有権が明確な社内ネットワークなどを排除することは想定してないし、グローバルなことも求めない。複数のコンピュータネットワーク（本明細書ではローカルネットワーク７とローカルネットワーク８）が接続される中間経路程度に考えればよい。

【0060】

監視用ＰＣ１は、親機２ａに対して監視対象Ａ３及び監視対象Ｂ４の状況をユーザが確認するための監視用ＰＣである。
監視用ＰＣ１は直接これら監視対象に対しては問い合わせを行うことは無い。監視用ＰＣ１は親機２ａに対して、これらの監視対象の状況を問い合わせる。なお本図においては監視用ＰＣが１台用意されているが、監視用ＰＣ１が複数台存在しても構わない。

【0061】

親機２ａは、監視対象Ａ４及び監視対象Ｂ６を直接的に監視するためのネットワーク機器監視装置である。すなわち、先行出願におけるネットワークの監視動作（ポーリング等）は親機２ａが担当する。

【0062】

通常、親機２ａが、監視対象との間で通信を行うことでこれらの監視対象の状況を確認する。監視対象Ａ３及び監視対象Ｂ４が正常に動作していないと確認できた場合には、親機２ａが子機２ｂと子機２ｃに対して監視対象Ａ３及び監視対象Ｂ４の再起動処理を求める。
また親機２ａは子機２ｂ及び子機２ｃとの間で通信を行うことで、各子機が監視対象に提供する電源（＝アウトレット）の情報を収集する。

【0063】

なお、本図においては親機２ａが１台に対して子機が複数台存在する形式を取っているが、複数の親機が複数の子機を管理しても構わない。また複数の親機が１の子機を管理するような形式も本発明の射程に含まれる。

【0064】

子機２ｂ及び子機２ｃは、親機２ａからの求めに応じて１）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの状況を返送し、２）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの出力状態を変更し、３）監視対象Ａ３につながるアウトレット及び監視対象Ｂ４につながるアウトレットの再起動を行う、ことを特徴とするネットワーク機器監視装置である。すなわち、先行出願における電源のＯｎ・Ｏｆｆに関する動作及びそれに関連したアウトレットに関する情報の収集を各子機は実施する。

【0065】

各子機は親機が監視を行う監視対象に対して電力を供給する。本図においては、子機２ｂは監視対象Ａ３に対して電力を供給する。また、子機２ｃは監視対象Ｂ４に対して電力を供給する。但し各子機が監視対象であるネットワーク機器に対して直接情報の収集を行うことはない。

【0066】

図３は、子機２ｂの一例の外観図（正面図）である。なお、各構成要素の配置は本図に拘る必要が無いことは言うまでもない。

【0067】

この子機２ｂの外観は、アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６及びＬＡＮポート２ｂ－１１、電源ケーブル２ｂ－１２を含んで構成される。無論商品たる子機２ｂ１台に幾つアウトレットを備えるかは設計事項であり、必要に応じて増減させればよい。

【0068】

アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６は、監視対象に電源を供給するための電源供給端子及びその内部回路１セットを意味する。従って本図における子機２ｂは６つのアウトレットを有しており、最大６つのネットワーク機器を接続できるといえる。

【0069】

アウトレット２ｂ－０１、２ｂ－０２、２ｂ－０５は、ＡＣ１００Ｖの電源を供給できる。またアウトレット２ｂ－０３はＤＣ５Ｖを、アウトレット２ｂ－０４はＤＣ１２Ｖをそれぞれ監視対象に供給できる。アウトレット２ｂ－０６は、接点端子となる。これらはリレーやスイッチング素子（これらを総称してスイッチ）を内部に含んでおり、電源供給のＯｎ、Ｏｆｆを自由に行えるようになっている。

【0070】

本発明に係る子機２ｂは、これらのアウトレットの情報を親機２ａに対して提供できるようになっている。また親機２ａのコマンドによって、子機２ｂは各アウトレットのスイッチを操作できるようになっている。

【0071】

ＬＡＮポート２ｂ－１１は、図２のネットワーク８に接続するためのＬＡＮポートである。このＬＡＮポート２ｂ－１１を介して、子機２ｂは親機２ａと通信を行う。

【0072】

電源ケーブル２ｂ－１２は、子機２ｂに電源を供給するための電源コードである。

【0073】

なお親機２ａの外観も基本的には子機２ｂのそれと違いない。但し、親機２ａは自身が直接監視対象に電力を供給する必要が無いため、アウトレットが存在しなくても成立する点で子機とは異なる。

【0074】

本明細書において、親機２ａと子機２ｂ、子機２ｃの間は、ＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ：ハイパーテキスト・トランスファー・プロトコル）＋ＴＳＬ（Ｔｒａｎｓｐｏｒｔ Ｓｅｃｕｒｉｔｙ Ｌａｙｅｒ：トランスポート・レイヤー・セキュリティ）、すなわちＨＴＴＰＳ（Ｈｙｐｅｒｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｅ：ハイパーテキスト・トランスファー・プロトコル・セキュア）、を用いて通信することを想定している。よって通信ポート番号はウェルノウンポートとして初期値４４３が割り当てられる。従って本明細書において、親機２ａと子機２ｂ、子機２ｃはＨＴＴＰＳプロトコルを採用する為、下位の物理層、データリンク層、ネットワーク層、トランスポート層の各インターネットプロトコルをサポートすることはいうまでもない。

【0075】

ＨＴＴＰＳで通信する際には、セッション確立、ＴＬＳセッション開始後ＴＬＳネゴシエーションを行う。ＴＬＳネゴシエーションでは認証方式を交渉、決定し、その後認証、鍵交換を行い、共通鍵を決定する。以降この共通鍵を利用して暗号化し通信することになる。ただし共通鍵の取得プロセスは本発明には直接関係が無いのでこれ以降説明は省略する。

【0076】

監視対象Ａ３及び監視対象Ｂ４は、親機２ａが監視を行う監視対象たるネットワーク機器である。
監視対象Ａ３及び監視対象Ｂ４は、一般的にインターネットに接続するような機器（例えばサーバ）とは限定していない。しかし、生存報告を可能にする為に、監視対象Ａ３及び監視対象Ｂ４は任意のインターネットプロトコルを実装することが求められる。

【0077】

次に本発明実現のために実施される親機と子機の間で行われる通信について説明する。
（親機と子機間の通信）
親機と子機間の通信は以下の３つの目的を想定する。
１）生存確認
２）状態監視
３）アウトレットＯｎ・Ｏｆｆ指示

【0078】

いずれの目的であっても、以下の基本的な通信方式は共通する。
図４は本発明の親機２ａと子機２ｂとの間の通信方式に関する概念図である。図４では子機２ｂとしているが挙動は子機２ｃでももちろん同じである。

【0079】

本発明において、親機と子機の間はＨＴＴＰＳ方式のＧｅｔメソッドを用いて通信を行う。この時ＨＴＴＰＳリクエストは本発明に係るテキストデータを含めて送ることで本発明に係る「コマンド」の内上記３種の何れかであるかを子機２ｂに伝える。それに応じて子機２ｂが親機２ａに対して本発明に係るテキストデータを内包したＨＴＴＰＳレスポンス、すなわち本発明に係る「レスポンス」を返す。これを１セットとして通信を行う。なお、上述の通りＨＴＴＰＳはＨＴＴＰに共通鍵を取得するプロセスが増えたプロトコルであり、リクエスト及びレスポンスの構成は変わらない（もともとＲＦＣ７２３０で規定されている為）。よって、本明細書内ではＨＴＴＰＳとＨＴＴＰを混用する。

【0080】

親機２ａがコマンドを発行した後、一定時間が経過してもレスポンスが子機２ｂから返送されなかった場合には、タイムアウトとして子機２ｂ自体が動いていないと親機２ａは判断する。この時、子機ごとにタイムアウト値を設定するか、共通で１つのタイムアウト値とするかは親機２ａの設計事項である。

【0081】

図５は、図４に係るコマンドに該当するテキストデータが、ＨＴＴＰリクエストの何処に含まれるかを説明する概念図である。また図６は、図４に係るレスポンスに該当するテキストデータがＨＴＴＰレスポンスの何処に含まれるかを説明する概念図である。なお、ＨＴＴＰＳでもＨＴＴＰでも同じデータフォーマットを用いるため、この図で説明する。

【0082】

ＲＦＣ７２３０ではＨＴＴＰリクエスト及びＨＴＴＰレスポンスのデータ形式を定義する。なお図５及び図６は、ＨＴＴＰにかかわる物であり、本発明に関連するモノではないので図番は省略する。

【0083】

基本的にＨＴＴＰリクエストもＨＴＴＰレスポンスも同じデータ形式をとる。ＨＴＴＰリクエストはリクエスト行、ヘッダ及びメッセージボディから構成される。また、ＨＴＴＰレスポンスはレスポンス行、ヘッダ及びメッセージボディから構成される。

【0084】

図５のリクエスト行は、ＨＴＴＰリクエストのデータフィールドの一つである。リクエスト行にはメソッド（通信目的）、送信先を表すパス（クエリも含む）、ＨＴＴＰのバージョンを記載しなければならない。なお、既述の通り、本発明ではＧｅｔメソッドを使用することを想定する。またＨＴＴＰのバージョンは１．１を想定する。本発明におけるＨＴＴＰリクエストのパスには、子機２ｂに対する通信目的及びその付加情報（認証ＩＤや認証パスワード）がクエリの形で添付される。

【0085】

図５のヘッダは、リクエストに関連する追加情報を表すデータフィールドである。使用する文字コードやキープアライブ（通信が終わってもセッションを維持し続けるか？）、認証方式の指定等と言った情報が記載される。

【0086】

図５のメッセージボディは、該ＨＴＴＰリクエストにおける補足情報などを送るためのデータフィールドである。ヘッダとメッセージボディの間にはＣＲ＋ＬＦ（キャリッジリターン＋ラインフィード）が挿入されており、その間の識別は比較的容易である。本発明においては暗号化したデータをリクエスト行パス中のクエリに添付される。そのためＨＴＴＰリクエストのメッセージボディは使用しない。ただし、メッセージボディに添付するような形にしても良い。

【0087】

図６のＨＴＴＰレスポンスのレスポンス行は、ＨＴＴＰレスポンスのデータフィールドの一つである。レスポンス行には、ＨＴＴＰのバージョン、ステータスコード、補足情報（主にステータスコードの詳細情報）などが記載される。

【0088】

図６のヘッダは、レスポンスに関連する追加情報を表すデータフィールドである。

【0089】

図６のメッセージボディは、要求元に送り返すデータを添付するデータフィールドである。一般的なＨＴＴＰＳ Ｇｅｔメソッドによる通信であれば、このメッセージボディには要求元のブラウザで表示するためのＨＴＭＬデータが添付され、暗号化されることになる。本発明でも、処理結果がメッセージボディに添付され暗号化されることになる。

【0090】

ＨＴＴＰＳリクエストを本発明の「コマンド」足らしめるテキストデータはＨＴＴＰＳリクエストのパスに付加されるクエリに格納されることを想定する。また、ＨＴＴＰＳレスポンスを、本発明の「レスポンス」足らしめるテキストデータはＨＴＴＰＳレスポンスのメッセージボディに格納されることを想定する。ただし、別のリクエスト行、レスポンス行及びヘッダにそれらを含ませるようにしても良い。

【0091】

（生存確認）
次に通信目的である「生存確認」について説明する。
図７は、「生存確認」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図よりコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がリクエスト行のクエリ（コマンド）あるいはメッセージボディ（レスポンス）に格納される文字列である。なお、エラー処理については各ハードの動作の説明で記載する（（子機の生存確認モジュールＳＷ２の処理）参照）。

【0092】

生存確認は、子機２ｂが正常に動作しているかを親機２ａが確認するコマンドである。
任意のタイミングで親機２ａは、子機２ｂに対してコマンドを発行する。この際、ＨＴＴＰＳリクエストのリクエスト行パスのクエリ（以下ＨＴＴＰＳリクエストのクエリ）に「ＨＥＬＬＯ」を記載し暗号化される。

【0093】

親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行上で指示されたパスによってこのメッセージが本発明に係るメッセージかを確認する。

【0094】

このリクエストが本発明に係るメッセージであることを子機２ｂが確認すると、子機２ｂは受け取ったクエリの復号後の内容がテキストの「ＨＥＬＬＯ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する（使用する文字コードなど）。

【0095】

復号後のクエリの内容がテキストの「ＨＥＬＬＯ」であれば、子機２ｂは自身の稼働状態を問われているのだと理解する。子機２ｂが問題なく動作していれば、送り返すＨＴＴＰＳレスポンスのメッセージボディを「ＡＬＩＶＥ」として暗号化後にＨＴＴＰモジュールに戻す。また必要があればＨＴＴＰレスポンスのヘッダに関する情報をＨＴＴＰモジュールに戻す。なお、子機２ｂの本発明に係るモジュールが動作していない場合は、必要な情報がそろわないため当然ＨＴＴＰＳレスポンスは返せない。子機２ｂはＨＴＴＰＳレスポンスを返せないため、親機２ａにはレスポンスは届かず、親機２ａではタイムアウトとして処理する。

【0096】

このＨＴＴＰレスポンスを受け取った親機２ａの図示しないＨＴＴＰモジュールはこのＨＴＴＰレスポンスのメッセージボディに復号後「ＡＬＩＶＥ」が付いていることを確認することで子機２ｂが動作していることを確認することになる。

【0097】

なお生存確認に関しては内部設定の変更等を行うことを想定していないため、本明細書では親機２ａから子機２ｂにＩＤやパスワード等は送られないとしている。しかしこれらを送信対象とすることも本発明の射程に含まれる。

【0098】

（状態監視）
次に通信目的である「状態監視」について説明する。
図８は、「状態監視」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図もコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がメッセージボディに格納される文字列である。また、エラー処理については図７同様各ハードの記載で説明する。

【0099】

本明細書における「状態監視」とは、子機２ｂの有する全ての「アウトレット」の情報を収集して親機２ｂに返答することを言う。従って、子機２ｂの情報が外部に発信されることとなる為、認証ＩＤ及び認証パスワードで情報の提供の是非を確認する。

【0100】

親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行でこのメッセージが本発明に係るメッセージかを確認する。

【0101】

子機２ｂは受け取ったＨＴＴＰＳリクエストを復号し、クエリの先頭がテキストの「ＳＴＡＴＵＳ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する。ＨＴＴＰＳリクエストのクエリの先頭がテキストの「ＳＴＡＴＵＳ」であれば、子機２ｂは自身の各アウトレットの状態を問われているのだと理解する。

【0102】

次に、その子機２ｂが親機２ａに対して状態監視を許可しているか確認する。子機２ｂは残りの復号後のＨＴＴＰＳリクエストのクエリから認証ＩＤ及び認証パスワードを抽出する。図上ではメッセージボディは「ＳＴＡＴＵＳ」に続いて文字間識別の“、”（コンマ）、認証ＩＤ、文字間識別の“、”（コンマ）、認証パスワードと続くが、これらの並びは設計事項である。また文字間識別の“、”（コンマ）を？や＆に置き換えるなども設計者が適宜選択すればよい。但し本明細書では文字間識別に“、”（コンマ）を使うものとして記述する（以下同様）。

【0103】

認証ＩＤ及び認証パスワードが抽出できれば、子機２ｂは自身が保持する認証ＩＤ及び認証パスワードとの比較を行う。認証ＩＤと認証パスワードの比較の結果が一致した場合には子機２ｂは自ハードウェア内のアウトレットの稼働状況を収集する。自身の各アウトレットの状態の収集が終了したら、送り返すＨＴＴＰＳレスポンスのレスポンスボディを生成する。

【0104】

ＨＴＴＰＳレスポンス用のレスポンスボディはテキスト「ＲＥＳＰ、」を先頭にし、その後収集したアウトレット情報を記載する。アウトレット情報の詳細は各ハードの記載で説明する（（子機の状態監視モジュールＳＷ３の処理）参照）。

【0105】

（アウトレットＯｎ・Ｏｆｆ指示）
次に通信目的である「アウトレットＯｎ・Ｏｆｆ指示」について説明する。

【0106】

図９は、「アウトレットＯｎ・Ｏｆｆ指示」時の親機２ａと子機２ｂとの間の通信方式に関する概念図である。なお本図もコマンド及びレスポンスの後ろに括弧書きを挿入するが、この括弧書き中に含まれる文字列がメッセージボディに格納される文字列である。また、エラー処理については図７同様各ハードの記載で説明する。

【0107】

本明細書における「アウトレットＯｎ・Ｏｆｆ指示」は、子機２ｂが有するアウトレットへの電源の供給をＯｎ・Ｏｆｆすることを目的とする。従って、子機２ｂの操作を伴うため、「状態監視」時同様、認証ＩＤと認証パスワードを用いて情報の提供の是非を確認する。

【0108】

親機２ａから送られた上記コマンドを受信した子機２ｂのＨＴＴＰモジュールは、リクエスト行でこのメッセージが本発明に係るメッセージかを確認する。

【0109】

子機２ｂは受け取ったＨＴＴＰＳリクエストを復号しクエリを確認する。そして子機２ｂは復合後の内容の先頭がテキストの「ＣＯＮＴ」であることを確認する。その際必要であれば、子機２ｂは受け取ったヘッダの情報を参酌する。複合語のクエリの内容の先頭がテキストの「ＣＯＮＴ」であれば、子機２ｂは自身が有するアウトレットへの電源供給のＯｎ・Ｏｆｆを指示されているのだと理解する。

【0110】

次に、その子機２ｂが親機２ａに対してアウトレットＯｎ・Ｏｆｆ指示を許可しているか確認する。子機２ｂは残りの復号後のクエリから認証ＩＤ及び認証パスワードを抽出する。

【0111】

認証ＩＤ及び認証パスワードが抽出できれば、子機２ｂは自身が保持する認証ＩＤ及び認証パスワードとの比較を行う。認証ＩＤと認証パスワードの比較が一致した場合には子機２ｂは復号後のクエリ中で指示された番号のアウトレット（図９中のアウトレット番号）の電源に対する動作を実行する。この際の、変更される電源の供給状態も復号後のクエリ中に記載されている（図９中の「命令」）。子機２ｂは、その変更結果を参考に送り返すＨＴＴＰレスポンスのメッセージボディを生成する。ここで「命令」とは１バイトのデータであり、該アウトレットのリレーをＯｎ・Ｏｆｆすることを意味する。本明細書においては１をＯｎ、０をＯｆｆとして定義する。

【0112】

ＨＴＴＰＳレスポンス用のレスポンスボディはテキスト「ＲＥＳＵＬＴ」を先頭にし、文字間識別の“、”（コンマ）をつなげた後に、設定変更の結果を記載する。結果の詳細は各ハードの記載で説明する（（子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の処理）参照）。

【0113】

（ハードウェア構成）
次にハードウェア構成について説明する。
図３の説明でも述べたが、親機２ａと子機２ｂの基本的な違いはアウトレットの数のみである。突き詰めて考えればメモリの搭載量なども相違するが、昨今の状況ではいずれであっても十分な容量を確保できる。よって、本明細書では親機２ａと子機２ｂのハードウェアはアウトレットの数以外は共通するものとして説明する。従って、相違点についてはここで記す。

【0114】

図１０は、子機２ｂの物理的電気的構成を表す概念図である。
本発明に関わる子機２ｂはＣＰＵ１０１、バスコントローラ１０２、メモリ２０１、周辺用バスコントローラ２０２、ＬＡＮ ＩＦ３０１、ＬＥＤコントローラ３０２、リレーコントローラ３０３、リレー３１１、３１２，３１３、コンセント３２１、３２２、３２３を含んで構成される。

【0115】

ＣＰＵ１０１は、メモリ２０１中に記録されたプログラムに従い処理を行う中央制御装置である。本明細書ではＣＰＵとしているが、ＭＰＵでも問題はない。

【0116】

バスコントローラ１０２は、ＣＰＵ１０１がメモリ２０１等にアクセスする際に経由するチップセットである。

【0117】

その性質上バスコントローラ１０２は、内部バスａ及び外部バスｂに接続されており、ＣＰＵ１０１から外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信を制御する。

【0118】

市場ではＣＰＵ１０１の種類に対応してバスコントローラ１０２は市販品あるいは専用品に拘らず、ＣＰＵ１０１と外部バスｂ及び周辺用バスｃに存在するコントローラ等との通信ができれば良い。

【0119】

メモリ２０１は、ＣＰＵ１０１が実行するプログラム及び処理の対象となるデータ（ネットワーク機器監視装置の設定など）を記録するためのメモリである。通常だとＤＲＡＭのような揮発性記憶素子と電源を切っても保持されるＮＶＲＡＭのような不揮発的な記憶素子、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）に分けて考えられるが、本明細書では全てを包含してメモリ２０１とする。また本図ではメモリ２０１を外部バスｂのみに接続しているが、内部バスａや周辺バスｃに分散させて配置しても良い。

【0120】

メモリ２０１には、一般的なＨＴＴＰモジュールだけでなく、本発明に係るサブモジュール（以下単にサブモジュール）もプログラムとして記憶されている。

【0121】

理論上、親機２ａのメモリの容量と子機２ｂのメモリの容量では前者の方が大きい方が良い。子機２ｂは自身のネットワーク情報（ＩＰアドレス等）とアウトレット情報を保持すればよいが、親機２ａは子機２ｂを最大接続数分確保しなければならないためである。但し、近年ではメモリの容量も大きくなっている為、特に気にしない場合も多い。

【0122】

以下具体的に通信に必要なメモリ容量を確認する。
まず子機２ｂについて検討する。

【0123】

（子機のメモリ容量）
ＨＴＴＰ及びＩＰで通信をする以上、子機２ｂも相手と通信する際には自身のＩＰアドレス、ＩＰｖ４であればサブネットマスク、ゲートウェイアドレスが必要になることは言うまでもない。まずはこれらを記憶する（各４バイト）。ただし、これらはＩＰ層に関する情報であるのでＩＰ層に管理を任せても問題は無い。

【0124】

また本発明では、状態監視やアウトレットＯｎ・Ｏｆｆ指示を行う際には認証ＩＤと認証パスワードが必要になる。認証ＩＤはともかく認証パスワードは文字数が多ければ多いほど暗号強度が高くなる為できる限り長くすべきである。子機２ｂは自分の認証ＩＤ（１５バイト）と認証パスワード（３２バイト）をそれぞれ確保する必要がある。ただし、これらのバイト数に拘る必要は無く、もっと長いバイト長でも良い。

【0125】

また自身のＨＴＴＰモジュールに割り当てられているポート番号も記憶する（２バイト）。
さらにアウトレット１つごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝が必要になる。これをアウトレットセットと称呼する。

【0126】

以下、アウトレットセットのデータフィールドについて説明する。
アウトレット番号は、各アウトレットに対して一意に割り当てられる番号である。

【0127】

アウトレットの特性情報は、アウトレットがどのような出力を行うかを表すデータフィールドである。具体的には図３の各アウトレットがもつＡＣ１００Ｖ、ＤＣ５Ｖ、ＤＣ１２Ｖ、接点などを表す。具体的にはＡＣ１００Ｖに１、ＤＣ５Ｖに２、ＤＣ１２Ｖに４などを割り当てて、それをこのデータフィールドに記憶することになる。

【0128】

アウトレットの出力情報は、現在どのような出力状態を表すデータフィールドである。具体的にはＯＮ＝１、ＯＦＦ＝２、故障＝４、不明＝８（値は１０進数）などを割り当て、アウトレットが現在どのような状況下であるかを取得してこのデータフィールドに記憶することになる。

【0129】

さらに各アウトレットの電源をＯｆｆ－＞ＯＮあるいはＯｎ－＞Ｏｆｆする際に、最低限待つ時間を表すデータフィールドを記憶する（１バイト）。

【0130】

以上を合計すると４＊３＋１５＋３２＋２＋４＊ｎ（アウトレット数）＋１＝６２＋（４＊ｎ）が必要になる。アウトレットが１つなら６６バイト、アウトレットが６つなら８６バイトが必要になる。

【0131】

（親機のメモリ容量）
次に親機２ａについて検討する。
親機２ａは、複数の子機を管理するためにまず子機ごとに管理が必要なデータフィールドを確認する。

【0132】

まず子機２ｂのネットワークアドレスおよびポート番号が必要になる。親機、子機ともにＩＰｖ４ローカルネットワーク内に存在するのであれば、ネットワークアドレスとしてはＩＰアドレス（４バイト）およびサブネットマスク（４バイト）で十分であるが、インターネット９を挟んだ２つのローカルネットワーク７、８を含んだ構成の場合、ゲートウェイアドレス（４バイト）と、ドメイン名あるいはグローバルＩＰアドレスを指定する必要がある。この場合、ドメイン名のデータフィールドとして最大２５３バイトが必要になる。ＩＰで通信する以上、これらは必須である。なお、ドメイン名で指定したパケットが所定の子機に到達するためには、ローカルネットワーク８内の図示しないルータによってパケットを転送する所謂ルーティングが必要となるが、ルーティング設定については本発明には直接関係が無いのでこれ以降説明は省略する。

【0133】

また、状態監視やアウトレットＯｎ・Ｏｆｆ指示を行う際には認証ＩＤと認証パスワードが必要になる。よって子機２ｂごとに、認証ＩＤ（１５バイト）と認証パスワード（３２バイト）を記録するデータフィールドが必要である。

【0134】

更に当該子機２ｂが持つアウトレットごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝が必要になる。これらの性質は子機２ｂのそれらと同様である。
以上より、通信先の子機２ｂごとに（４＋４＋４＋２５３＋４）＋２＋１５＋３２＋４＊ｘ（子機２ｂのアウトレット数）＝３１８＋４＊ｘが必要になる。

【0135】

そのほかシステム用のパラメータとして、通信タイムアウト時間を規定するタイムアウト時間を規定するデータフィールド（２バイト）及び生存確認の再送信時間を規定するデータフィールド（２バイト）が記憶される。

【0136】

以上より、１子機あたりに４＋｛（３１８＋４＊ａ）＋（３１８＋４＊ｂ）＋（３１８＋４＊ｃ）＋…｝が親機２ａに必要な容量となる。もちろんシステム用のメモリが必要となる為、これだけあればプログラムが動くというものではないことは言うまでもない。

【0137】

周辺用バスコントローラ２０２は、ＣＰＵ１０１等が外部バスｂを経由して周辺用バスｃ上にあるコントローラを制御する際に経由するチップセットである。
バスコントローラ１０２同様、周辺用バスコントローラ２０２も外部バスｂ及び周辺用バスｃに接続されている。

【0138】

市場ではＣＰＵ１０１の種類に対応して周辺用バスコントローラ２０２も市販品あるいは専用品に拘らず、本実施の形態ではＣＰＵ１０１と周辺用バスに存在するコントローラ等との通信ができれば良い。

【0139】

タイマ２０３は、図示しない動作クロックによって内部で時間を図るためのタイマである。

【0140】

ＬＡＮ ＩＦ３０１は、ネットワーク８に接続する為のコネクタ（物理層）及びチップ（データリンク層、ネットワーク層）などを含むインターフェイス群である。このＬＡＮ ＩＦ３０１を経由して他のネットワーク機器との通信を行う。このＬＡＮ ＩＦ３０１は、ネットワーク８と接続可能なものでなければならないことは言うまでもない。

【0141】

このＬＡＮ ＩＦ３０１が複数ある場合には、ＬＡＮ ＩＦごとにＩＰアドレスが割り振られる。従って、子機２ｂが無線ＬＡＮと有線ＬＡＮの二つのＬＡＮ ＩＦを有する場合には、其々にＩＰアドレスが割り振られることに注意する。親機２ａは無線ＬＡＮ及び有線ＬＡＮのいずれをもちいて監視対象と接続しても良い。また子機２ｂはいずれを用いて親機２ａと接続しても良い。

【0142】

ＬＥＤコントローラ３０２は、ネットワーク機器監視装置の状態をユーザに視覚伝達する為のＬＥＤを制御するためのコントローラである。本図では省略しているが、ＬＥＤコントローラ３０２は図示しないＬＥＤが接続され、これを点灯、点滅させることでユーザに子機２ｂの動作状態を伝える。

【0143】

リレーコントローラ３０３は、リレー３１１，３１２、３１３を制御するためのコントローラである。子機２ｂの製品仕様に応じて、制御するリレーの最低必要数が決定される。そしてそのリレーの数に応じてリレーコントローラ３０３はレジスタを持つ。ＣＰＵ１０１はリレーコントローラ３０３中の該当するレジスタに１／０を書き込むことで、該当するリレーをＯｎ／Ｏｆｆし、対応するコンセントへの電源供給を制御する構造になっている。但しこれに拘るものでなく、いかなる方法であってもリレーを制御できる手段を提供できれば、リレーコントローラ３０３の役割を果たすことが可能である。

【0144】

リレー３１１、３１２，３１３は、電源からコンセントへの電力供給を制御するための継電器である。リレー３１１、３１２，３１３は、リレーコントローラ３０３からの制御信号によってそれぞれ対応するコンセントへの電力供給が独立して制御可能なように構成されている。

【0145】

コンセント３２１、３２２、３２３は、子機２ｂから監視対象に電力を供給するためのコンセントである。各コンセントは対応するリレーに接続されることで、ＣＰＵ１０１による制御が可能になっている。

【0146】

先にも述べたがリレーとそれに接続されるコンセント一組でアウトレットを構成する。図中では＃１、＃２、＃３の３組で示される。本図ではアウトレットは３つから構成されているが、あくまでもこれは図のスペースの都合上そうしているだけである。実機では図３準拠でアウトレットを６つにしても良い。その場合はコンセント３２４とリレー３１４を含む図示しないアウトレット＃４、コンセント３２５とリレー３１５を含む図示しないアウトレット＃５、コンセント３２６とリレー３１６を含む図示しないアウトレット＃６がさらに追加されることになる。各アウトレットには一意のアウトレット番号が割り当てられており、親機２ａが操作するアウトレットを指定する際にこのアウトレット番号が用いられる。

【0147】

各子機内の各アウトレットには、子機単位で一意のアウトレット番号が割り振られている。これらは親機２ａが子機に対して特定のアウトレットを指定して操作を指示する際に用いられる。アウトレット情報、アウトレット番号に関する記載を参照されたい。

【0148】

既述の通り親機２ａにはアウトレットが存在しなくても問題はない。直接の制御は子機２ｂに行わせればよいためである。もちろん親機２ａにアウトレットをつけて親機２ａが直接ネットワーク機器を管理するようにしても良い。

【0149】

なお、監視対象とコンセントの接続を適切に行わないと、該監視対象に異常が発生し電源を切断するときに異なる監視対象の電源を切断することになる。よってユーザは注意を払って接続及び子機２ｂの設定を行うべきである。本明細書ではそれらの対応は取れているものとして説明している。

【0150】

次に、親機２ａと子機２ｂ間で通信を行う際の親機２ａ及び子機２ｂの内部動作について説明する。
（ソフトウェアモジュールの構成）
図１１は、本発明に係るソフトウェアモジュールの構成を表す図である。
本発明に係るソフトウェアモジュールは、ＨＴＴＰモジュールＳＷ１、生存確認モジュールＳＷ２、状態監視モジュールＳＷ３、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４を含む。

【0151】

ＨＴＴＰモジュールＳＷ１は、１）図示しないＩＰモジュールから図５に示すＨＴＴＰＳリクエストを受け取り、２）復号した後、パスに付加されるクエリを抽出し、３）処理を他のモジュールに割り当てるモジュールである。また他のモジュールから送られたデータを図６に示すＨＴＴＰＳレスポンス形式に整えた後ＩＰモジュールに送信する。親機も子機も基本構成は同じだが、生存確認モジュールＳＷ２、状態監視モジュールＳＷ３、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の動作は異なる。子機はＨＴＴＰＳリクエストを処理するのに対し、親機はＨＴＴＰＳレスポンスを処理する必要があるためである。

【0152】

親機２ａがＨＴＴＰＳリクエストを送信した後、子機２ｂでは図示しないＩＰモジュールが受信したデータに添付されたＴＣＰヘッダのポート番号によってＨＴＴＰモジュールＳＷ１に処理を引き渡すかを決定する。

【0153】

ＨＴＴＰモジュールＳＷ１に処理が引き渡されたＨＴＴＰＳリクエストのデータは図５のように、リクエスト行、ヘッダ、メッセージボディ（本明細書では不使用）を含んで構成される。

【0154】

このＨＴＴＰＳリクエストのリクエスト行中のパス名によって、このＨＴＴＰＳリクエストが本発明にかかわるＨＴＴＰＳリクエストに相当するかを判断する。ＨＴＴＰＳリクエストが本発明に係るＨＴＴＰＳリクエストに関連するモノでなければＨＴＴＰモジュールＳＷ１は相応の対応を取る。但しそれらは設計事項である。

【0155】

送られたＨＴＴＰＳコマンドが本発明に係るＨＴＴＰＳリクエストであると判断すると、ＨＴＴＰモジュールＳＷ１がクエリの先頭の文字列（図５メッセージボディ詳細の「値１」）によってどのモジュールにそのデータを送るかを決定する。すでに述べた通り各モジュールに対応する文字列は、生存確認は「ＨＥＬＬＯ」、状態監視は「ＳＴＡＴＵＳ」、アウトレットＯｎ・Ｏｆｆ指示は「ＣＯＮＴ」である。よってＨＴＴＰモジュールＳＷ１は、復号後のクエリに対して構文解析を行い、これらの文字列を抽出する。そして、ＨＴＴＰモジュールＳＷ１は、復号後のクエリのデータからこれらの文字列および続く文字間識別の“、”（コンマ）を削除する。その後に、ＨＴＴＰモジュールＳＷ１は適切なモジュールＳＷ２～４に削除後のクエリのデータを引き渡す。これら以外の文字列が先頭に出現した際のエラー処理は設計事項である。

【0156】

また、ＨＴＴＰＳレスポンスを送信する場合には、ＨＴＴＰモジュールＳＷ１は各モジュールＳＷ２～４から処理を引き渡されたデータにＴＣＰヘッダを添付し、ＩＰモジュールに引き渡す。この際、ＨＴＴＰＳレスポンスのメッセージボディの先頭に、生存確認は「ＡＬＩＶＥ」、状態監視は「ＲＥＳＰ」、アウトレットＯｎ・Ｏｆｆ指示は「ＲＥＳＵＬＴ」を添付する必要があるが、これらは各モジュールＳＷ２～４によって添付される。各モジュールＳＷ２～４から渡されたデータはＨＴＴＰＳレスポンスのメッセージボディに付加され、ＨＴＴＰモジュールＳＷ１によって暗号化され親機２ａに送信される。

【0157】

（子機の生存確認モジュールＳＷ２の処理）
生存確認モジュールＳＷ２は、生存確認に関する処理を行うモジュールである。上記の通りＨＴＴＰモジュールＳＷ１が復号後のクエリからＨＥＬＬＯ等を削除すると、残存データが存在しなくなるのでクエリの実質的な中身は喪失する。従って、生存確認モジュールＳＷ２には処理のみを引き渡すことになる。なお、本来送られてくるはずのないデータが送られてきた場合のエラー処理は設計事項である。

【0158】

生存確認は、ＨＴＴＰＳレスポンスのメッセージボディに「ＡＬＩＶＥ」をつけてＨＴＴＰモジュールＳＷ１に処理を返すのみである。従って、本モジュール起動時は引き渡されるデータは無い。そして、戻り値として「ＡＬＩＶＥ」だけをＨＴＴＰモジュールＳＷ１に戻して終了する。但し、生存確認モジュールＳＷ２がハードウェアの動作確認を行い正常であることを確認した後に生存確認モジュールＳＷ２が「ＡＬＩＶＥ」をつけてＨＴＴＰモジュールＳＷ１に処理を返しても良い。なお、この場合のエラー発生時の挙動は設計事項である。

【0159】

（子機の状態監視モジュールＳＷ３の処理）
状態監視モジュールＳＷ３は、状態監視に関する処理を行うモジュールである。また、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４は、アウトレットＯｎ・Ｏｆｆ指示に関する処理を行うモジュールである。これらは生存確認モジュールＳＷ２と異なり、ＨＴＴＰモジュールＳＷ１から引き渡されるデータ（復号後のＨＴＴＰリクエストのクエリから先頭文字列およびそれに続く文字間識別の“、”（コンマ）を削除したもの）を処理する必要がある。従って、これら各モジュールＳＷ３、ＳＷ４にはそれぞれに適した構文解析手段（パーサ）が付与されている。図上ではこれらはＳＷ３ａ、ＳＷ４ａと記載されている。

【0160】

図１２は、子機２ｂの状態監視モジュールＳＷ３の受信処理に関するフローチャートである。
状態監視モジュールＳＷ３のパーサＳＷ３ａは、まずＨＴＴＰモジュールＳＷ１から引き渡されたデータ（復号後のクエリから「ＳＴＡＴＵＳ、」を削除したもの）から認証ＩＤ（ステップＳ２００１）及び認証パスワード（ステップＳ２００２）を抽出する。

【0161】

そして、状態監視モジュールＳＷ３は抽出した認証ＩＤと認証パスワードを自身が保持する認証ＩＤと認証パスワードを比較し、一致していなければＨＴＴＰモジュールＳＷ１に文字列「ＲＥＳＰ、ＮＡＫ」を戻り値として返す（ステップＳ２００３：Ｎｏ）。

【0162】

一方比較の結果が一致していれば（ステップＳ２００３：Ｙｅｓ）、状態監視モジュールＳＷ３は子機２ｂ自身の全てのアウトレットの情報を収集する（ステップＳ２００４）。この際、（子機のメモリ容量）で説明した、アウトレットセットからデータを読みだしても良いし、実際に当該アウトレットのハードの情報をレジスタ等から読みだしても良い。

【0163】

ステップＳ２００４で収集した情報を、送信可能な形に形成する（ステップＳ２００５）。具体的な形式は、メモリの記憶形式に記載ものと同じで、１つのアウトレットごとに｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝の形式になる（以下アウトレット情報）。また文字列間には文字間識別の“、”（コンマ）を挿入する。すなわちアウトレット番号１バイト＋文字間識別の“、”（コンマ）１バイト＋アウトレットの特性情報（２バイト）＋文字間識別の“、”（コンマ）１バイト＋アウトレットの出力情報（１バイト）の計６バイトで１アウトレットの情報にする。これを子機２ｂ自身の有する全てのアウトレットに対して行う。

【0164】

そして、全てのアウトレット情報を結合する（ステップＳ２００６）。ここではアウトレット番号順に並べて文字間識別の“、”（コンマ）１バイトでつなげていく形で文字列を結合する。すなわち１アウトレット情報（６バイト）＋文字間識別の“、”（コンマ）１バイト＋１アウトレット情報（６バイト）＋…と言う形で形成される。アウトレットが複数存在することでアウトレット情報が複数ある際に、連続するデータ間をどのように識別するか設計事項である。

【0165】

この子機２ｂの持つ全アウトレットのアウトレット情報をデータにしたのちに、状態監視モジュールＳＷ３はその文字列の先頭に「ＲＥＳＰ、」を追加する（ステップＳ２００７）。
以上の手順にてＨＴＴＰＳレスポンスのメッセージボディが生成される。これをＨＴＴＰモジュールに送り、ＨＴＴＰモジュールはＨＴＴＰレスポンスを親機２ａに送り返すことになる。

【0166】

（子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の処理）
図１３は子機のアウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４の受信処理に関するフローチャートである。
状態監視モジュールＳＷ３のパーサＳＷ３ａは、まずＨＴＴＰモジュールＳＷ１から引き渡されたデータから認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）を抽出する。なお、認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）を抽出した後に、ＨＴＴＰモジュールＳＷ１から引き渡されたデータから認証ＩＤ（ステップＳ３００１）及び認証パスワード（ステップＳ３００２）及びそれの区切りとして使用していた文字間識別の“、”（コンマ）１バイトを２回（計２バイト）削除する。

【0167】

そして、状態監視モジュールＳＷ３は抽出した認証ＩＤと認証パスワードを自身が保持する認証ＩＤと認証パスワードと比較し、一致しなければＨＴＴＰモジュールＳＷ１に文字列「ＲＥＳＵＬＴ、ＮＡＫ」を戻り値として返す（ステップＳ３００３：Ｎｏ）。ここまでは、状態監視モジュールＳＷ３とほぼ同じである。

【0168】

比較の結果が一致していれば（ステップＳ３００３：Ｙｅｓ）、認証ＩＤ、認証パスワード等を削除したデータから、アウトレット番号（ステップＳ３００４）及び命令（ステップＳ３００５）を抽出する。前述の通り、命令とは該アウトレットのリレーをＯｎ・Ｏｆｆいずれにするか、あるいはリブート（一定時間後に再起動）を表すコマンドである。本明細書では命令自体は１バイトであり、１でＯｎ、０でＯｆｆとする。すなわちアウトレット命令の形式は、｛アウトレット番号（１バイト）、アウトレットコマンド（１バイト）｝の形式であり、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４はこれから対象アウトレットと動作を導出する。

【0169】

以下、アウトレット命令の各パラメータについて説明する。
アウトレット番号は、各アウトレットに対して一意に割り当てられる１バイトの番号である。これを用いることで親機２ａは操作対象になるアウトレットを子機２ｂに指定することができる。

【0170】

アウトレットコマンドは、各アウトレットをどのように動かすかをあらわす１バイトの番号である。具体的には電源をＯｎが１、電源をＯｆｆが２、電源をリブートする（Ｏｆｆ－＞Ｏｎ）が４、と言った形であり当てられる。リブートが命令の中に含まれるのは、ルータを監視対象とした場合に電源をＯｆｆしてしまうとネットワークを越えて通信ができなくなり、ルータを再起動できなくなる。この対策として子機２ｂにリブート機構を持たせるようにしたものである。

【0171】

この命令に従い、アウトレットＯｎ・Ｏｆｆ指示モジュールＳＷ４は該アウトレットのリレーを命令に従い制御し、その結果を取得する（ステップＳ３００６）。正常に処理できた場合には（ステップＳ３００７：Ｙｅｓ）、戻り値を「ＲＥＳＵＬＴ、ＤＯＮＥ」とし戻り値としてＨＴＴＰモジュールに返す。

【0172】

正常に処理できなかった場合には（ステップＳ３００７：Ｎｏ）、その理由が何かを親機２ａに送信する。本図においては処理不能の場合、例えばリレーの破損や本来存在しないアウトレット番号が親機２ａから指定された場合など、は戻り値を「ＲＥＳＵＬＴ、ＥＲＲＯＲ、０」とする。一方、リレーの操作禁止時間（例えばアウトレット命令４のリブート期間中のコマンドの送信など）以内にアクセスした等の場合、該アウトレットはビジーとして戻り値を「ＲＥＳＵＬＴ、ＥＲＲＯＲ、１」とする。
このように、子機２ｂから親機２ａに戻す戻り値を決定する。

【0173】

（親機起動時の動作）
次に親機の起動時の動作について説明する。
図１４は、親機２ａに電源を投入した時の動作を表すフローチャートである。

【0174】

電源を投入すると、親機２ａのＣＰＵ１０１はタイマ２０３をリセットし、また自身が管理する為の子機をカウントする為のカウンタＸを１に設定する（ステップＳ１００１）。

【0175】

そして、親機２ａのＣＰＵ１０１は生存確認用のモジュールをメモリ２０１から読み出し子機Ｘの生存確認を行い（ステップＳ１００２）、続けて生存確認用のモジュールをメモリ２０１から読み出し、当該子機の状態確認を行い当該子機のアウトレットの状態を確認する（ステップＳ１００３）。この確認の際に、ステップＳ１００１でリセットしたタイマ２０３を用いてタイムアウトの確認を行う。子機の電源が入っていないなどにより、これらの処理はタイムアウトしてしまうことで上記処理が終了することもある。またステップＳ１００２でタイムアウトした場合にステップＳ１００３を当該子機に実施するかは設計事項である。

【0176】

生存確認および状態監視の成否にかかわらず確認が終了すると、Ｘの値を１増分する（ステップＳ１００４）。そして自身が管理する全ての子機の確認が終了するまでステップＳ１００２～Ｓ１００４を繰り返す（ステップＳ１００５：Ｎｏ）。全ての子機の確認が終了すると（ステップＳ１００６：Ｙｅｓ）、起動時の処理を終了する。

【0177】

（親機２ａによるコマンドの送信）
次に親機２ａによるコマンドの送信について説明する。
これまでも述べたが親機２ａは１）生存確認、２）状態監視、３）アウトレットＯｎ・Ｏｆｆ指示の３つのコマンドを送信することがある。親機２ａはコマンド送信時にそれぞれ以下のような処置をとる。

【0178】

１）生存確認
生存確認コマンドを送信する際には、親機２ａはＨＴＴＰＳリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また文字列「ＨＥＬＬＯ」をクエリに添付し暗号化する。

【0179】

２）状態監視
状態監視コマンドを送信する際には、親機２ａはＨＴＴＰリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また親機２ａは文字列「ＳＴＡＴＵＳ、」及びそれに続けて認証ＩＤと認証パスワードを所定の形式で記載しこれらをリクエスト行のパスにクエリとして添付した後にこれらを暗号化して送信する。構文は既述の（状態監視）に記載されているので確認してほしい。

【0180】

３）アウトレットＯｎ・Ｏｆｆ指示
アウトレットＯｎ・Ｏｆｆ指示コマンドを送信する際には、ＨＴＴＰリクエストのリクエスト行に送信先の子機２ｂのパス名を記載する。また親機２ａは文字列「ＣＯＮＴ、」及びそれに続けて認証ＩＤと認証パスワードを、そして命令対象である子機２ｂのアウトレット番号と命令の内容（アウトレット命令）をそれぞれ記載する。その後データをクエリとしてパスに添付した後に暗号化し、親機２ａはＨＴＴＰＳリクエストを送信する。なおアウトレット命令の形式は、｛アウトレット番号（１バイト）、アウトレットの出力情報（１バイト）｝の形式になる。本明細書ではアウトレットＯｎ・Ｏｆｆ指示は同時に一つのアウトレットしか操作することを想定していないため、１つのコマンド（ＨＴＴＰリクエスト）で２つのアウトレットを操作することを考えていない。しかし、一つのコマンドに複数のアウトレット命令を含ませても良い。

【0181】

最後に、親機２ａによるＨＴＴＰＳレスポンスの受信について説明する。
子機の各モジュールＳＷ２～ＳＷ４が子機のＨＴＴＰモジュールＳＷ１に返した戻り値の暗号化後のものが親機２ａへのＨＴＴＰレスポンスとして戻される。従って、その値をどのように処理するかは親機２ａ側の設計に委ねられると言える。以下は取り扱いの例であるが、これに拘るモノではない。

【0182】

（生存確認に関するＨＴＴＰレスポンスの受信）
既述の通り、生存確認のＨＴＴＰレスポンスのメッセージボディには、
「ＡＬＩＶＥ」
のみが添付される。他はタイムアウトのみなので、この「ＡＬＩＶＥ」に対してのみ対応を考えればよい。
親機２ａによる復号化後、「ＡＬＩＶＥ」が戻っていることが確認できれば、親機２ａは対象子機が生きていることを認識する。次に親機２aは状態監視コマンドとしてのＨＴＴＰリクエストを該当する子機に要求することが一般的であるが、設計事項でありどのような処理を続けても良い。

【0183】

（状態監視に関するＨＴＴＰレスポンスの受信）
これまた既述の通り、状態監視に関するＨＴＴＰリクエストの応答であるＨＴＴＰレスポンスのメッセージボディには、
「ＲＥＳＰ、１のアウトレット情報、２のアウトレット情報…」
と言う形の暗号化後のデータが添付される。そして、上記１のアウトレット情報は｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝のデータフィールド構成となる。

【0184】

これを、子機ごとかつアウトレットごとに構文解析し、自身のメモリに記憶する。記憶の形式は（親機のメモリ容量）で説明したので、そちらを参酌されたい。

【0185】

（アウトレットＯｎ・Ｏｆｆに関するＨＴＴＰレスポンスの受信）
子機２ｂから戻ってくるアウトレットＯｎ・Ｏｆｆに関するＨＴＴＰレスポンスのメッセージボディには次のようなデータが含まれている。
◆ＲＥＳＵＬＴ、ＤＯＮＥ
◆ＲＥＳＵＬＴ、ＥＲＲＯＲ、０
◆ＲＥＳＵＬＴ、ＥＲＲＯＲ、１
この場合でも親機２ａは復号化後のメッセージボディを構文解析する。
「ＲＥＳＵＬＴ、ＤＯＮＥ」が戻ってきた際には親機２ａの指示通りに子機が処理を行ったという事になる。従って、それを反映させるべく自身のメモリに記憶した該当する子機２ｂのデータを修正する。この際、親機２ａ側が自身の判断でメモリを修正しても良いし、状態監視に関するＨＴＴＰリクエストを発行して、該子機に関する情報すべてを書き換えても良い。

【0186】

「ＲＥＳＵＬＴ、ＥＲＲＯＲ、０」の場合、子機２ｂの内部処理がうまく実行されなかった場合になる。この場合は、再び該子機に対して状態監視に関するＨＴＴＰリクエストを発行することが一般的であるが、設計事項であり、どのような処理を続けても良い。

【0187】

「ＲＥＳＵＬＴ、ＥＲＲＯＲ、１」の場合、子機２ｂの該当アウトレットがビジーだったことを示す。この場合は、再び該子機に対して状態監視に関するＨＴＴＰリクエストを発行することが一般的であるが、設計事項であり、どのような処理を続けても良い。

【0188】

いずれにしても、親機２ａは必ずＨＴＴＰリクエストを発行するため、ＨＴＴＰレスポンスを受け取ることが必須となる。また、受け取った結果から次に何をするかも親機２ａ側の処理であるため、親機側での実装が必要になる。

【0189】

最後に親機２ａの情報をどのように活用するか説明する。
親機２ａが収集した子機２ｂ及びその子機のアウトレットに関する情報は親機２ａ自身が用いるだけでなく監視用ＰＣ１に送り表示することでユーザに提供することが可能になる。
また親機２ａが上記のＨＴＴＰリクエストを周期的に各子機へ発行し、自動監視及び自動制御を行うことも可能である。

【0190】

このようにすることで、遠隔地にある子機及び子機に接続されたネットワーク機器の監視を可能にし、結果大規模なネットワーク環境の管理を可能ならしめる。

【0191】

（第２の実施の形態）
次に本発明の第２の実施の形態について説明する。
本発明においては、親機２ａと子機２ｂの間はＨＴＴＰで通信を行う。従って、１の子機に複数の親機が接続しても他の親機が存在することによって生じる問題は起きない。

【0192】

図１５は、本発明の第２の実施の形態に係るトポロジの図である。
本図では、インターネット９を挟んで２つの親機２ａが接続されている。またこれらにインターネット７経由で、監視用ＰＣ１がこれら２つの親機２ａに接続する。

【0193】

第１の実施の形態でも述べたが、子機側はリアクションをするのみであるので、親機側のＩＰアドレス等は覚える必要はない。また、ＨＴＴＰは「記憶を持たない通信方式」であり、通信時の状況にのみ左右されるのでこのような運用をすることができる。

【0194】

複数の親機に同じ機能を提供することで監視及び子機制御を容易に二重化でき、障害に強い環境を提供することが可能になる。

【0195】

また、一方の親機が再起動等の実行を行い、他方の親機が監視用ＰＣ１に情報を提供することで、処理を分担することが可能になる。

【0196】

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更が可能であることは言うまでもない。

【0197】

例えば、上記ではＨＴＴＰＳリクエストのリクエスト行のパスのクエリストリングの先頭に位置する識別子（例：ＳＴＡＴＵＳ）によって生存確認、状態監視、アウトレットＯｎ・Ｏｆｆの識別をなしていた。これに代えて、使用しないとしていたメッセージボディにこれらを付すことも可能である。

【0198】

また上記では、通信方式としてＨＴＴＰ＋ＴＳＬ方式を用いるとしているが、ＨＴＴＰ方式を用いることも本発明の射程に含まれる。また、ＨＴＴＰリクエストメソッドとしてＧＥＴメソッドを用いるとしているが、ＰＯＳＴメソッドで処理を行うことも本発明の射程に含まれることは言うまでもない。

【0199】

また、上記では、親機が複数の子機を管理する場合１のテーブル（データフォーム）で管理していた。しかし、子機ごとにテーブルを作成し管理することも本発明の射程に含まれる。

【0200】

また上記では状態監視モジュールＳＷ３が返信するアウトレット情報を｛アウトレット番号（１バイト）、アウトレットの特性情報（２バイト）、アウトレットの出力情報（１バイト）｝という固定長バイト表記で表した。これを｛Ｎｕｍｂｅｒ＝１，Ｔｙｐｅ＝５，Ｓｔａｔｕｓ＝Ｏｎ｝（注：Ｎｕｍｂｅｒはアウトレット番号、Ｔｙｐｅはアウトレットの特性情報、Ｓｔａｔｕｓはアウトレットの出力情報）のように可変長テキスト表記に変更することも可能である。同様に親機２ａから子機２ｂに送るアウトレットＯｎ・Ｏｆｆ指示のアウトレット命令を｛Ｎｕｍｂｅｒ＝１，Ｏｒｄｅｒ＝Ｏｎ｝（注：Ｎｕｍｂｅｒはアウトレット番号、Ｏｒｄｅｒはアウトレットコマンド）のような可変長テキスト表記にしても良い。

【0201】

また上記ではＩＰｖ４前提で説明したが、ＩＰｖ６での実装も本発明の射程に含まれる。

【産業上の利用可能性】

【0202】

本発明はネットワーク機器の監視装置に適用可能である。また、ルータや課金サーバ、ＨＴＴＰサーバだけでなく、他のネットワーク機器を監視対象としても良いことは言うまでもない。

【符号の説明】

【0203】

１：監視用ＰＣ、
２：ネットワーク機器監視装置、
２ａ：親機、
２ｂ、２ｃ：子機、
３：監視対象Ａ、
４：監視対象Ｂ、
７、８：ローカルネットワーク、
９：インターネット、
２ｂ－０１、２ｂ－０２、２ｂ－０３、２ｂ－０４、２ｂ－０５、２ｂ－０６：アウトレット、
２ｂ－１１：ＬＡＮポート、
２ｂ－１２：電源ケーブル、
１０１：ＣＰＵ、
１０２：バスコントローラ、
２０１：メモリ、
２０２：周辺用バスコントローラ、
３０１：ＬＡＮ Ｉ／Ｆ、
３０２：ＬＥＤコントローラ、
３０３：リレーコントローラ、
３１１、３１２，３１３：リレー、
３２１、３２２、３２３：コンセント。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】