(57)【要約】【課題】  ネットワークデバイスのベンダーの判別処理、その後のデバイスの種別（機能）を判別するためのより良い管理手法が望まれている。【解決手段】  本発明は、ＳＮＭＰを利用して、ネットワーク上のデバイスをＭＩＢの値により管理する管理装置であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドをネットワーク上の対象デバイスに送信する送信手段と、応答として受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする。【選択図】  図７
2012164134.tif 000002
【特許請求の範囲】
【請求項１】
ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を利用して、ネットワーク上のデバイスをＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）の値により管理する管理装置であって、
ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、
前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信手段と、
前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする管理装置。
【請求項２】
前記判別手段は、前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドにより返却された値において、前記特定の機能を示すノードのＯＩＤを含まれている場合には前記対象デバイスが前記特定の機能を備えると判別し、前記特定の機能を示すノードのＯＩＤを含まれていない場合には前記対象デバイスが前記特定の機能を備えないと判別することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記特定の機能は、モデム機能またはプリンタ機能であることを特徴とする請求項１または２に記載の管理装置。
【請求項４】
前記管理装置でサポートするベンダーを登録したテーブルを保持する保持手段とを有し、
前記判別手段は、前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することで判別した前記対象デバイスのベンダーが前記テーブルに登録されていない場合には、前記特定の機能に関する判別を行わないことを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
【請求項５】
ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を利用して、ネットワーク上のデバイスをＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）の値により管理する管理装置における管理方法であって、
ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信工程と、
前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信工程と、
前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別工程とを有することを特徴とする管理方法。
【請求項６】
請求項１乃至４のいずれか１項に記載の手段としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を利用してネットワーク上のデバイスを管理する技術に関する。
【背景技術】
【０００２】
近年、ネットワークに接続された各種のデバイスを、ＳＮＭＰを利用して管理・監視するデバイス管理プログラムが数多く普及している。ＳＮＭＰによる管理の対象となるデバイスはＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）と呼ばれる管理情報データベースを持っており、デバイス管理プログラムは管理対象デバイスのＭＩＢに基づいて適切な設定を行うことによりデバイスを管理している。ＭＩＢにはインターネットに関する技術の標準を定める団体であるＩＥＴＦ（Ｉｎｔｅｒｎｅｔ  Ｅｎｇｉｎｅｅｒｉｎｇ  Ｔａｓｋ  Ｆｏｒｃｅ）が発行するＲＦＣ（Ｒｅｑｕｅｓｔ  Ｆｏｒ  Ｃｏｍｍｅｎｔ）で定義された標準ＭＩＢとデバイスのベンダーが独自に定義するプライベートＭＩＢが存在する。
【０００３】
近年普及しているデバイス管理プログラムの中には、標準ＭＩＢのみならず、複数のベンダーのプライベートＭＩＢをサポートするものも数多く存在している。このようなデバイス管理プログラムとしては、ｓｙｓＯｂｊｅｃｔＩＤと呼ばれるＭＩＢオブジェクトに格納されたオブジェクト識別子（以下、ＯＩＤ）を参照してベンダーの判別をおこなうものが知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０００−３３９２４７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ここで、１ベンダーが、異なるＭＩＢをサポートする複数の機種のデバイスを提供する場合がある。従来のデバイス管理プログラムでは、こういった場合、ベンダーの判別処理の後、より詳細にデバイスの種別を判別するための手続きが必要であった。
【０００６】
たとえば、複数のベンダーの複数の機種のデバイスが接続された大規模なネットワーク環境では、デバイス管理プログラムによる機種の判別処理に必要な送信パケットの数が増大してしまう。そのために、デバイス管理プログラムが動作する情報処理装置のパフォーマンス、およびシステム内のネットワークトラフィックに対する大きな障害となっていた。
【課題を解決するための手段】
【０００７】
そこで、本発明は、ＳＮＭＰ（Ｓｉｍｐｌｅ  Ｎｅｔｗｏｒｋ  Ｍａｎａｇｅｍｅｎｔ  Ｐｒｏｔｏｃｏｌ）を利用して、ネットワーク上のデバイスをＭＩＢ（Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ  Ｂａｓｅ）の値により管理する管理装置であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、前記対象デバイスより、ＧｅｔＮｅｘｔＲｅｑｕｅｓｔコマンドの応答としてのＧｅｔＲｅｓｐｏｎｓｅコマンドを受信する受信手段と、前記受信したＧｅｔＲｅｓｐｏｎｓｅコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする。
【発明の効果】
【０００８】
本発明によれば、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。
【図面の簡単な説明】
【０００９】
【図１】ネットワークシステムの構成図
【図２】デバイス監視サーバーの構成を示すブロック図
【図３】ネットワークシステムのブロック図
【図４】ＭＩＢの構成を示す概念図
【図５】ＳＮＭＰメッセージのデータ構成図
【図６】ＳＮＭＰのパケットの送受信の特徴を示すシーケンス図
【図７】デバイス管理プログラムにおけるベンダー、および、機能判別のフローチャート
【図８】管理対象デバイスのベンダー、および、機能を判別するための判別テーブル
【発明を実施するための形態】
【００１０】
以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、実施例においては、デバイス管理プログラムにより実現される処理の管理対象となるネットワークデバイスの例として、複合機能デバイスとしている。しかしながら、プリンタやスキャナを含む単機能のデバイスなどであっても、本実施例は適用可能である。
【００１１】
図１は、本実施例が適用されるネットワークシステムの構成例を示す図である。同図において、１００はローカルエリアネットワークである。ローカルエリアネットワーク１００には、管理装置１１０、および、複合機能デバイス１２０、１３０、１４０が接続されている。管理装置１１０では、デバイス管理プログラムが実行され、後述する手順によって複合機能デバイス１２０、１３０、１４０を管理しているものとする。
【００１２】
図２は、本実施例が適用される管理装置１１０の構成を示すブロック図である。なお、本実施例における管理装置１１０は一般的なパーソナルコンピューターの構成を持つものとする。
【００１３】
ＲＯＭ２０１若しくはハードディスク（ＨＤ）２１０に記憶されたデバイス管理プログラム（詳細後述）を実行するＣＰＵ２００を備える。さらに、ＣＰＵ２００は、システムバス２０３に接続された各デバイスを総括的に制御する。２０２はＲＡＭであり、ＣＰＵ２００の主メモリ、ワークエリア等として機能する。２０４はキーボードコントローラ（ＫＢＣ）であり、キーボード（ＫＢ）２０８や不図示のポインティングデバイス等からの指示入力を制御する。２０５はＤＩＳＰコントローラ（ＤＩＳＰＣ）であり、ディスプレイ（ＤＩＳＰ）２０９への表示を制御する。２０６はディスクコントローラ（ＤＫＣ）であり、ハードディスク（ＨＤ）２１０、フロッピー（登録商標）ディスクコントローラ（ＦＤ）２１１、ＣＤ−ＲＯＭドライブ（ＣＤ）２１２とのアクセスを制御する。２０７はネットワークインタフェースカード（ＮＩＣ）であり、ＬＡＮ１００を介して複合機能デバイス１２０、１３０、１４０と双方向にデータを授受する。なお、後述するすべての説明で特に断りのない限り、管理装置１１０で提供する機能の主体はＣＰＵ２００であり、ハードディスク（ＨＤ）２１０などに格納されるデバイス管理プログラムを実行することでそれら機能が実現されるものとする。また、デバイス管理プログラムは、ＣＤ−ＲＯＭなどの記憶媒体に格納された形で供給されても良く、ＣＤ−ＲＯＭドライブ２１２などによって記憶媒体からプログラムが読み取られ、ハードディスク（ＨＤ）２１０にインストールされる。ほかにも、デバイス管理プログラムはネットワークからダウンロードされる形で供給され、ハードディスク（ＨＤ）２１０にインストールされてもよい。
【００１４】
図３は、本実施例が適用されるネットワークシステムにおいて、管理装置１１０、および、複合機能デバイス１２０、１３０、１４０上で稼働するソフトウェア構成を説明するブロック図である。
【００１５】
枠３００内は、デバイス管理プログラムに関連するＳＮＭＰにより複合機能デバイス１２０、１３０、１４０を管理するＳＮＭＰマネージャーとしての機能モジュール群を示している。管理装置１１０において、デバイス管理プログラム３００、および、各モジュールは、ハードディスク（ＨＤ）２１０に保存されたファイルとして存在する。これらは実行時にＯＳやその他のモジュールによってＲＡＭ２０２にロードされ、ＣＰＵ２００により実行される実行形式ファイルである。
【００１６】
３０１は、ＵＩ制御モジュールであり、キーボード（ＫＢ）２０８や不図示のポインティングデバイス等からの指示入力をコマンドに変換し、全体制御モジュール３０２に送信するモジュールである。ＵＩ制御モジュール３０１はまた、後述のモジュールによる処理を経て複合機能デバイス１２０、１３０、１４０に対しておこなった処理の結果をＤＩＳＰコントローラ（ＤＩＳＰＣ）２０５を介してディスプレイ（ＤＩＳＰ）２０９に表示する。３０２は、全体制御モジュールであり、ＵＩ制御モジュール３０１から受信したコマンドを後述のデバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５に振り分ける制御をおこなうモジュールである。さらに、全体制御モジュールは、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の処理結果を受信して、必要に応じて変換し、ＵＩ制御モジュール３０１に通知する。
【００１７】
３０３はデバイス管理モジュールであり、ＵＩ制御モジュール３０１から指定された特定の複合機能デバイス１２０、１３０、１４０に対して詳細な情報を取得・設定するためのモジュールである。より詳細には、デバイス管理モジュール３０３はＳＮＭＰ制御部３０７を介して複合機能デバイスの名称や設置場所、さらには、各種のネットワーク情報を取得設定するために、復号機能デバイスのＭＩＢ情報の取得・設定をおこなうためのモジュールである。３０４は、デバイス探索モジュールであり、ＳＮＭＰ制御モジュール３０７を介してネットワークに接続された複合機能デバイス１２０、１３０、１４０を探索するモジュールである。本実施例においては、複合機能デバイスに実装が期待されるＭＩＢの情報を取得するため、ＳＮＭＰの”ＧｅｔＲｅｑｕｅｓｔ”をブロードキャストやユニキャストで送信し、正常にＭＩＢの情報を取得できたデバイスを管理対象の複合機能デバイスとして認識する。３０５は、デバイス監視モジュールであり、複合機能デバイス１２０、１３０、１４０の状態を示すＭＩＢ情報を、あらかじめ設定された間隔で定期的に取得し、複合機能デバイスの障害を検出するためのモジュールである。デバイス監視モジュール３０５はさらに、取得したＭＩＢ情報から複合機能デバイス１２０、１３０、１４０の障害を検出した場合、データベースモジュール３０６に障害の履歴情報を登録するとともに、ＵＩモジュール３０１に対して障害の発生を通知する。
【００１８】
３０６は、データベースモジュールであり、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の処理結果やＳＮＭＰ制御モジュール３０７が参照するＭＩＢ情報、その他、設定された各種のパラメータが保存される。３０７は、ＳＮＭＰ制御モジュールで、デバイス管理モジュール３０３、デバイス探索モジュール３０４、デバイス監視モジュール３０５の要求に応じてＭＩＢオブジェクトのハンドリング、ＳＮＭＰパケットの送受信などをおこなうためのモジュールである。
【００１９】
一方、ＳＮＭＰエージェント３１１は、複合機能デバイス１２０上で稼働し、ＭＩＢ情報モジュール３１２を参照して、ＳＮＭＰマネージャーから送信されたＳＮＭＰパケットに応答を返すプログラムである。ＳＮＭＰエージェント３２１、３３１、および、ＭＩＢ情報モジュール３２２、３３２はそれぞれ、複合機能デバイス１３０、１４０上で稼働し、それぞれ、ＳＮＭＰエージェント３１１、および、ＭＩＢ情報モジュール３１２と同様の構成を持つものとする。
【００２０】
図４は、ＭＩＢの構成を示す概念図である。ＭＩＢの構成はツリー構造で示され、各ノードはＭＩＢオブジェクトと呼ばれる。各ＭＩＢオブジェクトは、それぞれ、オブジェクト識別子（ＯＩＤ）と呼ばれるＩＤが割り当てられている。ＯＩＤは、木構造の階層ごとに割り当てられた枝番により表される。例えば、ＭＩＢオブジェクト４０７のＯＩＤは、「１．３．６．１．２．１．４３」のように表される。ＳＮＭＰマネージャーは、ＳＮＭＰエージェント３１１、３２１、３３１に対して、ＯＩＤを指定して機器の情報の取得及び設定変更を要求する。
【００２１】
また、ＭＩＢはエージェントの持つ機能により実装が異なっている。例えば、モデム機能を持つデバイス対しては、ＭＩＢオブジェクト４０６以下の葉ノードで示されるＭＩＢオブジェクトの実装が期待され、プリント機能を持つデバイスに対してはＭＩＢオブジェクト４０７以下のノードで示されるＭＩＢの実装が期待されている。さらに、ＭＩＢオブジェクト４０９以下は、デバイスのベンダーを示すＭＩＢオブジェクト４１０、４１１、４１２が定義され、これらベンダーを示すＭＩＢオブジェクト以下はプライベートＭＩＢと呼ばれ、各ベンダーが独自に定義するＭＩＢである。
【００２２】
図５は、ＳＮＭＰメッセージのデータ構造の一例を示す図である。
【００２３】
５００はＰＤＵ（Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）であり、後述のパラメータによって構成されるＳＮＭＰの基本的なデータユニットである。５０１は、ＰＤＵタイプフィールドであり、ＳＮＭＰのリクエストの種別を示すＩＤが設定される。ＳＮＭＰ  Ｖｅｒｓｉｏｎ１（以下、ＳＮＭＰｖ１）ではＰＤＵタイプとしては、”ＧｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”、”ＳｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＲｅｓｐｏｎｓｅ”、及び、”Ｔｒａｐ”が定義されている。これらのうち”Ｔｒａｐ”については、異なるデータ構造を持ち、本実施例においては説明を省略する。５０２は、リクエストＩＤフィールドである。リクエストＩＤフィールド５０２には、ＳＮＭＰマネージャーからの要求とＳＮＭＰエージェント３１１、３２１、３３１からの応答とを一意に識別するためのリクエストＩＤが格納される。
【００２４】
５０３は、エラーステータスフィールドであり、ＳＮＭＰマネージャーからのＳＮＭＰリクエストにＳＮＭＰエージェント３１１、３２１、３３１が正常に応答を返せなかった場合、その理由を示すコードを格納する領域である。ＳＮＭＰｖ１における代表的なエラーステータス５０３としては以下のものがある。なお、”ＧｅｔＲｅｓｐｏｎｓｅ”以外のＰＤＵでは、エラーステータス５０３にはｎｏＥｒｒｏｒが設定される。
（１）ｎｏＥｒｒｏｒ：正常終了
（２）ｔｏｏＢｉｇ：要求されたＳＮＭＰリクエストに対する応答がＰＤＵのサイズ制限を超えてしまう
（３）ｎｏＳｕｃｈＮａｍｅ：ＳＮＭＰリクエストで要求されたＭＩＢオブジェクトが実装されていない
（４）ｂａｄＶａｌｕｅ：”ＳｅｔＲｅｑｕｅｓｔ”で要求された値がＭＩＢの定義に矛盾している
（５）ｒｅａｄＯｎｌｙ：読み出しのみ可能なＭＩＢオブジェクトに対して”ＳｅｔＲｅｑｕｅｓｔ”が要求された
（６）ｇｅｎＥｒｒｏｒ：上記以外のエラーが発生した
【００２５】
５０４は、エラーインデックスフィールドである。ＳＮＭＰのＰＤＵ５００では、後述の変数バインディングリスト５０５（以下、ＶＢＬ５０５）において複数のＭＩＢオブジェクトの指定が可能である。エラーインデックスフィールド５０４に格納されるエラーインデックスは、これら複数のＭＩＢオブジェクトのうち、エラーが発生したＭＩＢオブジェクトを示す最も小さい値が格納される。また、エラーステータスがｎｏＥｒｒｏｒの場合、本エラーインデックスには０が設定される。５０５は、ＶＢＬ（Ｖａｒｉａｂｌｅ  Ｂｉｎｄｉｎｇ  Ｌｉｓｔ）フィールドであり、１以上のＭＩＢのＯＩＤ、および、その値が情報が格納されている。
【００２６】
５０６、５０８、５１０は、ＯＩＤフィールドであり、５０７、５０９、５１１は値フィールドである。ＯＩＤフィールド５０６、５０８、５１０には、各ＭＩＢオブジェクトに割り当てられた実際のＯＩＤの後にインスタンス識別子を付け加えた値が格納される。インスタンス識別子は、ＭＩＢオブジェクトが単一の値しか有さない場合には「０」が設定される。
【００２７】
一方、ＭＩＢオブジェクトがテーブル形式で複数の値を有する場合には、テーブル内の夫々の値に対して「１」以上の連続であるとは限られない数字により表されるインスタンス識別子が付与される。この場合に、従来では、ＰＤＵとして”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を用い、これを繰り返し呼び出すことにより、テーブル内の全ての情報を取得することが可能である。また、”ＧｅｔＲｅｑｕｅｓｔ”、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”の場合、値フィールド５０７、５０９、５１１にはＮＵＬＬが指定される。”ＳｅｔＲｅｑｕｅｓｔ”の場合、値フィールド５０７、５０９、５１１には、デバイス管理プログラム３００が複合機能デバイス１２０、１３０、１４０に対して設定する値が格納される。さらに、”ＧｅｔＲｅｓｐｏｎｓｅ”の場合、値フィールド５０７、５０９、５１１には、複合機能デバイス１２０、１３０、１４０においてＭＩＢに設定されている値が格納される。
【００２８】
図６は、ＳＮＭＰのパケットの送受信の特徴を示すシーケンス図であり、図６（ａ）は後述のＳＮＭＰエージェント６２０におけるＭＩＢの実装状況を示す図である。
【００２９】
ＭＩＢオブジェクト６０３、６０４、６０６は複合機能デバイスに実装されており、値として「ａ」、「ｂ」、「ｃ」が設定されているが、ＭＩＢオブジェクト６０５については複合機能デバイスに実装されていないものとする。また、根ノードにあたる６００、および、内部ノードにあたる６０１、６０２については値をもたず、定義上のみに存在するＭＩＢオブジェクトであり、ＭＩＢオブジェクト６０５と同様に実装されていないものとする。
【００３０】
図６（ｂ）は、ＳＮＭＰマネージャー６１０と図６（ａ）のツリー構造によって示されるＭＩＢが実装されたＳＮＭＰエージェント６２０間におけるＳＮＭＰパケットの送受信の様子を示すシーケンス図である。
【００３１】
６３０では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。ここで、最後の「０」は上述のインスタンス識別子にあたるため、ＯＩＤ「１．２．１．０」は図６（ａ）のＭＩＢオブジェクト６０３を示している。６３１では、”ＧｅｔＲｅｑｕｅｓｔ”  ６３０を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ＭＩＢオブジェクト６０３は図６（ａ）の記載の通り、値として「ａ」が設定されているため、ＯＩＤ「１．２．１．０」の値として「ａ」を返す。
【００３２】
６３２では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６３３では、”ＧｅｔＲｅｑｕｅｓｔ”６３２を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ここで、ＯＩＤ「１．２．０」は図６（ａ）のＭＩＢオブジェクト６０１を示しているが、ＭＩＢオブジェクト６０１はＭＩＢツリーの内部ノードにあたるため、ＳＮＭＰエージェント６２０には実装されていないものとする。したがって、”ＧｅｔＲｅｓｐｏｎｓｅ”６３３は、エラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
【００３３】
６３４では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０に図６（ａ）のＭＩＢオブジェクト６０１を示すＯＩＤ「１．２」の次のインスタンスを要求するために”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。ここで、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”の場合、指定したＭＩＢオブジェクトの次のインスタンスを要求するため、本実施例においては、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”で指定するＯＩＤにインスタンス識別子である「０」を付加しないこととする。６３５では、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対してＭＩＢオブジェクト６０１の次のインスタンスであるＭＩＢオブジェクト６０３を示すＯＩＤ「１．２．１．０」とその値である「ａ」が”ＧｅｔＲｅｓｐｏｎｓｅ”として通知される。
【００３４】
６３６では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．４．５．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６３７では、”ＧｅｔＲｅｑｕｅｓｔ”６３６を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。ここで、ＯＩＤ「１．４．５．０」は図６（ａ）のＭＩＢオブジェクト６０５を示しているが、上記記載の通りＳＮＭＰエージェント６２０には実装されていない。したがって、”ＧｅｔＲｅｓｐｏｎｓｅ”６３７はエラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
【００３５】
６３８では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０に図６（ａ）のＭＩＢオブジェクト６０５を示すＯＩＤ「１．４．５」の次のインスタンスを要求するために”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。６３９では、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対してＭＩＢオブジェクト６０５の次のインスタンスであるＭＩＢオブジェクト６０６を示すＯＩＤ「１．２．７．０」とその値である「ｃ」が”ＧｅｔＲｅｓｐｏｎｓｅ”として通知される。
【００３６】
６４０では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１．０」および「１．４．５．０」に対する”ＧｅｔＲｅｑｕｅｓｔ”が送信される。６４１では、”ＧｅｔＲｅｑｕｅｓｔ”を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。なお、ＭＩＢオブジェクト６０５はＳＮＭＰエージェント６２０には実装されていないＭＩＢオブジェクトであるため、”ＧｅｔＲｅｓｐｏｎｓｅ”６３７はエラー（ｎｏＳｕｃｈＮａｍｅ）としてＳＮＭＰマネージャー６１０に送信される。
【００３７】
６４２では、ＳＮＭＰマネージャー６１０からＳＮＭＰエージェント６２０にＯＩＤ「１．２．１」（ＭＩＢオブジェクト６０３）、および、「１．４．５」（ＭＩＢオブジェクト６０５）に対する”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”が送信される。６４３では、”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”６４２を受けて、ＳＮＭＰエージェント６２０からＳＮＭＰマネージャー６１０に対して”ＧｅｔＲｅｓｐｏｎｓｅ”が送信される。なお、ＭＩＢオブジェクト６０３、および、６０５の次のインスタンスは、それぞれ、ＭＩＢオブジェクト６０４、および、６０６である。したがって、６４３では、”ＧｅｔＲｅｓｐｏｎｓｅ”として、ＯＩＤ「１．２．３．０」、および、「１．４．７．０」と、それぞれの値として「ｂ」、および、「ｃ」が送信される。
【００３８】
以上、図６において説明したように”ＧｅｔＲｅｑｕｅｓｔ”では、ＭＩＢツリーの内部ノードにあたるＭＩＢオブジェクトや実装されていないＭＩＢオブジェクト、さらには、それらを含む複数のＯＩＤを同一のパケットで送信した場合、必ずエラーが発生する。一方、ＧｅｔＮｅｘｔＲｅｑｕｅｓでは、ＭＩＢツリーの内部ノードにあたるＭＩＢオブジェクトや実装されていないＭＩＢオブジェクト、さらには、それらを含む複数のＯＩＤを同一のパケットで送信しても、エラーとなる可能性は極めて少ない。
【００３９】
図７は、管理装置において行われる処理を説明するためのフローチャートである。本処理では、多数のネットワークデバイスの中から複合機能デバイス１２０、１３０、１４０を検出するため、それらデバイスのベンダー、モデム機能の有無、プリント機能の有無を判別するものとする。なお、本実施例においては、ＰＩＮＧ等の手段で事前に何らかのデバイスに割り当てられているＩＰアドレスを判別しており、本処理はそれらのＩＰアドレスを用いてベンダー、および、機能の判別処理をおこなうものとする。
【００４０】
Ｓ７００では、ネットワークデバイスのベンダーを識別するために図４のＭＩＢオブジェクト４０９のＯＩＤである「１．３．６．１．１．４」を図５に示すＶＢＬ５０５に設定し、Ｓ７０１に移行する。Ｓ７０１では、ネットワークデバイスのモデムの有無を判別するため、図４のＭＩＢオブジェクト４０６のＯＩＤである「１．３．６．１．２．１．３８」を図５に示すＶＢＬ５０５に設定し、Ｓ７０２に移行する。Ｓ７０２では、ネットワークデバイスのプリンタの有無を判別するため、図４のＭＩＢオブジェクト４０７のＯＩＤである「１．３．６．１．２．１．４３」を図５に示すＶＢＬ５０５に設定し、Ｓ７０３に移行する。
【００４１】
Ｓ７０３では、Ｓ７００〜Ｓ７０２でＯＩＤを設定したＶＢＬ５０５を含むＰＤＵ５００のＰＤＵタイプ５０１に”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を指定してＳＮＭＰパケットを送信し、Ｓ７０４に移行する。
【００４２】
Ｓ７０４では、Ｓ７０３においてパケット送信したＩＰアドレスからのＳＮＭＰパケットを受信したかどうかの判断がおこなわれる。本ステップにおいて、ＳＮＭＰパケットを受信したと判断した場合には、Ｓ７０５に移行し、それ以外の場合はＳ７０４に戻る。
【００４３】
Ｓ７０５では、Ｓ７０４で受信したＳＮＭＰパケットのＰＤＵタイプ５０１の確認がおこなわれる。本ステップにおいて、ＰＤＵタイプ５０１に設定された値が”ＧｅｔＲｅｓｐｏｎｓｅ”を示すものであると判断した場合は、Ｓ７０６に移行し、それ以外の場合は、Ｓ７０４に戻る。
【００４４】
Ｓ７０６では、Ｓ７０５で受信したパケットが”ＧｅｔＲｅｓｐｏｎｓｅ”であると判断した場合にリクエストＩＤ５０２の値を参照する。本ステップにおいて、リクエストＩＤ５０２が、Ｓ７０３で送信したＳＮＭＰパケットのものと一致する場合にはＳ７０７に移行し、それ以外の場合にはＳ７０４に戻る。
【００４５】
Ｓ７０７では、Ｓ７０４で受信したＳＮＭＰパケットにおけるエラーステータス５０３の確認がおこなわれる。本ステップにおいて、エラーステータス５０３がｎｏＥｒｒｏｒ（ｎｕｌｌ）であると判断した場合には、Ｓ７０９に移行し、それ以外の場合には、Ｓ７０８に移行する。Ｓ７０８では、Ｓ７０７においてエラーステータス５０３がｎｏＥｒｒｏｒではないと判断した場合の処理として、エラーステータス５０３に設定された値に応じたエラー処理を実行して処理を終了する。
【００４６】
Ｓ７０９では、Ｓ７０７においてエラーステータス５０３がｎｏＥｒｒｏｒであると判断した場合にＳ７０４で受信したＳＮＭＰパケットのＶＢＬ５０５の先頭に格納されたＯＩＤ５０６を参照し、Ｓ７１０に移行する。Ｓ７１０では、Ｓ７０９で参照したＯＩＤ５０６に、後述のベンダー判別テーブル（図８（ａ））に登録されているＯＩＤが含まれているかどうかの判別がおこなわれる。本ステップにおいて、ＯＩＤ５０６がベンダー判別テーブルに登録されたＯＩＤを含んでいると判断した場合には、Ｓ７１２に移行し、それ以外の場合には、Ｓ７１１に移行する。Ｓ７１１では、Ｓ７０３でパケット送信したＩＰアドレスのデバイス（対象デバイス）はサポート外として処理を終了する。
【００４７】
Ｓ７１２では、Ｓ７０４で受信したＳＮＭＰパケットのＶＢＬ５０５の２番目のＯＩＤ５０８を参照し、Ｓ７１３に移行する。Ｓ７１３では、Ｓ７１２で参照した２番目のＯＩＤ５０８にモデム機能を含むことを示すＯＩＤ４０６（「１．３．６．１．２．１．３８」）が含まれているかどうかの判断がおこなわれる。例えば、「１．３．６．１．２．１．３８．＊」といった値が返却された場合にはモデム機能を含むことを示すＯＩＤ４０６が含まれるので、対象デバイスがモデム機能を持つことが判定できる。一方、「１．３．６．１．２．１．３９．＊」といった値が返却される場合には対象デバイスがモデム機能を持たないことを判定できる。本ステップにおいて、２番目のＯＩＤ５０８にＯＩＤ４０６が含まれていると判断した場合にはＳ７１５に移行し、それ以外の場合にはＳ７１４に移行する。Ｓ７１４では、Ｓ７０３でパケット送信したＩＰアドレスのデバイス（対象デバイス）がモデム機能はないと判断してＳ７１６に移行する。一方、Ｓ７１５では、対象デバイスがモデム機能を持つと判断してＳ７１６に移行する。
【００４８】
Ｓ７１６では、Ｓ７０４で対象デバイスから受信したＳＮＭＰパケットのＶＢＬ５０５の３番目のＯＩＤ５１０を参照し、Ｓ７１７に移行する。Ｓ７１７では、Ｓ７１６で参照した３番目のＯＩＤ５１０にプリント機能を含むことを示すＯＩＤ４０７（「１．３．６．１．２．１．４３」）が含まれているかどうかの判断がおこなわれる。本ステップにおいて、３番目のＯＩＤ５１０にＯＩＤ４０７が含まれていると判断した場合にＳ７１９に移行し、それ以外の場合は、Ｓ７１８に移行する。Ｓ７１８では、対象デバイスがプリント機能を備えていないと判断して処理を終了する。Ｓ７１９では、対象デバイスがプリント機能を備えていると判断して処理を終了する。
【００４９】
図８は、本実施例において、管理対象デバイスのベンダー、および、機能を判別するための判別テーブルである。
【００５０】
図８（ａ）は、ベンダー判別用のテーブルであり、８００はデバイス管理プログラム３００がサポートするベンダー名を示している。一方、８０１は、デバイス管理プログラムがサポートするベンダーのプライベートＭＩＢのプリフィックスを示している。図７のＳ７１０では、受信した”ＧｅｔＲｅｓｐｏｎｓｅ”のＯＩＤに図８（ａ）で定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスのベンダーが判別される。
【００５１】
一方、図８（ｂ）は、機能判別用のテーブルであり、８１０はデバイスに実装された機能名を示している。一方、８１１はデバイスが８１０で示す機能をサポートするにあたって実装が期待されるＯＩＤのプリフィックスを示している。図７のＳ７１３、および、Ｓ７１７では、受信した”ＧｅｔＲｅｓｐｏｎｓｅ”のＯＩＤに本図８（ｂ）で定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスの機能が判別される。
【００５２】
以上のように、本発明では、デバイス管理プログラム３００により、管理対象となるデバイスに対して”ＧｅｔＮｅｘｔＲｅｑｕｅｓｔ”を送信し、”ＧｅｔＲｅｓｐｏｎｓｅ”に含まれるＯＩＤの構成からベンダーや機能をまとめて判別する機能を提供する。これにより、管理対象となるデバイスに実装が保証されていない複数のＭＩＢを１つのリクエストとして送信できるため、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。
【図１】
2012164134.tif 000003
【図２】
2012164134.tif 000004
【図３】
2012164134.tif 000005
【図４】
2012164134.tif 000006
【図５】
2012164134.tif 000007
【図６】
2012164134.tif 000008
【図７】
2012164134.tif 000009
【図８】
2012164134.tif 000010