ネットワーク機器、その制御方法、および制御プログラム
【課題】管理端末で使用するソフトウェアが異なっても管理端末がネットワーク機器から機器情報を容易に取得してその管理を行うことができるようにする。
【解決手段】ネットワーク機器であるＭＦＰ１００は、ＬＡＮ１６０を介して管理端末であるＰＣ１６１および１６２に接続されている。ＭＦＰは機器情報取得要求を管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する。そして、複数の同一のオブジェクト識別子が含まれていると判定すると、ＭＦＰは同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定し、当該決定に応じて機器情報を含むレスポンスを管理端末に返信する返信手段とを有することを特徴とするネットワーク機器。
【解決手段】ネットワーク機器であるＭＦＰ１００は、ＬＡＮ１６０を介して管理端末であるＰＣ１６１および１６２に接続されている。ＭＦＰは機器情報取得要求を管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する。そして、複数の同一のオブジェクト識別子が含まれていると判定すると、ＭＦＰは同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定し、当該決定に応じて機器情報を含むレスポンスを管理端末に返信する返信手段とを有することを特徴とするネットワーク機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたネットワーク機器、その制御方法、および制御プログラムに関する。
【背景技術】
【０００２】
一般に、ネットワークに直接接続されたネットワーク機器（以下ネットワークデバイスともいい、例えば、ＭＦＰなどの画像形成装置をいう）を、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのデバイス管理プロトコルを用いて管理することが知られている。さらに、パソコンなどの情報処理装置がネットワークに接続され、情報処理装置に接続されたデバイスと上記のネットワークデバイスとを区別可能として一元管理するようにしたシステムが知られている（例えば、特許文献１参照）。
【０００３】
特許文献１に記載のデバイスの管理手法では、ネットワークデバイスが直接ネットワーク接続されているか否かを事前に区別するとともに、ネットワークデバイスである場合には、情報処理装置はＳＮＭＰを用いてネットワークデバイスに関するデバイス情報を取得する必要がある。
【０００４】
一方、ネットワークに接続された情報処理装置にＵＳＢなどで接続されたデバイスについては、接続先のデバイスに適したプロトコルでデバイス情報を取得するための要求コマンド送出して管理を行っている。つまり、情報処理装置においてデバイス情報の取得の要求を行う際に、予めデバイスの種別を認識して要求コマンドを変更するようにしている。
【０００５】
さらに、別のデバイス管理手法として、例えば、ネットワークデバイスに固有に割り当てられたシステム名称等を、情報処理装置が管理プロトコルを用いて取得するようにしたものがある。ここでは、情報処理装置は、取得したシステム名称などの識別情報に応じてネットワークデバイスに問い合わせを行うためのコマンドに切り替えて、ネットワークデバイスからデバイス情報を取得するようにしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２７１２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところが、情報処理装置においてネットワークデバイスが当該情報処理装置に直接接続されているか又は他の情報処理装置を介してネットワークに接続されているかについて事前に判定することは困難である。そして、事前に上記の接続形態が判定できないと、情報処理装置は要求コマンドの変更を行うことができず、必要なデバイス情報の収集に支障をきたす可能性がある。
【０００８】
また、ＳＮＭＰにおいて取得可能なＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）情報には、例えば、スカラー型およびテーブル型の２種類のＭＩＢ変数が存在している。そして、スカラー型は単一の値を有しており、例えば、ｓｙｓＤｅｓｃｒ（図２の２０３）というＭＩＢ値は、読み出し専用（Ｒｅａｄ Ｏｎｌｙ）の情報である。このＭＩＢ値はネットワークデバイスに関する説明を示す文字列としてデバイスに一つしか存在しない情報である。
【０００９】
一方、テーブル型の場合には、類似の情報をテーブル情報として複数示すことが可能である。例えば、消耗品であるトナーの情報を、ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＤｅｓｃｒｉｐｔｉｏｎ（図３の３１０）というＭＩＢ値を用いて、シアン（Ｃ）、マゼンタ（Ｍ）、イエロー（Ｙ）、およびブラック（Ｋ）の４色のトナー情報として個別に列挙することが可能である。
【００１０】
一般的な情報処理装置では、ネットワークデバイスに一つしか存在せず、かつＲｅａｄ Ｏｎｌｙのスカラー型の情報を用いてデバイスの識別を行って、詳細な管理情報を取得するためのロジックを切り替えるなどして最適化を行っている。
【００１１】
このため、異なるソフトウェアを用いた情報処理装置において、デバイス識別の可／不可が異なるようなケースが存在する。この場合、デバイス識別が可能なソフトウェアを用いた情報処理装置でのみネットワークデバイスの詳細な情報および状態の管理が行えることになって、使用するソフトウェアが異なるとデバイスの管理が行えず、利便性が低下してしまう。
【００１２】
従って、本発明の目的は、情報処理装置で使用するソフトウェアが異なっても情報処理装置が機器情報を容易に取得して管理を行うことのできるネットワーク機器、その制御方法、および制御プログラムを提供することにある。
【課題を解決するための手段】
【００１３】
上記の目的を達成するため、本発明によるネットワーク機器は、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器であって、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定手段と、前記判定手段によって複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定手段と、前記決定手段による決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信手段とを有することを特徴とする。
【００１４】
本発明による制御方法は、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器の制御方法であって、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを有することを特徴とする。
【００１５】
本発明による制御プログラムは、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器で用いられる制御プログラムであって、前記ネットワーク機器が備えるコンピュータに、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを実行させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、管理端末である情報処理装置がネットワーク機器からその機器情報を取得する際に、管理端末で使用するソフトウェアが異なっても、特別な設定を行う必要なく容易に機器情報を取得してネットワーク機器の管理を行うことができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１の実施形態によるネットワーク機器が用いられたネットワークシステムの一例を示す図である。
【図２】ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の一例を示す図である。
【図３】ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の他のを示す図である。
【図４】図１に示すＭＦＰに備えられた制御部の構成の一例を示すブロック図である。
【図５】図１に示すＭＦＰにおいてパケットデータを受信した際の返信処理の一例を説明するためのフローチャートである。
【図６】図１に示すＭＦＰに予め記録されたレスポンステーブルの一例を示す図である。
【図７】本発明の第２の実施形態によるＭＦＰ１００の返信処理を説明するためのフローチャートである。
【図８】本発明の第２の実施形態による返信値テーブルの更新の一例を説明するための図である。
【図９】本発明の第２の実施形態による返信値テーブルの更新の他の例を説明するための図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態によるネットワーク機器の一例について図面を参照して説明する。
【００１９】
［第１の実施形態］
図１は、本発明の第１の実施形態によるネットワーク機器が用いられたネットワークシステムの一例を示す図である。なお、図１においては、ネットワーク機器の一例として、例えば、ＭＦＰ（複合機）などの画像形成装置が示されており、ここでは、ＭＦＰを例に挙げて説明する。ただし、本発明のネットワーク機器は、ＭＦＰ等の画像形成装置に限るものではない。
【００２０】
図示のネットワークシステムは、ＭＦＰ（画像形成装置）１００を有しており、このＭＦＰ１００はＬＡＮ１６０などのネットワークに接続されている。さらに、図示の例では、ＬＡＮ１６０には情報処理装置であるＰＣ１６１および１６２が接続されている。つまり、ＭＦＰ１００はネットワークを介してＰＣ１６１および１６２に接続可能となっている。なお、図１には示されていないが、ＬＡＮ１６０には他のＰＣが接続されるとともに、別のＭＦＰおよびプリンタなどが接続されることがある。また、ＰＣ１６１および１６２にはプリンタなどの画像形成装置が接続されることがある。
【００２１】
＜画像形成装置の構成＞
図示のＭＦＰ１００はコピー機能およびプリンタ機能等の複数の機能を有している。なお、画像形成装置として、コピー機能又はプリンタ機能のみを有するＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）を用いるようにしてもよい。
【００２２】
ＭＦＰ１００は制御部（コントローラ部）１１０を有している。制御部１１０はリーダ部１２０およびプリンタ部１３０に接続されている。制御部１１０はリーダ部１２０およびプリンタ部１３０から各種データを受信する。また、制御部１１０はリーダ部１２０およびプリンタ部１３０に対して各種コマンドを送信する。さらに、制御部１１０はＬＡＮ１６０を介してＰＣ１６１又は１６２と接続されており、ＰＣ１６１又は１６２から画像データおよび制御コマンドを受信する。なお、ＬＡＮ１６０は、例えば、イーサネット（登録商標）で構築される。ＰＣ１６１および１６２の各々は管理端末とも呼ばれ、ＭＦＰ１００についてその機器構成および現在のステータスの監視等も行う。
【００２３】
リーダ部１２０は原稿上の画像を光学的に読み取って画像データを得る。リーダ部１２０はスキャナユニット１２１および原稿給紙ユニット（ＤＦユニット）１２２を備えている。ＤＦユニット１２２によって原稿はスキャナユニット１２１によって読み取り可能な位置まで搬送される。そして、スキャナユニット１２１によって原稿上の画像が読み取られる。スキャナユニット１２１はスキャナコントローラ１２３を備えており、このスキャナコントローラ１２３は制御部１１０からの指示に基づいてスキャナユニット１２１および原稿給紙ユニット１２２を制御する。
【００２４】
プリンタ部１３０は給紙ユニット１３１、マーキングユニット１３２、および排紙ユニット１３４を備えている。マーキングユニット１３２にはプリンタコントローラ１３５が備えられており、プリンタコントローラ１３５は制御部１１０の制御下で給紙ユニット１３１、マーキングユニット１３２、および排紙ユニット１３４を制御する。
【００２５】
給紙ユニット１３１には印刷用紙が収納され、給紙ユニット１３１からマーキングユニット１３２に用紙が搬送される。マーキングユニット１３２は、例えば、電子写真プロセスによって画像データに応じた画像を用紙に形成する。そして、画像形成（印刷）が行われた後、用紙は排紙ユニット１３４によって排紙される。なお、排紙ユニット１３４では印刷後の用紙に対して、ソートおよびステイプル等の処理を行うことができる。
【００２６】
給紙ユニット１３１には複数の給紙部が備えられている。給紙部には、例えば、普通紙および光沢紙などの複数種類の用紙を収納することができる。また、給紙部には、プリンタ部１３０において印刷された用紙を再び収納することもできる。給紙部の例として、給紙カセット、給紙デッキ、又は手差用紙レイなどがある。
【００２７】
操作部１４０は、例えば、ハードキー、液晶表示部、および当該液晶表示部の表面上に貼り付けられたタッチパネル部を備えており、操作部１４０によってユーザの指示が受け付けられる。さらに、操作部１４０の液晶表示部にはソフトキーが表示されるとともに、ＭＦＰ１００の機能および状態が表示される。操作部１４０で受け付けたユーザの指示に対応するコマンドは制御部１１０に送られる。図示の例では、ＭＦＰ１００にはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１５０が備えられ、このＨＤＤには、ＭＦＰ１００に係る各種設定および画像データなどが記憶される。
【００２８】
図示のＭＦＰ１００は、コピー機能、画像データ送信機能、およびプリンタ機能などの複数の機能を有している。コピー機能を用いる際には、前述のように、制御部１１０はリーダ部１２０を制御して原稿上の画像データを読み込み、プリンタ部１３０を制御して画像データに応じた印刷を行う。
【００２９】
画像データ送信機能を用いる際には、制御部１１０はリーダ部１２０による読み取りの結果得られた画像データをコードデータに変換して、当該コードデータを、ＬＡＮ１６０を介してＰＣ１６１又は１６２に送信する。プリンタ機能を用いる際には、制御部１１０はＰＣ１６１又は１６２からＬＡＮ１６０を介して受信したコードデータ（印刷データ）を画像データに変換して、プリンタ部１３０に送信する。そして、プリンタ部１３０は、受信した画像データを応じて用紙に印刷を行う。なお、制御部１１０の構成については後述する。
【００３０】
続いて、ＰＣ１６１又は１６２がネットワーク機器であるＭＦＰ１００からその構成情報を取得する際に用いられる一般的な手法（以下標準技術と呼ぶ）について説明する。
【００３１】
＜標準技術の説明＞
ここでは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）がインターネットで用いられる技術の標準化を目的として発行するＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）に基づいたネットワーク機器からの情報取得について説明する。
【００３２】
一般的に、ネットワーク機器における情報管理プロトコルとしてＳＮＭＰが用いられている。ＳＮＭＰで管理されるネットワーク機器には、ＭＩＢ情報が格納されている。そして、管理端末（図１に示すＰＣ１６１又は１６２）から送られるＳＮＭＰリクエストに対してネットワーク機器がレスポンス（ＭＩＢ情報）を返信し、これによって、管理端末がネットワーク機器の管理を行う。なお、ＭＩＢ情報の構造についてもＩＥＦＴにおいて標準化されている。
【００３３】
ＳＮＭＰにおいて取得可能なＭＩＢ情報にはスカラー型およびテーブル型の２種類のＭＩＢ変数が存在している。ここで、スカラー型の例として、ｓｙｓＤｅｓｃｒについて説明する。
【００３４】
図２は、ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の一例を示す図である。
【００３５】
図２において、ｓｙｓＤｅｓｃｒ２０３はＲＦＣによって規定されたオブジェクト識別子を有している。ＲＦＣによると、ｓｙｓｔｅｍ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｍｉｂ−２ １ ｝となる。つまり、ｓｙｓｔｅｍ２０２のＯＩＤ（オブジェクト識別子）はｍｉｂ−２（２０１）配下の一番目のエントリーに配置されていることを示している。
【００３６】
一方、ｓｙｓＤｅｓｃｒ２０３のＲＦＣにおける定義は、
ｓｙｓＤｅｓｃｒ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ ＤｉｓｐｌａｙＳｔｒｉｎｇ （ＳＩＺＥ（０．．２５５））
ＡＣＣＥＳＳ ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ ｍａｎｄａｔｏｒｙ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ａ ｔｅｘｔｕａｌ ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｔｈｅ ｅｎｔｉｔｙ． Ｔｈｉｓ ｖａｌｕｅ ｓｈｏｕｌｄ ｉｎｃｌｕｄｅ ｔｈｅ ｆｕｌｌ ｎａｍｅ ａｎｄ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ｓｙｓｔｅｍ’ｓ ｈａｒｄｗａｒｅ ｔｙｐｅ， ｓｏｆｔｗａｒｅ ｏｐｅｒａｔｉｎｇ−ｓｙｓｔｅｍ， ａｎｄ ｎｅｔｗｏｒｋｉｎｇ ｓｏｆｔｗａｒｅ． Ｉｔ ｉｓ ｍａｎｄａｔｏｒｙ ｔｈａｔ ｔｈｉｓ ｏｎｌｙ ｃｏｎｔａｉｎ ｐｒｉｎｔａｂｌｅ ＡＳＣＩＩ ｃｈａｒａｃｔｅｒｓ．”
：：＝ ｛ｓｙｓｔｅｍ １｝
である。これによって、前述のｓｙｓｔｅｍ２０２の一番目のエントリーに配置されていることが示される。
【００３７】
ｓｙｓｔｅｍ２０２のｓｕｂ−ｔｒｅｅはテーブル型の構造にはなっていない（テーブルのエントリーが存在していない）。このため、例えば、ｓｙｓＤｅｓｃｒ２０３のＯＩＤは（１．３．６．１．２．１．１．１）であるが、ＳＮＭＰプロトコル上においてはスカラー型を示すｓｙｓＤｅｓｃｒ．０（１．３．６．１．２．１．１．１．０）で表現される。実際の取得値としては、ＳＮＭＰｖ２−ＭＩＢ：：ｓｙｓＤｅｓｃｒ．０＝ＳＴＲＩＮＧ： ＡＡＡ ｐｒｉｎｔｅｒという値（文字列で「ＡＡＡ ｐｒｉｎｔｅｒ」）の取得が可能である。
【００３８】
図３は、ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の他の一例を示す図である。
【００３９】
図３を参照して、テーブル型の例であるｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５とｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０について説明する。
【００４０】
ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５はＲＦＣによって規定されたオブジェクト識別子を有しており、ｍｉｂ−ｔｒｅｅの配置は図３で示すようになる。
【００４１】
ＲＦＣによると、
ｐｒｔＭａｒｋｅｒＥｎｔｒｙ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＰｒｔＭａｒｋｅｒ Ｅｎｔｒｙ
ＡＣＣＥＳＳ
ｎｏｔ−ａｃｃｅｓｓｉｂｌｅ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｅｎｔｒｉｅｓ ｍａｙ ｅｘｉｓｔ ｉｎ ｔｈｅ ｔａｂｌｅ ｆｏｒ ｅａｃｈ ｄｅｖｉｃｅ ｉｎｄｅｘ ｗｈｏ’ｓ ｄｅｖｉｃｅ ｔｙｐｅ ｉｓ ｀ｐｒｉｎｔｅｒ’．”
ＩＮＤＥＸ
｛ｈｒＤｅｖｉｃｅＩｎｄｅｘ， ｐｒｔＭａｒｋｅｒＩｎｄｅｘ｝
：：＝｛ｐｒｔＭａｒｋｅｒＴａｂｌｅ １ ｝
ｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
Ｃｏｕｎｔｅｒ ３２
ＡＣＣＥＳＳ
ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｔｈｅ ｃｏｕｎｔ ｏｆ ｔｈｅ ｎｕｍｂｅｒ ｏｆ ｕｎｉｔｓ ｏｆ ｍｅａｓｕｒｅ ｃｏｕｎｔｅｄ ｄｕｒｉｎｇ ｔｈｅ ｌｉｆｅ ｏｆ ｐｒｉｎｔｅｒ ｕｓｉｎｇ ｕｎｉｔｓ ｏｆ ｍｅａｓｕｒｅ ａｓ ｓｐｅｃｉｆｉｅｄ ｂｙ Ｃｏｕｎｔｅｒ Ｕｎｉｔ．”
：：＝｛ｐｒｔＭａｒｋｅｒＥｎｔｒｙ ４｝
である。これによって、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５の定義はｐｒｔ Ｍａｒｋｅｒ Ｅｎｔｒｙ３０３の４番目として定義されていることが分かる。また、図３からに分かるように、ｐｒｔＭａｒｋｅｒ Ｅｎｔｒｙ３０３は、ｐｒｔＭａｒｋｅｒ Ｔａｂｌｅ３０２の配下に位置し、ｐｒｔＭａｒｋｅｒ Ｔａｂｌｅ３０２はｐｒｔＭａｒｋｅｒ３０１の配下に位置している。ｐｒｔＭａｒｋｅｒ Ｅｎｔｒｙ３０３はＩＮＤＥＸ情報としてｈｒＤｅｖｉｃｅ ＩｎｄｅｘおよびｐｒｔＭａｒｋｅｒ Ｉｎｄｅｘ３０４を有するテーブル型の定義となっている。
【００４２】
管理しているネットワーク機器が複数のサブユニットデバイスに分割されて管理されている際に、ｈｒＤｅｖｉｃｅ Ｉｎｄｅｘはサブユニットデバイスが何番目のデバイス情報であるかを識別するためのＩｎｄｅｘ番号である。また、プリンタが複数のマーキング装置を有している際、ｐｒｔＭａｒｋｅｒ Ｉｎｄｅｘ３０４はマーキング装置が何番目のマーキング装置であるかを識別するためのＩｎｄｅｘ番号である。
【００４３】
ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５のＯＩＤは（１．３．６．１．２．１．４３．１０．２．１．４）であるが、テーブル型であるため、一番目のデバイスの一番目のマーキング装置のｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ（３０５）を示す場合には、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１（１．３．６．１．２．１．４３．１０．２．１．４．１．１）で表現される。
【００４４】
実際の取得値は、Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１＝Ｃｏｕｎｔｅｒ３２：６４３という値（カウンタ値で６４３）の取得が可能である。
【００４５】
続いて、同様なテーブル型の例として、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０について説明する。ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３０１において、ｍｉｂ−ｔｒｅｅの配置は図３で示すように。
【００４６】
ＲＦＣによると、
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＰｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ
ＡＣＣＥＳＳ
ｎｏｔ−ａｃｃｅｓｓｉｂｌｅ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ａｔｔｒｉｂｕｔｅｓ ｏｆ ａ ｍａｒｋｅｒ ｓｕｐｐｌｙ．
Ｅｎｔｒｉｅｓ ｍａｙ ｅｘｉｓｔ ｉｎ ｔｈｅ ｔａｂｌｅ ｆｏｒ ｅａｃｈ ｄｅｖｉｃｅ ｉｎｄｅｘ ｗｈｏ’ｓ ｄｅｖｉｃｅ ｔｙｐｅ ｉｓ ｀ｐｒｉｎｔｅｒ’．”
ＩＮＤＥＸ
｛ｈｒＤｅｖｉｃｅＩｎｄｅｘ， ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＩｎｄｅｘ｝
：：＝｛ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＴａｂｌｅ １ ｝
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＯＣＴＥＴ ＳＴＲＩＮＧ （ＳＩＺＥ（０．．２５５））
ＡＣＣＥＳＳ
ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｔｈｅ ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｔｈｉｓ ｓｕｐｐｌｙ ｃｏｎｔａｉｎｅｒ／ｒｅｃｅｐｔａｃｌｅ ｉｎ ｔｈｅ ｌｏｃａｌｉｚａｔｉｏｎ ｓｐｅｃｉｆｉｅｄ ｂｙ ｐｒｔＧｅｎｅｒａｌＣｕｒｒｅｎｔＬｏｃａｌｉｚａｔｉｏｎ．”
：：＝｛ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＥｎｔｒｙ ６ ｝
である。これによって、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０の定義は、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８の６番目として定義されていることが分かる。
【００４７】
また、図３から分かるように、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８は、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｔａｂｌｅ３０７の配下に位置している。ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｔａｂｌｅ３０７は、ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓ３０６の配下に位置している。
【００４８】
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８はＩＮＤＥＸ情報としてｈｒＤｅｖｉｃｅ Ｉｎｄｅｘ， ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｉｎｄｅｘ３０９を有するテーブル型の定義となっている。管理しているネットワーク機器が複数のサブユニットデバイスに分割されて管理されている場合には、ｈｒＤｅｖｉｃｅ Ｉｎｄｅｘは何番目のサブユニットデバイスに係る情報であるかを識別するためのＩｎｄｅｘ番号である。プリンタが複数のマーカーサプライ（例：トナーなどの消耗品）を有している際、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｉｎｄｅｘ３０９は何番目のマーカーサプライに係る情報であるかを識別するためのＩｎｄｅｘ番号である。
【００４９】
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０のＯＩＤは（１．３．６．１．２．１．４３．１１．１．１．６）であるが、テーブル型であるため、一番目のデバイスのｎ番目のマーカーサプライのｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０を示す場合にはｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．ｎ（１．３．６．１．２．１．４３．１１．１．１．６．１．ｎ）で表現される。
【００５０】
実際の取得値は、
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．１＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｂｌａｃｋ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．２＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｃｙａｎ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．３＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｍａｇｅｎｔａ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．４＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｙｅｌｌｏｗ Ｔｏｎｅｒ”
という値（文字列）の取得が可能である。
【００５１】
このように、ＲＦＣの標準規格として定義がされているＭＩＢ情報については、ネットワークの相互運用性を確立するために独自の拡張を行うことはできない。
【００５２】
＜制御部１１０の構成＞
図４は、図１に示すＭＦＰ１００に備えられた制御部１１０の一例を示すブロック図である。
【００５３】
図４において、制御部１１０はメインコントローラ４１１を有している。そして、メインコントローラ４１１はＣＰＵ４１２およびバスコントローラ４１３を備えるとともに、各種のＩ／Ｆ（インタフェース）コントローラ回路（図示せず）を備えている。ＣＰＵ４１２およびバスコントローラ４１３は、制御部１１０全体の動作を統括的に制御する。ＣＰＵ４１２は、ＲＯＭ４１４からＲＯＭＩ／Ｆ４１５を介して読み込んだプログラムに基づいて各種の動作を実行する。例えば、ＣＰＵ４１２は、読み込んだプログラムに基づいて、図１に示すＰＣ１６１又はＰＣ１６２から受信したコードデータ（例えば、ＰＤＬ（ページ記述言語））を解釈する。バスコントローラ４１３は各Ｉ／Ｆを介してデータ転送に関する制御、例えば、バスの調停およびＤＭＡデータ転送の制御を行う。
【００５４】
ＤＲＡＭ４１６は、ＤＲＡＭＩ／Ｆ４１７を介してメインコントローラ４１１と接続され、ＣＰＵ４１２が動作するためのワーク領域および画像データを蓄積するための領域として用いられる。
【００５５】
コーディック（Ｃｏｄｅｃ）４１８は、例えば、ＤＲＡＭ４１６に蓄積されたラスタイメージデータをＭＨ／ＭＲ／ＭＭＲ／ＪＢＩＧ／ＪＰＥＧ等の方式で圧縮する。また、Ｃｏｄｅｃ４１８は圧縮された状態で蓄積されたコードデータをラスタイメージデータに伸長する処理を行う。ＳＲＡＭ４１９は、Ｃｏｄｅｃ４１８の一時的なワーク領域として用いられる。Ｃｏｄｅｃ４１８は、Ｉ／Ｆ４２０を介してメインコントローラ４１１と接続される。
【００５６】
ＳＲＡＭ４１９とＤＲＡＭ４１６との間のデータの転送は、バスコントローラ４１３によって制御され、ＤＭＡ転送よってデータ転送が行われる。
【００５７】
グラフィックプロセッサ（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ）４３５は、ＤＲＡＭ４１６に蓄積されたラスタイメージデータに対して、画像回転、画像変倍、色空間変換、又は二値化等の処理を行う。ＳＲＡＭ４３６は、Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５の一時的なワーク領域として用いられる。Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５は、Ｉ／Ｆ４３７を介してメインコントローラ４１１と接続されている。Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５とＤＲＡＭ４１６との間のデータの転送は、バスコントローラ４１３によって制御され、ＤＭＡ転送によってデータ転送が行われる。
【００５８】
ネットワークコントローラ（ Ｎｅｔｗｏｒｋ Ｃｏｎｔｏｒｌｌｅｒ）４２１は、Ｉ／Ｆ４２３によってメインコントローラ４１１と接続され、コネクタ４２２を介して外部ネットワーク（例えば、ＬＡＮ１６０）と接続される。
【００５９】
汎用高速バス４２５には、拡張ボードを接続するための拡張コネクタ４２４とＩ／Ｏ制御部４２６とが接続される。汎用高速バス４２５は、例えば、ＰＣＩバスである。Ｉ／Ｏ制御部４２６は、リーダ部１２０およびプリンタ部１３０の各ＣＰＵ（つまり、スキャナコントローラ１２３およびプリンタコントローラ１３５）との間で制御コマンドを送受信するための調歩同期式のシリアル通信部コントローラ４２７を２チャンネル備えている。
【００６０】
Ｉ／Ｏ制御部４２６は、Ｉ／Ｏバス４２８を介してスキャナＩ／Ｆ４４０およびプリンタＩ／Ｆ４４５と接続されている。パネルＩ／Ｆ４３２は、操作部１４０との間でデータの送受信を行うためのＩ／Ｆである。パネルＩ／Ｆ４３２は、ＬＣＤコントローラ４３１から転送されてきた画像データを操作部１４０に転送する。また、パネルＩ／Ｆ４３２は、操作部１４０が備えるハードキー又はタッチパネルを介して入力されるキー入力信号を、キー入力Ｉ／Ｆ４３０を介してＩ／Ｏ制御部４２６に転送する。
【００６１】
リアルタイムクロックモジュール４３３は、バックアップ用電池４３４によって電力を供給され、ＭＦＰ１００で管理する日付及び時刻を更新／保存する。Ｅ−ＩＤＥ Ｉ／Ｆ４６１は、ＨＤＤ１５０を接続するＩ／Ｆである。ＣＰＵ４１２は、Ｅ−ＩＤＥ Ｉ／Ｆ４６１を介してＨＤＤ１５０に画像データを記憶させ、又はＨＤＤ１５０から画像データを読み込む。
【００６２】
コネクタ４４２および４４７には、それぞれリーダ部１２０およびプリンタ部１３０が接続される。コネクタ４４２および４４７は、同調歩同期シリアルＩ／Ｆ４４３および４４８とビデオＩ／Ｆ４４４および４４９を介してスキャナＩ／Ｆ４４０およびプリンタＩ／Ｆ４４５に接続されている。
【００６３】
スキャナＩ／Ｆ４４０は、コネクタ４４２を介してリーダ部１２０と接続され、スキャナバス４４１を介してメインコントローラ４１１と接続されている。スキャナＩ／Ｆ４４０は、リーダ部１２０から受信した画像データに対して所定の処理を施す。また、スキャナＩ／Ｆ４４０は、リーダ部１２０から受信したビデオ制御信号に基づいて生成した制御信号を、スキャナバス４４１に出力する。スキャナバス４４１からＤＲＡＭ４１６へのデータ転送は、バスコントローラ４１３によって制御される。
【００６４】
プリンタＩ／Ｆ４４５は、コネクタ４４７を介してプリンタ部１３０と接続され、プリンタバス４４６を介してメインコントローラ４１１と接続されている。プリンタＩ／Ｆ４４５は、メインコントローラ４１１から出力された画像データに所定の処理を施して、プリンタ部１３０へ出力する。ＤＲＡＭ４１６上に展開されたラスタイメージデータをプリンタ部１３０に転送する際には、バスコントローラ４１３による制御が行われる。当該ラスタイメージデータはプリンタバス４４６、プリンタＩ／Ｆ４４５、およびビデオＩ／Ｆ４４９を介してプリンタ部１３０にＤＭＡ転送される。
【００６５】
ＳＲＡＭ４５１は、バックアップ用の電池から供給される電力によって、ＭＦＰ１００の電源が遮断された状態でも記憶内容を保持し続けることが可能なメモリである。ＳＲＡＭ４５１は、バス４５０を介してＩ／Ｏ制御部４２６と接続されている。また、ＥＥＰＲＯＭ４５２も同様に、バス４５０を介してＩ／Ｏ制御部４２６と接続されたメモリである。
【００６６】
図５は、図１に示すＭＦＰ１００においてパケットデータ（ＳＮＭＰパケット）を受信した際の返信処理の一例を説明するためのフローチャートである。また、図６は図１に示すＭＦＰ１００に予め記録されたレスポンステーブルの一例を示す図である。なお、例えば、ＣＰＵ４１２はＲＯＭ４１４に格納されたプログラムを読み出して図５に示すフローチャートの各ステップを実行する。
【００６７】
ＭＦＰ１００は図６に示すレスポンステーブルを有している。そして、ＣＰＵ４１２は後述するようにしてこのレスポンステーブルを参照して、受信パケットデータに対する返信を行う。図示のように、レスポンステーブルは複数の返信値と当該返信値に対する優先度（優先順位ともいう）が規定されている。さらに、レスポンステーブルには返信値に対応する返信識別名が規定されている。そして、後述するように、ＣＰＵ４１２は返信識別名を用いてＮｅｔｗｏｒｋ Ｃｏｎｔｏｒｌｌｅｒ４２１を制御して、ＳＮＭＰパケットとしてＬＡＮ１６０に送出する。
【００６８】
なお、レスポンステーブルに規定された優先度はユーザが操作部１４０を用いて変更することができる。
【００６９】
いま、ＳＮＭＰパケットの送信・受信処理が開始されると、ＣＰＵ４１２は、例えば、ＰＣ１６１から送信されたＳＮＭＰパケット（機器情報取得要求）を受信する（ステップＳ６０２）。ステップＳ６０２では、ＰＣ１６１はＭＦＰ１００からその機器情報を取得するためにＳＮＭＰパケットを送出したものとする。つまり、ここでは、ＳＮＭＰパケットはリクエスト・パケットである。このリクエスト・パケットは単一のパケットデータに２つのアイテム（ｉｔｅｍ）が含まれており、ｓｙｓＤｅｓｃｒ情報を複数取得する際に用いられる。
【００７０】
続いて、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤ（オブジェクト識別子）が互いに一致するか否かを判定する（ステップＳ６０３）。
【００７１】
いま、ステップＳ６０２において、符号６００１で示すように、複数のＯＩＤが互いに一致するＳＮＭＰパケットを受信したとすると、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤが互いに一致すると判定することになる。複数のＯＩＤが互いに一致すると判定すると（ステップＳ６０３において、ＹＥＳ）、ＣＰＵ４１２は、予め設定された返信条件に基づいて同一のＯＩＤ（オブジェクト識別子）に対して互いに異なる返信値を選択（採用）するか否かについて判定する（ステップＳ６０４）。なお、上記の返信条件は、ユーザによって予め操作部１４０から設定されているものとする。
【００７２】
いま、互いに異なる返信値を採用しないと判定すると（ステップＳ６０４において、ＮＯ）、ＣＰＵ４１２は図６に示すレスポンステーブルを参照して、優先度が最も高い返信値（つまり、最高順位の返信値）に係る返信識別名を採用して、ＳＮＭＰパケットによって返信処理を行う（ステップＳ６０５）。そして、ＣＰＵ４１２は処理を終了する。
【００７３】
一方、互いに異なる返信値を採用すると判定すると（ステップＳ６０４において、ＹＥＳ）、ＣＰＵ４１２はレスポンステーブルを参照して、優先度の高い順で返信値の並び替えを行う。そして、ＣＰＵ４１２は同一のＯＩＤの並び順と返信値の並び順とに応じて返信値とＯＩＤとを突き合わせて送信バッファに返信識別名を格納する（ステップＳ６０７）。続いて、ＣＰＵ４１２は送信バッファに格納された送信識別名（値）の順でＳＮＭＰパケットによる返信を行って（ステップＳ６０８）、処理を終了する。
【００７４】
ステップＳ６０２において、符号６００２で示すように、リクエスト・パケットとして単一のパケットデータに２つのアイテムが含まれ、ｓｙｓＤｅｓｃｒ情報およびｉｆＮｕｍｂｅｒ情報とを取得するためのパケットを受信したとする。このように、複数のＯＩＤが互いに一致しないＳＮＭＰパケットを受信したとすると、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤが互いに一致しないと判定することになる。
【００７５】
複数のＯＩＤが互いに一致しないと判定すると（ステップＳ６０３において、ＮＯ）、ＣＰＵ４１２は各ＯＩＤについての個別の返信値を採用して、返信識別名を用いてＳＮＭＰパケットによって返信を行う（ステップＳ６１０）。そして、ＣＰＵ４１２は処理を終了する。そして、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００から返信されたレスポンス（ＳＮＭＰパケット）に含まれる返信識別名に応じて処理の切替を行うことになる。
【００７６】
このように、第１の実施形態では、管理端末であるＰＣ１６１又はＰＣ１６２が予めネットワーク機器であるＭＦＰ１００を見分ける必要がなく、リクエスト・パケットに対するＭＦＰ１００からのレスポンスを受けて、当該レスポンスにＭＦＰ１００を識別可能な情報が含まれているか否かによって処理の切り替えを行うことができる。つまり、情報処理装置で使用するソフトウェアが異なってもＭＦＰ１００の管理を容易に行うことができる。
【００７７】
なお、単一のパケットに情報識別子（ＯＩＤ）が複数指定されていない場合には、返信値（返信識別名）については従来と同様にしてＳＮＭＰパケットの返信が行われる結果、既存のネットワークシステムに導入した場合においても悪影響を及ぼすことはない。
【００７８】
［第２の実施形態］
続いて、本発明の第２の実施形態によるＭＦＰ１００の一例について説明する。ここでは、単一のＳＮＭＰパケットに情報識別子（ＯＩＤ）が複数指定されている際に、予め設定された返信値（返信識別名）を用いることなく、返信値に関する履歴情報を記憶して、前回のレスポンスの返信が行われた際に返信した返信値又はＭＦＰ１００において所定の時間毎に更新した返信値を用いる。なお、ネットワークシステムの構成およびＭＦＰ１００の構成は図１および図４と同様であるので説明を省略する。
【００７９】
図７は、本発明の第２の実施形態によるＭＦＰ１００の処理を説明するためのフローチャートである。ＣＰＵ４１２はＲＯＭ４１４に格納されたプログラムを読み出して図７に示すフローチャートの各ステップを実行する。
【００８０】
図１、図４、および図７を参照して、ＳＮＭＰパケットの送信・受信処理が開始されると、ＣＰＵ４１２は、例えば、ＰＣ１６１から送信されたＳＮＭＰパケットを受信する（ステップＳ７０２）。ステップＳ７０２では、ＰＣ１６１はＭＦＰ１００からその機器情報を取得するためにＳＮＭＰパケットを送出したものとする。つまり、ここでは、ＳＮＭＰパケットはリクエスト・パケットである。このリクエスト・パケットは単一のパケットデータに２つのアイテム（ｉｔｅｍ）が含まれており、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１情報を複数取得する際に用いられる。
【００８１】
続いて、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤ（オブジェクト識別子）が互いに一致するか否かに判定する（ステップＳ７０３）。複数のＯＩＤが互いに一致すると判定すると（ステップＳ７０３において、ＹＥＳ）、ＣＰＵ４１２は、予め設定された返信条件に基づいて同一のＯＩＤ（識別子）に対して互いに異なる返信値を採用するか否かについて判定する（ステップＳ７０４）。上記の返信条件は、前述のようにユーザによって予め操作部１４０から設定されている。
【００８２】
互いに異なる返信値を選択（採用）しないと判定すると（ステップＳ７０４において、ＮＯ）、ＣＰＵ４１２は、現在のｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１の返信値（図示の例では”５７”）を各ＯＩＤの返信値として採用する。そして、当該返信値をＳＮＭＰパケットによってＰＣ１６１に返信して（ステップＳ７０５）、処理を終了する。
【００８３】
一方、互いに異なる返信値を採用すると判定すると（ステップＳ７０４において、ＹＥＳ）、ＣＰＵ４１２はレスポンステーブル（返信値テーブル）を更新する（ステップＳ７０７）。
【００８４】
図８は本発明の第２の実施形態による返信値テーブルの更新の一例を説明するための図である。
【００８５】
図８において、返信値テーブルは複数のバッファに関連付けられており、ここでは、バッファ”１”〜”３”に関連付けられている。そして、バッファ”１”〜”３”に格納された情報がそれぞれ第１〜第３の返信値とされる。ここでは、バッファ”１”は第１のバッファであり、バッファ”２”および”３”はそれぞれ付加バッファである。
【００８６】
再び、図１、図４、および図７を参照して、ＣＰＵ４１２は返信値テーブルを更新する際には、前回第１の返信値として用いた返信値を第２の返信値として用いるために、バッファ”１”に格納された第１の返信値を第２の返信値としてバッファ”２”に格納する。さらに、ＣＰＵ４１２は前回第２の返信値として用いた返信値を第３の返信値として用いるために、バッファ”２”に格納された第２の返信値を第３の返信値としてバッファ”３”に格納する。
【００８７】
図８に示す例では、前回の返信際に用いた第１〜第３の返信値はそれぞれ１回目８０２で示す返信値となる。そして、ＣＰＵ４１２は今回の返信の際に、バッファ”２”の返信値をバッファ”３”にコピーし、バッファ”１”の返信値をバッファ”２”にコピーする。つまり、ＣＰＵ４１２はバッファ”１”〜”３”に格納された返信値を順次シフトする処理を行う。
【００８８】
続いて、ＣＰＵ４１２は現在のｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ．１．１の返信値（図７に示す例では”５７”）を、図８に示す２回目８０３の返信値（つまり、第１の返信値）としてバッファ”１”に格納する。２回目以降におけるバッファ”１”〜”３”の更新について、同様にして、ＣＰＵ４１２は処理する結果、例えば、図８に示す３回目８０４に示すようになる。つまり、ＣＰＵ４１２は現在の印刷カウント値（ここでは、”１２３”）をプリンタ部１３０から取得して第１の返信値としてバッファ”１”に格納する（ステップＳ７０８）。つまり、ＣＰＵ４１２は最新の印刷カウント値を機器情報として第１のバッファに格納することになる。
【００８９】
このようにして、返信値テーブルの更新（つまり、バッファ更新）を完了した後、ＣＰＵ４１２はバッファ”１”および”２”に格納された返信値に応じてＳＮＭＰパケットを生成して、当該ＳＮＭＰパケット（つまり、レスポンス）をＰＣ１６１に返信する（ステップＳ７０９）。そして、ＣＰＵ４１２は処理を終了する。
【００９０】
つまり、ＣＰＵ４１２はバッファ”１”に格納された返信値をＯＩＤの１つに対応づけ、バッファ”２”に格納された返信値をＯＩＤの残りに順次対応づけてＳＮＭＰパケット（このＳＮＭＰパケットはレスポンスである）を生成することになる。
【００９１】
ステップＳ７０３において、複数のＯＩＤが互いに一致しないと判定すると（ステップＳ７０３において、ＮＯ）、ＣＰＵ４１２は各ＯＩＤについての個別の返信値を用いてＳＮＭＰパケットよって返信を行う（ステップＳ７１０）。そして、ＣＰＵ４１２は処理を終了する。そして、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００から返信されたレスポンス（ＳＮＭＰパケット）に含まれる返信値に応じて処理の切替を行うことになる。
【００９２】
図９は、本発明の第２の実施形態による返信値テーブルの更新の他の例を説明するための図である。
【００９３】
図９において、ＣＰＵ４１２はバッファ”１”に格納する返信値を、ＭＦＰ１００（例えば、プリンタ部）の現在の印刷カウント値を格納する。そして、ＣＰＵ４１２は予め定められた時間間隔でバッファ”２”以降に格納された返信値を、図８で説明したようにして更新する。図９に示す例では、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１に関する返信値について、１回目９０２の返信値と２回目９０３の返信値が示されている。ここでは、バッファ”１”には現在の印刷カウント値が格納され、バッファ”２”以降においては１時間の時間間隔で返信値が更新されている。
【００９４】
なお、この時間間隔はユーザが操作部１４０を用いて設定するようにしてもよい。
【００９５】
このように、第２の実施形態では、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００における現在の印刷カウント値に加えて、その前（過去）の印刷カウント値を履歴情報データとしても参照することができる。このため、所定の時間間隔でＭＦＰ１００の状態を確認することができるばかりでなく、さらには印刷枚数の差分（つまり、所定の時間毎の印刷枚数）を容易に確認することができる。
【００９６】
上述の説明から明らかなように、図１において、制御部１１０は判定手段、決定手段、および返信手段の一例である。また、制御部１１０および操作部１４０は設定手段の一例である。
【００９７】
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【００９８】
例えば、上記の実施の形態の機能を制御方法として、この制御方法を、ネットワーク機器であるＭＦＰ１００に実行させるようにすればよい。また、上記の実施の形態の各機能を、ネットワーク機器単体で実行するのではなく、ネットワーク上の複数の装置で分散して実行するようにしてもよい。即ち、図５や図７に示すフローチャートの一部のステップを、ＭＦＰ１００ではないネットワーク上の外部装置に実行させるようにしてもよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、この制御プログラムをネットワーク機器であるＭＦＰ１００が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記録媒体に記録される。
【００９９】
この際、制御方法および制御プログラムは、少なくとも判定ステップ、設定ステップ、決定ステップ、および返信ステップを有することになる。
【０１００】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１０１】
１００ 画像形成装置（ＭＦＰ）
１１０ 制御部（コントローラ部）
１２０ リーダ部
１３０ プリンタ部
１３１ 給紙ユニット
１３２ マーキングユニット
１３４ 排紙ユニット
１４０ 操作部
１６０ ネットワーク（ＬＡＮ）
１６１，１６２ 管理端末（ＰＣ）
【技術分野】
【０００１】
本発明は、ネットワークに接続されたネットワーク機器、その制御方法、および制御プログラムに関する。
【背景技術】
【０００２】
一般に、ネットワークに直接接続されたネットワーク機器（以下ネットワークデバイスともいい、例えば、ＭＦＰなどの画像形成装置をいう）を、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）などのデバイス管理プロトコルを用いて管理することが知られている。さらに、パソコンなどの情報処理装置がネットワークに接続され、情報処理装置に接続されたデバイスと上記のネットワークデバイスとを区別可能として一元管理するようにしたシステムが知られている（例えば、特許文献１参照）。
【０００３】
特許文献１に記載のデバイスの管理手法では、ネットワークデバイスが直接ネットワーク接続されているか否かを事前に区別するとともに、ネットワークデバイスである場合には、情報処理装置はＳＮＭＰを用いてネットワークデバイスに関するデバイス情報を取得する必要がある。
【０００４】
一方、ネットワークに接続された情報処理装置にＵＳＢなどで接続されたデバイスについては、接続先のデバイスに適したプロトコルでデバイス情報を取得するための要求コマンド送出して管理を行っている。つまり、情報処理装置においてデバイス情報の取得の要求を行う際に、予めデバイスの種別を認識して要求コマンドを変更するようにしている。
【０００５】
さらに、別のデバイス管理手法として、例えば、ネットワークデバイスに固有に割り当てられたシステム名称等を、情報処理装置が管理プロトコルを用いて取得するようにしたものがある。ここでは、情報処理装置は、取得したシステム名称などの識別情報に応じてネットワークデバイスに問い合わせを行うためのコマンドに切り替えて、ネットワークデバイスからデバイス情報を取得するようにしている。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００８−２７１２８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところが、情報処理装置においてネットワークデバイスが当該情報処理装置に直接接続されているか又は他の情報処理装置を介してネットワークに接続されているかについて事前に判定することは困難である。そして、事前に上記の接続形態が判定できないと、情報処理装置は要求コマンドの変更を行うことができず、必要なデバイス情報の収集に支障をきたす可能性がある。
【０００８】
また、ＳＮＭＰにおいて取得可能なＭＩＢ（Ｍａｎａｇｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ Ｂａｓｅ）情報には、例えば、スカラー型およびテーブル型の２種類のＭＩＢ変数が存在している。そして、スカラー型は単一の値を有しており、例えば、ｓｙｓＤｅｓｃｒ（図２の２０３）というＭＩＢ値は、読み出し専用（Ｒｅａｄ Ｏｎｌｙ）の情報である。このＭＩＢ値はネットワークデバイスに関する説明を示す文字列としてデバイスに一つしか存在しない情報である。
【０００９】
一方、テーブル型の場合には、類似の情報をテーブル情報として複数示すことが可能である。例えば、消耗品であるトナーの情報を、ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＤｅｓｃｒｉｐｔｉｏｎ（図３の３１０）というＭＩＢ値を用いて、シアン（Ｃ）、マゼンタ（Ｍ）、イエロー（Ｙ）、およびブラック（Ｋ）の４色のトナー情報として個別に列挙することが可能である。
【００１０】
一般的な情報処理装置では、ネットワークデバイスに一つしか存在せず、かつＲｅａｄ Ｏｎｌｙのスカラー型の情報を用いてデバイスの識別を行って、詳細な管理情報を取得するためのロジックを切り替えるなどして最適化を行っている。
【００１１】
このため、異なるソフトウェアを用いた情報処理装置において、デバイス識別の可／不可が異なるようなケースが存在する。この場合、デバイス識別が可能なソフトウェアを用いた情報処理装置でのみネットワークデバイスの詳細な情報および状態の管理が行えることになって、使用するソフトウェアが異なるとデバイスの管理が行えず、利便性が低下してしまう。
【００１２】
従って、本発明の目的は、情報処理装置で使用するソフトウェアが異なっても情報処理装置が機器情報を容易に取得して管理を行うことのできるネットワーク機器、その制御方法、および制御プログラムを提供することにある。
【課題を解決するための手段】
【００１３】
上記の目的を達成するため、本発明によるネットワーク機器は、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器であって、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定手段と、前記判定手段によって複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定手段と、前記決定手段による決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信手段とを有することを特徴とする。
【００１４】
本発明による制御方法は、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器の制御方法であって、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを有することを特徴とする。
【００１５】
本発明による制御プログラムは、ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器で用いられる制御プログラムであって、前記ネットワーク機器が備えるコンピュータに、前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを実行させることを特徴とする。
【発明の効果】
【００１６】
本発明によれば、管理端末である情報処理装置がネットワーク機器からその機器情報を取得する際に、管理端末で使用するソフトウェアが異なっても、特別な設定を行う必要なく容易に機器情報を取得してネットワーク機器の管理を行うことができる。
【図面の簡単な説明】
【００１７】
【図１】本発明の第１の実施形態によるネットワーク機器が用いられたネットワークシステムの一例を示す図である。
【図２】ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の一例を示す図である。
【図３】ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の他のを示す図である。
【図４】図１に示すＭＦＰに備えられた制御部の構成の一例を示すブロック図である。
【図５】図１に示すＭＦＰにおいてパケットデータを受信した際の返信処理の一例を説明するためのフローチャートである。
【図６】図１に示すＭＦＰに予め記録されたレスポンステーブルの一例を示す図である。
【図７】本発明の第２の実施形態によるＭＦＰ１００の返信処理を説明するためのフローチャートである。
【図８】本発明の第２の実施形態による返信値テーブルの更新の一例を説明するための図である。
【図９】本発明の第２の実施形態による返信値テーブルの更新の他の例を説明するための図である。
【発明を実施するための形態】
【００１８】
以下、本発明の実施の形態によるネットワーク機器の一例について図面を参照して説明する。
【００１９】
［第１の実施形態］
図１は、本発明の第１の実施形態によるネットワーク機器が用いられたネットワークシステムの一例を示す図である。なお、図１においては、ネットワーク機器の一例として、例えば、ＭＦＰ（複合機）などの画像形成装置が示されており、ここでは、ＭＦＰを例に挙げて説明する。ただし、本発明のネットワーク機器は、ＭＦＰ等の画像形成装置に限るものではない。
【００２０】
図示のネットワークシステムは、ＭＦＰ（画像形成装置）１００を有しており、このＭＦＰ１００はＬＡＮ１６０などのネットワークに接続されている。さらに、図示の例では、ＬＡＮ１６０には情報処理装置であるＰＣ１６１および１６２が接続されている。つまり、ＭＦＰ１００はネットワークを介してＰＣ１６１および１６２に接続可能となっている。なお、図１には示されていないが、ＬＡＮ１６０には他のＰＣが接続されるとともに、別のＭＦＰおよびプリンタなどが接続されることがある。また、ＰＣ１６１および１６２にはプリンタなどの画像形成装置が接続されることがある。
【００２１】
＜画像形成装置の構成＞
図示のＭＦＰ１００はコピー機能およびプリンタ機能等の複数の機能を有している。なお、画像形成装置として、コピー機能又はプリンタ機能のみを有するＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）を用いるようにしてもよい。
【００２２】
ＭＦＰ１００は制御部（コントローラ部）１１０を有している。制御部１１０はリーダ部１２０およびプリンタ部１３０に接続されている。制御部１１０はリーダ部１２０およびプリンタ部１３０から各種データを受信する。また、制御部１１０はリーダ部１２０およびプリンタ部１３０に対して各種コマンドを送信する。さらに、制御部１１０はＬＡＮ１６０を介してＰＣ１６１又は１６２と接続されており、ＰＣ１６１又は１６２から画像データおよび制御コマンドを受信する。なお、ＬＡＮ１６０は、例えば、イーサネット（登録商標）で構築される。ＰＣ１６１および１６２の各々は管理端末とも呼ばれ、ＭＦＰ１００についてその機器構成および現在のステータスの監視等も行う。
【００２３】
リーダ部１２０は原稿上の画像を光学的に読み取って画像データを得る。リーダ部１２０はスキャナユニット１２１および原稿給紙ユニット（ＤＦユニット）１２２を備えている。ＤＦユニット１２２によって原稿はスキャナユニット１２１によって読み取り可能な位置まで搬送される。そして、スキャナユニット１２１によって原稿上の画像が読み取られる。スキャナユニット１２１はスキャナコントローラ１２３を備えており、このスキャナコントローラ１２３は制御部１１０からの指示に基づいてスキャナユニット１２１および原稿給紙ユニット１２２を制御する。
【００２４】
プリンタ部１３０は給紙ユニット１３１、マーキングユニット１３２、および排紙ユニット１３４を備えている。マーキングユニット１３２にはプリンタコントローラ１３５が備えられており、プリンタコントローラ１３５は制御部１１０の制御下で給紙ユニット１３１、マーキングユニット１３２、および排紙ユニット１３４を制御する。
【００２５】
給紙ユニット１３１には印刷用紙が収納され、給紙ユニット１３１からマーキングユニット１３２に用紙が搬送される。マーキングユニット１３２は、例えば、電子写真プロセスによって画像データに応じた画像を用紙に形成する。そして、画像形成（印刷）が行われた後、用紙は排紙ユニット１３４によって排紙される。なお、排紙ユニット１３４では印刷後の用紙に対して、ソートおよびステイプル等の処理を行うことができる。
【００２６】
給紙ユニット１３１には複数の給紙部が備えられている。給紙部には、例えば、普通紙および光沢紙などの複数種類の用紙を収納することができる。また、給紙部には、プリンタ部１３０において印刷された用紙を再び収納することもできる。給紙部の例として、給紙カセット、給紙デッキ、又は手差用紙レイなどがある。
【００２７】
操作部１４０は、例えば、ハードキー、液晶表示部、および当該液晶表示部の表面上に貼り付けられたタッチパネル部を備えており、操作部１４０によってユーザの指示が受け付けられる。さらに、操作部１４０の液晶表示部にはソフトキーが表示されるとともに、ＭＦＰ１００の機能および状態が表示される。操作部１４０で受け付けたユーザの指示に対応するコマンドは制御部１１０に送られる。図示の例では、ＭＦＰ１００にはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）１５０が備えられ、このＨＤＤには、ＭＦＰ１００に係る各種設定および画像データなどが記憶される。
【００２８】
図示のＭＦＰ１００は、コピー機能、画像データ送信機能、およびプリンタ機能などの複数の機能を有している。コピー機能を用いる際には、前述のように、制御部１１０はリーダ部１２０を制御して原稿上の画像データを読み込み、プリンタ部１３０を制御して画像データに応じた印刷を行う。
【００２９】
画像データ送信機能を用いる際には、制御部１１０はリーダ部１２０による読み取りの結果得られた画像データをコードデータに変換して、当該コードデータを、ＬＡＮ１６０を介してＰＣ１６１又は１６２に送信する。プリンタ機能を用いる際には、制御部１１０はＰＣ１６１又は１６２からＬＡＮ１６０を介して受信したコードデータ（印刷データ）を画像データに変換して、プリンタ部１３０に送信する。そして、プリンタ部１３０は、受信した画像データを応じて用紙に印刷を行う。なお、制御部１１０の構成については後述する。
【００３０】
続いて、ＰＣ１６１又は１６２がネットワーク機器であるＭＦＰ１００からその構成情報を取得する際に用いられる一般的な手法（以下標準技術と呼ぶ）について説明する。
【００３１】
＜標準技術の説明＞
ここでは、ＩＥＴＦ（Ｉｎｔｅｒｎｅｔ Ｅｎｇｉｎｅｅｒｉｎｇ Ｔａｓｋ Ｆｏｒｃｅ）がインターネットで用いられる技術の標準化を目的として発行するＲＦＣ（Ｒｅｑｕｅｓｔ ｆｏｒ Ｃｏｍｍｅｎｔｓ）に基づいたネットワーク機器からの情報取得について説明する。
【００３２】
一般的に、ネットワーク機器における情報管理プロトコルとしてＳＮＭＰが用いられている。ＳＮＭＰで管理されるネットワーク機器には、ＭＩＢ情報が格納されている。そして、管理端末（図１に示すＰＣ１６１又は１６２）から送られるＳＮＭＰリクエストに対してネットワーク機器がレスポンス（ＭＩＢ情報）を返信し、これによって、管理端末がネットワーク機器の管理を行う。なお、ＭＩＢ情報の構造についてもＩＥＦＴにおいて標準化されている。
【００３３】
ＳＮＭＰにおいて取得可能なＭＩＢ情報にはスカラー型およびテーブル型の２種類のＭＩＢ変数が存在している。ここで、スカラー型の例として、ｓｙｓＤｅｓｃｒについて説明する。
【００３４】
図２は、ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の一例を示す図である。
【００３５】
図２において、ｓｙｓＤｅｓｃｒ２０３はＲＦＣによって規定されたオブジェクト識別子を有している。ＲＦＣによると、ｓｙｓｔｅｍ ＯＢＪＥＣＴ ＩＤＥＮＴＩＦＩＥＲ：：＝｛ｍｉｂ−２ １ ｝となる。つまり、ｓｙｓｔｅｍ２０２のＯＩＤ（オブジェクト識別子）はｍｉｂ−２（２０１）配下の一番目のエントリーに配置されていることを示している。
【００３６】
一方、ｓｙｓＤｅｓｃｒ２０３のＲＦＣにおける定義は、
ｓｙｓＤｅｓｃｒ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ ＤｉｓｐｌａｙＳｔｒｉｎｇ （ＳＩＺＥ（０．．２５５））
ＡＣＣＥＳＳ ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ ｍａｎｄａｔｏｒｙ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ａ ｔｅｘｔｕａｌ ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｔｈｅ ｅｎｔｉｔｙ． Ｔｈｉｓ ｖａｌｕｅ ｓｈｏｕｌｄ ｉｎｃｌｕｄｅ ｔｈｅ ｆｕｌｌ ｎａｍｅ ａｎｄ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ ｏｆ ｔｈｅ ｓｙｓｔｅｍ’ｓ ｈａｒｄｗａｒｅ ｔｙｐｅ， ｓｏｆｔｗａｒｅ ｏｐｅｒａｔｉｎｇ−ｓｙｓｔｅｍ， ａｎｄ ｎｅｔｗｏｒｋｉｎｇ ｓｏｆｔｗａｒｅ． Ｉｔ ｉｓ ｍａｎｄａｔｏｒｙ ｔｈａｔ ｔｈｉｓ ｏｎｌｙ ｃｏｎｔａｉｎ ｐｒｉｎｔａｂｌｅ ＡＳＣＩＩ ｃｈａｒａｃｔｅｒｓ．”
：：＝ ｛ｓｙｓｔｅｍ １｝
である。これによって、前述のｓｙｓｔｅｍ２０２の一番目のエントリーに配置されていることが示される。
【００３７】
ｓｙｓｔｅｍ２０２のｓｕｂ−ｔｒｅｅはテーブル型の構造にはなっていない（テーブルのエントリーが存在していない）。このため、例えば、ｓｙｓＤｅｓｃｒ２０３のＯＩＤは（１．３．６．１．２．１．１．１）であるが、ＳＮＭＰプロトコル上においてはスカラー型を示すｓｙｓＤｅｓｃｒ．０（１．３．６．１．２．１．１．１．０）で表現される。実際の取得値としては、ＳＮＭＰｖ２−ＭＩＢ：：ｓｙｓＤｅｓｃｒ．０＝ＳＴＲＩＮＧ： ＡＡＡ ｐｒｉｎｔｅｒという値（文字列で「ＡＡＡ ｐｒｉｎｔｅｒ」）の取得が可能である。
【００３８】
図３は、ｍｉｂ−ｔｒｅｅ上のＭＩＢオブジェクトの配置の他の一例を示す図である。
【００３９】
図３を参照して、テーブル型の例であるｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５とｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０について説明する。
【００４０】
ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５はＲＦＣによって規定されたオブジェクト識別子を有しており、ｍｉｂ−ｔｒｅｅの配置は図３で示すようになる。
【００４１】
ＲＦＣによると、
ｐｒｔＭａｒｋｅｒＥｎｔｒｙ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＰｒｔＭａｒｋｅｒ Ｅｎｔｒｙ
ＡＣＣＥＳＳ
ｎｏｔ−ａｃｃｅｓｓｉｂｌｅ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｅｎｔｒｉｅｓ ｍａｙ ｅｘｉｓｔ ｉｎ ｔｈｅ ｔａｂｌｅ ｆｏｒ ｅａｃｈ ｄｅｖｉｃｅ ｉｎｄｅｘ ｗｈｏ’ｓ ｄｅｖｉｃｅ ｔｙｐｅ ｉｓ ｀ｐｒｉｎｔｅｒ’．”
ＩＮＤＥＸ
｛ｈｒＤｅｖｉｃｅＩｎｄｅｘ， ｐｒｔＭａｒｋｅｒＩｎｄｅｘ｝
：：＝｛ｐｒｔＭａｒｋｅｒＴａｂｌｅ １ ｝
ｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
Ｃｏｕｎｔｅｒ ３２
ＡＣＣＥＳＳ
ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｔｈｅ ｃｏｕｎｔ ｏｆ ｔｈｅ ｎｕｍｂｅｒ ｏｆ ｕｎｉｔｓ ｏｆ ｍｅａｓｕｒｅ ｃｏｕｎｔｅｄ ｄｕｒｉｎｇ ｔｈｅ ｌｉｆｅ ｏｆ ｐｒｉｎｔｅｒ ｕｓｉｎｇ ｕｎｉｔｓ ｏｆ ｍｅａｓｕｒｅ ａｓ ｓｐｅｃｉｆｉｅｄ ｂｙ Ｃｏｕｎｔｅｒ Ｕｎｉｔ．”
：：＝｛ｐｒｔＭａｒｋｅｒＥｎｔｒｙ ４｝
である。これによって、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５の定義はｐｒｔ Ｍａｒｋｅｒ Ｅｎｔｒｙ３０３の４番目として定義されていることが分かる。また、図３からに分かるように、ｐｒｔＭａｒｋｅｒ Ｅｎｔｒｙ３０３は、ｐｒｔＭａｒｋｅｒ Ｔａｂｌｅ３０２の配下に位置し、ｐｒｔＭａｒｋｅｒ Ｔａｂｌｅ３０２はｐｒｔＭａｒｋｅｒ３０１の配下に位置している。ｐｒｔＭａｒｋｅｒ Ｅｎｔｒｙ３０３はＩＮＤＥＸ情報としてｈｒＤｅｖｉｃｅ ＩｎｄｅｘおよびｐｒｔＭａｒｋｅｒ Ｉｎｄｅｘ３０４を有するテーブル型の定義となっている。
【００４２】
管理しているネットワーク機器が複数のサブユニットデバイスに分割されて管理されている際に、ｈｒＤｅｖｉｃｅ Ｉｎｄｅｘはサブユニットデバイスが何番目のデバイス情報であるかを識別するためのＩｎｄｅｘ番号である。また、プリンタが複数のマーキング装置を有している際、ｐｒｔＭａｒｋｅｒ Ｉｎｄｅｘ３０４はマーキング装置が何番目のマーキング装置であるかを識別するためのＩｎｄｅｘ番号である。
【００４３】
ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ３０５のＯＩＤは（１．３．６．１．２．１．４３．１０．２．１．４）であるが、テーブル型であるため、一番目のデバイスの一番目のマーキング装置のｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ（３０５）を示す場合には、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１（１．３．６．１．２．１．４３．１０．２．１．４．１．１）で表現される。
【００４４】
実際の取得値は、Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１＝Ｃｏｕｎｔｅｒ３２：６４３という値（カウンタ値で６４３）の取得が可能である。
【００４５】
続いて、同様なテーブル型の例として、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０について説明する。ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３０１において、ｍｉｂ−ｔｒｅｅの配置は図３で示すように。
【００４６】
ＲＦＣによると、
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＰｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ
ＡＣＣＥＳＳ
ｎｏｔ−ａｃｃｅｓｓｉｂｌｅ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ａｔｔｒｉｂｕｔｅｓ ｏｆ ａ ｍａｒｋｅｒ ｓｕｐｐｌｙ．
Ｅｎｔｒｉｅｓ ｍａｙ ｅｘｉｓｔ ｉｎ ｔｈｅ ｔａｂｌｅ ｆｏｒ ｅａｃｈ ｄｅｖｉｃｅ ｉｎｄｅｘ ｗｈｏ’ｓ ｄｅｖｉｃｅ ｔｙｐｅ ｉｓ ｀ｐｒｉｎｔｅｒ’．”
ＩＮＤＥＸ
｛ｈｒＤｅｖｉｃｅＩｎｄｅｘ， ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＩｎｄｅｘ｝
：：＝｛ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＴａｂｌｅ １ ｝
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ ＯＢＪＥＣＴ−ＴＹＰＥ
ＳＹＮＴＡＸ
ＯＣＴＥＴ ＳＴＲＩＮＧ （ＳＩＺＥ（０．．２５５））
ＡＣＣＥＳＳ
ｒｅａｄ−ｏｎｌｙ
ＳＴＡＴＵＳ
ｃｕｒｒｅｎｔ
ＤＥＳＣＲＩＰＴＩＯＮ
”Ｔｈｅ ｄｅｓｃｒｉｐｔｉｏｎ ｏｆ ｔｈｉｓ ｓｕｐｐｌｙ ｃｏｎｔａｉｎｅｒ／ｒｅｃｅｐｔａｃｌｅ ｉｎ ｔｈｅ ｌｏｃａｌｉｚａｔｉｏｎ ｓｐｅｃｉｆｉｅｄ ｂｙ ｐｒｔＧｅｎｅｒａｌＣｕｒｒｅｎｔＬｏｃａｌｉｚａｔｉｏｎ．”
：：＝｛ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓＥｎｔｒｙ ６ ｝
である。これによって、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０の定義は、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８の６番目として定義されていることが分かる。
【００４７】
また、図３から分かるように、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８は、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｔａｂｌｅ３０７の配下に位置している。ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｔａｂｌｅ３０７は、ｐｒｔＭａｒｋｅｒＳｕｐｐｌｉｅｓ３０６の配下に位置している。
【００４８】
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｅｎｔｒｙ３０８はＩＮＤＥＸ情報としてｈｒＤｅｖｉｃｅ Ｉｎｄｅｘ， ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｉｎｄｅｘ３０９を有するテーブル型の定義となっている。管理しているネットワーク機器が複数のサブユニットデバイスに分割されて管理されている場合には、ｈｒＤｅｖｉｃｅ Ｉｎｄｅｘは何番目のサブユニットデバイスに係る情報であるかを識別するためのＩｎｄｅｘ番号である。プリンタが複数のマーカーサプライ（例：トナーなどの消耗品）を有している際、ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｉｎｄｅｘ３０９は何番目のマーカーサプライに係る情報であるかを識別するためのＩｎｄｅｘ番号である。
【００４９】
ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０のＯＩＤは（１．３．６．１．２．１．４３．１１．１．１．６）であるが、テーブル型であるため、一番目のデバイスのｎ番目のマーカーサプライのｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ３１０を示す場合にはｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．ｎ（１．３．６．１．２．１．４３．１１．１．１．６．１．ｎ）で表現される。
【００５０】
実際の取得値は、
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．１＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｂｌａｃｋ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．２＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｃｙａｎ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．３＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｍａｇｅｎｔａ Ｔｏｎｅｒ”
Ｐｒｉｎｔｅｒ−ＭＩＢ：：ｐｒｔＭａｒｋｅｒ Ｓｕｐｐｌｉｅｓ Ｄｅｓｃｒｉｐｔｉｏｎ．１．４＝ＳＴＲＩＮＧ：”Ｃａｎｏｎ Ｙｅｌｌｏｗ Ｔｏｎｅｒ”
という値（文字列）の取得が可能である。
【００５１】
このように、ＲＦＣの標準規格として定義がされているＭＩＢ情報については、ネットワークの相互運用性を確立するために独自の拡張を行うことはできない。
【００５２】
＜制御部１１０の構成＞
図４は、図１に示すＭＦＰ１００に備えられた制御部１１０の一例を示すブロック図である。
【００５３】
図４において、制御部１１０はメインコントローラ４１１を有している。そして、メインコントローラ４１１はＣＰＵ４１２およびバスコントローラ４１３を備えるとともに、各種のＩ／Ｆ（インタフェース）コントローラ回路（図示せず）を備えている。ＣＰＵ４１２およびバスコントローラ４１３は、制御部１１０全体の動作を統括的に制御する。ＣＰＵ４１２は、ＲＯＭ４１４からＲＯＭＩ／Ｆ４１５を介して読み込んだプログラムに基づいて各種の動作を実行する。例えば、ＣＰＵ４１２は、読み込んだプログラムに基づいて、図１に示すＰＣ１６１又はＰＣ１６２から受信したコードデータ（例えば、ＰＤＬ（ページ記述言語））を解釈する。バスコントローラ４１３は各Ｉ／Ｆを介してデータ転送に関する制御、例えば、バスの調停およびＤＭＡデータ転送の制御を行う。
【００５４】
ＤＲＡＭ４１６は、ＤＲＡＭＩ／Ｆ４１７を介してメインコントローラ４１１と接続され、ＣＰＵ４１２が動作するためのワーク領域および画像データを蓄積するための領域として用いられる。
【００５５】
コーディック（Ｃｏｄｅｃ）４１８は、例えば、ＤＲＡＭ４１６に蓄積されたラスタイメージデータをＭＨ／ＭＲ／ＭＭＲ／ＪＢＩＧ／ＪＰＥＧ等の方式で圧縮する。また、Ｃｏｄｅｃ４１８は圧縮された状態で蓄積されたコードデータをラスタイメージデータに伸長する処理を行う。ＳＲＡＭ４１９は、Ｃｏｄｅｃ４１８の一時的なワーク領域として用いられる。Ｃｏｄｅｃ４１８は、Ｉ／Ｆ４２０を介してメインコントローラ４１１と接続される。
【００５６】
ＳＲＡＭ４１９とＤＲＡＭ４１６との間のデータの転送は、バスコントローラ４１３によって制御され、ＤＭＡ転送よってデータ転送が行われる。
【００５７】
グラフィックプロセッサ（Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ）４３５は、ＤＲＡＭ４１６に蓄積されたラスタイメージデータに対して、画像回転、画像変倍、色空間変換、又は二値化等の処理を行う。ＳＲＡＭ４３６は、Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５の一時的なワーク領域として用いられる。Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５は、Ｉ／Ｆ４３７を介してメインコントローラ４１１と接続されている。Ｇｒａｐｈｉｃ Ｐｒｏｃｅｓｓｏｒ４３５とＤＲＡＭ４１６との間のデータの転送は、バスコントローラ４１３によって制御され、ＤＭＡ転送によってデータ転送が行われる。
【００５８】
ネットワークコントローラ（ Ｎｅｔｗｏｒｋ Ｃｏｎｔｏｒｌｌｅｒ）４２１は、Ｉ／Ｆ４２３によってメインコントローラ４１１と接続され、コネクタ４２２を介して外部ネットワーク（例えば、ＬＡＮ１６０）と接続される。
【００５９】
汎用高速バス４２５には、拡張ボードを接続するための拡張コネクタ４２４とＩ／Ｏ制御部４２６とが接続される。汎用高速バス４２５は、例えば、ＰＣＩバスである。Ｉ／Ｏ制御部４２６は、リーダ部１２０およびプリンタ部１３０の各ＣＰＵ（つまり、スキャナコントローラ１２３およびプリンタコントローラ１３５）との間で制御コマンドを送受信するための調歩同期式のシリアル通信部コントローラ４２７を２チャンネル備えている。
【００６０】
Ｉ／Ｏ制御部４２６は、Ｉ／Ｏバス４２８を介してスキャナＩ／Ｆ４４０およびプリンタＩ／Ｆ４４５と接続されている。パネルＩ／Ｆ４３２は、操作部１４０との間でデータの送受信を行うためのＩ／Ｆである。パネルＩ／Ｆ４３２は、ＬＣＤコントローラ４３１から転送されてきた画像データを操作部１４０に転送する。また、パネルＩ／Ｆ４３２は、操作部１４０が備えるハードキー又はタッチパネルを介して入力されるキー入力信号を、キー入力Ｉ／Ｆ４３０を介してＩ／Ｏ制御部４２６に転送する。
【００６１】
リアルタイムクロックモジュール４３３は、バックアップ用電池４３４によって電力を供給され、ＭＦＰ１００で管理する日付及び時刻を更新／保存する。Ｅ−ＩＤＥ Ｉ／Ｆ４６１は、ＨＤＤ１５０を接続するＩ／Ｆである。ＣＰＵ４１２は、Ｅ−ＩＤＥ Ｉ／Ｆ４６１を介してＨＤＤ１５０に画像データを記憶させ、又はＨＤＤ１５０から画像データを読み込む。
【００６２】
コネクタ４４２および４４７には、それぞれリーダ部１２０およびプリンタ部１３０が接続される。コネクタ４４２および４４７は、同調歩同期シリアルＩ／Ｆ４４３および４４８とビデオＩ／Ｆ４４４および４４９を介してスキャナＩ／Ｆ４４０およびプリンタＩ／Ｆ４４５に接続されている。
【００６３】
スキャナＩ／Ｆ４４０は、コネクタ４４２を介してリーダ部１２０と接続され、スキャナバス４４１を介してメインコントローラ４１１と接続されている。スキャナＩ／Ｆ４４０は、リーダ部１２０から受信した画像データに対して所定の処理を施す。また、スキャナＩ／Ｆ４４０は、リーダ部１２０から受信したビデオ制御信号に基づいて生成した制御信号を、スキャナバス４４１に出力する。スキャナバス４４１からＤＲＡＭ４１６へのデータ転送は、バスコントローラ４１３によって制御される。
【００６４】
プリンタＩ／Ｆ４４５は、コネクタ４４７を介してプリンタ部１３０と接続され、プリンタバス４４６を介してメインコントローラ４１１と接続されている。プリンタＩ／Ｆ４４５は、メインコントローラ４１１から出力された画像データに所定の処理を施して、プリンタ部１３０へ出力する。ＤＲＡＭ４１６上に展開されたラスタイメージデータをプリンタ部１３０に転送する際には、バスコントローラ４１３による制御が行われる。当該ラスタイメージデータはプリンタバス４４６、プリンタＩ／Ｆ４４５、およびビデオＩ／Ｆ４４９を介してプリンタ部１３０にＤＭＡ転送される。
【００６５】
ＳＲＡＭ４５１は、バックアップ用の電池から供給される電力によって、ＭＦＰ１００の電源が遮断された状態でも記憶内容を保持し続けることが可能なメモリである。ＳＲＡＭ４５１は、バス４５０を介してＩ／Ｏ制御部４２６と接続されている。また、ＥＥＰＲＯＭ４５２も同様に、バス４５０を介してＩ／Ｏ制御部４２６と接続されたメモリである。
【００６６】
図５は、図１に示すＭＦＰ１００においてパケットデータ（ＳＮＭＰパケット）を受信した際の返信処理の一例を説明するためのフローチャートである。また、図６は図１に示すＭＦＰ１００に予め記録されたレスポンステーブルの一例を示す図である。なお、例えば、ＣＰＵ４１２はＲＯＭ４１４に格納されたプログラムを読み出して図５に示すフローチャートの各ステップを実行する。
【００６７】
ＭＦＰ１００は図６に示すレスポンステーブルを有している。そして、ＣＰＵ４１２は後述するようにしてこのレスポンステーブルを参照して、受信パケットデータに対する返信を行う。図示のように、レスポンステーブルは複数の返信値と当該返信値に対する優先度（優先順位ともいう）が規定されている。さらに、レスポンステーブルには返信値に対応する返信識別名が規定されている。そして、後述するように、ＣＰＵ４１２は返信識別名を用いてＮｅｔｗｏｒｋ Ｃｏｎｔｏｒｌｌｅｒ４２１を制御して、ＳＮＭＰパケットとしてＬＡＮ１６０に送出する。
【００６８】
なお、レスポンステーブルに規定された優先度はユーザが操作部１４０を用いて変更することができる。
【００６９】
いま、ＳＮＭＰパケットの送信・受信処理が開始されると、ＣＰＵ４１２は、例えば、ＰＣ１６１から送信されたＳＮＭＰパケット（機器情報取得要求）を受信する（ステップＳ６０２）。ステップＳ６０２では、ＰＣ１６１はＭＦＰ１００からその機器情報を取得するためにＳＮＭＰパケットを送出したものとする。つまり、ここでは、ＳＮＭＰパケットはリクエスト・パケットである。このリクエスト・パケットは単一のパケットデータに２つのアイテム（ｉｔｅｍ）が含まれており、ｓｙｓＤｅｓｃｒ情報を複数取得する際に用いられる。
【００７０】
続いて、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤ（オブジェクト識別子）が互いに一致するか否かを判定する（ステップＳ６０３）。
【００７１】
いま、ステップＳ６０２において、符号６００１で示すように、複数のＯＩＤが互いに一致するＳＮＭＰパケットを受信したとすると、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤが互いに一致すると判定することになる。複数のＯＩＤが互いに一致すると判定すると（ステップＳ６０３において、ＹＥＳ）、ＣＰＵ４１２は、予め設定された返信条件に基づいて同一のＯＩＤ（オブジェクト識別子）に対して互いに異なる返信値を選択（採用）するか否かについて判定する（ステップＳ６０４）。なお、上記の返信条件は、ユーザによって予め操作部１４０から設定されているものとする。
【００７２】
いま、互いに異なる返信値を採用しないと判定すると（ステップＳ６０４において、ＮＯ）、ＣＰＵ４１２は図６に示すレスポンステーブルを参照して、優先度が最も高い返信値（つまり、最高順位の返信値）に係る返信識別名を採用して、ＳＮＭＰパケットによって返信処理を行う（ステップＳ６０５）。そして、ＣＰＵ４１２は処理を終了する。
【００７３】
一方、互いに異なる返信値を採用すると判定すると（ステップＳ６０４において、ＹＥＳ）、ＣＰＵ４１２はレスポンステーブルを参照して、優先度の高い順で返信値の並び替えを行う。そして、ＣＰＵ４１２は同一のＯＩＤの並び順と返信値の並び順とに応じて返信値とＯＩＤとを突き合わせて送信バッファに返信識別名を格納する（ステップＳ６０７）。続いて、ＣＰＵ４１２は送信バッファに格納された送信識別名（値）の順でＳＮＭＰパケットによる返信を行って（ステップＳ６０８）、処理を終了する。
【００７４】
ステップＳ６０２において、符号６００２で示すように、リクエスト・パケットとして単一のパケットデータに２つのアイテムが含まれ、ｓｙｓＤｅｓｃｒ情報およびｉｆＮｕｍｂｅｒ情報とを取得するためのパケットを受信したとする。このように、複数のＯＩＤが互いに一致しないＳＮＭＰパケットを受信したとすると、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤが互いに一致しないと判定することになる。
【００７５】
複数のＯＩＤが互いに一致しないと判定すると（ステップＳ６０３において、ＮＯ）、ＣＰＵ４１２は各ＯＩＤについての個別の返信値を採用して、返信識別名を用いてＳＮＭＰパケットによって返信を行う（ステップＳ６１０）。そして、ＣＰＵ４１２は処理を終了する。そして、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００から返信されたレスポンス（ＳＮＭＰパケット）に含まれる返信識別名に応じて処理の切替を行うことになる。
【００７６】
このように、第１の実施形態では、管理端末であるＰＣ１６１又はＰＣ１６２が予めネットワーク機器であるＭＦＰ１００を見分ける必要がなく、リクエスト・パケットに対するＭＦＰ１００からのレスポンスを受けて、当該レスポンスにＭＦＰ１００を識別可能な情報が含まれているか否かによって処理の切り替えを行うことができる。つまり、情報処理装置で使用するソフトウェアが異なってもＭＦＰ１００の管理を容易に行うことができる。
【００７７】
なお、単一のパケットに情報識別子（ＯＩＤ）が複数指定されていない場合には、返信値（返信識別名）については従来と同様にしてＳＮＭＰパケットの返信が行われる結果、既存のネットワークシステムに導入した場合においても悪影響を及ぼすことはない。
【００７８】
［第２の実施形態］
続いて、本発明の第２の実施形態によるＭＦＰ１００の一例について説明する。ここでは、単一のＳＮＭＰパケットに情報識別子（ＯＩＤ）が複数指定されている際に、予め設定された返信値（返信識別名）を用いることなく、返信値に関する履歴情報を記憶して、前回のレスポンスの返信が行われた際に返信した返信値又はＭＦＰ１００において所定の時間毎に更新した返信値を用いる。なお、ネットワークシステムの構成およびＭＦＰ１００の構成は図１および図４と同様であるので説明を省略する。
【００７９】
図７は、本発明の第２の実施形態によるＭＦＰ１００の処理を説明するためのフローチャートである。ＣＰＵ４１２はＲＯＭ４１４に格納されたプログラムを読み出して図７に示すフローチャートの各ステップを実行する。
【００８０】
図１、図４、および図７を参照して、ＳＮＭＰパケットの送信・受信処理が開始されると、ＣＰＵ４１２は、例えば、ＰＣ１６１から送信されたＳＮＭＰパケットを受信する（ステップＳ７０２）。ステップＳ７０２では、ＰＣ１６１はＭＦＰ１００からその機器情報を取得するためにＳＮＭＰパケットを送出したものとする。つまり、ここでは、ＳＮＭＰパケットはリクエスト・パケットである。このリクエスト・パケットは単一のパケットデータに２つのアイテム（ｉｔｅｍ）が含まれており、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１情報を複数取得する際に用いられる。
【００８１】
続いて、ＣＰＵ４１２はＳＮＭＰパケットに含まれる複数のＯＩＤ（オブジェクト識別子）が互いに一致するか否かに判定する（ステップＳ７０３）。複数のＯＩＤが互いに一致すると判定すると（ステップＳ７０３において、ＹＥＳ）、ＣＰＵ４１２は、予め設定された返信条件に基づいて同一のＯＩＤ（識別子）に対して互いに異なる返信値を採用するか否かについて判定する（ステップＳ７０４）。上記の返信条件は、前述のようにユーザによって予め操作部１４０から設定されている。
【００８２】
互いに異なる返信値を選択（採用）しないと判定すると（ステップＳ７０４において、ＮＯ）、ＣＰＵ４１２は、現在のｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１の返信値（図示の例では”５７”）を各ＯＩＤの返信値として採用する。そして、当該返信値をＳＮＭＰパケットによってＰＣ１６１に返信して（ステップＳ７０５）、処理を終了する。
【００８３】
一方、互いに異なる返信値を採用すると判定すると（ステップＳ７０４において、ＹＥＳ）、ＣＰＵ４１２はレスポンステーブル（返信値テーブル）を更新する（ステップＳ７０７）。
【００８４】
図８は本発明の第２の実施形態による返信値テーブルの更新の一例を説明するための図である。
【００８５】
図８において、返信値テーブルは複数のバッファに関連付けられており、ここでは、バッファ”１”〜”３”に関連付けられている。そして、バッファ”１”〜”３”に格納された情報がそれぞれ第１〜第３の返信値とされる。ここでは、バッファ”１”は第１のバッファであり、バッファ”２”および”３”はそれぞれ付加バッファである。
【００８６】
再び、図１、図４、および図７を参照して、ＣＰＵ４１２は返信値テーブルを更新する際には、前回第１の返信値として用いた返信値を第２の返信値として用いるために、バッファ”１”に格納された第１の返信値を第２の返信値としてバッファ”２”に格納する。さらに、ＣＰＵ４１２は前回第２の返信値として用いた返信値を第３の返信値として用いるために、バッファ”２”に格納された第２の返信値を第３の返信値としてバッファ”３”に格納する。
【００８７】
図８に示す例では、前回の返信際に用いた第１〜第３の返信値はそれぞれ１回目８０２で示す返信値となる。そして、ＣＰＵ４１２は今回の返信の際に、バッファ”２”の返信値をバッファ”３”にコピーし、バッファ”１”の返信値をバッファ”２”にコピーする。つまり、ＣＰＵ４１２はバッファ”１”〜”３”に格納された返信値を順次シフトする処理を行う。
【００８８】
続いて、ＣＰＵ４１２は現在のｐｒｔＭａｒｋｅｒＬｉｆｅＣｏｕｎｔ．１．１の返信値（図７に示す例では”５７”）を、図８に示す２回目８０３の返信値（つまり、第１の返信値）としてバッファ”１”に格納する。２回目以降におけるバッファ”１”〜”３”の更新について、同様にして、ＣＰＵ４１２は処理する結果、例えば、図８に示す３回目８０４に示すようになる。つまり、ＣＰＵ４１２は現在の印刷カウント値（ここでは、”１２３”）をプリンタ部１３０から取得して第１の返信値としてバッファ”１”に格納する（ステップＳ７０８）。つまり、ＣＰＵ４１２は最新の印刷カウント値を機器情報として第１のバッファに格納することになる。
【００８９】
このようにして、返信値テーブルの更新（つまり、バッファ更新）を完了した後、ＣＰＵ４１２はバッファ”１”および”２”に格納された返信値に応じてＳＮＭＰパケットを生成して、当該ＳＮＭＰパケット（つまり、レスポンス）をＰＣ１６１に返信する（ステップＳ７０９）。そして、ＣＰＵ４１２は処理を終了する。
【００９０】
つまり、ＣＰＵ４１２はバッファ”１”に格納された返信値をＯＩＤの１つに対応づけ、バッファ”２”に格納された返信値をＯＩＤの残りに順次対応づけてＳＮＭＰパケット（このＳＮＭＰパケットはレスポンスである）を生成することになる。
【００９１】
ステップＳ７０３において、複数のＯＩＤが互いに一致しないと判定すると（ステップＳ７０３において、ＮＯ）、ＣＰＵ４１２は各ＯＩＤについての個別の返信値を用いてＳＮＭＰパケットよって返信を行う（ステップＳ７１０）。そして、ＣＰＵ４１２は処理を終了する。そして、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００から返信されたレスポンス（ＳＮＭＰパケット）に含まれる返信値に応じて処理の切替を行うことになる。
【００９２】
図９は、本発明の第２の実施形態による返信値テーブルの更新の他の例を説明するための図である。
【００９３】
図９において、ＣＰＵ４１２はバッファ”１”に格納する返信値を、ＭＦＰ１００（例えば、プリンタ部）の現在の印刷カウント値を格納する。そして、ＣＰＵ４１２は予め定められた時間間隔でバッファ”２”以降に格納された返信値を、図８で説明したようにして更新する。図９に示す例では、ｐｒｔＭａｒｋｅｒ Ｌｉｆｅ Ｃｏｕｎｔ．１．１に関する返信値について、１回目９０２の返信値と２回目９０３の返信値が示されている。ここでは、バッファ”１”には現在の印刷カウント値が格納され、バッファ”２”以降においては１時間の時間間隔で返信値が更新されている。
【００９４】
なお、この時間間隔はユーザが操作部１４０を用いて設定するようにしてもよい。
【００９５】
このように、第２の実施形態では、管理端末であるＰＣ１６１又は１６２はＭＦＰ１００における現在の印刷カウント値に加えて、その前（過去）の印刷カウント値を履歴情報データとしても参照することができる。このため、所定の時間間隔でＭＦＰ１００の状態を確認することができるばかりでなく、さらには印刷枚数の差分（つまり、所定の時間毎の印刷枚数）を容易に確認することができる。
【００９６】
上述の説明から明らかなように、図１において、制御部１１０は判定手段、決定手段、および返信手段の一例である。また、制御部１１０および操作部１４０は設定手段の一例である。
【００９７】
以上、本発明について実施の形態に基づいて説明したが、本発明は、これらの実施の形態に限定されるものではなく、この発明の要旨を逸脱しない範囲の様々な形態も本発明に含まれる。
【００９８】
例えば、上記の実施の形態の機能を制御方法として、この制御方法を、ネットワーク機器であるＭＦＰ１００に実行させるようにすればよい。また、上記の実施の形態の各機能を、ネットワーク機器単体で実行するのではなく、ネットワーク上の複数の装置で分散して実行するようにしてもよい。即ち、図５や図７に示すフローチャートの一部のステップを、ＭＦＰ１００ではないネットワーク上の外部装置に実行させるようにしてもよい。また、上述の実施の形態の機能を有するプログラムを制御プログラムとして、この制御プログラムをネットワーク機器であるＭＦＰ１００が備えるコンピュータに実行させるようにしてもよい。なお、制御プログラムは、例えば、コンピュータに読み取り可能な記録媒体に記録される。
【００９９】
この際、制御方法および制御プログラムは、少なくとも判定ステップ、設定ステップ、決定ステップ、および返信ステップを有することになる。
【０１００】
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記録媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１０１】
１００ 画像形成装置（ＭＦＰ）
１１０ 制御部（コントローラ部）
１２０ リーダ部
１３０ プリンタ部
１３１ 給紙ユニット
１３２ マーキングユニット
１３４ 排紙ユニット
１４０ 操作部
１６０ ネットワーク（ＬＡＮ）
１６１，１６２ 管理端末（ＰＣ）
【特許請求の範囲】
【請求項１】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器であって、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定手段と、
前記判定手段によって複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定手段と、
前記決定手段による決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信手段とを有することを特徴とするネットワーク機器。
【請求項２】
複数の機器情報について優先順位を規定するレスポンステーブルを有し、
前記決定手段は前記レスポンステーブルで規定された優先順位に応じて前記オブジェクト識別子を選択することを特徴とする請求項１に記載のネットワーク機器。
【請求項３】
前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを規定する返信条件を設定する設定手段を更に有し、
前記返信条件が同一のオブジェクト識別子の各々に同一の機器情報を対応づけることを示していると、前記決定手段は前記レスポンステーブルで規定された最高順位の機器情報を選択することを特徴とする請求項２に記載のネットワーク機器。
【請求項４】
前記返信条件が同一のオブジェクト識別子の各々に互いに異なる機器情報を対応づけることを示していると、前記決定手段は前記レスポンステーブルで規定された優先順位の順で機器情報を選択することを特徴とする請求項３に記載のネットワーク機器。
【請求項５】
前記ネットワーク機器の現在の機器情報を格納する第１のバッファと、
前記現在の機器情報よりも過去の機器情報が前回の機器情報として格納される少なくとも１つの付加バッファとを有し、
前記返信条件が同一のオブジェクト識別子の各々に互いに異なる機器情報を対応づけることを示していると、前記決定手段は前記第１のバッファに格納された機器情報を前記付加バッファに順次シフトするとともに、前記第１のバッファに最新の機器情報を格納してバッファ更新を行った後、前記第１のバッファに格納された機器情報を前記オブジェクト識別子の１つに対応づけ、前記付加バッファに格納された機器情報を前記オブジェクト識別子の残りに順次対応づけることを特徴とする請求項３に記載のネットワーク機器。
【請求項６】
前記決定手段は予め規定された時間間隔で前記バッファの更新を行うことを特徴とする請求項５に記載のネットワーク機器。
【請求項７】
前記ネットワーク機器は、画像データに応じて画像形成を行う画像形成装置であることを特徴とする請求項１乃至６のいずれか１項に記載のネットワーク機器。
【請求項８】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器の制御方法であって、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、
前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、
前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを有することを特徴とする制御方法。
【請求項９】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器で用いられる制御プログラムであって、
前記ネットワーク機器が備えるコンピュータに、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、
前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、
前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを実行させることを特徴とする制御プログラム。
【請求項１】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器であって、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定手段と、
前記判定手段によって複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定手段と、
前記決定手段による決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信手段とを有することを特徴とするネットワーク機器。
【請求項２】
複数の機器情報について優先順位を規定するレスポンステーブルを有し、
前記決定手段は前記レスポンステーブルで規定された優先順位に応じて前記オブジェクト識別子を選択することを特徴とする請求項１に記載のネットワーク機器。
【請求項３】
前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを規定する返信条件を設定する設定手段を更に有し、
前記返信条件が同一のオブジェクト識別子の各々に同一の機器情報を対応づけることを示していると、前記決定手段は前記レスポンステーブルで規定された最高順位の機器情報を選択することを特徴とする請求項２に記載のネットワーク機器。
【請求項４】
前記返信条件が同一のオブジェクト識別子の各々に互いに異なる機器情報を対応づけることを示していると、前記決定手段は前記レスポンステーブルで規定された優先順位の順で機器情報を選択することを特徴とする請求項３に記載のネットワーク機器。
【請求項５】
前記ネットワーク機器の現在の機器情報を格納する第１のバッファと、
前記現在の機器情報よりも過去の機器情報が前回の機器情報として格納される少なくとも１つの付加バッファとを有し、
前記返信条件が同一のオブジェクト識別子の各々に互いに異なる機器情報を対応づけることを示していると、前記決定手段は前記第１のバッファに格納された機器情報を前記付加バッファに順次シフトするとともに、前記第１のバッファに最新の機器情報を格納してバッファ更新を行った後、前記第１のバッファに格納された機器情報を前記オブジェクト識別子の１つに対応づけ、前記付加バッファに格納された機器情報を前記オブジェクト識別子の残りに順次対応づけることを特徴とする請求項３に記載のネットワーク機器。
【請求項６】
前記決定手段は予め規定された時間間隔で前記バッファの更新を行うことを特徴とする請求項５に記載のネットワーク機器。
【請求項７】
前記ネットワーク機器は、画像データに応じて画像形成を行う画像形成装置であることを特徴とする請求項１乃至６のいずれか１項に記載のネットワーク機器。
【請求項８】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器の制御方法であって、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、
前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、
前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを有することを特徴とする制御方法。
【請求項９】
ネットワークを介して管理端末に接続可能で、当該管理端末からの機器情報取得要求に応じて機器情報を含むレスポンスを返信するネットワーク機器で用いられる制御プログラムであって、
前記ネットワーク機器が備えるコンピュータに、
前記機器情報取得要求を前記管理端末から受信すると、当該機器情報取得要求に複数の同一のオブジェクト識別子が含まれているか否かを判定する判定ステップと、
前記判定ステップで複数の同一のオブジェクト識別子が含まれていると判定されると、前記同一のオブジェクト識別子の各々に対応づけて異なる機器情報を返信するか否かを決定する決定ステップと、
前記決定ステップによる決定に応じて前記機器情報を含むレスポンスを前記管理端末に返信する返信ステップとを実行させることを特徴とする制御プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１３−３００８０（Ｐ２０１３−３００８０Ａ）
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願番号】特願２０１１−１６７０４０（Ｐ２０１１−１６７０４０）
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２５年２月７日（２０１３．２．７）
【国際特許分類】
【出願日】平成２３年７月２９日（２０１１．７．２９）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]