JP6996178B2 - 機器管理システム、機器管理方法およびプログラム - Google Patents

Description

本発明は、機器管理システム、機器管理方法およびプログラムに関する。

ローカルネットワーク内に設けられた情報機器をローカルネットワーク外から遠隔管理する遠隔管理システムが知られている。遠隔管理システムは、例えば、情報機器から機器情報を取得可能な仲介装置をローカルネットワーク内に設けている。そして、ローカルネットワーク外に位置する管理サーバは、仲介装置との間でファイアウォールを介して通信を行うことで、情報機器の遠隔管理を実現している。

このようなシステムにおいて、仲介装置は、接続された情報機器の障害（異常）を検知して、情報機器の機器状態を管理サーバに対して送信し、管理サーバが情報機器の障害（異常）を解消するための処理を実行することができるものがある。

例えば、特許文献１には、特定の管理サーバが稼働していない場合、ルータから特定の管理サーバに対する起動依頼を他の管理サーバに対して送信し、他の管理サーバが特定の管理サーバを起動させることで、ルータからクラウド側ネットワークに向けて障害に関する情報を送信する技術が開示されている。

しかし、上記の情報機器の障害（異常）を改善する方法では、ルータである仲介装置に接続する情報機器や仲介装置自体に障害が発生したあとの事後処理となり、障害が発生した場合にシステムの稼働率が下がってしまうという課題があった。

本発明に係る機器管理システムは、ローカルネットワーク内の機器と接続される仲介装置と、ファイアウォールを介して通信を行う機器管理システムであって、前記仲介装置から該仲介装置の状態を示すステータス情報を取得するタイミングを、前記仲介装置ごとに設定するとともに、特定のリソース項目に対応する情報を前記ステータス情報として、前記仲介装置に送信させるように設定する設定手段と、前記設定されたタイミングで、前記仲介装置から前記ステータス情報を受信し、前記設定された前記特定のリソース項目に対応する前記ステータス情報を受信する受信手段と、前記受信されたステータス情報が所定の条件を満たす場合、前記条件に紐づく所定の処理の実行を指示する指示情報を決定する決定手段と、前記決定された前記指示情報を、前記仲介装置に対して送信する送信手段と、を備える。

本発明によれば、障害が発生する前に障害の兆候を検知して予防措置を行うことで、システムを継続して正常に稼働させることができる。

第１の実施形態に係る遠隔管理システムのシステム構成の一例を示す図である。 第１の実施形態に係る遠隔管理システムの概略の一例を示す図である。 第１の実施形態に係るコンピュータのハードウエア構成の一例を示す図である。 第１の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第１の実施形態に係る仲介装置および機器の機能構成の一例を示す図である。 第１の実施形態に係るアラートポリシーの一例を示す図である。 第１の実施形態に係る措置情報管理テーブルの一例を示す図である。 第１の実施形態に係るステータス情報の一例を示す図である。 第１の実施形態に係る機器接続定義の一例を示す図である。 第１の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 第１の実施形態に係るクラウドサーバにおけるアラート通知処理の一例を示すフローチャートである。 第１の実施形態に係るクラウドサーバが送信するアラートの内容の一例を示す図である。 第１の実施形態に係るアプリサーバにおける措置情報の決定処理の一例を示すフローチャートである。 第１の実施形態に係る予防措置要求の内容の一例を示す図である。 第１の実施形態に係る仲介装置における予防措置のフィードバックの内容の一例を示す図である。 第１の実施形態の変形例１に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第１の実施形態の変形例１に係る措置情報管理テーブルの一例を示す図である。 第１の実施形態の変形例１に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 第１の実施形態の変形例１に係るクラウドサーバにおける措置情報の決定処理の一例を示すフローチャートである。 第１の実施形態の変形例２に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第１の実施形態の変形例２に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 第１の実施形態の変形例２に係るアプリサーバにおける措置情報の決定処理の一例を示すフローチャートである。 第２の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第２の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 第３の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第３の実施形態に係る第２のアラートポリシーの一例を示す図である。 第３の実施形態に係る第２の措置情報管理テーブルの一例を示す図である。 第３の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 第４の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。 第４の実施形態に係るステータス情報の一例を示す図である。 第４の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。 その他の実施形態に係る遠隔管理システムのシステム構成の一例を示す図である。

以下、図面を参照しながら、発明を実施するための形態を説明する。なお、図面の説明において同一要素には同一符号を付し、重複する説明は省略する。

●第１の実施形態●
●システム構成
図１は、第１の実施形態に係る遠隔管理システムのシステム構成の一例を示す図である。図１に示す遠隔管理システム１は、機器管理システム１０が仲介装置５０から取得したリソース情報に基づいて、障害（異常）の兆候を検知して予防措置を行うことにより、システムを継続して正常に稼働させることができるシステムである。遠隔管理システム１は、機器管理システム１０、ローカルネットワーク１１およびファイアウォール１３を含む。ローカルネットワーク１１は、インターネットを介して機器管理システム１０と接続されている。ローカルネットワーク１１と機器管理システム１０は、ファイアウォール１３をインターフェースとして接続されている。

ローカルネットワーク１１は、オフィス、会議室、倉庫、工場または特定の生産ライン等のネットワーク環境において形成される通信ネットワークである。ローカルネットワーク１１は、例えば、インターネットを経由しない社内ＬＡＮ（Local Area Network）である。ローカルネットワーク１１は、仲介装置５０、ＭＦＰ（Multi-Function Peripheral：複合機）６１、ＰＪ（Projector：プロジェクタ）６２、ＩＷＢ（Interactive White Board：相互通信が可能な電子式の黒板機能を有する白板）６３、ＰＣ（Personal Computer：パソコン）６４、センサデバイス６５（例：外部と通信可能な、電子天秤・気圧計・加速度計・電流計・温度計・光度計・人感センサ・カメラ・照度計）を含む。ＭＦＰ６１、ＰＪ６２、ＩＷＢ６３、ＰＣ６４、センサデバイス６５は、機器管理システム１０における遠隔管理の対象となる被管理装置である。なお、以下の説明で使用する機器６０は、これらの被管理装置の総称である。

ファイアウォール１３は、機器管理システム１０（インターネット）からの特定のパケットのみをローカルネットワーク１１内に通過させる機能を有する。これにより、ファイアウォール１３は、ローカルネットワーク１１への意図しないまたは不正なアクセスをブロックすることが可能となる。また、ファイアウォール１３は、仲介装置５０からのパケットを機器管理システム１０に転送する機能を有する。

機器管理システム１０は、ローカルネットワーク１１内に位置する仲介装置５０および機器６０を管理するためのシステムである。機器管理システム１０は、クラウドサーバ２０およびアプリサーバ３０を含む。クラウドサーバ２０は、複数のサーバコンピュータを含み、ファイアウォ－ルを介して仲介装置５０と接続される。クラウドサーバ２０は、ローカルネットワーク１１内の機器６０を、仲介装置５０を介して遠隔管理する。管理の一例として、クラウドサーバ２０は、ＭＦＰ６１から、トナー残量・印刷枚数等の状態に関する情報を取得することが可能である。また、クラウドサーバ２０は、ＭＦＰ６１に蓄積されたドキュメントデータの印刷を実行させるための指示が可能である。また、クラウドサーバ２０は、ＰＪ６２、ＩＷＢ６３、およびＰＣ６４に対して、電源のＯＮまたはＯＦＦを制御することが可能である。さらに、クラウドサーバ２０は、センサデバイス６５に対して、当該センサデバイス６５によって取得された情報を取得することが可能である。クラウドサーバ２０は、第１の管理装置の一例である。

アプリサーバ３０は、クラウドサーバ２０のアクセス手段を用いて、所望のソリューションを実現するためのアプリケーションソフトウエア（以下、アプリ）を提供するサーバ装置である。ソリューションは、例えば、機器６０に係るログ収集サービス、機器６０に係るカウンタ収集サービス、機器６０のメンテナンスサービス等を含む。アプリサーバ３０は、ＰＣ４０ａ、ＰＣ４０ｂおよびＰＣ４０ｃ（以下、それぞれを区別しない場合「ＰＣ４０」という。）に対して、それぞれアプリ３５を提供する。アプリサーバ３０は、第２の管理装置の一例である。

ＰＣ４０は、機器管理システム１０に接続されるＰＣである。ＰＣ４０ａではアプリ３５ａ、ＰＣ４０ｂではアプリ３５ｂ、ＰＣ４０ｃではアプリ３５ｃ（以下、アプリ３５ａ～ｃのそれぞれを区別しない場合、アプリ３５という。）が動作している。図１に示すアカウントは、アプリ３５を使用する複数のユーザ（管理者）をグルーピングするものである。アプリ３５は、アプリごとに異なるソリューションを提供することができる。アプリ３５は、例えば、ローカルネットワーク１１の使用環境や機器６０の種別に応じて、提供するソリューションを設定することができる。アプリサーバ３０は、ＰＣ４０ごとに提供する複数のアプリ３５を管理している。

仲介装置５０は、クラウドサーバ２０と、ローカルネットワーク１１における機器６０との間の通信を仲介する装置である。また、仲介装置５０は、機器６０およびファイアウォール１３と、有線または無線ＬＡＮ等を介して通信可能である。仲介装置５０は、クラウドサーバ２０からの指示を受けて機器６０にアクセスしたり、機器６０からのアラート通知をクラウドサーバ２０に送信したり、予め設定されたスケジュールに基づき機器６０の情報取得通知や死活監視（例えば、機器６０が通信可能であるかどうか等）を行う。仲介装置５０は、単体として機能するボックス型（箱型）の通信装置であってもよく、ＭＦＰ６１等の情報機器に内蔵されていてもよい。

また、仲介装置５０は、インターネット上にあるクラウドサーバ２０と、ファイアウォール１３を経由して通信可能である。すなわち、仲介装置５０は、ファイアウォール（をインターフェースとするローカルネットワーク１１）内に位置し、機器管理システム１０を構成するクラウドサーバ２０は、ファイアウォール（をインターフェースとするローカルネットワーク１１）外に位置するといえる。

機器６０（ＭＦＰ６１、ＰＪ６２、ＩＷＢ６３、ＰＣ６４およびセンサデバイス６５）は、ローカルネットワーク１１内に位置し、かつファイアウォール（をインターフェースとするローカルネットワーク１１）内に位置する。機器６０は、機器管理システム１０によるメンテナンスやカウンタ検針等が行われる管理対象の機器である。また、機器６０は、人感センサ等のネットワーク機能を備えていない端末に、ネットワーク機能を備えた機器を取り付けてもよい。

なお、図１は、機器管理システム１０が、一つのローカルネットワーク１１内に位置する複数の機器６０を遠隔管理する例を示すが、機器管理システム１０が、複数のローカルネットワーク１１内のそれぞれに位置する機器６０を遠隔管理する構成にしてもよい。また、図１は、一台の仲介装置が一つのローカルネットワーク１１内に位置する例を示すが、一つのローカルネットワーク内に二台以上の仲介装置５０が位置する構成にしてもよい。この場合、仲介装置５０ごとに担う機能を分担してもよい。

●概略
図２は、第１の実施形態に係る遠隔管理システムの概略の一例を示す図である。図２に示す遠隔管理システム１は、機器管理システム１０によって、ローカルネットワーク１１内に位置する仲介装置５０の障害（異常）の兆候を検知して、仲介装置５０の障害を改善するための予防措置を行うことを示している。なお、図２は、第１の実施形態に係る遠隔管理システムの概略を簡略的に説明したものであり、遠隔管理システム１が実現する機能等の詳細は、後述する図面等を用いて説明する。

仲介装置５０は、予め設定されたスケジュールに基づいて、クラウドサーバ２０に対して、仲介装置５０の状態を示すステータス情報５８０を送信する。ステータス情報５８０は、例えば、仲介装置５０のコンピュータリソースや稼働状態に関するログ情報を含む。また、仲介装置５０は、例えば、仲介装置５０または機器６０の障害の発生を検知した場合、検知した障害の状態を示す情報（ＷＡＲＮ、ＥＲＲＯＲ、ＩＮＦＯ、ＤＥＢＵＧ等）を含むステータス情報５８０を送信してもよい。仲介装置５０がステータス情報５８０を送信するタイミング（スケジュール）および送信するステータス情報５８０の内容は、アプリサーバ３０によって設定される。

機器管理システム１０を構成するクラウドサーバ２０は、仲介装置５０からステータス情報５８０を受信した場合、予め設定されたアラートポリシー２５１に基づいて、アプリサーバ３０に対するアラート通知の要否を判定する。アラート通知は、クラウドサーバ２０によって仲介装置５０の状態（例えば、仲介装置５０の障害（異常）の兆候）を検知した場合に、アプリサーバ３０に対して行われる通知である。

アラートポリシー２５１は、アラート通知の要否を判定するための所定の条件を含む。アラートポリシー２５１に含まれる条件は、仲介装置５０のコンピュータリソースの使用量（稼働量）の閾値を超えていることという条件を含む。また、アラートポリシー２５１に含まれる条件は、ステータス情報５８０に、仲介装置５０のリソース状態を示す所定の文字列が含まれていることという条件を含む。なお、ステータス情報５８０およびアラートポリシー２５１の詳細な内容は、後述する。クラウドサーバ２０は、受信したステータス情報５８０が、アラートポリシー２５１に含まれる所定の条件を満たす場合、アプリサーバ３０に対して、アラート通知を送信する。

機器管理システム１０を構成するアプリサーバ３０は、クラウドサーバ２０からアラート通知を受信した場合、措置情報管理テーブル３５１に基づいて、仲介装置５０に対する措置情報を決定する。措置情報は、アラート通知の要否を判定するための所定の条件に紐づく（対応づけられた、関連づけられた）所定の処理の実行を指示する情報である。措置情報は、仲介装置５０に対して所定の処理の実行を指示する指示情報の一例である。措置情報は、例えば、仲介装置５０の障害（異常）の兆候を改善するために、仲介装置５０に実行させる所定の処理内容を指示する情報を含む。

措置情報は、例えば、仲介装置５０の障害の兆候がメモリ不足である場合は、仲介装置５０のリブート処理が設定されている。その他、措置情報は、仲介装置５０がディスクフルの状態である場合、ファイルの削除、Ｉ／Ｏエラーである場合、周辺機器のリセット、ソフトウエアにバグがある場合、ファームウエアの更新等の処理が設定されている。なお、措置情報管理テーブル３５１および措置情報の詳細な内容は、後述する。アプリサーバ３０は、決定した措置情報に基づく予防措置要求を、クラウドサーバ２０を経由して仲介装置５０に対して送信する。

仲介装置５０は、クラウドサーバ２０を介して、アプリサーバ３０によって送信された予防措置要求を受信した場合、要求された予防措置を実行する。これによって、仲介装置５０は、アプリサーバ３０からの要求に基づいて、リソース状態等に障害（異常）が発生する前に対策を講じることができる。

したがって、第１の実施形態に係る遠隔管理システムは、機器管理システム１０が定期的に仲介装置５０のログ情報を収集して、仲介装置５０の障害（異常）の兆候を事前に検知する。そして、機器管理システム１０は、検知した障害（異常）の兆候を改善するための予防措置を、仲介装置５０に対して要求する。遠隔管理システム１において、機器管理システム１０は、仲介装置５０を介して機器６０のログ情報を取得するため、仲介装置５０に障害が発生した場合、機器６０の管理を行えないおそれがある。そのため、遠隔管理システム１は、仲介装置５０に障害（異常）が発生する前に予防措置を実行することができるので、システムを継続して正常に稼働させることができる。

●ハードウエア構成
続いて、第１の実施形態に係る各装置のハードウエア構成について説明する。遠隔管理システム１を構成する各装置は、一般的なコンピュータの構成を有する。ここでは、一般的なコンピュータのハードウエア構成例について説明する。

図３は、第１の実施形態に係るコンピュータのハードウエア構成の一例を示す図である。なお、図３に示すコンピュータ１０００のハードウエア構成は、各実施形態において同様の構成を有していてもよく、必要に応じて構成要素が追加または削除されてもよい。コンピュータ１０００は、ＣＰＵ（Central Processing Unit）１００１、ＲＯＭ（Read Only Memory）１００２、ＲＡＭ（Random Access Memory）１００３、ストレージ１００４、入力部１００５、表示部１００６、入出力インターフェース（Ｉ／Ｆ）１００７、通信部１００８およびバス１００９等を有する。

ＣＰＵ１００１は、ＲＯＭ１００２やストレージ１００４等に格納されたプログラムやデータをＲＡＭ１００３上に読み出し、処理を実行することで、コンピュータ１０００の各機能を実現する演算装置である。クラウドサーバ２０およびアプリサーバ３０（機器管理システム１０）は、例えば、本発明に係るプログラムをＣＰＵ１００１が実行することによって、本発明に係る機器管理方法を実現する。

ＲＯＭ１００２は、電源を切ってもプログラムやデータを保持することができる不揮発性のメモリである。ＲＯＭ１００２は、例えば、フラッシュＲＯＭ等により構成される。ＲＯＭ１００２は、多種の用途に対応したＳＤＫ（Software Development Kit）がインストールされており、ＳＤＫのアプリケーションを用いて、コンピュータ１０００の機能やネットワーク接続等を実現することが可能である。

ＲＡＭ１００３は、ＣＰＵ１００１のワークエリア等として用いられる揮発性のメモリである。ストレージ１００４は、例えば、ＨＤＤ（Hard Disk Drive）、ＳＳＤ（Solid State Drive）等のストレージデバイスである。ストレージ１００４は、例えば、ＯＳ（Operation System）、アプリケーションプログラムおよび各種データ等を記憶する。

入力部１００５は、コンピュータ１０００の操作を行うための入力を受け付ける。入力部１００５は、例えば、キーボード、マウス、タッチパネル等の入力装置である。表示部１００６は、コンピュータ１０００の処理結果等を表示する。表示部１００６は、例えば、ＬＣＤ（Liquid Crystal Display）等の表示装置である。なお、入力部１００５または表示部１００６は、コンピュータ１０００の外部に設けられていても良い。また、入力部１００５および表示部１００６は、例えば、タッチパネルディスプレイ等の一体型の表示入力部等であってもよい。

入出力インターフェース（Ｉ／Ｆ）１００７は、コンピュータ１０００に周辺装置を接続するためのインターフェースである。周辺装置は、例えば、ＵＳＢ（Universal Serial Bus）メモリ、メモリカード、光学ディスク等の記録媒体１００７ａや、各種の電子機器等が含まれる。

通信部１００８は、コンピュータ１０００をネットワークに接続し、他のコンピュータや、電子機器等とデータの送受信を行う。通信部１００８は、例えば、有線または無線ＬＡＮ等の通信インターフェースである。また、通信部１００８は、３Ｇ（3rd Generation）、ＬＴＥ(Long Term Evolution)、４Ｇ（4rd Generation）、５Ｇ（5rd Generation）、Ｚｉｇｂｅｅ（登録商標）、ＥｎＯｃｅａｎ、ＢＬＥ（Bluetooth（登録商標）Low Energy）、ＮＦＣ（Near Field Communication）、ミリ波無線通信、赤外線通信、ＱＲコード（登録商標）、可視光、環境音または超音波等の通信インターフェースを備えてもよい。

バス１００９は、上記の各構成要素に共通に接続され、アドレス信号、データ信号、および各種制御信号等を伝送する。ＣＰＵ１００１、ＲＯＭ１００２、ＲＡＭ１００３、ストレージ１００４、入力部１００５、表示部１００６、入出力インターフェース（Ｉ／Ｆ）１００７および通信部１００８は、バス１００９を介して相互に接続されている。

なお、第１の実施形態に係る各装置のハードウエア構成は、必要に応じて構成要素が追加または削除されてもよい。また、図３に示す各装置のハードウエア構成は、各実施形態において同様の構成を有していてもよい。

●機能構成
続いて、第１の実施形態に係る遠隔管理システムの機能構成について説明する。図４は、第１の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。図４に示すクラウドサーバ２０により実現される機能は、仲介装置通信部２０１、アプリ通信部２０２、通信経路管理部２０３、アラートポリシー管理部２０４、グループ設定部２０５、記憶・読出部２０６および記憶部２０７を含む。

仲介装置通信部２０１は、仲介装置５０との間でデータをやり取りする機能である。仲介装置通信部２０１は、ローカルネットワーク１１の内部に位置する仲介装置５０との間のファイアウォ－ルを経由した通信を制御する。仲介装置通信部２０１は、例えば、仲介装置５０の状態を示すステータス情報５８０を、仲介装置５０から受信する。

また、仲介装置通信部２０１は、例えば、アプリサーバ３０から送信されたコマンド（予防措置要求）を仲介装置５０に対して転送する。具体的には、仲介装置通信部２０１は、アプリサーバ３０から送信された仲介装置５０または機器６０に対する予防措置要求を、仲介装置５０に対して送信する。予防措置要求は、後述するステータス情報解析部３０２によって決定される措置情報を含む。措置情報は、後述するアラートポリシー管理部２０４によってアラート通知の要否を判定するための所定の条件に対応づけられた所定の処理の実行を指示する情報である。措置情報は、仲介装置５０に対して所定の処理の実行を指示する指示情報の一例である。

さらに、仲介装置通信部２０１は、例えば、アプリサーバ３０から送信されたコマンド（予防措置要求）の実行結果を、仲介装置５０から受信する。仲介装置通信部２０１は、例えば、図３に示した通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。仲介装置通信部２０１は、受信手段および送信手段の一例である。

ここで、通常、ローカルネットワーク１１とインターネット環境との間にはファイアウォール１３が設置されているため、アプリサーバ３０（または、アプリサーバ３０から提供されるアプリ３５を実行するＰＣ４０）から仲介装置５０に対して直接接続することはできない。そこで、アプリサーバ３０と仲介装置５０の間の通信は、クラウドサーバ２０を経由して行われる。

具体的には、仲介装置５０は、仲介装置５０からクラウドサーバ２０へポーリングを行い、当該ポーリングに対する応答としてクラウドサーバ２０を介して、アプリサーバ３０からの命令を取得する。または、仲介装置５０からクラウドサーバに対して常時通信可能なように通信セッション（ＷｅｂＳｏｃｋｅｔ等）を維持しておき、アプリサーバ３０（または、アプリ３５）は、クラウドサーバ２０を介して、仲介装置５０に対してデータを送信する。本実施形態では、どちらの方法をとってもよい。

アプリ通信部２０２は、アプリサーバ３０との間でデータをやり取りする機能である。アプリ通信部２０２は、ＨＴＴＰＳ（HyperText Transfer Protocol Secure）のプロトコルを用いて、アプリサーバ３０と通信を行う。なお、通信方式は、これに限られず、ＦＴＰ（File Transfer Protocol）、ＨＴＴＰ（HyperText Transfer Protocol）またはＳＭＴＰ（Simple Mail Transfer Protocol）等のプロトコルを用いてもよい。

アプリ通信部２０２は、例えば、アプリサーバ３０に対して、アラート通知を送信する。また、アプリ通信部２０２は、例えば、アプリサーバ３０から送信されたコマンド（予防措置要求）を受信する。具体的には、アプリ通信部２０２は、仲介装置５０に対する予防措置要求を、アプリサーバ３０から受信する。アプリ通信部２０２は、例えば、図３に示した通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。

通信経路管理部２０３は、アプリサーバ３０が提供するアプリ３５と仲介装置５０または機器６０との間の通信経路を管理する機能である。通信経路管理部２０３は、例えば、アプリサーバ３０が提供するアプリ３５と仲介装置５０または機器６０との間の通信経路を、通信経路管理ＤＢ２５２を用いて管理する。そして、通信経路管理部２０３は、アプリ３５（またはアプリサーバ３０）から命令が発行された場合、いずれの仲介装置５０にルーティングすべきかを通信経路管理ＤＢ２５２により管理された情報を用いて判断する。

また、通信経路管理部２０３は、仲介装置５０から通知された情報を、いずれのアプリ３５に転送すべきかを通信経路管理ＤＢ２５２により管理された情報を用いて判断する。通信経路管理部２０３は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。

アラートポリシー管理部２０４は、仲介装置５０の状態を検知するためのアラートポリシー２５１を管理する機能である。アラートポリシー管理部２０４は、記憶部２０７に記憶されたアラートポリシー２５１に基づいて、アプリサーバ３０に対するアラート通知の要否を判定する。アラートポリシー２５１は、例えば、仲介装置５０の障害（異常）の兆候を検知するためのものである。アラートポリシー２５１の詳細は、後述する。アラートポリシー管理部２０４は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。アラートポリシー管理部２０４は、通知手段の一例である。

グループ設定部２０５は、アプリサーバ３０が提供する複数のアプリ３５に対して、アラート通知を一括で送信するためのグルーピング設定を行う機能である。グループ設定部２０５は、アラート通知が必要なアプリ３５をグループピングする。一方で、グループ設定部２０５は、アラート通知が不要なアプリ３５をグループから外すことで、クラウドサーバ２０からアラート通知を送信しないようにする。グループ設定部２０５は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。

記憶・読出部２０６は、記憶部２０７に各種データを記憶し、記憶部２０７から各種データを読み出す機能である。記憶・読出部２０６および記憶部２０７は、例えば、図３に示したＲＯＭ１００２、ストレージ１００４およびＣＰＵ１００１で実行されるプログラム等により実現される。記憶部２０７は、記憶手段の一例である。記憶部２０７は、通信経路管理部２０３により管理される通信経路管理ＤＢ２５２を構築している。また、記憶部２０７は、アラートポリシー２５１を記憶している。

ここで、記憶部２０７に記憶されるアラートポリシー２５１について説明する。図６は、第１の実施形態に係るアラートポリシーの一例を示す図である。図６に示すアラートポリシー２５１は、仲介装置５０の障害（異常）の兆候を検知するためのものである。アラートポリシー２５１は、コンピュータのリソースに関する「項目」、アラート通知の要否を判定するための「条件」および条件を識別するための「条件ＩＤ」に対応する情報を含む。アラートポリシー２５１は、「項目」ごとに「条件」が設定され、「条件」ごとに「条件ＩＤ」が紐づけられている。アラートポリシー２５１は、ＣＰＵ、メモリ、ストレージ等の「項目」に対して、それぞれの稼働状態や使用量（使用率）を「条件」として設定して、仲介装置５０の障害（異常）の兆候を検知させる。

「項目」は、汎用的なコンピュータリソースを示す情報が示されている。図６に示す「項目」は、例えば、ＣＰＵ、メモリ、ストレージ、電源等を含む。その他、「項目」は、スレッド数、ファイルディスクリプタ、Ｓｏｃｋｅｔ通信の接続クライアントの数等を含んでもよい。

「条件」は、アラート通知の要否を判定するための条件であり、例えば、仲介装置５０の障害（異常）の兆候を検知するための条件である。「条件」は、仲介装置５０のコンピュータリソースの使用量（稼働量）の閾値を超えていることという条件を含む。図6に示す「条件」は、例えば、「項目」ＣＰＵに対して、使用率が８０％を超えていることという条件を含む。また、「条件」は、ステータス情報５８０に、仲介装置５０のリソース状態を示す所定の文字列が含まれていることという条件を含む。図６に示す「条件」は、例えば、「項目」メモリに対して、“Ｏｕｔ oｆ Ｍｅｍｏｒｙ”が含まれていることという条件を含む。

アラートポリシー管理部２０４は、仲介装置５０から受信したステータス情報５８０の中から、アラートポリシー２５１に含まれる「項目」に該当する情報（例えば、キーワードや文字列等）を抽出し、抽出した内容が「条件」を満たす場合、アラート通知をアプリサーバ３０に対して送信するように判定する。なお、図６に示すアラートポリシー２５１に含まれる「項目」および「条件」の内容は、一例であり、機器管理システム１０の管理者等によって適宜設定・変更可能である。

続いて、アプリサーバ３０の機能構成について説明する。図４に示すアプリサーバ３０により実現される機能は、送受信部３０１、ステータス情報解析部３０２、監視レベル設定部３０３、受付部３０４、レポート集計・出力部３０５、記憶・読出部３０６および記憶部３０７を含む。

送受信部３０１は、クラウドサーバ２０との間でデータをやり取りする機能である。送受信部３０１は、ＨＴＴＰＳのプロトコルを用いて、クラウドサーバ２０と通信を行う。なお、通信方式は、これに限られず、ＦＴＰ、ＨＴＴＰまたはＳＭＴＰ等のプロトコルを用いてもよい。送受信部３０１は、例えば、クラウドサーバ２０から送信されたアラート通知を受信する。また、送受信部３０１は、クラウドサーバ２０に対して、仲介装置５０に対する予防措置要求を送信する。予防措置要求は、後述するステータス情報解析部３０２によって決定された措置情報を含む。送受信部３０１は、例えば、図３に示した通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。

ステータス情報解析部３０２は、仲介装置５０のステータス情報５８０に基づいて、仲介装置５０に対する予防措置の内容を決定する機能である。ステータス情報解析部３０２は、例えば、クラウドサーバ２０からアラート通知を受信した場合、記憶部３０７に記憶された措置情報管理テーブル３５１を用いて、仲介装置５０に対する措置情報を決定する。

措置情報は、アラート通知の要否を判定するための所定の条件に紐づく（対応づけられた、関連づけられた）所定の処理の実行を指示する情報である。措置情報は、例えば、仲介装置５０の障害（異常）の兆候を改善するために、仲介装置５０に実行させる所定の処理内容を指示する情報を含む。措置情報は、仲介装置５０に対して所定の処理の実行を指示する指示情報の一例である。措置情報に含まれる処理内容は、例えば、リブート処理やファイル削除処理等が含まれる。ステータス情報解析部３０２は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。ステータス情報解析部３０２は、決定手段および特定手段の一例である。

ここで、措置情報管理テーブル３５１について説明する。図７は、第１の実施形態に係る措置情報管理テーブルの一例を示す図である。図７に示す措置情報管理テーブル３５１は、仲介装置５０に対する障害（異常）の兆候を改善するための措置情報を管理するものである。措置情報管理テーブル３５１は、「条件ＩＤ」に、障害（異常）の兆候の改善を仲介装置５０に対して指示する「措置情報」を紐づけて管理している。

「条件ＩＤ」は、図６に示したアラートポリシー２５１に含まれる「条件ＩＤ」に対応している。「措置情報」は、仲介装置５０の障害（異常）の兆候を改善するために、仲介装置５０に実行させる処理内容を指示する指示情報である。「措置情報」は、例えば、仲介装置５０の障害の兆候がメモリ不足である場合は仲介装置５０のリブート処理、仲介装置５０がディスクフルの状態である場合はファイルの削除、Ｉ／Ｏエラーである場合は周辺機器のリセット、ソフトウエアにバグがある場合はファームウエアの更新等の処理内容が設定されている。

ステータス情報解析部３０２は、クラウドサーバ２０から受信したアラート通知に含まれる「条件ＩＤ」と同一の「条件ＩＤ」に対応づけられた「措置情報」を、仲介装置５０に対して指示する処理内容として決定する。図７に示す措置情報管理テーブル３５１は、アラート通知に含まれる「条件ＩＤ」が“Ａ０００３”の場合、“リブート処理”を「措置情報」として決定する。なお、措置情報管理テーブル３５１は、アプリサーバ３０が提供するアプリ３５ごとに設けられていてもよい。措置情報管理テーブル３５１に含まれる「措置情報」の内容は、アプリサーバ３０が提供するアプリ３５のユーザによって適宜設定・変更されてもよい。

監視レベル設定部３０３は、仲介装置５０または機器６０に対する監視レベルを設定する機能である。監視レベル設定部３０３は、例えば、仲介装置５０のステータス情報５８０や機器６０の機器情報を取得するタイミング（例えば、スケジュールやインターバル間隔等）を、監視下にある仲介装置５０ごとに設定する。

また、監視レベル設定部３０３は、仲介装置５０から取得するログ情報（ステータス情報５８０または機器情報）の内容を設定する。監視レベル設定部３０３は、例えば、図６に示したアラートポリシー２５１に含まれる特定の「項目」（リソース項目）に対応する情報をステータス情報５８０として、仲介装置５０に送信させるように設定する。監視レベル設定部３０３は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。ステータス情報解析部３０２は、監視レベル設定部３０３によって設定された監視レベルに基づいて、仲介装置５０からログ情報（ステータス情報５８０または機器情報）を取得し、障害（異常）の兆候の検知および予防措置を行う。監視レベル設定部３０３は、設定手段の一例である。

なお、監視レベル設定部３０３は、アプリサーバ３０が提供するアプリ３５ごとに、管理下にある仲介装置５０または機器６０に対する監視レベルを設定してもよい。また、監視レベル設定部３０３は、仲介装置５０や機器６０において障害（異常）が発生した場合に、動作ログ（ＥＲＲＯＲ、ＷＡＲＮ、ＩＮＦＯ、ＤＥＢＵＧ等）を、仲介装置５０や機器６０から送信させるように設定してもよい。

受付部３０４は、管理下にある仲介装置５０や機器６０に対する命令を受け付ける機能である。受付部３０４は、例えば、アプリサーバ３０が提供するアプリ３５を実行するＰＣ４０に対して、管理対象の仲介装置５０や機器６０の状態や情報を表示させる。また、受付部３０４は、例えば、アプリサーバ３０が提供するアプリ３５を実行するＰＣ４０に対して、管理対象の仲介装置５０や機器６０に対する情報取得や制御等の命令を受け付けるユーザＩ／Ｆを備えた画面を表示させる。受付部３０４は、例えば、図３に示した表示部１００６およびＣＰＵ１００１で実行されるプログラム等により実現される。

レポート集計・出力部３０５は、ユーザ所望のフォーマットにデータを集計し出力する機能である。レポート集計・出力部３０５は、例えば、管理対象の機器６０のカウンタ情報を集計し、ＣＳＶ（Comma Separated Value）形式にまとめて月次でレポートを生成して出力する。レポート集計・出力部３０５は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。

記憶・読出部３０６は、記憶部３０７に各種データを記憶し、記憶部３０７から各種データを読み出す機能である。記憶・読出部３０６および記憶部３０７は、例えば、図３に示すＲＯＭ１００２、ストレージ１００４およびＣＰＵ１００１で実行されるプログラム等により実現される。記憶部３０７は、記憶手段の一例である。記憶部３０７は、図７に示した措置情報管理テーブル３５１を記憶している。さらに、記憶部３０７は、ステータス情報管理ＤＢ３５２を構築している。ステータス情報管理ＤＢ３５２は、仲介装置５０から送信された、仲介装置５０のリソース状態を示すステータス情報５８０を管理する。

ここで、ステータス情報管理ＤＢ３５２に管理されるステータス情報５８０について説明する。図８は、第１の実施形態に係るステータス情報の一例を示す図である。図８（ａ）は、仲介装置５０から送信されるステータス情報５８０の内容の概略を示す。ステータス情報５８０は、「タイムスタンプ」、「メッセージ」、「スレッドＩＤ」および「ソースコード」等の情報を含む。

「タイムスタンプ」は、仲介装置５０がステータス情報５８０を送信した時間を示す情報を含む。「メッセージ」は、仲介装置５０のリソースに関する情報を含む。図８（ｂ）に、「メッセージ」に含まれる内容を示す。「メッセージ」は、例えば、仲介装置５０のＣＰＵの使用率、メモリの使用量、ストレージの使用量、電源（バッテリー）の残量、スレッドＩＤの数、ファイルディスクリプタの数、Ｓｏｃｋｅｔ通信の接続クライアントの数等を含む。なお、メッセージに含まれる項目は、これに限られない。「スレッドＩＤ」は、仲介装置が実行する１つのプロセスの中で、複数のスレッドが実行される場合に、所定のスレッドを識別するためのものである。「メッセージ」は、確認すべき文字列やコードが含まれる「ソースコード」の行数の情報等が含まれてもよい。

図５は、第１の実施形態に係る仲介装置および機器の機能構成の一例を示す図である。図５に示す仲介装置５０により実現される機能は、クラウド通信部５０１、機器通信部５０２、スケジューラ機能部５０３、異常検知ポリシー管理部５０４、装置状態監視部５０５、表示制御部５０６、記憶・読出部５０７および記憶部５０８を含む。

クラウド通信部５０１は、クラウドサーバ２０との間でデータをやり取りする機能である。クラウド通信部５０１は、例えば、仲介装置５０または機器６０のログ情報（例えば、図８に示した仲介装置５０のステータス情報５８０、機器６０の機器情報等）を、クラウドサーバ２０に対して送信する。また、クラウド通信部５０１は、例えば、アプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）が発行したコマンド（予防措置要求）を、クラウドサーバ２０から受信する。さらに、クラウド通信部５０１は、アプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）が発行したコマンド（予防措置要求）に対する処理の実行結果を、クラウドサーバ２０に対して送信する。クラウド通信部５０１は、例えば、図３に示す通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。

機器通信部５０２は、機器６０との間でデータをやり取りする機能である。機器通信部５０２は、ＨＴＴＰまたはＳＮＭＰ（Simple Network Management Protocol）のプロトコルを用いて、機器６０と通信を行う。なお、通信方式は、これに限られず、ＨＴＴＰＳまたはＬＰＤ(Line Printer Daemon)等のプロトコルを用いてもよい。機器通信部５０２は、例えば、機器６０からの機器アラートであるテキストメッセージまたはバイナリデータを受信する。また、機器通信部５０２は、アプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）が発行したコマンドの内容を解釈して機器６０にリクエストを送信する。機器通信部５０２は、例えば、図３に示す通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。

スケジューラ機能部５０３は、仲介装置５０の内部タイマおよび予め設定されたスケジュール（タスクスケジュール５５２）に基づいて、管理対象の機器６０から情報を取得し、取得した情報をクラウドサーバ２０に対して通知する機能である。また、スケジューラ機能部５０３は、機器６０がネットワーク通信可能であるか確認する（死活監視）等の定期動作を行う。スケジューラ機能部５０３は、例えば、図３に示すＣＰＵ１００１で実行されるプログラム等により実現される。

異常検知ポリシー管理部５０４は、機器６０の障害（異常）の兆候を検知するための異常検知ポリシー５５１を管理する機能である。異常検知ポリシー管理部５０４は、記憶部５０８に記憶された異常検知ポリシー５５１に基づいて、機器６０の障害（異常）の兆候を検知する。異常検知ポリシー管理部５０４は、例えば、図３に示すＣＰＵ１００１で実行されるプログラム等により実現される。

装置状態監視部５０５は、仲介装置５０のリソース状態を監視する機能である。装置状態監視部５０５は、メモリ不足、ストレージ不足、書き込みエラー等の障害（異常）の兆候を検知する。装置状態監視部５０５は、記憶部５０８に記憶されたタスクスケジュール５５２に基づいて、リソース状態の監視結果を含むステータス情報５８０を生成する。装置状態監視部５０５は、例えば、図３に示したＣＰＵ１００１により実行されるプログラム等によって実現される。

表示制御部５０６は、クラウドサーバ２０や機器６０と通信を行うためのネットワーク設定や、クラウドサーバ２０と通信を開始するためのアクティベーション手続きまたは接続確認等を行うための表示を行う機能である。表示制御部５０６は、例えば、図３に示した表示部１００６およびＣＰＵ１００１で実行されるプログラム等により実現される。

記憶・読出部５０７は、記憶部５０８に各種データを記憶し、記憶部５０８から各種データを読み出す機能である。記憶・読出部５０７および記憶部５０８は、例えば、図３に示すＲＯＭ１００２、ストレージ１００４およびＣＰＵ１００１で実行されるプログラム等により実現される。記憶部５０８は、異常検知ポリシー５５１およびタスクスケジュール５５２を記憶している。

異常検知ポリシー５５１は、例えば、機器６０の障害（異常）の兆候を検知するための条件を示すポリシーである。異常検知ポリシー５５１の内容は、図６に示したアラートポリシー２５１の内容と同様の内容でもよく、機器６０の種別に応じて、機器６０特有の情報を追加してもよい。タスクスケジュール５５２は、機器６０に対してログ取得要求を送信するスケジュールや、クラウドサーバ２０に対してログ（ステータス情報５８０または機器情報）を送信するスケジュールを保持している。タスクスケジュール５５２は、仲介装置５０を管理するアプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）によって設定される。

また、記憶部５０８は、機器情報管理ＤＢ５５３および機器接続定義管理ＤＢ５５４を構築している。機器情報管理ＤＢ５５３は、機器６０から受信した機器情報を管理する。機器情報は、機器６０のリソース状態を示す情報や稼働状態に関する情報等を含む。機器接続定義管理ＤＢ５５４は、機器６０の追加・削除・検索、機器情報取得・疎通確認を実行するための通信パラメータを管理する。ＨＴＴＰの通信パラメータは、例えば、リソースＵＲＩ（Uniform Resource Identifier）、メソッド、ヘッダ、クエリ、ボディを含む。また、ＳＮＭＰの通信パラメータは、例えば、コマンド種別（Ｇｅｔ／ＧｅｔＢｕｌｋ）、バージョン、コミュニティ名、ＯＩＤ（オブジェクト識別子）を含む。

ここで、図９を用いて、機器接続定義について説明する。図９は、第１の実施形態に係る機器接続定義の一例を示す図である。図９は、機器接続定義の通信プロトコルは変更せずに通信パラメータを変えて値を取得する場合の例を示す。図９に示す追加前の機器接続定義において、機器６０との通信に使用できる通信プロトコルは、ＨＴＴＰ（ボディ部はＪＳＯＮ（Java（登録商標）Script Object Notation））とＳＮＭＰの２つであることを示している。また、ＨＴＴＰ通信する際には、メソッド、リソースＵＲＩ、ヘッダ、ボディというパラメータを指定する必要がある。

図９に示す追加前の機器接続定義は、プロジェクタからの状態取得（ＧＥＴ ／ｓｔａｔｅ）の例である。パラメータ「デバイス」に対応するデバイス通信定義情報は、「プロジェクタ」である。同様に、「アクション」は「状態取得」、「メソッド」は「ＧＥＴ」、「リソースＵＲＩ」は「／ｓｔａｔｅ」、「ヘッダ」は「無し」、「ボディ」は「無し」が対応する。なお、通信プロトコル管理部は、機器接続定義管理ＤＢ５５４に含まれる機能であり、通信ライブラリは、使用可能な複数の通信プロトコルの群をいう。

図９に示す追加後の機器接続定義は、通信ライブラリ中のＨＴＴＰ＋ＪＳＯＮに、通信パラメータを追加している。追加された通信パラメータにおいて、パラメータ「アクション」に対応するデバイス通信定義情報は、「機器情報取得」である。また、パラメータ「リソースＵＲＩ」に対応するデバイス通信定義情報は、「／ｐｒｏｐｅｒｔｙ」である。通信パラメータの追加によって、仲介装置５０は、デバイス「プロジェクタ」に対して、「機密情報取得」を「／ｐｒｏｐｅｒｔｙ」に対して行うことができる。図９に示すパラメータの追加は、アプリサーバ３０の命令によるものであってもよい。上述のようにパラメータを追加または変更することで、仲介装置５０のファームウエアを更新せずに、機器接続定義を容易に拡張することができる。

続いて、機器６０の機能構成について説明する。図５に示す機器６０により実現される機能は、送受信部６０１および機器情報生成部６０２を含む。なお、図５は、ローカルネットワーク１１内に一台の機器６０が位置する場合を説明するが、機器６０は、ローカルネットワーク１１内に複数設けられていてもよい。

送受信部６０１は、仲介装置５０との間でデータをやり取りする機能である。送受信部６０１は、ＨＴＴＰまたはＳＮＭＰのプロトコルを用いて、仲介装置５０と通信を行う。なお、通信方式は、これに限られず、ＨＴＴＰＳまたはＬＰＤ等のプロトコルを用いてもよい。

送受信部６０１は、例えば、機器アラートであるテキストメッセージまたはバイナリデータ等の機器情報を、仲介装置５０に対して送信する。また、送受信部６０１は、例えば、アプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）が発行したコマンド（予防措置要求）を、仲介装置５０から受信する。さらに、送受信部６０１は、例えば、アプリサーバ３０（またはアプリサーバ３０が提供するアプリ３５）が発行したコマンド（予防措置要求）に対する処理の実行結果を、仲介装置５０に対して送信する。送受信部６０１は、例えば、図３に示す通信部１００８およびＣＰＵ１００１で実行されるプログラム等により実現される。

機器情報生成部６０２は、機器６０の機器情報を生成する機能である。機器情報は、機器６０のリソース状態を示す情報や稼働状態に関する情報を含むログ情報である。機器情報生成部６０２は、仲介装置５０からの要求に応じて、仲介装置５０へ送信するための機器情報を生成する。機器情報生成部６０２は、例えば、図３に示すＣＰＵ１００１で実行されるプログラム等により実現される。

●機器管理方法
続いて、遠隔管理システム１における機器管理方法について説明する。図１０は、第１の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。図１０は、機器管理システム１０が仲介装置５０の障害（異常）の予兆を検知する処理について説明する。なお、仲介装置５０は、アプリサーバ３０によって設定された、ログ情報（ステータス情報５８０）を送信するタイミングを示すタスクスケジュール５５２を、予め記憶部５０８に記憶しているものとする。

ステップＳ１０１において、仲介装置５０は、仲介装置５０のリソース状態を示すステータス情報５８０を生成する。ステップＳ１０２において、仲介装置５０は、生成したステータス情報５８０をクラウドサーバ２０に対して送信する。具体的には、仲介装置５０は、記憶部５０８に記憶されたタスクスケジュール５５２に基づいて、ステップＳ１０１におけるステータス情報５８０の生成処理とステップＳ１０２におけるステータス情報５８０の送信処理を繰り返す。ステータス情報５８０は、図８に示したように、ＣＰＵ、メモリ、ストレージ、ファイルディスクリプタ、ネットワークＩ／Ｆの状態等の仲介装置５０のリソース状態を示す情報が含まれる。

ここで、仲介装置５０が送信するステータス情報５８０の内容は、アプリサーバ３０の監視レベル設定部３０３によって設定・変更可能である。ステータス情報５８０のサイズが大きい場合、送信完了までに時間を要し、クラウドサーバ２０は、短い間隔での仲介装置５０の状態を把握できない。また、クラウドサーバ２０は、ステータス情報５８０のサイズが大きい場合、例えば、モバイル回線等では、通信サイズの制限を超えてしまう可能性がある。そのため、ステータス情報５８０に含める内容は、必要なログに絞る方が好ましい。

ステップＳ１０３において、クラウドサーバ２０は、仲介装置５０からステータス情報５８０を受信した場合、アラートポリシー２５１に基づいて、アプリサーバ３０に対するアラート通知の要否を判定する。ここで、クラウドサーバ２０におけるアラート通知の要否判定について説明する。図１１は、第１の実施形態に係るクラウドサーバにおけるアラート通知処理の一例を示すフローチャートである。図１１は、図６に示したアラートポリシー２５１が、予め記憶部２０７に記憶されている例を説明する。また、仲介装置５０から送信されるステータス情報５８０は、図８で示したものと同様の内容とする。

ステップＳ２０１において、クラウドサーバ２０の仲介装置通信部２０１は、仲介装置５０からステータス情報５８０を受信した場合、処理をステップＳ２０１へ移行させる（受信ステップの一例）。一方で、クラウドサーバ２０の仲介装置通信部２０１は、仲介装置５０からステータス情報５８０を受信していない場合、ステップＳ２０１の処理を繰り返す。

ステップＳ２０２において、クラウドサーバ２０のアラートポリシー管理部２０４は、記憶部２０７に記憶されたアラートポリシー２５１の読み出しを行う。具体的には、アラートポリシー管理部２０４は、記憶・読出部２０６に対して、アラートポリシー２５１の読出要求を出力する。記憶・読出部２０６は、出力された読出要求を検知すると、記憶部２０７に記憶されたアラートポリシー２５１を読み出す。そして、記憶・読出部２０６は、読み出したアラートポリシー２５１を、アラートポリシー管理部２０４に対して出力する。

ステップＳ２０３において、クラウドサーバ２０のアラートポリシー管理部２０４は、受信したステータス情報５８０に含まれる情報に、アラートポリシー２５１の条件を満たすものがある場合、処理をステップＳ２０４へ移行させる。アラートポリシー管理部２０４は、例えば、仲介装置５０から送信されたステータス情報５８０の中から、アラートポリシー２５１に含まれる「項目」に該当する情報（例えば、キーワードや文字列等）を抽出する。そして、アラートポリシー管理部２０４は、抽出した内容がアラートポリシー２５１に含まれる「条件」を満たす場合、アラート通知をアプリサーバ３０に対して送信するように判定する。

ステップＳ２０４において、クラウドサーバ２０のアプリ通信部２０２は、アプリサーバ３０に対して、アラート通知を送信する。アラート通知は、例えば、ＨＴＴＰＳのプロトコルを用いて送信されることを想定するが、通信プロトコルはこれに限られない。

ここで、クラウドサーバ２０から送信されるアラート通知の内容について説明する。図１２は、第１の実施形態に係るクラウドサーバが送信するアラートの内容の一例を示す図である。図１２に示すアラート通知１１０は、「アラート対象となる仲介装置」、「条件ＩＤ」、「項目名」、「Ｖａｌｕｅ」等の情報が含まれる。「条件ＩＤ」は、アラートポリシー２５１に含まれる、条件を満たすと判定された「条件」に紐づく「条件ＩＤ」が記述される。「項目名」および「Ｖａｌｕｅ」は、アラートポリシー管理部２０４によって条件を満たすと判定された項目と、ステータス情報５８０に含まれる当該項目に対応する値が記述される。

クラウドサーバ２０は、例えば、図８に示すステータス情報５８０の場合、図６に示したアラートポリシー２５１に含まれる「条件」のうち、メモリの容量が条件を満たしているため、項目に「メモリ」、Ｖａｌｕｅに「９５０ＭＢ」の情報が含まれるアラート通知１１０を送信する。なお、図１２に示すアラート通知の内容は、一例であり、複数の「項目」を含んでもよい。

一方で、ステップＳ２０３において、クラウドサーバ２０のアラートポリシー管理部２０４は、受信したステータス情報５８０に含まれる情報に、アラートポリシー２５１の条件を満たすものがない場合、処理を終了する。この場合、仲介装置５０から送信されたログ（ステータス情報５８０）には、仲介装置５０の障害（異常）の兆候を示す情報を含まれていないため、クラウドサーバ２０は、仲介装置５０が正常に動作しているものとして、アプリサーバ３０に対するアラート通知を行わない。

図１０に戻り、第１の実施形態に係る遠隔管理システムにおける機器管理方法の説明を続ける。ステップＳ１０４において、クラウドサーバ２０は、図１１に示したように、アプリサーバ３０に対して、アラート通知を送信する。ステップＳ１０５において、アプリサーバ３０は、クラウドサーバ２０からアラート通知を受信した場合、仲介装置５０に対する措置情報を決定する。

ここで、アプリサーバ３０における措置情報の決定処理について説明する。図１３は、第１の実施形態に係るアプリサーバにおける措置情報の決定処理の一例を示すフローチャートである。図１３は、図７に示した措置情報管理テーブル３５１が、予め記憶部３０７に記憶されている例を説明する。

ステップＳ３０１において、アプリサーバ３０の送受信部３０１は、クラウドサーバ２０からアラート通知１１０を受信した場合、処理をステップＳ３０２へ移行させる。一方で、アプリサーバ３０の送受信部３０１は、クラウドサーバ２０からアラート通知１１０を受信していない場合、ステップＳ３０１の処理を繰り返す。

ステップＳ３０２において、アプリサーバ３０のステータス情報解析部３０２は、記憶部３０７に記憶された措置情報管理テーブル３５１の読み出しを行う。具体的には、ステータス情報解析部３０２は、記憶・読出部３０６に対して、措置情報管理テーブル３５１の読出要求を出力する。記憶・読出部３０６は、出力された読出要求を検知すると、記憶部３０７に記憶された措置情報管理テーブル３５１を読み出す。そして、記憶・読出部３０６は、読み出した措置情報管理テーブル３５１を、ステータス情報解析部３０２に対して出力する。

ステップＳ３０３において、アプリサーバ３０のステータス情報解析部３０２は、受信したアラート通知１１０に含まれる情報に対応する措置情報を決定する（決定ステップの一例）。具体的には、ステータス情報解析部３０２は、措置情報管理テーブル３５１の中で、アラート通知１１０に含まれる条件ＩＤと同一の条件ＩＤに関連づけられた措置情報を決定する。ステータス情報解析部３０２は、例えば、図１２に示したアラート通知に含まれる条件ＩＤが「Ａ０００３」であるため、図７に示した措置情報管理テーブル３５１の中で、条件ＩＤが「Ａ０００３」に紐づく「リブート処理」を措置情報として決定する。

ステップＳ３０４において、アプリサーバ３０の送受信部３０１は、クラウドサーバ２０に対して、決定した措置情報に基づく予防措置要求を送信する。図１４は、第１の実施形態に係る予防措置要求の内容の一例を示す図である。図１４に示す予防措置要求１２０は、ステータス情報５８０の内容に基づいて障害（異常）の兆候があると判定された仲介装置５０に対して、障害（異常）の改善を指示するための要求である。予防措置要求１２０は、メッセージとして、「コマンドＩＤ」、「要求先の仲介装置」、ステータス情報解析部３０２によって決定された「措置情報」等の情報を含む。図１４に示す予防措置要求１２０は、例えば、コマンドＩＤ“Ｂ０００１”、要求先“仲介装置Ａ”、措置情報“ｒｅｂｏｏｔ”を含む。予防措置要求１２０は、例えば、ＨＴＴＰＳのプロトコルを用いて送信されることを想定するが、通信プロトコルはこれに限られない。

図１０に戻り、第１の実施形態に係る遠隔管理システムにおける機器管理方法の説明を続ける。ステップＳ１０６において、アプリサーバ３０は、図１３に示したように、クラウドサーバ２０に対して、予防措置要求を送信する。ステップＳ１０７において、クラウドサーバ２０は、仲介装置５０に対して、アプリサーバ３０から送信された予防措置要求を転送する（送信ステップの一例）。

ステップＳ１０８において、仲介装置５０は、クラウドサーバ２０から予防措置要求を受信した場合、要求された予防措置を実行する。仲介装置５０は、例えば、クラウドサーバ２０から図１４に示した予防措置要求１２０を受信した場合、措置情報として指示された“リブート処理”を実行する。ステップＳ１０９において、仲介装置５０は、予防措置が終了した場合、予防措置要求に対するフィードバックとして、措置結果通知をクラウドサーバ２０に対して送信する。ステップＳ１１０において、クラウドサーバ２０は、アプリサーバ３０に対して、仲介装置５０から送信された措置結果通知を転送する。

ここで、仲介装置５０が送信する措置結果通知の内容について説明する。図１５は、第１の実施形態に係る仲介装置における予防措置のフィードバックの内容の一例を示す図である。図１５に示す措置結果通知１３０は、「コマンドＩＤ」、「措置の成否」、「仲介装置のステータス」および「障害の原因」の情報等が含まれる。図１５に示す措置結果通知１３０は、例えば、図１４に示した予防措置要求１２０に含まれるコマンドＩＤ「Ｂ０００１」に対応するものである。また、図１５に示す措置結果通知１３０は、要求された予防措置が成功し、仲介装置５０のステータスが復旧したことを示している。さらに、図１５に示す措置結果通知１３０は、障害（異常）の原因がメモリ残量不足であったことを併せて通知する。アプリサーバ３０は、仲介装置５０から措置結果通知１３０を取得することによって、自らが発行したコマンド（予防措置要求）に対する措置結果を知ることができる。

アプリサーバ３０は、措置結果通知１３０の内容によって、障害（異常）の兆候が改善していない場合、異なる予防措置要求を仲介装置５０に対して送信してもよい。また、アプリサーバ３０は、予防措置要求を送信後、一定期間、措置結果通知１３０を受信できない場合、同様の予防措置要求を仲介装置５０に対して再度送信してもよい。さらに、アプリサーバ３０は、取得した措置結果通知１３０の内容に基づいて、措置情報管理テーブル３５１の内容を更新してもよい。

●第１の実施形態の効果
以上説明したように、第１の実施形態に係る遠隔管理システムは、機器管理システム１０を構成するクラウドサーバ２０が、仲介装置５０の状態を示すステータス情報５８０を仲介装置５０から取得する。機器管理システム１０を構成するアプリサーバ３０は、クラウドサーバ２０が取得したステータス情報５８０に基づいて、仲介装置５０に所定の処理の実行を指示する指示情報を決定する。そして、クラウドサーバ２０は、アプリサーバ３０によって決定された指示情報に基づいて、予防措置要求を仲介装置５０に対して送信する。そのため、第１の実施形態に係る遠隔管理システムは、仲介装置５０による障害（異常）が発生する前に、障害（異常）の兆候を検知して予防措置を行うので、システムを継続して正常に稼働させることができる。

●第１の実施形態の変形例１●
次に、第１の実施形態の変形例１について説明する。第１の実施形態の変形例１に係る遠隔管理システムは、図１３に示した仲介装置５０の障害（異常）の兆候を改善するための措置情報の決定処理を、アプリサーバ３０ではなく、クラウドサーバ２０において行う。

●機能構成
図１６は、第１の実施形態の変形例１に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。図１６に示すクラウドサーバ２０により実現される機能は、第１の実施形態のアラートポリシー管理部２０４に変えて、ステータス情報解析部２０８を含む。さらに、図１６に示すクラウドサーバ２０は、記憶部２０７に措置情報管理テーブル３５１ａを記憶している。

ステータス情報解析部２０８は、仲介装置５０から取得したステータス情報５８０の内容に基づいて、仲介装置５０に対する予防措置となる措置情報を決定する機能である。具体的には、ステータス情報解析部２０８は、記憶部２０７に記憶された措置情報管理テーブル３５１ａを用いて、仲介装置５０に対する措置情報を決定する。ステータス情報解析部２０８は、例えば、図３に示したＣＰＵ１００１で実行されるプログラム等により実現される。

図１７は、第１の実施形態の変形例１に係る措置情報管理テーブルの一例を示す図である。図１７に示す措置情報管理テーブル３５１ａは、図６に示したアラートポリシー２５１と図７に示した措置情報管理テーブル３５１に含まれる情報を、一つのテーブルにまとめたものである。すなわち、措置情報管理テーブル３５１ａは、アラートポリシー２５１および措置情報管理テーブル３５１に含まれる「条件ＩＤ」を含まない。これによって、第１の実施形態の変形例１に係るクラウドサーバ２０は、仲介装置５０から受信したステータス情報５８０に含まれる情報が、措置情報管理テーブル３５１ａに含まれる「条件」を満たす場合、当該条件に関連づけられた措置情報を決定することができる。

●機器管理方法
図１８は、第１の実施形態の変形例１に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。ステップＳ４０１およびステップＳ４０２の処理は、図１０に示したステップＳ１０１とステップＳ１０２の処理と同様であるため、説明を省略する。

ステップＳ４０３において、クラウドサーバ２０は、受信したステータス情報５８０の解析を行う。ここで、クラウドサーバ２０における措置情報の決定処理について説明する。図１９は、第１の実施形態の変形例１に係るクラウドサーバにおける措置情報の決定処理の一例を示すフローチャートである。ステップＳ４５１において、クラウドサーバ２０の仲介装置通信部２０１は、仲介装置５０からステータス情報５８０を受信した場合、処理をステップＳ４５２へ移行させる。一方で、クラウドサーバ２０の仲介装置通信部２０１は、仲介装置５０からステータス情報５８０を受信していない場合、ステップＳ４５１の処理を繰り返す。

ステップＳ４５２において、クラウドサーバ２０のステータス情報解析部２０８は、記憶部２０７に記憶された措置情報管理テーブル３５１ａの読み出しを行う。具体的には、ステータス情報解析部２０８は、記憶・読出部２０６に対して、措置情報管理テーブル３５１ａの読出要求を出力する。記憶・読出部２０６は、出力された読出要求を検知すると、記憶部２０７に記憶された措置情報管理テーブル３５１ａを読み出す。そして、記憶・読出部２０６は、読み出した措置情報管理テーブル３５１ａを、ステータス情報解析部２０８に対して出力する。

ステップＳ４５３において、クラウドサーバ２０のステータス情報解析部２０８は、受信したステータス情報５８０に含まれる情報に、措置情報管理テーブル３５１ａの条件を満たすものがある場合、処理をステップＳ４５４へ移行させる。一方で、クラウドサーバ２０のステータス情報解析部２０８は、受信したステータス情報５８０に含まれる情報に、措置情報管理テーブル３５１ａの条件を満たすものがない場合、処理を終了する。なお、「条件を満たすものがあるか否か」の判定方法は、図１１のステップＳ２０３に示した内容と同様である。

ステップＳ４５４において、クラウドサーバ２０のステータス情報解析部２０８は、条件を満たす情報に対応する措置情報を決定する。ステータス情報解析部２０８は、例えば、図１７に示した措置情報管理テーブル３５１ａの中の項目「メモリ」の条件「９００ＭＢ以上」を満たす場合、措置情報として「リブート処理」を決定する。ステップＳ４５５において、クラウドサーバ２０の仲介装置通信部２０１は、決定した措置情報に基づく予防措置要求を、仲介装置５０に対して送信する。なお、予防措置要求の内容および形式は、図１４に示した予防措置要求１２０と同様のものである。

図１８に戻り、第１の実施形態の変形例１に係る遠隔管理システムにおける機器管理方法の説明を続ける。ステップＳ４０４において、クラウドサーバ２０は、アプリサーバ３０に対して、ステータス情報５８０を送信する。アプリサーバ３０は、ステータス情報５８０を受信した場合、受信したステータス情報５８０をステータス情報管理ＤＢ３５２に記憶させる。ステップＳ４０５において、クラウドサーバ２０は、図１９に示したように、仲介装置５０に対して、決定した措置情報に基づく予防措置要求を、仲介装置５０に対して送信する。なお、ステップＳ４０４とステップＳ４０５の処理の順序は、前後してもよく、または並行して行われてもよい。ステップＳ４０６乃至ステップＳ４０８の処理は、図１０に示したステップＳ１０８乃至ステップＳ１１０の処理と同様であるため、説明を省略する。

したがって、第１の実施形態の変形例１に係る遠隔管理システムは、仲介装置５０の障害（異常）の兆候を検知して予防措置を特定するまでの処理を、クラウドサーバ２０が担う。そのため、第１の実施形態の変形例１に係る遠隔管理システムは、アプリサーバ３０の処理負担を軽減することができ、またはアプリサーバ３０が設けられない使用環境においても適用することができる。

●第１の実施形態の変形例２●
次に、第１の実施形態の変形例２について説明する。第１の実施形態の変形例２に係る遠隔管理システムは、クラウドサーバ２０においてアラートの要否の判定処理を行わずに、アプリサーバ３０において仲介装置５０に対する予防措置の特定処理を行う。

●機能構成
図２０は、第１の実施形態の変形例２に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。図２０に示すアプリサーバ３０は、第１の実施形態の機能に加え、記憶部３０７に措置情報管理テーブル３５１ｂを記憶している。措置情報管理テーブル３５１ｂは、図１７に示した措置情報管理テーブル３５１ａと同様の構成である。ステータス情報解析部３０２は、クラウドサーバ２０から仲介装置５０のステータス情報５８０を受信した場合、記憶部３０７に記憶された措置情報管理テーブル３５１ｂを用いて、仲介装置５０の障害（異常）の兆候を改善するための措置情報を決定する。

なお、遠隔管理システム１ｂは、クラウドサーバ２０においてアラート要否の判定を行わないため、図２０に示すクラウドサーバ２０にアラートポリシー管理部２０４の構成を設けなくてもよい。また、遠隔管理システム１ｂは、図２０に示すクラウドサーバ２０の記憶部２０７にアラートポリシー２５１を記憶していなくてもよい。

●機器管理方法
図２１は、第１の実施形態の変形例２に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。ステップＳ５０１およびステップＳ５０２の処理は、図１０に示したステップＳ１０１とステップＳ１０２の処理と同様であるため、説明を省略する。

ステップＳ５０３において、クラウドサーバ２０は、仲介装置５０のステータス情報５８０を、アプリサーバ３０に対して送信する。なお、クラウドサーバ２０は、グループ設定部２０５において設定されたグループに基づいて、ステータス情報５８０の送信要否を判断してもよい。

ステップＳ５０４において、アプリサーバ３０は、クラウドサーバ２０から仲介装置５０のステータス情報５８０を受信した場合、ステータス情報５８０の解析を行う。ここで、アプリサーバ３０における措置情報の決定処理について説明する。図２２は、第１の実施形態の変形例２に係るアプリサーバにおける措置情報の決定処理の一例を示すフローチャートである。

ステップＳ５５１において、アプリサーバ３０の送受信部３０１は、クラウドサーバ２０から仲介装置５０のステータス情報５８０を受信した場合、処理をステップＳ５５２へ移行させる。一方で、アプリサーバ３０の送受信部３０１は、クラウドサーバ２０から仲介装置５０のステータス情報５８０を受信していない場合、ステップＳ５５１の処理を繰り返す。

ステップＳ５５２において、アプリサーバ３０のステータス情報解析部３０２は、記憶部３０７に記憶された措置情報管理テーブル３５１ｂの読み出しを行う。具体的には、ステータス情報解析部３０２は、記憶・読出部３０６に対して、措置情報管理テーブル３５１ｂの読出要求を出力する。記憶・読出部３０６は、出力された読出要求を検知すると、記憶部３０７に記憶された措置情報管理テーブル３５１ｂを読み出す。そして、記憶・読出部３０６は、読み出した措置情報管理テーブル３５１ｂを、ステータス情報解析部３０２に対して出力する。

ステップＳ５５３において、アプリサーバ３０のステータス情報解析部３０２は、受信したステータス情報５８０に含まれる情報に、措置情報管理テーブル３５１ｂの条件を満たすものがある場合、処理をステップＳ５５４へ移行させる。一方で、アプリサーバ３０のステータス情報解析部３０２は、受信したステータス情報５８０に含まれる情報に、措置情報管理テーブル３５１ｂの条件を満たすものがない場合、処理を終了する。なお、「条件を満たすものがあるか否か」の判定方法は、図１１のステップＳ２０３に示した内容と同様である。

ステップＳ５５４において、アプリサーバ３０のステータス情報解析部３０２は、条件を満たす情報に対応する措置情報を決定する。なお、ステータス情報解析部３０２による措置情報の決定方法は、図１９のステップＳ４５４で示したクラウドサーバ２０のステータス情報解析部２０８の処理と同様である。ステップＳ５５５において、アプリサーバ３０の送受信部３０１は、決定した措置情報に基づく予防措置要求を、クラウドサーバ２０に対して送信する。なお、予防措置要求の内容および形式は、図１４に示した予防措置要求１２０と同様のものである。

図２１に戻り、第１の実施形態の変形例２に係る遠隔管理システムにおける機器管理方法の説明を続ける。ステップＳ５０５において、アプリサーバ３０は、クラウドサーバ２０に対して、決定した措置情報に基づく予防措置要求を送信する。ステップＳ５０６乃至ステップＳ５０９の処理は、図１０に示したステップＳ１０７乃至ステップＳ１１０の処理と同様であるため、説明を省略する。

したがって、第１の実施形態の変形例２に係る遠隔管理システムは、仲介装置５０の障害（異常）の兆候を検知して予防措置を特定するまでの処理を、アプリサーバ３０が担う。そのため、遠隔管理システム１ｂは、クラウドサーバ２０の処理負担を軽減することができ、またはクラウドサーバ２０が設けられない使用環境においても適用することができる。

●第２の実施形態●
続いて、第２の実施形態に係る遠隔管理システムについて説明する。第１の実施形態と同一構成および同一機能は、同一の符号を付して、その説明を省略する。第２の実施形態に係る遠隔管理システムは、仲介装置５０において異常リブートが発生した場合の処理である。遠隔管理システム１ｄは、仲介装置５０から異常リブートの発生を示す情報を機器管理システム１０に送信する。そして、遠隔管理システム１ｄは、機器管理システム１０において異常リブートの原因を解析し、仲介装置に対して対策要求を送信する。

●機能構成
図２３は、第２の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。第２の実施形態に係るアプリサーバ３０は、第１の実施形態の機能に加え、記憶部３０７にファームウエア３５３を記憶している。ファームウエア３５３は、仲介装置５０の制御を行うために、仲介装置５０に対して配布するソフトウエアである。アプリサーバ３０は、クラウドサーバ２０を介して、更新用のファームウエア３５３を仲介装置５０に対して送信する。仲介装置５０は、アプリサーバ３０からファームウエア３５３を受信した場合、ファームウエアの更新を実行する。

●機器管理方法
図２４は、第２の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。図２４は、仲介装置５０において、更新前のファームウエアがインストールされている例を説明する。また、クラウドサーバ２０の記憶部２０７に記憶されたアラートポリシー２５１は、項目「ファームウエア」の条件として、「ファームウエアのバージョンが最新でない」ことを示す内容が設定されているものとする。さらに、アプリサーバ３０の記憶部３０７に記憶された措置情報管理テーブル３５１は、上記条件に対応する措置情報として、「ファームウエアを更新する」ことを示す内容が設定されているものとする。

ステップＳ６０１において、仲介装置５０は、異常リブートの発生を検知する。異常リブートとは、予期しないタイミングで自動的に発生したリブートのことである、仲介装置５０は、異常リブートの発生を検知すると、異常リブートが発生したことを示す情報を含むステータス情報５８０を生成する。ステータス情報５８０は、図８に示した情報のほか、実行中（更新前）のファームウエアのバージョン情報を含む。

ステップＳ６０２において、仲介装置５０は、生成したステータス情報５８０をクラウドサーバ２０に対して送信する。ステップＳ６０３において、クラウドサーバ２０は、仲介装置５０からステータス情報５８０を受信した場合、受信したステータス情報５８０の解析を行う。ここでは、仲介装置５０から送信されたステータス情報５８０は、更新前のファームウエアのバージョン情報を含む。そのため、クラウドサーバ２０のアラートポリシー管理部２０４は、記憶部２０７に記憶されたアラートポリシー２５１に含まれる条件を満たすため、アラート通知を送信するように判定する。

ステップＳ６０４において、クラウドサーバ２０は、アプリサーバ３０に対して、アラート通知を送信する。アラート通知は、仲介装置５０において実行されているファームウエアのバージョン情報を含む。なお、アラート通知の構成は、図１２に示したアラート通知１１０と同様の構成であってもよい。ステップＳ６０５において、アプリサーバ３０は、クラウドサーバ２０からアラート通知を受信した場合、仲介装置５０に対する予防措置を特定する。具体的には、アプリサーバ３０のステータス情報解析部３０２は、記憶部３０７に記憶された措置情報管理テーブル３５１の中で、受信したアラート通知に含まれる条件ＩＤと同一の条件ＩＤに紐づく措置情報を決定する。ここでは、決定される措置情報の内容は、「ファームウエアの更新」である。

ステップＳ６０６において、アプリサーバ３０は、決定した措置情報を含む対策要求を、クラウドサーバ２０に対して送信する。ここでは、決定した措置情報がファームウエアの更新であるため、アプリサーバ３０は、対策要求とともにファームウエア３５３を送信する。なお、対策要求の構成は、図１４に示した予防措置要求１２０と同様の構成であってもよい。ステップＳ６０７において、クラウドサーバ２０は、アプリサーバ３０から送信された対策要求を、仲介装置５０に対して転送する。ステップＳ６０８において、仲介装置５０は、クラウドサーバ２０から対策要求を受信した場合、要求された対策を実行する。具体的には、仲介装置５０は、対策要求とともに送信されたファームウエア３５３を用いて、実行中のファームウエアの更新を行う。

ステップＳ６０９において、仲介装置５０は、要求された対策が完了すると、クラウドサーバ２０に対して、対策結果通知を送信する。対策結果通知は、更新されたファームウエアのバージョン情報を含む。対策結果通知の構成は、図１５に示した措置結果通知１３０と同様の構成であってもよい。ステップＳ６１０において、クラウドサーバ２０は、仲介装置５０から送信された対策結果通知を、アプリサーバ３０に対して転送する。

以上の説明において、仲介装置５０において異常リブートが発生した場合の対策として、仲介装置５０のファームウエアを更新させる例を示したが、機器管理システム１０において決定される対策は、これに限られない。機器管理システム１０は、例えば、第１の実施形態で示した予防措置の特定処理と同様の方法で、仲介装置５０に対して要求する対策を決定してもよい。また、機器管理システム１０は、仲介装置５０から取得したログ情報を蓄積し、人工知能（Artificial Intelligence; AI）にログのパターンを学習させて原因の解析を行ってもよい。

さらに、仲介装置５０は、異常リブートが発生した場合、ログ情報（ステータス情報５８０）の送信を行わない構成にしてもよい。仲介装置５０は、例えば、機器管理システム１０との間における通信量の制限が厳しい場合、機器管理システム１０に対するログ情報の送信を中断し、通信量の制限が緩い場合、機器管理システム１０に対してログ情報を送信する構成にしてもよい。これによって、機器管理システム１０と仲介装置５０の間の通信量に応じて、適切なシステム運用が可能となる。

●第２の実施形態の効果
以上説明したように、第２の実施形態に係る遠隔管理システムは、仲介装置５０において異常リブートが発生した場合に、予め設定されたタスクスケジュール５５２に依らずに、機器管理システム１０において仲介装置５０の障害（異常）の検知および対策要求を行う。そのため、遠隔管理システム１ｃは、仲介装置５０で障害（異常）が発生した場合においても、早期に対策を講じることが可能であるので、システムを継続して正常に稼働させることができる。

●第３の実施形態●
次に、第３の実施形態に係る遠隔管理システムについて説明する。第１の実施形態または第２の実施形態と同一構成および同一機能は、同一の符号を付して、その説明を省略する。遠隔管理システム１ｄは、機器管理システム１０において、仲介装置５０だけでなく、仲介装置５０に接続される機器６０の障害（異常）の兆候を検知するためのシステムである。

●機能構成
図２５は、第３の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。図２５に示すクラウドサーバ２０は、第１の実施形態または第２の実施形態の機能に加え、記憶部２０７に第１のアラートポリシー２５３および第２のアラートポリシー２５４を記憶している。

第１のアラートポリシー２５３は、アラートポリシー２５１と同様の構成を有する。第１のアラートポリシー２５３（アラートポリシー２５１）は、監視対象が一般的なコンピュータである仲介装置５０であるため、汎用的なコンピュータリソースの状態を示す情報が含まれていればよい。一方で、第２のアラートポリシー２５４は、監視対象が種別の異なる機器６０であるため、汎用的なコンピュータリソースの状態を示す情報に加えて、機器６０特有の稼働状態を示す情報を含む。

図２６は、第３の実施形態に係る第２のアラートポリシーの一例を示す図である。図２６に示す第２のアラートポリシー２５４は、機器６０がプロジェクタ（ＰＪ）である場合の一例である。図２６に示す第２のアラートポリシー２５４は、例えば、ＣＰＵ、メモリ、ストレージ、電源等の汎用的なコンピュータリソースの状態を示す情報に加え、ＰＪの投影用ランプの稼働状態を示す情報を含む。第２のアラートポリシー２５４に含まれるアラート通知の要否を判定するための「条件」は、例えば、機器６０の障害（異常）の兆候を検知するための条件であり、第２の条件の一例である。

なお、第２のアラートポリシー２５４は、テキスト情報だけでなく、例えば、音の情報を含んでもよい。具体的には、第２のアラートポリシー２５４は、機器６０に障害が発生した場合に発せられる音の情報を条件として設定する。クラウドサーバ２０は、機器６０から送信される機器情報に当該条件を満たす音の情報を含まれる場合に、機器６０の障害（異常）の兆候を検知したとして、アラート通知を送信する構成にしてもよい。また、第２のアラートポリシー２５４は、機器６０ごとに設けてもよく、機器６０の種別に応じて、項目や条件を変更してもよい。

図２５に示すアプリサーバ３０は、第１の実施形態または第２の実施形態の機能に加え、記憶部３０７に第１の措置情報管理テーブル３５４および第２の措置情報管理テーブル３５５を記憶している。第１の措置情報管理テーブル３５４は、図７に示した措置情報管理テーブル３５１と同様のものであり、仲介装置５０の障害（異常）の兆候を改善するための措置情報を管理する。第２の措置情報管理テーブル３５５は、機器６０の障害（異常）の兆候を改善するための管理するためのものである。

図２７は、第３の実施形態に係る第２の措置情報管理テーブルの一例を示す図である。図２７に示す第２の措置情報管理テーブル３５５は、第１の措置情報管理テーブル３５４と同様に、「条件ＩＤ」に障害の兆候の改善を指示する「措置情報」を紐づけて管理している。「条件ＩＤ」は、図２６に示した第２のアラートポリシー２５４に含まれる「条件ＩＤ」に対応している。

ステータス情報解析部３０２は、クラウドサーバ２０から受信したアラート通知に含まれる「条件ＩＤ」と同一の「条件ＩＤ」に対応づけられた「措置情報」を、機器６０に対する措置情報として決定する。なお、第２のアラートポリシー２５４が複数存在する場合、第２の措置情報管理テーブル３５５は、第２のアラートポリシー２５４に対応づけて複数存在する。また、第２の措置情報管理テーブル３５５は、機器６０ごとに設けてもよく、機器６０の種別に応じて措置情報を変更してもよい。第２の措置情報管理テーブル３５５に含まれる措置情報は、機器６０に対して所定の処理の実行を指示する第２の指示情報の一例である。

さらに、図２５に示すアプリサーバ３０は、記憶部３０７に機器情報管理ＤＢ３５６を構築している。機器情報管理ＤＢ３５６は、機器６０から取得した機器６０のリソース状態や稼働状態を示す機器情報を管理している。機器情報は、例えば、図２６に示した第２のアラートポリシー２５４に含まれる「項目」の情報を含む。

●機器管理方法
図２８は、第３の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。図２８は、機器管理システム１０が、仲介装置５０を介して、一台の機器６０から機器情報を取得する例を説明するが、一台の仲介装置５０を介して、複数の機器６０の機器情報を取得してもよい。

ステップＳ７０１において、仲介装置５０は、機器６０に対して、機器情報の取得要求を送信する。仲介装置５０の機器通信部５０２は、スケジューラ機能部５０３の制御により、予め定められたスケジュール（タスクスケジュール５５２）に基づいて、機器情報の取得要求を、機器６０に対して送信する。ステップＳ７０２において、機器６０の機器情報生成部６０２は、仲介装置５０から機器情報の取得要求を受信した場合、機器６０のリソース状態や稼働状態を示す機器情報を生成する。ステップＳ７０３において、機器６０の送受信部６０１は、生成した機器情報を仲介装置５０に対して送信する。

ステップＳ７０４において、仲介装置５０は、機器６０から送信された機器情報を、クラウドサーバ２０に対して送信する。ここで、ステップＳ７０４の処理は、仲介装置５０の記憶部５０８に記憶されたタスクスケジュール５５２に示されるスケジュールに基づいて行われる。

ステップＳ７０５において、クラウドサーバ２０は、仲介装置５０から機器情報を受信した場合、第２のアラートポリシー２５３を用いて、アプリサーバ３０に対するアラート通知の要否を判定する。なお、第２のアラートポリシー２５３を用いたアラート通知の要否の判定処理は、図１１に示したアラートポリシー２５１を用いたアラート通知の要否の判定処理と同様である。また、ステップＳ７０５の処理において、クラウドサーバ２０のアラートポリシー管理部２０４は、アラート通知を送信すると判定したものとする。ステップＳ７０６において、クラウドサーバ２０は、アプリサーバ３０に対して、アラート通知を送信する。

ステップＳ７０７において、アプリサーバ３０は、クラウドサーバ２０からアラート通知を受信した場合、第２の措置情報管理テーブル３５５を用いて、機器６０の障害（異常）の兆候を改善するための措置情報を決定する。なお、第２の措置情報管理テーブル３５５を用いた予防措置の特定処理は、図１３に示した措置情報管理テーブル３５１を用いた予防措置の特定処理と同様である。ステップＳ７０８において、アプリサーバ３０は、決定した措置情報に基づく予防措置要求を、クラウドサーバ２０に対して送信する。ステップＳ７０９において、クラウドサーバ２０は、アプリサーバ３０から送信された予防措置要求を、仲介装置５０に対して転送する。

ステップＳ７１０において、仲介装置５０は、クラウドサーバ２０から予防措置要求を受信した場合、予防措置要求に含まれる措置情報に対応する措置を、機器６０に対して実行する。なお、仲介装置５０は、機器６０に対して予防措置要求を転送して、措置情報に対応する措置を機器６０自身に行わせてもよい。

ステップＳ７１１において、仲介装置５０は、機器６０の予防措置が終了した場合、予防措置要求に対するフィードバックとして、措置結果通知をクラウドサーバ２０に対して送信する。ステップＳ７１２において、クラウドサーバ２０は、アプリサーバ３０に対して、仲介装置５０から受信した措置結果通知を転送する。なお、措置結果通知の構成は、図１５に示した措置結果通知１３０と同様の構成であってもよい。

アプリサーバ３０は、機器６０から措置結果通知を取得することによって、自らが発行したコマンドに対する措置結果を知ることができる。アプリサーバ３０は、取得した措置結果通知の内容に基づいて、第２の措置情報管理テーブル３５５の内容を更新してもよい。

●第３の実施形態の効果
以上説明したように、第３の実施形態に係る遠隔管理システムは、機器管理システム１０が仲介装置５０だけでなく、機器６０のログを収集する。そのため、遠隔管理システム１ｄは、管理対象である機器６０の障害（異常）の兆候を事前に検知して、機器６０に予防措置を実行させることができるので、ローカルネットワーク１１の内部環境を含めたシステムを、継続して正常に稼働させることができる。

●第４の実施形態●
次に、第４の実施形態に係る遠隔管理システムについて説明する。第１の実施形態乃至第３の実施形態と同一構成および同一機能は、同一の符号を付して、その説明を省略する。遠隔管理システム１ｅは、予め設定されたスケジュール制御による仲介装置５０からのログアップだけでなく、アプリサーバ３０がログを取得したいタイミングでログを取得して障害の兆候を検知して予防措置を行わせることができる。

●機能構成
図２９は、第４の実施形態に係るクラウドサーバおよびアプリサーバの機能構成の一例を示す図である。図２９に示すクラウドサーバ２０は、記憶部２０７にステータス情報管理ＤＢ２５５を構築している。図２９に示すステータス情報管理ＤＢ２５５は、仲介装置５０から取得したステータス情報を記憶している。図３０は、第４の実施形態に係るステータス情報管理ＤＢにより管理される情報の一例を示す図である。図３０に示す管理情報５９０は、仲介装置５０から受信したステータス情報５８０ごとにログＩＤを紐づけて管理している。管理情報５９０は、図８（ａ）に示したステータス情報５８０のメッセージ欄に含まれる情報、すなわち図８（ｂ）に示した情報が含まれる。

●機器管理方法
図３１は、第４の実施形態に係る遠隔管理システムにおける機器管理方法の一例を示すシーケンス図である。ステップＳ８０１において、アプリサーバ３０は、クラウドサーバ２０に対して、仲介装置５０のステータス情報のアップロード要求を送信する。ステップＳ８０２において、クラウドサーバ２０は、アプリサーバ３０から送信されたステータス情報のアップロード要求を、仲介装置５０に対して転送する。

ステップＳ８０３において、仲介装置５０は、ステータス情報のアップロード要求を受信した場合、仲介装置５０のコンピュータリソースに関する情報を含むステータス情報５８０を生成する。ステップＳ８０４において、仲介装置５０は、生成したステータス情報５８０を、クラウドサーバ２０に対して送信する。

ステップＳ８０５において、クラウドサーバ２０は、仲介装置５０からステータス情報５８０を受信した場合、受信したステータス情報５８０にログＩＤを付与し、ログＩＤをアプリサーバ３０に対して送信する。また、クラウドサーバ２０は、ログＩＤを付与したステータス情報５８０を、ステータス情報管理ＤＢ２５５に記憶させる。

ステップＳ８０６において、アプリサーバ３０は、クラウドサーバ２０に対して、ステータス情報のダウンロード要求を送信する。ダウンロード要求は、クラウドサーバ２０から送信されたログＩＤの情報を含む。ステップＳ８０７において、クラウドサーバ２０は、ステ―タス情報のダウンロード要求を受信した場合、ステータス情報管理ＤＢ２５５に記憶されたステータス情報の中からログＩＤに対応するステータス情報５８０を送信する。

ステップＳ８０８において、アプリサーバ３０は、クラウドサーバ２０からステータス情報５８０を受信した場合、ステータス情報５８０の解析を行う。ステップＳ８０８におけるステータス情報５８０の解析処理は、第１の実施形態の変形例２で示したように、アプリサーバ３０のステータス情報解析部３０２が、措置情報管理テーブル３５１ｂを用いて、仲介装置５０に対する予防措置の特定処理をおこなってもよい。一方で、ステータス情報５８０の解析処理は、第１の実施形態で示したように、措置情報管理テーブル３５１を用いて、仲介装置５０に対する予防措置の特定処理をおこなってもよい。この場合、ステップＳ８０７の処理において、クラウドサーバ２０のアラートポリシー管理部２０４が、ダウンロード要求を受信したステータス情報５８０に対してアラート通知の要否判定を行い、必要と判定されたステータス情報５８０のアラート通知を、アプリサーバ３０に対して送信する。

ステップＳ８０９において、アプリサーバ３０は、決定した措置情報に基づく予防措置要求を、クラウドサーバ２０に対して送信する。ステップＳ８１０において、クラウドサーバ２０は、アプリサーバ３０から送信された予防措置要求を、仲介装置５０に対して転送する。ステップＳ８１１において、仲介装置５０は、クラウドサーバ２０から予防措置要求を受信した場合、要求された予防措置を実行する。

ステップＳ８１２において、仲介装置５０は、予防措置が終了した場合、予防措置要求に対するフィードバックとして、措置結果通知をクラウドサーバ２０に対して送信する。ステップＳ８１３において、クラウドサーバ２０は、アプリサーバ３０に対して、仲介装置５０から受信した措置結果通知を転送する。なお、ステップＳ８０９～ステップＳ８１３の処理は、図１０に示したステップＳ１０６～ステップＳ１１０の処理と同様である。

本実施形態に係る遠隔管理システムは、仲介装置５０のステータス情報の取得要求を送信する場合を説明したが、機器６０の機器情報の取得要求をアプリサーバ３０から送信する構成にしてもよい。この場合、機器情報の取得処理や機器６０の障害（異常）の兆候の検知処理等は、第３の実施形態で説明した構成を用いて行われる。

●第４の実施形態の効果
以上説明したように、第４の実施形態に係る遠隔管理システムは、予め設定されたスケジュール制御による仲介装置５０からのログアップだけでなく、アプリサーバ３０がログを取得したいタイミングでログを取得して障害の兆候を検知して予防措置を行わせることができる。そのため、遠隔管理システム１ｅは、仲介装置５０が属するネットワーク環境や、アプリ３５ごとの運用の仕方に応じて、システムを継続して正常に稼働させるための機器管理を柔軟に行うことができる。また、アプリサーバ３０からの要求時にのみログ取得を行うことで、機器管理に伴う通信量を低減させることができる。

●その他の実施形態●
図３２は、その他の実施形態に係る遠隔管理システムのシステム構成の一例を示す図である。図３２に示す遠隔管理システム２は、ローカルネットワークＡ１１ａおよびローカルネットワークＢ１１ｂを含む。ローカルネットワークＡ１１ａとローカルネットワークＢ１１ｂは、異なる環境で使用されるネットワークであり、それぞれのネットワーク内に位置する管理対象の機器６０の種類が異なる。ローカルネットワークＡ１１ａおよびローカルネットワークＢ１１ｂは、例えば、各顧客先で形成されるネットワークである。

ローカルネットワークＡ１１ａは、仲介装置５０ａ、産業機械７１、撮像装置７２および集音装置７３を含む。仲介装置５０ａは、有線または無線ＬＡＮ等を介して産業機械７１、撮像装置７２、集音装置７３と通信可能である。また、仲介装置５０ａは、ファイアウォール１３ａを経由してクラウドサーバ２０と通信可能である。

産業機械７１は、加工装置、検査装置、搬送装置、ピッキング装置等である。産業機械７１は、機器の識別情報や、稼働状況、異常動作の有無、消耗品の交換時期に関する情報、機器による検査結果等の機器情報を、機器管理システム（クラウドサーバ２０またはアプリサーバ３０）に対して送信する。産業機械７１は、データ形式または画像形式等の種々の情報伝達手段を用いて、機器情報を機器管理システム（クラウドサーバ２０またはアプリサーバ３０）に対して送信する。撮像装置７２と集音装置７３は、例えば、産業機械７１自体または産業機械７１の周囲に取り付けられた、産業機械７１の状態を把握するための装置である。

ローカルネットワークＢ１１ｂは、仲介装置５０ｂ、医療機器７４、ネットワーク家電７５および３Ｄプリンタ７６を含む。仲介装置５０ｂは、有線または無線ＬＡＮ等を介して医療機器７４、ネットワーク家電７５および３Ｄプリンタ７６と通信可能である。また、仲介装置５０ｂは、ファイアウォール１３ｂを経由してクラウドサーバ２０と通信可能である。

医療機器７４は、眼底検査装置、Ｘ線検査装置、血圧計、体脂肪計、視力計、ペースメーカ等である。医療機器７４は、機器の識別情報や、機器の稼働状況、異常動作の有無、機器による測定結果等の機器情報を、機器管理システム（クラウドサーバ２０またはアプリサーバ３０）に対して送信する。医療機器７４は、データ形式または画像形式等の種々の情報伝達手段を用いて、機器情報を機器管理システム（クラウドサーバ２０またはアプリサーバ３０）に対して送信する。ネットワーク家電７５は、家庭用電化製品（家電）のうち、ネットワークに接続できる機能を有する装置である。

３Ｄプリンタ７５は、造形方式として、材料押出堆積法（ＦＤＭ（Fused Deposition Modeling））、マテリアルジェッティング、バインダジェッティング、粉末焼結積層造形（ＳＬＳ（Selective Laser Sintering））、光造形法（ＳＬＡ（Stereolithography））等を採用する。３Ｄプリンタ７５は、当該機器の識別情報、当該機器の稼働状況、異常動作の有無または当該機器に装着された消耗品の状態等を、数値データ、テキストデータまたは画像データ等の種々のデータ形式を用いて仲介装置５０を経由して機器管理システム（クラウドサーバ２０またはアプリサーバ３０）に送信する。

なお、遠隔管理システム２における管理対象の機器６０は、これに限られない。機器６０は、例えば、自動販売機、電源装置、空調システム、ガス・水道・電気等の計量システム等に通信機能を持たせた機器であってもよい。

図３２に示す遠隔管理システム２において、仲介装置５０は、機器管理システム１０とファイアウォール１３ａまたはファイアウォール１３ｂを介して接続されている。仲介装置５０は、機器６０内に設けてあるファームウエアを、インターネット接続を利用して更新するファームウエア更新機能を備えていてもよい。図３２の例において、一つのローカルネットワーク内に複数の機器６０と一台の仲介装置５０を含む構成を示しているが、複数の仲介装置５０を含んで構成してもよい。例えば、一台の仲介装置５０では処理負荷が大きくなる場合、機器６０のファームウエア更新のための機能と機器６０の遠隔管理を集中的に行う機能を複数の仲介装置に分けて割り当てる構成にしてもよい。

●まとめ●
以上説明したように、本発明の一実施形態に係る機器管理システムは、ローカルネットワーク１１内の機器６０と接続される仲介装置５０と、ファイアウォール１３を介して通信を行う機器管理システム１０であって、仲介装置５０の状態を示すステータス情報５８０を、仲介装置５０から受信する。そして、機器管理システム１０は、受信されたステータス情報５８０が所定条件を満たす場合、条件に紐づく所定の処理の実行を指示する指示情報を決定し、決定した指示情報を、仲介装置５０に対して送信する。そのため、機器管理システム１０は、仲介装置５０による障害（異常）が発生する前に、障害（異常）の兆候を検知して予防措置を行うので、システムを継続して正常に稼働させることができる。

また、本発明の一実施形態に係る機器管理システムは、受信されたステータス情報５８０が、仲介装置５０のリソース状態が所定の閾値を超えていることという条件を満たす場合、条件に紐づく所定の処理の実行を指示する指示情報を決定する。そのため、機器管理システム１０は、仲介装置５０のリソース状態に応じて、仲介装置５０に実行させる処理（予防措置）を指示するので、仲介装置５０による障害（異常）を発生させることなく、システムを継続して正常に稼働させることができる。

さらに、本発明の一実施形態に係る機器管理システムは、受信されたステータス情報５８０が、仲介装置５０のリソース状態を示す所定の文字列が含まれていることという条件を満たす場合、条件に紐づく所定の処理の実行を指示する指示情報を決定する。そのため、機器管理システム１０は、仲介装置５０のリソース状態に応じて、仲介装置５０に実行させる処理（予防措置）を指示するので、仲介装置５０による障害（異常）を発生させることなく、システムを継続して正常に稼働させることができる。

また、本発明の一実施形態に係る機器管理システムは、仲介装置５０からステータス情報５８０を取得するタイミングを、仲介装置５０ごとに設定し、設定されたタイミングで、仲介装置５０からステータス情報５８０を受信する。そのため、機器管理システム１０は、システムの適用環境や管理対象の装置の種別に応じて、適切なシステム運用が可能となる。

さらに、本発明の一実施形態に係る機器管理システムは、特定のリソース項目に対応する情報をステータス情報５８０として、仲介装置５０に送信させるように設定し、設定されたリソース項目に対応する仲介装置５０の状態を示す情報を受信する。そのため、機器管理システム１０は、システムの適用環境や管理対象の装置の種別に応じて、適切なシステム運用が可能となる。

また、本発明の一実施形態に係る機器管理システムは、機器６０の状態を示す機器情報を、仲介装置５０から受信し、受信された機器情報が機器６０の異常の兆候を検知するための条件（第２の条件の一例）を満たす場合、条件に紐づく所定の処理の実行を指示する指示情報（第２の指示情報の一例）を決定する。そのため、機器管理システム１０は、管理対象である機器６０の障害（異常）の兆候を事前に検知して、機器６０に予防措置を実行させることができるので、ローカルネットワーク１１の内部環境を含めたシステムを、継続して正常に稼働させることができる。

さらに、本発明の一実施形態に係る機器管理方法は、ローカルネットワーク１１内の機器６０と接続される仲介装置５０と、ファイアウォール１３を介して通信を行う機器管理システム１０が実行する機器管理方法であって、仲介装置５０から、仲介装置５０の状態を示すステータス情報５８０を受信する受信ステップと、受信されたステータス情報５８０が所定条件を満たす場合、条件に紐づく所定の処理の実行を指示する指示情報を決定する決定ステップと、決定された指示情報を、仲介装置５０に対して送信する送信ステップと、を実行する。そのため、本発明の一実施形態に係る機器管理方法を実行する機器管理システム１０は、仲介装置５０による障害（異常）が発生する前に、障害（異常）の兆候を検知して予防措置を行うので、システムを継続して正常に稼働させることができる。

なお、各実施形態の機能は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）等のレガシープログラミング言語やオブジェクト指向プログラミング言語等で記述されたコンピュータ実行可能なプログラムにより実現でき、ＲＯＭ、ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory）、ＥＰＲＯＭ（Erasable Programmable Read-Only Memory）、フラッシュメモリ、フレキシブルディスク、ＣＤ（Compact Disc）－ＲＯＭ、ＣＤ－ＲＷ（Re-Writable）、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＤＶＤ－ＲＷ、ブルーレイディスク、ＳＤカード、ＭＯ（Magneto-Optical disc）等の装置可読な記録媒体に格納して、または電気通信回線を通じて頒布することができる。

また、各実施形態の機能の一部または全部は、例えばＦＰＧＡ（Field Programmable Gate Array）等のプログラマブル・デバイス（PD）上に実装することができ、またはＡＳＩＣ（Application Specific Integrated Circuit）として実装することができ、各実施形態の機能をＰＤ上に実現するためにＰＤにダウンロードする回路構成データ（ビットストリームデータ）、回路構成データを生成するためのＨＤＬ（Hardware Description Language）、ＶＨＤＬ（Very High Speed Integrated Circuits Hardware Description Language）、Ｖｅｒｉｌｏｇ－ＨＤＬ等により記述されたデータとして記録媒体により配布することができる。

これまで本発明の一実施形態に係る機器管理システム、機器管理方法およびプログラムについて説明してきたが、本発明は上述した実施形態に限定されるものではなく、他の実施形態、追加、変更、削除等、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１ 遠隔管理システム
１０ 機器管理システム
２０ クラウドサーバ（第１の管理装置の一例）
３０ アプリサーバ（第２の管理装置の一例）
５０ 仲介装置
６０ 機器
２０１ 仲介装置通信部（受信手段および送信手段の一例）
２０４ アプリ通信部（通知手段の一例）
２０７ 記憶部（記憶手段の一例）
３０２ ステータス情報解析部（決定手段および特定手段の一例）
３０３ 監視レベル設定部３０３（設定手段の一例）
３０７ 記憶部（記憶手段の一例）

特開２０１６－１５２４６１号公報

Claims (9)

1. ローカルネットワーク内の機器と接続される仲介装置と、ファイアウォールを介して通信を行う機器管理システムであって、
   前記仲介装置から該仲介装置の状態を示すステータス情報を取得するタイミングを、前記仲介装置ごとに設定するとともに、特定のリソース項目に対応する情報を前記ステータス情報として、前記仲介装置に送信させるように設定する設定手段と、
   前記設定されたタイミングで、前記仲介装置から前記ステータス情報を受信し、前記設定された前記特定のリソース項目に対応する前記ステータス情報を受信する受信手段と、
   前記受信されたステータス情報が所定の条件を満たす場合、前記条件に紐づく所定の処理の実行を指示する指示情報を決定する決定手段と、
   前記決定された前記指示情報を、前記仲介装置に対して送信する送信手段と、
   を備える機器管理システム。
2. ローカルネットワーク内の機器と接続される仲介装置と、ファイアウォールを介して通信を行う機器管理システムであって、
   前記仲介装置から、該仲介装置の状態を示すステータス情報を受信する受信手段と、
   前記受信された前記ステータス情報が所定の条件を満たす場合、前記条件に紐づく所定の処理の実行を指示する指示情報を決定する決定手段と、
   前記決定された前記指示情報を、前記仲介装置に対して送信する送信手段と、
   前記仲介装置と前記ファイアウォールを介して通信を行う第１の管理装置と、
   前記機器を管理するためのアプリケーションを提供する第２の管理装置と、
   を備え、
   前記受信されたステータス情報が前記条件を満たす場合、前記決定手段は、前記第１の管理装置から前記第２の管理装置に対してアラートを通知する通知手段と、前記通知されたアラートに対応する前記指示情報を特定する特定手段と、
   を含む機器管理システム。
3. 前記条件は、前記仲介装置のリソース状態が所定の閾値を超えていることという条件を含み、
   前記決定手段は、前記受信されたステータス情報に示されるリソース状態が、前記閾値を超えている場合、前記指示情報を決定する、請求項１または２に記載の機器管理システム。
4. 前記条件は、前記仲介装置のリソース状態を示す所定の文字列が含まれていることという条件を含み、
   前記決定手段は、前記受信されたステータス情報に前記文字列を含まれている場合、前記指示情報を決定する、請求項１乃至３のいずれか一項に記載の機器管理システム。
5. 前記受信手段は、前記仲介装置から、前記機器の状態を示す機器情報を受信し、
   前記決定手段は、前記受信された機器情報が、前記機器の異常の兆候を検知するための条件である第２の条件を満たす場合、前記第２の条件に紐づく所定の処理の実行を指示する第２の指示情報を決定する、請求項１乃至４のいずれか一項に記載の機器管理システム。
6. 請求項１乃至５のいずれか一項に記載の機器管理システムであって、更に、
   前記条件および該条件に紐づく前記指示情報を記憶する記憶手段を備え、
   前記決定手段は、前記記憶された前記条件および前記指示情報に基づいて、前記仲介装置に対する前記指示情報を決定する、機器管理システム。
7. 請求項６に記載の機器管理システムであって、更に、
   異なる複数の前記ローカルネットワーク内に位置する複数の前記仲介装置を備え、
   前記記憶手段は、前記条件および該条件に紐づく前記指示情報を、前記仲介装置ごとに記憶し、
   前記決定手段は、前記仲介装置に対応する前記条件および前記指示情報に基づいて、前記仲介装置に対する前記指示情報を決定する、機器管理システム。
8. ローカルネットワーク内の機器と接続される仲介装置と、ファイアウォールを介して通信を行う機器管理システムが実行する機器管理方法であって、
   前記仲介装置から該仲介装置の状態を示すステータス情報を取得するタイミングを、前記仲介装置ごとに設定するとともに、特定のリソース項目に対応する情報を前記ステータス情報として、前記仲介装置に送信させるように設定する設定ステップと、
   前記設定されたタイミングで、前記仲介装置から前記ステータス情報を受信し、前記設定された前記特定のリソース項目に対応する前記ステータス情報を受信する受信ステップと、
   前記受信されたステータス情報が所定の条件を満たす場合、前記条件に紐づく所定の処理の実行を指示する指示情報を決定する決定ステップと、
   前記決定された前記指示情報を、前記仲介装置に対して送信する送信ステップと、
   を実行する機器管理方法。
9. ローカルネットワーク内の機器と接続される仲介装置と、ファイアウォールを介して通信を行う機器管理システムが実行する機器管理方法であって、
   前記仲介装置から、該仲介装置の状態を示すステータス情報を受信する受信ステップと、
   前記受信された前記ステータス情報が所定の条件を満たす場合、前記条件に紐づく所定の処理の実行を指示する指示情報を決定する決定ステップと、
   前記決定された前記指示情報を、前記仲介装置に対して送信する送信ステップと、
   前記受信された前記ステータス情報が前記条件を満たす場合、前記仲介装置と前記ファイアウォールを介して通信を行う第１の管理装置から前記機器を管理するためのアプリケーションを提供する第２の管理装置に対してアラートを通知する通知ステップと、前記通知されたアラートに対応する前記指示情報を特定する特定ステップと、
   を実行する機器管理方法。

Images