JP7365832B2 - デバイス管理システム及びその制御方法 - Google Patents

Description

本発明は、デバイス管理システム及びその制御方法に関する。

従来、画像形成装置などのデバイスを一元管理するためのデバイス管理システムがある。デバイス管理システムは、管理しているデバイスから各種データを収集する機能や、収集したデータを利用して顧客に各種サービスを提供する機能を持つ。各サービスは、サービスを提供するために必要となるデータを、データ収集モジュールを用いて、デバイスから収集する。

一方、データ収集モジュールにも様々な機能上の差異が存在し、例えば、通知機能の有無や送信可能なデータの項目であるデータ属性の対応・非対応などの違いがある。また、各データ収集モジュールが送信可能なデータ属性は、デバイスのファームウェアバージョンなどのデバイスの能力によっても対応・非対応が決まる。そのため、各サービスの提供者は、提供するサービスの特性に応じて、各データをどのデータ収集モジュールで送信するかを決める。また、近年、データを利活用する目的で、収集したデータを一箇所に集約して管理することが求められている。このような場合、各データ収集モジュールにより送信されたデータは、最終的には一箇所に集約して管理することになる。

特許文献１には、複数のデータ収集モジュールによってデータを収集するデバイス管理システムにおいて、同一のデータがデバイスから収集されている場合、同一のデータを送信しているデータ収集モジュールのうち、任意のひとつを除いたデータ収集モジュールを全て送信停止させる技術が開示されている。

特開２０１７－１２３０５８号公報

複数のサービスを提供している環境において、各サービスが同じデバイスに複数のデータ収集モジュールを用いてデータ収集要求をすると以下のような課題が発生する。複数のデータ収集モジュールを用いて同一のデータ属性を収集するため、顧客環境とデバイス管理システム運用環境のいずれにおいても無駄なトラフィックが発生する。また、同一データ収集モジュールによりデータを収集したとしても、デバイスのファームウェアバージョンなどの違いにより、データ収集モジュールが送信できるデータ属性は異なる。さらに、データ収集モジュールによって対応可能なデータの送信手段は異なるため、デバイスへ送信されるデータが同一なものか否かを確認できない可能性がある。このため、任意のデータ収集モジュールのデータ送信を停止させるだけでは、デバイス管理システムが、デバイスから取得できるはずであったデータ属性が取得できなくなる可能性がある。

本発明は、上記課題に鑑み、複数のサービスがデバイスから複数のデータ収集モジュールを用いてデータ収集する環境において、効率的にデータを収集することを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、データを送信する複数のモジュールを備えるデバイスを管理するデバイス管理システムであって、前記デバイスのデータに対する要求を受信する受信手段と、前記受信手段にて受信した要求に基づき、前記デバイスから送信されるべきデータの属性を決定する決定手段と、前記決定手段にて決定したデータの属性に応じて、当該データを送信するモジュールを前記複数のモジュールの中から割り当てる割り当て手段と、前記割り当て手段による割り当てに基づいて、前記デバイスのモジュールにデータの送信を要求する要求手段とを備え、前記割り当て手段は、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から割り当てた後に、前記デバイスにて動作するソフトウェアのバージョンが更新されたことに応じて、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から再度、割り当てる。

本願発明により、複数のサービスが複数のデータ収集モジュールを用いてデバイスからデータ収集する環境において、効率的にデータ収集を行うことができる。

本発明の第１の実施形態に係るシステムの全体構成を示す模式図。 本願発明の一実施形態に係る情報処理装置のハードウェア構成の例を示す図。 本発明の第１の実施形態に係る機能構成の例を示す図。 第１の実施形態に係るデータ収集要求処理を示すフローチャート。 第１の実施形態に係るデータ収集要求のグループ化処理のフローチャート。 第１の実施形態に係る収集データ属性の割り振り処理のフローチャート。 第１の実施形態に係る収集データ属性の再割り振り処理のフローチャート。 本発明の第２の実施形態に係るシステムの全体構成を示す模式図。 本発明の第２の実施形態に係る機能構成の一例を示すブロック図。 第２の実施形態に係るサービスの切り替え処理を示すフローチャート。 第２の実施形態に係るデータ収集モジュールの停止処理を示すフローチャート。 第２の実施形態に係るアップデート待ち停止処理を示すフローチャート。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
［システム構成］
図１は、本発明の第１の実施形態に係るシステムの全体構成の例を示す図である。図１において、サービス提供サーバー１０１は、デバイス１０３から収集したデータを利用して顧客に各種サービスを提供する。サービス提供サーバー１０１は、サービス内容に応じて複数存在する。デバイス管理サーバー１０２は、各種サービスに用いられるデータを収集するための、デバイス１０３へのデータ収集要求を管理する。さらに、デバイス管理サーバー１０２は、データ収集要求をデバイス１０３へ送信する。デバイス１０３は、デバイス管理サーバー１０２から受信したデータ収集要求に基づき自装置における各種データ（使用実績、ステータス、エラー情報など）を収集し、データストリーム１０４、またはデータストア１０５へ送信する。

データストリーム１０４は、デバイス１０３から受信した各種データを、サービス提供サーバー１０１へ送信する。また、データストリーム１０４は、デバイス１０３から受信した各種データを、データストア１０５へ送信する。データストア１０５は、デバイス１０３から収集した各種データを格納する。データ変換サーバー１０６は、デバイス１０３から受信した各種データを、サービス提供サーバー１０１が処理可能なデータ形式に変換し、データストリーム１０４に送信する。

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

［ハードウェア構成］
図２は、本実施形態に係るサービス提供サーバー１０１、デバイス管理サーバー１０２、デバイス１０３、およびデータ変換サーバー１０６に適用可能な情報処理装置２００のハードウェア構成の一例を示す図である。

ＣＰＵ２０１は、システムバス２０４に接続される各ハードウェアを総括的に制御する。ＣＰＵ２０１は、記憶装置であるハードディスクドライブ（ＨＤＤ）２０３に記憶されたソフトウェアを実行することで各種処理を実現する。メモリー２０２は、ＣＰＵ２０１の主メモリー、ワークエリア等として機能する。ＨＤＤ２０３は、大容量記憶装置としてデータを記録する。入力制御部２０５は、例えば、キーボードなどの入力装置２０６からの入力を制御する。なお、情報処理装置２００の役割によっては、入力制御部２０５や入力装置２０６がない構成であってもよい。

表示制御部２０７は、例えば、液晶ディスプレイなどの表示装置２０８への表示を制御する。なお、情報処理装置２００の役割によっては、表示制御部２０７や表示装置２０８がない構成であってもよい。ネットワーク制御部２０９は、ネットワーク１０７を介して、外部装置と双方向にデータをやりとりする。

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

［機能構成］
図３は、本実施形態に係るサービス提供サーバー１０１、デバイス管理サーバー１０２、デバイス１０３、およびデータ変換サーバー１０６の機能構成の一例を示す図である。本実施形態において、各装置の各機能は、例えば情報処理装置２００のＣＰＵ２０１がＨＤＤ２０３等に格納されたプログラムをそれぞれ読み出して実行することにより実現されてよい。

サービス提供サーバー１０１は、データ収集要求送信部３０１、データ受信部３０２、およびデータ取得部３０３を備える。データ収集要求送信部３０１は、サービスを提供するために必要なデータをデバイス１０３から収集するために、データ収集要求を作成し、デバイス管理サーバー１０２のデータ収集要求管理部３０４へ送信する。データ収集要求は、顧客がサービスを開始した場合、顧客がデータを収集することに同意した場合、サービス対象のデバイスが追加された場合などに行われる。また、本実施形態において、データ収集要求には、デバイス１０３からのデータ収集を停止する要求も含む。データ収集を停止する要求は、顧客がサービスを停止や解約した場合、顧客がデータを収集することを拒否した場合、サービス対象のデバイスが削除された場合などに行われる。

データ受信部３０２は、デバイス１０３からのデータを、データストリーム１０４を介して受信する。データ取得部３０３は、デバイス１０３からのデータを、データストア１０５から取得する。なお、サービス提供サーバー１０１において、提供するサービスによっては、データ受信部３０２、またはデータ取得部３０３がない構成であってもよい。

デバイス管理サーバー１０２は、データ収集要求管理部３０４、プッシュ通知管理部３０５、データ収集モジュール管理部３０６、およびバージョン管理部３０７を備える。データ収集要求管理部３０４は、サービス提供サーバー１０１のデータ収集要求送信部３０１が送信するデータ収集要求を受信し、管理する。

表１は、データ収集要求管理部３０４が保持し、各サービスのデータ収集要求を管理するテーブルの一例を示す表である。本テーブルでは、要求先デバイスの識別子であるデバイスＩＤ、要求元サービスの識別子であるサービスＩＤ、収集対象のデータ、および収集するルートを管理する。収集するルートとは、デバイス１０３からのデータをどの方式（経路）で収集するかを示すものである。収集するルートとしては、データストリーム１０４を介してデータを収集するデータストリーミング、データストア１０５を介してデータを収集するデータストアなどがある。ここで、即時性が必要なデータについては「データストリーム」を指定し、即時性が不要なデータについては「データストア」を指定する。そのため、各サービスは、提供するサービスの特性に応じて、各データをデータストリーム１０４に送信するか、データストア１０５に送信するかが設定される。なお、本テーブルは、デバイス管理サーバー１０２ではなく、ネットワーク１０７を介して接続される別のサーバーが保持する構成であっても良い。

さらに、データ収集要求管理部３０４は、各サービスのデータ収集要求をマージして、プッシュ通知管理部３０５を介してデバイス１０３やデータ変換サーバー１０６へ送信する。

表２は、データ収集要求管理部３０４が保持し、デバイス１０３へ送信したデータ収集要求を管理するテーブルの一例を示す表である。表２に示すデータ収集要求は、表１で示したデバイスＩＤが「Ｄｅｖｉｃｅ００１」のデバイス１０３について、各サービスのデータ収集要求をマージし、グループ化した結果である。なお、本テーブルは、デバイス管理サーバー１０２ではなく、ネットワーク１０７を介して接続される別のサーバーが保持する構成であってもよい。

プッシュ通知管理部３０５は、受信したデータや要求を、指定された通知先に送信する。本実施形態では、データ収集要求管理部３０４が送信するデータ収集要求を受信し、デバイス１０３の第１データ収集モジュール３０８のプッシュ通知受信部３０９と、データ変換サーバー１０６のプッシュ通知管理部３１５へ送信する。

データ収集モジュール管理部３０６は、デバイス１０３が備えるデータ収集モジュール情報を受信し、保存する。また、データ収集モジュール管理部３０６は、指定された要求に対するデータを、指定された通知先に送信する。本実施形態では、データ収集モジュール管理部３０６は、データ収集要求管理部３０４からデバイス１０３のデータ収集モジュール情報の送信要求を受信し、データ収集モジュール情報をデータ収集要求管理部３０４に送信する。

表３は、データ収集モジュール管理部３０６が保持し、各エージェント情報を管理するテーブルの一例を示す表である。本テーブルでは、デバイス１０３の識別子であるデバイスＩＤ、データ収集モジュールの識別子であるデータ収集モジュールＩＤ、および優先度フラグを管理する。優先度フラグは、デバイス１０３が備えるデータ収集モジュールのうち、該当データ収集モジュールのデータ属性取得が他のデータ収集モジュールよりも優先なものかを示す。本実施形態において、優先度フラグは「ｔｒｕｅ」もしくは「ｆａｌｓｅ」の値が設定され、優先度フラグの初期値は「ｆａｌｓｅ」である。データ収集モジュール情報の例については、後述する。

バージョン管理部３０７は、デバイス１０３が備えるバージョン情報を受信し、保存する。本実施形態では、デバイス１０３のデバイス情報管理部３１４が送信するバージョン情報を受信し、保存する。バージョン情報には、デバイス１０３にて動作するファームウェアなどのソフトウェアのバージョンを少なくとも含む。また、バージョン管理部３０７は、バージョン情報のうち、更新された情報をデータ収集要求管理部３０４に送信する。なお、本実施形態においては、デバイスが備えるファームウェアのバージョン情報を用いて説明しているが、これに限定するものではない。例えば、ファームウェア以外のアプリケーションとして実現されているデータ収集モジュールのバージョンなどが用いられてもよい。

表４は、バージョン管理部３０７が保持し、デバイス１０３が備えるバージョン情報を管理するテーブルの一例を示す表である。本テーブルでは、要求先デバイスの識別子であるデバイスＩＤ、およびファームウェアバージョンを管理する。

デバイス１０３は、第１データ収集モジュール３０６、第２データ収集モジュール３０７、およびデバイス情報管理部３１４を備える。第１データ収集モジュール３０８は、プッシュ通知受信部３０９、およびデータ収集部３１０を備える。プッシュ通知受信部３０９は、受信したデータや要求を、指定された通知先に送信する。本実施形態では、プッシュ通知受信部３０９は、デバイス管理サーバー１０２から受信したデータ収集要求を、データ収集部３１０へ送信する。また、プッシュ通知受信部３０９は、データ収集部３１０が収集したデータ属性の集合である収集可能データ属性を取得して、デバイス管理サーバー１０２のプッシュ通知管理部３０５へ送信する。データ収集部３１０は、プッシュ通知受信部３０９からデータ収集要求を受信し、受信したデータ収集要求に基づき、各種データ属性を収集する。そして、データ収集部３１０は、収集した各種データ属性をデータストリーム１０４、またはデータストア１０５へ送信する。また、データ収集部３１０は、データ属性の収集結果を、プッシュ通知受信部３０９を介してデバイス管理サーバー１０２のプッシュ通知管理部３０５に送信する。

以下に、本実施形態に係るデータ属性の収集結果を示す記述の例を示す。
｛
“デバイスＩＤ”：“Ｄｅｖｉｃｅ００１”
“データ収集モジュールＩＤ”：“Ａｇｅｎｔ００１”
“取得データ属性群”：［“ＤａｔａＸ”，“ＤａｔａＹ”，“ＤａｔａＺ”］
｝

データ属性の収集結果には、少なくともデバイスＩＤ、データ収集モジュールの識別子であるデータ収集モジュールＩＤ、および、データ収集要求に対して取得されたデータ属性の集合である取得データ属性群が含まれる。

第２データ収集モジュール３１１は、プッシュ通知取得部３１２、及びデータ収集部３１３を備える。プッシュ通知取得部３１２は、データ収集要求に基づいて、指定された通知先に送信する。本実施形態では、プッシュ通知取得部３１２は、データ変換サーバー１０６のプッシュ通知管理部３１５からデータ収集要求を取得し、データ収集要求をデータ収集部３１３に送信する。データ収集部３１３は、プッシュ通知取得部３１２から受信したデータ収集要求に基づいて、各種データ属性を収集し、データ変換サーバー１０６のデータ変換部３１６へ送信する。

本実施形態では、サービス提供サーバー１０１から要求されたデータを収集する手段は、第１データ収集モジュール３０８、および第２データ収集モジュール３１１という構成であるが、これに限定するものではない。少なくとも１つのデータ収集モジュールがプッシュ通知管理部を備えるのであれば、データ収集モジュールが２つ以上ある構成であっても良い。

デバイス情報管理部３１４は、デバイス１０３が備えるファームウェアのバージョンやデータ収集モジュールのバージョンなどのバージョン情報を、デバイス管理サーバー１０２のバージョン管理部３０７に送信する。以下にバージョン情報を示す記述の一例を示す。バージョン情報は、少なくともデバイスＩＤ、およびファームウェアバージョンを含む。
｛
“デバイスＩＤ”：“Ｄｅｖｉｃｅ００１”
“ファームウェアバージョン”：“Ｘ．０”
｝

データ変換サーバー１０６は、プッシュ通知管理部３１５、およびデータ変換部３１６を備える。プッシュ通知管理部３１５は、受信したデータや要求を、指定された通知先に送信する。本実施形態では、プッシュ通知管理部３１５は、デバイス管理サーバー１０２のプッシュ通知管理部３０５からデータ収集要求を取得し、受信したデータ収集要求に基づき、デバイス１０３の第２データ収集モジュール３１１に通知する。データ変換部３１６は、第２データ収集モジュール３１１のデータ収集部３１３が送信するデータを取得し、各サービスが処理可能なデータ形式に変換する変換処理を行い、データストリーム１０４に送信する。本実施形態では、第２データ収集モジュール３１１が送信するデータはサービス提供サーバー１０１が処理可能なデータ形式ではない構成を前提として、データ変換サーバー１０６を構成に含んでいる。しかし、デバイス１０３の第２データ収集モジュール３１１が送信するデータをサービス提供サーバー１０１で直接処理可能なデータ形式である場合には、データ変換部３１６はなく、プッシュ通知管理部３１５のみの構成であってよい。

［処理フロー］
（データ収集要求処理）
図４は、本実施形態に係るデバイス管理サーバー１０２のデータ収集要求管理部３０４が実行するデータ収集要求処理のフローチャートである。データ収集要求管理部３０４は、各サービスのサービス提供サーバー１０１からデータ収集要求を受信し、保存した後に、本処理を実行する。本実施形態において、図４のフローチャートで示す処理は、デバイス管理サーバー１０２を構成する情報処理装置２００におけるメモリー２０２、またはＨＤＤ２０３にプログラムとして記憶され、ＣＰＵ２０１により実行されることで実現される。

Ｓ４０１にて、データ収集要求管理部３０４は、データ収集要求グループ化処理を実行する。データ収集要求グループ化処理の詳細については、図５を用いて後述する。

Ｓ４０２にて、データ収集要求管理部３０４は、収集するデータをデータ属性毎に各データ収集モジュールに割り振る。収集データ属性割り振り処理の詳細については、図６を用いて後述する。

Ｓ４０３にて、データ収集要求管理部３０４は、Ｓ４０２で各データ収集モジュールに割り振られていないデータ属性の収集停止要求を、各データ収集モジュールに送信する。これに応じて、データ収集モジュール側では、指定されたデータ属性の収集及び送信が停止される。

Ｓ４０４にて、データ収集要求管理部３０４は、Ｓ４０２で各データ収集モジュールに割り振ったデータ属性の収集要求を、各データ収集モジュールに送信する。これに応じて、データ収集モジュール側では、指定されたデータ属性の収集及び送信が実行される。

Ｓ４０５にて、データ収集要求管理部３０４は、Ｓ４０５で送信したデータ収集要求を表２で示したテーブルへ保存する。そして、本処理フローを終了する。

（データ収集要求グループ化処理）
図５は、本実施形態に係るデバイス管理サーバー１０２のデータ収集要求管理部３０４が実行するデータ収集要求マージ処理のフローチャートである。本処理フローは、図４のＳ４０１の工程に対応する。

Ｓ５０１にて、データ収集要求管理部３０４は、表１に示すテーブルからデバイス１０３ごとにデータ収集要求を取得する。例えば、表１の例の場合、デバイスＩＤごとにデータ収集要求を取得する。

Ｓ５０２にて、データ収集要求管理部３０４は、デバイス１０３それぞれのデータ収集要求を、サービスごとにマージする。

Ｓ５０３にて、データ収集要求管理部３０４は、データ属性ごとにデータ収集要求をグループ化する。上述したように、表１で示したデバイスＩＤが「Ｄｅｖｉｃｅ００１」のデバイス１０３について、データ取得要求のマージおよびグループ化を行った場合、表２に示す結果が得られる。

Ｓ５０４にて、データ収集要求管理部３０４は、Ｓ５０３でデータ属性ごとにグループ化したレコードに基づいて、データ収集モジュールごとのデータ属性の収集要求を有するデータ収集要求テーブルを作成する。そして、本処理フローを終了する。

表５は、表１の例に基づいて、Ｓ５０４にて生成されるデータ収集要求テーブルの例である。データ収集要求テーブルは、要求先デバイスの識別子であるデバイスＩＤ、収集対象のデータ属性、収集するルート、データ属性の収集対象のデータ収集モジュールであるデータ収集先を少なくとも有する。本実施形態では、データ収集先の値としてデータ収集モジュールＩＤが用いられ、初期値は空となっている。このデータ収集要求テーブルにより、データの要求先が決定される。

（収集データ属性割り振り処理）
図６は、本実施形態に係るデバイス管理サーバー１０２のデータ収集要求管理部３０４が実行する収集データ属性割り振り処理のフローチャートである。本処理フローは、図４のＳ４０２の工程に対応する。

収集データ属性割り振り処理では、データ属性ごとに、データ収集要求をデータ収集モジュールに割り振る。本処理により、デバイスが同じデータ属性のデータを送信することや、同じデータ収集モジュールを備えるデバイスのデータ属性のデータを重複して収集されることを部分的に避けることができる。そのため、顧客環境と、デバイス管理システムの運用環境におけるトラフィックを削減することができ、効率的にデータ収集ができる。

Ｓ６０１にて、データ収集要求管理部３０４は、データ収集要求に対して、デバイス管理サーバー１０２から、各データ収集モジュールのデータ収集部が収集した取得データ属性群を取得する。本実施形態の場合、データ収集要求管理部３０４は、デバイス１０３の第１データ収集モジュール３０８からは上述したようなデータ属性の収集結果を取得する。一方、第２データ収集モジュール３１１からはデータ属性収集結果を取得できないものとして説明する。

Ｓ６０２にて、データ収集要求管理部３０４は、データ収集モジュール管理部３０６に対して、デバイス１０３が備えるデータ収集モジュール情報を要求する。そして、この要求の応答として、データ収集要求管理部３０４は、デバイス１０３が備えるデータ収集モジュール情報を取得する。例えば、データ収集要求管理部３０４は、デバイスＩＤを指定してデータ収集モジュール管理部３０６に要求を行い、その応答として、当該デバイスＩＤに対応付けられているデータ収集モジュールＩＤが返される。

Ｓ６０３にて、データ収集要求管理部３０４は、Ｓ６０２で取得したデバイス１０３が備えるデータ収集モジュール情報に基づいて、デバイス１０３が備えるデータ収集モジュールを特定する。つまり、上述した表３のテーブルの情報に基づいてデータ収集モジュールを特定する。そして、そのデータ収集モジュールのうち、未処理のデータ収集モジュールを処理対象とする。その後、Ｓ６０４へ進む。

Ｓ６０４にて、データ収集要求管理部３０４は、Ｓ６０１で取得したデータ収集モジュールに対する取得可能データ属性群のうち、未処理のデータ属性を処理対象とする。ここでの取得可能データ属性群は、Ｓ６０１にて取得した取得データ属性群にて示されるデータ属性が該当する。その後、Ｓ６０５へ進む。

Ｓ６０５にて、データ収集要求管理部３０４は、処理対象であるデータ属性に対し、Ｓ５０３でグループ化した表５のテーブルに基づき、データ収集先が設定されているか否かを判定する。データ属性に対するデータ収集先が設定されていないと判定された場合（Ｓ６０５にてＮＯ）Ｓ６０６に進み、データ属性に対するデータ収集先が設定されていると判定された場合（Ｓ６０５にてＹＥＳ）Ｓ６０７に進む。

Ｓ６０６にて、データ収集要求管理部３０４は、表５に示すデータ収集要求テーブルのデータ収集先の値を、処理対象としているデータ収集モジュールのデータ収集モジュールＩＤに設定する。そして、Ｓ６０９に進む。

Ｓ６０７にて、データ収集要求管理部３０４は、処理対象であるデータ属性に対応するデータ収集先に設定されているデータ収集モジュールＩＤの優先度フラグが“ｆａｌｓｅ”であるか否かを、表３のテーブルを参照して判定する。データ収集先に設定されているデータ収集モジュールＩＤの優先度フラグが“ｆａｌｓｅ”であると判定された場合は（Ｓ６０７にてＹＥＳ）Ｓ６０８へ進み、優先度フラグが“ｔｒｕｅ”であると判定された場合は（Ｓ６０７にてＮＯ）Ｓ６０９へ進む。

Ｓ６０８にて、データ収集要求管理部３０４は、表５に示すデータ収集要求テーブルにおいて、処理対象であるデータ属性に対するデータ収集先の値を、処理対象としているデータ収集モジュールのデータ収集モジュールＩＤにて更新する。そして、Ｓ６０９に進む。

Ｓ６０９にて、データ収集要求管理部３０４は、全てのデータ属性に対するＳ６０５～Ｓ６０８の処理が完了したか否かを判定する。未処理のデータ属性がある場合は（Ｓ６０９にてＮＯ）Ｓ６０４へ戻り、処理を繰り返す。全てのデータ属性に対する処理が完了した場合（Ｓ６０９にてＹＥＳ）、Ｓ６１０へ進む。

Ｓ６１０にて、データ収集要求管理部３０４は、全てのデータ収集モジュールに対するＳ６０４～Ｓ６０９の処理が完了したか否かを判定する。未処理のデータ収集モジュールがある場合は（Ｓ６１０にてＮＯ）Ｓ６０３へ戻り、処理を繰り返す。全てのデータ収集モジュールに対する処理が完了した場合（Ｓ６１０にてＹＥＳ）、Ｓ６１１へ進む。

Ｓ６１１にて、データ収集要求管理部３０４は、表５に示すデータ収集要求テーブルにおいて、データ収集先が設定されていないレコードがあるか否かを判定する。データ収集先が設定されていないレコードがあると判定された場合は（Ｓ６１１にてＹＥＳ）Ｓ６１２へと進み、データ収集先が設定されていないレコードがないと判定された場合は（Ｓ６１１にてＮＯ）、本処理フローを終了する。

Ｓ６１２にて、データ収集要求管理部３０４は、表５に示すデータ収集要求テーブルにおいてデータ収集先が設定されていないレコードのデータ収集先の値に、表３に示すテーブルの中から優先度フラグが“ｆａｌｓｅ”となっているデータ収集モジュールＩＤを設定する。そして、本処理フローを終了する。

（収集データ属性再割り振り処理）
図７は、本実施形態に係るデバイス管理サーバー１０２のデータ収集要求管理部３０４が実行するデータ収集要求再割り振り処理のフローチャートである。本実施形態において、図７のフローチャートで示す処理は、デバイス管理サーバー１０２を構成する情報処理装置２００におけるメモリー２０２、またはＨＤＤ２０３にプログラムとして記憶され、ＣＰＵ２０１により実行されることで実現される。

本処理により、デバイスのファームウェアなどのバージョン情報のアップデート後に取得可能になったデータ属性をデータ収集要求に含めることができる。また、収集データ属性割り振り処理ではデータ収集先が重複していたデータ属性のデータ収集先を削減することが可能となり、更なるトラフィック削減が可能となる。

本処理は、例えば、図６のデータ収集要求処理が終了後、デバイス管理サーバー１０２のデータ収集要求管理部３０４が、バージョン管理部３０７を介して、デバイス１０３のデバイス情報管理部３１４から送信されたバージョン情報を受信したタイミングで実行される。

Ｓ７０１にて、データ収集要求管理部３０４は、デバイス１０３のデバイス情報管理部３１４から送信される更新されたバージョン情報を受信する。

Ｓ７０２にて、データ収集要求管理部３０４は、Ｓ７０１で受信した更新されたバージョン情報のうち、ファームウェアバージョンに関する情報が存在するか否かを判定する。ファームウェアバージョンに関する情報が存在すると判定された場合（Ｓ７０２にてＹＥＳ）Ｓ７０３に進み、ファームウェアバージョンに関する情報が存在しないと判定された場合（Ｓ７０２にてＮＯ）本処理フローを終了する。

Ｓ７０３にて、データ収集要求管理部３０４は、図４～図６を用いて説明したデータ収集要求処理を実行する。データ収集要求処理が終了した後、本処理フローを終了する。

以上、本実施形態により、複数のサービスが複数方式でデバイスからデータ収集する環境において、通信負荷を抑制しつつ、効率的にデータ収集ができる。

＜第２の実施形態＞
以下、本願発明の第２の実施形態について説明する。なお、上述した第１の実施形態と同じ構成等については説明を省略し、差分に着目して説明を行う。本実施形態では、サービス提供サーバーが、その構成などの変化に対応して移行される場合を想定する。また、本実施形態では、クラウドサービスによるサービス提供サーバーの構成を想定する。

［システム構成］
図８は、本実施形態に係るシステムの全体構成を示す図である。図８において、移行後サービス提供サーバー８０１、デバイス管理サーバー８０２の構成はそれぞれ、第１の実施形態にて示したサービス提供サーバー１０１、デバイス管理サーバー１０２と同様である。 データストリーム８０４、データストア８０５の構成はそれぞれ、第１の実施形態にて示したデータストリーム１０４、データストア１０５と同様である。

デバイス８０３は、デバイス管理サーバー８０２や移行前サービス提供サーバー８０７から受信したデータ収集要求に基づいて、各種データ（使用実績、ステータス、エラー情報など）を収集し、データストリーム８０４、データストア８０５、または移行前サービス提供サーバー８０７へ送信する。データ変換サーバー８０６は、デバイス８０３、移行前サービス提供サーバー８０７から受信した各種データを、移行後サービス提供サーバー８０１が処理可能なデータ形式に変換し、データストリーム８０４に送信する。

移行前サービス提供サーバー８０７は、デバイス８０３から収集したデータを利用して顧客にサービスを提供する。本実施形態では、移行前サービス提供サーバー８０７はひとつのみを含む構成を示しているが、サービス内容に応じて複数存在する構成でも構わない。

テナント管理サーバー８０８は、移行前サービス提供サーバー８０７と移行後サービス提供サーバー８０１が提供するサービスを利用するテナントの情報を管理する。テナント管理サーバー８０８は、移行前サービスと移行後サービスを利用する顧客のデータを、顧客ごとの専用領域であるテナントの単位で管理する。

移行後サービス提供サーバー８０１、デバイス管理サーバー８０２、デバイス８０３、データストリーム８０４、データストア８０５、データ変換サーバー８０６、移行前サービス提供サーバー８０７、およびテナント管理サーバー８０８は、ネットワーク８０９を介して通信可能に接続されている。ネットワーク８０９は、第１の実施形態にて説明したネットワーク１０７と同様である。

［機能構成］
図９は、本実施形態に係る移行後サービス提供サーバー８０１、デバイス管理サーバー８０２、デバイス８０３、データ変換サーバー８０６、移行前サービス提供サーバー８０７、およびテナント管理サーバー８０８の機能構成の一例を示す図である。

移行後サービス提供サーバー８０１、デバイス管理サーバー８０２の機能構成はそれぞれ、第１の実施形態の図３にて述べたサービス提供サーバー１０１、デバイス管理サーバー１０２と同様である。

デバイス８０３は、第１データ収集モジュール９０８、第２データ収集モジュール９１１、およびデバイス情報管理部９１４を備える。第１データ収集モジュール９０８、デバイス情報管理部９１４の構成はそれぞれ、第１の実施形態の図３にて述べた第１データ収集モジュール３０８、デバイス情報管理部３１４と同様である。第２データ収集モジュール９１１は、データ収集部９１３、およびプッシュ通知取得部９１２を備える。プッシュ通知取得部９１２は、取得したデータ収集要求をもとに、指定された通知先に送信する。本実施形態では、移行前サービス提供サーバー８０７のデータ収集要求管理部９１７からデータ収集要求を取得し、データ収集部９１３に送信する。データ収集部９１３は、移行前サービス提供サーバー８０７から取得したデータ収集要求に基づき、各種データ属性を収集し、移行前サービス提供サーバー８０７のデータ受信部９１９へ送信する。

本実施形態では、移行後サービス提供サーバー８０１からの要求に応じてデータ収集を行う手段として、第１データ収集モジュール９０８が用いられる構成を示しているが、これに限定するものではない。少なくとも１つのデータ収集モジュールがプッシュ通知受信部を備えるのであれば、データ収集モジュールは２つ以上ある構成でもよい。また、本実施形態において、移行前サービス提供サーバー８０７からの要求に応じてデータ収集を行う手段として、第２データ収集モジュール９１１が用いられる構成を示しているが、これに限定するものではない。移行前サービス提供サーバー８０７からの要求に対してデータを送信する全てのデータ収集モジュールがプッシュ通知取得部を備えるのであれば、データ収集モジュールは２つ以上ある構成でもよい。

データ変換サーバー８０６は、プッシュ通知管理部９１５、およびデータ変換部９１６を備える。プッシュ通知管理部９１５は、受信したデータや要求を、指定された通知先に送信する。本実施形態において、移行前サービス提供サーバー８０７から移行後サービス提供サーバー８０１へ移行作業が完了したことに応じて、プッシュ通知管理部９１５は、デバイス管理サーバー８０２からデータ収集要求を受信する。プッシュ通知管理部９１５は、デバイス８０３の第２データ収集モジュール９１１にて、各種データ属性を収集させる。そして、データ変換部９１６は、第２データ収集モジュール９１１にて収集されたデータを受信する。データ変換部９１６は、移行前サービス提供サーバー８０７から移行後サービス提供サーバーへ移行作業が完了したことに応じて、第２データ収集モジュール９１１のデータ収集部９１３が送信するデータを、移行後サービス提供サーバー８０１による各サービスが処理可能なデータ形式に変換する変換処理を行い、データストリーム８０４に送信する。

本実施形態において、第２データ収集モジュール９１１が送信するデータは、移行後サービス提供サーバー８０１が処理可能なデータ形式ではないという構成を前提としているため、データ変換サーバー８０６を構成に含んでいるがこれに限定するものではない。第２データ収集モジュール９１１が送信するデータが移行後サービス提供サーバー８０１で処理可能なデータ形式であった場合は、データ変換部９１６はなくプッシュ通知管理部９１５のみの構成でもよい。

移行前サービス提供サーバー８０７は、データ収集要求管理部９１７、データ転送部９１８、およびデータ受信部９１９を備える。データ収集要求管理部９１７は、デバイス８０３に対するデータ収集要求を管理する。本実施形態において、データ収集要求管理部９１７は、第２データ収集モジュール９１１からのデータ収集要求を受けて、データ属性の取得要求をプッシュ通知取得部９１２に送信する。データ受信部９１９は、デバイス８０３からのデータや要求を受信する。本実施形態において、データ受信部９１９は、データ属性の取得要求に応じて第２データ収集モジュール９１１のデータ収集部９１３が送信したデータを受信する。データ転送部９１８は、データ収集要求に基づいてデバイス８０３から取得したデータを、移行後サービス提供サーバー８０１が利用できるように送信する。本実施形態において、データ転送部９１８は、第２データ収集モジュール９１１からのデータ収集要求に基づいて、第２データ収集モジュール９１１のデータ収集部９１３が送信したデータをデータストア８０５に転送する。

テナント管理サーバー８０８は、移行状態管理部９２０、および移行状態変更部９２１を備える。移行状態管理部９２０は、テナントの移行状態を管理する。本実施形態において、移行前サービス提供サーバー８０７から移行後サービス提供サーバー８０１へテナントが移行されたか否かを管理する。表６は、本実施形態に係る各テナントの移行状態を管理するテーブルの例を示す。テーブルはテナントの識別子であるテナントＩＤとテナントが移行されたか否かを示す移行状態をもつ。移行状態は“完了”または“未完了”の値が設定され、テナントＩＤに対する移行状態の初期値は“未完了”である。

移行状態変更部９２１は、テナントの移行状態に応じて、表６に示すテーブルの値の変更を行う。本実施形態において、ユーザやコマンドからの移行状態変更通知を受けて、移行状態変更部９２１がテナントＩＤに対する移行状態管理部９２０のテーブルに含まれるレコードの移行状態の値を“完了”に更新する。

［サービス切り替え処理］
図１０は、本実施形態に係るサービス切り替え処理のフローチャートである。本処理フローは、テナント管理サーバー８０８として動作する情報処理装置２００のＣＰＵ２０１が、メモリー２０２、ＨＤＤ２０３のいずれかの記憶装置に記憶されたプログラムを実行することにより実現される。

サービス切り替え処理では、全てのテナントがサービス移行を完了したことを確認したことに応じて、移行前サービス提供サーバー８０７にデータを送信しているデバイス８０３の第２データ収集モジュール９１１のデータ収集要求の取得先を、移行後サービス提供サーバー８０１に切り替える。本実施形態では、第２データ収集モジュール９１１のデータ送信先を移行後サービス提供サーバー８０１に切り替える。本処理により、サービスを提供するシステムの移行を安全に行うことができる。

Ｓ１００１にて、テナント管理サーバー８０８の移行状態管理部９２０は、表６に示すテーブルを参照し、移行状態の値が“未完了”のレコードがあるか否かを判定する。上述したように、本実施形態において、移行状態は、ユーザやコマンドからの移行状態変更通知に起因して更新される。未完了のものがあると判定された場合（Ｓ１００１にてＹＥＳ）本処理フローを終了し、未完了のものがないと判定された場合（Ｓ１００１にてＮＯ）Ｓ１００２へ進む。

Ｓ１００２にて、テナント管理サーバー８０８は、全てのテナントが移行後サービス提供サーバー８０１に移行したことを所定の通知先に通知する。本実施形態では、通知先は移行後サービス提供サーバー８０１（サービス）の運用管理者であるとする。運用管理者によって、デバイス８０３は、データの収集要求を受信して、データを送信する送信先を変更する。送信先の変更手段の例としては、ＤＮＳ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ）を用いて変更する方法が挙げられる。

Ｓ１００３にて、移行状態変更部９２１は、運用管理者からの移行作業完了通知を受けて、移行状態管理部９２０にて管理されている全移行状態完了フラグを“ｔｒｕｅ”に変更する。なお、全移行状態完了フラグは、例えば、テナント管理サーバー８０８として動作する情報処理装置２００のＨＤＤ２０３などの記憶部にて保持されており、移行が開始されたタイミングにて初期値として”ｆａｌｓｅ”が設定されているものとする。そして、本処理フローを終了する。

［データ収集モジュール停止処理］
図１１は、本実施形態に係るデータ収集モジュール停止処理のフローチャートである。本処理フローは、デバイス管理サーバー８０２として動作する情報処理装置２００のＣＰＵ２０１が、メモリー２０２、ＨＤＤ２０３のいずれかの記憶装置に記憶されたプログラムを実行することにより実現される。

データ収集モジュール停止処理では、全移行状態完了フラグを参照し、全てのテナントがサービス移行を完了したことを確認したことに応じて、移行前サービス提供サーバー８０７にデータを送信しているデバイス８０３の第２データ収集モジュール９１１のデータ収集を停止させる。本処理により、移行後のサービスにおいて必要ないデータ収集モジュールを停止させることができる。これにより、顧客環境と、デバイス管理システム運用環境におけるトラフィックを削減することができ、効率的にデータ収集ができるだけではなく、不要なデータ収集モジュールの運用の手間を削減することができる。本処理は、サービス切り替え処理により、全てのデータ収集モジュールのデータ送信先が移行後サービス提供サーバー８０１となった際に実行される。

Ｓ１１０１にて、データ収集要求管理部９０４は、第１の実施形態にて図６を用いて説明したデータ収集要求割り振り処理を実行する。処理が完了した後、Ｓ１１０２へ進む。

Ｓ１１０２にて、データ収集要求管理部９０４は、表３および表５に示すテーブルを参照し、全てのデータ属性のデータ収集先が、優先度フラグが“ｔｒｕｅ”であるデータ収集モジュールであるか否かを判定する。全てのデータ属性のデータ収集先が、優先度フラグが“ｔｒｕｅ”であるデータ収集モジュールである場合（Ｓ１１０２にてＹＥＳ）Ｓ１１０３に進み、それ以外の場合（Ｓ１１０２にてＮＯ）本処理フローを終了する。

Ｓ１００３にて、データ収集要求管理部９０４は、表３に示すテーブルの中から、データ属性が割り振られておらず、かつ、優先度フラグが“ｆａｌｓｅ”であるデータ収集モジュールのデータ収集モジュールＩＤの値が設定されたレコードを削除する。そして、本処理フローを終了する。

［アップデート待ち停止処理］
図１２は、アップデート待ち停止処理のフローチャートである。本処理フローは、デバイス管理サーバー８０２として動作する情報処理装置２００のＣＰＵ２０１が、メモリー２０２、ＨＤＤ２０３のいずれかの記憶装置に記憶されたプログラムを実行することにより実現される。

アップデート待ち停止処理では、デバイスにて動作するファームウェアがアップデートされた場合に、データ収集モジュール停止の処理が実行される。本処理は、データ収集要求管理部９０４が、バージョン管理部９０７からデバイス８０３のファームウェアバージョンの更新通知を受信した際に実行される。本処理により、移行後のサービスにて必要ないデータ収集モジュールを、デバイスやデータ収集モジュールの状態に応じて停止させることができる。これにより、不要なデータ収集モジュールの運用の手間を削減することができるだけでなく、移行後サービス提供サーバー８０１が必要とするデータ属性をより効率的に取得することができる。

Ｓ１２０１にて、データ収集要求管理部９０４は、バージョン管理部９０７から送信される更新されたバージョン情報を受信する。

Ｓ１２０２にて、データ収集要求管理部９０４は、Ｓ１２０１で受信した更新されたバージョン情報のうち、ファームウェアバージョンが存在するか否かを判定する。ファームウェアバージョンが存在すると判定された場合（Ｓ１２０２にてＹＥＳ）Ｓ１２０３に進み、ファームウェアバージョンが存在しないと判定された場合（Ｓ１２０２にてＮＯ）本処理フローを終了する。

Ｓ１２０３にて、データ収集要求管理部９０４は、図１１を用いて説明したデータ収集モジュール停止処理を実行する。その後、本処理フローを終了する。

以上、本実施形態により、複数のサービス提供サーバーの移行が行われる際に、移行後の構成に応じて、効率的にデータ収集ができるように切り替えることができる。

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

１０１…サービス提供サーバー、１０２…デバイス管理サーバー、１０３…デバイス、１０４…データストリーム、１０５…データストア、１０６…データ変換サーバー、１０７…ネットワーク

Claims (9)

1. データを送信する複数のモジュールを備えるデバイスを管理するデバイス管理システムであって、
   前記デバイスのデータに対する要求を受信する受信手段と、
   前記受信手段にて受信した要求に基づき、前記デバイスから送信されるべきデータの属性を決定する決定手段と、
   前記決定手段にて決定したデータの属性に応じて、当該データを送信するモジュールを前記複数のモジュールの中から割り当てる割り当て手段と、
   前記割り当て手段による割り当てに基づいて、前記デバイスのモジュールにデータの送信を要求する要求手段と
   を備え、
   前記割り当て手段は、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から割り当てた後に、前記デバイスにて動作するソフトウェアのバージョンが更新されたことに応じて、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から再度、割り当てることを特徴とするデバイス管理システム。
2. 前記受信手段にて受信した要求に応じて、前記複数のモジュールの中の第１モジュールによる送信先が決定されることを特徴とする請求項１に記載のデバイス管理システム。
3. 前記送信先は、データストリーミングを行うための第１の記憶手段、または、データを格納するための第２の記憶手段の少なくともいずれかであることを特徴とする請求項２に記載のデバイス管理システム。
4. 前記受信手段は、前記デバイスからのデータを用いてサービスを提供するサービス提供サーバーから要求を受信し、
   前記サービス提供サーバーは、当該要求に対応するデータを前記第１の記憶手段または前記第２の記憶手段を介して取得することを特徴とする請求項３に記載のデバイス管理システム。
5. 前記デバイスのデータを前記サービス提供サーバーが提供するサービスにて処理可能なデータに変換する変換手段を更に有し、
   前記複数のモジュールの中の第２モジュールにて送信されたデータは、前記変換手段による変換処理が行われた後、前記第１の記憶手段または前記第２の記憶手段に転送されることを特徴とする請求項４に記載のデバイス管理システム。
6. 前記デバイスのデータに対する要求を送信しているサービス提供サーバーの新たなサービス提供サーバーへの移行状態を管理する管理手段を更に有し、
   前記管理手段にて管理する情報に基づき、前記新たなサービス提供サーバーへの移行が完了したと判定された場合に、前記割り当て手段は、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から再度、割り当てることを特徴とする請求項１乃至５のいずれか一項に記載のデバイス管理システム。
7. 前記管理手段は、前記新たなサービス提供サーバーを構成するクラウドサービスのテナントごとに移行状態を管理し、
   前記割り当て手段は、全てのテナントにおける前記新たなサービス提供サーバーへの移行が完了したと判定された場合に、前記決定手段にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から再度、割り当てることを特徴とする請求項６に記載のデバイス管理システム。
8. 前記要求手段は、前記割り当て手段による割り当てに基づいて、前記デバイスが備えるモジュールに対して、当該モジュールに割り当てられた属性のデータの送信、もしくは、該属性のデータの送信の停止を要求することを特徴とする請求項１乃至７のいずれか一項に記載のデバイス管理システム。
9. データを送信する複数のモジュールを備えるデバイスを管理するデバイス管理システムの制御方法であって、
   前記デバイスのデータに対する要求を受信する受信工程と、
   前記受信工程にて受信した要求に基づき、前記デバイスから送信されるべきデータの属性を決定する決定工程と、
   前記決定工程にて決定したデータの属性に応じて、当該データを送信するモジュールを前記複数のモジュールの中から割り当てる割り当て工程と、
   前記割り当て工程による割り当てに基づいて、前記デバイスのモジュールにデータの送信を要求する要求工程と
   を有し、
   前記決定工程にて決定したデータの属性に応じた当該データを送信するモジュールを前記複数のモジュールの中から割り当てた後に、前記デバイスにて動作するソフトウェアのバージョンが更新されたことに応じて、前記決定工程にて決定したデータの属性に応じた当該データを送信するモジュールが前記複数のモジュールの中から再度、割り当てられることを特徴とするデバイス管理システムの制御方法。

Images