JP5919887B2 - 管理デバイス - Google Patents

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」〜「22」に対応する２２個のＭＩＢ値「V1」〜「V22」を含むインデックス情報である。従って、情報テーブル５２では、ＯＩＤ「1.3.6.1.4.1…1.2.3.2.1」〜「1.3.6.1.4.1…1.2.3.2.22」と、２２個のＭＩＢ値「V1」〜「V22」と、が対応付けられている。なお、２２個のインデックス値「1」〜「22」は、１次元の値（１次元の整数）である。

インデックス値は、２次元以上の値で表現されることもあり得る。例えば、ベースＩＤ「1.3.6.1.4.1…1.2.3.3」に対応する１個の情報は、４４個の２次元インデックス値「1.1」〜「1.21」，「2.1」〜「2.10」，「3.1」〜「3.13」に対応する４４個のＭＩＢ値「V1.1」〜「V1.21」，「V2.1」〜「V2.10」，「V3.1」〜「V3.13」を含むインデックス情報である。同様に、３次元インデックス値（図８の「1.1.1」等参照）、４次元インデックス値等も採用され得る。なお、以下では、インデックス値の次元数に応じて、１次元インデックス情報、２次元インデックス情報等の用語を利用することがある。

例えば、プリンタ５０は、以下のようにして、２次元インデックス情報を利用することができる。例えば、複数のユーザがプリンタ５０を共用する状況を想定する。この場合、プリンタ５０は、個々のユーザに対して、２次元インデックス値のうちの上位の桁の値（例えば「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」に関連付けられている次元数「０」は、当該ベースＩＤに対応する１個の情報が、非インデックス情報であることを示す。

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

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

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

Ｓ１４では、取得部３０は、対象ベースＩＤ「＊＊＊」と、デフォルト値「0」と、を組み合わせて、ＯＩＤ「＊＊＊.0」を準備する。Ｓ１４では、取得部３０は、１個のＯＩＤ「＊＊＊.0」のみを準備する。次いで、Ｓ１６において、取得部３０は、Ｓ１４で準備されたＯＩＤ「＊＊＊.0」を含むＧＥＴリクエストを、プリンタ５０に送信する。

なお、Ｓ１６で送信されるＧＥＴリクエストは、ＧＥＴＮＥＸＴリクエストやＧＥＴＢＵＬＫリクエストではなく、通常のＧＥＴリクエストである。通常のＧＥＴリクエストは、ＳＮＭＰｖ１で採用されているリクエストである。なお、ＧＥＴＢＵＬＫリクエストは、ＳＮＭＰｖ１で採用されておらず、ＳＮＭＰｖ２又はＳＮＭＰｖ３で採用されているリクエストである。ただし、ＳＮＭＰｖ２又はＳＮＭＰｖ３は、複雑なセキュリティ手法を採用しているために、利用し難い。従って、本実施例では、管理デバイス１０は、ＳＮＭＰｖ１の管理プログラムに従って、通常のＧＥＴリクエストを利用する構成を採用している。以下でも、特に区別して記載しない限り、「ＧＥＴリクエスト」は、通常のＧＥＴリクエストを意味する。

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

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

一方において、取得部３０は、プリンタ５０からレスポンスを受信した場合（Ｓ１８でＹＥＳ）には、Ｓ２０において、Ｓ１４で準備されたＯＩＤと、レスポンスに含まれる対象のＭＩＢ値と、を対応付けて、メモリ２４内の所定の記憶領域に記憶させる。これにより、取得部３０は、プリンタ５０から非インデックス情報を取得して、非インデックス情報を上記の所定の記憶領域に記憶させることができる。なお、図４には、図２のＳ１４〜Ｓ２０に従って実行される非インデックス情報（即ちＭＩＢ値「V0」）の取得例が示されている（図４のＧＥＴリクエストＲｅｑ０、レスポンスＲｅｓ０参照）。

なお、レスポンスが「Ｎｏ Ｓｕｃｈ」を含む場合には、Ｓ２０では、取得部３０は、Ｓ１４で準備されたＯＩＤと、「Ｎｏ Ｓｕｃｈ」を示す情報と、を対応付けて、上記の所定の記憶領域に記憶させる。Ｓ２０を終えると、Ｓ２４に進む。

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

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

（インデックス情報取得処理）
Ｓ２２のインデックス情報取得処理は、対象ベースＩＤに関連付けられている次元数に応じて実行される。即ち、取得部３０は、取得対象の情報が１次元インデックス情報である場合には、図３の１次元インデックス情報取得処理を実行する、同様に、取得部３０は、取得対象の情報が、２次元インデックス情報、Ｋ次元インデックス情報（Ｋは３以上の整数）である場合には、それぞれ、図５の２次元インデックス情報取得処理、図７のＫ次元インデックス情報取得処理を実行する。

（１次元インデックス情報取得処理；図３）
まず、図３を参照して、１次元インデックス情報取得処理の内容を説明する。Ｓ４０において、第１の送信部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「1」〜「10」のそれぞれと、を組合せて、１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」を準備する。次いで、Ｓ４２において、第１の送信部３２は、Ｓ４０で準備された１０個のＯＩＤを含むＧＥＴリクエストを、プリンタ５０に送信する。なお、以下では、Ｓ４２で送信されるＧＥＴリクエスト（即ち、１０個のＯＩＤを含むＧＥＴリクエスト）のことを「メインリクエスト」と呼ぶ。

プリンタ５０は、管理デバイス１０からメインリクエストを受信すると、メインリクエストに含まれる１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」に対応する１０個のＭＩＢ値（即ち１０個の対象のＭＩＢ値）の全てが、情報テーブル５２内に格納されているのか否かを判断する。１０個の対象のＭＩＢ値の全てが存在する場合には、プリンタ５０は、１０個のＯＩＤ「＊＊＊.1」〜「＊＊＊.10」と、１０個の対象のＭＩＢ値と、を含むレスポンスを、管理デバイス１０に送信する。一方において、１０個の対象のＭＩＢ値のうちの１個でも存在しない場合には、プリンタ５０は、「Ｎｏ Ｓｕｃｈ」を含むレスポンスを、管理デバイス１０に送信する。

Ｓ４４では、第１の送信部３２は、プリンタ５０からレスポンスを受信することを監視する。レスポンスが受信されない場合（Ｓ４４でＮＯ）には、図３の処理が終了する。レスポンスが受信された場合（Ｓ４４でＹＥＳ）には、Ｓ４６において、第１の送信部３２は、レスポンスが「Ｎｏ Ｓｕｃｈ」を含むのか否かを判断する。レスポンスが「Ｎｏ Ｓｕｃｈ」を含まない場合（Ｓ４６でＮＯ）、即ち、レスポンスが１０個の対象のＭＩＢ値を含む場合には、Ｓ４８に進む。

Ｓ４８では、第１の送信部３２は、Ｓ４０で準備された１０個のＯＩＤと、レスポンスに含まれる１０個の対象のＭＩＢ値と、を対応付けて、メモリ２４内の上記の所定の記憶領域に記憶させる。次いで、Ｓ５０において、第１の送信部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「Imax+1」〜「Imax+10」のそれぞれと、を組合せて、１０個のＯＩＤ「＊＊＊.Imax+1」〜「＊＊＊.Imax+10」を準備する。ここで、「Imax」は、前回のＳ４２の処理で送信されたメインリクエストに含まれる最大のインデックス値である。例えば、前回のＳ４２の処理で送信されたメインリクエストが、１０個のインデックス値「1」〜「10」を含む場合には、「Imax」は「10」である。この場合、Ｓ５０では、第１の送信部３２は、１０個のＯＩＤ「＊＊＊.11」〜「＊＊＊.20」を準備する。

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

Ｓ４６でＹＥＳの場合（レスポンスが「Ｎｏ Ｓｕｃｈ」を含む場合）には、Ｓ５２において、第２の送信部３４は、対象ベースＩＤ「＊＊＊」と、インデックス値「Imin」と、を組み合わせて、１個のＯＩＤ「＊＊＊.Imin」のみを準備する。ここで、「Imin」は、前回のＳ４２の処理で送信されたメインリクエストに含まれる最小のインデックス値である。例えば、前回のＳ４２の処理で送信されたメインリクエストが、１０個のインデックス値「21」〜「30」を含む場合には、「Imin」は「21」である。この場合、Ｓ５２では、第２の送信部３４は、ＯＩＤ「＊＊＊.21」を準備する。

次いで、Ｓ５４において、第２の送信部３４は、Ｓ５２で準備されたＯＩＤ「＊＊＊.Imin」を含むＧＥＴリクエストを、プリンタ５０に送信する。なお、以下では、Ｓ５４で送信されるＧＥＴリクエスト（即ち、１個のＯＩＤのみを含むＧＥＴリクエスト）のことを「サブリクエスト」と呼ぶ。Ｓ５６〜Ｓ６０は、Ｓ４４〜Ｓ４８と同様である。Ｓ６０を終えると、Ｓ６２において、第２の送信部３４は、対象ベースＩＤ「＊＊＊」と、インデックス値「Iprev+1」と、を組み合わせて、１個のＯＩＤ「＊＊＊.Iprev+1」のみを準備する。ここで、「Iprev」は、前回のＳ５４の処理で送信されたサブリクエストに含まれるインデックス値である。例えば、前回のＳ５４の処理で送信されたサブリクエストが、インデックス値「21」を含む場合には、「Iprev」は「21」である。この場合、Ｓ６２では、第２の送信部３４は、１個のＯＩＤ「＊＊＊.22」を準備する。

次いで、Ｓ５４において、第２の送信部３４は、Ｓ６２で準備されたＯＩＤ「＊＊＊.Iprev+1」を含むサブリクエストを、プリンタ５０に送信する。第２の送信部３４は、Ｓ５６でＮＯ又はＳ５８でＹＥＳと判断されるまで、Ｓ５４〜Ｓ６２の処理を繰り返し実行する。なお、Ｓ５８でＹＥＳの場合（レスポンスが「Ｎｏ Ｓｕｃｈ」を含む場合）は、１次元インデックス情報に含まれる複数個のＭＩＢ値の全てが取得されたことを意味する。この場合、図３の処理が終了する。

（１次元インデックス情報の取得例；図４）
図４は、管理デバイス１０が、図３の１次元インデックス情報取得処理に従って、２２個のインデックス値「1」〜「22」に対応する２２個のＭＩＢ値「V1」〜「V22」を取得する例を示す。

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

次いで、管理デバイス１０は、１０個のＯＩＤ「＊＊＊.21」〜「＊＊＊.30」を含むメインリクエストＲｅｑ３をプリンタ５０に送信する（図３のＳ５０、Ｓ４２）。プリンタ５０には、「23」以上のインデックス値に対応するＭＩＢ値が格納されていないために、管理デバイス１０は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスＲｅｓ３を受信する。従って、管理デバイス１０は、図３のＳ４６でＹＥＳと判断して、Ｓ５２以降の処理を実行する。

次いで、管理デバイス１０は、１個のＯＩＤ「＊＊＊.21」を含むサブリクエストＲｅｑ４をプリンタ５０に送信して（図３のＳ５２、Ｓ５４）、プリンタ５０から１個のＭＩＢ値「V21」を含むレスポンスＲｅｓ４を受信する。次いで、管理デバイス１０は、１個のＯＩＤ「＊＊＊.22」を含むサブリクエストＲｅｑ５をプリンタ５０に送信して（図３のＳ６２、Ｓ５４）、プリンタ５０から１個のＭＩＢ値「V22」を含むレスポンスＲｅｓ５を受信する。

次いで、管理デバイス１０は、１個のＯＩＤ「＊＊＊.23」を含むサブリクエストＲｅｑ６をプリンタ５０に送信する（図３のＳ６２、Ｓ５４）。プリンタ５０には、インデックス値「23」に対応するＭＩＢ値が格納されていないために、管理デバイス１０は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスＲｅｓ６を受信する。従って、管理デバイス１０は、図３のＳ５８でＹＥＳと判断して、図３の処理を終了する。

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

また、管理デバイス１０は、メインリクエストＲｅｑ１を送信した結果として、１０個のＭＩＢ値「V1」〜「V10」を一括して取得することができる場合に、さらに、メインリクエストＲｅｑ２をプリンタ５０に送信する。この場合、メインリクエストＲｅｑ２に含まれるインデックス値「11」〜「20」のうちの最小のインデックス値「11」は、メインリクエストＲｅｑ１に含まれるインデックス値「1」〜「10」のうちの最大のインデックス値「10」に連続する値である（図３のＳ５０の「Imax+1」参照）。このために、管理デバイス１０は、メインリクエストＲｅｑ１，Ｒｅｑ２を順次送信する場合に、連続する２０個のインデックス値「1」〜「20」に対応する２０個のＭＩＢ値「V1」〜「V20」を適切に取得することができる。

また、管理デバイス１０は、１０個のＭＩＢ値を一括して取得することができない場合（図４のレスポンスＲｅｓ３参照）に、１個のＯＩＤのみを含むサブリクエストＲｅｑ４，Ｒｅｑ５，Ｒｅｑ６をプリンタ５０に順次送信する。そして、管理デバイス１０は、後に送信されるサブリクエストＲｅｑ５に含まれるインデックス値「22」が、先に送信されるサブリクエストＲｅｑ４に含まれるインデックス値「21」より大きく、かつ、前者のインデックス値「22」が後者のインデックス値「21」に連続するように、各ＯＩＤを準備する（図３のＳ５２の「Imin」、Ｓ６２の「Iprev+1」参照）。即ち、本実施例では、管理デバイス１０は、１０個のＭＩＢ値を一括して取得することができない場合に、「＊＊＊.21」、「＊＊＊.22」、「＊＊＊.23」・・・のような昇順で、各サブリクエストに含まれるべき各ＯＩＤを順次準備する。そして、管理デバイス１０は、ＭＩＢ値を取得することができなくなるまで（即ち、図３のＳ５８でＹＥＳと判断されるまで）、サブリクエストをプリンタ５０に送信することを繰り返す。

仮に、本実施例の構成を採用せずに、１０個のＭＩＢ値を一括して取得することができない場合に、「＊＊＊.30」、「＊＊＊.29」・・・「＊＊＊.21」のような降順で、各サブリクエストに含まれるべき各ＯＩＤを準備する構成（以下では「第２の比較例の構成」と呼ぶ）を採用することが考えられる。このような第２の比較例の構成を採用しても、管理デバイスは、各ＭＩＢ値「V21」，「V22」を取得することができるが、１０個のサブリクエストを送信する必要がある。これに対し、本実施例では、管理デバイス１０は、各サブリクエストに含まれるべき各ＯＩＤを昇順で準備するために、図４の例では、３個のサブリクエストＲｅｑ４，Ｒｅｑ５，Ｒｅｑ６をプリンタ５０に送信すれば足りる。このために、本実施例の管理デバイス１０は、第２の比較例の構成と比べて、インデックス情報を効率良く取得することができる。

（２次元インデックス情報取得処理；図５、図６）
続いて、図５及び図６を参照して、２次元インデックス情報取得処理の内容を説明する。図６は、管理デバイス１０が、図５の２次元インデックス情報取得処理に従って、４４個のインデックス値に対応する４４個のＭＩＢ値を取得する例を示す。なお、図６では、管理デバイス１０が、ＯＩＤを含むＧＥＴリクエストをプリンタ５０に送信して、プリンタ５０からレスポンスを受信するための１回の処理を、「１回目」、「２回目」等で表現している。また、結果の「ＯＫ」は、管理デバイス１０が、ＭＩＢ値を含むレスポンスを受信することを示す。結果の「Ｎｏ Ｓｕｃｈ」は、管理デバイス１０が、「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信することを示す。この点は、後述の図８でも同様である。

図５のＳ８０〜Ｓ９０は、２次元インデックス値を利用する点を除くと、図３のＳ４０〜Ｓ５０と同様である。即ち、Ｓ８０では、第１の送信部３２は、対象ベースＩＤ「＊＊＊」と、連続する１０個のインデックス値「1.1」〜「1.10」のそれぞれと、を組合せて、１０個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.10」を準備する。なお、連続する１０個のインデックス値は、上位の桁（即ち、２次元目の桁）の値として同じ値「1」を有すると共に、下位の桁（即ち、１次元目の桁）の値として連続する値「1」〜「10」を有する。

次いで、Ｓ８２では、第１の送信部３２は、Ｓ８０で準備された１０個のＯＩＤ「＊＊＊.1.1」〜「＊＊＊.1.10」を含むメインリクエストをプリンタ５０に送信する。これにより、図６の１回目に示されるように、第１の送信部３２は、プリンタ５０から１０個のＭＩＢ値「V1.1」〜「V1.10」を取得する。この場合、第１の送信部３２は、Ｓ８４でＹＥＳと判断し、Ｓ８６でＮＯと判断し、Ｓ８８を経て、Ｓ９０に進む。

Ｓ９０では、第１の送信部３２は、１０個のＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」を準備する。次いで、Ｓ８２において、第１の送信部３２は、Ｓ９０で準備された１０個のＯＩＤ「＊＊＊.1.11」〜「＊＊＊.1.20」を含むメインリクエストをプリンタ５０に送信する。これにより、図６の２回目に示されるように、第１の送信部３２は、プリンタ５０から１０個のＭＩＢ値「V1.11」〜「V1.20」を取得する。

同様に、第１の送信部３２は、Ｓ９０で準備された１０個のＯＩＤ「＊＊＊.1.21」〜「＊＊＊.1.30」を含むメインリクエストをプリンタ５０に送信する。これにより、図６の３回目に示されるように、第１の送信部３２は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する。この場合、第１の送信部３２は、Ｓ８４でＹＥＳと判断し、Ｓ８６でＹＥＳと判断し、Ｓ９２に進む。

図５のＳ９２〜Ｓ１０２は、２次元インデックス値を利用する点を除くと、図３のＳ５２〜Ｓ６２と同様である。即ち、Ｓ９２では、第２の送信部３４は、１個のＯＩＤ「＊＊＊.1.21」を準備する。次いで、Ｓ９４において、第２の送信部３４は、Ｓ９２で準備された１個のＯＩＤ「＊＊＊.1.21」を含むサブリクエストをプリンタ５０に送信する。これにより、図６の４回目に示されるように、第２の送信部３４は、プリンタ５０から１個のＭＩＢ値「V1.21」を取得する。この場合、第２の送信部３４は、図５のＳ９６でＹＥＳと判断し、Ｓ９８でＮＯと判断し、Ｓ１００を経て、Ｓ１０２に進む。

Ｓ１０２では、第２の送信部３４は、１個のＯＩＤ「＊＊＊.1.22」を準備する。次いで、Ｓ９４において、第２の送信部３４は、Ｓ１０２で準備された１個のＯＩＤ「＊＊＊.1.22」を含むサブリクエストをプリンタ５０に送信する。これにより、図６の５回目に示されるように、第２の送信部３４は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する。この場合、第２の送信部３４は、図５のＳ９６でＹＥＳと判断し、Ｓ９８でＹＥＳと判断し、Ｓ１０４に進む。

Ｓ１０４では、第１の送信部３２は、前回のＳ９４で送信されたサブリクエストに含まれるインデックス値の１次元目の桁の値（即ち、下位の桁の値）が「1」であるのか否かを判断する。例えば、前回のＳ９４で送信されたサブリクエストがＯＩＤ「＊＊＊.4.1」を含む場合には、そのインデックス値「4.1」の１次元目の桁の値が「1」である。この場合、第１の送信部３２は、Ｓ１０４でＹＥＳと判断して、図５の処理を終了する。

一方において、例えば、前回のＳ９４で送信されたサブリクエストがＯＩＤ「＊＊＊.1.22」を含む場合には、そのインデックス値「1.22」の１次元目の桁の値が「22」である。この場合、第１の送信部３２は、Ｓ１０４でＮＯと判断して、Ｓ１０６に進む。

Ｓ１０６では、第１の送信部３２は、まず、前回のＳ９４で送信されたサブリクエストに含まれるインデックス値「1.22」の２次元目の桁の値「1」を特定する。次いで、第１の送信部３２は、特定済みの２次元目の桁の値「1」を１だけインクリメントして、新たな２次元目の桁の値「2」を決定する。そして、第１の送信部３２は、決定済みの２次元目の桁の値「2」を有する連続する１０個のインデックス値「2.1」〜「2.10」を準備する。そして、第１の送信部３２は、準備済みの１０個のインデックス値「2.1」〜「2.10」を用いて、１０個のＯＩＤ「＊＊＊. 2.1」〜「＊＊＊. 2.10」を準備する。

次いで、Ｓ８２において、第１の送信部３２は、Ｓ１０６で準備された１０個のＯＩＤ「＊＊＊. 2.1」〜「＊＊＊. 2.10」を含むメインリクエストを、プリンタ５０に送信する。これにより、図６の６回目に示されるように、第１の送信部３２は、プリンタ５０から１０個のＭＩＢ値「V2.1」〜「V2.10」を取得して、Ｓ９０に進む。

以降の処理は、上記と同様である。この結果、図６の７回目以降の処理が実行される。図６の１６回目の処理を実行すると、図５のＳ１０４でＹＥＳと判断され、２次元インデックス情報取得処理（図５）の処理が終了する。即ち、図５の例では、管理デバイス１０は、プリンタ５０から４４個のＭＩＢ値を取得するのに、１６個のＧＥＴリクエストをプリンタ５０に送信すれば足りる。従って、管理デバイス１０は、２次元インデックス情報を効率良く取得することができる。

（Ｋ次元インデックス情報取得処理；図７、図８）
続いて、図７及び図８を参照して、Ｋ次元インデックス情報取得処理（Ｋは３以上の整数）の内容を説明する。図８は、管理デバイス１０が、図７のＫ次元インデックス情報取得処理に従って、２７個の３次元インデックス値に対応する２７個のＭＩＢ値を取得する例を示す。なお、以下では、３次元インデックス情報を取得する場合を例にして、図７のフローチャートの内容を説明するが、４次元以上のインデックス情報を取得する場合にも、図７のフローチャートを利用することができる。

Ｓ１２０において、第１の送信部３２は、Ｉ（Ｋ）、Ｉ（Ｋ−１）、・・・Ｉ（１）のそれぞれを、「1」に決定する。ここで、Ｉ（ｊ）は、インデックス値のうちのｊ次元目の桁の値を示すパラメータである。例えば、Ｋ＝３である場合には、Ｓ１２０において、第１の送信部３２は、３次元目の桁の値を示すＩ（３）、２次元目の桁の値を示すＩ（２）、及び、１次元目の桁の値を示すＩ（１）のそれぞれを、「1」に決定する。即ち、第１の送信部３２は、インデックス値「1.1.1」を準備する。

次いで、Ｓ１２２において、第１の送信部３２は、現在の処理対象の桁を示すパラメータＴを「1」に決定する。次いで、Ｓ１２４において、第１の送信部３２は、ＧＥＴリクエストに含まれるべきＯＩＤの数を示すパラメータＭを「10」に決定する。次いで、Ｓ１２６において、第１の送信部３２は、ベースＩＤ「＊＊＊」と、Ｓ１２０で準備されたインデックス値「1.1.1」と、を組み合わせて、ＯＩＤ「＊＊＊.1.1.1」を準備する。

次いで、Ｓ１２８において、第１の送信部３２は、現在のＩ（１）を１だけインクリメントして、新たなＩ（１）を決定する。現在のＩ（１）が「1」であるために、第１の送信部３２は、新たなＩ（１）を「2」に決定する。次いで、Ｓ１３０において、第１の送信部３２は、Ｍ個のＯＩＤを準備したのか否かを判断する。現在のＭが「１０」であり、かつ、現時点では１個のＯＩＤ「＊＊＊.1.1.1」しか準備されていないために、第１の送信部３２は、Ｓ１３０でＮＯと判断する。この場合、第１の送信部３２は、Ｓ１２６に戻り、１個のＯＩＤを準備する。ここでは、Ｓ１２８で決定された新たなＩ（１）の値「2」が利用される。即ち、第１の送信部３２は、ＯＩＤ「＊＊＊.1.1.2」を準備する。第１の送信部３２は、Ｓ１２６〜Ｓ１３０の処理を繰り返し実行することによって、連続する１０個のインデックス値「1.1.1」〜「1.1.10」を含む１０個のＯＩＤ「＊＊＊.1.1.1」〜「＊＊＊.1.1.10」を準備する。ここでも、連続する１０個のインデックス値「1.1.1」〜「1.1.10」は、上位の桁（即ち、３次元目の桁及び２次元目の桁）の値として同じ値「1.1」を有すると共に、下位の桁（即ち、１次元目の桁）の値として連続する値「1」〜「10」を有する。この場合、第１の送信部３２は、Ｓ１３０でＹＥＳと判断して、Ｓ１３２に進む。

Ｓ１３２では、第１の送信部３２は、１０個のＯＩＤ「＊＊＊.1.1.1」〜「＊＊＊.1.1.10」を含むメインリクエストを、プリンタ５０に送信する。これにより、図８の１回目に示されるように、第１の送信部３２は、プリンタ５０から１０個のＭＩＢ値「V1.1.1」〜「V1.1.10」を取得する。この場合、第１の送信部３２は、図７のＳ１３４でＹＥＳと判断し、Ｓ１３６でＮＯと判断し、Ｓ１３８を経て、Ｓ１２６に進む。なお、Ｓ１３８では、第１の送信部３２は、現在の処理対象の桁を示すパラメータＴが「1」以外の値であれば（Ｓ１４６でＴがインクリメントされ得る）、Ｔを「1」に戻す。

第１の送信部３２は、Ｓ１２６〜Ｓ１３０の処理を再び繰り返し実行することによって、１０個のＯＩＤ「＊＊＊.1.1.11」〜「＊＊＊.1.1.20」を準備し、Ｓ１３２において、メインリクエストを送信する。これにより、図８の２回目に示されるように、第１の送信部３２は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する。この場合、第１の送信部３２は、図７のＳ１３４でＹＥＳと判断し、Ｓ１３６でＹＥＳと判断し、Ｓ１４０に進む。

Ｓ１４０では、第２の送信部３４は、現在のＭが「１」であるのか否かを判断する。現在のＭが「１０」であるために、第２の送信部３４は、Ｓ１４０でＮＯと判断して、Ｓ１４２に進む。Ｓ１４２では、第２の送信部３４は、前回のＳ１３２で送信されたメインリクエストに含まれる１０個のインデックス値「1.1.11」〜「1.1.20」のうち、最も小さいインデックス値であるＩｍｉｎ「1.1.11」に含まれる１次元目の桁の値「11」を特定する。そして、第２の送信部３４は、現在のＩ（１）を特定済みの値「11」に置換することによって、新たなＩ（１）を決定する。Ｓ１４２では、さらに、第２の送信部３４は、Ｍを「１０」から「１」に変更する。

Ｓ１４２を終えると、第２の送信部３４は、Ｓ１２６に戻り、１個のＯＩＤを準備する。ここでは、Ｓ１４２で決定された新たなＩ（１）の値「11」が利用される。即ち、第２の送信部３４は、ＯＩＤ「＊＊＊.1.1.11」を準備する。現在のＭが「１」であるために、第２の送信部３４は、Ｓ１３０でＹＥＳと判断して、Ｓ１３２において、ＯＩＤ「＊＊＊.1.1.11」を含むサブリクエストを送信する。これにより、図８の３回目に示されるように、第２の送信部３４は、プリンタ５０から１個のＭＩＢ値「V1.1.11」を取得する。この場合、第２の送信部３４は、図７のＳ１３４でＹＥＳと判断し、Ｓ１３６でＮＯと判断し、Ｓ１３８を経て、Ｓ１２６に進む。

第２の送信部３４は、Ｓ１２６〜Ｓ１３８の処理を繰り返し実行する。これにより、第２の送信部３４は、ＯＩＤ「＊＊＊.1.1.12」を含むサブリクエストを送信して、ＭＩＢ値「V1.1.12」を取得する（図８の４回目）。次いで、第２の送信部３４は、ＯＩＤ「＊＊＊.1.1.13」を含むサブリクエストを送信して、「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する（図８の５回目）。この場合、第２の送信部３４は、図７のＳ１３６でＹＥＳと判断し、Ｓ１４０でＹＥＳと判断し、Ｓ１４４に進む。

Ｓ１４４では、第１の送信部３２は、現在のＴがＫに等しいのか否かを判断する。現在のＴが「１」であり、かつ、Ｋが「３」であるために、第１の送信部３２は、Ｓ１４４でＮＯと判断して、Ｓ１４６に進む。

Ｓ１４６では、第１の送信部３２は、現在のＴを「１」だけインクリメントして、新たなＴを決定する。現在のＴが「１」であるために、第１の送信部３２は、新たなＴを「２」に決定する。次いで、第１の送信部３２は、現在のＩ（Ｔ）を「１」だけインクリメントして、新たなＩ（Ｔ）を決定する。Ｔが「２」であるために、現在のＩ（Ｔ）は、２次元目の桁の現在の値を示す。２次元目の桁の現在の値が「1」であるために、第１の送信部３２は、２次元目の桁の新たな値を「2」に決定する（即ち、Ｉ（Ｔ）＝「2」に決定する）。次いで、第１の送信部３２は、Ｉ（Ｔ−１）、Ｉ（Ｔ−２）、・・・Ｉ（１）のそれぞれを、「1」に決定する。ただし、Ｔが「２」であるために、現時点では、Ｉ（Ｔ−１）（即ちＩ（１））しか存在しない。このために、第１の送信部３２は、１次元目の桁の新たな値を「1」に決定する（即ち、Ｉ（Ｔ−１）＝「1」に決定する）。Ｓ１４６では、さらに、第１の送信部３２は、現在のＭを「１」から「１０」に変更する。

Ｓ１４６を終えると、第１の送信部３２は、Ｓ１２６に戻り、Ｓ１４６で決定されたＩ（Ｔ）及びＩ（Ｔ−１）等に従って、ＯＩＤ「＊＊＊.1.2.1」を準備する。次いで、第１の送信部３２は、Ｓ１２６〜Ｓ１３０の処理を繰り返し実行することによって、１０個のＯＩＤ「＊＊＊.1.2.1」〜「＊＊＊.1.2.10」を準備して、Ｓ１３２において、１０個のＯＩＤ「＊＊＊.1.2.1」〜「＊＊＊.1.2.10」を含むメインリクエストを、プリンタ５０に送信する。これにより、図８の６回目に示されるように、第１の送信部３２は、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する（図７のＳ１３６でＹＥＳ、Ｓ１４０でＮＯ）。

次いで、第２の送信部３４は、ＯＩＤ「＊＊＊.1.2.1」を含むサブリクエストを、プリンタ５０に送信して（図７のＳ１４２、Ｓ１２６〜Ｓ１３２）、プリンタ５０からＭＩＢ値「V1.2.1」を取得する（図８の７回目、図７のＳ１３４でＹＥＳ、Ｓ１３６でＮＯ）。これにより、図７のＳ１３８において、第２の送信部３４は、現在のＴ（即ち、Ｓ１４６でインクリメントされたＴ）を、「２」から「１」に変更する。

次いで、第２の送信部３４は、ＯＩＤ「＊＊＊.1.2.2」を含むサブリクエストを送信して、プリンタ５０からＭＩＢ値「V1.2.2」を取得する（図８の８回目）。次いで、第２の送信部３４は、ＯＩＤ「＊＊＊.1.2.3」を含むサブリクエストを送信して、プリンタ５０から「Ｎｏ Ｓｕｃｈ」を含むレスポンスを受信する（図８の９回目）。

以降の処理は、上記と同様である。この結果、図８の１０回目以降の処理が実行される。図８の２３回目の処理を実行すると、図７のＳ１４４でＹＥＳと判断され、Ｋ次元インデックス情報取得処理（図７）が終了する。即ち、管理デバイス１０は、プリンタ５０から２７個のＭＩＢ値を取得するのに、２３個のＧＥＴリクエストをプリンタ５０に送信すれば足りる。従って、管理デバイス１０は、Ｋ次元インデックス情報を効率良く取得することができる。

なお、図７では、Ｋが３以上の整数として表わしているが、実際には、Ｋが１又は２であっても、図７のＫ次元インデックス情報取得処理を利用可能である。即ち、本実施例では、技術の理解を容易にするために、管理デバイス１０は、図７の代わりに、図３及び図５のインデックス情報取得処理を実行する。しかしながら、管理デバイス１０は、図３及び図５の代わりに、図７のＫ次元インデックス情報取得処理に従って、１次元インデックス情報及び２次元インデックス情報を取得してもよい。この場合も、図４及び図６の取得例を実現することができる。

（実施例の効果）
本実施例によると、管理デバイス１０は、取得対象の情報がインデックス情報である場合に、１０個のＯＩＤを含むメインリクエストをプリンタ５０に送信することによって（図３のＳ４２、図５のＳ８２、図７のＭ＝１０の場合のＳ１３２）、１０個のＭＩＢ値を一括して取得することができる。このために、管理デバイス１０は、各ＭＩＢ値を効率良く取得することができる。また、管理デバイス１０は、１０個のＭＩＢ値を取得することができない場合に、１個のＯＩＤを含むサブリクエストをプリンタ５０に順次送信することによって（図３のＳ５４、図５のＳ９４、図７のＭ＝１の場合のＳ１３２）、各ＭＩＢ値を適切に取得することができる。結果として、図４、図６、及び、図８に示されるように、管理デバイス１０は、インデックス情報に含まれる複数個のＭＩＢ値の数（例えば図４では２２個）よりも少ない個数（例えば図４では６個）のＧＥＴリクエストを送信して、複数個のＭＩＢ値の全てを適切に取得することができる。このように、本実施例によると、管理デバイス１０は、各ＭＩＢ値を効率良く取得し得る。

特に、本実施例によると、管理デバイス１０は、インデックス情報に含まれるＭＩＢ値の数を把握していない状況でも、図２のＳ２２のインデックス情報取得処理（図３、図５、図７）を実行することによって、インデックス情報に含まれる複数個のＭＩＢ値を効率良く取得することができる。なお、管理デバイス１０は、例えば、図４の取得例に従って各ＭＩＢ値を取得すれば、１次元インデックス情報が、２２個のインデックス値「1」〜「22」に対応する２２個のＭＩＢ値「V1」〜「V22」を含んでいることを把握することができる。従って、管理デバイス１０（即ち第１の送信部３２）は、２回目以降のインデックス情報取得処理を実行する際に、２２個のＯＩＤ「＊＊＊.1」〜「＊＊＊.22」を含むＧＥＴリクエストをプリンタ５０に送信して、２２個のＭＩＢ値「V1」〜「V22」を一括して取得してもよい。ただし、上述したように、例えば、プリンタ５０がエラー履歴等を累積して格納する場合には、インデックス情報に含まれるＭＩＢ値の数（即ちインデックス値の数）が変化し得るために、管理デバイス１０は、２回目以降のインデックス情報取得処理を実行する際にも、図３、図５、及び、図７の処理を実行することが好ましい。管理デバイス１０が、プリンタ５０に新たに格納されたＯＩＤに対応するＭＩＢ値を、適切に取得することができるからである。

（対応関係）
プリンタ５０が、「対象デバイス」の一例である。ベースＩＤ、ＯＩＤが、それぞれ、「対象ＩＤ」、「組合せＩＤ」の一例である。例えば、図１の１次元インデックス情報では、１次元インデックス値「1」〜「22」、ＭＩＢ値「V1」〜「V22」が、それぞれ、「複数個のインデックス値」、「複数個の部分対象情報」の一例である。また、図４のＧＥＴリクエストＲｅｑ１、ＧＥＴリクエストＲｅｑ２が、それぞれ、「第１のメインリクエスト」、「第２のメインリクエスト」の一例である。この場合、１次元インデックス値「1」〜「10」、ＯＩＤ「＊＊＊.1」〜「＊＊＊.10」、ＭＩＢ値「V1」〜「V10」が、それぞれ、「連続するＭａ個のインデックス値」、「Ｍａ個の組合せＩＤ」、「Ｍａ個の部分対象情報」の一例である。即ち、「１０」が、「Ｍａ」及び「Ｍｂ」の一例である。また、次元数テーブル２２内の次元数が、「特定データ」の一例である。

また、ＧＥＴリクエストＲｅｑ３も、「第１のメインリクエスト」の一例である。この場合、１次元インデックス値「21」〜「30」、ＯＩＤ「＊＊＊.21」〜「＊＊＊.30」が、それぞれ、「連続するＭａ個のインデックス値」、「Ｍａ個の組合せＩＤ」の一例である。この例では、ＧＥＴリクエストＲｅｑ４，Ｒｅｑ５，Ｒｅｑ６が、「１個以上（又は２個以上）のサブリクエスト」の一例である。例えば、ＧＥＴリクエストＲｅｑ４では、ＯＩＤ「＊＊＊.21」が、「Ｍａ個の組合せＩＤのうちのＮ個の組合せＩＤ」及び「対象デバイスから取得するためのＮ個の組合せＩＤ」の一例である。また、ＭＩＢ値「V21」が、「Ｎ個の部分対象情報」の一例である。即ち、「１」が、「Ｎ」の一例である。

また、ＧＥＴリクエストＲｅｑ５、ＧＥＴリクエストＲｅｑ４が、それぞれ、「第１のサブリクエスト」、「第２のサブリクエスト」の一例である。この場合、ＯＩＤ「＊＊＊.22」、インデックス値「22」が、それぞれ、「第１の組合せＩＤ」、「第１のインデックス値」の一例である。また、ＯＩＤ「＊＊＊.21」、インデックス値「21」が、それぞれ、「第２の組合せＩＤ」、「第２のインデックス値」の一例である。

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

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

（変形例２）「Ｍａ」及び「Ｍｂ」は、１０でなくてもよく、２以上の整数であれば、どのような値（例えば、Ｍａ＝５、Ｍｂ＝５）であってもよい。また、「Ｍａ」及び「Ｍｂ」は異なる値（例えば、Ｍａ＝１０、Ｍｂ＝８）であってもよい。

（変形例３）「Ｎ」は、１でなくてもよく、１以上Ｍａ未満の整数であれば、どのような値（例えば、Ｎ＝３）であってもよい。

（変形例４）「１個以上（又は２個以上）のサブリクエスト」は、ＧＥＴリクエストでなくてもよく、ＧＥＴＮＥＸＴリクエストであってもよい。ＧＥＴＮＥＸＴリクエストは、ＧＥＴＮＥＸＴリクエストに含まれるＯＩＤの次のＯＩＤに対応するＭＩＢ値を取得するためのリクエストである。ＧＥＴＮＥＸＴリクエストは、ＳＮＭＰｖ１で採用されているリクエストである。例えば、図４において、第２の送信部３４は、レスポンスＲｅｓ３を受信する場合に、ＯＩＤ「＊＊＊.21」を含むＧＥＴリクエストの代わりに、ＯＩＤ「＊＊＊.20」を含むＧＥＴＮＥＸＴリクエストを、プリンタ５０に送信してもよい。このような構成でも、第２の送信部３４は、ＯＩＤ「＊＊＊.20」の次のＯＩＤ「＊＊＊.21」に対応するＭＩＢ値「V21」を含むレスポンスを受信することができる。本変形例では、ＯＩＤ「＊＊＊.20」が「対象デバイスから取得するためのＮ個の組合せＩＤ」の一例であり、ＯＩＤ「＊＊＊.21」が「Ｍａ個の組合せＩＤのうちのＮ個の組合せＩＤ」の一例である。即ち、本変形例のように、「対象デバイスから取得するためのＮ個の組合せＩＤ」が、「Ｍａ個の組合せＩＤのうちのＮ個の組合せＩＤ」とは異なっていてもよい。

（変形例５）第２の送信部３４は、例えば、図４のレスポンスＲｅｓ３を受信する場合に、ＯＩＤ「＊＊＊.21」，「＊＊＊.22」，「＊＊＊.23」のような昇順で、各サブリクエストに含まれるべき各ＯＩＤを順次準備しなくてもよく、ＯＩＤ「＊＊＊.30」，「＊＊＊.29」・・・「＊＊＊.21」のような降順で、各サブリクエストに含まれるべき各ＯＩＤを順次準備してもよい。即ち、「１個以上のサブリクエスト」のそれぞれは、Ｎ個の組合せＩＤを含んでいればよい。

（変形例６）次元数テーブル２２では、次元数が記述される代わりに、インデックス情報であるのか非インデックス情報であるのかを区別するためのフラグが記述されてもよい。この場合、判断部３６は、対象ベースＩＤに関連付けられているフラグに基づいて、図２のＳ１２の判断を実行してもよい。即ち、「特定データ」は、次元数に限られず、フラグであってもよい。

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

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

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

Claims (6)

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

Images