JP6812171B2 - ネットワークシステム、および、ネットワークシステムにおける制御方法 - Google Patents

Description

本発明は、ネットワークシステム、および、ネットワークシステムにおける制御方法に関する。

近年、顧客のデバイス（複写機やプリンター等）の機器管理、障害復旧、印刷状況の管理、などを行うデバイス管理サービスが、インターネット上のサーバーでクラウドサービスとして提供されている。デバイス管理サービスでは、顧客や所定のグループといった単位でデバイスを管理し、顧客環境にあるデバイスとインターネット上のサーバーの間で、デバイスの情報や印刷の実績値といったデバイスの使用に関するデバイス情報を送受信する。その際、顧客環境には一般的にファイアウォールが設定されており、インターネット上のサーバー側から顧客環境のデバイスに対してデバイス情報を直接収集することができない。そのため、顧客環境にデバイス管理アプリケーションを配置し、デバイス管理アプリケーションが顧客環境のデバイスからデバイス情報を収集し、インターネット上のサーバーに送信する、という構成が取られる。しかし、顧客環境に配置されたデバイス管理アプリケーションが何らかの要因でサーバーと通信できなくなった場合、サーバー側ではその要因がわからない、という問題がある。

特許文献１には、ネットワーク機器の情報を収集する情報収集装置が収集を継続できなくなった場合に、ネットワーク内で情報収集機能を備える他の機器に収集処理を引き継ぐ技術が開示されている。

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

しかしながら、特許文献１では、情報収集装置が引き継ぎ先を決定して引き継ぎ処理を行うため、故障や障害などで情報収集装置自体が不意に動作を継続できなくなった場合には、情報収集処理を引き継ぐことができない。

本発明は上記の課題を解決するためになされたものであり、インターネット上のデバイス管理サーバーがデバイス管理アプリケーションの異常を検知し、不意な異常時も含めて当該アプリケーションの情報をセキュアに収集することを目的とする。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、複数のネットワークデバイスと、前記複数のネットワークデバイスから収集した情報を管理する管理システムと、を含むネットワークシステムであって、前記複数のネットワークデバイスのそれぞれで実行される管理アプリケーションは、管理アプリケーションが正当な要求元からの管理情報の要求を受け付けたかを判定するために検証されるトークン情報を前記管理システムに送信し、前記管理システムは、ネットワークデバイスまたはネットワークデバイスで実行される管理アプリケーションの識別情報を用いて、１つの管理グループに対して複数のネットワークデバイスを関連付けて管理する管理手段と、ネットワークデバイスから前記トークン情報を受信する受信手段と、当該受信したトークン情報と、当該ネットワークデバイスおよび当該ネットワークデバイスで実行される管理アプリケーションの識別情報の少なくともいずれかと、を関連付けて登録する登録手段と、前記複数のネットワークデバイスのうちの第１のネットワークデバイスとの通信の異常を検知した際に、前記第１のネットワークデバイスと同じ管理グループに関連付けて管理されている第２のネットワークデバイスに対して、前記第１のネットワークデバイスから受信済みの前記登録されたトークン情報を送信する第１送信手段と、を有し、前記第２のネットワークデバイスは、前記管理システムから送信されてきた前記トークン情報を用いて、前記第１のネットワークデバイスとの通信を試行する通信手段と、前記第１のネットワークデバイスとの通信に関する情報を前記管理システムに送信する第２送信手段と、を有する。

本願発明により、デバイス管理アプリケーションが不意に異常状態になった場合も含めて、当該デバイス管理アプリケーションの情報をセキュアに収集することができる。

本願発明に係るデバイス管理システムのネットワーク構成の例を示す図。 本願発明に係る画像形成装置のハードウェア構成の例を示す図。 本願発明に係る情報処理装置のハードウェア構成の例を示す図。 第１の実施形態に係る管理アプリケーションのソフトウェア構成の例を示す図。 第１の実施形態に係るデバイス管理サーバーのソフトウェア構成の例を示す図。 本願発明に係るデータ構造の一例を示す図。 管理アプリケーションによる管理情報収集処理のフローチャート。 管理アプリケーションによる管理情報提供処理のフローチャート。 デバイス管理サーバーによる選定処理のフローチャート。 デバイス管理サーバーによる回復処理の要否判定処理のフローチャート。 第２の実施形態に係る管理アプリケーションのソフトウェア構成の例を示す図。 第３の実施形態に係る管理アプリケーションのソフトウェア構成の例を示す図。 第３の実施形態に係るデバイス管理サーバーのソフトウェア構成の例を示す図。

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

［システム構成］
第１の実施形態に係るデバイス管理システムを構成している各装置について、図１を参照して説明する。図１において、デバイス管理システムは、デバイス管理サーバー１０１、クライアント端末１０４、顧客Ａの内部ネットワーク、及び顧客Ｂの内部ネットワークがインターネット１０７を介して接続されるネットワークシステムとして構成される。また、顧客Ａおよび顧客Ｂそれぞれの内部ネットワークと、インターネット１０７との間には、ファイアウォール１０５が配置され、所定の規則に基づき、通信が制限される。

顧客Ａの内部ネットワークには、２つの画像形成装置１０２が含まれ、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）１０６を介して通信可能に接続される。また、ＬＡＮ１０６はファイアウォール１０５を介して外部ネットワークへと接続される。顧客Ｂの内部ネットワークには、画像形成装置１０２と情報処理装置１０３が含まれ、ＬＡＮ１０６を介して通信可能に接続される。また、ＬＡＮ１０６はファイアウォール１０５を介して外部ネットワークへと接続される。なお、ここでは、顧客として顧客Ａ、Ｂの２つを示したが、これに限定するものではなく、更に多くの顧客のネットワークを含んでよい。また、各顧客の内部ネットワークに含まれる装置の構成はこれに限定するものではなく、更に多くの装置を含んでもよい。

デバイス管理サーバー１０１は、複数の顧客のデバイスを集中管理するため、顧客毎に論理的、または物理的に分離して管理するマルチテナントアーキテクチャーを備える。つまり、各顧客は、マルチテナント構成によるテナントとして管理される。なお、図１では、１のデバイス管理サーバー１０１を示しているが、複数の装置もしくは複数の仮想デバイスによりデバイス管理サーバー１０１を構成し、これらにより分散して各被管理装置を管理する構成であってもよい。

本実施形態に係る画像形成装置１０２は、自身の状態を監視して印刷実績ログ情報、エラー情報、消耗品情報等などを収集してデバイス管理サーバー１０１に送信する管理アプリケーションをインストールすることができる。画像形成装置として、単機能のネットワークプリンタやＭＦＰ（Ｍｕｌｔｉ−Ｆｕｎｃｔｉｏｎ Ｐｅｒｉｐｈｅｒａｌ）、スキャナなどが該当する。画像形成装置１０２は、ネットワークに接続されたネットワーク機器の一例であり、画像形成装置に限定するものではない。デバイス管理サーバー１０１が集中的に情報を管理、監視する対象とすることが可能なデバイスであれば、他のネットワークデバイスであってもよい。

情報処理装置１０３は、管理アプリケーションがインストールされていない画像形成装置１０２を監視して、印刷実績ログ情報、エラー情報、消耗品情報等などを収集してデバイス管理サーバー１０１に送信する。

本実施形態において、顧客Ａの内部ネットワークに含まれる画像形成装置１０２がそれぞれ管理アプリケーションをインストールされ、自身の各種情報をデバイス管理サーバー１０１に送信できるものとする。また、顧客Ｂの内部ネットワークにおいては、情報処理装置１０３が、同じ内部ネットワークに属する、管理アプリケーションがインストールされていない画像形成装置１０２を監視し、その情報をデバイス管理サーバー１０１に送信するものとする。

クライアント端末１０４は、デバイス管理サーバー１０１にインターネット１０７を介してアクセスし、顧客毎のデバイス管理に関するオペレーションを指示する。クライアント端末１０４はパーソナルコンピュータ（ＰＣ）に限定するものではなく、同機能を持つ携帯端末などでもよい。

［ハードウェア構成］
図２は、本実施形態に係る画像形成装置１０２のハードウェア構成の例を示す図である。画像形成装置１０２は、画像処理ユニット２０１、印刷ユニット２０２、及び読み込みユニット２０３を含んで構成される。画像形成装置１０２が複合機ではない場合は、読み込みユニット２０３が存在しない構成であってもよい。

画像処理ユニット２０１は、ＣＰＵ２０４、メモリ２０５、ハードディスク２０６、及びユーザーインターフェース２０７を含んで構成される。ＣＰＵ２０４は、画像形成装置１０２全体の制御を担う。ＣＰＵ２０４は、記憶部に記憶された各種プログラムを読み出して実行することにより、様々な機能を実現するユニットである。メモリ２０５は、各種情報を一時的に記憶するユニットであり、例えば、ハードディスク２０６に記憶されているプログラムを読み出す際に用いられたり、ＣＰＵ２０４の一時的な作業記憶領域としても利用されたりする。ハードディスク２０６は、不揮発性の記憶領域であり、例えば、フラッシュメモリなどの同機能を持つ他のハードウェアでもよい。

ユーザーインターフェース２０７は、ユーザーからの指示を受け付けたり、ユーザーに対して画面を出力したりするためのユニットである。ネットワークインタフェース２０８は、画像形成装置１０２をネットワークに接続するためのユニットであり、接続に用いられる方式に関し有線・無線などの種別は問わない。

印刷ユニット２０２は、ＣＰＵ２０４の指示に基づいて、印刷動作（画像形成動作）を行う。読み込みユニット２０３は、ＣＰＵ２０４の指示に基づいて、原稿等の読み込み動作（スキャン動作）を行う。なお、図２は、画像形成装置１０２の代表的なハードウェア構成の例であり、この構成に限定するものではない。また、上記の構成に加え、例えば、ＦＡＸボードや外部制御装置が接続されている構成であってもよい。また、被管理装置として、画像形成装置以外のネットワークデバイスに本願発明を適用する場合には、印刷ユニット２０２とは異なるユニットを含んでいてもよい。

図３は、デバイス管理サーバー１０１、情報処理装置１０３、及びクライアント端末１０４のハードウェア構成の例を示す図である。ＣＰＵ３０１は、装置全体の制御を担う。ＣＰＵ３０１は、記憶部に記憶された各種プログラムを読み出して実行することにより、様々な機能を実現するユニットである。メモリ３０２は、各種情報を一時的に記憶するユニットであり、例えば、ハードディスク３０３に記憶されているプログラムを読み出す際に用いられたり、ＣＰＵ３０１の一時的な作業記憶領域としても利用されたりする。ハードディスク３０３は、不揮発性の記憶領域であり、例えば、フラッシュメモリなどの同機能を持つ他のハードウェアでもよい。

ユーザーインターフェース３０４は、ユーザーからの指示を受け付けたり、ユーザーに対して画面を出力したりするためのユニットである。ネットワークインタフェース３０５は、装置をネットワークに接続するためのユニットであり、接続に用いられる方式に関し有線・無線などの種別は問わない。なお、図３は、代表的なハードウェア構成の例であり、この構成に限定するものではなく、例えば、一般的なＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等の情報処理装置が備えるような他の部位を備える構成であってよい。

［ソフトウェア構成］
（管理アプリケーション）
図４は、画像形成装置１０２、および情報処理装置１０３にインストールされる管理アプリケーションのソフトウェア構成の例を示す。図４に示されている各ソフトウェア構成の機能を実現するプログラムは、各装置のハードディスク２０６、３０３に記憶され、ＣＰＵ２０４、３０１がメモリ２０５、３０２にプログラムをロードし実行することで、これらの機能は実現される。

デバイス情報収集部４０１は、被管理装置となる画像形成装置１０２にアクセスして画像形成装置１０２の使用における各種デバイス情報（印刷実績ログ情報、エラー情報、消耗品情報など）を収集する。なお、各種デバイス情報は、画像形成装置１０２の利用に伴って更新され、画像形成装置１０２にて保持されているものとする。例えば、印刷実績ログ情報の収集の場合、デバイス情報収集部４０１は、画像形成装置１０２から収集済みの印刷実績ログ情報のポインタを管理し、画像形成装置１０２に対していつの印刷実績ログ情報から収集するかを管理する。収集する方法として、ＳＮＭＰ（Ｓｉｍｐｌｅ Ｎｅｔｗｏｒｋ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｔｏｃｏｌ）や画像形成装置１０２のベンダー特有のプロトコルを用いて収集する方法がある。収集するデバイス情報の種類、収集方法は特に限定されるものではない。また、デバイス情報収集部４０１は、管理アプリケーションがインストールされている装置が画像形成装置１０２自身か、情報処理装置１０３かに応じて、収集する方法を変更してもよい。

デバイス情報送信部４０２は、画像形成装置１０２から収集したデバイス情報をデバイス管理サーバー１０１に送信する。例えば、印刷実績ログ情報の収集の場合、デバイス情報送信部４０２は、デバイス管理サーバー１０１へ送信済みの印刷実績ログ情報のポインタを管理する。そして、次回の送信するタイミングでデバイス管理サーバー１０１にいつの印刷実績ログ情報から送信するかを管理している。つまり、デバイス情報送信部４０２は、送信済みの範囲と未送信の範囲を管理し、その送信状況に応じて、未送信の範囲に含まれる情報を送信する。また、未送信の情報が所定のサイズ以上であれば、複数回に分けて送信するようにしてもよい。各種情報の送信方法として、例えば、デバイス管理サーバー１０１のＷｅｂＡＰＩ（Ｗｅｂ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）を呼び出す方法がある。なお、送信するデバイス情報、送信方法は、これらに限定するものではない。例えば、デバイス情報送信部４０２は、定期的にデバイス情報を送信する時間間隔や日時を設定されていてもよいし、所定のイベントが発生したタイミングにて送信するようにしてもよい。

管理情報提供部４０３は、管理アプリケーションが管理する管理情報を、管理アプリケーションの外からの要求に応じて提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）である。例えば、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）ＡＰＩの場合、管理情報提供部４０３にアクセスするためのアクセス先は、「ｈｔｔｐ：／／＜管理アプリケーションのエンドポイント＞／ｓｅｔｔｉｎｇ」のようになる。管理情報とは、管理アプリケーションが動作する際に使用、記録する情報であり、例えば、管理アプリケーションの設定情報、動作ログ情報、前述したデバイス情報収集部４０１で管理するデバイス情報の収集状態を示す情報が挙げられる。

管理情報提供部４０３は、何らかの要因により管理アプリケーションがデバイス管理サーバー１０１と通信できなくなった場合に、他の管理アプリケーションからの要求に対して自身が管理する管理情報を提供するために使用される。つまり、正常に動作している他の管理アプリケーションは、上記に示すようなアクセス先にアクセスすることで、管理情報提供部４０３から管理情報を取得することができる。そして、正常に動作する他の管理アプリケーションが、異常が発生した管理アプリケーションの情報を収集し、デバイス管理サーバー１０１に代理で送信する。これにより、何の要因で管理アプリケーションが異常状態になったのかをデバイス管理サーバー１０１側で把握することが可能となる。管理情報提供部４０３で提供する管理情報の種類は、管理アプリケーションを介して収集可能な情報であればよく、特に限定するものではない。また、複数の管理情報を提供する場合、ＡＰＩは管理情報の種類毎に別のＡＰＩであっても、１つのＡＰＩで複数の管理情報をまとめて収集できてもよい。

アクセストークン管理部４０４は、管理アプリケーションが管理情報提供部４０３で管理情報を提供する際に、要求元を認証するために使用するアクセストークン（トークン情報）を発行し、発行済のアクセストークンを管理する。アクセストークンの発行に係る方式については特に限定するものではない。ここで発行したアクセストークンにおいて、有効期限を設定し、併せて管理してもよい。アクセストークン送信部４０５は、発行したアクセストークンをデバイス管理サーバー１０１に送信し、送信した管理アプリケーションと関連付けてデバイス管理サーバー１０１で管理させる。

アクセストークン認証部４０６は、管理情報提供部４０３に取得要求があった際に、アクセストークン管理部４０４で管理するアクセストークンと一致するアクセストークンが取得要求に付与されているか否かを判定する。アクセストークンが一致する場合は認証成功と判定し、管理情報提供部４０３の処理を継続する。また、アクセストークンに有効期限を設定している場合には、この期限内であるかも併せて判定する。一方、アクセストークンが一致しない場合は、認証失敗と判定し、管理情報提供部４０３の処理を実行しない。上記により、管理アプリケーションは、アクセストークンを持つ正当な要求元に対してのみ、管理情報提供部４０３を介して管理情報を提供する。

アクセストークン管理部４０４によるアクセストークンの発行は、定期的に実施してもよい。これにより、古いアクセストークンを持つ要求元を排除し、セキュリティ強度を上げることができる。また、アクセストークン管理部４０４とアクセストークン認証部４０６が、管理アプリケーションとは異なる認証アプリケーションとして別に存在する構成であってもよい。その場合、アクセストークン送信部４０５は、認証アプリケーションで発行されたアクセストークンを取得し、デバイス管理サーバー１０１に送信する。また、管理情報提供部４０３に取得要求があった際に、認証アプリケーションに認証処理を依頼して、認証結果に応じて管理情報提供部４０３の処理の実行可否を判定する。

調査依頼受付部４０７は、異常状態である管理アプリケーションに対する調査依頼をデバイス管理サーバー１０１から受け付ける。調査依頼とは、ある管理アプリケーションが異常状態となっていることに対応して、どのような異常が発生しているかを特定するためにその管理アプリケーションからの各種情報の収集を、正常に動作している管理アプリケーションに対して依頼することを指す。ここでは、説明を容易にするため、調査対象となる管理アプリケーション（異常状態である管理アプリケーション）を「被調査管理アプリケーション」と称する。また、調査を行う側の管理アプリケーション（調査依頼を受けた管理アプリケーション）を「調査管理アプリケーション」と称する。

調査依頼を受け付ける際に、調査管理アプリケーションは、被調査管理アプリケーションに対する管理情報提供部４０３の情報とアクセストークンを、デバイス管理サーバー１０１から受信する。調査依頼の受付方法の１つとして、管理アプリケーションがデバイス管理サーバー１０１に対して、自身への処理要求があるかを定期的に確認し、その処理要求の１つとして調査依頼を受け付ける方法がある。受付方法の別の方法として、デバイス管理サーバー１０１が管理アプリケーションに対して調査依頼を送信する方法がある。しかし、調査依頼の方法は、これらに限定するものではなく、他の方法であってもよい。なお、デバイス管理サーバー１０１が複数の管理アプリケーションのうち、いずれの管理アプリケーションに対して調査依頼を行うかを決定する方法については処理フローと併せて後述する。

管理情報収集部４０８は、デバイス管理サーバー１０１からの調査依頼にて指定された被調査管理アプリケーションの管理情報提供部４０３に対し、受信したアクセストークンを用いて呼び出しを行い、被調査管理アプリケーションから管理情報を収集する。動作装置情報収集部４０９は、管理アプリケーションがインストールされている画像形成装置１０２または情報処理装置１０３に対して、被調査管理アプリケーションの管理情報提供部４０３を介さずに動作装置情報を収集する。動作装置情報とは、管理アプリケーションがインストールされている装置における、起動状態、オペレーションシステムに関する情報、ネットワークに関する情報などが該当する。しかし、デバイス管理サーバー１０１との通信に関係するものであればよく、特に限定するものではない。また、動作装置情報収集部４０９は、画像形成装置１０２と情報処理装置１０３に応じて、取得方法および取得内容を変更してもよい。動作装置情報を取得することにより、例えば起動状態など、管理アプリケーションが動作する装置側の要因で、各種情報をデバイス管理サーバー１０１に通信できない場合も、その要因に関する情報を収集することができる。

管理情報送信部４１０は、調査管理アプリケーションとして動作している際に、調査依頼への応答として、管理情報収集部４０８で収集した管理情報、および、動作装置情報収集部４０９で収集した動作装置情報を、デバイス管理サーバー１０１に送信する。回復処理実行部４１１は、調査依頼受付部４０７が、デバイス管理サーバー１０１から被調査管理アプリケーションに対する回復処理の実行要求を受け付けた場合に、被調査管理アプリケーションに対して回復処理を実行させる。回復処理とは、例えば、管理アプリケーションの再起動や、管理アプリケーションが動作する装置の再起動などが挙げられる。これにより、デバイス管理サーバー１０１から、異常状態が生じている管理アプリケーションからの情報収集だけではなく、その管理アプリケーションの復旧を試みることも可能となる。

（デバイス管理サーバー）
図５は、デバイス管理サーバー１０１のソフトウェア構成の例を示す。図５に示されている各ソフトウェア構成の機能を実現するプログラムは、ハードディスク３０３に記憶されており、ＣＰＵ３０１がメモリ３０２にプログラムをロードし実行することで、これらの機能は実現される。

テナント管理部５０１は、図１における顧客Ａ、顧客Ｂといった単位でテナントとして分離して、デバイスや収集したデバイス情報などを分離して管理する。ここでのテナントとは、契約や顧客に応じて設けられた管理グループの単位を示し、テナントごとに例えば本実施形態に係る画像形成装置などの管理対象が設定される。テナント別に管理する方法として、データベースを別にする方法、テーブルを別にする方法、テーブル内のＩＤで区別する方法、テナント別にアクセス権を変える方法などがあるが、これら特定の方法に限定するものではない。テナントごとに管理することで、テナント間の干渉を防止し、セキュアな環境を実現することが可能となる。更に、デバイス管理サーバー１０１は、クライアント端末１０４等から、各種デバイスの管理設定や各種要求を受け付けるための画面（不図示）を提供する部位を備えていてもよい。

デバイス情報管理部５０２は、管理アプリケーションから収集した画像形成装置１０２それぞれのデバイス情報をテナント別に管理する。管理アプリケーション管理部５０３は、顧客環境に配置された管理アプリケーションの情報をテナント別に管理する。

管理アプリケーション異常検知部５０４は、管理アプリケーション管理部５０３の中で異常状態になっている管理アプリケーションを検知する。異常検知方法の一例として、管理アプリケーションがデバイス管理サーバー１０１に最後に通信してから、特定期間以上通信がない場合に異常と判定する。また、管理アプリケーションから、例えば動作装置のハードディスクの空き容量が少ないなどの通知を受けたことに応じて異常と判定してもよい。ここでの異常を検知するための特定期間や、通知の種類などは予め定義され、管理されているものとする。

調査管理アプリケーション選定部５０５は、管理アプリケーション異常検知部５０４が異常と判定した管理アプリケーションに対して、調査を実行する他の管理アプリケーション（調査管理アプリケーション）を選定する。選定処理の詳細については、図９で後述する。

アクセストークン管理部５０６は、管理アプリケーションのアクセストークン送信部４０５から受信したアクセストークンをテナント別に管理する。調査依頼部５０７は、調査管理アプリケーション選定部５０５で選定した管理アプリケーションの調査依頼受付部４０７に対して調査依頼を行う。この調査依頼を受け付けた管理アプリケーションが、調査管理アプリケーションとしての役割を担う。調査依頼部５０７は、調査依頼を行う際に、異常検知した管理アプリケーションから予め受信していたアクセストークンをアクセストークン管理部５０６から取得して調査依頼と共に送信する。

回復処理判定部５０８は、異常状態である管理アプリケーションに対して、回復処理の実行を行うか否かを判定する。回復処理の判定処理の詳細については、図１０で後述する。通信部５０９は、管理アプリケーションとの通信処理を担い、デバイス情報の受信、調査依頼の送信、管理情報の受信などを行う。

本実施形態では、デバイス管理サーバー１０１が管理アプリケーションの異常を判定するため、管理アプリケーションが不意にデバイス管理サーバー１０１と通信できなくなった場合も、他の管理アプリケーションに調査を依頼することができる。更に、調査管理アプリケーション選定部５０５が選定した適切な管理アプリケーションにのみアクセストークンを付与することで、適切な管理アプリケーションのみに異常な管理アプリケーションの管理情報を収集させることができる。

［データ構造例］
図６は、デバイス管理サーバー１０１の管理アプリケーション管理部５０３、アクセストークン管理部５０６が管理する、管理アプリケーション情報とアクセストークンのデータ構造の一例を示す図である。

テナントＩＤ６０１は、テナント管理部５０１でテナントを一意に識別するための識別情報（識別子）である。テナントＩＤが同じレコードについては、同じテナント内の情報として識別される。なお、同じテナントＩＤであっても、物理的に異なる拠点に各装置が配置されてよい。管理アプリＩＤは、顧客環境に配置した管理アプリケーションを一意に識別するための識別情報である。管理アプリＩＤは、例えば、管理アプリケーションを顧客環境にインストールし、デバイス管理サーバー１０１と初めて通信した際にデバイス管理サーバー１０１が発行する。タイプ６０３は、管理アプリケーションがインストールされている装置が、画像形成装置１０２であるか、情報処理装置１０３であるかを識別する情報である。図６では、画像形成装置１０２の場合は「Ｄｅｖｉｃｅ」、情報処理装置１０３の場合は「ＰＣ」として示している。

バージョン６０４は、管理アプリケーションのソフトウェアバージョンを示す情報である。管理情報提供部４０３や管理情報収集部４０８で収集可能な管理情報の種類（項目）は、管理アプリケーションのバージョンに応じて変わる。これは、管理アプリケーションは、そのバージョンに応じて機能が変更・拡張されているためである。本実施形態では、管理情報提供部４０３や管理情報収集部４０８で収集可能な管理情報の種類を特定する際に、管理アプリケーションのバージョン情報を使用する。例えば、バージョンが「１．０．０」の管理アプリケーションは、管理情報提供部４０３や管理情報収集部４０８を持たない構成とする。また、バージョン「１．２．０」の管理アプリケーションは、バージョン「２．０．０」の管理アプリケーションと比べて管理情報提供部４０３や管理情報収集部４０８で収集可能な管理情報の種類が少ない構成とする。このような管理アプリケーションのバージョン情報とそのバージョンに応じて設けられた機能（部位）は、図６に示すテーブルの他のテーブルにて対応付けて管理するようにしてもよい。

アクセストークン６０５は、管理アプリケーションのアクセストークン送信部４０５から受信したアクセストークンを示す情報である。本実施形態では、バージョン「１．０．０」の管理アプリケーションでは、管理情報提供部４０３を持たないため、アクセストークンも管理されていない。一方、バージョン「１．２．０」以降の管理アプリケーションは、管理情報提供部４０３を備え、アクセストークンに対応しているものとする。

ステータス６０６は、管理アプリケーションの状態を示す情報であり、管理アプリケーション異常検知部５０４により更新される。ステータス６０６の値としては「正常」もしくは「異常」が設定される。なお、「異常」の場合には、更に詳細にその内容を示すようにしてもよい。最終通信日時６０７は、管理アプリケーションがデバイス管理サーバー１０１と最後に通信した日時を示す情報である。本実施形態では、２行目の管理アプリケーションの最終通信日時からの経過時間が、予め設定された閾値を超えたことで、管理アプリケーション異常検知部５０４がステータス６０６を「異常」としている。ここでの閾値は、テナントごとに設定できるようにしてもよいし、一律で同じ値が設定できるようにしてもよい。設置場所６０８は、顧客環境に配置された管理アプリケーションの場所を示す情報であり、デバイス管理サーバー１０１の管理アプリケーションの設定画面（不図示）により入力された任意の文字列を管理する。

なお、図６に示すデータ構造は一例であり、管理する情報の種類、テーブル構造をこの例に限定するものではない。また、各種情報を複数のテーブルに分けて管理してもよいし、他の情報を含めて管理してもよい。

［処理フロー］
（管理情報収集処理）
図７は、デバイス管理サーバー１０１から調査依頼を受けた管理アプリケーション（調査管理アプリケーション）が、調査対象の管理アプリケーション（被調査管理アプリケーション）から管理情報を収集する際の処理フローチャートである。図４で示した管理アプリケーションのソフトウェア構成の各構成要素は、本実施形態では、インストールされた画像形成装置１０２または情報処理装置１０３のＣＰＵ、メモリ、ハードディスク等が動作することにより実現される。そして、以下に示すフローチャートの手順が、プログラムとして各構成要素のメモリ、ハードディスクのいずれかの記憶手段に記憶されており、ＣＰＵにより実行される。

Ｓ７０１にて、調査管理アプリケーションの動作装置情報収集部４０９は、被調査管理アプリケーションが動作する装置に対して導通確認を行う。導通確認処理の一例として、調査依頼にて示された被調査管理アプリケーションのＩＰアドレスに対してＰＩＮＧコマンドを実行することで、通信確認を試行する。この処理の結果、被調査管理アプリケーションから応答があったか否かにより、導通確認が成功したか否かを判定する。

Ｓ７０２にて、調査管理アプリケーションの動作装置情報収集部４０９は、導通確認の結果が成功だったか否かを判定する。導通確認の結果が失敗だった場合（Ｓ７０２にてＮＯ）、Ｓ７１１へ進み、導通確認の結果が成功だった場合（Ｓ７０２にてＹＥＳ）Ｓ７０３へ進む。

Ｓ７０３にて、調査管理アプリケーションの動作装置情報収集部４０９は、被調査管理アプリケーションが動作する装置の情報（動作装置情報）を収集する。

Ｓ７０４にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションに管理情報提供部４０３が存在するか否かを確認する。管理情報提供部４０３が存在する場合は（Ｓ７０４にてＹＥＳ）Ｓ７０５に進み、存在しない場合は（Ｓ７０４にてＮＯ）Ｓ７１０に進む。本実施形態では、図６で先述したように、管理アプリケーションのバージョンの情報によって判定することができる。例えば、被調査管理アプリケーションが図６の４行目の管理アプリケーションの場合、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションに管理情報提供部４０３が存在しないと判定する。なお、判定方法はこれに限定するものではなく、他の方法を用いてもよい。別の判定方法の一例として、デバイス管理サーバー１０１が上記判定を行い、調査管理アプリケーションに判定結果に応じた調査依頼を送信するようにしてもよい。

Ｓ７０５にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションの管理情報提供部４０３が応答可能かを判定する。応答可能な場合は（Ｓ７０５にてＹＥＳ）Ｓ７０６に進み、応答不可能な場合は（Ｓ７０５にてＮＯ）Ｓ７１０に進む。判定方法の一例として、応答可能かを確認する専用のＡＰＩを呼び出した結果に基づいて判定してよい。

Ｓ７０６にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションの管理情報提供部４０３に対して、デバイス情報の収集状況に関する情報を提供するように要求することで、この情報を収集する。この要求に従って、被調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションのデバイス情報収集部４０１で管理するデバイス情報の収集状態を示す情報を収集し、調査管理アプリケーションに提供する。当該情報を収集することで、調査管理アプリケーション（もしくは、デバイス管理サーバー１０１）は、被調査管理アプリケーションの収集状況から、異常の緊急度を判定することができる。例えば、収集済みの印刷実績ログは、所定の時間が経過した後、もしくは、所定の容量を記憶した場合に、自動的に過去のログが削除されるとする。そのため、被調査管理アプリケーションにおいて、収集済みの印刷実績ログ情報のポインタが古い場合、管理対象の画像形成装置１０２から未収集の印刷実績ログ情報が削除される可能性があり、緊急度を高いと判定できる。

Ｓ７０７にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションの管理情報提供部４０３に対して、動作ログ情報を提供するように要求することで、被調査管理アプリケーションの動作ログ情報を収集する。調査管理アプリケーションが動作ログ情報を収集してデバイス管理サーバー１０１に送信することにより、開発者はデバイス管理サーバー１０１から異常状態の管理アプリケーションの動作ログ情報を収集できる。これにより、例えば、開発者は、顧客環境に赴くことなく障害の原因調査をすることができる。

Ｓ７０８にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションの管理情報提供部４０３に対して、設定情報を提供するように要求することで、被調査管理アプリケーションの設定情報を収集する。設定情報とは、ＩＰアドレスやプロキシサーバーなどのネットワーク設定、デバイス管理サーバー１０１に対する送信タイミングや認証方法などの送信設定などが該当する。設定情報を収集することで、被調査管理アプリケーションの設定変更や設定不備によりデバイス管理サーバー１０１と通信できない、という原因を調査・特定することができる。

Ｓ７０９にて、調査管理アプリケーションの管理情報収集部４０８は、被調査管理アプリケーションの管理情報提供部４０３に対して、管理しているデバイス情報を提供するように要求する。これにより、調査管理アプリケーションは、被調査管理アプリケーションの管理対象の画像形成装置１０２のデバイス情報を収集し、被調査管理アプリケーションに代わって、デバイス管理サーバー１０１に送信することができる。デバイス情報の収集手段の例として、被調査管理アプリケーションのＡＰＩを介して、被調査管理アプリケーションが管理する画像形成装置１０２のデバイス情報を収集する。これにより、被調査管理アプリケーションのデバイス情報収集部４０１は正常に動作しているが、何らかの原因により被調査管理アプリケーションのデバイス情報送信部４０２が正常に動作していない場合に、調査管理アプリケーションが代理で、収集したデバイス情報をデバイス管理サーバー１０１に送信することができる。

Ｓ７１０にて、調査管理アプリケーションの管理情報送信部４１０は、Ｓ７０３〜Ｓ７０９で収集した各種情報をデバイス管理サーバー１０１に送信する。このとき、収集できなかった情報についても、収集できなかったという結果が原因調査に有用であるため、被調査管理アプリケーションの管理情報提供部４０３が返却したエラー内容を併せて送信する。そして、本処理フローを終了する。

Ｓ７１１にて、調査管理アプリケーションの管理情報収集部４０８は、Ｓ７０１の処理にて導通確認できなかったという結果をデバイス管理サーバー１０１に送信する。そして、本処理フローを終了する。

なお、Ｓ７０６〜Ｓ７０９に記載した管理情報の収集の順番については、図７にて示した順番に限定するものではなく、例えば、情報の優先度や処理負荷などを考慮して他の順番であってもよい。また、被調査管理アプリケーションのバージョンに応じて、被調査管理アプリケーションから収集できないことが明らかである管理情報については、当該管理情報の収集処理をスキップしてもよい。

（管理情報提供処理）
図８は、調査対象の管理アプリケーション（被調査管理アプリケーション）が、調査依頼を受けた管理アプリケーション（調査管理アプリケーション）に対して管理情報を提供する際の処理フローチャートである。図４で示した管理アプリケーションのソフトウェア構成の各構成要素は、本実施形態では、インストールされた画像形成装置１０２または情報処理装置１０３のＣＰＵ、メモリ、ハードディスク等が動作することにより実現される。そして、以下に示すフローチャートの手順が、プログラムとして各構成要素のメモリ、ハードディスクのいずれかの記憶手段に記憶されており、ＣＰＵにより実行される。当然ながら、図７のＳ７０１にて導通確認が失敗した場合には調査管理アプリケーションから各種要求を受信できないため、本処理フローは実行されない。また、被調査管理アプリケーションがインストールされた装置自体に障害が発生している場合などにも同様に実行されない場合が生じる。

Ｓ８０１にて、被調査管理アプリケーションの管理情報提供部４０３は、調査管理アプリケーションから、管理情報の取得要求を受信する。

Ｓ８０２にて、被調査管理アプリケーションのアクセストークン認証部４０６は、取得要求と併せて受信したアクセストークンを検証し、正当な要求元からの要求か否かを判定する。アクセストークンによる認証が失敗であると判定した場合（Ｓ８０２にてＮＯ）、Ｓ８０３へ進み、認証が成功した場合（Ｓ８０２にてＹＥＳ）、Ｓ８０４へ進む。

Ｓ８０３にて、被調査管理アプリケーションの管理情報提供部４０３は、取得要求の要求元に認証失敗という結果を送信する。そして、本処理フローを終了する。

Ｓ８０４にて、被調査管理アプリケーションの管理情報提供部４０３は、取得要求にて要求された管理情報を要求元に提供する。そして、本処理フローを終了する。

なお、上述したように、認証アプリケーションとしてアクセストークンの認証を行う部位が管理アプリケーションとは別に設けられている場合には、Ｓ８０２にて、管理アプリケーションは、その認証アプリケーションに対して認証要求を行うこととなる。

（調査管理アプリケーションの選定処理）
図９は、デバイス管理サーバー１０１が調査を実行する管理アプリケーション（調査管理アプリケーション）を選定する際の処理フローチャートである。本処理は、所定の時間間隔にて定期的に実行されてもよいし、所定のイベントが発生したタイミングにて実行するようにしてもよい。図５で示したデバイス管理サーバー１０１のソフトウェア構成の各構成要素は、本実施形態では、情報処理装置１０３のＣＰＵ、メモリ、ハードディスク等が動作することにより実現される。そして、以下に示すフローチャートの手順が、プログラムとして各構成要素のメモリ、ハードディスクのいずれかの記憶手段に記憶されており、ＣＰＵにより実行される。

Ｓ９０１にて、管理アプリケーション異常検知部５０４は、図６に示すテーブル（ステータス６０６）を参照して、異常状態にある管理アプリケーションを検知する。

Ｓ９０２にて、調査管理アプリケーション選定部５０５は、Ｓ９０１で検知した異常状態にある管理アプリケーションと同一テナントに、管理情報収集部４０８を備える正常状態にある他の管理アプリケーションが存在するか否かを判定する。ここでは、例えば、管理アプリケーション管理部５０３を介して、図６に示したテナントＩＤ６０１、バージョン６０４、ステータス６０６等を参照して特定する。同一テナントに管理情報収集部４０８を備える正常状態にある他の管理アプリケーションが存在しない場合は（Ｓ９０２にてＮＯ）、調査管理アプリケーション選定部５０５は調査依頼が可能な管理アプリケーションは存在しないと判定し、本処理フローを終了する。一方、他の管理アプリケーションが存在する場合には（Ｓ９０２にてＹＥＳ）Ｓ９０３に進む。

Ｓ９０３にて、調査管理アプリケーション選定部５０５は、調査管理アプリケーションに対する限定設定があるか否かを判定する。ここでの限定設定とは、設定画面（不図示）によりユーザーから調査を実行する管理アプリケーション（調査管理アプリケーションとして動作可能な管理アプリケーション）を予め限定した設定を指す。例えば、被調査管理アプリケーションと同じ設置場所や、同じサブネット設定の管理アプリケーションにのみ、調査管理アプリケーションとして動作することを限定するような設定が挙げられる。これにより、例えば、同一テナントの中でも物理的に離れた位置にある管理アプリケーション間で通信させたくないような場合に、調査依頼の対象を制御することができる。限定設定があると判定された場合には（Ｓ９０３にてＹＥＳ）Ｓ９０４に進み、限定設定がないと判定された場合には（Ｓ９０３にてＮＯ）Ｓ９０５に進む。

Ｓ９０４にて、調査管理アプリケーション選定部５０５は、設定された限定設定の範囲で調査を実行する管理アプリケーションの候補を絞り込む。

Ｓ９０５にて、調査管理アプリケーション選定部５０５は、異常状態にある管理アプリケーションに対して、過去に管理情報を収集しているか否かを判定する。過去に管理情報を収集している場合は（Ｓ９０５にてＹＥＳ）Ｓ９０６に進み、収集していない場合は（Ｓ９０５にてＮＯ）Ｓ９０８に進む。

Ｓ９０６にて、調査管理アプリケーション選定部５０５は、所定の条件を満たす管理情報収集部４０８を備える管理アプリケーションの有無を確認する。所定の条件を満たす管理アプリケーションが存在する場合は（Ｓ９０６にてＹＥＳ）Ｓ９０８に進み、存在しない場合は（Ｓ９０６にてＮＯ）Ｓ９０８に進む。調査管理アプリケーション選定部５０５は、管理情報収集部４０８の機能情報、または管理情報収集部４０８に対応する管理アプリケーションの属性情報（バージョン情報など）から、所定の条件を満たしている管理情報収集部４０８の有無を判定する。所定の条件とは、最近収集した管理情報よりも、多くの管理情報を収集できる管理情報収集部４０８であるか否かが相当する。例えば最近、管理情報を収集した管理アプリケーションのバージョンが「１．２．０」である場合、同じテナント内にバージョンが「２．０．０」の管理アプリケーションが存在するか否かを判定する。これにより、調査管理アプリケーション選定部５０５は、過去に収集した管理情報が存在する場合であっても、過去の調査結果より多くの管理情報を収集できる場合は、時間を置かずに再度調査を依頼する。

Ｓ９０７にて、調査管理アプリケーション選定部５０５は、最近の収集日時から一定期間が経過しているかを判定する。経過している場合は（Ｓ９０７にてＹＥＳ）Ｓ９０８に進み、経過していない場合は（Ｓ９０７にてＮＯ）調査依頼する管理アプリケーションは存在しないと判定して、本処理フローを終了する。これにより、過去に収集した管理情報より多くの管理情報を収集できる可能性がない場合は、一定の間隔を置くことで、異常状態な管理アプリケーションに負荷を与えないようにできる。ここでの一定期間は、予め設定され、保持されているものとする。

Ｓ９０８にて、調査管理アプリケーション選定部５０５は、調査を実行する管理アプリケーションの候補があるか否かを判定する。候補がある場合（Ｓ９０８にてＹＥＳ）Ｓ９０９へ進み、候補が無い場合（Ｓ９０８にてＮＯ）本処理フローを終了する。

Ｓ９０９にて、調査依頼部５０７は、選定した管理アプリケーションに調査依頼を送信する。この時、図６に示すテーブル（アクセストークン６０５）を参照し、調査対象の管理アプリケーションによって予め登録されたアクセストークンを付与して送信する。そして、本処理フローを終了する。

なお、管理アプリケーション側からデバイス管理サーバー１０１に対して定期的に処理依頼を確認する方法の場合、調査依頼部５０７は、Ｓ９０９で確認にきた管理アプリケーションが選定した調査管理アプリケーションの候補にあれば、調査依頼を送信する。一方、デバイス管理サーバー１０１が管理アプリケーションに対して調査依頼を送信する方法の場合、選定した調査管理アプリケーションの候補の中で、１つ以上の任意の管理アプリケーションに対して調査依頼を送信する。更に、管理アプリケーション管理部５０３で管理アプリケーションの最終通信日時６０７を確認し、選定した候補の中で相対的に最終通信日時が新しく、デバイス管理サーバー１０１と通信できる可能性が高い管理アプリケーションに、優先的に依頼してもよい。

（回復処理の要否判定処理）
図１０は、デバイス管理サーバー１０１が異常状態であることを検知した管理アプリケーションに対して、回復処理を行うか否かを判定する際の処理フローチャートである。図５で示したデバイス管理サーバー１０１のソフトウェア構成の各構成要素は、本実施形態では、情報処理装置１０３のＣＰＵ、メモリ、ハードディスク等が動作することにより実現される。そして、以下に示すフローチャートの手順が、プログラムとして各構成要素のメモリ、ハードディスクのいずれかの記憶手段に記憶されており、ＣＰＵにより実行される。

Ｓ１００１にて、回復処理判定部５０８は、異常状態である管理アプリケーションに対して、過去に管理情報を収集しているかを判定する。収集していない場合は（Ｓ１００１にてＮＯ）Ｓ１００２に進み、収集している場合は（Ｓ１００１にてＹＥＳ）Ｓ１００２に進む。

Ｓ１００２にて、回復処理判定部５０８は、異常状態を検知してから一定期間以上経過しているか否かを判定する。なお、異常を検知してからの経過時間は、図６に示す最終通信日時６０７からの経過時間等に基づいて特定することが可能である。また、ここでの一定期間は予め設定されて保持されているものとする。一定期間以上経過している場合は（Ｓ１００２にてＹＥＳ）Ｓ１００４に進み、経過していない場合は（Ｓ１００２にてＮＯ）緊急性が高くないとして、本処理フローを終了する。

Ｓ１００３にて、回復処理判定部５０８は、収集した管理情報から異常状態である管理アプリケーションの復旧の緊急度を判定する。緊急度が高い場合は（Ｓ１００３にてＹＥＳ）Ｓ１００４に進み、高くない場合は（Ｓ１００３にてＮＯ）本処理フローを終了する。ここでの判定方法として、前述した例のように収集済みの印刷実績ログ情報のポインタが一定期間以上古い場合、印刷実績ログ情報の収集漏れが発生する可能性があり、緊急度を高いと判定する。なお、ここでの判定方法は上記に限定するものではなく、例えば、所定のイベントが発生した場合などに緊急度が高いと判定してもよい。

Ｓ１００４にて、回復処理判定部５０８は、予め設定されたメールアドレスに対して、異常状態である管理アプリケーションがデバイス管理サーバー１０１に通信できていない旨、または復旧の緊急度が高い旨を通知する。ここで設定されているメールアドレスとは、異常状態である管理アプリケーションに対するデバイス管理サービスの提供を受けている顧客でもよいし、デバイス管理サービスのシステム管理者や開発者であってもよい。

Ｓ１００５にて、回復処理判定部５０８は、異常状態の検知時の自動再起動の設定有無を確認する。自動再起動の設定が有効に設定されている場合は（Ｓ１００５にてＹＥＳ）Ｓ１００６に進み、設定されていない場合は（Ｓ１００５にてＮＯ）本処理を終了する。自動再起動とは、設定画面（不図示）から予めユーザーによって管理アプリケーションが異常状態になり、緊急度が高いと判定された場合に再起動を行うか否かを設定するものである。この設定は、管理アプリケーションそれぞれ（もしくは、テナント単位）に設定され、デバイス管理サーバー１０１にて管理されているものとする。

Ｓ１００６にて、回復処理判定部５０８は、異常状態である管理アプリケーションの再起動を、図９で選定した調査管理アプリケーションに対して要求する。そして、本処理フローを終了する。

この回復処理判定部５０８による回復処理判定により、緊急度の高い状態の管理アプリケーションに対しては、メール通知や自動再起動といった復旧処理を行うことができる。

以上、本実施形態により、デバイス管理アプリケーションが不意に異常状態になった場合も含めて、当該デバイス管理アプリケーションの異常情報をセキュアにサーバーに収集することができる。

＜第２の実施形態＞
第１の実施形態では、管理アプリケーションの管理情報提供部４０３は、要求元が適切なアクセストークンを持っていることをアクセストークン認証部４０６で認証することで正当な要求元として判定した。第２の実施形態では、さらにセキュリティ強度を向上させるために、管理アプリケーション間で事前に同一テナント内の正当な管理アプリケーションであることを認証する。つまり、本実施形態では、同一テナント内にある管理アプリケーション間で事前に相互認証を行い、認証鍵（認証情報）を発行する構成を備える。

図１１は、第２の実施形態に係る画像形成装置１０２、情報処理装置１０３にインストールされた管理アプリケーションのソフトウェア構成の例を示す。図４との差異として、管理アプリケーション事前認証部１１０１、認証鍵管理部１１０２、事前認証要求部１１０３が追加されている点である。第１の実施形態にて示した図４と同じ構成については、同じ参照番号を付し、説明を省略する。

管理アプリケーション事前認証部１１０１は、他の管理アプリケーションが同一テナント内の正当な管理アプリケーションであるか否かを認証する。認証方法の例として、管理アプリケーション内に保持するテナント毎に一意な情報を確認する方法や、デバイス管理サーバー１０１に問い合わせることで確認する方法がある。また、Ｂｌｕｅｔｏｏｔｈ（登録商標）やＷｉ−Ｆｉ（Ｆｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ；登録商標）のような距離に依存する無線通信を実行し、一定範囲に存在する管理アプリケーションであることを、同一テナントであることの判定に加えてもよい。

認証鍵管理部１１０２は、管理アプリケーション事前認証部１１０１による事前認証に成功した際に認証鍵を発行し、その事前認証が成功した認証済みの管理アプリケーションに認証鍵を送信する。また、管理情報提供部４０３が呼び出された時に、要求元の管理アプリケーションが持つ認証鍵が正当なものか否かを検証する。上記のように、管理アプリケーションが異常状態の場合は通信を含む処理はできない可能性があるため、正常状態であるうちに通信を用いる事前認証をしておき、異常状態になった時は認証鍵などの単純な認証を行う。ここで用いられる認証鍵等の認証の方式については、特に限定するものではない。

事前認証要求部１１０３は、他の管理アプリケーションに事前認証を要求する。本実施形態では、事前認証要求部１１０３は、デバイス管理サーバー１０１から要求対象の管理アプリケーションのリストを受信する。そして、事前認証要求部１１０３は、そのリストに含まれる他の管理アプリケーションの管理アプリケーション事前認証部１１０１および認証鍵管理部１１０２と、先述した認証手段で相互に事前認証を行う。

本実施形態では、第１の実施形態にて述べた図８のＳ８０２の認証処理において、アクセストークン認証部４０６による認証に加え、認証鍵管理部１１０２による認証を行う。これにより、本実施形態は、第１の実施形態と比べてセキュリティ強度を更に向上させることができる。例えば、アクセストークンを不正に入手したプログラムからの管理情報提供部４０３の呼び出しを禁止することができる。

＜第３の実施形態＞
第１の実施形態では、デバイス管理サーバー１０１の調査管理アプリケーション選定部５０５は、同一テナント内や調査管理アプリケーションの限定設定の範囲で調査管理アプリケーションを選定した。この場合、同一テナントに属する管理アプリケーションであっても、調査対象の管理アプリケーション（被調査管理アプリケーション）と元々ネットワーク的に接続できない管理アプリケーションが選定される可能性がある。このような可能性があると、図７のＳ７１１で被調査管理アプリケーションと導通確認できなかった結果が得られた場合に、選定した調査管理アプリケーションに起因する問題なのか、被調査管理アプリケーションに起因する問題なのかが特定できない。そこで、本実施形態では、この問題を解消するための構成について説明する。

［ソフトウェア構成］
（管理アプリケーション）
図１２は、第３の実施形態に係る画像形成装置１０２、情報処理装置１０３にインストールされた管理アプリケーションのソフトウェア構成の例を示す。図４との差異として、導通確認部１２０１、通信履歴管理部１２０２、通信履歴送信部１２０３が追加されている点である。第１の実施形態にて示した図４と同じ構成については、同じ参照番号を付し、説明を省略する。

導通確認部１２０１は、デバイス管理サーバー１０１から指示された他の管理アプリケーションに対してネットワーク的に接続可能か否かを判定するために導通確認処理を行う。導通確認処理の一例として、他の管理アプリケーションが持つＡＰＩを呼ぶ方法や、管理アプリケーションのＩＰアドレスに対してＰＩＮＧコマンドを実行する方法などが挙げられる。デバイス管理サーバー１０１は、同一テナント内の管理アプリケーションや、さらに限定設定された管理アプリケーションへの導通確認を指示する。

通信履歴管理部１２０２は、導通確認部１２０１で実行した導通確認の結果を管理する。通信履歴送信部１２０３は、通信履歴管理部１２０２で管理する導通確認の結果を、デバイス管理サーバー１０１に送信する。導通確認部１２０１が、１日１回などの定期的に管理アプリケーションと導通確認し、通信履歴送信部１２０３は、新しい導通確認の結果をデバイス管理サーバー１０１に送信してもよい。この場合、導通確認部１２０１による導通確認の間隔は予め定義され、導通確認部１２０１にて管理されているものとする。

（デバイス管理サーバー）
図１３は、第３の実施形態に係るデバイス管理サーバー１０１のソフトウェア構成の例を示す。図５との差異として、通信履歴管理部１３０１が追加されている点である。第１の実施形態にて示した図５と同じ構成については、同じ参照番号を付し、説明を省略する。

通信履歴管理部１３０１は、管理アプリケーションの通信履歴送信部１２０３から送信された管理アプリケーション間の通信履歴を受信し、記憶する。また、図９で先述した調査管理アプリケーションの選定処理において、Ｓ９０９で調査管理アプリケーション選定部５０５は異常状態である管理アプリケーションと通信履歴が無い管理アプリケーションは、調査管理アプリケーションとして選定しない。一方、Ｓ９０９で複数の管理アプリケーションが調査管理アプリケーションの候補として残った場合は、新しい通信履歴を持つ管理アプリケーションに調査依頼を送る。

上記のように、調査管理アプリケーションの選定処理において管理アプリケーション間の通信履歴を加味し、元々ネットワーク的に通信できない管理アプリケーションの調査結果を除く。これにより、本実施形態では、第１の実施形態の効果に加え、調査結果の信憑性を向上させることができる。また、新しい通信履歴を持つ管理アプリケーションに調査依頼を行うことで、管理情報の収集が成功する確率を向上させることができる。

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

４０１…デバイス情報収集部、４０２…デバイス情報送信部、４０３…管理情報提供部、４０４…アクセストークン管理部、４０５…アクセストークン送信部、４０６…アクセストークン認証部、４０７…調査依頼受付部、４０８…管理情報収集部、４０９…動作装置情報収集部、４１０…管理情報送信部、４１１…回復処理実行部、５０１…テナント管理部、５０２…デバイス情報管理部、５０３…管理アプリケーション管理部、５０４…管理アプリケーション異常検知部、５０５…調査管理アプリケーション選定部、５０６…アクセストークン管理部、５０７…調査依頼部、５０８…回復処理判定部、５０９…通信部

Claims (11)

1. 複数のネットワークデバイスと、前記複数のネットワークデバイスから収集した情報を管理する管理システムと、を含むネットワークシステムであって、
   前記複数のネットワークデバイスのそれぞれで実行される管理アプリケーションは、管理アプリケーションが正当な要求元からの管理情報の要求を受け付けたかを判定するために検証されるトークン情報を前記管理システムに送信し、
   前記管理システムは、
   ネットワークデバイスまたはネットワークデバイスで実行される管理アプリケーションの識別情報を用いて、１つの管理グループに対して複数のネットワークデバイスを関連付けて管理する管理手段と、
   ネットワークデバイスから前記トークン情報を受信する受信手段と、
   当該受信したトークン情報と、当該ネットワークデバイスおよび当該ネットワークデバイスで実行される管理アプリケーションの識別情報の少なくともいずれかと、を関連付けて登録する登録手段と、
   前記複数のネットワークデバイスのうちの第１のネットワークデバイスとの通信の異常を検知した際に、前記第１のネットワークデバイスと同じ管理グループに関連付けて管理されている第２のネットワークデバイスに対して、前記第１のネットワークデバイスから受信済みの前記登録されたトークン情報を送信する第１送信手段と、を有し、
   前記第２のネットワークデバイスは、
   前記管理システムから送信されてきた前記トークン情報を用いて、前記第１のネットワークデバイスとの通信を試行する通信手段と、
   前記第１のネットワークデバイスとの通信に関する情報を前記管理システムに送信する第２送信手段と、を有することを特徴とするネットワークシステム。
2. 前記管理グループは、前記管理システムでの管理で用いるマルチテナント構成に含まれる１つのテナントであることを特徴とする請求項１に記載のネットワークシステム。
3. 前記管理システムと前記第１のネットワークデバイスとの間の通信が所定の期間にわたって行われていない場合に、前記管理システムで、前記異常として検知されることを特徴とする請求項１または２に記載のネットワークシステム。
4. 前記第１のネットワークデバイスで実行される前記管理アプリケーションは、前記第２のネットワークデバイスからの前記通信において、前記トークン情報を含むデータ取得要求を受け付けた際に、当該トークン情報による検証が成功したことに応じてデータを前記第２のネットワークデバイスに提供し、
   前記第２送信手段は、前記第１のネットワークデバイスから提供された前記データを、前記通信に関する情報として、前記管理システムに送信することを特徴とする請求項１乃至３のいずれか１項に記載のネットワークシステム。
5. 前記通信に関する情報には、前記第１のネットワークデバイスで実行される管理アプリケーションの設定情報、該管理アプリケーションのログ情報の収集状況に関する情報、及び、該管理アプリケーションのログ情報の送信状況に関する情報の少なくともいずれかが含まれることを特徴とする請求項１乃至４のいずれか１項に記載のネットワークシステム。
6. 前記通信に関する情報には、前記第１のネットワークデバイスで実行される管理アプリケーションにより収集されたログ情報が含まれることを特徴とする請求項１乃至５のいずれか１項に記載のネットワークシステム。
7. 前記通信に関する情報には、前記第１のネットワークデバイスの起動状態、及び、前記第１のネットワークデバイスの設定情報の少なくともいずれかが含まれることを特徴とする請求項１乃至６のいずれか１項に記載のネットワークシステム。
8. 前記第２送信手段は、前記第１のネットワークデバイスとの通信を試行した際の成功もしくは失敗の情報を、前記通信に関する情報として、前記管理システムに送信することを特徴とする請求項１乃至７のいずれか１項に記載のネットワークシステム。
9. 前記複数のネットワークデバイスのそれぞれで実行される管理アプリケーションは、前記管理システムにて管理されているトークン情報を更新するように、定期的に前記管理システムに対して新たなトークン情報を送信することを特徴とする請求項１乃至８のいずれか１項に記載のネットワークシステム。
10. 前記第１送信手段は、さらに、前記第１のネットワークデバイスにて検知された異常が所定の条件を満たす場合、前記第２のネットワークデバイスに対して、前記第１のネットワークデバイスもしくは前記第１のネットワークデバイスで実行される管理アプリケーションの再起動を行わせるための要求を送信することを特徴とする請求項１乃至９のいずれか１項に記載のネットワークシステム。
11. 複数のネットワークデバイスと、前記複数のネットワークデバイスから収集した情報を管理する管理システムと、を含むネットワークシステムにおける制御方法であって、
    前記複数のネットワークデバイスのそれぞれで実行される管理アプリケーションは、管理アプリケーションが正当な要求元からの管理情報の要求を受け付けたかを判定するために検証されるトークン情報を前記管理システムに送信し、
    前記管理システムにおいて、
    ネットワークデバイスまたはネットワークデバイスで実行される管理アプリケーションの識別情報を用いて、１つの管理グループに対して複数のネットワークデバイスを関連付けて管理する管理工程と、
    ネットワークデバイスから前記トークン情報を受信する受信工程と、
    当該受信したトークン情報と、当該ネットワークデバイスおよび当該ネットワークデバイスで実行される管理アプリケーションの識別情報の少なくともいずれかと、を関連付けて登録する登録工程と、
    前記複数のネットワークデバイスのうちの第１のネットワークデバイスとの通信の異常を検知した際に、前記第１のネットワークデバイスと同じ管理グループに関連付けて管理されている第２のネットワークデバイスに対して、前記第１のネットワークデバイスから受信済みの前記登録されたトークン情報を送信する第１送信工程と、を有し、
    前記第２のネットワークデバイスにおいて、
    前記管理システムから送信されてきた前記トークン情報を用いて、前記第１のネットワークデバイスとの通信を試行する通信工程と、
    前記第１のネットワークデバイスとの通信に関する情報を前記管理システムに送信する第２送信工程と、を有することを特徴とする制御方法。

Images