JP2019164622A - 管理装置、管理装置の制御方法およびプログラム - Google Patents

Abstract

【課題】不要な多重管理を抑制しつつ、例外処理として有効なネットワークを利用できる管理装置を提供する。【解決手段】複数のエージェントとの通信を用いて複数のデバイスを管理する管理装置１０１は、各エージェントからのデバイスに対する探索結果に基づいてデバイスを担当するエージェントを決定する決定手段と、決定したデバイスを担当するエージェントに対してデバイスを処理対象として含む処理の依頼を実行する実行手段とを備え、複数の探索結果から同一のデバイスを検出し、当該検出デバイスを含む探索結果の送信元である複数のエージェントの中から決定した第１のエージェントに対する依頼に応じた処理が失敗した場合、検出デバイスを含む探索結果の送信元である複数の管理エージェントの中から第１のエージェントとは異なる第２のエージェントを決定して検出デバイスを処理対象に含む処理の依頼を実行する。【選択図】図８

Description

本発明は、管理装置、管理装置の制御方法およびプログラムに関する。

ネットワーク接続あるいはローカル接続されたデバイスを分散管理（監視）する管理システムがある。管理システムには、デバイスの管理を行う管理サーバが複数配置され、１台の親管理サーバが複数台の子管理サーバの設定を統括管理する。各子管理サーバは、自装置が属するサブネット内のデバイスを管理する。親管理サーバは、子管理サーバから各子管理サーバが管理しているデバイスの各種情報を取得し、各種情報をＵＩで表示する。特許文献１は、顧客のネットワーク環境においてデバイスを管理する子管理サーバと、子管理サーバからデバイスの利用状況などの情報を受信する管理サーバを含む管理システムにおいて、管理エージェントを追加導入できる構成を開示している。

ここで、デバイスの中には、ネットワークを複数動作させるものがある。例えば、有線ＬＡＮカードの二枚差しや、有線ＬＡＮと無線ＬＡＮの同時動作が可能なデバイスである。１台のデバイスが有する複数のネットワークは、それぞれ異なるアドレス（例えば、ＩＰアドレス、ＭＡＣアドレス）を有するため、異なるサブネットワークから利用可能に構成される場合が多い。そのため、子管理サーバがネットワークごとのアドレスでデバイスを特定する場合は、複数のアドレスを有する１台のデバイスを、異なるサブネットワークにある複数の子管理サーバが重複して探索してしまい、多重管理を行ってしまう恐れがある。特許文献１では、現在の子管理サーバで通信を行えないデバイスに対して子管理サーバを追加するため、１台のデバイスの管理を１台の子管理サーバで行うことができる。

特開２０１６−０７６１６１号公報

一方で、複数のアドレスを有する１台のデバイスを異なるネットワークにある複数の子管理サーバが重複して管理してる場合には、片方のネットワークだけ不調となっても、他方の正常なネットワークを利用して管理を続けることができる。しかしながら、特許文献１では、１台のデバイスに対して１台の子管理サーバしか対応していないため、片方のネットワークだけ不調の場合に、正常な他方のネットワークから処理を行うことができない。

本発明は、不要な多重管理を抑制しつつ、例外処理として有効なネットワークを利用できる管理装置を提供することを目的とする。

上記課題を解決するために、本発明の管理装置は、複数のエージェントとの通信を用いて、複数のデバイスを管理する管理装置であって、各エージェントからの管理対象のデバイスに対する探索結果を受信する受信手段と、前記探索結果に基づいて、デバイスを担当するエージェントを決定する決定手段と、デバイスを処理対象として含む処理に関するタスクを実行する際に、前記決定手段により決定されたデバイスを担当するエージェントに対して、前記処理の依頼を実行する実行手段と、を備える。前記決定手段は、複数の探索結果から同一のデバイスを検出した場合、当該検出デバイスを含む探索結果の送信元である複数のエージェントの中から、前記検出デバイスを担当する第１のエージェントを決定し、前記実行手段は、前記第１のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行し、前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合に、前記決定手段は、前記検出デバイスを含む探索結果の送信元である複数の管理エージェントの中から、前記第１のエージェントとは異なる第２のエージェントを決定し、前記実行手段は、前記第２のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行する。

本発明によれば、不要な多重管理を抑制しつつ、例外処理として有効なネットワークを利用できる管理装置を提供することができる。

デバイス管理システムの構成を示す図である。 管理装置等のハードウェア構成の一例を示す図である。 管理装置の構成図の一例を示す図である。 管理エージェントの構成図の一例を示す図である。 管理装置のタイマー呼び出し動作を示すフローチャートである。 管理装置の予約タスク開始処理を示すフローチャートである。 デバイス管理システムの要求処理のシーケンスを示す図である。 管理装置のサブタスク実行結果受信処理を示すフローチャートである。 管理装置のデバイス情報を示す図である。 管理装置のデバイス情報更新処理を示すフローチャートである。 管理装置のデバイスリストを表示するＵＩの一例である。 管理装置のタスクログを表示するＵＩの一例である。

（第１実施形態）
図１は、第１実施形態におけるデバイス管理システムの構成を示す図である。デバイス管理システムは、親管理サーバである管理装置１０１、子管理サーバである管理エージェントアプリケーション（以下、エージェント）１０３〜１０５を備える。また、デバイス管理システムは、データベース１１２を備えていてもよい。デバイス管理システムが管理する対象となるデバイスが、デバイス１０９〜１１５である。

管理装置１０１は、エージェント１０３〜１０５を介してデバイス１０９〜１１５の管理を集中的に行う管理装置である。管理装置１０１は、サーバ装置の他、サーバ装置を含むデータセンターにより提供されたリソースを利用した仮想マシンにより実現されてもよいし、アプリケーションにより実現されてもよい。データベース１１２は、管理装置１０１により管理されるデータを格納するデータベースである。

エージェントは、管理装置１０１に対して１つ以上配置され、各エージェントは１つ以上のデバイスに接続され、各デバイスを管理する。本実施形態の各エージェント１０３〜１０５は、管理装置１０１と連携し、管理装置１０１からの指示に基づいてデバイス１０９〜１１５を管理し、管理結果を管理装置１０１に送信する。管理結果を各エージェント１０３〜１０５から受信した管理装置１０１は、管理結果を必要に応じてデータベース１１２に格納する。また、管理装置１０１は、各エージェント１０３〜１０５と各デバイス１０９〜１１５を紐づけて管理する。本実施形態では、エージェント１０３は、デバイス１０９およびデバイス１１０と紐付けられている。エージェント１０４は、デバイス１１１〜デバイス１１３と紐付けられている。エージェント１０５は、デバイス１１４およびデバイス１１５と紐付けられている。エージェント１０３〜１０５は、例えば、管理エージェントプログラムがインストールされた、管理エージェントとして機能するコンピュータ等の情報処理装置やサーバである。また、各エージェントは、管理対象のデバイスの探索を行う際のネットワーク範囲、プロトコル、対象となる機種の少なくともいずれかを含む条件の少なくとも一部の設定がそれぞれ相違している。デバイス１０９〜デバイス１１５は、管理装置１０１により管理される、例えば、情報処理装置、画像形成装置などのデバイスである。

管理装置１０１と各エージェント１０３〜１０５は、ネットワーク１０２を介して接続されている。エージェント１０３は、デバイス１０９およびデバイス１１０と、ネットワーク１０６を介して接続されている。エージェント１０４は、デバイス１１１〜デバイス１１３と、ネットワーク１０７を介して接続されている。エージェント１０５は、デバイス１１４およびデバイス１１５と、ネットワーク１０８を介して接続されている。なお、ネットワーク１０６〜１０８は、それぞれ独立したネットワークでも、同一のネットワークでも構わない。

図２は、管理装置１０１等のハードウェア構成の一例を示す図である。エージェント１０３〜１０５およびデータベース１１２も、図２と同様のハードウェア構成を有するものとする。管理装置１０１は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、キーボードコントローラー（ＫＢＤＣ）２０４、ビデオコントローラー（ＶＣ）２０５、ディスクコントローラー（ＤＣ）２０６、ＮＩＣ２０８および外部記憶装置２０７を備える。

ＣＰＵ２０１は、ＲＯＭ２０３または外部記憶装置２０７に記憶されたプログラムを読み出して実行することでシステムバス２０９に接続された各部を総括的に制御し、管理装置１０１の機能を実現する。ＲＡＭ２０２は、ＣＰＵ２０１の主メモリあるいはワークエリアとして機能し、ＣＰＵ２０１の演算データや各種プログラムが記憶される。外部記憶装置２０７は、ハードディスクドライブ（ＨＤＤ）やソリッドステートドライブ（ＳＳＤ）等の記憶装置である。外部記憶装置２０７は、ブートプログラム、オペレーティングシステム、認証サーバ、認証クライアント等を含む各種のアプリケーション、データベースデータ、ユーザファイル等を記憶する。ＫＢＤＣ２０４は、キーボードやポインティングデバイスからの入力情報をＣＰＵ２０１に送る。ＶＣ２０５は、液晶ディスプレイ等の表示装置の表示を制御する。ＤＣ２０６は、外部記憶装置２０７とのアクセスを制御する。ＮＩＣ２０８は、通信コントローラーであり、ネットワーク１０２との接続を制御する。

ここで、データベース１１２に格納されるデータについて説明する。表１は、データベース１１２に格納された、管理装置１０１により管理されるエージェント１０３を表すエージェント情報の一例である。エージェント情報は、エージェントＩＤ、エージェント名、ＩＰアドレスおよびデバイスアドレスを含む。

エージェントＩＤは、各エージェントを一意に識別するために管理装置１０１が付与した識別子である。本実施形態では、エージェントＩＤとしてＵＵＩＤを使用する。エージェント１０３のエージェントＩＤは、「ｅ８８７ｂｄｄｂ−ｆ３ａ９−４０４ａ−ａ７ｂ６−ｅ２７５７６ｄ０９７５ｂ」である。エージェント名は、各エージェントを識別するためにユーザが付けた任意の文字列である。エージェント１０３のエージェント名は、「Ａｇｅｎｔ１」である。

ＩＰアドレスは、各エージェントのＩＰアドレスである。エージェント１０３のＩＰアドレスは、「１７２．１６．１０．１７」である。デバイスアドレスは、各エージェントに紐づく管理対象のデバイスのアドレスを指定する。デバイスアドレスは、複数の開始アドレスと終了アドレスをハイフンで区切った範囲（例えば、１７２．２０．０．０−１７２．２０．０．２５５）またはＩＰアドレス（例えば、１７２．２０．１．１０）をカンマで区切った文字列である。エージェント１０３のデバイスアドレスは、「１７２．１６．０．０−１７２．１６．２５５．２５５」であり、１７２．１６．０．０から１７２．１６．２５５．２５５までのＩＰアドレスを持つデバイスを指定している。

表２は、データベース１１２に格納された、管理装置１０１により管理されるデバイス１０９を表すデバイス情報（デバイスインスタンス）の一例である。デバイス情報は、デバイスＩＤ、エージェントＩＤ、デバイス名、製品名、ＩＰアドレス、ＭＡＣアドレス、シリアル番号、ステータスおよび参照デバイスＩＤを含む。なお、複数の探索結果から同一のデバイスを検出した場合、デバイス情報は、探索結果ごとに、即ち管理するエージェントごとに生成される。

デバイスＩＤは、各デバイスを一意に識別するために管理装置１０１が付与した識別子である。本実施形態では、デバイスＩＤとしてＵＵＩＤを使用する。デバイス１０９のデバイスＩＤは、「４１１２４ｃｄ１−７４ｆ８−４１９１−８ｃ３９−ｆ８０２７ｃ９ｃ０５ａ２」である。エージェントＩＤは、デバイス情報で示されるデバイスに紐付いたエージェントのエージェントＩＤである。本実施形態では、デバイスに紐付いたエージェントは、デバイスの検出（探索）を行い、当該検出デバイスの探索情報の送信元のエージェントである。各デバイスは、エージェントのデバイスアドレスに基づいてエージェントに紐付いている。デバイス１０９にはエージェント１０３が紐付いているため、エージェントＩＤにはエージェント１０３のエージェントＩＤが格納されている。

デバイス名は、各デバイスを識別するためにユーザが付けた任意の文字列である。デバイス１０９のデバイス名は、「Ｄｅｖｉｃｅ１」である。製品名は、デバイスの製品名である。なお、製品名は、ファームウェア更新などによって変更されることがある。デバイス１０９の製品名は、「ＭＦＰ−３２００」である。ＩＰアドレスは、デバイスのＩＤアドレスである。なお、ＩＰアドレスは、ネットワーク設定などによって変更されることがある。デバイス１０９のＩＰアドレスは、「１７２．１６．１０．１２４」である。ＭＡＣアドレスは、デバイスのＭＡＣアドレスである。なお、ＭＡＣアドレスは、ＮＩＣ交換などにより変更されることがある。デバイス１０９のＭＡＣアドレスは、「Ｆ４：８１：３９：Ｃ４：ＣＡ：Ｆ７」である。

シリアル番号は、デバイス固有の番号である。シリアル番号は、通常変更されることはない。デバイス１０９のシリアル番号は、「ａｂｃ０６５０１３５７９」である。ステータスは、デバイスの状態を示す。本実施形態では、ステータスとして、例えば、エラー状態（ＥＲＲＯＲ）もしくは非エラー状態（ＮＯ ＥＲＲＯＲ）が示される。参照デバイスＩＤは、同一デバイスが別のエージェントにより探索された場合に重複なく優先順に従って処理を可能にするための参照情報であり、設定方法については後述する。

以下では、管理装置１０１が複数の管理対象のデバイス１０９〜１１５に対して実行する処理を総称してタスクと呼ぶ。また、タスクを処理するに際して各エージェント１０３〜１０５が各デバイス１０９〜１１５に対して実行する処理をサブタスクと呼ぶ。すなわち、タスクは複数のサブタスクより構成される。タスクは、例えば、管理対象デバイスの探索処理、管理対象デバイスの状態の取得、設定値の一覧の取得、設定値の設定処理などである。

また、デバイスが画像形成装置である場合、タスクとして印刷枚数の取得などが行われる。印刷枚数には、例えば、総印刷枚数、カラー印刷枚数、モノクロ印刷枚数、両面印刷枚数、片面印刷枚数、両面カラー印刷枚数、両面モノクロ印刷枚数等の各種印刷枚数が含まれる。また、デバイスが画像形成装置である場合、デバイスの状態を取得するタスクでは、エラー状態、トナーや感光体などの消耗品情報、給紙部の用紙サイズや用紙残量などが取得される。

図３は、管理装置１０１の構成を示す図である。なお、図３では、管理装置１０１の管理下にあるエージェントの例としてエージェント１０３を図示している。ホストコンピュータ（以下、ホスト）３０５は、管理装置１０１が動作するホストコンピュータである。ホスト３０６は、エージェント１０３が動作するホストコンピュータである。ホスト３０７は、ＷＥＢブラウザ３０１が動作するホストコンピュータである。

管理装置１０１は、ＷＥＢサーバ３０２上で動作するＷＥＢアプリケーション（以下、ＷＥＢアプリ）３０３とスケジューラ３０４を含む。ＷＥＢアプリ３０３は、ホスト３０７で動作するＷＥＢブラウザ３０１経由でユーザからの要求を受信して応答を返すことにより、ユーザインターフェース（ＵＩ）を提供する。また、ＷＥＢアプリ３０３は、エージェント１０３からの各種データの送受信要求を処理する。なお、本実施形態では、管理装置１０１のユーザインターフェースを、ＷＥＢブラウザ３０１を用いて提供しているが、オペレーティングシステムの画面を用いたアプリケーションであっても構わない。

スケジューラ３０４は、定期的にデータベース１１２を走査し、実行予定時刻を経過した予約タスクの実行の準備を行い、エージェント１０３に対して、タスクの実行を指示する。予約タスクとは、実行するタスクの詳細に、実行スケジュールを付加したものである。実行スケジュールは、タスクを実行する日時や、定期的な実行計画（例えば毎週月曜日の８時等）である。

図４は、エージェント１０３の構成を示す図である。なお、エージェント１０４およびエージェント１０５も同様の構成を有している。図４では、エージェント１０３の管理下にあるデバイスの例として、デバイス１０９を図示している。エージェント１０３は、受信部４０１、デバイス管理部（以下、管理部）４０２、送信部４０３、タスク実行部４０４および通信部４０５を備えている。

受信部４０１は、管理装置１０１からの指示を受信する。受信部４０１は、例えば、ＨＴＴＰ／ＨＴＴＰＳサーバを内蔵し、管理装置１０１からのＨＴＴＰ要求を受信して、要求のＵＲＬやメソッドにより所定の処理を実行する。管理部４０２は、エージェント１０３に紐づいているデバイスの情報を管理装置１０１から取得し、デバイスを管理する。例えば、管理部４０２は、デバイスＩＤを用いてデバイスの情報を検索する機能を有する。デバイスＩＤは、システム上でデバイスを特定するデバイス毎に固有の番号である。管理部４０２は、デバイスＩＤに基づいて、特定デバイスのアドレス情報を取得することが可能になる。また、管理部４０２は、通信部４０５がデバイスと通信する際の認証情報を管理する。例えば、管理部４０２は、ＳＮＭＰバージョン３を用いてネットワークデバイスに接続する際のユーザ名、コンテキスト名、認証プロトコルおよびキー、暗号化プロトコルおよびキー等の情報を管理する。ＳＮＭＰは、Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌの略称であり、ネットワークの管理・管理を行うためのプロトコルである。

送信部４０３は、指定されたデータを管理装置１０１の指定されたアドレス（ＵＲＬ）に送信する機能、管理装置１０１の指定されたアドレスに送信した要求に対する応答を送信依頼元に返す機能等を有する。タスク実行部４０４は、管理装置１０１から実行を通知されたタスクを実行する。通信部４０５は、タスク実行部４０４からの依頼によりデバイス１０９との通信を行う。通信部４０５は、例えば、デバイス１０９とＳＮＭＰやＷＥＢサービス等を用いて通信を行う。

ここで、複数のエージェントからデバイスが探索される場合の探索処理の詳細を説明する。探索処理は、システムにあらかじめ設定された間隔で定期的に実行される予約タスクとして実行される。なお、探索処理が、ユーザ指定の実行日時に一時タスクとして実行されてもよい。

表３は、データベース１１２に保存された予約タスク情報の例である。表３では、予約タスクの例として、デバイス探索タスクを示している。予約タスク情報は、予約タスクＩＤ、タスククラス、タスク名、タスク詳細、スケジュール設定および開始日時を含む。なお、予約タスクの対象となるデバイスは、データベース１１２の別のテーブル（例えば、予約タスクＩＤとネットワークデバイスを一意に識別するＩＤとを列に持つテーブル）で管理されているものとする。

予約タスクＩＤは、各予約タスクを一意に識別するために管理装置１０１が付与した識別子である。本実施形態では、予約タスクＩＤとしてＵＵＩＤを使用している。タスククラス名は、予約タスクの作成、編集、実行等を処理するためのプログラム上のクラスの名前である。表３に示されるデバイス探索タスクのタスククラス名は、「Ｄｉｓｃｏｖｅｒｙ」である。ＷＥＢアプリ３０３は、タスククラス名に基づいて、予約タスクの編集画面の操作のための処理を行う。スケジューラ３０４は、タスククラス名に基づいて、予約タスクから後述するタスク情報とサブタスク情報を作成する処理を行う。

タスク名は、ユーザがＷＥＢアプリ３０３を介して入力した、各予約タスクを識別するための名前である。表３に示されるデバイス探索タスクのタスク名は、「Ｄｉｓｃｏｖｅｒ ｄｅｖｉｃｅｓ」である。タスク詳細は、タスクの詳細を各タスククラスが解釈できる形で保存したデータである。表３に示されるデバイス探索タスクのタスク詳細は、ＳＮＭＰのバージョン１を利用してデバイスの探索を行う際のＳＮＭＰのバージョン１のコミュニティ名の配列となっている。デバイスの探索処理では、各エージェント１０３〜１０５が、タスク詳細に列挙されたコミュニティ名を用いて、デバイスとのＳＮＭＰのバージョン１の通信を試行する。

スケジュール設定は、タスクの実行スケジュールである。スケジュール設定には、タスク実行の繰り返しや、曜日、時刻等を設定することができる。表３に示された例では、毎週の繰り返しが設定されている。開始日時は、次に予約タスクを実行すべき日時であり、スケジュール設定に従って設定される。例えば、スケジュール設定に毎週金曜日の午前８時と設定されて、今日が水曜日の場合、開始日時は次の金曜日の午前８時となる。

スケジューラ３０４は、デバイス探索タスクの「スケジュール設定」に従って、対象となる全エージェントに対し、デバイス探索を指示する。デバイス探索の指示を受けたエージェントは、指定されたアドレス範囲で探索処理を実行し、探索結果を管理装置１０１に送信する。管理装置１０１は、探索結果に基づいて新規デバイスを検出する。エージェントによるデバイス探索では、「タスク詳細」で指定されたコミュニティ名を持つＳＮＭＰのバージョン１の要求を、指定したＩＰアドレスに送信し、要求に対する応答を確認することでデバイスの接続の有無を判断する。なお、ＳＮＭＰのバージョン１のコミュニティ名は、タスク全体で共通であり、要求を送信するＩＰアドレスの範囲はエージェント毎に管理装置１０１が指定するものとする。

図５は、スケジューラ３０４がデータベース１１２の予約タスクを開始する処理（以下、タイマー処理）のフローチャートである。タイマー処理では、スケジューラ３０４はデータベース１１２の予約タスクの内、実行予定日時が現在時刻より以前の予約タスクを開始する。なお、スケジューラ３０４はタスクの種類に関係なく、全てのタスクのタイマー処理を同様に行う。

スケジューラ３０４は、起動時にオペレーティングシステムやアプリケーションの実行環境が提供するタイマーに対し、図５で示すタイマー処理を定期的に呼び出すように指示する。オペレーティングシステムやアプリケーションの実行環境は、例えば、「ＪＲＥ（Ｊａｖａ（登録商標） Ｒｕｎｔｉｍｅ Ｅｎｖｉｒｏｎｍｅｎｔ）」、「．ＮＥＴ Ｆｒａｍｅｗｏｒｋ」等である。

ステップＳ５０１にて、スケジューラ３０４は、データベース１１２から実行予定時日時が現在時刻より以前の予約タスクの一覧を取得する。ステップＳ５０２にて、スケジューラ３０４は、ステップＳ５０１で取得した予約タスクの一覧から予約タスクを１つ取り出す。ステップＳ５０３にて、スケジューラ３０４は、ステップＳ５０２で取り出した予約タスクが存在するかの確認を行う。予約タスクが存在しない場合、即ち、ステップＳ５０２での予約タスクの取り出しに失敗した場合は、全ての予約タスクの取り出しが終了したとして、タイマー処理を終了する。一方、予約タスクが存在する場合、即ちステップＳ５０２での予約タスクの取り出しが成功した場合、ステップＳ５０４に進む。

ステップＳ５０４にて、スケジューラ３０４は、ステップＳ５０２で取り出した予約タスクのタスククラスに従い、予約タスクの開始処理を実装したクラスのインスタンスを作成する。ステップＳ５０５にて、スケジューラ３０４は、作成したインスタンスの予約タスクの開始処理を呼び出す。予約タスクの開始処理については、図６を用いて後述する。

ステップＳ５０６にて、スケジューラ３０４は、予約タスクのスケジュール設定に従い次の実行予定日時を計算し、データベース１１２内の該予約タスクのデータを更新する。この際、一度限りの実行や定期実行の終了日が設定されている等の理由により次の実行予定日時が存在しない場合には、スケジューラ３０４は、遠い未来（例えば、９９９９年１月１日）を実行予定日時として設定する。予約タスクのデータの更新は、ステップＳ５０２に戻り、次の予約タスクに対してタイマー処理を行う。

図６は、図５のタイマー処理のステップＳ５０５で呼び出される、予約タスクの開始処理（以下、予約タスク開始処理）のフローチャートである。予約タスク開始用のクラスは、下記に示すＴａｓｋＲｕｎｎｅｒ抽象クラスを継承する。

ｐｕｂｌｉｃ ａｂｓｔｒａｃｔ ｃｌａｓｓ ＴａｓｋＲｕｎｎｅｒ ｛
ｐｕｂｌｉｃ ｖｏｉｄ Ｓｔａｒｔ（ ＲｅｓｅｒｖｅｄＴａｓｋ ｔａｓｋ ）；
｝

また、予約タスク開始用のクラスは、Ｓｔａｒｔという関数を実装している。Ｓｔａｒｔ関数は予約タスク情報を引数に取る。

ステップＳ６０１にて、スケジューラ３０４は、予約タスク情報から新規にタスク情報を作成し、データベース１１２に格納する。表４は、タスク情報の一例である。表４のタスク情報は、表３に示されるデバイスの探索の予約タスク情報に基づいて作成されたタスク情報である。タスク情報は、タスクＩＤ、予約タスクＩＤ、タスククラス、タスク名、タスク詳細、ステータス、開始日時および終了日時を含む。

タスクＩＤは、タスク情報を一意に識別するため予約タスク開始処理が付与した識別子である。本実施形態では、識別子としてＵＵＩＤを使用している。タスク情報の予約タスクＩＤ、タスククラス、タスク名およびタスク詳細は、予約タスク情報の予約タスクＩＤ、タスククラス、タスク名およびタスク詳細である。なお、予約タスクＩＤ、タスククラス、タスク名およびタスク詳細は、タスク情報の作成時点では予約タスク情報と同じものであるが、予約タスクはタスク情報作成後に変更や削除がなされることもあるため、タスク情報内に同データを持つ。

ステータスは、タスク情報により表現されるタスクの状態を示す。本実施形態におけるタスクの状態には「実行中（ＲＵＮＮＩＮＧ）」、「正常（全ての対象のデバイスに対する処理が成功した）」、「失敗（処理に失敗したデバイスが存在する）」があり、「実行中」を初期状態とする。そのため、タスク情報作成時点ではステータスは「実行中」である。なお、タスク状態はこれに限られるものではなく、更に詳細なステータス制御をしてもよい。開始日時は、タスク情報が作成された日時を示す。終了日時は、タスク情報により表現されるタスクの実行が終了した日時を示す。タスク情報の作成時点では、終了日時は空である。

ステップＳ６０２にて、スケジューラ３０４は、タスクの処理対象がデバイスであるか否かを判定する。本実施形態では、タスククラスに基づいてタスクの処理対象を判定する。そのため、タスククラスは、タスククラスの属性としてタスクの処理対象が取得出来るよう構成される。例えば、表４では、タスククラス「Ｄｉｓｃｏｖｅｒｙ」の処理対象はエージェントであり、ステップＳ６０２ではＮｏと判断される。ステップＳ６０２で処理対象がデバイスであると判定された場合は、ステップＳ６０３に進む。一方、処理対象がデバイスではないと判定された場合は、ステップＳ６０７に進む。

ステップＳ６０３にて、スケジューラ３０４は、予約タスクの対象となるデバイスの一覧を取得する。ステップＳ６０４にて、スケジューラ３０４は、ステップＳ６０３で取得したデバイス情報の一覧からデバイスを１つ取り出す。ステップＳ６０５にて、スケジューラ３０４は、デバイス情報の一覧からデバイスの取り出しが成功したかを確認する。デバイス情報の一覧に取り出すデバイスの情報が存在しない場合、即ちステップＳ６０４でのデバイスの取り出しに失敗した場合は、ステップＳ６０３で取得した全デバイスに対する処理が終了したとして、ステップＳ６０８に進む。一方、デバイスの取り出しに成功した場合、ステップＳ６０６に進む。ステップＳ６０６にて、スケジューラ３０４は、Ｓ６０４で取り出したデバイスの情報に対応するサブタスク情報を作成し、データベース１１２に格納する。サブタスクとは、タスクを、対象エージェント、或いは対象デバイスに対する処理に分解した処理の単位を示す。ステップＳ６０６でサブタスク情報の生成後、ステップＳ６０４に戻る。

ステップＳ６０２において、処理対象がデバイスでないと判定された場合、タスクの対象はエージェントである。ステップＳ６０７にて、スケジューラ３０４は、対象エージェント毎にサブタスクを生成する。ステップＳ６０８にて、スケジューラ３０４は、対象エージェントにタスクの開始要求を通知し、予約タスク開始処理を終了する。なお、エージェントへのタスクの開始要求については後述する。

ここで、ステップＳ６０６もしくはステップＳ６０７で生成されるサブタスク情報について説明する。表５および表６は、サブタスク情報の例である。表５および表６のサブタスク情報は、表４に示されるデバイスの探索のタスク情報に基づいて作成されたサブタスク情報である。サブタスク情報は、サブタスクＩＤ、タスクＩＤ、デバイスＩＤ、エージェントＩＤ、サブタスク詳細、ステータス、実行結果、開始日時および終了日時を含む。なお、表５は、エージェント１０３により実行されるデバイス探索処理のサブタスク情報であり、表６は、エージェント１０４により実行されるデバイス探索処理のサブタスク情報である。

サブタスクＩＤは、サブタスク情報を一意に識別するため予約タスク開始処理が付与した識別子である。本実施形態では、識別子としてＵＵＩＤを使用している。タスクＩＤは、サブタスクの元となるタスクのタスクＩＤである。また、表５および表６に示されるサブタスクは表４のタスクのサブタスクとして生成されるため、同一のタスクＩＤ（表４のタスクＩＤ）が設定される。

デバイスＩＤは、サブタスクで示される処理を行う対象のデバイスを識別するための識別子である。デバイスの探索処理の場合、指定アドレス範囲のデバイスを見つける処理であるためサブタスクの処理を実行する対象はエージェントとなる。そのため、表５および表６において、サブタスク情報のデバイスＩＤは空になっている。エージェントＩＤは、サブタスクで示される処理を行うエージェントを識別するための識別子である。表５のサブタスクは、エージェントＩＤ：ｅ８８７ｂｄｄｂ−ｆ３ａ９−４０４ａ−ａ７ｂ６−ｅ２７５７６ｄ０９７５ｂのエージェント１０３であるエージェント１０３が処理する。表６のサブタスクは、エージェントＩＤ：ｃ３６０５３２ｃ−ｂ３８ｆ−４９ｆ６−ｂａ７３−９３ａｆｅａ９０ｄｆｆ０のエージェント１０４であるエージェント１０４が処理する。

サブタスク詳細は、サブタスクの詳細を記載したデータである。デバイス探索処理の場合のサブタスク詳細は、エージェントが探索用のＳＮＭＰのバージョン１のパケットを送信する宛先である。探索処理では、サブタスク詳細に記載されたネットワークアドレスのそれぞれに対して、探索用のＳＮＭＰのバージョン１のパケットを送信することで、デバイスの探索を行う。表５の例では、１７２．１６．０．０から１７２．１６．２５５．２５５の合計６５５３６個のＩＰアドレスのそれぞれに対してＳＮＭＰパケットを送信する。表６の例では、１７２．１７．０．０から１７２．１７．２５５．２５５の合計６５５３６個のＩＰアドレスのそれぞれに対してＳＮＭＰパケットを送信する。

ステータスは、サブタスク情報で表現されるサブタスクの状態を示す。ステータスには「準備中」「実行中」「成功」「失敗」「例外（実行中に予期せぬエラーが発生した）」「キャンセル」がある。サブタスク情報作成時点では、サブタスクの実行は開始されていないため「準備中（Ｒｅａｄｙ）」」である。実行結果は、サブタスクを処理する各クラスが解釈可能なサブタスクの実行結果である。作成時点では実行が開始されていないため、実行結果は空である。開始日時、終了日時はそれぞれサブタスクのエージェントによる実行の開始と終了の日時である。

図７は、デバイス管理システムの要求処理のシーケンスを示す図である。管理装置１０１によるタスクの開始処理から、エージェント１０３およびエージェント１０４によるタスクの実行と、管理装置１０１への結果の送信までの流れの概要を示している。ステップＳ７０１で、管理装置１０１は、図６の予約タスク開始処理を実行する。ステップＳ７０２で、管理装置１０１は、タスク開始要求をエージェント１０３に送信する。タスク開始要求は、予約タスク開始処理の一環として行われる処理であり、図６のステップＳ６０８に相当する処理である。タスク開始要求で送信する情報には、サブタスク情報も含まれる。ステップＳ７０３で、エージェント１０３はタスク開始要求を受信し、当該タスクおよびサブタスク処理のためのインスタンスを作成し、サブタスクを処理キューに積む。

ステップＳ７０４で、エージェント１０３は、処理キューに積まれたサブタスクを実行するサブタスク実行処理を行う。そして、ステップＳ７０５で、エージェント１０３は、サブタスク毎の実行処理で必要に応じてデバイスと通信し、サブタスク実行結果を作成する。ステップＳ７０６で、エージェント１０３は、管理装置１０１にサブタスク実行結果を通知する。デバイス探索タスクの場合は、サブタスク実行結果として探索されたデバイスの一覧が返される。なお、エージェント側のタスクおよびサブタスクの処理詳細は本実施形態の本質とは関係がないため、説明を省略する。

エージェント１０３からサブタスク実行結果を受信した管理装置１０１は、ステップＳ７０７でサブタスク実行結果受信処理を行う。サブタスク実行結果受信処理については、図８を用いてその詳細を説明する。サブタスク実行結果受信処理では、サブタスク実行結果に含まれるクラス名からサブタスク実行結果処理用クラスを生成する。そして、ステップＳ７０８で、管理装置１０１は、サブタスク実行結果処理（即ちＨｏｏｋ関数）を行う。その後、サブタスク実行結果受信処理では、サブタスク実行結果処理のサブタスク実行結果の内容に基づいてデータベース１１２内のサブタスク情報を更新する。なお、管理装置１０１とエージェント１０３との通信に使用される各ＵＲＬおよび各要求の受信処理は、タスクの種類に依らず共通である。

予約タスク開始処理において、ステップＳ７０２でエージェント１０３にタスク開始要求を送信したのと同様に、ステップＳ７０９でエージェント１０４にもタスク開始要求を送信する。エージェント１０４は、エージェント１０３と同様に、管理装置１０１に指示されたタスクおよびサブタスクを処理し、サブタスク実行結果を管理装置１０１へ送信する。エージェント１０４におけるステップＳ７１０〜ステップＳ７１２は、エージェント１０３におけるステップＳ７０３〜ステップＳ７０５と同様の処理である。エージェント１０４からサブタスク実行結果を受信した管理装置１０１は、ステップＳ７１４およびステップＳ７１５で、ステップＳ７０７およびステップＳ７０８と同様の処理を行う。これらの処理は、全てのエージェントに対し、同様に実行される。

図８は、サブタスク実行結果受信処理を示すフローチャートである。サブタスク実行結果受信処理は、管理装置１０１のＷＥＢアプリ３０３がエージェントからサブタスク実行結果を受信した際の処理である。サブタスク実行結果を受信した管理装置１０１において、ＷＥＢアプリ３０３は、ＵＲＬパス（例えば、「／ａｐｉ／ｖ１／ｔａｓｋｓ／ｓｕｂｔａｓｋ／クラス名」）に対するＰＯＳＴメソッドのＨＴＴＰ要求を受信する。ＨＴＴＰ要求を受信したＷＥＢアプリ３０３は、「クラス名」と要求の本文に含まれるサブタスク実行結果を引数にして、サブタスク実行結果受信処理を呼び出す。以下、一例として「クラス名」が「Ｄｉｓｃｏｖｅｒｙ」である場合について説明する。

ステップＳ８０１で、管理装置１０１は、引数で与えられたクラス名を用いて、サブタスク受信結果を処理可能なサブタスク実行結果処理用クラスのインスタンスを作成する。サブタスクの実行結果処理を実行するクラスは、以下に示すインターフェースを実装している。

ｐｕｂｌｉｃ ｉｎｔｅｒｆａｃｅ ＳｕｂｔａｓｋＲｅｓｕｌｔＨｏｏｋｅｒ ｛
ＳｕｂｔａｓｋＩｎｆｏ Ｈｏｏｋ（ＳｕｂｔａｓｋＩｎｆｏ ｒｅｓｕｌｔ）；
｝

サブタスク受信結果（ＳｕｂｔａｓｋＩｎｆｏ）の中には少なくともサブタスクＩＤが含まれ、データベース１１２を参照することにより、サブタスク情報が取得可能である。なお、デバイスＩＤは、処理対象がデバイスであるサブタスクの場合は必須であるが、デバイス探索のように処理対象がエージェントである場合はデバイスＩＤが空であるか項目ごと含まれない。

ステップＳ８０２で、管理装置１０１は、サブタスク受信結果の処理対象がデバイスであるか否かを判定する。処理対象がデバイスである場合、ステップＳ８０３に進む。一方、処理対象がデバイスでない場合、ステップＳ８０７に進む。ステップＳ８０３で、管理装置１０１は、データベース１１２のデバイス情報テーブルから、デバイス情報の参照デバイスＩＤにサブタスク受信結果に含まれるデバイスＩＤが設定されたデバイスＤｎがあるか否かを判定する。参照デバイスＩＤは、同一デバイスが異なるエージェントにより探索された場合に設定されるため、ステップＳ８０３は、同一デバイスを担当する別のエージェントに処理を依頼できるかを判定するのと同義である。デバイス情報の参照デバイスＩＤにサブタスク受信結果に含まれるデバイスＩＤが設定されたデバイスＤｎがある場合、即ち別のエージェントに処理の依頼が可能である場合、ステップＳ８０４に進む。一方、デバイス情報の参照デバイスＩＤにサブタスク受信結果に含まれるデバイスＩＤが設定されたデバイスＤｎがない場合、即ち別のエージェントに処理の依頼ができない場合、ステップＳ８０７に進む。

ステップＳ８０４で、管理装置１０１は、エージェント変更対象エラーであるか否かを判定する。エージェント変更対象エラーとは、エージェントの変更で処理可能である失敗、即ち別のエージェントに処理を依頼することにより正常処理できる可能性のある失敗である。エージェント変更対象エラーには、例えば、通信タイムアウトのエラーがある。さらに。エージェント変更対象エラーには、ＩＰアドレス／ＭＡＣアドレスまたはＩＰアドレス／シリアル番号の組合せが不一致であることによるデバイス不一致エラーなど、デバイスを特定する情報が対象となるデバイスと異なる値であった場合がある。エージェント変更対象エラーである場合、即ち別のエージェントに処理を依頼することが有効である場合は、ステップＳ８０５に進む。一方、エージェント変更対象エラーで出ない場合は、ステップＳ８０７に進む。

ステップＳ８０５で、管理装置１０１は、同一のデバイスを担当する別のエージェントに処理を依頼するためのサブタスクを生成する。即ち、ステップＳ８０３で特定したデバイスＤｎ用のサブタスクを生成する。サブタスクの生成においては、データベース１１２から、サブタスクＩＤの親タスクであるタスクＩＤを取得し、参照デバイスＩＤにより該当デバイスの管理を担当するエージェントＩＤを取得することにより、必要情報を特定し、エージェントを決定する。ステップＳ８０６で、管理装置１０１は、Ｓ８０５で生成したサブタスクの依頼先となる、デバイスＤｎを管理するエージェントにサブタスク実行を指示する。

ステップＳ８０７で、管理装置１０１は、ステップＳ８０１で作成したサブタスク実行結果処理用クラスのインスタンスのＨｏｏｋ関数を呼び出し、結果を受け取る。サブタスク実行結果処理用クラスは、引数として渡されたサブタスク実行結果を元に各タスクに固有の処理を行い、必要に応じてサブタスク実行結果の内容を変更し、これを返して関数を終了する。各タスクに固有の後処理の例を、以下に示す。まず、デバイス探索処理タスクの場合について説明する。デバイス探索処理タスクの場合、管理エージェントから送信される実行結果の例は以下のようになる。

｛”ｓｃａｎｎｅｄ”： ６５０２５，
”ｄｉｓｃｏｖｅｒｅｄ”： ４，
”ｄｅｖｉｃｅｓ”： ［
｛”ｉｐ”： ”１７２．１６．１０．１２４”， ”ｎａｍｅ”： ”ＭＦＰ−３２００”，
”ｍａｃ”： ”Ｆ４：８１：３９：Ｃ４：ＣＡ：Ｆ７”， ”ｓｎ”： ”ａｂｃ０６５０１” ｝，
｛”ｉｐ”： ”１７２．１６．１１０．１８１”， ”ｎａｍｅ”： ”ＳＦＰ−２０００”，
”ｍａｃ”： ”Ｆ４：８１：１９：Ｅ２：Ｂ１：Ｃ９”， ”ｓｎ”： ”ｓｓｄ１１２０７” ｝，
｛”ｉｐ”： ”１７２．１６．１１３．１３４”， ”ｎａｍｅ”： ”ＳＦＰ−３５００”，
”ｍａｃ”： ”Ｆ４：８１：２３：ＡＣ：ＢＦ：４５”， ”ｓｎ”： ”ｓｆｂ１１３５６” ｝，
｛”ｉｐ”： ”１７２．１６．１３８．９１”， ”ｎａｍｅ”： ”ＭＦＰ−５５００”，
”ｍａｃ”： ”Ｆ４：８１：９２：ＢＥ：Ｆ１：１Ａ”， ”ｓｎ”： ”ａｂｆ０５５０５” ｝
］
｝

ｓｃａｎｎｅｄは、その時点までに探索を施行したアドレスの数である。ｄｉｓｃｏｖｅｒｅｄは、見つかったデバイスの数である。ｄｅｖｉｃｅｓは、前回送信から新たに見つかったデバイスの情報のリストである。デバイス情報には、ｉｐ、ｎａｍｅ、ｍａｃおよびｓｎが含まれている。ｉｐはＩＰアドレス、ｎａｍｅは製品名、ｍａｃはＭＡＣアドレス、ｓｎはシリアル番号である。探索対象の全てのＩＰアドレスに対する処理が完了した場合、受信したサブタスク実行結果のステータスは「ＤＯＮＥ」となっている。

デバイス探索処理の場合、ステップＳ８０７で呼び出される実行結果処理クラスの実行結果処理関数は、以下の動作をする。まず、サブタスクの実行結果から、探索されたデバイス情報の一覧（「ｄｅｖｉｃｅｓ」情報）を取り出す。次に、実行結果処理関数は、取り出したデバイス情報の其々に対し、データベース１１２内のデバイス情報のテーブルに同じデバイス情報が既に登録されているか否かを判定する。デバイス情報の判定のためには、シリアル番号（”ｓｎ”）もしくはＭＡＣアドレス（”ｍａｃ”）を使用する。判定の結果、デバイス情報のテーブルに同じデバイス情報が登録されていない場合、実行結果受信関数は受信したデバイス情報を、新規にデータベース１１２のデバイス情報テーブルに追加する。一方、デバイス情報のテーブルに同じデバイス情報が既に登録されている場合、エージェントＩＤが同一であるか否かを判定する。エージェントＩＤが同一である場合、実行結果処理関数は、データベース１１２内のテーブル内の情報を受信した情報で更新する。一方、エージェントＩＤが異なる場合は、デバイス情報のテーブルに同じデバイス情報が登録されていない場合と同様に、受信したデバイス情報に基づいて新規にデバイス情報を生成する。そして、デバイス情報に参照デバイスＩＤを設定することにより、デバイス間のリンク情報を設定して、データベース１１２のデバイス情報テーブルに追加する。

図９は、デバイスのインスタンスの参照デバイスＩＤによるリンクを説明する図である。Ｄｅｖｉｃｅ１〜３は、同一のシリアル番号を有する同一デバイスであるが、ＭＡＣアドレス等が異なることにより、それぞれ異なるエージェントが管理を担当している。デバイス探索処理タスクの実行結果で見つかった先頭のデバイスは、Ｄｅｖｉｃｅ１として登録されている。本実施形態では、先頭デバイスには参照デバイスＩＤを設定せず（ＮＵＬＬ）、２番目以降のデバイスに一つ前のデバイスのデバイスＩＤを参照デバイスＩＤとして設定することで、デバイス間のリンク関係を保持する。

図９の例では、デバイス探索処理タスクの実行結果で見つかった２番目のデバイスはＤｅｖｉｃｅ３であり、Ｄｅｖｉｃｅ３の参照デバイスＩＤとして、Ｄｅｖｉｃｅ１のデバイスＩＤを設定する。デバイス探索処理タスクの実行結果で見つかった３番目のデバイスはＤｅｖｉｃｅ６であり、同様にＤｅｖｉｃｅ６の参照デバイスＩＤとして、Ｄｅｖｉｃｅ３のデバイスＩＤを設定する。

また、エージェントＩＤから、Ｄｅｖｉｃｅ１はエージェント１０３が、Ｄｅｖｉｃｅ３はエージェント１０４が、Ｄｅｖｉｃｅ６はエージェント１０５がそれぞれ管理を担当していることが分かる。Ｄｅｖｉｃｅ１のインスタンスは、エージェント１０３用のデバイス１０９のインスタンスである。同様に、Ｄｅｖｉｃｅ３のインスタンスは、エージェント１０４用のデバイス１１１のインスタンスであり、Ｄｅｖｉｃｅ６のインスタンスは、エージェント１０５用のデバイス１１４のインスタンスである。

本実施形態において、デバイス間のリンクの順番はサブタスクの試行順番になる。デバイスに対するサブタスク処理を実施する際には、最初に先頭のデバイス（図９のＤｅｖｉｃｅ１）のみサブタスクを生成し、当該デバイスの管理を担当するエージェントに実行指示を出す。先頭のデバイスのサブタスク実行結果がステップＳ８０４でエージェント変更対象エラーと判断された場合に、次点のデバイス（図９のＤｅｖｉｃｅ３）を試行することになる。次点のデバイス（図９のＤｅｖｉｃｅ３）のサブタスク実行結果がステップＳ８０４でエージェント変更対象エラーと判断された場合は、さらに、次々点のデバイス（図９のＤｅｖｉｃｅ６）を試行することになる。デバイス間のリンクは、上位のデバイス情報から参照デバイスＩＤにデバイスＩＤを持つデバイスのインスタンスを参照することで辿ることができる。

なお、デバイスの登録順位について、デバイス探索処理タスクの実行結果で見つかった順に設定する例を説明したが、これに限られるものではなく、デバイス情報の生成順に設定してもよいし、他の優先条件に従って組み替えてもよい。受信した全てのデバイス情報に対する処理が完了したら、実行結果処理関数は、サブタスク実行結果を関数の呼び出し元に返す。

次に、各タスクに固有の後処理の例として、デバイスの状態の取得タスクの場合について説明する。デバイスの状態の取得タスクの後処理では、デバイスの現在の状態を格納するデータベース１１２内のテーブルの内容を更新し、前回の状態から新たにエラー状態が検出された場合、その旨をユーザが指定したメールアドレスに対してメール送信する。なお、デバイス情報更新処理については、図１０を用いて後述する。

次に、各タスクに固有の後処理の例として、デバイスの利用状況の取得タスクの場合について説明する。デバイスの利用状況の取得タスクでは、例えば、デバイスが画像形成装置である場合、各種カウンタの値を取得する。デバイスの利用状況の取得タスクの後処理では、利用状況の統計を格納するデータベース１１２内のテーブルの内容を更新する。

図８の説明に戻る。ステップＳ８０８で、管理装置１０１は、Ｈｏｏｋ関数から返されたサブタスク実行結果に基づいて、表５および表６に示すデータベース１１２内のサブタスク情報を更新する。ステップＳ８０９で、管理装置１０１は、受信したサブタスク実行結果のタスクＩＤに紐づいたすべてのサブタスクが終了したか否か判定する。すべてのサブタスクが終了したか否かは、データベース１１２内の受信したサブタスクに紐づいたタスクＩＤと同じタスクＩＤを持つサブタスク情報のステータスが終了状態でないサブタスク情報があるか否かにより判定する。終了状態とは、成功、失敗、例外、キャンセルの何れかに該当する状態である。

すべてのサブタスクが終了していない場合、ステップＳ８１０に進む。一方、実行が終了していないサブタスク情報がある場合、即ちステータスが終了状態でないサブタスク情報がある場合は、本処理を終了する。ステップＳ８１０で、管理装置１０１は、表４に示すデータベース１１２内のタスク情報のステータスと終了日時を更新する。ステータスは、タスクＩＤを持つ全てのサブタスク情報のステータスが「成功」の場合は「成功」、そうでない場合は「失敗」となる。

図１０は、デバイス情報更新処理を示すフローチャートである。デバイス情報更新処理は、図８のＳ８０７におけるサブタスク固有の後処理の一例である。図９のようにデバイス情報がリンクしていることにより、１つのデバイスで検出した情報更新を、リンクされた別のデバイス情報（デバイスインスタンス）に反映することが出来る。リンクされた別のデバイス情報にも更新された情報を反映することにより、例えば、ＵＩ表示おいてエージェント指定でデバイスリストのフィルタリングを行った場合でも、別エージェントが検出した最新のデバイス情報を表示することができる。

Ｓ１００１において、管理装置１０１は、データベース１１２から更新対象デバイスＤのデバイス情報を検索する。デバイス情報の検索は、ステップＳ８０７の実行処理関数の引数として、サブタスク受信結果（ＳｕｂｔａｓｋＩｎｆｏ）に含まれているデバイスＩＤをキーに検索する。Ｓ１００２において、管理装置１０１は、更新対象のデバイスＤのデバイス情報をサブタスク受信結果（ＳｕｂｔａｓｋＩｎｆｏ）に含まれている、最新のデバイス情報で更新する。管理装置１０１は、さらに、更新対象デバイスのデバイスＩＤを一時変数Ｄｔとして、デバイスＤのデバイスＩＤで初期化する。

Ｓ１００３において、管理装置１０１は、データベース１１２よりデバイス情報のテーブルからデバイス情報の［参照デバイスＩＤ］にＤｔが設定されている参照元デバイスＤｃがあるか否かを判定する。［参照デバイスＩＤ］にＤｔが設定されている参照元デバイスＤｃがある場合、Ｓ１００４に進む。一方、［参照デバイスＩＤ］にＤｔが設定されている参照元デバイスＤｃがない場合、ステップＳ９０６に進む。

ステップＳ１００４において、管理装置１０１は、参照元デバイスＤｃのデバイス情報を、最新のデバイス情報で更新する。ステップＳ１００５において、管理装置１０１は、次の優先順位のデバイスを検索するために、Ｄｔを参照元デバイスＤｃのデバイスＩＤで初期化し、Ｓ１００３へ戻る。

ステップＳ１００６において、管理装置１０１は、データベース１１２より更新対象デバイスＤのデバイス情報に含まれる［参照デバイスＩＤ］を取得し、一次変数Ｉとする。ステップＳ１００７において、管理装置１０１は、Ｉが空であるか否か、即ち優先順位が上位のデバイスが存在するか否かを判定する。Ｉが空ではないと判定された場合、即ち優先順位が上位のデバイスが存在する場合は、ステップＳ１００８に進む。一方、Ｉがからであると判定された場合、即ち優先順位が上位のデバイスが存在しない場合は、リンクされた全てのデバイス情報の更新が完了したため、本処理を終了する。

ステップＳ１００８において、管理装置１０１は、データベース１１２よりデバイスＩＤがＩである参照先デバイスＤｐのデバイス情報を、最新のデバイス情報で更新する。ステップＳ１００９において、管理装置１０１は、上位の優先順位のデバイスを検索するために、ＩをＤｐのデバイスＩＤで初期化し、Ｓ１００７へ戻る。

図１１は、本実施形態のデバイスリストのＵＩの一例である。図１１には、エージェント１０３〜１０５に対応するＡｇｅｎｔ１〜３で探索されたデバイスの一覧が表示されている。デバイスリストのＵＩには、デバイス情報として、デバイスＩＤ、デバイス名、製品名、製品シリアル番号、ＭＡＣアドレス、デバイスのアドレス、エージェント名およびデバイス状態が表示されているが、これに限られるものではない。デバイスリストのＵＩには、デバイス情報として管理に必要な情報を表示する。

図９で例示した、複数のデバイス情報Ｄｅｖｉｃｅ１、Ｄｅｖｉｃｅ３、Ｄｅｖｉｃｅ６として管理されている実体が一つのデバイスは、優先順位１番のＤｅｖｉｃｅ１としてＵＩ上に表示されており、Ｄｅｖｉｃｅ３およびＤｅｖｉｃｅ６は表示されていない。Ｄｅｖｉｃｅ１に相当するデバイスが、３つのエージェントから管理されていることは、デバイスアイコン上の「３」で表現されている。なお、複数のエージェントから管理されていることの表示方法は、これに限られるものではない。また、デバイスリストのＵＩからＤｅｖｉｃｅ１の詳細なデバイス情報を表示すると、詳細デバイス情報としてＤｅｖｉｃｅ３としてエージェント１０４、Ｄｅｖｉｃｅ６としてエージェント１０５でも管理されている旨を、表示するよう構成してもよい。

また、本実施形態では、図１１に示されるＦｉｌｔｅｒにより、エージェント指定でデバイスを限定表示することを想定している。ＦｉｌｔｅｒでＡｇｅｎｔ１を選択した場合には、Ａｇｅｎｔ１（エージェント１０３）の管理デバイスのみを表示する。また、ＦｉｌｔｅｒでＡｇｅｎｔ２を選択した場合、全デバイス表示では表示していないＤｅｖｉｃｅ３のデバイス情報を表示する。同様に、ＦｉｌｔｅｒでＡｇｅｎｔ３を選択した場合も全デバイス表示では表示していないＤｅｖｉｃｅ６のデバイス情報を表示する。このように、Ｆｉｌｔｅｒによりエージェント指定した場合には、各エージェントが管理するすべてのデバイスを表示する。本実施形態のデバイスリストのＵＩによると、管理装置１０１のユーザが管理操作を行う際に、実体が一つのデバイスが複数のエージェントに管理されていることを容易に認識することができる。

以上説明したように、本実施形態によると、不要な多重管理を抑制しつつ、例外処理として、第１のエージェントによる処理が失敗した場合に、有効なネットワークを有する第２のエージェントを利用することができる。

（第２実施形態）
第１実施の形態では、複数のエージェントが一つのデバイスを管理する時に、効果的に重複なく、管理に関わる処理を実行する方法に関して説明した。第１実施形態においてサブタスクが成功するまで、どのエージェントがサブタスクを実行し、どのエージェントで処理が成功したかが分かり、更に、其々のサブタスクに対して再試行の指示ができれば、ユーザビリティを向上させることができる。

例えば、デバイス設定の取得に関して、毎回第１のエージェントでエラーとなり第２のエージェントで成功している場合は、デバイスが第１のエージェントの管理範囲から、第２のエージェントの管理範囲へ移動した場合がある。デバイスの管理範囲の移動が、管理者が意図したものではなく、デバイス使用者が無断で移動する場合もある。また、デバイスが複数のネットワークカード等の通信インターフェースを持つ場合、その中の一つのアドレスのみ変更され、デバイスの管理範囲が移動するケースがある。例えば、ＤＨＣＰサーバによりデバイスのＩＰアドレスが可変に構成されているケース等が考えられる。しかし、デバイスなどは管理効率を鑑みて、特定アドレスが割り当てられるように設定されていることも多く、アドレスの変更が管理者が意図しない設定に起因する場合も多い。

図１２は、タスクログの一例を示す図である。図１２に示されるタスクログは、デバイス設定タスクのログである。デバイス設定タスクのログには、タスク名、ログＩＤ，タスクＩＤ、タスクの対象、実行結果のステータス、タスク作成日時および完了日時を含む。さらに、タスクのログの下部にはタスクを構成するサブタスクの一覧が表示されている。図１１のサブタスク一覧には、サブタスクをＤｅｖｉｃｅ１、Ｄｅｖｉｃｅ３、Ｄｅｖｉｃｅ６と試行し、Ｄｅｖｉｃｅ１、Ｄｅｖｉｃｅ３でエラーとなり、Ｄｅｖｉｃｅ６で成功したことが示されている。これにより、Ｄｅｖｉｃｅ１でのサブタスクの実行結果のエラーを受けてＤｅｖｉｃｅ３でサブタスクを実行し、さらに、Ｄｅｖｉｃｅ３でのサブタスクの実行結果のエラーを受けてＤｅｖｉｃｅ６でサブタスクを実行し成功したことが分かる。また、サブタスクの左端にはチェックボックスを配置し、再試行したいサブタスクにチェックを付けて、「Ｒｅｔｒｙ Ｓｕｂｔａｓｋ」ボタンを押下すると、同一の管理内容で新しいサブタスクが生成され、再試行が可能である。

以上説明したように、本実施形態によると、第１実施形態より管理の視認性や操作性が向上し、更に効率的なデバイスの管理が実現できる。

（その他の実施形態）
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (12)

1. 複数のエージェントとの通信を用いて、複数のデバイスを管理する管理装置であって、
   各エージェントからの管理対象のデバイスに対する探索結果を受信する受信手段と、
   前記探索結果に基づいて、デバイスを担当するエージェントを決定する決定手段と、
   デバイスを処理対象として含む処理に関するタスクを実行する際に、前記決定手段により決定されたデバイスを担当するエージェントに対して、前記処理の依頼を実行する実行手段と、を備え、
   前記決定手段は、複数の探索結果から同一のデバイスを検出した場合、当該検出デバイスを含む探索結果の送信元である複数のエージェントの中から、前記検出デバイスを担当する第１のエージェントを決定し、
   前記実行手段は、前記第１のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行し、
   前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合に、
   前記決定手段は、前記検出デバイスを含む探索結果の送信元である複数の管理エージェントの中から、前記第１のエージェントとは異なる第２のエージェントを決定し、
   前記実行手段は、前記第２のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行する
   ことを特徴とする管理装置。
2. 前記各エージェントは、管理対象のデバイスの探索を行う際のネットワーク範囲、プロトコル、対象となる機種の少なくともいずれかを含む条件の少なくとも一部の設定がそれぞれ相違する
   ことを特徴とする請求項１に記載の管理装置。
3. 前記決定手段は、前記探索結果に含まれるデバイスを一意に識別するシリアル番号を用いて、同一のデバイスを検出する
   ことを特徴とする請求項１または２に記載の管理装置。
4. 前記決定手段は、前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合に、前記失敗した処理がエージェントの変更で処理可能である場合に、前記第２のエージェントを決定する
   ことを特徴とする請求項１乃至３のいずれか１項に記載の管理装置。
5. 前記エージェントの変更で処理可能である失敗は、通信タイムアウトのエラー、もしくは、ＩＰアドレス／ＭＡＣアドレスまたはＩＰアドレス／シリアル番号の組合せが不一致であることによるデバイス不一致エラーである
   ことを特徴とする請求項４に記載の管理装置。
6. 前記探索結果に基づいて、各エージェント用のデバイスのインスタンスを生成する生成手段をさらに備え、
   複数の探索結果から同一のデバイスを検出した場合、前記生成手段は、当該検出デバイスのインスタンスに、同一デバイスの他のインスタンスを紐づける
   ことを特徴とする請求項１乃至５のいずれか１項に記載の管理装置。
7. 前記インスタンスは、インスタンスごとにデバイスを特定するデバイスＩＤ、および、当該デバイスを担当するエージェントを示すエージェントＩＤを含み、
   前記生成手段は、同一デバイスの他のインスタンスのデバイスＩＤを参照デバイスＩＤに設定することにより、同一デバイスの他のインスタンスを紐づける
   ことを特徴とする請求項６に記載の管理装置。
8. 前記第２のエージェント用の前記検出デバイスのインスタンスの参照デバイスＩＤには、前記第１のエージェント用の前記検出デバイスのインスタンスのデバイスＩＤが設定されている
   ことを特徴とする請求項７に記載の管理装置。
9. 前記決定手段は、前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合、前記第１のエージェント用の前記検出デバイスのインスタンスのデバイスＩＤを参照デバイスＩＤに有するインスタンスを参照し、当該インスタンスを担当する第２のエージェントを決定する
   ことを特徴とする請求項８に記載の管理装置。
10. 前記実行手段は、前記デバイスのインスタンスを用いて当該デバイスを処理対象とするサブタスクをエージェントごとに生成し、処理の依頼を実行する際に前記サブタスクをエージェントに送信し、
    前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合に、前記実行手段は、前記第１のエージェント用の前記検出デバイスのインスタンスに紐づく、前記第２のエージェント用の前記検出デバイスのインスタンスを用いて前記検出デバイスを処理対象とするサブタスクを生成し、当該サブタスクを前記第２のエージェントに送信する
    ことを特徴とする請求項６乃至９のいずれか１項に記載の管理装置。
11. 複数のエージェントとの通信を用いて、複数のデバイスを管理する管理装置の制御方法であって、
    各エージェントからの管理対象のデバイスに対する探索結果を受信する受信工程と、
    複数の探索結果から同一のデバイスを検出した場合、当該検出デバイスを含む探索結果の送信元である複数のエージェントの中から、前記検出デバイスを担当する第１のエージェントを決定する第１の決定工程と、
    前記第１のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行する第１の実行工程と、
    前記第１のエージェントに対する前記依頼に応じた前記処理が失敗した場合に、前記検出デバイスを含む探索結果の送信元である複数の管理エージェントの中から、前記第１のエージェントとは異なる第２のエージェントを決定する第２の決定工程と、
    前記第２のエージェントに対して、前記検出デバイスを処理対象に含む処理の依頼を実行する第２の実行工程と、
    を有することを特徴とする制御方法。
12. 請求項１乃至１０のいずれか１項に記載の各手段としてコンピュータを機能させるためのプログラム。

Images