JP2020087323A - デバイス管理サーバー、方法及びプログラム - Google Patents

Abstract

【課題】 従来、複数サービスのそれぞれのために、デバイスから必要なデータ収集する必要がある環境において、効率的にデータ収集ができる方式を提供できていなかった。【解決手段】 本発明のデバイス管理サーバーは、１以上のサービスから同じネットワークデバイスを対象とする複数の収集要求を受信した後に、それらの中から、指定されているタイミングとルートに基づいて、該ネットワークデバイスに設定されるべき１以上の収集要求を選択する選択手段を有し、前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスからの該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記第１収集要求で指定されたタイミング及び相対的にコストの低いルートが指定された収集要求が前記ネットワークデバイスに送信されることを特徴とする。【選択図】 図３

Description

本発明は、画像形成装置などのネットワークデバイスを管理するデバイス管理システムに関する。

複合機やプリンター、ネットワークカメラなどの画像形成装置を含むネットワークデバイス（以降、デバイスとも呼ぶ）を、ネットワークを介して一元管理するためのデバイス管理システムがある。デバイス管理システムは、管理しているデバイスから各種データを収集する機能や、収集したデータを利用して顧客に各種サービスを提供する機能を持つ。各サービスは、サービスを提供するために必要となるデータをデバイスから収集する。

また、クラウドベンダーが提供するクラウド基盤を利用して構築される情報処理システムがある。デバイスからのデータを情報処理システムで蓄積して、その情報を利用するために連携するデバイス管理システムも存在する（例えば、特許文献１）。

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

クラウド基盤を利用して構築される情報処理システムと連携するサービスを複数提供している環境を想定する。このような環境においては、複数サービスのそれぞれがデバイスから必要なデータを収集したい場合がある。このような場合に、同じデバイスに対して、各サービスが個別にデータ収集要求をすると課題が発生する。

例えば、稼働中の複数のサービスの中のいずれかのサービスが停止したり、解約されたりした場合、当該サービスが収集していたデータの収集を停止するようデバイスに要求することになる。一方で、収集停止の対象となったデータを、稼働中の他のサービスが必要としていることが考えられる。つまり、他のサービスにとって必要なデータの収集が停止してしまうといった課題がある。

また、各サービスが個別にデータ収集を要求した場合、同じデータを重複して送信するような要求をしてしまうことも考えられる。このような要求をした場合、データの重複管理や、デバイスが設置される環境において無駄なトラフィックが発生する。

本発明は、上記課題に鑑みてなされたものであり、複数サービスのそれぞれのために、デバイスから必要なデータ収集する際に、効率的にデータ収集ができる方式を提供することを目的とする。

本発明は、ネットワークデバイスに対して、データ種別とタイミングと収集のためのルートが指定された収集要求を送信するデバイス管理サーバーであって、１以上のサービス提供サーバーから、対象となるデバイスとデータ種別とタイミングと収集のためのルートが指定された収集要求を受信する受信手段と、同じネットワークデバイスを対象とする複数の収集要求を受信した後に、該複数の収集要求の中から、各収集要求で指定されているタイミングとルートに基づいて、該ネットワークデバイスに設定されるべき１以上の収集要求を選択する選択手段と、前記選択された１以上の収集要求をネットワークデバイスに対して送信する送信手段と、を有し、前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスに対して既に送信済みの前記所定のデータ種別を指定した第２収集要求による該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記所定のデータ種別、前記第１収集要求で指定されたタイミング、及び相対的にコストの低いルートが指定された収集要求が、前記ネットワークデバイスに対して送信される、ことを特徴とする。

本発明によれば、複数サービスのそれぞれのために、デバイスから必要なデータ収集する際に、効率的にデータ収集ができる方式を提供することができる。

本発明におけるシステムの全体構成を示す模式図 情報処理装置のハードウェア構成の一例を示すブロック図 本発明におけるシステム内の各装置の機能構成の一例を示すブロック図 デバイス管理サーバーにおけるデータ収集要求処理を説明するためのフローチャート データ収集要求のマージ処理の詳細を説明するためのフローチャート マージ結果の補正処理の詳細を説明するためのフローチャート

以下、本発明を実施するための最良の形態について図面を用いて説明する。

（実施例１）
＜システム構成＞
図１は、本発明におけるシステム全体の構成例を示す図である。

図１において、１０１は、複数のサービス提供サーバーで、デバイス１０３から収集したデータを利用して顧客にサービスを提供する。サービス提供サーバー１０１は、サービス内容に応じて複数存在する形態でも良いし、１つのサーバーシステム上に複数のサービスが実現されても良い。１０２は、デバイス管理サーバーで、各サービスのデバイスへのデータ収集要求を管理する。さらに、収集タイミングや収集対象のデータの種別、収集方式などを定義するデータ収集要求をデバイス１０３へ送信する。収集方式で規定される送信先として、データストリーム１０４、データストア１０５がある。

なお、サービス提供サーバー１０１及びデバイス管理サーバー１０２のそれぞれは、クラウド基盤上に構築され、１台以上のコンピューター（情報処理装置）からなる仮想化システム上で実現することができる。データストリーム１０４、データストア１０５も、同じクラウド基盤上に構築することができる。

１０３は、ネットワークデバイス（以降、デバイスとも呼ぶ）で、デバイス管理サーバー１０１から受信したデータ収集要求にもとづき各種データ（使用実績、ステータス、エラー情報など）を収集し、ネットワークを介して外部に送信する。本発明のシステムには、複数のデバイスが接続されている。デバイスには、複合機やプリンター、ネットワークカメラなどの画像形成装置や、デジタル医療機器、家電、デジタル健康機器などが含まれる。本発明の対象となるデバイスは、サービス提供サーバー１０１が提供する各サービスと契約した顧客が持つネットワーク環境に設置され、デバイス管理サーバー１０２に登録されるデバイスである。

１０４は、データストリームであり、デバイス１０３から受信した各種データを、その受信データを必要とするサービス提供サーバー１０１へ送信する。その一方で、デバイス１０３から受信した各種データを、データストア１０５にも格納する。

１０５は、データストアであり、デバイス１０３からの要求に従い、デバイス１０３内で収集された各種データを格納する。ここで格納されたデータは、そのデータを必要とするサービス提供サーバー１０１のサービスから参照可能となる。データストア１０５は、ストレージサービスサーバーであり、大容量のストレージを提供するシステムである。

サービス提供サーバー１０１、デバイス管理サーバー１０２、デバイス１０３、データストリーム１０４、データストア１０５は、ネットワーク１０６を介して接続されている。ネットワーク１０６は、例えば、インターネットなどのＬＡＮ、ＷＡＮ、電話回線、専用デジタル回線、ＡＴＭやフレームリレー回線、ケーブルテレビ回線、データ放送用無線回線等のいずれか、または組み合わせにより実現される通信ネットワークである。

＜情報処理装置のハードウェア構成＞
図２は、サービス提供サーバー１０１、デバイス管理サーバー１０２、デバイス１０３を実現する情報処理装置のハードウェア構成の一例を示すブロック図である。

情報処理装置は、記憶装置であるハードディスクドライブ（ＨＤＤ）２０３に記憶されたソフトウェアを実行するＣＰＵ２０１を備える。ＣＰＵ２０１はシステムバス２０４に接続される各ハードウェアを総括的に制御する。メモリー２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。ハードディスクドライブ（ＨＤＤ）２０３は、大容量記憶装置としてデータを記録する。入力制御部２０５は、例えばキーボードなどの入力装置２０６からの入力を制御する。なお、情報処理装置の役割によっては、入力制御部２０５、入力装置２０６がない構成でも良い。表示制御部２０７は、例えば液晶ディスプレイなどの表示装置２０８への表示を制御する。なお、情報処理装置の役割によっては、表示制御部２０７、表示装置２０８がない構成でも良い。ネットワーク制御部２０９は、ネットワークを介して、他のノードと双方向にデータをやりとりする。後述の図３に示す各装置の機能は、各装置のＣＰＵ２０１が装置内の機能を実現するためのプログラムを実行することで実現されることになる。

サービス提供サーバー１０１、デバイス管理サーバー１０２を構成する情報処理装置は、クラウドコンピューティングサービスとして提供される情報処理装置によって実現される。クラウドコンピューティングとしては、サーバーレスコンピューティングや仮想マシンなどがある。クラウドコンピューティングでは、図２に示したハードウェアリソースが複数利用される。なお、サーバー１０１、１０２が、それぞれ１台の物理マシンで実現される構成でも良い。

＜機能構成＞
図３は、サービス提供サーバー１０１、デバイス管理サーバー１０２、デバイス１０３の機能構成の一例を示すブロック図である。

サービス提供サーバー１０１は、収集要求送信部３０１、データ受信部３０２、データ取得部３０３、サービス提供部３０８を有する。

収集要求送信部３０１は、サービスを提供するために必要なデータをデバイスから収集するために、データ収集要求を作成し、デバイス管理サーバー１０２へ送信する。データ収集要求は、デバイスを保有する顧客がサービスに契約した時、顧客がそのサービスのためにデータを収集することに同意した時、サービス対象のデバイスが追加された時などに作成される。また、データ収集要求には、デバイスからの特定のデータの収集を停止する要求も含まれる。データ収集を停止する要求は、顧客がサービスを停止や解約した場合、顧客がデータを収集することを拒否した場合、サービス対象のデバイスが削除された場合などに作成される。

データ受信部３０２は、デバイスからのデータを、データストリーム１０４を介して受信する。データ取得部３０３は、データストア１０５に格納済みのデバイスからのデータを、データストア１０５に対して要求することで取得する。なお、提供するサービスによっては、データ受信部３０２、データ取得部３０３の何れかのみを持つ構成であってもよい。サービス提供部３０８は、データ受信部３０２、データ取得部３０３の何れか、または両方が取得したデータを用いて、顧客によって規約されたサービスを提供する。サービスの具体例としては、消耗品の自動配送サービスや、デバイスデータのバックアップ・リストアサービス、デバイスの稼働情報のレポーティングサービス、デバイス利用者に関するレポーティングサービスなどがある。

デバイス管理サーバー１０２は、収集要求管理部３０４、通知部３０５、デバイス管理部３０９を有する。デバイス管理部３０９は、デバイス管理サーバー１０２の管理対象となるデバイスの識別情報やデバイスを保有する顧客情報などを管理する。サービス提供サーバー１０１のサービス提供の対象となるデバイスは、デバイス管理部３０９によって管理されている識別情報に対応するデバイスのいずれかとなる。

収集要求管理部３０４は、収集要求送信部３０１から送信されてきたデータ収集要求を受信して、保存する。通知部３０５は、収集要求管理部３０４からの指示に従い、デバイスに対してデータ収集要求を送信する。

デバイス１０３は、通知処理部３０６、データ収集部３０７を有する。通知処理部３０６は、通知部３０５から受信したデータ収集要求を処理する。そして、データ収集部３０７に転送する。なお、デバイス１０３の通知処理部３０６がデバイス管理サーバー１０２から定期的にデータ収集要求を取得する構成にすることも可能である。データ収集部３０７は、受信したデータ収集要求にもとづき、指定されたタイミングで各種データを収集し、データストレージ１０４、またはデータストア１０５へ送信する。

表Ａは、デバイス管理サーバー１０２の収集要求管理部３０４が、受信したデータ収集要求に基づく各サービスのデータ収集要求を管理するためのテーブルの一例を示す表である。

表Ａでは、データ収集要求の対象となるデバイスの識別子であるデバイスＩＤ、要求元であるサービスの識別子であるサービスＩＤ、収集対象のデータの種別、収集するタイミング、収集するルートを管理する。

収集するタイミングとしては、すくなくとも３パターンが指定できる。１つは、対象データに関するイベントが発生した際に、そのタイミングでデバイスがデータを収集して送信する“イベント発生時”がある。さらに、指定した時間間隔でデバイスが対象データを収集して送信する“間隔指定”がある。さらに、指定した時刻にデータを収集して送信する“時刻指定”がある。

収集するルートとは、デバイスが収集したデータをどの方式で送信するかを示すものである。収集するルートとしては、収集したデータをデータストリーム１０４に送信する“データストリーム”、収集したデータをデータストア１０５に格納する“データストア”などがある。

各サービスは、データ処理及びサービス提供のために即時性が必要なデータについてはデータストリームを指定する。即時性が不要で、データ収集と非同期に処理すれば良いデータについては、データストアを指定する。また、クラウド基盤を利用して構築される情報処理システムにおいては、データをデータストアに送信するよりもデータストリームに送信する方が相対的に高コスト（処理負荷、費用など）である。各サービスは、提供するサービスの特性に応じて、各データをデータストリームに送信するか、データストアに送信するかを決めることが可能である。データストアのみに低頻度で送信されるデータの例としては、顧客の運用に直接的に関係しないデータ分析に利用されるようなログやセンサデータである。一方で、顧客の運用に大きな影響がある稼働情報や特別なログ、障害情報などについては、データストリームが利用され得る。

なお、表Ａで示すテーブルは、デバイス管理サーバー１０２ではなく、ネットワークを介して接続される別のサーバーが保持する構成でも良い。その場合は、デバイス管理サーバー１０２が表Ａで示すテーブルに参照可能なように構築される。

収集要求管理部３０４は、各サービスのデータ収集要求をデバイスごとにマージして、通知部３０５を介して各デバイスへ送信する。マージ処理の詳細は後述する。

表Ｂは、収集要求管理部３０４が保持し、通知部３０５がデバイスに対して送信済みデータ収集要求を管理するテーブルの一例を示す表である。ここで、表Ｂは、表Ａで示したデバイスＩＤが“Ｄｅｖｉｃｅ００１”のデバイスに対して送信されたデータ収集要求の例を示している。なお、本テーブルは、デバイス管理サーバー１０２ではなく、ネットワークを介して接続される別のサーバーが保持する構成でも良い。

＜データ収集要求処理＞
図４は、デバイス管理サーバーの収集要求管理部３０４が実行するデータ収集要求処理を説明するためのフローチャートである。収集要求管理部３０４は、各サービスのサービス提供サーバー１０１からデータ収集要求を受信して保存した後に、本処理を実行する。なお、フローチャートで示す手順は、メモリー２０２、ハードディスクドライブ（ＨＤＤ）２０３のいずれかの記憶装置に記憶され、ＣＰＵ２０１により実行される。

Ｓ４０１で、収集要求管理部３０４は、新たに保存されたデータ収集要求の対象となったデバイスについて、各サービスからの複数のデータ収集要求をマージする。データ収集要求のマージ処理の詳細については、図５を用いて後述する。

Ｓ４０２で、収集要求管理部３０４は、Ｓ４０１でマージしたデータ収集要求を補正する。データ収集要求の補正処理の詳細については、図６を用いて後述する。

Ｓ４０３で、収集要求管理部３０４は、Ｓ４０２で補正したデータ収集要求を、通知部３０５を介して対象のデバイス１０３へ送信する。

Ｓ４０４で、収集要求管理部３０４は、Ｓ４０３で送信したデータ収集要求をテーブルへ保存し、本処理を終了する。

＜データ収集要求のマージ処理＞
図５は、図４に示したＳ４０１で実行するデータ収集要求のマージ処理の詳細を説明するためのフローチャートである。

マージ処理では、各サービスから新たに受け付けたデータ収集要求により、既存の収集設定が更新されるデバイスを対象に実行される。具体的には、既に保存済みの収集要求に含まれる対象データ、収集タイミング、収集ルートと、新たに受け付けたデータ収集要求とに基づきマージ処理が行われる。なお、サービスからは複数のデータ収集要求が一緒に送信されてきて、デバイス管理サーバーでまとめてそれらが保存されることもある。

本処理により、新たなデータ収集要求の送信元以外のサービスが必要としているデータの収集を停止や、同じデータの重複送信などを防止することができる。これにより、正常なサービス提供を継続でき、かつ、無駄なトラフィックやコストを発生させずに、効率的にデータ収集ができる。

Ｓ５０１で、収集要求管理部３０４は、新たに受け付けたデータ収集要求の対象となるデバイスについて、表Ａで管理されている各サービスからのデータ収集要求を取得する。取得されたデータ収集要求を送信対象テーブルに格納して管理する。Ｓ５０２で、収集要求管理部３０４は、Ｓ５０１で取得した各サービスのデータ収集要求について、同じデータ種別を対象とする収集要求ごとにグループ（以降、要求グループと呼ぶ）にする。表Ａの例では、“ＤａｔａＸ”を対象とする複数のデータ収集要求を含むグループと、“ＤａｔａＹ”を対象とする複数のデータ収集要求を含むグループと、の２つの要求グループが作成され得る。

収集要求管理部３０４は、Ｓ５０２で作成した要求グループのそれぞれに対して、Ｓ５０３〜Ｓ５１３に示すループ処理を実行する。作成された全てのグループに対して処理が完了すると、Ｓ５１３で示す通り、ループ処理を抜けて、図５で示す処理が終了する。

Ｓ５０４で、収集要求管理部３０４は、処理対象の要求グループ内に、同じタイミング、かつ、同じルートの要求があるか否かを判定する。例えば、２つのデータ収集要求のタイミングの指定が“イベント発生時”なら同じタイミングと判定される。また、２つのデータ収集要求のタイミングの指定が“間隔指定”である場合は指定されている時間間隔が一致する場合に同じタイミングと判定される。また、２つのデータ収集要求のタイミングの指定が“時刻指定”である場合は指定されている時刻が一致する場合に同じタイミングと判定される。ここで収集要求管理部３０４が、同じタイミング、かつ、同じルートの要求があると判定した場合はＳ５０５に進む。一方で、収集要求管理部３０４が、同じタイミング、かつ、同じルートの要求がないと判定した場合はＳ５０６に進む。

Ｓ５０５で、収集要求管理部３０４は、送信対象テーブルに含まれる、同じタイミング、かつ、同じルートの複数のデータ収集要求について、１件のみ残し、その他のデータ収集要求を削除する。

Ｓ５０６で、収集要求管理部３０４は、処理対象の要求グループ内に、同じタイミング、かつ、異なるルートの要求があるか否かを判定する。ここで収集要求管理部３０４が、該当する要求があると判定した場合はＳ５０７に進む。一方で、収集要求管理部３０４が、該当する要求がないと判定した場合はＳ５０８に進む。

Ｓ５０７で、収集要求管理部３０４は、送信対象テーブルに含まれる、同じタイミング、かつ、異なるルートの複数の要求について、ルートがデータストリームのデータ収集要求を１つ残し、その他のデータ収集要求を削除する。ここで、削除されるデータ収集要求とは、ルートがデータストアである要求となる。

Ｓ５０８で、収集要求管理部３０４は、処理対象の要求グループ内に、タイミングが間隔指定でその指定間隔がそれぞれ異なり、かつ、同じルートの要求があるか否かを判定する。ここで、収集要求管理部３０４が、該当する要求があると判定した場合はＳ５０９に進む。一方で、該当する要求がないと判定した場合はＳ５１０に進む。

Ｓ５０９で、収集要求管理部３０４は、送信対象テーブルに含まれる、タイミングが間隔指定でその指定間隔がそれぞれ異なり、かつ、同じルートの複数の要求について、最も短い時間間隔が指定されたデータ収集要求を１つ残し、その他のデータ収集要求を削除する。

Ｓ５１０で、収集要求管理部３０４は、処理対象の要求グループ内に、タイミングが間隔指定でその指定間隔がそれぞれ異なり、かつ、異なるルートの要求があるか否かを判定する。ここで、収集要求管理部３０４が、該当する要求があると判定した場合はＳ５１１に進む。一方、収集要求管理部３０４が、該当する要求がないと判定した場合はＳ５１３に進む。

Ｓ５１１で、収集要求管理部３０４は、タイミングが間隔指定でその指定間隔がそれぞれ異なり、かつ、異なるルートの要求について、ルートが“データストリーム”のデータ収集要求で指定された時間間隔が、ルートが“データストア”のデータ収集要求で指定された時間間隔より短いか否かを判定する。ここで、収集要求管理部３０４が、ルートが“データストリーム”のデータ収集要求の方が、指定された時間間隔が短いと判定した場合はＳ５１２に進む。一方で、収集要求管理部３０４が、ルートが“データストリーム”のデータ収集要求の方が、指定された時間間隔が長いと判定した場合はＳ５１３に進む。

Ｓ５１２で、収集要求管理部３０４は、送信対象テーブルに含まれる、タイミングが間隔指定でその指定間隔がそれぞれ異なり、かつ、異なるルートの要求について、ルートとして“データストリーム”が指定されたデータ収集要求を１つ残し、その他のデータ収集要求を削除する。

全ての要求グループを処理した場合に、図４のフローチャートに戻る。複数のサービス提供サーバーから同じネットワークデバイスを対象とする複数の収集要求を受信した場合に、図５で上記した各条件で残すことで、該ネットワークデバイスに設定されるべきデータ収集要求の候補として選択されることになり、それらを送信対象テーブルで管理することができる。

＜データ収集要求の補正処理＞
図６は、図４に示したＳ４０２で実行するデータ収集要求の補正処理の詳細を説明するためのフローチャートである。

あるサービスがデータ収集を停止する要求をした場合などに、所定のデータ種別のデータの収集頻度が低くなることがある。データ収集頻度が低くなると、提供されるサービスの精度が落ちることがあり得る。収集したデータを分析して利活用しているような場合、データ分析の精度も落ち、データを活用した意思決定のスピードが落ちてしまう可能性がある。

本処理は、その問題を抑止するための処理である。Ｓ４０１や図５で示す処理に基づきマージされたデータ収集要求（新要求）を含む送信対象テーブルを補正する。具体的には、図５のＳ５０５、Ｓ５０７、Ｓ５０９、Ｓ５１２の処理で、削除されずに残されたデータ収集要求を新要求と呼び、これら新要求に対して補正などの処理を行う。これにより、デバイスから収集されるデータの精度が落ちないように維持する。また、データの精度を維持する際に、より低コストの収集ルートを使用するよう自動決定する。

Ｓ６０１で、収集要求管理部３０４は、Ｓ４０１の処理の対象となったデバイスについて、それ以前に通知部３０５がデバイスに送信していたデータ収集要求（旧要求と呼ぶ）を、表Ｂで示したテーブルから取得する。

収集要求管理部３０４は、新要求のそれぞれに対して、Ｓ６０２〜Ｓ６０７に示すループ処理を実行する。全ての新要求に対して処理が完了すると、Ｓ６０７で示す通り、ループ処理を抜けて、図６で示す処理が終了する。

Ｓ６０３で、収集要求管理部３０４は、同じデータ種別を対象とし、かつ、同じルートを指定する新要求と旧要求を比較し、収集頻度が低くなるか否かを判定する。ここでは、データ収集要求のタイミングで指定される時間間隔について、新要求が旧要求よりも長い時間が指定されている場合に収集頻度が低くなると判定される。収集要求管理部３０４が、収集頻度が低くなると判定した場合はＳ６０４に進む。一方で、収集要求管理部３０４が、収集頻度が高くなると判定した場合はＳ６０７に進む。

Ｓ６０４で、収集要求管理部３０４は、新要求に指定されているルートを確認する。ここで、収集要求管理部３０４が、ルートが“データストリーム”であると判定した場合はＳ６０５に進む。一方で、収集要求管理部３０４が、ルートが“データストア”であると判定した場合はＳ６０６に進む。

Ｓ６０５で、収集要求管理部３０４は、旧要求のルートについて“データストア”を適用した新たなデータ収集要求を自動作成し、送信対象テーブルに追加する。

Ｓ６０６で、収集要求管理部３０４は、新要求のタイミングとしての間隔指定に対して、旧要求のタイミングで指定されていた時間間隔を適用する。

その後、収集要求管理部３０４が、未処理の要求がないと判定した場合、図４のフローチャートに戻る。そして、Ｓ４０３で、送信対象テーブルに含まれるデータ収集要求が、デバイスへ送信されることになる。

＜図４で示す処理が適用された場合の具体例について＞
表Ｂで示したデータ収集要求をデバイスへ送信した後に、表Ａで示したサービスＩＤがＳｅｒｖｉｃｅＣのサービスがデータ収集を停止する要求をした場合の例を示す。

サービスＩＤがＳｅｒｖｉｃｅＣのサービスがデータ収集を停止する要求をした場合、表Ａで示したテーブルから４レコード目のデータ収集要求を削除する。データ収集要求を削除した後、デバイスＩＤがＤｅｖｉｃｅ００１のデバイスについて、図５で説明した処理により、各サービスのデータ収集要求についてマージ処理が行われる。

表Ｃは、ＳｅｒｖｉｃｅＣのサービスがデータ収集を停止するデータ収集要求を送信してきた場合に行われたマージ処理の後の送信対象テーブルを示している。

さらに、表Ｄは、表Ｃに対して図６で説明した補正処理を行った場合の送信対象テーブルを示している。

表Ｄでは、Ｓ６０５に示す処理により、５レコード目で示すデータ収集要求が自動作成され追加されている。これは、低コストの収集ルートである“データストア”を使用してデータ収集することで、データ精度を維持することを意味している。例えば、そのデータを分析していたＳｅｒｖｉｃｅＣ以外のサービスにおけるデータ分析の精度などが維持されることになる。

（他の実施例）
本発明は、上述した実施形態を適宜組み合わせることにより構成された装置あるいはシステムやその方法も含まれるものとする。

ここで、本発明は、上述した実施形態の機能を実現する１以上のソフトウェア（プログラム）を実行する主体となる装置あるいはシステムである。また、その装置あるいはシステムで実行される上述した実施形態を実現するための方法も本発明の一つである。また、そのプログラムは、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給され、そのシステム或いは装置の１以上のコンピュータ（ＣＰＵやＭＰＵ等）によりそのプログラムが読み出され、実行される。つまり、本発明の一つとして、さらにそのプログラム自体、あるいは該プログラムを格納したコンピューターにより読み取り可能な各種記憶媒体も含むものとする。また、上述した実施形態の機能を実現する回路（例えば、ＡＳＩＣ）によっても、本発明は実現可能である。

１０１ サービス提供サーバー
１０２ デバイス管理サーバー
１０３ ネットワークデバイス
３０４ 収集要求管理部

Claims (8)

1. ネットワークデバイスに対して、データ種別とタイミングと収集のためのルートが指定された収集要求を送信するデバイス管理サーバーであって、
   １以上のサービス提供サーバーから、対象となるデバイスとデータ種別とタイミングと収集のためのルートが指定された収集要求を受信する受信手段と、
   同じネットワークデバイスを対象とする複数の収集要求を受信した後に、該複数の収集要求の中から、各収集要求で指定されているタイミングとルートに基づいて、該ネットワークデバイスに設定されるべき１以上の収集要求を選択する選択手段と、
   前記選択された１以上の収集要求をネットワークデバイスに対して送信する送信手段と、を有し、
   前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスに対して既に送信済みの前記所定のデータ種別を指定した第２収集要求による該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記所定のデータ種別、前記第１収集要求で指定されたタイミング、及び相対的にコストの低いルートが指定された収集要求が、前記ネットワークデバイスに対して送信される、ことを特徴とするデバイス管理サーバー。
2. 前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスに対して既に送信済みの前記所定のデータ種別を指定した第２収集要求による該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記第１収集要求の代わりに、前記所定のデータ種別、前記第１収集要求で指定されたタイミング、及び相対的にコストの低いルートが指定された収集要求が、前記ネットワークデバイスに対して送信されることを特徴とする請求項１に記載のデバイス管理サーバー。
3. 前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスに対して既に送信済みの前記所定のデータ種別を指定した第２収集要求による該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記第１収集要求に加えて、前記所定のデータ種別、前記第１収集要求で指定されたタイミング、及び相対的にコストの低いルートが指定された収集要求が、前記ネットワークデバイスに対して送信されることを特徴とする請求項１に記載のデバイス管理サーバー。
4. 前記選択手段は、指定されているタイミングとルートとが同じである複数の収集要求から、１つの収集要求を選択することを特徴とする請求項１乃至３のいずれか１項に記載のデバイス管理サーバー。
5. 前記選択手段は、指定されているタイミングが同じで、ルートの指定がそれぞれ異なる複数の収集要求から、相対的にコストの高いルートが指定された１つの収集要求を選択することを特徴とする請求項１乃至４のいずれか１項に記載のデバイス管理サーバー。
6. 前記選択手段は、指定されているルートが同じで、タイミングとして異なる時間間隔をそれぞれ指定する複数の収集要求から、最も短い時間間隔が指定された１つの収集要求を選択することを特徴とする請求項１乃至５のいずれか１項に記載のデバイス管理サーバー。
7. ネットワークデバイスに対して、データ種別とタイミングと収集のためのルートが指定された収集要求を送信するデバイス管理サーバーにおける方法であって、
   １以上のサービス提供サーバーから、対象となるデバイスとデータ種別とタイミングと収集のためのルートが指定された収集要求を受信する受信工程と、
   同じネットワークデバイスを対象とする複数の収集要求を受信した後に、該複数の収集要求の中から、各収集要求で指定されているタイミングとルートに基づいて、該ネットワークデバイスに設定されるべき１以上の収集要求を選択する選択工程と、
   前記選択された１以上の収集要求をネットワークデバイスに対して送信する送信工程と、を有し、
   前記選択された１以上の収集要求に含まれる所定のデータ種別を指定した第１収集要求が送信されることで、前記ネットワークデバイスに対して既に送信済みの前記所定のデータ種別を指定した第２収集要求による該所定のデータ種別のデータの収集の頻度が低くなる場合には、前記所定のデータ種別、前記第１収集要求で指定されたタイミング、及び相対的にコストの低いルートが指定された収集要求が、前記ネットワークデバイスに対して送信される、ことを特徴とする方法。
8. 請求項１乃至６のいずれか１項に記載の各手段としてコンピューターを機能させるためのプログラム。

Images