SNMPSimpleNetworkManagementProtocolを利用して、ネットワーク上のデバイスをMIBManagementInformationBaseの値により管理する管理装置であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したGetNextRequestコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、前記対象デバイスより、GetNextRequestコマンドの応答としてのGetResponseコマンドを受信する受信手段と、前記受信したGetResponseコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする管理装置。前記判別手段は、前記受信したGetResponseコマンドにより返却された値において、前記特定の機能を示すノードのOIDを含まれている場合には前記対象デバイスが前記特定の機能を備えると判別し、前記特定の機能を示すノードのOIDを含まれていない場合には前記対象デバイスが前記特定の機能を備えないと判別することを特徴とする請求項1に記載の管理装置。前記特定の機能は、モデム機能またはプリンタ機能であることを特徴とする請求項1または2に記載の管理装置。前記管理装置でサポートするベンダーを登録したテーブルを保持する保持手段とを有し、前記判別手段は、前記受信したGetResponseコマンドを解析することで判別した前記対象デバイスのベンダーが前記テーブルに登録されていない場合には、前記特定の機能に関する判別を行わないことを特徴とする請求項1乃至3のいずれか1項に記載の管理装置。SNMPSimpleNetworkManagementProtocolを利用して、ネットワーク上のデバイスをMIBManagementInformationBaseの値により管理する管理装置における管理方法であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したGetNextRequestコマンドを前記ネットワーク上の対象デバイスに送信する送信工程と、前記対象デバイスより、GetNextRequestコマンドの応答としてのGetResponseコマンドを受信する受信工程と、前記受信したGetResponseコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別工程とを有することを特徴とする管理方法。請求項1乃至4のいずれか1項に記載の手段としてコンピュータを機能させるためのプログラム。ここで、1ベンダーが、異なるMIBをサポートする複数の機種のデバイスを提供する場合がある。従来のデバイス管理プログラムでは、こういった場合、ベンダーの判別処理の後、より詳細にデバイスの種別を判別するための手続きが必要であった。たとえば、複数のベンダーの複数の機種のデバイスが接続された大規模なネットワーク環境では、デバイス管理プログラムによる機種の判別処理に必要な送信パケットの数が増大してしまう。そのために、デバイス管理プログラムが動作する情報処理装置のパフォーマンス、およびシステム内のネットワークトラフィックに対する大きな障害となっていた。そこで、本発明は、SNMPSimpleNetworkManagementProtocolを利用して、ネットワーク上のデバイスをMIBManagementInformationBaseの値により管理する管理装置であって、ベンダーを特定する値を持つノードの親ノードと、デバイスの特定の機能を示すノードと、を指定したGetNextRequestコマンドを前記ネットワーク上の対象デバイスに送信する送信手段と、前記対象デバイスより、GetNextRequestコマンドの応答としてのGetResponseコマンドを受信する受信手段と、前記受信したGetResponseコマンドを解析することにより、前記対象デバイスのベンダーと、前記特定の機能の有無とを判別する判別手段とを有することを特徴とする。本発明によれば、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。以下、本発明を実施するための最良の形態について図面を用いて説明する。なお、実施例においては、デバイス管理プログラムにより実現される処理の管理対象となるネットワークデバイスの例として、複合機能デバイスとしている。しかしながら、プリンタやスキャナを含む単機能のデバイスなどであっても、本実施例は適用可能である。図1は、本実施例が適用されるネットワークシステムの構成例を示す図である。同図において、100はローカルエリアネットワークである。ローカルエリアネットワーク100には、管理装置110、および、複合機能デバイス120、130、140が接続されている。管理装置110では、デバイス管理プログラムが実行され、後述する手順によって複合機能デバイス120、130、140を管理しているものとする。図2は、本実施例が適用される管理装置110の構成を示すブロック図である。なお、本実施例における管理装置110は一般的なパーソナルコンピューターの構成を持つものとする。ROM201若しくはハードディスクHD210に記憶されたデバイス管理プログラム詳細後述を実行するCPU200を備える。さらに、CPU200は、システムバス203に接続された各デバイスを総括的に制御する。202はRAMであり、CPU200の主メモリ、ワークエリア等として機能する。204はキーボードコントローラKBCであり、キーボードKB208や不図示のポインティングデバイス等からの指示入力を制御する。205はDISPコントローラDISPCであり、ディスプレイDISP209への表示を制御する。206はディスクコントローラDKCであり、ハードディスクHD210、フロッピー登録商標ディスクコントローラFD211、CD-ROMドライブCD212とのアクセスを制御する。207はネットワークインタフェースカードNICであり、LAN100を介して複合機能デバイス120、130、140と双方向にデータを授受する。なお、後述するすべての説明で特に断りのない限り、管理装置110で提供する機能の主体はCPU200であり、ハードディスクHD210などに格納されるデバイス管理プログラムを実行することでそれら機能が実現されるものとする。また、デバイス管理プログラムは、CD-ROMなどの記憶媒体に格納された形で供給されても良く、CD-ROMドライブ212などによって記憶媒体からプログラムが読み取られ、ハードディスクHD210にインストールされる。ほかにも、デバイス管理プログラムはネットワークからダウンロードされる形で供給され、ハードディスクHD210にインストールされてもよい。図3は、本実施例が適用されるネットワークシステムにおいて、管理装置110、および、複合機能デバイス120、130、140上で稼働するソフトウェア構成を説明するブロック図である。枠300内は、デバイス管理プログラムに関連するSNMPにより複合機能デバイス120、130、140を管理するSNMPマネージャーとしての機能モジュール群を示している。管理装置110において、デバイス管理プログラム300、および、各モジュールは、ハードディスクHD210に保存されたファイルとして存在する。これらは実行時にOSやその他のモジュールによってRAM202にロードされ、CPU200により実行される実行形式ファイルである。301は、UI制御モジュールであり、キーボードKB208や不図示のポインティングデバイス等からの指示入力をコマンドに変換し、全体制御モジュール302に送信するモジュールである。UI制御モジュール301はまた、後述のモジュールによる処理を経て複合機能デバイス120、130、140に対しておこなった処理の結果をDISPコントローラDISPC205を介してディスプレイDISP209に表示する。302は、全体制御モジュールであり、UI制御モジュール301から受信したコマンドを後述のデバイス管理モジュール303、デバイス探索モジュール304、デバイス監視モジュール305に振り分ける制御をおこなうモジュールである。さらに、全体制御モジュールは、デバイス管理モジュール303、デバイス探索モジュール304、デバイス監視モジュール305の処理結果を受信して、必要に応じて変換し、UI制御モジュール301に通知する。303はデバイス管理モジュールであり、UI制御モジュール301から指定された特定の複合機能デバイス120、130、140に対して詳細な情報を取得設定するためのモジュールである。より詳細には、デバイス管理モジュール303はSNMP制御部307を介して複合機能デバイスの名称や設置場所、さらには、各種のネットワーク情報を取得設定するために、復号機能デバイスのMIB情報の取得設定をおこなうためのモジュールである。304は、デバイス探索モジュールであり、SNMP制御モジュール307を介してネットワークに接続された複合機能デバイス120、130、140を探索するモジュールである。本実施例においては、複合機能デバイスに実装が期待されるMIBの情報を取得するため、SNMPのGetRequestをブロードキャストやユニキャストで送信し、正常にMIBの情報を取得できたデバイスを管理対象の複合機能デバイスとして認識する。305は、デバイス監視モジュールであり、複合機能デバイス120、130、140の状態を示すMIB情報を、あらかじめ設定された間隔で定期的に取得し、複合機能デバイスの障害を検出するためのモジュールである。デバイス監視モジュール305はさらに、取得したMIB情報から複合機能デバイス120、130、140の障害を検出した場合、データベースモジュール306に障害の履歴情報を登録するとともに、UIモジュール301に対して障害の発生を通知する。306は、データベースモジュールであり、デバイス管理モジュール303、デバイス探索モジュール304、デバイス監視モジュール305の処理結果やSNMP制御モジュール307が参照するMIB情報、その他、設定された各種のパラメータが保存される。307は、SNMP制御モジュールで、デバイス管理モジュール303、デバイス探索モジュール304、デバイス監視モジュール305の要求に応じてMIBオブジェクトのハンドリング、SNMPパケットの送受信などをおこなうためのモジュールである。一方、SNMPエージェント311は、複合機能デバイス120上で稼働し、MIB情報モジュール312を参照して、SNMPマネージャーから送信されたSNMPパケットに応答を返すプログラムである。SNMPエージェント321、331、および、MIB情報モジュール322、332はそれぞれ、複合機能デバイス130、140上で稼働し、それぞれ、SNMPエージェント311、および、MIB情報モジュール312と同様の構成を持つものとする。図4は、MIBの構成を示す概念図である。MIBの構成はツリー構造で示され、各ノードはMIBオブジェクトと呼ばれる。各MIBオブジェクトは、それぞれ、オブジェクト識別子OIDと呼ばれるIDが割り当てられている。OIDは、木構造の階層ごとに割り当てられた枝番により表される。例えば、MIBオブジェクト407のOIDは、1.3.6.1.2.1.43のように表される。SNMPマネージャーは、SNMPエージェント311、321、331に対して、OIDを指定して機器の情報の取得及び設定変更を要求する。また、MIBはエージェントの持つ機能により実装が異なっている。例えば、モデム機能を持つデバイス対しては、MIBオブジェクト406以下の葉ノードで示されるMIBオブジェクトの実装が期待され、プリント機能を持つデバイスに対してはMIBオブジェクト407以下のノードで示されるMIBの実装が期待されている。さらに、MIBオブジェクト409以下は、デバイスのベンダーを示すMIBオブジェクト410、411、412が定義され、これらベンダーを示すMIBオブジェクト以下はプライベートMIBと呼ばれ、各ベンダーが独自に定義するMIBである。図5は、SNMPメッセージのデータ構造の一例を示す図である。500はPDUProtocolDataUnitであり、後述のパラメータによって構成されるSNMPの基本的なデータユニットである。501は、PDUタイプフィールドであり、SNMPのリクエストの種別を示すIDが設定される。SNMPVersion1以下、SNMPv1ではPDUタイプとしては、GetRequest、GetNextRequest、SetRequest、GetResponse、及び、Trapが定義されている。これらのうちTrapについては、異なるデータ構造を持ち、本実施例においては説明を省略する。502は、リクエストIDフィールドである。リクエストIDフィールド502には、SNMPマネージャーからの要求とSNMPエージェント311、321、331からの応答とを一意に識別するためのリクエストIDが格納される。503は、エラーステータスフィールドであり、SNMPマネージャーからのSNMPリクエストにSNMPエージェント311、321、331が正常に応答を返せなかった場合、その理由を示すコードを格納する領域である。SNMPv1における代表的なエラーステータス503としては以下のものがある。なお、GetResponse以外のPDUでは、エラーステータス503にはnoErrorが設定される。1noError:正常終了2tooBig:要求されたSNMPリクエストに対する応答がPDUのサイズ制限を超えてしまう3noSuchName:SNMPリクエストで要求されたMIBオブジェクトが実装されていない4badValue:SetRequestで要求された値がMIBの定義に矛盾している5readOnly:読み出しのみ可能なMIBオブジェクトに対してSetRequestが要求された6genError:上記以外のエラーが発生した504は、エラーインデックスフィールドである。SNMPのPDU500では、後述の変数バインディングリスト505以下、VBL505において複数のMIBオブジェクトの指定が可能である。エラーインデックスフィールド504に格納されるエラーインデックスは、これら複数のMIBオブジェクトのうち、エラーが発生したMIBオブジェクトを示す最も小さい値が格納される。また、エラーステータスがnoErrorの場合、本エラーインデックスには0が設定される。505は、VBLVariableBindingListフィールドであり、1以上のMIBのOID、および、その値が情報が格納されている。506、508、510は、OIDフィールドであり、507、509、511は値フィールドである。OIDフィールド506、508、510には、各MIBオブジェクトに割り当てられた実際のOIDの後にインスタンス識別子を付け加えた値が格納される。インスタンス識別子は、MIBオブジェクトが単一の値しか有さない場合には0が設定される。一方、MIBオブジェクトがテーブル形式で複数の値を有する場合には、テーブル内の夫々の値に対して1以上の連続であるとは限られない数字により表されるインスタンス識別子が付与される。この場合に、従来では、PDUとしてGetNextRequestを用い、これを繰り返し呼び出すことにより、テーブル内の全ての情報を取得することが可能である。また、GetRequest、GetNextRequestの場合、値フィールド507、509、511にはNULLが指定される。SetRequestの場合、値フィールド507、509、511には、デバイス管理プログラム300が複合機能デバイス120、130、140に対して設定する値が格納される。さらに、GetResponseの場合、値フィールド507、509、511には、複合機能デバイス120、130、140においてMIBに設定されている値が格納される。図6は、SNMPのパケットの送受信の特徴を示すシーケンス図であり、図6aは後述のSNMPエージェント620におけるMIBの実装状況を示す図である。MIBオブジェクト603、604、606は複合機能デバイスに実装されており、値としてa、b、cが設定されているが、MIBオブジェクト605については複合機能デバイスに実装されていないものとする。また、根ノードにあたる600、および、内部ノードにあたる601、602については値をもたず、定義上のみに存在するMIBオブジェクトであり、MIBオブジェクト605と同様に実装されていないものとする。図6bは、SNMPマネージャー610と図6aのツリー構造によって示されるMIBが実装されたSNMPエージェント620間におけるSNMPパケットの送受信の様子を示すシーケンス図である。630では、SNMPマネージャー610からSNMPエージェント620にOID1.2.1.0に対するGetRequestが送信される。ここで、最後の0は上述のインスタンス識別子にあたるため、OID1.2.1.0は図6aのMIBオブジェクト603を示している。631では、GetRequest630を受けて、SNMPエージェント620からSNMPマネージャー610に対してGetResponseが送信される。MIBオブジェクト603は図6aの記載の通り、値としてaが設定されているため、OID1.2.1.0の値としてaを返す。632では、SNMPマネージャー610からSNMPエージェント620にOID1.2.0に対するGetRequestが送信される。633では、GetRequest632を受けて、SNMPエージェント620からSNMPマネージャー610に対してGetResponseが送信される。ここで、OID1.2.0は図6aのMIBオブジェクト601を示しているが、MIBオブジェクト601はMIBツリーの内部ノードにあたるため、SNMPエージェント620には実装されていないものとする。したがって、GetResponse633は、エラーnoSuchNameとしてSNMPマネージャー610に送信される。634では、SNMPマネージャー610からSNMPエージェント620に図6aのMIBオブジェクト601を示すOID1.2の次のインスタンスを要求するためにGetNextRequestが送信される。ここで、GetNextRequestの場合、指定したMIBオブジェクトの次のインスタンスを要求するため、本実施例においては、GetNextRequestで指定するOIDにインスタンス識別子である0を付加しないこととする。635では、SNMPエージェント620からSNMPマネージャー610に対してMIBオブジェクト601の次のインスタンスであるMIBオブジェクト603を示すOID1.2.1.0とその値であるaがGetResponseとして通知される。636では、SNMPマネージャー610からSNMPエージェント620にOID1.4.5.0に対するGetRequestが送信される。637では、GetRequest636を受けて、SNMPエージェント620からSNMPマネージャー610に対してGetResponseが送信される。ここで、OID1.4.5.0は図6aのMIBオブジェクト605を示しているが、上記記載の通りSNMPエージェント620には実装されていない。したがって、GetResponse637はエラーnoSuchNameとしてSNMPマネージャー610に送信される。638では、SNMPマネージャー610からSNMPエージェント620に図6aのMIBオブジェクト605を示すOID1.4.5の次のインスタンスを要求するためにGetNextRequestが送信される。639では、SNMPエージェント620からSNMPマネージャー610に対してMIBオブジェクト605の次のインスタンスであるMIBオブジェクト606を示すOID1.2.7.0とその値であるcがGetResponseとして通知される。640では、SNMPマネージャー610からSNMPエージェント620にOID1.2.1.0および1.4.5.0に対するGetRequestが送信される。641では、GetRequestを受けて、SNMPエージェント620からSNMPマネージャー610に対してGetResponseが送信される。なお、MIBオブジェクト605はSNMPエージェント620には実装されていないMIBオブジェクトであるため、GetResponse637はエラーnoSuchNameとしてSNMPマネージャー610に送信される。642では、SNMPマネージャー610からSNMPエージェント620にOID1.2.1MIBオブジェクト603、および、1.4.5MIBオブジェクト605に対するGetNextRequestが送信される。643では、GetNextRequest642を受けて、SNMPエージェント620からSNMPマネージャー610に対してGetResponseが送信される。なお、MIBオブジェクト603、および、605の次のインスタンスは、それぞれ、MIBオブジェクト604、および、606である。したがって、643では、GetResponseとして、OID1.2.3.0、および、1.4.7.0と、それぞれの値としてb、および、cが送信される。以上、図6において説明したようにGetRequestでは、MIBツリーの内部ノードにあたるMIBオブジェクトや実装されていないMIBオブジェクト、さらには、それらを含む複数のOIDを同一のパケットで送信した場合、必ずエラーが発生する。一方、GetNextRequesでは、MIBツリーの内部ノードにあたるMIBオブジェクトや実装されていないMIBオブジェクト、さらには、それらを含む複数のOIDを同一のパケットで送信しても、エラーとなる可能性は極めて少ない。図7は、管理装置において行われる処理を説明するためのフローチャートである。本処理では、多数のネットワークデバイスの中から複合機能デバイス120、130、140を検出するため、それらデバイスのベンダー、モデム機能の有無、プリント機能の有無を判別するものとする。なお、本実施例においては、PING等の手段で事前に何らかのデバイスに割り当てられているIPアドレスを判別しており、本処理はそれらのIPアドレスを用いてベンダー、および、機能の判別処理をおこなうものとする。S700では、ネットワークデバイスのベンダーを識別するために図4のMIBオブジェクト409のOIDである1.3.6.1.1.4を図5に示すVBL505に設定し、S701に移行する。S701では、ネットワークデバイスのモデムの有無を判別するため、図4のMIBオブジェクト406のOIDである1.3.6.1.2.1.38を図5に示すVBL505に設定し、S702に移行する。S702では、ネットワークデバイスのプリンタの有無を判別するため、図4のMIBオブジェクト407のOIDである1.3.6.1.2.1.43を図5に示すVBL505に設定し、S703に移行する。S703では、S700~S702でOIDを設定したVBL505を含むPDU500のPDUタイプ501にGetNextRequestを指定してSNMPパケットを送信し、S704に移行する。S704では、S703においてパケット送信したIPアドレスからのSNMPパケットを受信したかどうかの判断がおこなわれる。本ステップにおいて、SNMPパケットを受信したと判断した場合には、S705に移行し、それ以外の場合はS704に戻る。S705では、S704で受信したSNMPパケットのPDUタイプ501の確認がおこなわれる。本ステップにおいて、PDUタイプ501に設定された値がGetResponseを示すものであると判断した場合は、S706に移行し、それ以外の場合は、S704に戻る。S706では、S705で受信したパケットがGetResponseであると判断した場合にリクエストID502の値を参照する。本ステップにおいて、リクエストID502が、S703で送信したSNMPパケットのものと一致する場合にはS707に移行し、それ以外の場合にはS704に戻る。S707では、S704で受信したSNMPパケットにおけるエラーステータス503の確認がおこなわれる。本ステップにおいて、エラーステータス503がnoErrornullであると判断した場合には、S709に移行し、それ以外の場合には、S708に移行する。S708では、S707においてエラーステータス503がnoErrorではないと判断した場合の処理として、エラーステータス503に設定された値に応じたエラー処理を実行して処理を終了する。S709では、S707においてエラーステータス503がnoErrorであると判断した場合にS704で受信したSNMPパケットのVBL505の先頭に格納されたOID506を参照し、S710に移行する。S710では、S709で参照したOID506に、後述のベンダー判別テーブル図8aに登録されているOIDが含まれているかどうかの判別がおこなわれる。本ステップにおいて、OID506がベンダー判別テーブルに登録されたOIDを含んでいると判断した場合には、S712に移行し、それ以外の場合には、S711に移行する。S711では、S703でパケット送信したIPアドレスのデバイス対象デバイスはサポート外として処理を終了する。S712では、S704で受信したSNMPパケットのVBL505の2番目のOID508を参照し、S713に移行する。S713では、S712で参照した2番目のOID508にモデム機能を含むことを示すOID4061.3.6.1.2.1.38が含まれているかどうかの判断がおこなわれる。例えば、1.3.6.1.2.1.38.といった値が返却された場合にはモデム機能を含むことを示すOID406が含まれるので、対象デバイスがモデム機能を持つことが判定できる。一方、1.3.6.1.2.1.39.といった値が返却される場合には対象デバイスがモデム機能を持たないことを判定できる。本ステップにおいて、2番目のOID508にOID406が含まれていると判断した場合にはS715に移行し、それ以外の場合にはS714に移行する。S714では、S703でパケット送信したIPアドレスのデバイス対象デバイスがモデム機能はないと判断してS716に移行する。一方、S715では、対象デバイスがモデム機能を持つと判断してS716に移行する。S716では、S704で対象デバイスから受信したSNMPパケットのVBL505の3番目のOID510を参照し、S717に移行する。S717では、S716で参照した3番目のOID510にプリント機能を含むことを示すOID4071.3.6.1.2.1.43が含まれているかどうかの判断がおこなわれる。本ステップにおいて、3番目のOID510にOID407が含まれていると判断した場合にS719に移行し、それ以外の場合は、S718に移行する。S718では、対象デバイスがプリント機能を備えていないと判断して処理を終了する。S719では、対象デバイスがプリント機能を備えていると判断して処理を終了する。図8は、本実施例において、管理対象デバイスのベンダー、および、機能を判別するための判別テーブルである。図8aは、ベンダー判別用のテーブルであり、800はデバイス管理プログラム300がサポートするベンダー名を示している。一方、801は、デバイス管理プログラムがサポートするベンダーのプライベートMIBのプリフィックスを示している。図7のS710では、受信したGetResponseのOIDに図8aで定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスのベンダーが判別される。一方、図8bは、機能判別用のテーブルであり、810はデバイスに実装された機能名を示している。一方、811はデバイスが810で示す機能をサポートするにあたって実装が期待されるOIDのプリフィックスを示している。図7のS713、および、S717では、受信したGetResponseのOIDに本図8bで定義されたプリフィックスが含まれているかどうかの判断がおこなわれ、デバイスの機能が判別される。以上のように、本発明では、デバイス管理プログラム300により、管理対象となるデバイスに対してGetNextRequestを送信し、GetResponseに含まれるOIDの構成からベンダーや機能をまとめて判別する機能を提供する。これにより、管理対象となるデバイスに実装が保証されていない複数のMIBを1つのリクエストとして送信できるため、ネットワークデバイスを管理する管理装置のパフォーマンスの向上が期待できる。また、ネットワークデバイスの探索や機能調査における、システム内のネットワークトラフィックの大幅な軽減を期待することができる。