(57)【要約】【課題】ネットワーク未対応機器の情報管理は人手を前提とする。【解決手段】ネットワーク対応機器に割り振られている固有のオブジェクトＩＤに対し、当該ネットワーク対応機器が直接又は外部装置を経由して間接的に収容する１つ又は複数のネットワーク未対応機器に固有のデバイス番号を付加して構成したＩＤを、ネットワーク未対応機器に固有の仮想オブジェクトＩＤとして定義する。この仮想オブジェクトＩＤにオブジェクトを対応付けることにより、仮想オブジェクトＩＤを通じてネットワーク未対応機器の情報を個別に又は一括して収集することが可能となる。【選択図】図１
2006201897.tif 000002
【特許請求の範囲】
【請求項１】
１つ又は複数台のネットワーク未対応機器と、当該ネットワーク未対応機器を直接又は外部装置を経由して間接的に収容するネットワーク対応機器とで構成される混成システムであって、
前記ネットワーク対応機器が、
自装置に割り振られている固有のオブジェクトＩＤに対し、各ネットワーク未対応機器に固有のデバイス番号を付加して構成したＩＤを、個々のネットワーク未対応機器に固有の仮想オブジェクトＩＤとして保持する
ことを特徴とするネットワーク未対応機器とネットワーク対応機器とで構成される混成システム。
【請求項２】
請求項１に記載の混成システムにおいて、
前記仮想オブジェクトＩＤは、その一部に、各ネットワーク未対応機器に固有のステータス情報を含む
ことを特徴とする混成システム。
【請求項３】
請求項２に記載の混成システムにおいて、
前記仮想オブジェクトＩＤを構成するデバイス番号は、管理対象として定義された状態情報で与えられ、
前記仮想オブジェクトＩＤを構成するステータス情報は、機器を識別する情報で与えられる
ことを特徴とする混成システム。
【請求項４】
請求項２に記載の混成システムにおいて、
前記仮想オブジェクトＩＤを構成するデバイス番号は、機器を識別する情報で与えられ、
前記仮想オブジェクトＩＤを構成するステータス情報は、管理対象として定義された状態情報で与えられる
ことを特徴とする混成システム。
【請求項５】
請求項１に記載の混成システムは、
ＳＮＭＰ（Simple Network
Management Protocol）によりシステム管理を実現する
ことを特徴とする混成システム。
【請求項６】
自装置に割り振られている固有のオブジェクトＩＤに対し、直接又は外部装置を経由して収容する１つ又は複数台のネットワーク未対応機器に固有のデバイス番号を付加して構成したＩＤを、個々のネットワーク未対応機器に固有の仮想オブジェクトＩＤとして保持する記憶領域を有する
ことを特徴とするネットワーク未対応機器の管理機能付きネットワーク対応機器
【請求項７】
ネットワーク対応機器に割り振られている固有のオブジェクトＩＤに対し、当該ネットワーク対応機器が直接又は外部装置を経由して間接的に収容する１つ又は複数のネットワーク未対応機器に固有のデバイス番号を付加して構成したＩＤを、個々のネットワーク未対応機器の仮想オブジェクトＩＤとして保持し、前記ネットワーク未対応機器を仮想的にネットワーク対応機器として管理する
ことを特徴とするネットワーク未対応機器の管理方法。
【請求項８】
ネットワーク対応機器に割り振られている固有のオブジェクトＩＤに対し、当該ネットワーク対応機器が直接又は外部装置を経由して間接的に収容する１つ又は複数のネットワーク未対応機器に固有のデバイス番号を付加したデータ構造
を有することを特徴とするネットワーク未対応機器に固有の仮想オブジェクトＩＤのデータ構造。
【発明の詳細な説明】
【技術分野】
【０００１】
発明の一つの形態は、ネットワーク未対応機器とネットワーク対応機器との混成システムに関する。また、発明の一つの形態は、混成システムを構成する管理機能付きネットワーク機器に関する。また、発明の一つの形態は、混成システムにおけるネットワーク未対応機器の管理方法に関する。また、ネットワーク未対応機器のネットワーク上での管理を実現する仮想オブジェクトＩＤのデータ構造に関する。
例えば、ネットワークシステムの管理プロトコルには、ＳＮＭＰ（Simple Network Management Protocol）を適用するが、これに限らない。
【背景技術】
【０００２】
現在主流のネットワーク管理プロトコルにＳＮＭＰがある。現在、ＳＮＭＰは、ネットワーク・インターフェースを有するルーター、スイッチ、サーバー、プリンタその他のコンピュータ関連機器に主に搭載され、これら機器のネットワーク（ＷＡＮ、ＬＡＮ）経由での遠隔監視や保守等に利用されている。
実際、システムの停止が基本的に許されない金融システムや基幹ネットワークシステムの分野では、システムの動作状況や不具合の発生を遠隔地より常時監視し、必要に応じてサポート（修理、保守）を実行するサービスが、ＳＮＭＰの機能を用いて提供されている。
そのためか、ネットワーク・インターフェースを有するコンピュータ機器は、ＳＮＭＰを使用するためのエージェント（管理対象となる側の機器に常駐するソフトウェア）をデフォルトで搭載することも少なくない。また、各種のオペレーションシステムでも、ＳＮＭＰの機能は、標準で搭載されている。
【特許文献１】特開２００１−３４４１３０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
現在、コンピュータ以外の分野でも、ネットワークへの対応が課題とされており、ＳＮＭＰへの対応が進むと考えられる。その一方で、これらの分野では、ネットワークへの完全対応が実現するまでの過渡期において、ネットワーク未対応機器とネットワーク対応機器が混在することが予想される。
例えば、放送用機器の分野は、ネットワーク化への過渡期に位置する。実際、ネットワークやＳＮＭＰに対応した機材は未だ少なく、それらの機材管理は従来通り人手に頼っているのが現状である。具体的には、管理人が本体機器まで実際に移動し、シリアル番号と使用時間を確認する作業が必要であった。
【０００４】
この作業は、経済的にも時間的にも多くの負担を要求する。実際、多数の機材を使用するキー局では、ネットワーク未対応機器の管理費用が非常に大きくなっている。また、遠隔地に支局を有し、その支局に機材を配置している場合、機材へのアクセスだけでも（すなわち、移動だけでも）大変な手間を必要とする。それだけでなく、複数の機材の使用状況や経時変化を知るのは、かなり大変な作業と費用を必要とする。
このように、放送用機器の分野では、機材の管理に多くの負担を要求する一方、サポートビジネスも成立できない状況にある。
【課題を解決するための手段】
【０００５】
発明者らは、以上の技術的課題に着目し、ネットワーク未対応機器をネットワーク経由で管理可能にできる仕組みを提案する。すなわち、ネットワーク対応機器に、以下の管理機能を搭載する仕組みを提案する。
ここでの管理機能とは、ネットワーク対応機器に割り振られている固有のオブジェクトＩＤに対し、各ネットワーク未対応機器に固有のデバイス番号を付加して構成したＩＤを、個々のネットワーク未対応機器に固有の仮想オブジェクトＩＤとして保持する機能をいう。
なお、オブジェクトＩＤとは、管理対象とする個々の情報（オブジェクト）に割り振られる識別子をいう。
【発明の効果】
【０００６】
この技術手法を採用すれば、仮想オブジェクトＩＤを通じてネットワーク未対応機器の情報を個別に又は一括して収集することが可能となる。すなわち、ネットワーク未対応機器をネットワーク対応機器と全く同じ条件で管理することが可能となる。
また、仮想オブジェクトＩＤを、ネットワーク対応機器に固有のオブジェクトＩＤにネットワーク未対応機器に固有のデバイス番号を付加して構成することにより、デバイス番号の変更だけで、複数台のネットワーク未対応機器の情報を効率よく収集できる。
【発明を実施するための最良の形態】
【０００７】
以下、発明に係る技術手法を採用する実施形態例を説明する。
なお、本明細書で特に図示又は記載されない部分には、当該技術分野の周知又は公知技術を適用する。
また以下に説明する実施形態は、発明の一つの実施形態であって、これらに限定されるものではない。
【０００８】
（Ａ）仮想オブジェクトＩＤの構造
図１に、仮想オブジェクトＩＤの構造例を示す。図１では、２つの構造例を示す。
いずれの構造例も、エージェント機能が常駐するネットワーク対応機器のオブジェクトＩＤにユニークな番号が付加した構造を採る。
図１（Ａ）は、エージェント機能が常駐するネットワーク対応機器のオブジェクトＩＤの後尾に、管理対象として定義された状態情報を表すデバイス番号、機器を識別する情報を表すステータス情報を付加する場合を表している。
【０００９】
図１（Ｂ）は、エージェント機能が常駐するネットワーク対応機器のオブジェクトＩＤの後尾に、機器を識別する情報を表すデバイス番号、管理対象として定義された状態情報を表すステータス情報を付加する場合を表している。
管理対象として定義された状態情報には、例えば機器の動作状態、設定状態、過去の履歴その他の機器の動作に関連した動的情報、機器の設置場所、連絡先その他の機器に関する静的情報がある。
機器を識別する情報を表すデバイス番号には、例えばモデル名、シリアル番号その他の情報がある。
【００１０】
図２に、仮想オブジェクトＩＤの具体例を示す。図２は、ネットワーク未対応機器がＶＴＲの場合について表している。なお、図２に示すデータ構造は、図１（Ａ）に対応する。
従って、図２の場合、エージェント機能が常駐するネットワーク対応機器のオブジェクトＩＤは、「１．３．６．１．４．１．１２２．８５０１．４．２．１．１」の部分である。そして、デバイス番号は、オブジェクトＩＤに続く「１」〜「２７」の部分である。また、ステータス情報は、「＊」の部分である。なお、「＊」には、例えば管理するステータス数に応じた自然数が割り当てられる。従って、この例であれば、モデル名が１つの場合、ステータス情報に対応する最後桁の数は、「１」となる。
【００１１】
図１（Ａ）に示すデータ構造の場合、以下のような利点が認められる。まず、ネットワーク対応機器に複数のネットワーク未対応機器が収容される場合にも、複数のネットワーク未対応機器に共通する状態情報には同じＩＤを割り当てることができる。ネットワーク未対応機器に応じた情報の違いは、ステータス情報の違いにより表現できるためである。勿論、図１（Ｂ）に示すデータ構造の場合には、デバイス番号を除いて同じＩＤを割り当てることができる。
ネットワーク未対応機器の違いは、ステータス情報（図１（Ａ）の場合）又はデバイス番号（図１（Ｂ）の場合）で特定されるため、接続されるネットワーク未対応機器の数を考慮せずに、ＩＤの定義が可能になることである。
【００１２】
また、このデータ構造は、マネージャ（情報を管理する側の機器に常駐するソフトウェア）による情報の収集を効率化できる利点がある。例えば、ネットワーク未対応機器が複数台収容されている場合、マネージャは、必要とする情報に対応する仮想オブジェクトＩＤのうち機器を識別する桁だけを変更するだけで、異なる機器の情報を収集することができる。
図３に一例を示す。図３は、同じネットワーク対応機器に収容される４台のネットワーク未対応機器から“バーチャルマシーンタイプ”に関する情報をそれぞれ収集する場合における仮想オブジェクトＩＤの発生例である。なお、仮想オブジェクトＩＤは、図１（Ａ）に示すタイプである。
【００１３】
すなわち、「１．３．６．１．４．１．１２２．８５０１．４．２．１．１．３」の部分が“バーチャルマシーンタイプ”の情報を識別するＩＤを表している。この場合、最下位桁であるステータス情報を「１」→「２」→「３」→「４」に変更するだけで、全てのネットワーク未対応機器の情報を連続的に取得できる。
この作業には、ＩＰ（Internet Protocol ）アドレスの変更も、ポート番号の変更も必要としない。このため、仮想オブジェクトＩＤの発生を非常に効率化できる。
勿論、同じ動作を適用できるポーリングにも有効である。
また、トラップ（オブジェクトの情報変化を監視し、マネージャに通知する機能）の実行についても、機器を識別する桁の変更だけで複数のネットワーク未対応機器の情報を効率的に監視できる。
【００１４】
（Ｂ）システム形態例
図４に、システム形態例を示す。図４は、エージェント機能が常駐するネットワーク対応機器１に対し、１台のネットワーク未対応機器３が直接的に収容された接続形態を表している。この場合、ネットワーク未対応機器３に対応する仮想オブジェクトＩＤのイメージは図２と同じである。
図５に、他のシステム形態例を示す。図５は、エージェント機能が常駐するネットワーク対応機器１が、ネットワーク通信機能を搭載したハブ５を経由してネットワーク未対応機器３を間接的に収容する接続形態を表している。
【００１５】
この例の場合、ハブ５は、ネットワーク対応機器１との通信をネットワーク経由で実現し、ネットワーク未対応機器３との通信をシリアルポート経由で実現している。すなわち、ハブ５は、ネットワーク通信方式のデータ形式とシリアル通信方式のデータ形式を相互に変換するデバイスとして機能する。
従って、ハブ５は固有のオブジェクトＩＤを有するものの、ネットワーク未対応機器３の仮想オブジェクトＩＤは、エージェント機能が常駐するネットワーク対応機器１に固有のオブジェクトＩＤを用いて定義する。
この場合、仮想オブジェクトＩＤへのアクセスは、仮想オブジェクトＩＤをハブ５のポートに対応付けたテーブルを用いて実現する。図６に、対応テーブル例を示す。この対応テーブルを用いることで、特定の非ＳＮＭＰ機器１７にアクセスすることができる。
【００１６】
（Ｃ）ＳＮＭＰに対応したシステムへの応用例
（Ｃ−１）全体構成
図７に、ネットワーク対応機器とネットワーク未対応機器の混合システム例を示す。この混合システムは、ネットワーク・インターフェースにはイーサネット（登録商標）を使用するものとする。また、ネットワーク１１上に存在するネットワーク対応機器をネットワーク経由で管理するためのプロトコルにはＳＮＭＰを使用するものとする。
ここでは、ＳＮＭＰの手順に基づいて監視対象とする機器の情報をシステム全体から収集する機能を搭載するネットワーク対応機器をマネージャ端末１３と記す。
また、自装置が直接又は間接的に収容するネットワーク未対応機器のエージェントとして仮想的に機能するネットワーク対応機器をエージェント端末１５と記す。勿論、エージェント端末１５は、ＳＮＭＰの手順に基づいてマネージャ端末１３との通信を実行する。
【００１７】
すなわち、エージェント端末１５は、（１）マネージャ端末１３から要求のあった情報を取得して応答する機能、（２）マネージャ端末１３から要求のあった設定変更を実行し、その結果を応答する機能、（３）状態が変化した情報をマネージャ端末１３に通知する機能を提供する。１つ目と２つ目の機能は、定期的なポーリング機能に対応する。また
、３つ目の機能は、トラップ機能に対応する。図８に、この通信イメージを示す。
なお、この応答又は通知機能は、マネージャ端末１３とエージェント端末１５が共通に有する管理情報ベース（ＭＩＢ：Management Information Base ）によって実行される。管理情報ベースには、監視対象とする機器の情報（オブジェクト）が、オブジェクトＩＤ又は仮想オブジェクトＩＤに関連付けて管理されている。
【００１８】
また、図７は、ネットワーク未対応機器（非ＳＮＭＰ機器）１７をネットワークに収容するネットワーク対応機器をプロトコル変換ハブ１９と記す。このプロトコル変換ハブ１９は、シリアル通信規格であるＲＳ２３２Ｃを通じてネットワーク未対応機器（非ＳＮＭＰ機器）１７と接続されている。
プロトコル変換ハブ１９は、イーサネット（登録商標）上のデータ形式とＲＳ２３２Ｃ上のデータ形式を相互変換する機能を搭載する。
プロトコル変換ハブ１９は、コマンドを非ＳＮＭＰ機器１７に与え、その応答を受け取ることにより、非ＳＮＭＰ機器１７のシリアル番号、仕向け等の静的情報、ステータス等の動的情報を取得する。図９に、この通信イメージを示す。
【００１９】
なお、プロトコル変換ハブ１９は、非ＳＮＭＰ機器１７から受け取った情報を内部バッファに保存する。内部バッファの情報は、エージェント端末１５からのポーリングによって読み出され、エージェント端末１５内の取り込まれる。図１０に、この通信イメージを示す。
情報の格納場所は、その内容によって異なる。例えば、ある情報はデータベースに格納され、ある情報はログファイルに書き込まれる。このように格納された情報（オブジェクト）が、仮想オブジェクトＩＤを通じてマネージャ端末１３に公開される。
なお、プロトコル変換ハブ１９もオブジェクトＩＤを有している。従って、プロトコル変換ハブ１９は、マネージャ端末１３とＳＮＭＰを通じて通信できる。ただし、この形態例に係るプロトコル変換ハブ１９は、非ＳＮＭＰ機器１７の内部情報を仮想オブジェクトＩＤに対応付ける機能（ソフトウェア）を搭載していないものとする。この形態例の場合、プロトコル変換ハブ１９は、専ら通信データのプロトコル変換に使用される。
【００２０】
（Ｃ−２）エージェント端末の内部構成
図１１に、エージェント端末１５の内部構成例を示す。この形態例に係るエージェント端末１５は、コンピュータをベースに構成されている。すなわち、エージェント機能は、オペレーションシステム１５１上で動作する各種のモジュールと記憶領域とで実現される。
ＳＮＭＰサービスモジュール１５３は、マネージャ端末１３との間でＳＮＭＰに基づくサービスを提供するソフトウェアである。このＳＮＭＰサービスモジュール１５３は、全体としてエージェントとしての機能を提供する。
【００２１】
ＳＮＭＰサービスモジュール１５３には、２つのサブモジュールが含まれる。仮想ＭＩＢ用モジュール１５３ＡとメーカＭＩＢ用モジュール１５３Ｂの２つである。
仮想ＭＩＢ用モジュール１５３Ａは、非ＳＨＭＰ機器１７の内部情報（オブジェクト）を管理情報ベース（ＭＩＢ）形式に変換するサブモジュールである。
メーカＭＩＢ専用モジュール１５３Ｂは、エージェント端末１５の内部情報をメーカ独自の管理情報ベース（ＭＩＢ）形式に変換するサブモジュールである。
なお、管理情報ベースの生成に必要な情報（例えば、ステータスデータ１５５Ａ、カレントエラー１５５Ｂ、プロキシ製品情報１５５Ｃ）は、端末内の各記憶領域から収集される。
【００２２】
プロキシモジュール１５７は、エージェント端末全体の動作を制御するソフトウェアであると共に、ネットワーク経由で接続された機器の管理や制御を実現するソフトウェアである。例えば、非ＳＮＭＰ機器１７に対する要求の送信や当該要求に対する応答の受信を実現する。なお、非ＳＮＭＰ機器１７との通信は、ネットワーク１１上のプロトコル変換ハブ１９を経由して実現される。
ポーリングモジュール１５９は、プロトコル変換ハブ１９を通じて非ＳＮＭＰ機器１７の内部情報（オブジェクト）を収集するソフトウェアである。ポーリングは、ＴＣＰ／ＩＰを用いて実現する。
【００２３】
データベース１６１は、ポーリングモジュール１５９で取得した非ＳＮＭＰ機器１７の情報を記憶する記憶領域である。例えば、製品情報、デバイス管理情報、ＴＳ情報、ポーリング間隔、しきい値情報、ステータス情報等が記憶される。
なお、エージェント端末１５には、セットアップデータ１６３Ａ、デバイス情報履歴ログ１６３Ｂ、プロキシ情報履歴ログ１６３Ｃを保持する記憶領域も設けられている。ログ情報は、専ら端末内部の管理に用いられる。
閲覧用データ生成部１６５は、ＨＴＭＬ文書や画像などの情報を用いたＧＵＩ（Graphical User Interface）の生成に用いられるソフトウェアである。
ウェブサーバー部１６７は、ネットワークに接続されたクライアント端末からの要求に応じて情報を送信するソフトウェアである。
【００２４】
（Ｄ）動作例
（Ｄ−１）初期動作
システムの動作が開始すると、プロトコル変換ハブ１９が各シリアルポートに対してコマンドを送信する。シリアルポートに非ＳＮＭＰ機器１７が接続されている場合、非ＳＮＭＰ機器１７はレスポンスを返す。収集された静的情報や動的情報は、プロトコル変換ハブ１９の内部バッファに保存される。
エージェント端末１５は、ポーリングモジュール１５９を通じてプロトコル変換ハブ１９にアクセスし、プロトコル変換ハブ１９に保存されている情報を取り込む。取り込まれた情報は、データベース１６１やカレントエラーログ１５３Ｂに書き込まれる。
仮想ＭＩＢ用モジュール１５３Ａは、非ＳＮＭＰ機器１７から収集した情報を、非ＳＮＭＰ機器１７に固有の仮想オブジェクトＩＤに対応付け、管理情報ベース（ＭＩＢ）形式に変換する。
【００２５】
（Ｄ−２）通常時の動作
初期設定動作で収集されたオブジェクトは、マネージャ端末１３から定期的に実行されるポーリングに対する応答として送信される他、マネージャ端末１３からの個別の情報に対する応答としても送信される。
例えば、非ＳＮＭＰ機器１７が接続されているプロトコル変換ハブ１９のホスト名を知りたい場合、マネージャ端末１３は、仮想オブジェクトＩＤの「１．３．６．１．４．１．１２２．８５０１．４．２．１．１．４．１」を指定する。なお、最終桁の「１」は、ステータス情報である。
このとき、エージェント端末１５は、仮想オブジェクトＩＤの「１．３．６．１．４．１．１２２．８５０１．４．２．１．１．４．１」に対応付けられた情報を応答として送信する。
なお、ある非ＳＮＭＰ機器１７に関する全ての情報（オブジェクト）を取得したいのであれば、デバイス番号（最下位桁から２つ目）の値を昇順に更新すれば良い。
【００２６】
（Ｄ−３）非ＳＮＭＰ機器が抜き差しされた場合の動作
前述の通り、マネージャ端末１３は、定期的なポーリング動作によりプロトコル変換ハブ１９経由で非ＳＮＭＰ機器１７の状態を監視している。
しかし、実際の運用では、非ＳＮＭＰ機器の取り外し、再接続、変更が発生する。
（１）非ＳＮＭＰ機器が取り外される場合
この場合、取り外し前までは応答のあったシリアルポートからの応答が受信されなくなる。すなわち、通信タイムアウトが発生する。ある一定時間をすぎても通信が回復しない場合、エージェント端末１５は、非ＳＮＭＰ機器が非接続であると認識する。この認識結果は、ＳＮＭＰサービスモジュール１５３を通じてマネージャ端末１３に通知される。この通知は、勿論、ＳＮＭＰにより実行される。
【００２７】
（２）同じ非ＳＮＭＰ機器が同じシリアルポートに再接続された場合
マネージャ端末１３は、非ＳＮＭＰ機器１７が非接続状態になっても、定期的にポーリング信号を発生させ、通信の再開を試行する。従って、非ＳＮＭＰ機器１７が再接続されれば、その情報が再び収集され、マネージャ端末１３に送信される。
（３）異なる非ＳＮＭＰ機器と入れ替えられた場合
マネージャ端末１３は、非ＳＮＭＰ機器１７の機種情報（モデル名他）をプロトコル変換ハブ１９経由で定期的に取得する。
このため、前回取得した情報と今回取得した情報とが異なる場合、新たな非ＳＮＭＰ機器１７が接続されたと判断し、同シリアルポートに接続されている非ＳＮＭＰ機器に関する全ての情報を変更する。
【００２８】
（Ｅ）形態例の効果
以上説明したように、仮想オブジェクトＩＤを用いることにより、シリアルポート等の通信ポートを有する機器であれば、非ＳＮＭＰ機器をＳＮＭＰ機器と同様にネットワーク経由で監視できる。
すなわち、たとえ監視対象とする情報が非ＳＮＭＰ機器に関するものであっても、マネージャ端末１３によるネットワーク経由での管理を実現できる。
勿論、監視対象とする非ＳＮＭＰ機器の台数が複数台の場合にも適用できる。これにより、従来から使用されてきた非ＳＮＭＰ機器とＳＮＭＰ機器との一元管理が実現される。
【００２９】
このことは、資材や機材の運用管理がより画一的に、簡単に、細かく、敏速にできることを意味する。よって、資材や機材の運用状況に応じた保守点検のスケジュール化など、現場でのサポートコストの抑制を実現できる。
また、メーカーやサプライヤー側としても遠隔地からの機材管理も可能となり、サポートに必要な工数の削減を実現できる。
また、監視センターによる遠隔監視ビジネス、それに基づいた保守サービス、定期点検など新しいサービスビジネスも実現できる。
また、顧客においても、機材の管理コストを削減でき、監視センターなどへのアウトソーシング化も実現できる。
【００３０】
（Ｆ）他の形態例
（ａ）前述の形態例では、エージェント機能をソフトウェアとして実現する場合について説明した。しかし、これらの機能はハードウェア的に実現することもできる。また、ソフトウェアとして実現する場合でも、アプリケーションとして実現するのではなく、ファームウェアとして実現することもできる。
（ｂ）前述の形態例では、１台の非ＳＮＭＰ機器１７がプロトコル変換ハブ１９に接続されている場合について説明したが、勿論、複数台の非ＳＮＭＰ機器が接続される場合にも適用できる。
また、プロトコル変換機能を搭載していれば、非ＳＮＭＰ機器１７を収容する機器は、プロトコル変換ハブ１９に限らない。
【００３１】
（ｃ）前述の形態例では、ネットワーク未対応機器を直接又は間接的に収容するネットワーク対応機器に固有のオブジェクトＩＤの最下位桁にデバイス番号とステータス情報を付加する場合について説明した。
しかし、デバイス番号とステータス情報を付加する位置はこれに限らない。また、付加する情報は、デバイス番号とステータス情報のいずれか一方でも良い。
（ｄ）前述の形態例には、発明の趣旨の範囲内で様々な変形例が考えられる。また、本明細書の記載に基づいて創作される各種の変形例及び応用例も考えられる。
【図面の簡単な説明】
【００３２】
【図１】仮想オブジェクトＩＤの構造例を示す図である。
【図２】仮想オブジェクトＩＤの具体例を示す図である。
【図３】仮想オブジェクトＩＤの発生例を示す図である。
【図４】システム形態例を示す図である。
【図５】他のシステム形態例を示す図である。
【図６】対応テーブル例を示す図である。
【図７】ネットワーク対応機器とネットワーク未対応機器の混合システム例を示す図である。
【図８】トラップ機能の通信イメージを示す図である。
【図９】コマンドとレスポンスによる通信イメージを示す図である。
【図１０】ポーリングによる通信イメージを示す図である。
【図１１】エージェント端末の内部構成例を示す図である。
【符号の説明】
【００３３】
１１      ネットワーク
１３      マネージャ端末
１５      エージェント端末
１７      非ＳＮＭＰ機器
１９      プロトコル変換ハブ
１５３    ＳＮＭＰサービスモジュール
１５３Ａ  仮想ＭＩＢ用モジュール
１５７    プロキシモジュール
１５９    ポーリングモジュール
１６５    閲覧用データ生成部
【図１】
2006201897.tif 000003
【図２】
2006201897.tif 000004
【図３】
2006201897.tif 000005
【図４】
2006201897.tif 000006
【図５】
2006201897.tif 000007
【図６】
2006201897.tif 000008
【図７】
2006201897.tif 000009
【図８】
2006201897.tif 000010
【図９】
2006201897.tif 000011
【図１０】
2006201897.tif 000012
【図１１】
2006201897.tif 000013