(57)【要約】【課題】  サブネット毎に探索サービスモジュールを用意する必要があるため、ネットワークの構成と、探索サービスのネットワーク上の配置を管理する必要が発生する。【解決手段】  ネットワークに他のサーバが存在するか否かを識別し（Ｓ１０３）、他のサーバが存在する場合、他のサーバが管理対象としているエージェント情報を取得し（Ｓ１０４）、管理対象としているエージェント情報と、取得したエージェント情報とに基づいて、管理対象としているエージェントを他のサーバが管理対象としているかを判定し（Ｓ１０６）、他のサーバが管理していない場合に、管理対象としているエージェント情報を管理対象リストに登録する（Ｓ１０９）。【選択図】  図６
2008140048.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク上のデバイスを探索する管理装置であって、
ネットワークに他の管理装置が存在するか否かを識別する識別手段と、
前記識別手段により他の管理装置が存在すると識別されると、当該他の管理装置によって探索されたデバイスの情報を、当該他の管理装置から取得する取得手段と、
前記ネットワーク上のデバイスを探索する探索手段と、
前記探索手段によって探索されたデバイスの情報と、前記取得手段により取得した情報とに基づいて、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されているか否かを判定する判定手段と、
前記判定手段により、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されていると判定されなかった場合、当該デバイスの情報のうち、前記探索手段によって取得していない情報を、当該デバイスから取得する第二の取得手段と、
を有することを特徴とする管理装置。
【請求項２】
前記探索手段は、探索されたデバイスから、ＩＰアドレス、ＵＵＩＤ、デバイスのシリアル番号、ＭＡＣアドレスの少なくともいずれかを含む、情報を取得することを特徴とする請求項１に記載の管理装置。
【請求項３】
前記識別手段により他の管理装置が存在すると識別された場合、前記第二の取得手段で取得した情報を、当該他の管理装置に通知する通知手段を更に有することを特徴とする請求項１又は２に記載の管理装置。
【請求項４】
前記第二の取得手段によって取得された情報に、前記デバイスのステータスを示す情報が含まれている場合、当該ステータスを示す情報を再取得する手段を更に有することを特徴とする請求項１乃至３の何れか１項に記載の管理装置。
【請求項５】
前記第二の取得手段によって情報を取得する前に、前記第二の取得手段による情報の取得の対象となるデバイスを前記他の管理装置に対して通知することにより、当該他の管理装置による当該デバイスの情報の取得を禁止する予約手段を更に有することを特徴とする請求項１乃至４のいずれか１項に記載の管理装置。
【請求項６】
前記予約手段の有効期間は、予め定められていることを特徴とする請求項５に記載の管理装置。
【請求項７】
ネットワーク上のデバイスを探索する管理装置の管理方法であって、
ネットワークに他の管理装置が存在するか否かを識別する識別工程と、
前記識別工程で他の管理装置が存在すると識別されると、当該他の管理装置によって探索されたデバイスの情報を、当該他の管理装置から取得する取得工程と、
前記ネットワーク上のデバイスを探索する探索工程と、
前記探索工程で探索されたデバイスの情報と、前記取得工程で取得した情報とに基づいて、前記探索工程で探索されたデバイスが前記他の管理装置によって探索されているか否かを判定する判定工程と、
前記判定工程で、前記探索工程で探索されたデバイスが前記他の管理装置によって探索されていると判定されなかった場合、当該デバイスの情報のうち、前記探索工程で取得していない情報を当該デバイスから取得する第二の取得工程と、
を有することを特徴とする管理方法。
【請求項８】
前記探索工程は、探索されたデバイスから、ＩＰアドレス、ＵＵＩＤ、デバイスのシリアル番号、ＭＡＣアドレスの少なくともいずれかを含む情報を取得することを特徴とする請求項７に記載の管理方法。
【請求項９】
前記識別工程で他の管理装置が存在すると識別された場合、前記第二の取得工程で取得した情報を、当該他の管理装置に通知する通知工程を更に有することを特徴とする請求項７又は８に記載の管理方法。
【請求項１０】
前記第二の取得工程で取得された情報に、前記デバイスのステータスを示す情報が含まれている場合、当該ステータスを示す情報を再取得する工程を更に有することを特徴とする請求項７乃至９の何れか１項に記載の管理方法。
【請求項１１】
前記第二の取得工程で情報を取得する前に、前記第二の取得工程での情報の取得の対象となるデバイスを前記他の管理装置に対して通知することにより、当該他の管理装置による当該デバイスの情報の取得を禁止する予約工程を更に有することを特徴とする請求項７乃至１０のいずれか１項に記載の管理方法。
【請求項１２】
前記予約工程の有効期間は、予め定められていることを特徴とする請求項１１に記載の管理方法。
【請求項１３】
ネットワーク上のデバイスを探索する管理方法をコンピュータに実行させるために、該コンピュータを、
ネットワークに他の管理装置が存在するか否かを識別する識別手段と、
前記識別手段により他の管理装置が存在すると識別されると、当該他の管理装置によって探索されたデバイスの情報を、当該他の管理装置から取得する取得手段と、
前記ネットワーク上のデバイスを探索する探索手段と、
前記探索手段によって探索されたデバイスの情報と、前記取得手段により取得した情報とに基づいて、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されているか否かを判定する判定手段と、
前記判定手段により、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されていると判定されなかった場合、当該デバイスの情報のうち、前記探索手段によって取得していない情報を、当該デバイスから取得する第二の取得手段と、
を有する管理装置として機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の分散管理エージェントを用いたネットワークデバイスの管理処理技術に関するものである。
【背景技術】
【０００２】
従来、ネットワークデバイス（コンピュータネットワークに接続される機器）を管理する方法として、ＳＮＭＰ／ＭＩＢ(Simple Network Management Protocol／Management Information Base)を使用する方法がある（非特許文献１参照）。
【０００３】
このＳＮＭＰネットワーク管理技術によれば、ネットワーク管理システムには、少なくとも１つのネットワーク管理ステーション（ＮＭＳ）、各々がエージェントを含むいくつかの管理対象ノード、及び管理ステーションやエージェントが管理情報を交換するために使用するネットワーク管理プロトコルが含まれる。ユーザは、このＮＭＳ上でネットワーク管理ソフトウエアを用いて管理対象ノード上のエージェントソフトウェアと通信することにより、ネットワーク上のデータを得たり、またデータを変更することができる。
【０００４】
このようなネットワーク管理ソフトウエアを分散環境で使用する場合、ネットワーク管理機能を持つサーバアプリケーションと、端末で起動されるＧＵＩ部分であるクライアントアプリケーションによる構成をとることが一般的である。
【０００５】
このような分散環境における異なる端末間で、クライアントアプリケーションとサーバアプリケーションはプロセス間通信を行う。このプロセス間通信の標準としてＲＦＣ１０５７ ＲＰＣ(Remote Procedure Call)が定義されている。このＲＰＣとは、ネットワークサービスを提供する関数群をサーバ側で用意し、この関数群の中の関数をローカルマシン内の関数と同様に、ネットワーク上の別端末のクライアントプロセスから呼び出せるようにしたものである。
【０００６】
このＲＰＣにおけるプロセス間通信の流れは以下のようになる。クライアントは、サーバに対するサービス要求として、サーバに用意されているＲＰＣ関数を呼び出す。この時点で、関数の呼び出し情報を格納したデータパケットがサーバに送られ、クライアントのプログラム（プロセス）は中断される。サーバが、そのパケットを受け取ると、呼び出された関数をディスパッチし、関数の引数を取り出した後、その引数を基にサービスを実行して、その結果をクライアントに返す。クライアントは関数の結果を受け取った後で、プログラムの実行（プロセス）を再開する。
【０００７】
上述のネットワーク管理機能を持つサーバアプリケーションは、分散ネットワーク上に１つ配置し、そのサーバアプリケーション内で複数のインスタンスを持つことにより複数のデバイスを管理している。一方、クライアントアプリケーションは、異なる端末で複数動作し、上述のプロセス間通信を用いてサーバアプリケーションにアクセスする。そして、サーバアプリケーションを介して、デバイス情報の取得、設定を行う。
【０００８】
またサーバアプリケーションはネットワーク管理機能として、ネットワークデバイスを探索するデバイス探索機能もクライアントに提供する。これによりクライアントは、サーバアプリケーションが探索したデバイスリストから、管理したいデバイスのアドレス及びデバイス名等のデバイス基本情報を取得することが可能である。
【０００９】
図１は、ネットワーク管理の対象となりうるコンピュータネットワークの構成例を示す図である。
【００１０】
図１に示すコンピュータネットワークでは、３つのＬＡＮ１００，１１０及び１２０がルータ１３０，１４０よって相互に接続されている。そして、ＬＡＮ１００，１１０及び１２０の各々にはクライアントとしてのコンピュータ装置１０３、管理対象ノードとしてのネットワークプリンタ１２２、ネットワーク管理ステーション（サーバ）としての通信装置１０４，１２１等が接続されている。
【００１１】
図２は、図１におけるＬＡＮ１００及び１２０について、ＬＡＮ１００に接続されたＰＣ１０３がクライアントとして動作し、ＬＡＮ１２０に接続された通信装置１２１がサーバ装置として動作するとした場合を説明する概略図である。尚、図２において「デバイス」は、ＬＡＮに接続されたネットワークデバイスであり、ネットワークプリンタやコンピュータ装置等を意味する。
【００１２】
図２において、ＰＣ１０３上でクライアントアプリケーションのプロセスＡが、通信装置１２１上のサーバアプリケーションのプロセスＢにアクセスしデバイスの探索を指示する。この場合、クライアントアプリケーション（プロセスＡ）は、プロセス間通信の機能を使用してサーバアプリケーション（プロセスＢ）と通信を行う。ここではサーバアプリケーションは、ＳＮＭＰプロトコルのブロードキャストを使用してデバイス探索を行う。
【００１３】
ここでデバイス探索は、２段階のステップで行われる。初めのステップは、ブロードキャストにより、各デバイスのアドレス情報を取得する。次のステップは、ブロードキャストで見つかった各デバイスに対して、デバイス名、ロケーション等のデバイス基本情報のＭＩＢ値を取得する。
【００１４】
デバイス探索を行うために、各クライアントアプリケーションはプロキシを用いてプロセス間通信を行い、サーバアプリケーションにデバイス探索を依頼する。サーバアプリケーションはプロキシ（スタブ）から送信された情報を受け取り、ＳＮＭＰプロトコル等のブロードキャストを用いてデバイス探索を行う。デフォルト設定では、サーバアプリケーションが存在しているサブネットワークに存在するデバイスのみ探索を行う。ここで、サブネットワークとは、ネットワーク上のルータで区切られたネットワークの領域を意味する。図１の例では、ネットワーク１００、１１０、１２０のそれぞれがサブネットワークである。クライアントアプリケーションからサブネットを超えた探索範囲が指定された場合、例えば図２のＬＡＮ１２０のデバイス探索を行うことが指定された場合、サブネットブロードキャストを行ってデバイスを探索する。
【００１５】
また、ＳＬＰ（Service Location Protocol）やWeb Services Dynamic Discovery（非特許文献２参照）プロトコルは、一般的にマルチキャストプロトコルを利用することにより、ルータを越えてデバイスを探索できる。こうして探索された結果から得られるデバイスリスト情報は、サーバアプリケーションのスタブからプロセス間通信を使用してプロキシに送信され、プロキシからクライアントアプリケーションにコールバック通知される。クライアントアプリケーションは、サーバアプリケーションからコールバック通知された情報を基にビットマップ表示等を行ってデバイスリスト情報を表示する。
【００１６】
このようなシステムでは、デバイス探索サービスは、ルータ等のネットワーク機器の制限により、サブネットブロードキャスト探索が使えない場合があった。またデバイスの仕様によりマルチキャスト探索が使えないなどの理由により、探索サービスモジュールをサブネット毎に分散して配置するものであった（特許文献１参照）。
【特許文献１】特開２００３−９９３４１
【非特許文献１】ＳＮＭＰ／ＭＩＢの詳細に関しては「ＴＣＰ／ＩＰ  ネットワーク管理入門  実用的な管理をめざして」Ｍ．Ｔ．ローズ＝著／西田竹志＝訳  （株）トッパン発行  １９９２年８月２０日初版
【非特許文献２】Web Services Dynamic Discovery (WS-Discovery)仕様書  October 2004  http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-discovery１004.pdf
【発明の開示】
【発明が解決しようとする課題】
【００１７】
上記従来例では、サブネット毎に探索サービスモジュールを用意する必要がある。このために、ネットワークの構成（サブネット構成）と、探索サービスのネットワーク上の配置を管理する必要が発生する。
【００１８】
更に別の問題点として、同一サブネット上に、複数のサーバを配置した場合、それらの複数のサーバに探索指示を出すと、そのネットワーク上でブロードキャストパケット等が多数発生し、トラフィックが増加する。一方、トラフィックを増加させないように、特定のサーバのみがサブネット内を代表して探索する場合は、探索の完了までに多くの時間がかかってしまうため、分散による探索時間の高速化が期待できない。また探索ブローカに探索数の上限がある場合は、特定ノードに多数のデバイスが存在する大規模なネットワークをサポートできない。更に、１台のサーバでは、複数稼動している場合と比較して、探索結果の取りこぼしが発生する可能性が高くなるなどの課題がある。
【００１９】
また、ホップ数の離れたＬＡＮ上のデバイス探索にマルチキャストパケットを使う場合、デバイスの仕様により、マルチキャストパケットが使えない場合があった。そのためクライアントは、管理対象サブネットのアドレスなどのＬＡＮ情報を事前に知っておく必要があり、効率的にエージェントを管理できるネットワーク管理システムが構築できない等の問題があった。
【００２０】
本発明の目的は、このような従来技術の問題点を解決することにある。
【００２１】
本願発明の特徴は、広範囲なデバイス探索が要求されても、効率的にデバイスを管理するネットワークデバイスの分散管理システム及び分散管理装置及び方法を提供することにある。
【００２２】
また、ネットワークデバイス探索サービスの管理が容易で、ネットワークのトラヒックの増大を防止したネットワークデバイスの管理装置及びその方法とそのプログラムを提供することにある。
【課題を解決するための手段】
【００２３】
上記目的を達成するために本発明の一態様に係る分散管理装置は以下のような構成を備える。即ち、
ネットワーク上のデバイスを探索する管理装置であって、
ネットワークに他の管理装置が存在するか否かを識別する識別手段と、
前記識別手段により他の管理装置が存在すると識別されると、当該他の管理装置によって探索されたデバイスの情報を、当該他の管理装置から取得する取得手段と、
前記ネットワーク上のデバイスを探索する探索手段と、
前記探索手段によって探索されたデバイスの情報と、前記取得手段により取得した情報とに基づいて、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されているか否かを判定する判定手段と、
前記判定手段により、前記探索手段によって探索されたデバイスが前記他の管理装置によって探索されていると判定されなかった場合、当該デバイスの情報のうち、前記探索手段によって取得していない情報を、当該デバイスから取得する第二の取得手段と、
を有することを特徴とする。
【００２４】
上記目的を達成するために本発明の一態様に係る管理方法は以下のような構成を備える。即ち、
ネットワーク上のデバイスを探索する管理装置の管理方法であって、
ネットワークに他の管理装置が存在するか否かを識別する識別工程と、
前記識別工程で他の管理装置が存在すると識別されると、当該他の管理装置によって探索されたデバイスの情報を、当該他の管理装置から取得する取得工程と、
前記ネットワーク上のデバイスを探索する探索工程と、
前記探索工程で探索されたデバイスの情報と、前記取得工程で取得した情報とに基づいて、前記探索工程で探索されたデバイスが前記他の管理装置によって探索されているか否かを判定する判定工程と、
前記判定工程で、前記探索工程で探索されたデバイスが前記他の管理装置によって探索されていると判定されなかった場合、当該デバイスの情報のうち、前記探索工程で取得していない情報を当該デバイスから取得する第二の取得工程と、
を有することを特徴とする。
【発明の効果】
【００２５】
本発明によれば、広範囲におけるデバイス探索が要求されても、効率的にデバイスを管理することができる。
【発明を実施するための最良の形態】
【００２６】
以下、添付図面を参照して本発明の好適な実施の形態を詳しく説明する。尚、以下の実施の形態は特許請求の範囲に係る本発明を限定するものでなく、また本実施の形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。
【００２７】
先ず、本発明の実施の形態１に係るネットワークデバイス分散管理システムについて説明する。
【００２８】
図３は、本発明の実施の形態１に係るネットワークデバイス分散管理システムの構成を示す図である。尚、本発明の機能が実現されるのであれば、ホストコンピュータ３０００でのプログラムの動作を、プリンタ１５００上のＣＰＵ、ＲＡＭ，ＲＯＭで実行しても良いことは言うまでもない。ここでは、実施の形態１に係るネットワークデバイス分散管理システムは、情報処理装置としてのホストコンピュータ３０００と、管理装置及びデバイスとしてのプリンタ１５００とから構成されているが、これ以外のネットワークデバイスが接続されていても良いことはもちろんである。例えば、管理装置としての機能を備えない、単なるデバイスとしてのプリンタ等が接続されていてもよい。
【００２９】
また、ホストコンピュータ３０００とプリンタ１５００間の接続方式が、ＬＡＮ，ＷＡＮ（Wide Area Network：広域ネットワーク）以外のネットワークを介してなされる場合でも、本発明を適用できることは言うまでもない。
【００３０】
この実施の形態１で説明する管理対象であるデバイスのエージェントは、プリンタ１５００のネットワークインタフェイスである入出力部１８であり、このエージェントの管理を行うクライアントはホストコンピュータ３０００である。
【００３１】
このエージェントからの情報を収集し、クライアントに情報を提供できるサーバは、サーバ部（以下、単にサーバと略す）１５０２で動作する、Embedded Java(登録商標)環境のプログラムである。また、このサーバは、プリンタ１５００のＣＰＵ１２，ＲＡＭ１９，ＲＯＭ１３で動作させるEmbedded Java(登録商標)環境のプログラムとしても動作させることができる。尚、本実施の形態では、サーバのプログラムをプリンタ上で動作させているが、ネットワークに接続されているＰＣ上で動作させることも可能である。
【００３２】
まずホストコンピュータ３０００の構成を説明する。ＣＰＵ１はシステムバス４に接続された各デバイスを統括的に制御する中央処理装置である。このＣＰＵ１は、ＲＯＭ３のプログラム用ＲＯＭ３ｂ（後述）或いは外部メモリ（ＨＤ）１１に記憶されたアプリケーション（文書処理プログラム等）に基づいて、図形、イメージ、文字、表（表計算等を含む）等が混在した文書処理等の各種処理を実行する。またＣＰＵ１は、例えばＲＡＭ２上に設定された表示ＲＡＭへのアウトラインフォントの展開（ラスタライズ）処理を実行し、ＣＲＴＣ（表示制御部）６を介して表示部１０に表示する。更に、ＣＰＵ１は、この表示部１０上のマウスカーソル（図示略）等で指示されたコマンドに基づいて、登録された種々のウインドウを開き、種々のデータ処理を実行する。ユーザはプリンタ１５００を使用して印刷する際、その印刷設定に関するウインドウを開き、プリンタ１５００の設定や印刷モードの選択を含むプリンタドライバに対する印刷処理方法の設定を行うことができるようになっている。尚、表示部１０はＣＲＴに限らず、液晶やプラズマ等でも良い。
【００３３】
ＲＡＭ２はＣＰＵ１の主メモリ、ワークエリア等として機能する。ＲＯＭ３はフォント用ＲＯＭ３ａと、プログラム用ＲＯＭ３ｂと、データ用ＲＯＭ３ｃとを備えている。フォント用ＲＯＭ３ａ或いは外部メモリ１１は、上記文書処理等の際に使用するフォントデータ等を記憶する。プログラム用ＲＯＭ３ｂ或いは外部メモリ１１は、ＣＰＵ１の制御プログラムであるオペレーティングシステム（以下、ＯＳ）等を記憶する。データ用ＲＯＭ３ｃ或いは外部メモリ１１は、上述の文書処理等を行う際に使用する各種データを記憶する。又外部メモリ１１に記憶されているプログラムは、実行時にＲＡＭ２に展開されて実行される。
【００３４】
キーボードコントローラ（ＫＢＣ）５は、キーボード９やポインティングデバイス（不図示）からの入力情報を制御する。ＣＲＴＣ６は、表示部１０への表示を制御する。ディスクコントローラ（ＤＫＣ）７は、外部メモリ１１とのアクセスを制御する。プリンタコントローラ（ＰＲＴＣ）８は、双方向性インタフェース２２を介してプリンタ１５００に接続されて、プリンタ１５００との通信制御処理を実行する。キーボード９は、各種キーを備えている。表示部１０は、図形、イメージ文字、表等を表示する。外部メモリ１１はハードディスク（ＨＤ）、フロッピー(登録商標)ディスク（ＦＤ）等から構成されている。この外部メモリ１１は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタ制御コマンド生成プログラム（以下、プリンタドライバ）等を記憶する。
【００３５】
上述したＣＰＵ１，ＲＡＭ２，ＲＯＭ３，キーボードコントローラ（ＫＢＣ）５，ＣＲＴＣ６，ディスクコントローラ（ＤＫＣ）７，プリンタコントローラ（ＰＲＴＣ）８は、コンピュータ制御ユニット２０００上に配設されている。
【００３６】
次に、プリンタ１５００各部の構成を説明する。
【００３７】
ＣＰＵ１２は、システムバス１５に接続された各デバイスを統括的に制脚する中央処理装置である。このＣＰＵ１２は、ＲＯＭ１３のプログラム用ＲＯＭ１３ｂ（後述）に記憶された制御プログラム等或いは外部メモリ１４に記憶された制御プログラム等に基づいて印刷部（プリンタエンジン）１７に印刷情報としての画像信号を出力する。またＣＰＵ１２は、入出力部１８を介してホストコンピュータ３０００との通信処理を行って、プリンタ１５００の情報等をホストコンピュータ３０００に通知できる構成となっている。
【００３８】
ＲＡＭ１９は、ＣＰＵ１２の主メモリや、ワークエリア等として機能し、増設ポートに接続されるオプションＲＡＭ（不図示）によりメモリ容量を拡張することができるように構成されている。尚、ＲＡＭ１９は、出力情報展開領域、環境データ格納領域、ＮＶＲＡＭ等に用いられる。ＲＯＭ１３は、フォント用ＲＯＭ１３ａと、プログラム用ＲＯＭ１３ｂと、データ用ＲＯＭ１３ｃとを備えている。フォント用ＲＯＭ１３ａは、上記印刷情報を生成する際に使用するフォントデータ等を記憶する。プログラム用ＲＯＭ１３ｂは、ＣＰＵ１２の制御プログラム等を記憶する。データ用ＲＯＭ１３ｃは、プリンタ１５００にハードディスク等の外部メモリ１４が接続されていない場合には、ホストコンピュータ３０００上で利用される情報等を記憶する。
【００３９】
ネットワークカード等の入出力部１８は、双方向性インタフェース２２を介してプリンタ１５００とホストコンピュータ３０００との間におけるデータの送受信を行う。また、入出力部１８に接続されたエージェント１５０１は、ホストコンピュータ３０００やサーバと、双方向性インタフェース２２又は、システムバス１５を介して通信を行う。この例で、サーバ１５０２はシステムバス１５に接続されており、エージェント１５０１は入出力部１８に接続されているが、プリンタ１５００のＣＰＵ１２，ＲＡＭ１９，ＲＯＭ１３上で動作するように実装することも考えられる。
【００４０】
印刷部インタフェース（Ｉ／Ｆ）１６は、ＣＰＵ１２と印刷部１７との間におけるデータの送受を行う。メモリコントローラ（ＭＣ）２０は、外部メモリ１４へのアクセスを制御する。印刷部１７は、ＣＰＵ１２の制御に基づき印刷動作を行う。操作部２１は、各種操作のためのスイッチや表示手段（例えばＬＥＤ表示器）等を備えている。外部メモリ１４は、ハードディスク（ＨＤ）、ＩＣカード等から構成されており、プリンタ１５００にオプションとして接続される。この外部メモリ１４は、フォントデータ、エミュレーションプログラム、フォームデータ等を記憶しており、メモリコントローラ（ＭＣ）２０によりアクセスが制御される。尚、外部メモリ１４は１個に限らず、複数個備えることが可能となっている。即ち、内蔵フォントに加えてオプションカード、言語系の異なるプリンタ制御言語を解釈するプログラムを格納した外部メモリを複数接続できるように構成されていてもよい。更に、ＮＶＲＡＭ（図示略）を有し、操作部２１からのプリンタモード設定情報を記憶するようにしてもよい。
【００４１】
上述したＣＰＵ１２，ＲＡＭ１９，ＲＯＭ１３，入出力部１８、印刷部インタフェース（Ｉ／Ｆ）１６、メモリコントローラ（ＭＣ）２０は、プリンタ制御ユニット１０００上に配設されている。
【００４２】
図４は、本発明の実施の形態１に係るネットワークデバイス分散管理システムにおいて、ネットワーク上に、クライアント、複数のサーバ、及び、少なくとも１つ以上のエージェント（管理対象となるデバイス）が存在する場合の構成例を示す図である。
【００４３】
ホストコンピュータ３０００で、ネットワークデバイスの管理ソフトウエアであるクライアント４１３が起動している。ＬＡＮ１００を介してホストコンピュータ３０００と接続されているプリンタ１５００では、そのプリンタの状態や構成をクライアント４１３に通知する情報を作成するエージェント１５０１が起動されている。更に、クライアント４１３からの命令をサブネット（ＬＡＮ１００）内のエージェントに実行させるサーバ１５０２が起動している。
【００４４】
またネットワーク１００に接続されている他のプリンタ１５００ａでは、エージェント１５０１ａ及び、サーバ１５０２ａが起動している。またネットワーク１００に接続されている更に別のプリンタ１５００ｃでは、エージェント１５０１ｃが起動している。このように図４の構成では、サブネット１００上で、サーバ１５０２及びサーバ１５０２ａの２つが存在している。
【００４５】
図５は、本実施の形態に係るプリンタ１５００のサーバ１５０２の構成を説明するブロック図である。
【００４６】
サーバ制御部５０１は、サーバ１５０２を制御している。通信制御部５０２は、クライアント４１３とサーバ１５０２との間、及び他のサーバ１５０２ａとの間の通信、サーバ１５０２と管理対象のエージェント１５０１との間の通信制御を行う。これら各通信では、通信用途によりウェブサービスのサーバ機能やクライアント機能、機器管理を行うためのＳＮＭＰやＳＬＰプロトコル等を行う。他サーバ管理部５０５は、マルチキャストパケットによるサーバサービスの探索結果やその管理対象エージェント情報を保持する。エージェント管理部５０６は、探索実行結果のエージェント情報を保持しておき、クライアントや他のサーバからの探索指示やエージェント取得指示を受取ると、自サーバで管理しているエージェント情報を通知する。主探索部５０７は、ネットワーク１００上のデバイスの存在を確認するための探索を行う。例えばWS-DiscoveryのProbe及びProbe Matchパケット（非特許文献２を参照）のようなサービスのアドレス探索を行う。副探索部５０８は、主探索部５０７のアドレス探索結果から、それらのデバイスの構成情報やステータス等を取得し、クライアントが必要としている情報を取得する。
【００４７】
図６は、上述の構成を有するネットワークデバイス分散管理システムにおける、サーバ１５０２による探索時の処理を説明するフローチャートである。
【００４８】
まずステップＳ１０１で、サーバ１５０２がサービス開始後にクライアント４１３からのデバイス探索リクエストを受信する。次にステップＳ１０２に進み、他サーバ管理部５０５は、他のサーバが存在するかを確認する。
【００４９】
図７は、本実施の形態に係る他サーバ管理部５０５が管理しているサーバ管理情報の一例を示す図である。
【００５０】
ここでは探索された各サーバに対応して、そのＩＰアドレスが登録されている。
【００５１】
ここで、サーバの探索方法としては、予めサブネット１００上の、他のサーバのアドレスを登録しておく方法がある。またブロードキャストアドレス、マルチキャストアドレス等により、ＳＬＰで探索する方法や、ポート番号を固定した独自プロトコルにより、サーバの存在を確認する方法等が考えられる。
【００５２】
ステップＳ１０２でサーバを探索する際、デバイス探索リクエストの探索予定のホップ数よりも大きいホップ数で他のサーバを探索することにより、重複してエージェントの探索を行う場合が減少する。次にステップＳ１０３で、ステップＳ１０２の探索結果により他のサーバが見つかったか否かを判定する。他のサーバが見つかった場合はステップＳ１０４に進み、他のサーバが既に管理対象としているエージェントの一覧を取得してステップＳ１０５に進む。これらの情報は、エージェント管理部５０６で、他のサーバが管理しているエージェント情報として保持されている。尚、ステップＳ１０３で、他のサーバが見つからなかった場合は、ステップＳ１０４を実行せずにステップＳ１０５に進む。
【００５３】
ステップＳ１０５では、エージェントのアドレスを取得するために主探索を実行する。この主探索では、例えばWS-DiscoveryのProbeを行う。これにより探索条件に該当するデバイスがProbe Matchパケットを返信してくるため、デバイスのアドレスとしてＵＵＩＤ(Universally Unique  Identifier)等のデバイス識別子を得ることができる。これらの情報はエージェント管理部５０６で主探索結果として保持される。
【００５４】
図８は、この主探索結果の一例を示す図である。
【００５５】
図８において、８０１には、管理サーバの名称が記憶されており、８０２には主探索の結果であるＩＰアドレスとＵＵＩＤが登録されている。即ち、図８の例では、主探索の結果見つかったＩＰアドレス１０．０．０．５のデバイスを、サーバ２が管理していることを意味している。
【００５６】
次にステップＳ１０６に進み、エージェント管理部５０６で保持されている主探索で見つかったデバイスと、エージェント管理部５０６で保持されている他のサーバが管理対象としているエージェントとを比較する。その結果、主探索で見つかった全てのデバイスの中で、既に他のサーバで管理対象としているデバイスがある場合はステップＳ１０７に進み、そのデバイスをエージェント管理部５０６のデバイス管理テーブルに非管理対象デバイスとして登録する。
【００５７】
一方、主探索で見つかったデバイスが、他のサーバが管理対象としていないエージェントである場合はステップＳ１０６からステップＳ１０８に進み、そのエージェントから構成情報やステータスを取得する副探索を実行する。この副探索は、主探索結果を基に、クライアント４１３が必要としている情報を取得するものである。例えば、そのデバイスのモデル名や、構成情報として周辺機器の接続状態、デバイスや周辺機器のステータス、各種ログ、機器の設定等を取得する。そしてステップＳ１０９で、デバイス管理テーブルに管理対象デバイスとして登録する。
【００５８】
図９は、この副探索による探索結果の一例を示す図である。
【００５９】
図８と図９とを比較すると明らかなように、副探索によりＩＰアドレス「10.0.0.6」に対応するデバイスのモデル名と、そのモデルがカラー印刷が可能であることが登録されている。
【００６０】
こうしてステップＳ１０７或はＳ１０９を実行するとステップＳ１１０に進み、これらの探索結果をクライアント４１３に返信する。
【００６１】
また、ステップＳ１０３でサーバが多数見つかった場合は、サーバ間の通信により通信量が増加しすぎる場合がある。よって、そのような場合は、クライアント４１３経由でユーザにサーバの再配置等の注意を促す。または、不要なサーバを停止するようにしても良い。
【００６２】
以上説明した本実施の形態１によれば、サーバが複数存在する場合であっても、複数のサーバとクライアントが重複する情報を取得する通信を防止できる。これによりネットワークのトラフィックが少ない効率的なのエージェントの管理が可能となる。
【００６３】
また管理対象デバイスに対して、無駄なリソースを使用しないようにできる。また、ユーザはサーバの配置等を意識することなく、効率的なデバイスの管理を行うことが可能となる。
【００６４】
［実施の形態２］
前述の実施の形態１では、サーバは、主探索で見つかったエージェントが他のサーバが管理対象としていない場合は、自サーバで管理対象とするために副探索を行っていた。しかし、副探索を行うときに、例えばモデル名などの毎回値の変わらない固定値の属性は、既に取得済みの情報があれば、それを採用して再取得しないようにする。これにより、ネットワークトラフィックをより低減することができる。
【００６５】
そこで本実施の形態２では、そのような環境で、ネットワークデバイスを効率的に管理するためのネットワークデバイス分散管理システムを提案する。
【００６６】
図１０は、本発明の実施の形態２に係るネットワークデバイス分散管理システムにおける、サーバによる探索時の処理を説明するフローチャートである。尚、この実施の形態２に係るネットワークデバイス分散管理システムの構成等は前述の実施の形態１の場合と同様であるため、その説明を省略する。尚、図１０において、ステップＳ１０１〜Ｓ１１０は、前述の図６のフローチャートにおけるステップＳ１０１〜Ｓ１１０と同じであるため、同じ記号を付してその説明を省略する。
【００６７】
ステップＳ１０６で、サブネットに複数のサーバが存在する場合、サーバはエージェントが他のサーバで管理対象済みか否かを確認する。管理対象でないデバイスが存在する場合はステップＳ２０１に進み、既に自ブローカが管理対象としているデバイスか否かを確認する。ステップＳ２０１で、既に自サーバが管理対象としているデバイスの場合はステップＳ２０２に進み、副探索で取得する属性に動的な含まれるか否かを確認する。ここで動的な属性がない場合は副探索を行わずにステップＳ１１０に進んで、探索結果をクライアントに通知する。一方、ステップＳ２０２で、動的な属性が含まれる場合はステップＳ２０３に進み、動的な属性のみを再取得する。次にステップＳ１１０に進み、副探索を完了して探索結果をクライアントに通知する。
【００６８】
図１１は、本発明の実施の形態２に係る探索結果の一例を示す図である。
【００６９】
図において、ＩＰアドレスが「10.0.0.6」のデバイスは、自サーバが管理対象としており、既に副探索済みである。この場合に、再度探索命令を受信した場合、モデル名やカラー印刷が可能か否かを示す属性は固定値であるために再取得しない（図９参照）。
【００７０】
しかし、９０１で示すように、デバイスステータスは動的な属性であるために再取得を行う。
【００７１】
尚、ここで各属性が静的な属性であるか、動的な属性であるかは、各属性ごとに事前に設定されているものとする。
【００７２】
以上説明したように本実施の形態２によれば、サーバが複数存在する場合も、複数のサーバとクライアントが重複する情報を取得するための通信を行わない。このため、トラフィックの少ない効率的なエージェントの管理が可能となる。
【００７３】
また、サーバが重複する属性を取得しないために、よりトラフィックの少ない情報取得が可能となる。また管理対象デバイスに対して、無駄なリソースを使わなくなる。
【００７４】
また、ユーザはサーバの配置等を意識しなくても効率的なデバイス管理を行う事が可能となる。
【００７５】
［実施の形態３］
前述の実施の形態１では、サーバは主探索で見つかったエージェントについて、他のサーバが管理対象としていない場合は、自サーバで管理対象とするために副探索を行っていた。しかし、いずれのサーバからも管理対象となっていないエージェントが存在する場合に、クライアント４１３がサーバ１５０２に対してマルチキャストで探索指示を行った場合、同時に複数のサーバが副探索を行ってしまう。
【００７６】
そこで本実施の形態３では、サーバは、他のサーバに管理対象デバイスであるか否かを確認すると同時に副探索の実行予約を行い、他のサーバへの予約が完了した後に副探索を行う。また、副探索の予約が完了した後に、実際に副探索が行われない場合には、一定時間後に副探索の実行予約を無効とする。
【００７７】
本実施の形態３は、そのような環境でのネットワークデバイスを効率的に管理するための、ネットワークデバイス分散管理システムの場合で説明する。
【００７８】
図１２は、本発明の実施の形態３に係るネットワークデバイス分散管理システムにおける、サーバによる探索時の処理を説明するフローチャートである。尚、この実施の形態３に係るネットワークデバイス分散管理システムの構成等は前述の実施の形態１の場合と同様であるため、その説明を省略する。
【００７９】
尚、図１２において、ステップＳ１０１〜Ｓ１１０は、前述の図６のフローチャートにおけるステップＳ１０１〜Ｓ１１０と同じであるため、同じ記号を付してその説明を省略する。
【００８０】
ステップＳ１０６で、サブネット上に複数のサーバが存在する場合、サーバはエージェントが他のサーバで管理対象済みかどうかを確認する。ここで管理対象としていないデバイスが存在する場合はステップＳ３０１に進み、他サーバに対して、探索対象予定（副探索実行予定）デバイスを副探索する副探索予約を行う。次にステップＳ３０２に進み、他サーバへの副探索予約が成功したかどうかを確認する。ここで他サーバへの副探索予約が成功した場合はステップＳ１０８に進み、エージェントから構成情報やステータスを取得する副探索を実行する。この副探索により、ステップＳ１０９で、主探索結果を基に、クライアント４１３やサーバが探索に必要な情報を取得し、デバイス管理テーブルに管理対象デバイスとして登録する。続いてステップＳ３０５に進み、他サーバに対して副探索結果を通知（予約解除）を行う。しかし、この通知を行わない場合も、他のサーバは、副探索予約の一定時間経過後であれば副探索を実行しても良い、また或は、その予約したサーバが副探索に失敗する等の理由により予約解除の通知が無くても、対象エージェントの他のサーバが管理対象としていなければ副探索を行うようにしても良い。
【００８１】
またステップＳ３０２で、他サーバへの副探索予約が成功しない、即ち、既に管理対象としている場合はステップＳ３０３に進み、デバイス管理テーブルに非管理対象デバイスとして登録して探索を終了する。
【００８２】
以上説明したように本実施の形態３によれば、サーバが複数存在する場合も、複数のサーバとクライアントが重複する情報を取得するための通信を防止できる。これにより、トラフィックの少ない効率的なのエージェントの管理が可能となる。
【００８３】
また、サーバが重複する属性取得を行わないために、よりトラフィックの少ない情報取得が可能となる。
【００８４】
また、管理対象デバイスに対して、無駄なリソースを使わなくなる。また、ユーザはサーバの配置等を意識しなくても効率的なデバイス管理を行う事が可能となる。
【００８５】
（他の実施形態）
以上、本発明の実施形態について詳述したが、本発明は、複数の機器から構成されるシステムに適用しても良いし、また一つの機器からなる装置に適用しても良い。
【００８６】
なお、本発明は、前述した実施形態の機能を実現するソフトウェアのプログラムを、システム或いは装置に直接或いは遠隔から供給し、そのシステム或いは装置のコンピュータが該供給されたプログラムを読み出して実行することによっても達成され得る。その場合、プログラムの機能を有していれば、形態は、プログラムである必要はない。
【００８７】
従って、本発明の機能処理をコンピュータで実現するために、該コンピュータにインストールされるプログラムコード自体も本発明を実現するものである。つまり、本発明のクレームでは、本発明の機能処理を実現するためのコンピュータプログラム自体も含まれる。その場合、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。
【００８８】
プログラムを供給するための記録媒体としては、様々なものが使用できる。例えば、フロッピー（登録商標）ディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤ（ＤＶＤ−ＲＯＭ，ＤＶＤ−Ｒ）などである。
【００８９】
その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続し、該ホームページからハードディスク等の記録媒体にダウンロードすることによっても供給できる。その場合、ダウンロードされるのは、本発明のコンピュータプログラムそのもの、もしくは圧縮され自動インストール機能を含むファイルであってもよい。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバも、本発明のクレームに含まれるものである。
【００９０】
また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布する形態としても良い。その場合、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせ、その鍵情報を使用することにより暗号化されたプログラムが実行可能な形式でコンピュータにインストールされるようにする。
【００９１】
また、コンピュータが、読み出したプログラムを実行することによって、前述した実施形態の機能が実現される形態以外の形態でも実現可能である。例えば、そのプログラムの指示に基づき、コンピュータ上で稼動しているＯＳなどが、実際の処理の一部または全部を行ない、その処理によっても前述した実施形態の機能が実現され得る。
【００９２】
更に、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれるようにしてもよい。この場合、その後で、そのプログラムの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行ない、その処理によって前述した実施形態の機能が実現される。
【図面の簡単な説明】
【００９３】
【図１】ネットワーク管理の対象となりうるコンピュータネットワークの構成例を示す図である。
【図２】図１において、コンピュータ装置がクライアントとして動作し、通信装置がサーバ装置として動作するとした場合を説明する概略図である。
【図３】本発明の実施の形態１に係るネットワークデバイス分散管理システムの構成を示す図である。
【図４】実施の形態１に係るネットワークデバイス分散管理システムにおいて、ネットワーク上に、クライアント、複数のサーバ、及び、少なくとも１つ以上のエージェントが存在する場合の構成例を示す図である。
【図５】本実施の形態に係るサーバの構成を説明するブロック図である。
【図６】実施の形態１に係るネットワークデバイス分散管理システムにおける、サーバによる探索時の処理を説明するフローチャートである。
【図７】本実施の形態に係る他ブローカ管理部が管理しているブローカ管理情報の一例を示す図である。
【図８】実施の形態１に係る主探索結果の一例を示す図である。
【図９】実施の形態１に係る副探索による探索結果の一例を示す図である。
【図１０】本発明の実施の形態２に係るネットワークデバイス分散管理システムにおける、サーバによる探索時の処理を説明するフローチャートである。
【図１１】本発明の実施の形態２に係る探索結果の一例を示す図である。
【図１２】本発明の実施の形態３に係るネットワークデバイス分散管理システムにおける、サーバによる探索時の処理を説明するフローチャートである。
【図１】
2008140048.tif 000003
【図２】
2008140048.tif 000004
【図３】
2008140048.tif 000005
【図４】
2008140048.tif 000006
【図５】
2008140048.tif 000007
【図６】
2008140048.tif 000008
【図７】
2008140048.tif 000009
【図８】
2008140048.tif 000010
【図９】
2008140048.tif 000011
【図１０】
2008140048.tif 000012
【図１１】
2008140048.tif 000013
【図１２】
2008140048.tif 000014