JP2009199458A - デバイス管理システム、サーバ、デバイス管理方法、プログラム - Google Patents

Abstract

【課題】 システム内の複数のサーバ間におけるデバイス管理を効率良く行うことである。
【解決手段】 子サーバから管理対象となるデバイス情報を取得する（Ｓ２００１）。次に、親サーバ参照時の属性９０５の情報が読取専用属性か否かの判定を行う（Ｓ２００２）。次に、対象となるデバイスよりデバイス情報の取得が成功したかどうかの判定を行う（Ｓ２００４）。ここで、デバイス情報の取得が成功したとデバイス管理部が判定した場合は、デバイス情報の取得が成功したデバイスの、現管理サーバの情報を参照し、現管理サーバが子サーバであるか否かを判定する（Ｓ２００５）。次に、現管理サーバが現管理サーバの情報を親サーバに変更する（Ｓ２００６）。次に、現管理サーバは、デバイス情報の表示の更新を行う（Ｓ２００８）ことを特徴とする。
【選択図】 図１２

Description

本発明は、デバイス管理システムにおける、管理対象デバイス情報をインポートする際の管理方法およびそのプログラムに関するものである。

従来、複数台の管理サーバで分散してデバイスを管理するような場合、親サーバと子サーバを備えるデバイス管理システムが下記特許文献１に開示されている。このようなデバイス管理システムにおいて、子サーバから拠点に存在するデバイスの情報を親サーバに送信し、親サーバ側で管理対象のデバイスであるか否かの判定を行うというような例が一般的だった。
特開２００３−３１６６７４号公報

しかしながら、上記従来例では、次のような問題点があった。

親サーバ側に、子サーバから送信されてくるデバイスのデバイス情報が、管理対象であるか否かの判定を行うための情報を持っていなければならず、またその情報は、常に最新のものに更新されている必要がある。

また、親サーバにおいて、子サーバから送られて来るデバイスのデバイス情報と、判定情報の比較を行うなどの処理が必要となり、管理対象のデバイスの数が多くなればなるほど、親サーバ側の負荷が増大するという問題があった。

更に、子サーバで管理を行っているデバイスの情報を親サーバが一元管理を行うと、子サーバにおいて個別に設定管理している内容が、親サーバによって更新されてしまう。そのため、子サーバの管理下の環境において設定内容に矛盾が生じるという問題がある。

本発明は、上記の課題を解決するためになされたもので、本発明の目的は、システム内の全デバイス情報の一括して認識可能とすると同時に、システム内の複数のサーバ間におけるデバイス管理を効率良く行うための手法を提供することである。

上記目的を達成する本発明のデバイス管理システムは以下に示す構成を備える。

第１のサーバと、当該第１のサーバとは異なる第２のサーバを含むデバイス管理システムであって、前記第１のサーバは、前記第１のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第１の管理手段を備え、前記第２のサーバは、前記第２のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第２の管理手段と、前記第１のサーバの管理対象であり、前記第２のサーバでは管理対象外のデバイスのデバイス情報を表示する表示手段とを備えることを特徴とする。

本発明によれば、システム内の複数のサーバ間におけるデバイス管理を効率良く行える。

次に本発明を実施するための最良の形態について図面を参照して説明する。

＜システム構成の説明＞
〔第１実施形態〕
図１は、本発明の本実施形態を示すデバイス管理システムの構成を説明するブロック図である。本例は、親サーバ１０２と子サーバ１０７でデバイス管理システムが構成されるである。なお、子サーバの数は複数でも構わず、またそのネットワーク構成上の階層などに関しても特に制限はない。また、本実施形態では、管理するデバイスには、プリンタ、複合機、ローカルＰＣが含まれるが、以下、説明上、デバイスと記す。なお、子サーバ１０７を第１のサーバとして、親サーバを第２のサーバとして機能させるデバイス管理システムを一例として、以下説明を行う。

図１において、１０１はイーサネット（登録商標）などの通信媒体（通信回線）で、親サーバ１０２で管理されているデバイス１０３〜１０５、子サーバ１０７などと通信データが交換される伝送経路となる。子サーバ１０７と親サーバ１２０とは通信回線を介して通信可能に構成されている。

デバイス１０３〜１０５はそれぞれ親サーバ１０２により直接管理されているデバイスを表わす。なお、デバイス１０３〜１０５は、多機能周辺装置であるＭＦＰ（Ｍｕｌｔｉｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）や、プリンタ機能のみを持つＳＦＰ（Ｓｉｎｇｌｅ Ｆｕｎｃｔｉｏｎ Ｐｒｉｎｔｅｒ）等で構成される。

１０６はルータで、親サーバ１０２が稼動する環境のネットワークと、子サーバ１０７が稼働する環境のネットワークを接続する。ここでは説明を簡略化するためにイントラネット内のネットワークを接続するルータを用いて説明するが、インターネットを経由して親サーバ稼働環境と、子サーバ稼働環境を接続するケースも考えられる。

１０７は子サーバで、デバイス１０８〜１１０を直接管理している。なお、デバイス１０８〜１１０は、ＭＦＰで構成されるが、プリンタ機能のみを持つＳＦＰで構成されていてもよい。

１１１はルータで、子サーバ１０７が管理するネットワーク環境に異なるサブネットが含まれているような場合に、それらのネットワークを接続する。本例では、デバイス１１０がサブネットに接続されている。尚、サーバが管理するデバイスとしてはパーソナルコンピュータ（ＰＣ）であってもよい。

なお、親サーバ１０２、子サーバ１０７は、ＣＰＵ、ＲＯＭ、ＲＡＭ等を含むコントローラを備え、システムバスに接続されるインタフェースを介して、入力デバイス、出力デバイスが接続される。また、親サーバ１０２、子サーバ１０７は、ネットワークコントローラを備えて、デバイス１０３〜１０５、ルータ１０６等と所定のプロトコルで通信を行う。

また、親サーバ１０２、子サーバ１０７が備える外部記憶装置に、オペレーティングシステム（ＯＳ）を含む各種のシステムプログラム、アプリケーションがインストールされている。そして、親サーバ１０２、子サーバ１０７のＣＰＵがＲＡＭにプログラムをロードして実行することにより、各種のデータ処理を行う。ここで、プログラムには、後述するフローチャートに示す手順が含まれる。

図２は、図１に示すデバイス管理システムの構成を説明するブロック図である。以下、デバイス管理システムを構成するデバイス、サーバのハードウエアについて説明する。

図２において、２０１はネットワーク媒体であって、各機器間のネットワークを構成する物理的なラインとして機能し、通常はイーサネット（登録商標）などが使われる。

図１に示した親サーバ１０２及び子サーバ１０７は、ネットワークボード２０２、ＣＰＵボード２０３、Ｖｉｄｅｏインタフェース２０４、Ｉ／Ｏインタフェース２０５、ＤＩＳＫインタフェース（ＨＤＩＦ）２０６を備える。なお、ＣＰＵボード２０３には、ＣＰＵ、ＲＯＭ、ＲＡＭが含まれる。

さらに、親サーバ１０２及び子サーバ１０７は、ＣＲＴ２０７、キーボード２０８、マウス２０９、ハードディスクドライブ（ＨＤ）２１０を備える。ここで、ＨＤ２１０は、複数のハードディスクユニットが並列に接続されており、データ転送の高速化と高信頼性を確保している。

なお、このＨＤ２１０には、親サーバ１０２及び子サーバ１０７上で動作するソフトウエアの機能を用いて、データベースを構築可能に構成されている。ＨＤ２１０には、デバイスとの通信により探索される各デバイスのデバイス情報が保持されている。また、各デバイスのデバイス情報は、例えば図６、図９に示すように、自身が管理対象のデバイスと他のサーバの管理対象のデバイスとを特定可能に保持される。

なお、ＣＲＴ２０７は、表示装置の一例を示すが、液晶ディスプレイで構成されていてもよい。

デバイス１０３〜１０５およびデバイス１０８，１０９は、周辺機器に対応したネットワークボード２２１、多機能周辺装置のコントローラボード２２２、モデム２２３を備える。さらに、デバイス１０３〜１０５およびデバイス１０８，１０９は、スキャナユニット２２４、スキャナコントローラ２２５、操作パネルコントローラ２２６、操作パネル２２７を備える。

さらに、デバイス１０３〜１０５およびデバイス１０８，１０９は、ハードディスクコントローラ２２８、ハードディスク（ＨＤ）２２９、プリントエンジン２３０、 オプションコントローラ２３１、オプションＩＦ２３２を備える。また、オプションＩＦ２３２にはフィニッシャユニット２５０を接続可能に構成されている。

なお、デバイス１０３〜１０５およびデバイス１０８，１０９は、本実施形態ではＭＦＰとして構成されている。

デバイス１１０は、周辺機器に対応したネットワークボード２１２、プリンタ機能コントローラボード２１３、プリントエンジン２１４、 操作パネルコントローラ２１５、操作パネル２１６を備える。

さらに、デバイス１１０は、ハードディスクコントローラ２１７、ハードディスク２１８、オプションコントローラ２１９、オプションＩＦ２２０を備える。

なお、デバイス１１０は、本実施形態ではＳＦＰとして構成されている。

図３は、図１に示した親サーバ１０２におけるソフトウエアモジュールの構成を説明する図である。以下、デバイス管理ソフトウエアの構成について説明する。

図３において、３０１はデバイス管理アプリケーションで、対象となるデバイスのステータスなどの管理情報を取得管理するデバイス管理部３０２を備える。また、デバイス管理アプリケーション３０１は、管理対象のデバイス群の情報を管理するデバイス情報管理部３０３と、子サーバ１０７と通信を行い、子サーバ１０７の管理デバイス情報を取得する子サーバ１０７の通信処理部３０４とを備える。

なお、デバイス管理アプリケーション３０１は、ＣＰＵボード２０３により実行されることで第２の管理手段として機能する。

３０５はライブラリで、ＯＳ３０６が提供するライブラリ群であり、アプリケーションプログラムを構築する際のフレームワークとして機能する。

３０７はドライバ（Ｄｒｉｖｅｒ）で、ハードウエアを制御するソフトウエアであり、印刷に使用するプリンタドライバなども含まれる。３０８はハードディスク制御部（ＨＤ制御部）で、ＨＤ２１０とのアクセスを制御する。３０９はネットワーク制御部で、ネットワークボード２０２を介してデバイスとの通信を制御する。

なお、親サーバ１０２は、上記デバイス管理ソフトを実行して、ネットワーク上に接続されるデバイスの管理処理を行う。

図４は、図１に示した子サーバ１０７におけるソフトウエアモジュールの構成を説明する図である。以下、デバイス管理ソフトウエアの構成について説明する。

図４において、４０１はデバイス管理アプリケーションプログラムで、以下のモジュールから構成される。なお、デバイス管理アプリケーション４０１は、ＣＰＵボード２０３により実行されることで第１の管理手段として機能する。

デバイス管理アプリケーション４０１は、管理すべき対象となるデバイスのステータスなどの管理情報を取得管理するデバイス管理部４０２を備える。また、デバイス管理アプリケーション４０１は、管理すべき対象のデバイス群の情報を管理するデバイス情報管理部４０３を備える。

さらに、デバイス管理アプリケーション４０１は、子サーバ１０７において管理すべき対象の印刷デバイスに対して実行された設定や情報取得などの処理タスクに関する情報を管理するタスク情報管理部４０４を備える。

さらに、デバイス管理アプリケーション４０１は、親サーバ１０２と通信を行い、親サーバ１０２に自サーバにおける管理デバイス情報を送信するための親サーバとの通信処理部４０５を備える。

４０６はライブラリで、ＯＳ４０７が提供するライブラリ群であり、アプリケーションプログラムを構築する際のフレームワークとして機能する。

４０８はドライバ（Ｄｒｉｖｅｒ）で、ハードウエアを制御するソフトウエアであり、印刷に使用するプリンタドライバなども含まれる。４０９はＨＤ制御部で、ＨＤ２１０とのアクセスを制御する。４１０はネットワーク制御部で、ネットワークボード２０２を介してデバイスとの通信を制御する。

なお、子サーバ１０７は、上記デバイス管理ソフトを実行して、ネットワーク上に接続されるデバイスの管理処理を行う。

図５は、図１に示した子サーバ１０７のユーザインタフェースで表示されるデバイスリスト画面の一例を示す図である。

本例は、デバイス管理ソフトにより管理される管理対象となるデバイスリストの一覧表示例である。

図５に示すように、本実施形態では、図１におけるデバイス１０８〜１１０が、それぞれDev４〜６というデバイス名称でリストアップされている例である。

また、本実施形態では、デバイスリストの表示項目として、デバイス名以外にも、製品名称、ＩＰアドレスに関する情報、ＭＡＣアドレスに関する情報を表示する。

なお、図５に示すデバイスリストに表示される項目以外に、印刷デバイスのエラーなどの情報を表わすステータス情報、デバイスの設置場所に関する情報を表示してもよい。

同様に、図５に示すデバイスリストに表示される項目以外に、デバイスのホスト名やドメインに関する情報あるいはデバイスに装着されているネットワーク通信ボードに関する情報を表示してもよい。

更には、デバイスの処理スピードなど特性に関する情報、デバイスの総処理数に関する情報、デバイスに対して管理者が設定を行ったコメント情報などを表示する事も可能である。ここで、デバイスがＭＦＰ、ＳＦＰである場合には、デバイスの処理スピードであれば印刷処理スピードとなり、総処理数に関する情報であれば印刷総枚数となる。

図５において、５０１はユーザインタフェースで、子サーバ１０７において、子サーバの管理者が管理対象のデバイスに関する管理を、親サーバ１０２に任せるか否かの選択を行うためのチェックボックスを備える。

子サーバ１０７の管理者は、親サーバ１０２において一元管理を行ってよいと判断したデバイスに関しては、「親サーバに管理を任せる」にチェックを付けることで、以降の管理を放棄するという設定を行う事が可能である。

一方、継続して子サーバ１０７において独自の管理、設定を行うデバイスに対しては、チェックボックスにチェックを付けないことで、継続して管理を行うという設定が可能である。

なお、図５に示すユーザインタフェースでは、デバイス名がDev４、Dev５の２つのデバイスが親サーバ１０２の管理対象に設定されている状態に対応する。

次に、ユーザインタフェース５０１を用いて管理すべきサーバ先の設定を行った際の、子サーバ１０７における管理対象デバイス情報の例を、図６を用いて説明する。

図６は、図１に示した子サーバ１０７で管理されるデバイス情報の一覧を説明する図である。

本例は、子サーバ１０７において管理対象となっているデバイスの情報を一元管理するテーブル例を示す。現在、子サーバ１０７が管理しているデバイス１０８〜１１０に関する情報が格納されている。ここで、デバイス１０８〜１１０に関する情報には、デバイスを識別するための識別情報、例えばデバイス名、ＩＰアドレス、ＭＡＣアドレスが含まれる例を示す。

これらの情報は、子サーバ１０７上にインストールされているデバイス管理部４０２によって子サーバ１０７の環境下でネットワークに接続されているデバイスを探索することで得られる。

なお、探索方法としてはＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）プロトコルを用いた探索パケットを子サーバ１０７がネットワーク上に送信する。

次に、子サーバ１０７によるＳＮＭＰ送信後、応答のあったデバイスに対する情報を取得し、デバイス情報管理部４０３が子サーバ１０７の記憶領域（例えばＨＤ２１０）に格納を行う事で探索が完了する。なお、探索プロトコルに関してはＳＮＭＰプロトコル以外にも、ＳＬＰ（Ｓｅｒｖｉｃｅ Ｌｏｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）プロトコルや、ＷＳＤ（Ｗｅｂ Ｓｅｒｖｉｃｅ Ｏｎ Ｄｅｖｉｃｅｓ）を用いた探索方法などがある。

また、デバイス探索に使用するプロトコルは、子サーバ１０７における探索能力やネットワーク下に存在するデバイスの機能などによって変ってくるため、使用するプロトコルに関しては特に規定しない。

図６において、６０１はデバイス名で、探索処理によってネットワーク下に接続されているデバイスのデバイス名を格納する。６０２はＩＰアドレスで、探索されたデバイスのＩＰアドレスを格納する。

６０３はＭＡＣアドレスで、探索されたデバイスのＭＡＣアドレスを格納する。６０４は現管理サーバで、デバイス名６０１に格納されているＤｅｖ４〜６（図１に示した１０８〜１１０に対応する）のデバイスを現在管理しているサーバ先の情報を格納する。

なお、図６に示すテーブルでは、現在子サーバ１０７が探索を行い、自分自身で情報を格納した場合を想定しているため、現管理サーバ６０４のエリアには"子サーバ"と情報が格納されている。

６０５は親サーバ参照時の属性で、親サーバ１０２と連携する際に、親サーバ１０２が子サーバ１０７の管理対象デバイス情報を参照した際に、対象デバイスの管理を親サーバに任せるか、子サーバ（自分自身）で継続して管理を行うかの選択状態を表わす情報が格納される。なお、本実施形態では、子サーバ（自分自身）で継続して管理を行う場合には、「読取専用」という情報が設定されている状態を示す。これにより、自身が管理対象のデバイスと他のサーバの管理対象とのデバイスとを特定可能となっている。

また、図５に示したユーザインタフェース５０１において、"親サーバに管理を任せる"に対応するチェックボックスに対して管理者がチェックを付けた場合、この領域の値は"親サーバに任せる"という状態を表わす値がセットされる。

一方、図５に示したユーザインタフェース５０１において、 "親サーバに管理を任せる"に対応するチェックボックスにチェックを付けなかった場合、この領域の値は"読取専用"という状態を表わす値がセットされる。

次に、図７を用いて親サーバ１０２が子サーバ１０７の管理対象デバイス情報を取得する際の処理の流れを説明する。

図７は、本実施形態を示す管理装置における第１のデータ処理手順の一例を示すフローチャートである。本例は、親サーバ１０２が子サーバ１０７の管理対象デバイス情報を取得する際の処理例である。なお、Ｓ７０１〜Ｓ７０９は各ステップを示し、各ステップは、図２に示したＣＰＵボード２０３のＣＰＵがＲＡＭにデバイス管理アプリケーション３０１をロードして実行することで実現される。

また、本処理は、デバイス管理アプリケーション３０１が、親サーバ１０２に登録されているデバイス管理関連の処理タスクを起動すべく、定期的にチェックを行うスケジューラプログラムにより、チェックタイミングが来た場合にスタートする。ここで、スケジューラプログラムのチェックは一定間隔ごとに繰り返され、デバイス管理アプリケーション３０１が起動中は、停止する事はない。

Ｓ７０１で、親サーバ１０２におけるデバイス管理アプリケーション３０１のデバイス管理部３０２において、親サーバ１０２に登録されている処理タスクの情報を取得する。親サーバ１０２に登録されている処理タスクの例を図８に示す。

図８は、図１に示した親サーバ１０２に登録されているタスク情報テーブルの一例を示す図である。本例は、親サーバ１０２に登録されているタスク情報を一元管理している例である。

図８において、本例では、登録されているタスクの名称、登録されているタスクの種別に関する情報、登録されているタスクの実行タイミング、登録されているタスクの処理対象であるターゲットデバイスの情報などが格納されている。

なお、実行タイミングに関しては、指定日時に１回のみ実行されるものと、周期的に実行を行う実行間隔が情報として格納されているものがある。

次に、Ｓ７０２で、Ｓ７０１において取得される情報に基づいて、子サーバ１０７から管理デバイスの情報を取得するタスクが登録されているか否かをデバイス管理部３０２が判定する。

ここで、子サーバ１０７からの管理デバイスの情報を取得するタスクが登録されていないとデバイス管理部３０２が判定した場合は、本処理を終了する。そして、次回のスケジューラプログラムの起動時に備える。

一方、Ｓ７０２で、子サーバ１０７から管理デバイスの情報を取得するタスクが登録されているとデバイス管理部３０２が判定した場合は、Ｓ７０３へ進む。

そして、Ｓ７０３で、Ｓ７０１において、子サーバ１０７から取得した処理タスク情報の実行タイミングの情報をデバイス管理部３０２が取得する。

次に、Ｓ７０４で、Ｓ７０３において取得した処理タスク情報における実行タイミングの情報を参照し、タスク実行タイミングか否かの判定をデバイス管理部３０２が行う。

ここで、デバイス管理部３０２が処理実行タイミングでないと判定した場合は、本処理を終了する。そして、次回のスケジューラプログラムの起動時に備える。

一方、Ｓ７０４で、タスク処理を実行すべきタイミングであるとデバイス管理部３０２が判定した場合は、Ｓ７０５へ進む。

次に、Ｓ７０５で、図８に示したターゲット情報を参照し、管理デバイスの情報を取得する子サーバ１０７のリストをデバイス管理部３０２が取得する。ここでは、ターゲットに子サーバが１つしか情報が格納されていないが、複数の子サーバの情報を格納する事が可能である。

また、格納されている情報は、ＩＰアドレスなど以降の通信処理においてターゲットを特定するための情報が格納されているものとする。

次に、Ｓ７０６で、親サーバ１０２における子サーバとの通信処理部３０４および、子サーバ１０７における親サーバとの通信処理部４０５の間において通信を確立し、子サーバ１０７に対して管理しているデバイスのリスト情報の取得を要求する。

ここで、親サーバ１０２と子サーバ１０７との間における通信は、Ｗｅｂ Ｓｅｒｖｉｃｅなどを用いるのが一般的である。

しかしながら、親サーバ１０２と子サーバ１０７間における通信およびデータ交換が可能であれば、そのプロトコルや方法に関しては何でも良い。

次に、Ｓ７０７で、親サーバ１０２が子サーバ１０７から管理対象デバイスの情報を取得し、デバイス管理部３０２が取得した情報を親サーバ１０２のＲＡＭ上や、ＨＤ２１０などの記憶領域に一時的に格納する。

なお、子サーバ１０７の管理対象デバイスに関する情報を取得する際には、親サーバ１０２と子サーバ１０７との間の通信プロトコルで送信可能な形式にデータ変換されており、受信時に元の形式に戻される。

次に、Ｓ７０８で、Ｓ７０７において取得した子サーバ１０７の管理デバイス情報を、親サーバ１０２の管理しているデバイス情報に追加する処理をデバイス管理部３０２が行う。

図９は、図１に示した親サーバ１０２で管理されるデバイス情報の一覧を説明する図である。本例は、親サーバ１０２において、子サーバ１０７の管理対象としているデバイス情報を追加したテーブルの例である。

図９において、９０１はデバイス名で、探索処理によってネットワーク下に接続されているデバイスのデバイス名を格納する。９０２はＩＰアドレスで、探索されたデバイスのＩＰアドレスを格納する。

９０３はＭＡＣアドレスで、探索されたデバイスのＭＡＣアドレスを格納する。９０４は現管理サーバで、デバイス名９０１に格納されているＤｅｖ１〜６（Ｄｅｖ４〜６は１０８〜１１０に対応する）のデバイスを現在管理しているサーバ先の情報を格納する。

９０５は親サーバ参照時の属性で、図７に示したＳ７０８の追加処理で、子サーバ１０７が管理していたデバイス情報を追加した状態を示している。現管理サーバ９０４の情報を参照すると、Ｄｅｖ４〜６の現管理サーバが、"子サーバ"になっている事から、子サーバ１０７より取得した管理デバイスの情報である事が分かる。

また、親サーバ参照時の属性９０５を見ると、Ｄｅｖ６に関する情報が図５で示したユーザインタフェース５０１でチェックボックスが設定されておらず、子サーバ１０７が未だ管理しているため読取専用属性である事が分かる。

このように本実施形態では、子サーバ１０７が管理している複数のデバイスのデバイス情報を一括して親サーバ１０２の管理下におくことも可能である。さらには、子サーバ１０７が管理している複数のデバイスのうち、一部のデバイスのデバイス情報を一括して親サーバ１０２の管理下におくことも可能である。

このように親サーバ１０２の管理デバイス情報にＳ７０５において取得した子サーバ１０７の管理デバイス情報を追加した後、Ｓ７０９へ進む。

そして、Ｓ７０９では、Ｓ７０５において取得した子サーバの情報リストから、更にデバイス情報を取得すべき子サーバがあるかどうかの判定をデバイス管理部３０２が行う。

ここで、更に取得を行うべきターゲットの子サーバがあるとデバイス管理部３０２が判定した場合は、Ｓ７０６へ戻り、上述の処理を繰り返し、ターゲットとなる子サーバがないとデバイス管理部３０２が判定した場合は、本処理を終了する。そして、次回のスケジューラプログラムの起動時に備える。

図７に示した処理を終了した直後における、親サーバ１０２で表示されるデバイス一覧画面の例を図８に示す。

図１０、図１１は、図１に示した親サーバ１０２で表示されるデバイス一覧画面の例を示す図である。本例は、親サーバ１０２が、子サーバ１０７が管理すべきデバイスの情報であって、管理対象外のデバイスのデバイス情報を表示した例である。

図１０において、１８０１は管理サーバで、図９に示した親サーバが管理するデバイス情報の現管理サーバ９０４を元に表示される。

ここで、現管理サーバ９０４の項目を参照し、自サーバ、すなわち親サーバである場合は、対象デバイスの情報を通常表示し、自サーバの管理下である事を明示的に示している。

一方、現管理サーバ９０４の情報が子サーバである場合は、子サーバより取得した直後である事を明示的に示すため、現管理サーバ９０４の情報をＣＲＴ２０７上でグレー表示する制御をＣＰＵボード２９３が行う。

次に、図１１に示す画面は、図１０に示した表示内容を更新、すなわち一覧情報に表示しているデバイスから情報の再取得を行った直後の画面例である。１０９１は管理サーバで、管理サーバ１８０１の状態が読取専用に更新されている状態を示す。

図１２は、本実施形態を示す管理装置における第２のデータ処理手順の一例を示すフローチャートである。本例は、親サーバ１０２が子サーバ１０７の管理対象デバイス情報を再取得してデバイス情報を更新する処理例である。なお、Ｓ２００１〜Ｓ２００８は各ステップを示し、各ステップは、図２に示したＣＰＵボード２０３のＣＰＵがＲＡＭにデバイス管理アプリケーション３０１をロードして実行することで実現される。

Ｓ２００１で、図９に示す現管理サーバ９０４に設定される子サーバから管理対象となるデバイス情報をデバイス管理部３０２が取得するとともに、親サーバ１０２の管理対象デバイスに加えたデバイス情報を親サーバ１０２の外部記憶領域より取得する。

次に、Ｓ２００２で、参照している管理対象となるデバイスの親サーバ参照時の属性９０５の情報が読取専用属性か否かの判定をデバイス管理部３０２が行う。ここで、読取専用であるとデバイス管理部３０２が判定した場合はＳ２００７へ進む。

一方、Ｓ２００２で、読取専用でないとデバイス管理部３０２が判定した場合、すなわち親サーバ１０２において管理対象のデバイスであると判断した場合は、Ｓ２００３へ進む。

そして、Ｓ２００３で、Ｓ２００２において参照しているデバイスより、デバイス情報の取得をデバイス管理部３０２が行う。

次に、Ｓ２００４で、対象となるデバイスよりデバイス情報の取得が成功したかどうかの判定をデバイス管理部３０２が行う。ここで、デバイス情報の取得が成功したとデバイス管理部３０２が判定した場合はＳ２００５へ進み、情報取得に失敗したデバイス管理部３０２が判定した場合は、Ｓ２００７へ進む。

そして、Ｓ２００５で、デバイス情報の取得が成功したデバイスの、現管理サーバ９０４の情報を参照し、現管理サーバ９０４が子サーバであるか否かをデバイス管理部３０２が判定する。ここで、現管理サーバ９０４が子サーバであるとデバイス管理部３０２が判定した場合はＳ２００６へ進み、現管理サーバ９０４が親サーバであると判定した場合はＳ２００７へ進む。

そして、Ｓ２００６で、デバイス管理部３０２が現管理サーバ９０４の情報を親サーバに変更する。

次に、Ｓ２００７で、上記処理を実行していない管理対象デバイスがあるかどうかの判定をデバイス管理部３０２が行う。

ここで、未処理のデバイスがあるとデバイス管理部３０２が判定した場合は、Ｓ２００２に進み、上述の処理ステップを繰り返し、未処理のデバイスが無いとデバイス管理部３０２が判定した場合はＳ２００８へ進む。

そして、Ｓ２００８で、デバイス管理部３０２は、デバイス情報の表示の更新を行い、本処理を終了。

ここで、親サーバ１０２は、デバイス情報として現管理サーバ９０４が親サーバになっているデバイスは、親サーバの管理対象であることを示すために、デバイス情報を通常表示する。

一方、現管理サーバ９０４の情報が子サーバのままのものは、デバイス情報をグレー表示する（図１０中では、網かけで示す）。この際、親サーバ１０２は、読取専用属性のものに関しては、図１１の管理サーバ１９０１に示すように、明示的に読取専用であることを表示する。

図１３は、図１に示した親サーバ１０２で管理されるデバイス情報の一覧を説明する図である。本例は、図９に示した一覧に対して、図１２に示す処理を実行した後の図１１に示す表示画面に対応するデバイス情報の一覧である。

図１４は、本実施形態を示す管理装置における第３のデータ処理手順の一例を示すフローチャートである。本例は、親サーバ１０２から管理対象のデバイスの情報を取得した子サーバ１０７側において、子サーバ１０７側での管理情報の更新処理例である。なお、Ｓ１００１〜Ｓ１００９は各ステップを示し、各ステップは、図２に示した子サーバ１０７のＣＰＵボード２０３のＣＰＵがＲＡＭにデバイス管理アプリケーション３０１をロードして実行することで実現される。

まず、Ｓ１００１で、親サーバ１０２より、子サーバ１０７に対してアクセス要求があったことを、親サーバとの通信処理部４０５が検知したら、Ｓ１００２へ進む。

そして、Ｓ１００２では、子サーバ１０７の管理対象デバイスの情報取得要求を行った親サーバ１０２の子サーバとの通信処理部３０４と、親サーバとの通信処理部４０５間における通信を確立するための前処理を実行し、その後の処理に備える。

ここで、親サーバ１０２と子サーバ１０７の通信処理は、Webserviceを使用するのが一般的であるが、他の通信方法を使用してデータ交換を行ってもよい。

次に、Ｓ１００３では、親サーバ１０２からの要求の種別をデバイス管理部４０２が判定する。そして、Ｓ１００４では、Ｓ１００３において取得した親サーバ１０２からの取得要求が、子サーバ１０７における管理対象となるデバイスの情報を取得する要求であるか否かの判断をデバイス管理部４０２が行う。ここで、デバイス管理部４０２が子サーバ１０７における管理対象のデバイス情報を取得する要求であると判定した場合は、Ｓ１００５へ進む。そして、Ｓ１００５で、子サーバ１０７における管理対象のデバイスの情報を取得する要求でないとデバイス管理部４０２が判定した場合は、本処理を終了する。

次に、Ｓ１００５で、デバイス管理部４０２は、図６に示した子サーバにおける管理対象デバイスに関するデバイス情報を、子サーバ１０７の外部記憶領域（ＨＤ２１０）より取得し、後述の処理ステップに備えてＲＡＭ上に展開を行う。

次に、Ｓ１００６で、Ｓ１００５においてＨＤ２１０から取得した子サーバにおける管理対象となるデバイスのデバイス情報を親サーバ１０２に対して送信する際に送信可能なデータ形式の情報に変換する。

そして、Ｓ１００７で、Ｓ１００６において送信可能な形式に変換された子サーバにおける管理対象となるデバイスのデバイス情報を、親サーバとの通信処理部４０５が親サーバ１０２に対して送信する。

次に、Ｓ１００８で、図６に示した子サーバ１０７が管理するデバイス情報の中の、親サーバ参照時の属性情報エリアに"親サーバに任せる"に設定されているデバイスがあるかどうかデバイス管理部４０２が判定する。

ここで、親サーバ１０２に管理を任せると設定されているデバイスが存在するとデバイス管理部４０２が判定した場合は、Ｓ１００９へ進む。

一方、Ｓ１００８で、親サーバ１０２に管理を任せるデバイスが存在しないとデバイス管理部４０２が判定した場合は、全てのデバイスを子サーバ１０７が継続して管理を行う設定になっているものと判定して、本処理を終了する。

次に、Ｓ１００９で、図６に示した子サーバ１０７における管理対象のデバイス情報から、親サーバ１０２に任せる、すなわち子サーバ１０７における管理を放棄したデバイスの情報をデバイス管理部４０２が削除して、本処理を終了する。

これにより、子サーバと親サーバで重複管理されるデバイスの情報は、親サーバからは読取専用属性を設ける事で、また親サーバへ管理を委譲したデバイスの情報は子サーバから削除する事により、設定系の矛盾を解消することが可能となる。

図１５は、図１に示した子サーバ１０７が管理するデバイス情報の一例を示す図である。本例は、図６に示した子サーバ１０７が管理するデバイス情報から、Ｓ１００９を実行した後、デバイス情報管理部４０３が参照するデバイス情報である。

尚、親サーバ１０２に管理を任せたデバイスのデバイス情報をデバイス管理部４０２が削除する際には、親サーバ１０２からのデバイス管理の設定が完了したという旨の完了通知を受け取ったタイミングで削除処理を行うといった構成としても良い。これにより、親子サーバ間で、デバイス情報の委譲を確実に行える。

ここで、本実施形態において、子サーバ１０７から定期的にデバイス情報を親サーバ１０２に送信してもよい。

また、子サーバ１０７からＳ１００７で送信するデバイス情報は、デバイスを特定するための特定情報（デバイス名など）と管理するのが親子サーバのどちらかを特定するための情報であってもよい。

例えば、子サーバ１０７が管理するデバイス情報を送る場合は、デバイス名やデバイスの設置場所などの情報のみを送信して、親サーバ１０２では不要な管理のために必要になる情報を送らないようにしてもよい。

もしくは、子サーバ１０７はデバイスに関する全ての情報を送信して、親サーバ１０２側で、デバイス情報の中で閲覧のみ可能にするか、情報の更新や削除、設定情報の配信などの管理まで可能にするかを制御するようにしてもよい。

次に、図５に示したＵＩ５０１において、"親サーバに管理を任せる"のチェックを付けず、子サーバ１０７で継続的に管理を行う指定を行ったデバイスを、親サーバ１０２へ管理を譲渡すべきかどうかの判定処理について説明する。

まず、図５に示したＵＩ５０１の"親サーバに管理を任せる"のチェックボックスに対してチェックを付けなかった場合、子サーバ１０７の管理者によって、子サーバ１０７により継続的に管理を行うデバイスであると判断される。

一方、チェックボックスにチェックを付けたデバイスは、親サーバが管理すべきデバイスであると判断できる。

しかしながら、子サーバにおいて継続的に独自の管理を行う、すなわち親サーバから集中管理させないデバイスであるか否かを再度判断するためには、子サーバにおいて、設定系の処理がなされているか否かが一つの判断材料となる。

ここで、設定系の処理とは、デバイスの設定配信タスク、デバイスの再起動タスク、デバイスへの宛先表配信など、管理対象のデバイスに対して書込みが発生するタスクや、対象デバイスの挙動に影響のあるタスクを設定系の処理と位置付ける。

子サーバ１０７内には、ＨＤ２１０などの外部記憶装置内に、タスク情報管理部４０４が参照するための、図１６に示すようなタスク種別情報判定テーブルがインストール時などにあらかじめ格納されているものとする。

図１６は、図２に示した子サーバ１０７のＨＤ２１０に格納されるタスク種別情報判定テーブルの一例を示す図である。本例は、タスク種別として、デバイス探索、設定配信、再起動、エラー監視、印刷枚数取得、印刷リソース配信、アドレス帳配信等が設定された例を示す。

図１７は、図２に示した子サーバ１０７が備えるＣＲＴ２０７に表示されるユーザインタフェースの一例を示す図である。本例は、親サーバへ委譲する猶予期間を設定するためのユーザインタフェース例である。

より具体的には、タスク情報管理部４０４に対して、過去に実行された設定系のタスクがある一定期間を超えた場合に、子サーバ１０７での継続管理を見直すタイミングであると、子サーバ１０７の管理者に対してメッセージを表示するまでの猶予期間を設定するＵＩの例である。

図１７において、ＳＢはスピンボックスで、管理者がマウス２０９を操作することで、親サーバにデバイス情報を委譲する猶予期間（現在表示では、「３０」日）が設定される。ＢＴ１はＯＫボタンで、設定した猶予期間を確定するためのボタンとして機能する。ＢＴ２はキャンセルボタンで、設定した猶予期間を取り消するためのボタンとして機能する。

したがって、図１７に示す表示画面の状態では、閾値として「３０日間」設定系のタスクが子サーバ１０７において実行されなかった場合に、親サーバ１０２へ管理を委譲するメッセージを子サーバ１０７で表示するという設定である。なお、猶予期間を設定する期間の上限、下限等に関してはここでは特に限定はない。

図１８は、図４に示した子サーバ１０７のタスク情報管理部４０４が参照するタスクの実行履歴情報テーブルの一例を示す図である。本例は、図４に示した子サーバ１０７のデバイス管理部４０２が過去において実行を行ったタスクの実行履歴情報テーブルの例である。

図１８には、過去に実行したタスクに関するタスク名称、実行タスクの種別に関する情報、実行タスクの実行日に関する情報、タスク実行時のターゲットデバイスに関する情報などが格納されている。もちろんここに示した情報は一例であり、これ以外の情報を含んでいても構わない。

これら上述した図１６〜図１８に示した情報を用いて、子サーバ１０７で継続管理を行うデバイスの管理を、親サーバ１０２へ委譲すべきかどうかの判定を行う処理の流れを、図１９を用いて説明する。

図１９は、本実施形態を示す管理装置における第４のデータ処理手順の一例を示すフローチャートである。本例は、子サーバ１０７で管理しているデバイスを、親サーバ１０２へ委譲すべきかどうかの判定を行う処理例である。

なお、Ｓ１５０１〜Ｓ１５１０は各ステップを示し、各ステップは、図２に示した子サーバ１０７のＣＰＵボード２０３のＣＰＵがＲＡＭにデバイス管理アプリケーション４０１をロードして実行することで実現される。

Ｓ１５０１で、デバイス情報管理部４０３が子サーバ１０７で図６に示す管理対象となっているデバイスのデバイス情報を取得する。Ｓ１５０２で、図１７に示した猶予期間を設定するためのＵＩから、子サーバ１０７の管理者が設定を行った、設定系のタスクが実行されなかった場合に、親サーバ１０２へデバイスの管理を委譲するための猶予期間の設定情報を取得する。なお、上記制御邸情報はタスク情報管理部４０４がＨＤ２１０から読み出す。

Ｓ１５０３では、タスク情報管理部４０４が、図１８に示した子サーバ１０７におけるタスク実行履歴情報テーブルの情報を取得する。

次に、Ｓ１５０４では、Ｓ１５０１で取得した管理対象デバイスのデバイス情報を順次参照し、現在参照しているデバイスの図６に示した親サーバ参照時の属性６０５が「読取専用」であるか否かの判定をデバイス管理部４０２が行う。

ここで、デバイス管理部４０２が「読取専用」であると判定した場合は、Ｓ１５０５へ進み、「読取専用」でない、すなわち親サーバへ任せる属性であると判定した場合は、Ｓ１５０９へ進む。

そして、取得した子サーバにおけるタスク実行履歴情報と、Ｓ１５０２で取得した猶予期間に関する情報および図１６に示したタスク種別情報判定テーブルの内容をデバイス管理部４０２が比較を行う。

その後、Ｓ１５０５で、猶予期間内に設定系のタスクが実行されたか否かの判定をデバイス管理部４０２が行う。

ここで、図１６〜図１８の例を用いて説明を行う。

２００７年５月３０日までが猶予期間内に設定系のタスクが実行された事になり、２００７年０５月３１日からは猶予期間に設定系のタスクが実行されていないとデバイス管理部４０２により判定される事になる。

ここで、猶予期間内に設定系のタスクが実行されているとデバイス管理部４０２により判定された場合は、Ｓ１５１０へ進み、猶予期間内に設定系のタスクが実行されていないとデバイス管理部４０２により判定された場合はＳ１５０６へ進む。

一方、Ｓ１５１０では、図１８に示した子サーバにおけるタスク実行履歴情報から、猶予期間内に実行された設定系タスクのターゲットデバイスに、Ｓ１５０４で参照しているデバイスが含まれているか否かの判定をデバイス管理部４０２が行う。

ここで、設定系のタスクが実行されているとデバイス管理部４０２により判定された場合は、子サーバ１０７において継続的に管理されているデバイスであるため、特に処理を行わず、Ｓ１５０９へ進む。

一方、Ｓ１５１０で、判定の結果設定系のタスクが実行されていないとデバイス管理部４０２により判定された場合は、子サーバ１０７において継続的に管理されていないデバイスであるため、Ｓ１５０６へ進む。

次に、Ｓ１５０６で、Ｓ１５０４において参照しているデバイスに対して、親サーバ１０２へ管理を委譲するかどうかを示す、図２０に示すような確認用メッセージの表示をデバイス管理部４０２により子サーバ１０７のＣＲＴ２０７に行う。

ここで、図２０に示した確認用メッセージに対して、子サーバ管理者が管理を委譲するかどうかを選択するため、マウス２０９を操作してボタンＢＴ２１１又はボタンＢＴ２１２のいずれかを選択する。

図２０は、本実施形態を示す管理装置で表示されるユーザインタフェースの一例を示す図である。本例は、子サーバ管理者がデバイスの管理を親サーバに委譲するかどうかを確認するためのメッセージを表示する画面に対応する。

これにより、ユーザインタフェースにより容易に管理サーバの選択を行うことが可能になる。と同時に、一定期間設定タスクが実行されていないデバイスに関しては、管理サーバの委譲を促すメッセージを表示する事で、実運用に合わせたサーバにより管理を行う事が可能になる。

次に、Ｓ１５０７で、図２０に示した確認用メッセージに対して、子サーバ管理者が図２０に示す画面において、「はい」に対応するボタンＢＴ２１１を選択しているかどうかを判断する。すなわち、親サーバ１０２に管理権限を委譲するかどうかを判断する。

ここで、ボタンＢＴ２１１が選択されたと判定した場合、すなわち、親サーバへ管理を委譲するとデバイス管理部４０２が判定した場合は、Ｓ１５０８へ進む。

一方、図２０において、「いいえ」に対応するボタンＢＴ２１２を選択した場合、すなわち親サーバへ管理を委譲しないとデバイス管理部４０２が判定した場合はＳ１５０９へ進む。

次に、Ｓ１５０８で、Ｓ１５０４において参照しているデバイスの親サーバ参照時の属性６０５の内容を、デバイス管理部４０２が「読取専用」から「親サーバに任せる」に変更する。

図２１は、図１に示した子サーバ１０７で管理されるデバイス情報の一覧を説明する図である。本例は、Ｓ１５０８の実行後、すなわち、デバイス名Ｄｅｖ６の親サーバ参照時の属性６０５の内容が「読取専用」から「親サーバに任せる」に変更されたデバイス情報の一覧に対応する。

次に、Ｓ１５０９では、Ｓ１５０１で取得した、子サーバ管理対象デバイスに関する情報テーブルの中の、全ての管理対象デバイスに関してチェックを行ったか否かの判定をデバイス管理部４０２が行う。

ここで、未チェックのデバイスがあるとデバイス管理部４０２が判定した場合は、Ｓ１５０４へ進み上述の処理を繰り返す。

一方、Ｓ１５０９で、全てのデバイスに対してチェックを実施したとデバイス管理部４０２が判定した場合には、本処理を終了する。

なお、本処理はデバイス管理アプリケーション４０１によって、１日に１回程度実行されるように設定されていれば良い。

次に、図２２を用いて、親サーバの管理対象デバイスの中に読取専用属性のデバイスが含まれた場合の、親サーバにおけるタスク実行処理の流れを説明する。

図２２は、本実施形態を示す管理装置における第５のデータ処理手順の一例を示すフローチャートである。本例は、親サーバの管理対象デバイスの中に読取専用属性のデバイスが含まれた場合の、親サーバにおけるタスク実行処理例である。

なお、Ｓ２２０１〜Ｓ２２０６は各ステップを示し、各ステップは、図２に示した子サーバ１０７のＣＰＵボード２０３のＣＰＵがＲＡＭにデバイス管理アプリケーション３０１をロードして実行することで実現される。

まず、Ｓ２２０１で、デバイス管理部３０２が実行を開始したタスクの処理内容などに関するタスクに関する情報の取得を行う。

タスク種別及び実行内容に関しては、図１６に示したタスク種別情報判定テーブルが、親サーバにおけるデバイス管理アプリケーション３０１が参照可能な外部記憶領域となるＨＤ２１０などに格納されている。

次に、Ｓ２２０２では、図８に示したような親サーバに登録されている処理タスク情報テーブルから、該当タスクのターゲットとして登録されているデバイスの情報をデバイス管理部３０２が取得する。

次にＳ２２０３では、Ｓ２２０１で取得したタスクの種別が、ターゲットデバイスに対して設定を行うような設定系のタスクであるか否かの判定をデバイス管理部３０２が行う。

ここで、設定系のタスクであるとデバイス管理部３０２が判定した場合Ｓ２２０４へ進み、設定系のタスクでないとデバイス管理部３０２が判定した場合、すなわち情報取得系のタスクであると判定した場合は、Ｓ２２０５へ進む。

次に、Ｓ２２０４で、対象とするデバイスが読取専用属性であるか否かを、図１３に示した親サーバ管理対象デバイス管理リストの、親サーバ参照時の属性情報を参照し、ターゲットデバイスが読取専用属性であるか否かの判定をデバイス管理部３０２が行う。

次に、Ｓ２２０４で、ターゲットデバイスが「読取専用」属性であるとデバイス管理部３０２が判定した場合は、タスク処理を実行せずにＳ２２０６へ進む。

一方、Ｓ２２０４において、ターゲットデバイスが「読取専用」でないとデバイス管理部３０２が判定した場合は、Ｓ２２０５へ進み、ターゲットデバイスに対してタスク処理の実行を行う。そして、タスク処理実行後、Ｓ２２０６へ進む。

次に、Ｓ２２０６で、タスクのターゲットデバイスが他にもあるか否かのチェックをデバイス管理部３０２が行い、タスク未実行のデバイスがあるとデバイス管理部３０２が判定した場合は、Ｓ２２０２へ進み、上述の処理ステップを繰り返す。

一方、Ｓ２２０６で、全てのターゲットデバイスに対してタスク処理実行を行って、ターゲットデバイスがないとデバイス管理部３０２が判定した場合は、本処理を終了する。

以上の処理により、子サーバにおいて継続的にデバイスの管理を続行する場合は、親サーバには読取専用で存在情報を提供する事が可能となる。

また、親サーバへ管理を委譲した管理デバイスの情報は、親サーバがその管理デバイスの情報を取得後、子サーバの管理対象デバイスから削除される。

さらに、子サーバで継続管理されているデバイスでも、設定系のタスクが未実行の場合は管理の委譲を促すメッセージを表示することが可能となる。

〔第２実施形態〕
以下、図２３に示すメモリマップを参照して本発明に係るサーバで読み取り可能なデータ処理プログラムの構成について説明する。

図２３は、本発明に係るサーバで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

なお、特に図示しないが、記憶媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。

さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、各種プログラムをコンピュータにインストールするためのプログラムや、インストールするプログラムが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。

本実施形態における図７、図１２、図１４、図１９、図２２に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記憶媒体により、あるいはネットワークを介して外部の記憶媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。

以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記憶媒体を、システムあるいは装置に供給する。そして、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。

この場合、記憶媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

従って、プログラムの機能を有していれば、オブジェクトコード、インタプリタにより実行されるプログラム、ＯＳに供給するスクリプトデータ等、プログラムの形態を問わない。

プログラムを供給するための記憶媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＭＯ、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、磁気テープ、不揮発性のメモリカード、ＲＯＭ、ＤＶＤなどを用いることができる。

この場合、記憶媒体から読出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。

その他、プログラムの供給方法としては、クライアントコンピュータのブラウザを用いてインターネットのホームページに接続する。そして、該ホームページから本発明のコンピュータプログラムそのもの、もしくは、圧縮され自動インストール機能を含むファイルをハードディスク等の記録媒体にダウンロードすることによっても供給できる。また、本発明のプログラムを構成するプログラムコードを複数のファイルに分割し、それぞれのファイルを異なるホームページからダウンロードすることによっても実現可能である。つまり、本発明の機能処理をコンピュータで実現するためのプログラムファイルを複数のユーザに対してダウンロードさせるＷＷＷサーバやｆｔｐサーバ等も本発明の請求項に含まれるものである。

また、本発明のプログラムを暗号化してＣＤ−ＲＯＭ等の記憶媒体に格納してユーザに配布し、所定の条件をクリアしたユーザに対し、インターネットを介してホームページから暗号化を解く鍵情報をダウンロードさせる。そして、その鍵情報を使用することにより暗号化されたプログラムを実行してコンピュータにインストールさせて実現することも可能である。

また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけではない。例えばそのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行う。そして、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込ませる。その後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。

本発明の様々な例と実施形態を示して説明したが、当業者であれば、本発明の趣旨と範囲は、本明細書内の特定の説明に限定されるのではない。

本発明の本実施形態を示すデバイス管理システムの構成を説明するブロック図である。 図１に示すデバイス管理システムの構成を説明するブロック図である。 図１に示した親サーバにおけるソフトウエアモジュールの構成を説明する図である。 図１に示した子サーバにおけるソフトウエアモジュールの構成を説明する図である。 図１に示した子サーバのユーザインタフェースで表示されるデバイスリスト画面の一例を示す図である。 図１に示した子サーバで管理されるデバイス情報の一覧を説明する図である。 本実施形態を示す管理装置における第１のデータ処理手順の一例を示すフローチャートである。 図１に示した親サーバに登録されているタスク情報テーブルの一例を示す図である。 図１に示した親サーバで管理されるデバイス情報の一覧を説明する図である。 図１に示した親サーバで表示されるデバイス一覧画面の例を示す図である。 図１に示した親サーバで表示されるデバイス一覧画面の例を示す図である。 本実施形態を示す管理装置における第２のデータ処理手順の一例を示すフローチャートである。 図１に示した親サーバで管理されるデバイス情報の一覧を説明する図である。 本実施形態を示す管理装置における第３のデータ処理手順の一例を示すフローチャートである。 図１に示した子サーバが管理するデバイス情報の一例を示す図である。 図２に示した子サーバのＨＤに格納されるタスク種別情報判定テーブルの一例を示す図である。 図２に示した子サーバが備えるＣＲＴに表示されるユーザインタフェースの一例を示す図である。 図４に示した子サーバのタスク情報管理部が参照するタスクの実行履歴情報テーブルの一例を示す図である。 本実施形態を示す管理装置における第４のデータ処理手順の一例を示すフローチャートである。 本実施形態を示す管理装置で表示されるユーザインタフェースの一例を示す図である。 図１に示した子サーバで管理されるデバイス情報の一覧を説明する図である。 本実施形態を示す管理装置における第５のデータ処理手順の一例を示すフローチャートである。 本発明に係るサーバで読み取り可能な各種データ処理プログラムを格納する記憶媒体のメモリマップを説明する図である。

符号の説明

１０２ 親サーバ
１０３〜１０５、１０８，１０９、１１０ デバイス
１０７ 子サーバ

Claims (16)

1. 第１のサーバと、当該第１のサーバとは異なる第２のサーバを含むデバイス管理システムであって、
   前記第１のサーバは、
   前記第１のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第１の管理手段を備え、
   前記第２のサーバは、
   前記第２のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第２の管理手段と、
   前記第１のサーバの管理対象であり、前記第２のサーバではデバイス情報の更新または削除を行えない管理対象外のデバイスのデバイス情報を表示する表示手段とを備えることを特徴とするデバイス管理システム。
2. 第１のサーバと、当該第１のサーバとは異なる第２のサーバを含むデバイス管理システムにおけるデバイス管理方法であって、
   前記第１のサーバは、
   前記第１のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第１の管理ステップを備え、
   前記第２のサーバは、
   前記第２のサーバの管理対象のデバイスのデバイス情報の更新または削除を行う第２の管理ステップと、
   前記第１のサーバの管理対象であり、前記第２のサーバではデバイス情報の更新または削除を行えない管理対象外のデバイスのデバイス情報を表示する表示ステップとを備えることを特徴とするデバイス管理方法。
3. 通信回線を介して通信可能なデバイスを識別するための識別情報を保持する保持手段と、
   前記保持手段により保持されている識別情報により識別されるデバイスの中で、自身の管理対象のデバイスのデバイス情報の更新または削除を行う管理手段と、
   自身の管理対象のデバイスと他のサーバの管理対象のデバイスとを特定可能に、前記保持手段により保持された識別情報を当該他のサーバに送信する送信手段とを備えることを特徴とするサーバ。
4. 前記送信手段による前記識別情報の送信後、前記他のサーバで管理すべきデバイスの識別情報を前記保持手段から削除する削除手段を更に備えることを特徴とする請求項３に記載のサーバ。
5. 前記送信手段は、前記保持手段により保持される識別情報で識別されるデバイスの中で、前記管理手段によるデバイス情報の更新または削除の行なわれない期間が閾値を超えた場合、当該デバイスを前記他のサーバの管理対象として特定可能に、前記識別情報の送信を行うことを特徴とする請求項３または４に記載のサーバ。
6. 前記保持手段により保持される識別情報で識別されるデバイスの中で、前記管理手段によるデバイス情報の更新または削除の行なわれない期間が閾値を超えた場合、当該デバイスを前記他のサーバの管理対象とするか否かを確認するための画面を表示する表示手段を備えることを特徴とする請求項５に記載のサーバ。
7. 通信回線を介して通信可能なデバイスを識別するための識別情報を保持する保持手段を備えるサーバにおけるデバイス管理方法であって、
   前記保持手段により保持されている識別情報により識別されるデバイスの中で、自身の管理対象のデバイスのデバイス情報の更新または削除を行う管理ステップと、
   自身の管理対象のデバイスと他のサーバの管理対象のデバイスとを特定可能に、前記保持手段により保持された識別情報を当該他のサーバに送信する送信ステップとを備えることを特徴とするデバイス管理方法。
8. 前記送信ステップによる前記識別情報の送信後、前記他のサーバで管理すべきデバイスの識別情報を前記保持手段から削除する削除ステップを更に備えることを特徴とする請求項７に記載のデバイス管理方法。
9. 前記送信ステップは、前記保持手段により保持される識別情報で識別されるデバイスの中で、前記管理ステップによるデバイス情報の更新または削除の行なわれない期間が閾値を超えた場合、当該デバイスを前記他のサーバの管理対象として特定可能に、前記識別情報の送信を行うことを特徴とする請求項７または８に記載のデバイス管理方法。
10. 前記保持手段により保持される識別情報で識別されるデバイスの中で、前記管理ステップによるデバイス情報の更新または削除の行なわれない期間が閾値を超えた場合、当該デバイスを前記他のサーバの管理対象とするか否かを確認するための画面を表示する表示ステップを備えることを特徴とする請求項９に記載のデバイス管理方法。
11. 他のサーバから当該他のサーバが保持するデバイスを識別するための識別情報を受信する受信手段と、
    前記受信手段により受信した識別情報で識別されるデバイスにおいて、前記識別情報とともに受信する前記他のサーバの管理対象のデバイスを特定するための属性情報に基づき、前記他のサーバの管理対象と特定されたデバイスのデバイス情報に対しては更新または削除を行わず、自身の管理対象のデバイスのデバイス情報に対しては更新または削除を行う管理手段と、
    前記受信手段により受信した識別情報で識別されるデバイスのデバイス情報を表示する表示手段とを備えることを特徴とするサーバ。
12. 前記デバイス情報は前記識別情報を含み、前記受信手段は前記他のサーバからデバイス情報を受信することを特徴とする請求項１１に記載のサーバ。
13. 他のサーバから当該他のサーバが保持するデバイスを識別するための識別情報を受信する受信ステップと、
    前記受信ステップにより受信した識別情報で識別されるデバイスにおいて、前記識別情報とともに受信する前記他のサーバの管理対象のデバイスを特定するための属性情報に基づき、前記他のサーバの管理対象と特定されたデバイスのデバイス情報に対しては更新または削除を行わず、自身の管理対象のデバイスのデバイス情報に対しては更新または削除を行う管理ステップと、
    前記受信ステップにより受信した識別情報で識別されるデバイスのデバイス情報を表示する表示ステップとを備えることを特徴とするデバイス管理方法。
14. 前記デバイス情報は前記識別情報を含み、前記受信ステップは前記他のサーバからデバイス情報を受信することを特徴とする請求項１３に記載のデバイス管理方法。
15. 請求項７〜１０のいずれか１項に記載のデバイス管理方法をコンピュータに実行させることを特徴とするプログラム。
16. １３または１４に記載のデバイス管理方法をコンピュータに実行させることを特徴とするプログラム。

Images