JP5862417B2

JP5862417B2 - 管理デバイス

Info

Publication number: JP5862417B2
Application number: JP2012077414A
Authority: JP
Inventors: 智美白木
Original assignee: Brother Industries Ltd
Current assignee: Brother Industries Ltd
Priority date: 2012-03-29
Filing date: 2012-03-29
Publication date: 2016-02-16
Anticipated expiration: 2032-03-29
Also published as: US9146971B2; US20130262448A1; JP2013206359A

Description

本明細書では、管理対象の対象デバイスを管理する管理デバイスを開示する。

例えば、特許文献１及び２には、複数個の情報を取得するためのＯＩＤ（Object ID）を含むＧＥＴＮＥＸＴリクエスト又はＧＥＴＢＵＬＫリクエストを送信して、複数個の情報を一括して取得する技術が開示されている。

特開２００７−１７４２３５号公報特開２００８−７１１９７号公報

本明細書では、特許文献１及び２とは異なる手法を用いて、取得対象の対象情報を効率良く取得し得る技術を開示する。特に、対象情報が、２次元以上の複数個のインデックス値に対応する複数個の部分対象情報を含む場合に、各部分対象情報を効率良く取得し得る技術を開示する。

本明細書では、管理対象の対象デバイスを管理する管理デバイスを開示する。管理デバイスは、取得対象の対象情報に対応するＩＤである対象ＩＤを含むリクエストを対象デバイスに送信して、対象デバイスから対象情報を取得する取得部を備える。取得部は、準備部と、送信部と、を備える。準備部は、対象情報が、Ｋ次元（Ｋは２以上の整数）の複数個のインデックス値に対応する複数個の部分対象情報を含む場合に、第１グループのＭａ個（Ｍａは２以上の整数）の組合せＩＤを準備する。第１グループのＭａ個の組合せＩＤのそれぞれは、対象ＩＤと、連続するＭａ個のインデックス値のそれぞれと、の組合せである。Ｍａ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有する。送信部は、第１グループのＭａ個の組合せＩＤを含む第１のＧＥＴＮＥＸＴリクエストを対象デバイスに送信する。準備部は、さらに、第１のＧＥＴＮＥＸＴリクエストを送信した結果として、対象デバイスから取得されるＭａ個の部分対象情報が、対象ＩＤと、上位の桁の値として第１の値とは異なる第２の値を有する特定のインデックス値と、の組合せである特定の組合せＩＤに対応する特定の部分対象情報を含む第１の場合に、Ｍｂ個（Ｍｂは２以上の整数）の組合せＩＤを準備する。Ｍｂ個の組合せＩＤのそれぞれは、対象ＩＤと、連続するＭｂ個のインデックス値のそれぞれと、の組合せである。Ｍｂ個のインデックス値は、上位の桁の値として第２の値を有すると共に、下位の桁の値として連続する値を有する。送信部は、さらに、第１の場合に、Ｍｂ個の組合せＩＤを含む第２のＧＥＴＮＥＸＴリクエストを対象デバイスに送信する。

上記の構成によると、管理デバイスは、第１グループのＭａ個の組合せＩＤを含む第１のＧＥＴＮＥＸＴリクエストを対象デバイスに送信する。ここで、第１グループのＭａ個の組合せＩＤ内のＭａ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有する。これにより、管理デバイスは、Ｍａ個の部分対象情報を一括して適切に取得し得る。また、管理デバイスは、第１のＧＥＴＮＥＸＴリクエストを送信した結果として、特定の組合せＩＤ（即ち、上位の桁の値として、第１の値とは異なる第２の値を有する特定のインデックス値を含む組合せＩＤ）に対応する特定の部分対象情報が取得される第１の場合に、Ｍｂ個の組合せＩＤを準備する。ここで、Ｍｂ個の組合せＩＤ内のＭｂ個のインデックス値は、上位の桁の値として第２の値を有すると共に、下位の桁の値として連続する値を有する。従って、管理デバイスは、第１の場合に、適切なＭｂ個の組合せＩＤを準備し得る。このために、管理デバイスは、Ｍｂ個の組合せＩＤを含む第２のＧＥＴＮＥＸＴリクエストを対象デバイスに送信することによって、Ｍｂ個の部分対象情報を一括して適切に取得し得る。上記の構成によると、管理デバイスは、２次元以上の複数個のインデックス値に対応する複数個の部分対象情報を、効率良く取得し得る。

準備部は、さらに、Ｍａ個の部分対象情報が、特定の部分対象情報を含まない第２の場合に、Ｍｃ個（Ｍｃは２以上の整数）の組合せＩＤを準備してもよい。Ｍｃ個の組合せＩＤのそれぞれは、対象ＩＤと、連続するＭｃ個のインデックス値のそれぞれと、の組合せであってもよい。Ｍｃ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有していてもよい。Ｍｃ個のインデックス値のうちの最小のインデックス値は、Ｍａ個のインデックス値のうちの最大のインデックス値に連続する値であってもよい。送信部は、さらに、第２の場合に、Ｍｃ個の組合せＩＤを含む第３のＧＥＴＮＥＸＴリクエストを対象デバイスに送信してもよい。この構成によると、管理デバイスは、第１のＧＥＴＮＥＸＴリクエストを送信した結果として、特定の部分対象情報が取得されない第２の場合に、Ｍｃ個の組合せＩＤを準備する。ここで、Ｍｃ個の組合せＩＤ内のＭｃ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有する。しかも、Ｍｃ個のインデックス値のうちの最小のインデックス値は、Ｍａ個のインデックス値のうちの最大のインデックス値に連続する値である。従って、管理デバイスは、第２の場合に、適切なＭｃ個の組合せＩＤを準備し得る。このために、管理デバイスは、Ｍｃ個の組合せＩＤを含む第３のＧＥＴＮＥＸＴリクエストを対象デバイスに送信することによって、Ｍｃ個の部分対象情報を一括して適切に取得し得る。

取得部は、第１のＧＥＴＮＥＸＴリクエストを送信した結果として、対象デバイスから、Ｍａ個の部分対象情報と共に、Ｍａ個の部分対象情報に対応する第２グループのＭａ個の組合せＩＤを取得してもよい。準備部は、第１の場合に、第２グループのＭａ個の組合せＩＤの中から、最大のインデックス値を有する最大の組合せＩＤを特定して、最大の組合せＩＤから昇順でＭｂ個の組合せＩＤを準備してもよい。この構成によると、管理デバイスは、Ｍｂ個の組合せＩＤを適切に準備し得るために、Ｍｂ個の部分対象情報を一括して適切に取得し得る。

取得部は、さらに、Ｍａ個の部分対象情報が特定の部分対象情報を含むのか否かを判断する判断部を備えていてもよい。

取得部は、第１のＧＥＴＮＥＸＴリクエストを送信した結果として、対象デバイスから、Ｍａ個の部分対象情報と共に、Ｍａ個の部分対象情報に対応する第２グループのＭａ個の組合せＩＤを取得してもよい。判断部は、第２グループのＭａ個の組合せＩＤが、特定の組合せＩＤを含むのか否かを判断することによって、Ｍａ個の部分対象情報が、特定の部分対象情報を含むのか否かを判断してもよい。この構成によると、管理デバイスは、Ｍａ個の部分対象情報が、特定の部分対象情報を含むのか否かを適切に判断し得る。

管理デバイスは、さらに、複数個のＩＤのそれぞれについて、当該ＩＤと、当該ＩＤに対応する情報に含まれる複数個の部分情報に対応する複数個のインデックス値の次元数を示す次元数データと、が関連付けられているテーブルを格納するメモリを備えていてもよい。準備部は、対象ＩＤに関連付けられている次元数データを用いて、第１グループのＭａ個の組合せＩＤを準備してもよい。この構成によると、管理デバイスは、第１グループのＭａ個の組合せＩＤを適切に準備し得る。

上記の管理デバイスを実現するための制御方法、コンピュータプログラム、及び、当該コンピュータプログラムを格納するコンピュータ読取可能記憶媒体も新規で有用である。

管理システムの構成を示す。管理デバイス処理のフローチャートを示す。インデックス情報取得処理のフローチャートを示す。１次元インデックス情報の取得例を表わすシーケンス図を示す。２次元インデックス情報の取得例を表わすシーケンス図を示す。３次元インデックス情報の取得例を表わすシーケンス図を示す。第１実施例の変形例のシーケンス図を示す。第２実施例の２次元以上のインデックス情報取得処理のフローチャートを示す。第２実施例の２次元インデックス情報の取得例を表わすシーケンス図を示す。

（システムの構成）
図１に示されるように、管理システム２は、管理デバイス１０と、プリンタ５０と、を備える。なお、図１では、１個のプリンタ５０のみが開示されているが、管理システム２は、複数個のプリンタ５０を備えていてもよい。管理デバイス１０及びプリンタ５０は、ＬＡＮ４に接続されている。従って、管理デバイス１０及びプリンタ５０は、ＬＡＮ４を介して、相互に通信可能である。

管理デバイス１０は、ＰＣ、サーバ等のデバイスである。管理デバイス１０は、プリンタ５０から様々な情報を取得して、当該情報を表示するための管理処理（図２参照）を実行する。これにより、管理デバイス１０は、管理対象のプリンタ５０を管理する。より具体的に言うと、管理デバイス１０とプリンタ５０との間では、ＳＮＭＰ（Simple Network Management Protocol）に従って、各情報の通信が実行される。即ち、管理デバイス１０がＳＮＭＰマネージャとして機能し、プリンタ５０がＳＮＭＰエージェントとして機能する。

（管理デバイス１０の構成）
管理デバイス１０は、操作部１２と、表示部１４と、ネットワークインターフェイス１６と、制御部２０と、を備える。操作部１２は、キーボード及びマウスによって構成される。ユーザは、操作部１２を操作することによって、様々な指示を管理デバイス１０に入力することができる。表示部１４は、様々な情報を表示するためのディスプレイである。ネットワークインターフェイス１６は、ＬＡＮ４に接続されている。

制御部２０は、ＣＰＵ２２と、メモリ２４と、を備える。ＣＰＵ２２は、メモリ２４に格納されているプログラムに従って、様々な処理を実行する。メモリ２４内のプログラムは、上記の管理処理を実行するための管理プログラムを含む。本実施例では、管理プログラムは、ＳＮＭＰｖ１（Simple Network Management Protocol version 1）に従ったプログラムである。ただし、変形例では、管理プログラムは、ＳＮＭＰｖ２、ＳＭＭＰｖ３等に従ったプログラムであってもよい。

管理プログラムは、例えば、プリンタ５０のベンダによって提供される。管理プログラムは、例えば、プリンタ５０と共に出荷されるメディアに格納されている。ユーザは、当該メディアから管理プログラムをＰＣ等のデバイスにインストールする。これにより、管理処理を実行可能な管理デバイス１０が実現される。なお、例えば、ユーザは、プリンタ５０のベンダによって提供されるサーバから、管理プログラムをＰＣ等のデバイスにインストールしてもよい。

ＣＰＵ２２が管理プログラムに従って処理を実行することによって、取得部３０の機能が実現される。なお、取得部３０は、準備部３２と送信部３４と判断部３６とを備える。また、管理プログラムは、次元数テーブル２６を含む。従って、管理プログラムが管理デバイス１０にインストールされると、メモリ２４に次元数テーブル２６が格納される。次元数テーブル２６の内容については、後で説明する。

（プリンタ５０の構成）
プリンタ５０は、ＰＣ等のデバイス（図示省略）から印刷指示を受信すると、印刷を実行する。プリンタ５０は、情報テーブル５２を格納している。情報テーブル５２では、ＯＩＤ（Object ID）と、ＭＩＢ（Management Information Base）値と、が対応付けられている。

（ＭＩＢとＯＩＤ）
プリンタ５０は、プリンタ５０のエラー履歴、プリンタ５０のステータス（印刷実行中、待機中等）、ユーザに関する設定値（パスワード等）、印刷に関する設定値（デフォルトの印刷解像度）等の様々な情報を、ツリー構造（即ち階層構造）を利用して格納する。このツリー構造を有する様々な情報の集合のことを「ＭＩＢ」と呼ぶ。

ＭＩＢのツリー構造では、オブジェクトという概念が利用される。そして、各オブジェクトには、１個の数字が割り当てられる。例えば、最上位の階層から最下位の階層に向かって、第１のオブジェクト（例えば数字「1」）、第２のオブジェクト（例えば数字「3」）、第３のオブジェクト（例えば数字「6」）、・・・、最下位のオブジェクト（例えば数字「1」）が存在する状況を想定する。この場合、最下位のオブジェクトに対応する情報を特定するためのパスは、「1.3.6.….1」で表現される。本実施例では、ＭＩＢのツリー構造に従って特定されるパスのことを「ベースＩＤ」と呼ぶ。また、１個のベースＩＤに対応する情報のことを「１個の情報」と呼ぶ。

ＭＩＢのツリー構造では、１個のベースＩＤに対応する１個の情報が、複数個の部分情報を含む場合に、それらの複数個の部分情報のそれぞれを特定するためのインデックス値を利用することができる。例えば、上記のベースＩＤ「1.3.6.….1」に対応する１個の情報が、第１及び第２の部分情報を含む場合には、第１の部分情報にインデックス値「1」を割り当て、第２の部分情報にインデックス値「2」を割り当てることができる。この場合、第１の部分情報に対応するＩＤは、ベースＩＤ「1.3.6.….1」とインデックス値「1」との組合せ「1.3.6.….1.1」で表現される。同様に、第２の部分情報に対応するＩＤは、ベースＩＤ「1.3.6.….1」とインデックス値「2」との組合せ「1.3.6.….1.2」で表現される。本実施例では、ベースＩＤとインデックス値との組合せのＩＤのことを「ＯＩＤ」と呼び、ＯＩＤに対応する部分情報のことを「ＭＩＢ値」と呼ぶ。また、複数個の部分情報（即ち複数個のＭＩＢ値）を含む１個の情報のことを「インデックス情報」と呼ぶ。

例えば、ベースＩＤ「1.3.6.….1」に対応するインデックス情報が、プリンタ５０のエラー履歴を示す情報である場合には、プリンタ５０は、１回目のエラーが発生すると、当該エラーを示す値を、インデックス値「1」を含むＯＩＤ「1.3.6.….1.1」に対応するＭＩＢ値として、格納することができる。そして、プリンタ５０は、２回目のエラーが発生すると、当該エラーを示す値を、インデックス値「2」を含むＯＩＤ「1.3.6.….1.2」に対応するＭＩＢ値として、格納することができる。このように、プリンタ５０は、インデックス情報を利用すれば、１個のベースＩＤに対応付けて、複数個のＭＩＢ値を累積的に格納することができる。

なお、例えば、上記のベースＩＤ「1.3.6….1」に対応する１個の情報が、複数個の部分情報を含まない場合（例えば、当該１個の情報が、１個の値のみで表現される場合）には、当該１個の情報に対応するＩＤは、ベースＩＤ「1.3.6….1」とデフォルト値「0」との組合せ「1.3.6….1.0」で表現される。本実施例では、ベースＩＤとデフォルト値との組合せのＩＤのことも「ＯＩＤ」と呼ぶ。また、複数個の部分情報を含まない１個の情報のことを「非インデックス情報」と呼ぶ。

プリンタ５０は、非インデックス情報及びインデックス情報を、ＯＩＤに対応付けて、情報テーブル５２に格納する。例えば、ベースＩＤ「1.3.6.1.4.1…1.2.3.1」に対応する１個の情報は、１個のＭＩＢ値「V0」のみを含む非インデックス情報である。従って、情報テーブル５２では、ＯＩＤ「1.3.6.1.4.1…1.2.3.1.0」と、ＭＩＢ値「V0」と、が対応付けられている。

また、ベースＩＤ「1.3.6.1.4.1…1.2.3.2」に対応する１個の情報は、２８個のインデックス値「1」〜「28」に対応する２８個のＭＩＢ値「V1」〜「V28」を含むインデックス情報である。従って、情報テーブル５２では、ＯＩＤ「1.3.6.1.4.1…1.2.3.2.1」〜「1.3.6.1.4.1…1.2.3.2.28」と、２８個のＭＩＢ値「V1」〜「V28」と、が対応付けられている。なお、２８個のインデックス値「1」〜「28」は、１次元の値（１次元の整数）である。

インデックス値は、２次元以上の値で表現されることもあり得る。例えば、ベースＩＤ「1.3.6.1.4.1…1.2.3.3」に対応する１個の情報は、４３個の２次元インデックス値「1.1」〜「1.25」，「2.1」〜「2.18」に対応する４３個のＭＩＢ値「V1.1」〜「V1.25」，「V2.1」〜「V2.18」を含むインデックス情報である。また、例えば、ベースＩＤ「1.3.6.1.4.1…1.2.3.4」に対応する１個の情報は、複数個の３次元インデックス値「1.1.1」〜「1.1.19」，「1.2.1」〜「1.2.10」等に対応する複数個のＭＩＢ値「V1.1.1」〜「V1.1.19」，「V1.2.1」〜「V1.2.10」等を含むインデックス情報である。同様に、４次元インデックス値等も採用され得る。なお、以下では、インデックス値の次元数に応じて、１次元インデックス情報、２次元インデックス情報、３次元インデックス情報等の用語を利用することがある。

例えば、プリンタ５０は、以下のようにして、２次元インデックス情報を利用することができる。例えば、複数のユーザがプリンタ５０を共用する状況を想定する。この場合、プリンタ５０は、個々のユーザに対して、２次元インデックス値のうちの上位の桁の値（例えば「2.3」のうちの「2」）を割り当てることができる。そして、プリンタ５０は、個々のユーザに関する各情報（例えば、ユーザ名、パスワード等）に対して、２次元インデックス値のうちの下位の桁の値（例えば「2.3」のうちの「3」）を割り当てることができる。これにより、プリンタ５０は、２次元インデックス情報を利用して、ユーザ毎に、当該ユーザに関する各情報を格納することができる。

なお、本実施例では、インデックス値として、連続する値（整数）が採用される。即ち、複数個の１次元インデックス値では、最小の値が「1」であり、以降の値が「2」、「3」・・・というように、１ずつインクリメントされる。また、複数個の２次元インデックス値では、最小の値が「1.1」であり、下位の桁の値が「1.2」、「1.3」・・・というように、１ずつインクリメントされる。また、上位の桁の値も、「1.1」、「2.1」、「3.1」・・・というように、１ずつインクリメントされる。同様に、３次元以上のインデックス値でも、連続する値が採用される。

なお、情報テーブル５２では、上側から下側に向かって各ベースＩＤの値が大きくなるように、各ＯＩＤが並んでいる。例えば、上側から下側に向かって、「1.3.6.1.4.1…1.2.3.1」、「1.3.6.1.4.1…1.2.3.2」、「1.3.6.1.4.1…1.2.3.3」・・・のように各ベースＩＤの値が大きくなる。また、情報テーブル５２では、上側から下側に向かって各インデックス値が大きくなるように、各ＯＩＤが並んでいる。例えば、１次元インデックス情報（ベースＩＤ「1.3.6.1.4.1…1.2.3.1」）では、上側から下側に向かって、「1」、「2」・・・「28」のように各インデックス値が大きくなる。従って、情報テーブル５２では、上側から下側に向かう程、大きい値を有するＯＩＤになる。

プリンタ５０のベンダは、プリンタ５０の情報テーブル５２内に格納されるべき各ベースＩＤについて、当該ベースＩＤに対応する１個の情報が、非インデックス情報であるのか、インデックス情報であるのか、を予め決定する。さらに、ベンダは、各インデックス情報について、当該インデックス情報が、何次元のインデックス情報であるのか、を予め決定する。そして、ベンダは、このようにして決定された内容に基づいて、次元数テーブル２６を作成して、ＰＣ等のための管理プログラムを準備する。即ち、次元数テーブル２６では、ベースＩＤと、当該ベースＩＤに対応する情報の次元数と、が関連付けられている。なお、ベースＩＤ「1.3.6.1.4.1…1.2.3.1」に関連付けられている次元数「０」は、当該ベースＩＤに対応する１個の情報が、非インデックス情報であることを示す。

（管理デバイス１０が実行する処理；図２）
続いて、図２を参照して、管理デバイス１０が実行する処理の内容を説明する。例えば、管理デバイス１０のユーザが、操作部１２を操作して、プリンタ５０から情報（即ち各ＭＩＢ値）を取得するための指示を管理デバイス１０に入力すると、制御部２０は、管理プログラムに従って、図２の処理を開始する。

Ｓ１０において、取得部３０は、次元数テーブル２６の中から、１個のベースＩＤを特定する。以下では、Ｓ１０で特定されるベースＩＤのことを「対象ベースＩＤ」と呼ぶ。また、以下では、対象ベースＩＤの具体的な値を「＊＊＊」で表現する。

次いで、Ｓ１２において、取得部３０は、対象ベースＩＤに対応する１個の情報、即ち、取得対象の情報が、インデックス情報であるのか、非インデックス情報であるのか、を判断する。具体的には、取得部３０は、次元数テーブル２６から、対象ベースＩＤに関連付けられている次元数を読み出して、当該次元数が「０」であれば、取得対象の情報が非インデックス情報である（Ｓ１２でＮＯ）と判断して、Ｓ１４に進む。また、取得部３０は、当該次元数が「０」であれば、取得対象の情報がインデックス情報である（Ｓ１２でＹＥＳ）と判断して、Ｓ２２に進む。

Ｓ１４では、準備部３２は、対象ベースＩＤ「＊＊＊」と、デフォルト値「0」と、を組み合わせて、ＯＩＤ「＊＊＊.0」を準備する。Ｓ１４では、準備部３２は、１個のＯＩＤ「＊＊＊.0」のみを準備する。例えば、対象ベースＩＤ「＊＊＊」が「1.3.6.1.4.1…1.2.3.1」（図１参照）である場合には、Ｓ１４では、準備部３２は、ＯＩＤ「1.3.6.1.4.1…1.2.3.1.0」を準備する。次いで、Ｓ１６において、送信部３４は、Ｓ１４で準備されたＯＩＤ「＊＊＊.0」を含むＧＥＴリクエストを、プリンタ５０に送信する。

なお、Ｓ１６で送信されるＧＥＴリクエストは、ＧＥＴＮＥＸＴリクエストやＧＥＴＢＵＬＫリクエストではなく、通常のＧＥＴリクエストである。通常のＧＥＴリクエストは、ＳＮＭＰｖ１で採用されているリクエストである。なお、ＧＥＴＢＵＬＫリクエストは、ＳＮＭＰｖ１で採用されておらず、ＳＮＭＰｖ２又はＳＮＭＰｖ３で採用されているリクエストである。ただし、ＳＮＭＰｖ２又はＳＮＭＰｖ３は、複雑なセキュリティ手法を採用しているために、利用し難い。従って、本実施例では、送信部３４が、Ｓ１６において、ＳＮＭＰｖ１の通常のＧＥＴリクエストを送信する構成を採用している。なお、後で説明するが、図３のＳ４２では、送信部３４は、ＧＥＴＮＥＸＴリクエストを送信する。ＧＥＴＮＥＸＴリクエストも、ＳＮＭＰｖ１で採用されているリクエストである。このように、本実施例では、比較的に利用し易いＳＮＭＰｖ１の管理プログラムに従って、通常のＧＥＴリクエスト又はＧＥＴＮＥＸＴリクエストを送信する構成を採用している。

プリンタ５０は、管理デバイス１０からＧＥＴリクエストを受信すると、ＧＥＴリクエストに含まれるＯＩＤ「＊＊＊.0」に対応するＭＩＢ値（以下では「対象ＭＩＢ値」と呼ぶ）が、情報テーブル５２内に格納されているのか否かを判断する。対象ＭＩＢ値が存在する場合には、プリンタ５０は、ＯＩＤ「＊＊＊.0」と、対象ＭＩＢ値と、を含むレスポンスを、管理デバイス１０に送信する。一方において、対象ＭＩＢ値が存在しない場合には、プリンタ５０は、対象ＭＩＢ値が存在しないことを示すコマンド「ＮｏＳｕｃｈ」を含むレスポンスを、管理デバイス１０に送信する。

Ｓ１８では、取得部３０は、プリンタ５０からレスポンスを受信することを監視する。取得部３０は、Ｓ１６でＧＥＴリクエストを送信してから所定時間が経過しても、レスポンスを受信することができない場合に、Ｓ１８でＮＯと判断して、Ｓ２４に進む。

例えば、対象ベースＩＤがベースＩＤ「1.3.6.1.4.1…1.2.3.1」（図１参照）である場合には、Ｓ１８において、取得部３０は、対象ＭＩＢ値「V0」を含むレスポンスを受信する（Ｓ１８でＹＥＳ）。この場合、Ｓ２０において、取得部３０は、Ｓ１４で準備されたＯＩＤと、レスポンスに含まれる対象ＭＩＢ値と、を対応付けて、メモリ２４内の所定の記憶領域に記憶させる。これにより、取得部３０は、プリンタ５０から非インデックス情報を取得して、非インデックス情報を上記の所定の記憶領域に記憶させることができる。なお、レスポンスが「ＮｏＳｕｃｈ」を含む場合には、Ｓ２０では、取得部３０は、Ｓ１４で準備されたＯＩＤと、「ＮｏＳｕｃｈ」を示す情報と、を対応付けて、上記の所定の記憶領域に記憶させる。Ｓ２０を終えると、Ｓ２４に進む。

なお、取得対象の情報がインデックス情報である場合（Ｓ１２でＹＥＳ）には、Ｓ２２において、取得部３０は、後述の図３のインデックス情報取得処理を実行する。Ｓ２２を終えると、Ｓ２４に進む。

Ｓ２４では、取得部３０は、次元数テーブル２６に含まれる全てのベースＩＤが、Ｓ１０で特定されたのか否かを判断する。全てのベースＩＤが特定されていない場合（Ｓ２４でＮＯ）には、取得部３０は、Ｓ１０に戻って、次元数テーブル２６から、次の対象ベースＩＤを特定する。全てのベースＩＤが特定された場合（Ｓ２４でＹＥＳ）には、図２の処理が終了する。なお、図示省略しているが、図２の処理が終了すると、制御部２０は、上記の所定の記憶領域に格納された各情報を、表示部１４に表示させる。これにより、ユーザは、プリンタ５０に関する様々な情報を見ることができる。

（インデックス情報取得処理；図３）
図３を参照して、図２のＳ２２のインデックス情報取得処理の内容を説明する。Ｓ４０において、準備部３２は、まず、対象ベースＩＤ「＊＊＊」のみを準備する。準備部３２は、さらに、次元数テーブル２６を参照して、対象ベースＩＤ「＊＊＊」に関連付けられている次元数を特定する。そして、準備部３２は、特定済みの次元数を用いて、９個のＯＩＤを準備する。具体的に言うと、準備部３２は、対象ベースＩＤ「＊＊＊」と、連続する９個のインデックス値「Idef」〜「Idef+8」のそれぞれと、を組合せて、９個のＯＩＤを準備する。ここで、「Idef」は、特定済みの次元数によって表現される最小のインデックス値である。例えば、特定済みの次元数が１次元である場合には、「Idef」は「1」である。同様に、特定済みの次元数が２次元、３次元である場合には、「Idef」は、それぞれ、「1.1」、「1.1.1」である。

例えば、特定済みの次元数が１次元である場合には、Ｓ４０において、準備部３２は、対象ベースＩＤ「＊＊＊」と、９個のＯＩＤ「＊＊＊.1」、「＊＊＊.2」・・・「＊＊＊.9」と、を準備する。なお、以下では、Ｓ４０で準備される対象ベースＩＤ「＊＊＊」そのもののことも、「ＯＩＤ」と呼ぶ。また、Ｓ４０で準備される各ＯＩＤのことを「対象ＯＩＤ」と呼ぶ。従って、上記の例では、Ｓ４０において、準備部３２は、１０個の対象ＯＩＤ「＊＊＊」、「＊＊＊.1」、「＊＊＊.2」・・・「＊＊＊.9」を準備する。同様に、例えば、特定済みの次元数が２次元である場合には、Ｓ４０において、準備部３２は、１０個の対象ＯＩＤ「＊＊＊」、「＊＊＊.1.1」、「＊＊＊.1.2」・・・「＊＊＊.1.9」を準備する。また、例えば、特定済みの次元数が３次元である場合には、Ｓ４０において、準備部３２は、１０個の対象ＯＩＤ「＊＊＊」、「＊＊＊.1.1.1」、「＊＊＊.1.1.2」・・・「＊＊＊.1.1.9」を準備する。

次いで、Ｓ４２において、送信部３４は、Ｓ４０で準備された１０個の対象ＯＩＤを含むＧＥＴＮＥＸＴリクエストを、プリンタ５０に送信する。ＧＥＴＮＥＸＴリクエストは、対象ＯＩＤの次のＯＩＤに対応するＭＩＢ値を取得するためのリクエストである。上記の「次のＯＩＤ」については、後で詳しく説明する。

プリンタ５０は、管理デバイス１０からＧＥＴＮＥＸＴリクエストを受信すると、ＧＥＴＮＥＸＴリクエストに含まれる１０個の対象ＯＩＤのそれぞれについて、当該対象ＯＩＤの次のＯＩＤを特定すると共に、当該次のＯＩＤに対応するＭＩＢ値を特定する。即ち、プリンタ５０は、１０個のＯＩＤを特定すると共に、１０個のＭＩＢ値を特定する。なお、本実施例では、上記の「次のＯＩＤ」を、以下のように定義する。

即ち、対象ＯＩＤが、対象ベースＩＤ「＊＊＊」のみによって表現されるＯＩＤである場合には、上記の「次のＯＩＤ」は、情報テーブル５２に存在する全てのＯＩＤのうち、対象ベースＩＤを含む最小のＯＩＤである。例えば、対象ＯＩＤが、図１の１次元インデックス情報に対応する「1.3.6.1.4.1…1.2.3.2」（即ち「＊＊＊」）である場合には、上記の「次のＯＩＤ」は、「1.3.6.1.4.1…1.2.3.2.1」（即ち「＊＊＊.1」）である。また、例えば、対象ＯＩＤが、図１の２次元インデックス情報に対応する「1.3.6.1.4.1…1.2.3.3」（即ち「＊＊＊」）である場合には、上記の「次のＯＩＤ」は、「1.3.6.1.4.1…1.2.3.3.1.1」（即ち「＊＊＊.1.1」）である。

また、対象ＯＩＤが、ベースＩＤとインデックス値との組合せのＯＩＤである場合には、上記の「次のＯＩＤ」は、情報テーブル５２に存在する全てのＯＩＤのうち、対象ＯＩＤよりも大きい最小のＯＩＤである。例えば、対象ＯＩＤが、図１の１次元インデックス情報に対応する「1.3.6.1.4.1…1.2.3.2.1」（即ち「＊＊＊.1」）である場合には、上記の「次のＯＩＤ」は、「1.3.6.1.4.1…1.2.3.2.2」（即ち「＊＊＊.2」）である。また、例えば、対象ＯＩＤが、図１の１次元インデックス情報に対応する「1.3.6.1.4.1…1.2.3.2.28」（即ち「＊＊＊.28」）である場合には、上記の「次のＯＩＤ」は、「1.3.6.1.4.1…1.2.3.3.1.1」（即ち「＃＃＃.1.1」）である。なお、上記の「＃＃＃（例えば1.3.6.1.4.1…1.2.3.3）」は、情報テーブル５２において、対象ベースＩＤ「＊＊＊（例えば1.3.6.1.4.1…1.2.3.2）」の一つ下に記述されているベースＩＤ（即ち、対象ベースＩＤの次のベースＩＤ）を示す。また、例えば、対象ＯＩＤが、情報テーブル５２内に存在しない「1.3.6.1.4.1…1.2.3.2.29」（即ち「＊＊＊.29」）である場合には、上記の「次のＯＩＤ」は、「1.3.6.1.4.1…1.2.3.3.1.1」（即ち「＃＃＃.1.1」）である。

１０個の対象ＯＩＤが、図１の１次元インデックス情報に対応する「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.2」）〜「＊＊＊.9」である場合には、プリンタ５０は、１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」を特定すると共に、１０個のＭＩＢ値「V1」〜「V10」を特定する。また、例えば、１０個の対象ＯＩＤが、図１の１次元インデックス情報に対応する「＊＊＊.20」〜「＊＊＊.29」である場合には、プリンタ５０は、１０個の対象ＯＩＤのうちの８個の対象ＯＩＤ「＊＊＊.20」〜「＊＊＊.27」について、ＯＩＤ「＊＊＊.21」〜「＊＊＊.28」を特定すると共に、ＭＩＢ値「V21」〜「V28」を特定する。プリンタ５０は、さらに、残りの２個の対象ＯＩＤ「＊＊＊.28」、「＊＊＊.29」について、同じＯＩＤ「＃＃＃.1.1（即ち「1.3.6.1.4.1…1.2.3.3.1.1」）」、「＃＃＃.1.1」を特定すると共に、同じＭＩＢ値「V1.1」、「V1.1」を特定する。プリンタ５０は、特定済みの１０個のＯＩＤと、特定済みの１０個のＭＩＢ値と、を含むレスポンスを、管理デバイス１０に送信する。

Ｓ４４では、取得部３０は、プリンタ５０からレスポンスを受信することを監視する。レスポンスが受信されない場合（Ｓ４４でＮＯ）には、図３の処理が終了する。レスポンスが受信された場合（Ｓ４４でＹＥＳ）には、Ｓ４６において、取得部３０は、レスポンスに含まれる１０個のＯＩＤと、レスポンスに含まれる１０個のＭＩＢ値と、を対応付けて、メモリ２４内の上記の所定の記憶領域に記憶させる。

次いで、Ｓ４８において、取得部３０は、対象ベースＩＤとは異なるベースＩＤを含むＯＩＤが、レスポンスに含まれるのか否かを判断する。上述したように、例えば、１０個の対象ＯＩＤが、図１の１次元インデックス情報に対応する「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.2」）〜「＊＊＊.9」である場合には、レスポンスは、１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」を含む。この場合、対象ベースＩＤ「＊＊＊」とは異なるベースＩＤを含むＯＩＤが、レスポンスに含まれないために、取得部３０は、Ｓ４８でＮＯと判断して、Ｓ５０に進む。

一方において、例えば、１０個の対象ＯＩＤが、図１の１次元インデックス情報に対応する「＊＊＊.20」（即ち「1.3.6.1.4.1…1.2.3.2.20」）〜「＊＊＊.29」である場合には、レスポンスは、１０個のＯＩＤ「＊＊＊.21」〜「＊＊＊.28」、「＃＃＃.1.1」（即ち「1.3.6.1.4.1…1.2.3.3.1.1」）、「＃＃＃.1.1」を含む。この場合、対象ベースＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.2」）とは異なるベースＩＤ「＃＃＃」（即ち「1.3.6.1.4.1…1.2.3.3」）を含むＯＩＤが、レスポンスに含まれるために、取得部３０は、Ｓ４８でＹＥＳと判断して、図３の処理を終了する。なお、Ｓ４８でＹＥＳの場合は、インデックス情報に含まれる複数個のＭＩＢ値の全てが取得されたことを意味する。この場合、図３の処理が終了する。

Ｓ５０では、準備部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「Imax」〜「Imax+9」のそれぞれと、を組合せて、１０個の対象ＯＩＤ「＊＊＊.Imax」〜「＊＊＊.Imax+9」を準備する。ここで、「Imax」は、前回のＳ４４の処理で受信されたレスポンスに含まれる最大のインデックス値である。より具体的に言うと、Ｓ５０では、準備部３２は、まず、前回のＳ４４で受信されたレスポンスに含まれる１０個のＯＩＤの中から、最大のインデックス値を有する最大のＯＩＤ「＊＊＊.Imax」を特定する。そして、準備部３２は、特定済みの最大のＯＩＤ「＊＊＊.Imax」から昇順で、１０個の対象ＯＩＤ「＊＊＊.Imax」〜「＊＊＊.Imax+9」を準備する。

例えば、前回のＳ４４の処理で受信されたレスポンスが、１０個のＯＩＤ「＊＊＊.1」（即ち「1.3.6.1.4.1…1.2.3.2.1」）〜「＊＊＊.10」（即ち「1.3.6.1.4.1…1.2.3.2.10」）を含む場合には、準備部３２は、最大のＯＩＤ「＊＊＊.10」を特定し、特定済みの最大のＯＩＤ「＊＊＊.10」から昇順で、１０個の対象ＯＩＤ「＊＊＊.10」〜「＊＊＊.19」を準備する。また、例えば、前回のＳ４４の処理で受信されたレスポンスが、１０個のＯＩＤ「＊＊＊.1.1」（即ち「1.3.6.1.4.1…1.2.3.3.1.1」）〜「＊＊＊.1.10」（即ち「1.3.6.1.4.1…1.2.3.3.1.10」）を含む場合には、準備部３２は、最大のＯＩＤ「＊＊＊.1.10」を特定し、特定済みの最大のＯＩＤ「＊＊＊.1.10」から昇順で、１０個の対象ＯＩＤ「＊＊＊.1.10」〜「＊＊＊.1.19」を準備する。

次いで、Ｓ４２において、送信部３４は、Ｓ５０で準備された１０個の対象ＯＩＤを含むＧＥＴＮＥＸＴリクエストを、プリンタ５０に送信する。Ｓ４４でＮＯ又はＳ４８でＹＥＳと判断されるまで、Ｓ４２〜Ｓ５０の処理が繰り返し実行される。

（１次元インデックス情報の取得例；図４）
図４は、管理デバイス１０が、図３のインデックス情報取得処理に従って、２８個の１次元インデックス値「1」〜「28」に対応する２８個のＭＩＢ値「V1」〜「V28」を取得する例を示す。なお、以下では、ＧＥＴＮＥＸＴリクエストのことを、簡単に、「リクエスト」と呼ぶ。

管理デバイス１０は、まず、１０個の対象ＯＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.2」）〜「＊＊＊.9」を準備して（図３のＳ４０）、１０個の対象ＯＩＤ「＊＊＊」〜「＊＊＊.9」を含むリクエストＲｅｑ１をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」と、１０個のＭＩＢ値「V1」〜「V10」と、を含むレスポンスＲｅｓ１を、プリンタ５０から受信する。

次いで、管理デバイス１０は、１０個の対象ＯＩＤ「＊＊＊.10」〜「＊＊＊.19」を準備して（図３のＳ５０）、１０個の対象ＯＩＤ「＊＊＊.10」〜「＊＊＊.19」を含むリクエストＲｅｑ２をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.11」〜「＊＊＊.20」と、１０個のＭＩＢ値「V11」〜「V20」と、を含むレスポンスＲｅｓ２を、プリンタ５０から受信する。

次いで、管理デバイス１０は、１０個の対象ＯＩＤ「＊＊＊.20」〜「＊＊＊.29」を準備して（図３のＳ５０）、１０個の対象ＯＩＤ「＊＊＊.20」〜「＊＊＊.29」を含むリクエストＲｅｑ３をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.21」〜「＊＊＊.28」、「＃＃＃.1.1」（即ち「1.3.6.1.4.1…1.2.3.3.1.1」）、「＃＃＃.1.1」と、１０個のＭＩＢ値「V21」〜「V28」、「V1.1」、「V1.1」と、を含むレスポンスＲｅｓ３を、プリンタ５０から受信する。対象ベースＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.2」）とは異なるベースＩＤ「＃＃＃」（即ち「1.3.6.1.4.1…1.2.3.3」）を含むＯＩＤ「＃＃＃.1.1」が、レスポンスＲｅｓ３に含まれるために、管理デバイス１０は、図３のＳ４８でＹＥＳと判断して、図３のインデックス情報取得処理を終了する。

仮に、１０個の対象ＯＩＤを含むリクエストを送信せずに、１個の対象ＯＩＤのみを含むリクエストをプリンタ５０に送信する構成（以下では「比較例の構成」と呼ぶ）を採用すると、管理デバイスは、１次元インデックス情報に含まれる２８個のＭＩＢ値をプリンタ５０から取得するのに、２８個のリクエストをプリンタ５０に送信する必要がある。これに対し、本実施例では、図４に示されるように、管理デバイス１０は、２８個のＭＩＢ値をプリンタ５０から取得するのに、３個のリクエストＲｅｑ１〜Ｒｅｑ３をプリンタ５０に送信すれば足りる。従って、管理デバイス１０は、比較例の構成と比べて、インデックス情報を効率良く取得することができる。

（２次元インデックス情報の取得例；図５）
図５は、管理デバイス１０が、図３のインデックス情報取得処理に従って、４３個の２次元インデックス値「1.1」〜「1.25」、「2.1」〜「1.18」に対応する４３個のＭＩＢ値「V1.1」〜「V1.25」、「V2.1」〜「V2.18」を取得する例を示す。なお、図５では、ＯＩＤ内のインデックス値のうちの四角で囲まれた値は、当該インデックス値のうちの上位の桁の値（即ち２次元目の桁の値）を示す。従って、ＯＩＤ内のインデックス値のうちの四角で囲まれていない値は、当該インデックス値のうちの下位の桁の値（即ち１次元目の桁の値）を示す。

管理デバイス１０は、まず、１０個の対象ＯＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.3」）〜「＊＊＊.1.9」を準備する（図３のＳ４０）。即ち、管理デバイス１０は、ベースＩＤのみによって表現される１個のＯＩＤ「＊＊＊」と、９個のインデックス値「1.1」〜「1.9」を有する９個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.9」と、を準備する。ここで、９個のインデックス値「1.1」〜「1.9」は、上位の桁の値（即ち２次元目の桁の値）として「1」を有すると共に、下位の桁の値（即ち１次元目の桁の値）として連続する値「1」〜「9」を有する。

管理デバイス１０は、１０個の対象ＯＩＤ「＊＊＊」〜「＊＊＊.1.9」を含むリクエストＲｅｑ１１をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.10」と、１０個のＭＩＢ値「V1.1」〜「V1.10」と、を含むレスポンスＲｅｓ１１を、プリンタ５０から受信する。レスポンスＲｅｓ１１内の全てのインデックス値「1.1」〜「1.10」は、上位の桁の値として「1」を有する。即ち、レスポンスＲｅｓ１１内の全てのインデックス値「1.1」〜「1.10」は、リクエストＲｅｑ１１内の各インデックス値「1.1」、「1.2」等の上位の桁の値「1」と同じ値「1」を、上位の桁の値として有する。以下では、このようなレスポンスＲｅｓ１１（即ち、レスポンス内の全てのインデックス値が、リクエスト内の各インデックス値の上位の桁の値と同じ値を、上位の桁の値として有するレスポンス）を受信するケースのことを、「同値のケース」と呼ぶ。

管理デバイス１０は、レスポンスＲｅｓ１１内の１０個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.10」のうち、最大のインデックス値「1.10」を有する最大のＯＩＤ「＊＊＊.1.10」を特定して、最大のＯＩＤ「＊＊＊.1.10」から昇順で１０個の対象ＯＩＤ「＊＊＊.1.10」〜「＊＊＊.1.19」を新たに準備する（図３のＳ５０）。即ち、上記の同値のケースでは、新たに準備される各インデックス値「1.10」〜「1.19」は、前回のリクエストＲｅｑ１１内の各インデックス値「1.1」〜「1.9」の上位の桁の値「1」と同じ値「1」を、上位の桁の値として有する。また、新たに準備される各インデックス値「1.10」〜「1.19」のうちの最小のインデックス値「1.10」は、前回のリクエストＲｅｑ１１内の各インデックス値「1.1」〜「1.9」のうちの最大のインデックス値「1.9」に連続する値である。

管理デバイス１０は、新たに準備された１０個の対象ＯＩＤ「＊＊＊.1.10」〜「＊＊＊.1.19」を含むリクエストＲｅｑ１２をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」と、１０個のＭＩＢ値「V1.11」〜「V1.20」と、を含むレスポンスＲｅｓ１２を、プリンタ５０から受信する。このレスポンスＲｅｓ１２は、上記の同値のケースである。

管理デバイス１０は、レスポンスＲｅｓ１２内の１０個のＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」のうち、最大のインデックス値「1.20」を有する最大のＯＩＤ「＊＊＊.1.20」を特定して、最大のＯＩＤ「＊＊＊.1.20」から昇順で１０個の対象ＯＩＤ「＊＊＊.1.20」〜「＊＊＊.1.29」を新たに準備する（図３のＳ５０）。

管理デバイス１０は、新たに準備された１０個の対象ＯＩＤ「＊＊＊.1.20」〜「＊＊＊.1.29」を含むリクエストＲｅｑ１３をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.1.21」〜「＊＊＊.1.25」、「＊＊＊.2.1」、「＊＊＊.2.1」「＊＊＊.2.1」「＊＊＊.2.1」「＊＊＊.2.1」と、１０個のＭＩＢ値「V1.21」〜「V1.25」、「V2.1」、「V2.1」、「V2.1」、「V2.1」、「V2.1」と、を含むレスポンスＲｅｓ１３を、プリンタ５０から受信する。このレスポンスＲｅｓ１３内のインデックス値「2.1」は、リクエストＲｅｑ１３内の各インデックス値「1.20」〜「1.29」の上位の桁の値「1」とは異なる値「2」を、上位の桁の値として有する。以下では、このようなレスポンスＲｅｓ１３（即ち、リクエスト内の各インデックス値の上位の桁の値とは異なる値を、上位の桁の値として有するインデックス値を含むレスポンス）を受信するケースのことを、「異値のケース」と呼ぶ。また、このようなインデックス値「2.1」（即ち、リクエスト内の各インデックス値の上位の桁の値とは異なる値を、上位の桁の値として有するインデックス値）のことを、「特定のインデックス値」と呼ぶ。

管理デバイス１０は、レスポンスＲｅｓ１３内の１０個のＯＩＤ「＊＊＊.1.21」〜「＊＊＊.1.25」、「＊＊＊.2.1」等のうち、最大のインデックス値「2.1」を有する最大のＯＩＤ「＊＊＊.2.1」を特定して、最大のＯＩＤ「＊＊＊.2.1」から昇順で１０個の対象ＯＩＤ「＊＊＊.2.1」〜「＊＊＊.2.10」を新たに準備する（図３のＳ５０）。即ち、上記の異値のケースでは、新たに準備される各インデックス値「2.1」〜「2.10」は、前回のレスポンスＲｅｓ１３内の上記の特定のインデックス値「2.1」の上位の桁の値「2」と同じ値「2」を、上位の桁の値として有する。

管理デバイス１０は、新たに準備された１０個の対象ＯＩＤ「＊＊＊.2.1」〜「＊＊＊.2.10」を含むリクエストＲｅｑ１４をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.2.2」〜「＊＊＊.2.11」と、１０個のＭＩＢ値「V2.2」〜「V2.11」と、を含むレスポンスＲｅｓ１４を、プリンタ５０から受信する。このレスポンスＲｅｓ１４は、上記の同値のケースである。

次いで、管理デバイス１０は、新たに準備された１０個の対象ＯＩＤ「＊＊＊.2.11」〜「＊＊＊.2.20」を含むリクエストＲｅｑ１５をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.2.12」〜「＊＊＊.2.18」、「＃＃＃.1.1.1」（即ち「1.3.6.1.4.1…1.2.3.4.1.1.1」）、「＃＃＃.1.1.1」、「＃＃＃.1.1.1」と、１０個のＭＩＢ値「V2.12」〜「V2.18」、「V1.1.1」、「V1.1.1」、「V1.1.1」と、を含むレスポンスＲｅｓ１５を、プリンタ５０から受信する。対象ベースＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.3」）とは異なるベースＩＤ「＃＃＃」（即ち「1.3.6.1.4.1…1.2.3.4」）を含むＯＩＤ「＃＃＃.1.1.1」が、レスポンスＲｅｓ１５に含まれるために、管理デバイス１０は、図３のＳ４８でＹＥＳと判断して、図３のインデックス情報取得処理を終了する。

図５に示されるように、本実施例では、管理デバイス１０は、２次元インデックス情報に含まれる４３個のＭＩＢ値をプリンタ５０から取得するのに、５個のリクエストＲｅｑ１１〜Ｒｅｑ１５をプリンタ５０に送信すれば足りる。従って、管理デバイス１０は、インデックス情報を効率良く取得することができる。

（３次元インデックス情報の取得例；図６）
図６は、管理デバイス１０が、図３のインデックス情報取得処理に従って、４８個の３次元インデックス値「1.1.1」〜「1.1.19」等に対応する４８個のＭＩＢ値「V1.1.1」〜「V1.1.19」等を取得する例を示す。図６でも、図５と同様に、四角で囲まれた値は、上位の桁の値（即ち２次元目及び３次元目の桁の値）であり、四角で囲まれていない値は、下位の桁の値（即ち１次元目の桁の値）を示す。

図６の取得例では、インデックス値のうちの２次元目及び３次元目の桁の値を、上位の桁の値として考慮する点を除くと、図５の取得例と同様である。例えば、レスポンスＲｅｓ２１内の全てのインデックス値「1.1.1」〜「1.1.10」の上位の桁の値「1.1」は、リクエストＲｅｑ２１内の各インデックス値「1.1.1」〜「1.1.9」の上位の桁の値「1.1」と同じである。即ち、レスポンスＲｅｓ２１は、上記の同値のケースである。このために、リクエストＲｅｑ２２内の各インデックス値「1.1.10」〜「1.1.19」は、前回のリクエストＲｅｑ２１内の各インデックス値「1.1.1」〜「1.1.10」の上位の桁の値「1.1」と同じ値「1.1」を、上位の桁の値として有する。また、リクエストＲｅｑ２２内の各インデックス値「1.1.10」〜「1.1.19」のうちの最小のインデックス値「1.1.10」は、前回のリクエストＲｅｑ２１内の各インデックス値「1.1.1」〜「1.1.9」のうちの最大のインデックス値「1.1.9」に連続する値である。

また、レスポンスＲｅｓ２２内のインデックス値「1.2.1」の上位の桁の値「1.2」は、リクエストＲｅｑ２２内の各インデックス値「1.1.10」〜「1.1.19」の上位の桁の値「1.1」とは異なる。即ち、レスポンスＲｅｓ２２は、上記の異値のケースである。また、上記のインデックス値「1.2.1」は、上記の特定のインデックス値である。このために、リクエストＲｅｑ２３内の各インデックス値「1.2.1」〜「1.2.10」は、上記の特定のインデックス値「1.2.10」の上位の桁の値「1.2」と同じ値「1.2」を、上位の桁の値として有する。

同様に、レスポンスＲｅｓ２３及びレスポンスＲｅｓ２４も、上記の異値のケースである。さらに、レスポンスＲｅｓ２５は、対象ベースＩＤ「＊＊＊」（即ち「1.3.6.1.4.1…1.2.3.4」）とは異なるベースＩＤ「＃＃＃」（例えば「1.3.6.1.4.1…1.2.3.5」）を含むＯＩＤ「＃＃＃」を含む。このために、管理デバイス１０は、図３のＳ４８でＹＥＳと判断して、図３のインデックス情報取得処理を終了する。

図６に示されるように、本実施例では、管理デバイス１０は、３次元インデックス情報に含まれる４８個のＭＩＢ値をプリンタ５０から取得するのに、５個のリクエストＲｅｑ２１〜Ｒｅｑ２５をプリンタ５０に送信すれば足りる。従って、管理デバイス１０は、インデックス情報を効率良く取得することができる。

（第１実施例の効果）
上述したように、本実施例によると、管理デバイス１０は、インデックス情報を効率よく取得することができる。特に、図５及び図６に示されるように、管理デバイス１０は、２次元以上のインデックス情報を取得する際に、上記の同値のケースでも、上記の異値のケースでも、次のリクエストに含まれるべき各ＯＩＤを適切に準備して、各ＭＩＢ値を一括して適切に取得することができる。

なお、管理デバイス１０は、１個のリクエストに含まれるＯＩＤの数を、「１０」よりも大きくすれば、より少ない通信回数で各ＭＩＢ値を取得することができる。例えば、図４の取得例において、１００個のＯＩＤを含むリクエストを送信する構成を採用すれば、管理デバイス１０は、１回の通信で２８個のＭＩＢ値の全てを取得することができる。しかしながら、例えば、多数個のＯＩＤ（例えば１００個のＯＩＤ）を含むリクエストを送信する構成を採用すると、レスポンスのパケットのサイズが上限を超え得る。この場合、レスポンスのパケットを分割する必要があり、通信効率が悪い。また、この場合、プリンタ５０の処理負荷も大きい。従って、本実施例では、１個のリクエストに含まれるＯＩＤの数が、あまり過大にならないように、「１０」に設定されている。

上述したように、１個のリクエストに含まれるＯＩＤの数が過大にならように設定されているために、管理デバイス１０は、１個のインデックス情報に含まれる複数個のＭＩＢ値を取得するのに、複数個のリクエストを送信する可能性が高い。例えば、図４の取得例では、３個のリクエストを送信する必要がある。ただし、管理デバイス１０は、図４の取得例に従って各ＭＩＢ値を取得すれば、１次元インデックス情報が、２８個のインデックス値「1」〜「28」に対応する２８個のＭＩＢ値「V1」〜「V28」を含むことを把握することができる。従って、管理デバイス１０（即ち取得部３０）は、２回目以降のインデックス情報取得処理を実行する際に、２８個のＯＩＤ「＊＊＊」〜「＊＊＊.27」を含むリクエストをプリンタ５０に送信して、２８個のＭＩＢ値「V1」〜「V28」を一括して取得してもよい。同様に、管理デバイス１０は、２次元以上のインデックス情報に含まれるＭＩＢ値の数を把握すれば、２回目以降のインデックス情報取得処理を実行する際に、把握済みの複数個のＭＩＢ値を一括して取得するための複数個のＯＩＤを含むリクエストをプリンタ５０に送信して、複数個のＭＩＢ値を一括して取得してもよい。ただし、上述したように、例えば、プリンタ５０がエラー履歴等を累積して格納する場合には、インデックス情報に含まれるＭＩＢ値の数（即ちインデックス値の数）が変化し得るために、管理デバイス１０は、２回目以降のインデックス情報取得処理を実行する際にも、図３の処理を実行することが好ましい。管理デバイス１０が、プリンタ５０に新たに格納されたＯＩＤに対応するＭＩＢ値を、適切に取得することができるからである。

（対応関係）
プリンタ５０が、「対象デバイス」の一例である。対象ベースＩＤ、ＯＩＤが、それぞれ、「対象ＩＤ」、「組合せＩＤ」の一例である。例えば、図５の２次元インデックス情報では、４３個のインデックス値、４３個のＭＩＢ値が、それぞれ、「Ｋ次元の複数個のインデックス値」、「複数個の部分対象情報」の一例である。

例えば、図５のリクエストＲｅｑ１３が、「第１のＧＥＴＮＥＸＴリクエスト」の一例である。この場合、１０個のＯＩＤ「＊＊＊.1.20」〜「＊＊＊.1.29」、１０個のインデックス値「1.20」〜「1.29」、これらのインデックス値のうちの上位の桁の値「1」が、それぞれ、「第１グループのＭａ個の組合せＩＤ」、「Ｍａ個のインデックス値」、「第１の値」の一例である。また、レスポンスＲｅｓ１３内の１０個のＯＩＤ「＊＊＊.1.21」〜「＊＊＊.1.25」、「＊＊＊.2.1」等、レスポンスＲｅｓ１３内の１０個のＭＩＢ値「V1.21」〜「V1.25」、「V2.1」等が、それぞれ、「第２グループのＭａ個の組合せＩＤ」、「Ｍａ個の部分対象情報」の一例である。また、ＯＩＤ「＊＊＊.2.1」、インデックス値「2.1」、このインデックス値のうちの上位の桁の値「2」、ＭＩＢ値「V2.1」が、それぞれ、「特定の組合せＩＤ」、「特定のインデックス値」、「第２の値」、「特定の部分対象情報」の一例である。そして、リクエストＲｅｑ１４、１０個のＯＩＤ「＊＊＊.2.1」〜「＊＊＊.2.10」が、それぞれ、「第２のＧＥＴＮＥＸＴリクエスト」、「Ｍｂ個の組合せＩＤ」の一例である。

また、例えば、図５のリクエストＲｅｑ１２が、「第１のＧＥＴＮＥＸＴリクエスト」の一例である。この場合、１０個のＯＩＤ「＊＊＊.1.10」〜「＊＊＊.1.19」、１０個のインデックス値「1.10」〜「1.19」が、それぞれ、「第１グループのＭａ個の組合せＩＤ」、「Ｍａ個のインデックス値」の一例である。また、レスポンスＲｅｓ１２内の１０個のＭＩＢ値「V1.11」〜「V1.20」が、「Ｍａ個の部分対象情報」の一例である。そして、リクエストＲｅｑ１３、１０個のＯＩＤ「＊＊＊.1.20」〜「＊＊＊.1.29」が、それぞれ、「第３のＧＥＴＮＥＸＴリクエスト」、「Ｍｃ個の組合せＩＤ」の一例である。

（第１実施例の変形例；図７）
上述したように、第１実施例では、プリンタ５０の情報テーブル５２において、ベースＩＤと、連続する各インデックス値と、の組合せの各ＯＩＤが利用されることが前提となっている。ただし、ベースＩＤと、連続しない各インデックス値と、の組合せの各ＯＩＤが利用される場合でも、第１実施例の図３のフローチャートを適用することができる。

例えば、図７に示される複数個のＯＩＤに対応する複数個のＭＩＢ値を取得する状況を想定する。ここで、複数個のＯＩＤ（複数個のＭＩＢ値）は、「＊＊＊.1.8」〜「＊＊＊.1.10」（「V1.8」〜「V1.10」）を含まない。即ち、ベースＩＤ「＊＊＊」と、連続しない各インデックス値「1.1」〜「1.7」、「1.11」〜「1.20」と、の組合せの各ＯＩＤが利用されている。

管理デバイス１０は、まず、１０個の対象ＯＩＤ「＊＊＊」〜「＊＊＊.1.9」を含むリクエストＲｅｑ３１をプリンタ５０に送信する（図３のＳ４２）。この場合、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.7」、「＊＊＊.1.11」、「＊＊＊.1.11」、「＊＊＊.1.11」と、１０個のＭＩＢ値「V1.1」〜「V1.7」、「V1.11」、「V1.11」、「V1.11」と、を含むレスポンスＲｅｓ３１を、プリンタ５０から受信する。

管理デバイス１０は、レスポンスＲｅｓ３１内の１０個のＯＩＤのうち、最大のインデックス値「1.11」を有する最大のＯＩＤ「＊＊＊.1.11」を特定して、最大のＯＩＤ「＊＊＊.1.11」から昇順で１０個の対象ＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」を新たに準備する（図３のＳ５０）。そして、管理デバイス１０は、新たに準備された１０個の対象ＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」を含むリクエストＲｅｑ３２をプリンタ５０に送信する（図３のＳ４２）。この後のレスポンスＲｅｓ３２、リクエストＲｅｑ３３、レスポンスＲｅｓ３３については、図５等と同様である。

図７に示されるように、管理デバイス１０は、図３のフローチャートに従って処理を実行すれば、ベースＩＤと、連続しない各インデックス値と、の組合せの各ＯＩＤが利用される場合でも、各ＭＩＢ値を適切に取得することができる。

（第２実施例）
第１実施例とは異なる点を説明する。本実施例では、図２のＳ２２のインデックス情報取得処理の内容が、第１実施例とは異なる。取得対象の情報が１次元インデックス情報である場合には、取得部３０は、第１実施例と同様に、図３のインデックス情報取得処理に従って、各ＭＩＢ値を取得する。一方において、取得対象の情報が２次元インデックス情報である場合には、取得部３０は、図８のインデックス情報取得処理に従って、各ＭＩＢ値を取得する。

（２次元以上のインデックス情報取得処理；図８）
図８のＳ６０〜Ｓ６８は、図３のＳ４０〜Ｓ４８と同様である。Ｓ６８でＮＯの場合には、Ｓ７０において、判断部３６は、前回のＳ６４の処理で受信されたレスポンス内の１０個のＯＩＤの中に、上記の特定のインデックス値（即ち、リクエスト内の各インデックス値の上位の桁の値とは異なる値を、上位の桁の値として有するインデックス値）を有するＯＩＤが含まれるのか否かを判断する。即ち、判断部３６は、上記の同値のケースであるのか（Ｓ７０でＮＯ）、上記の異値のケースであるのか（Ｓ７０でＹＥＳ）、を判断する。

なお、以下では、リクエスト内の各インデックス値の上位の桁の値のことを「Vreq」と表現し、レスポンス内の上記の特定のインデックス値の上位の桁の値のことを「Vres」と表現する。例えば、図９に示される取得例のリクエストＲｅｑ４１〜Ｒｅｑ４３では、Vreqは「1」である。そして、レスポンスＲｅｓ４３内のインデックス値「2.1」が、上記の特定のインデックス値であり、この場合、Vresは「2」である。

上記の同値のケースであると判断される場合（Ｓ７０でＮＯの場合）には、Ｓ７２において、準備部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「Vreq.Vmax+1」〜「Vreq.Vmax+10」のそれぞれと、を組合せて、１０個の対象ＯＩＤ「＊＊＊.Vreq.Vmax+1」〜「＊＊＊.Vreq.Vmax+10」を準備する。ここで、「Vmax」は、前回のＳ６２の処理で送信されたリクエストに含まれる最大のインデックス値である。例えば、図９のリクエストＲｅｑ４１及びレスポンスＲｅｓ４１の通信が終了した時点では、Vreqは「1」であり、Vmaxは「9」である。この場合、Ｓ７２において、準備部３２は、１０個の対象ＯＩＤ「＊＊＊.1.10」〜「＊＊＊.19」を準備する。次いで、Ｓ６２において、送信部３４は、１０個の対象ＯＩＤ「＊＊＊.1.10」〜「＊＊＊.19」を含むリクエストをプリンタ５０に送信する（図９のリクエストＲｅｑ４２参照）。

一方において、上記の異値のケースであると判断される場合（Ｓ７０でＹＥＳの場合）には、Ｓ７４において、準備部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「Vres.1」〜「Vres.10」のそれぞれと、を組合せて、１０個の対象ＯＩＤ「＊＊＊. Vres.1」〜「＊＊＊.Vres+10」を準備する。例えば、図９のリクエストＲｅｑ４３及びレスポンスＲｅｓ４３の通信が終了した時点では、Vresは「２」である。この場合、Ｓ７４において、準備部３２は、１０個の対象ＯＩＤ「＊＊＊.2.1」〜「＊＊＊.2.10」を準備する。次いで、Ｓ６２において、送信部３４は、１０個の対象ＯＩＤ「＊＊＊.2.1」〜「＊＊＊.2.10」を含むリクエスト（図９のリクエストＲｅｑ４４）をプリンタ５０に送信する。

Ｓ６４でＮＯ又はＳ６８でＹＥＳと判断されるまで、Ｓ６２〜Ｓ７４の処理が繰り返し実行される。図９の取得例では、図９のリクエストＲｅｑ４１〜Ｒｅｑ４５及びレスポンスＲｅｓ４１〜Ｒｅｓ４５の通信が終了すると、Ｓ６８でＹＥＳと判断される。

（第２実施例の効果）
本実施例の図９の取得例と、第１実施例の図５の取得例と、を比べると明らかなように、本実施例の図８のインデックス情報取得処理を実行しても、第１実施例の図３のインデックス情報取得処理を実行する場合と同じ結果が得られる。本実施例でも、管理デバイス１０は、２次元以上のインデックス情報を取得する際に、上記の同値のケース（図８のＳ７０でＮＯ）でも、上記の異値のケース（図８のＳ７０でＹＥＳ）でも、次のリクエストに含まれるべき各ＯＩＤを適切に準備して、各ＭＩＢ値を適切に取得することができる。

以上、本発明の具体例を詳細に説明したが、これらは例示にすぎず、特許請求の範囲を限定するものではない。特許請求の範囲に記載の技術には、以上に例示した具体例を様々に変形、変更したものが含まれる。例えば、以下の変形例が含まれる。

（変形例１）「Ｍａ」、「Ｍｂ」、「Ｍｃ」は、上記の各実施例のように「１０」でなくてもよく、２以上の整数であれば、どのような値であってもよい。また、「Ｍａ」、「Ｍｂ」、「Ｍｃ」は、上記の各実施例のように同じ値「１０」でなくてもよく、互いに異なる値であってもよい。

（変形例２）上記の第２実施例では、図８のＳ７０において、判断部３６は、レスポンス内の１０個のＯＩＤの中に、特定のインデックス値（上位の桁の値がVresであるインデックス値）を有するＯＩＤが含まれるのか否かを判断している。これに代えて、判断部３６は、以下の（手法Ａ）〜（手法Ｃ）のいずれかを利用して、Ｓ７０の判断を実行してもよい。（手法Ａ）判断部３６は、レスポンス内の１０個のＯＩＤの中に、２個以上の同じＯＩＤ（例えば、図９のレスポンスＲｅｓ４３内の５個のＯＩＤ「＊＊＊.2.1」）が含まれる場合に、Ｓ７０でＹＥＳと判断してもよい。（手法Ｂ）判断部３６は、レスポンス内の１０個のＭＩＢ値の中に、２個以上の同じＭＩＢ値（例えば、図９のレスポンスＲｅｓ４３内の５個のＭＩＢ値「V2.1」）が含まれる場合に、Ｓ７０でＹＥＳと判断してもよい。（手法Ｃ）判断部３６は、レスポンス内の１０個のインデックス値の下位の桁の値が連続しない場合（例えば、図９のレスポンスＲｅｓ４３では、「1.21」〜「1.25」が連続しているが、「1.25」と「2.1」（又は「2.1」と「2.1」）が連続していない）に、Ｓ７０でＹＥＳと判断してもよい。即ち、判断部３６は、第２実施例のＳ７０の手法、及び、上記の（手法Ａ）〜（手法Ｃ）のうちのいずれかの手法を利用して、Ｍａ個の部分対象情報が、特定の部分対象情報を含むのか否かを判断すればよい。

上述したように、第１実施例では、第２実施例のような判断（図８のＳ７０の判断）を実行せずに、図３のＳ５０において、準備部３２は、最大のインデックス値「Imax」を有する最大のＯＩＤ「＊＊＊.Imax」を特定して、最大のＯＩＤから昇順で各ＯＩＤ「＊＊＊.Imax」〜「＊＊＊.Imax+9」を準備する。一方において、第２実施例では、準備部３２は、図８のＳ７０の判断に応じて、各ＯＩＤを準備する（Ｓ７２、Ｓ７４）。そして、上述したように、図８のＳ７０の判断は、第２実施例の手法に限られず、上記の（手法Ａ）〜（手法Ｃ）の判断であってもよい。一般的に言うと、第１実施例、第２実施例、及び、上記の（手法Ａ）〜（手法Ｃ）のいずれの手法も、「準備部は、・・・Ｍｂ個の組合せＩＤを準備し」という構成に含まれる。

（変形例３）「対象デバイス」は、プリンタに限られず、他の種類のデバイス（例えば、ＰＣ、サーバ、多機能機、コピー機、スキャナ、ＦＡＸ装置等）であってもよい。

（変形例４）上記の各実施例では、管理デバイス１０のＣＰＵ２２がソフトウェアに従って処理を実行することによって、各部３０〜３６の機能が実現される。これに代えて、各部３０〜３６の機能のうちの少なくとも一部は、論理回路等のハードウェアによって実現されてもよい。

また、本明細書または図面に説明した技術要素は、単独であるいは各種の組合せによって技術的有用性を発揮するものであり、出願時請求項記載の組合せに限定されるものではない。また、本明細書または図面に例示した技術は複数目的を同時に達成するものであり、そのうちの一つの目的を達成すること自体で技術的有用性を持つものである。

２：管理システム、１０：管理デバイス、２０：制御部、２４：メモリ、２６：次元数テーブル、５０：プリンタ、５２：情報テーブル、Ｒｅｑ１〜Ｒｅｑ３，Ｒｅｑ１１〜Ｒｅｑ１５：ＧＥＴＮＥＸＴリクエスト、Ｒｅｓ１〜Ｒｅｓ３，Ｒｅｓ１１〜Ｒｅｓ１５：レスポンス、Ｖ１〜Ｖ２８，Ｖ１．１〜Ｖ１．２５，Ｖ２．１〜Ｖ２．１８：ＭＩＢ値

Claims

管理対象の対象デバイスを管理する管理デバイスであって、
取得対象の対象情報に対応するＩＤである対象ＩＤを含むリクエストを前記対象デバイスに送信して、前記対象デバイスから前記対象情報を取得する取得部を備え、
前記取得部は、
前記対象情報が、Ｋ次元（Ｋは２以上の整数）の複数個のインデックス値に対応する複数個の部分対象情報を含む場合に、第１グループのＭａ個（Ｍａは２以上の整数）の組合せＩＤを準備する準備部であって、前記第１グループのＭａ個の組合せＩＤのそれぞれは、前記対象ＩＤと、連続するＭａ個のインデックス値のそれぞれと、の組合せであり、前記Ｍａ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有する、前記準備部と、
前記第１グループのＭａ個の組合せＩＤを含む第１のＧＥＴＮＥＸＴリクエストを前記対象デバイスに送信する送信部と、を備え、
前記準備部は、さらに、前記第１のＧＥＴＮＥＸＴリクエストを送信した結果として、前記対象デバイスから取得されるＭａ個の部分対象情報が、前記対象ＩＤと、上位の桁の値として前記第１の値とは異なる第２の値を有する特定のインデックス値と、の組合せである特定の組合せＩＤに対応する特定の部分対象情報を含む第１の場合に、Ｍｂ個（Ｍｂは２以上の整数）の組合せＩＤを準備し、
前記Ｍｂ個の組合せＩＤのそれぞれは、前記対象ＩＤと、連続するＭｂ個のインデックス値のそれぞれと、の組合せであり、
前記Ｍｂ個のインデックス値は、上位の桁の値として前記第２の値を有すると共に、下位の桁の値として連続する値を有し、
前記送信部は、さらに、前記第１の場合に、前記Ｍｂ個の組合せＩＤを含む第２のＧＥＴＮＥＸＴリクエストを前記対象デバイスに送信する、
管理デバイス。
前記準備部は、さらに、前記Ｍａ個の部分対象情報が、前記特定の部分対象情報を含まない第２の場合に、Ｍｃ個（Ｍｃは２以上の整数）の組合せＩＤを準備し、
前記Ｍｃ個の組合せＩＤのそれぞれは、前記対象ＩＤと、連続するＭｃ個のインデックス値のそれぞれと、の組合せであり、
前記Ｍｃ個のインデックス値は、上位の桁の値として前記第１の値を有すると共に、下位の桁の値として連続する値を有し、
前記Ｍｃ個のインデックス値のうちの最小のインデックス値は、前記Ｍａ個のインデックス値のうちの最大のインデックス値に連続する値であり、
前記送信部は、さらに、前記第２の場合に、前記Ｍｃ個の組合せＩＤを含む第３のＧＥＴＮＥＸＴリクエストを前記対象デバイスに送信する、請求項１に記載の管理デバイス。
前記取得部は、前記第１のＧＥＴＮＥＸＴリクエストを送信した結果として、前記対象デバイスから、前記Ｍａ個の部分対象情報と共に、前記Ｍａ個の部分対象情報に対応する第２グループのＭａ個の組合せＩＤを取得し、
前記準備部は、前記第１の場合に、前記第２グループのＭａ個の組合せＩＤの中から、最大のインデックス値を有する最大の組合せＩＤを特定して、前記最大の組合せＩＤから昇順で前記Ｍｂ個の組合せＩＤを準備する、請求項１又は２に記載の管理デバイス。
前記取得部は、さらに、前記Ｍａ個の部分対象情報が、前記特定の部分対象情報を含むのか否かを判断する判断部を備える、請求項１又は２に記載の管理デバイス。
前記取得部は、前記第１のＧＥＴＮＥＸＴリクエストを送信した結果として、前記対象デバイスから、前記Ｍａ個の部分対象情報と共に、前記Ｍａ個の部分対象情報に対応する第２グループのＭａ個の組合せＩＤを取得し、
前記判断部は、前記第２グループのＭａ個の組合せＩＤが、前記特定の組合せＩＤを含むのか否かを判断することによって、前記Ｍａ個の部分対象情報が、前記特定の部分対象情報を含むのか否かを判断する、請求項４に記載の管理デバイス。
前記管理デバイスは、さらに、
複数個のＩＤのそれぞれについて、当該ＩＤと、当該ＩＤに対応する情報に含まれる複数個の部分情報に対応する複数個のインデックス値の次元数を示す次元数データと、が関連付けられているテーブルを格納するメモリを備え、
前記準備部は、前記対象ＩＤに関連付けられている前記次元数データを用いて、前記第１グループのＭａ個の組合せＩＤを準備する、請求項１から５のいずれか一項に記載の管理デバイス。
管理対象の対象デバイスを管理する管理デバイスのためのコンピュータプログラムであって、
前記管理デバイスに搭載されるコンピュータに、以下の処理、即ち、
取得対象の対象情報に対応するＩＤである対象ＩＤを含むリクエストを前記対象デバイスに送信して、前記対象デバイスから前記対象情報を取得する取得処理を実行させ、
前記取得処理は、
前記対象情報が、Ｋ次元（Ｋは２以上の整数）の複数個のインデックス値に対応する複数個の部分対象情報を含む場合に、第１グループのＭａ個（Ｍａは２以上の整数）の組合せＩＤを準備する準備処理であって、前記第１グループのＭａ個の組合せＩＤのそれぞれは、前記対象ＩＤと、連続するＭａ個のインデックス値のそれぞれと、の組合せであり、前記Ｍａ個のインデックス値は、上位の桁の値として第１の値を有すると共に、下位の桁の値として連続する値を有する、前記準備処理と、
前記第１グループのＭａ個の組合せＩＤを含む第１のＧＥＴＮＥＸＴリクエストを前記対象デバイスに送信する送信処理と、を含み、
前記準備処理では、さらに、前記第１のＧＥＴＮＥＸＴリクエストを送信した結果として、前記対象デバイスから取得されるＭａ個の部分対象情報が、前記対象ＩＤと、上位の桁の値として前記第１の値とは異なる第２の値を有する特定のインデックス値と、の組合せである特定の組合せＩＤに対応する特定の部分対象情報を含む第１の場合に、Ｍｂ個（Ｍｂは２以上の整数）の組合せＩＤを準備し、
前記Ｍｂ個の組合せＩＤのそれぞれは、前記対象ＩＤと、連続するＭｂ個のインデックス値のそれぞれと、の組合せであり、
前記Ｍｂ個のインデックス値は、上位の桁の値として前記第２の値を有すると共に、下位の桁の値として連続する値を有し、
前記送信処理では、さらに、前記第１の場合に、前記Ｍｂ個の組合せＩＤを含む第２のＧＥＴＮＥＸＴリクエストを前記対象デバイスに送信する、
コンピュータプログラム。