JP2012078945A - 管理システム、デバイス管理方法、及び遠隔管理装置 - Google Patents

Abstract

【課題】被遠隔管理装置の状態を、通信ネットワーク経由で遠隔管理装置により管理する遠隔管理システムについて、リトライ時に生じる情報の二重登録を防止する。
【解決手段】被遠隔管理装置と遠隔管理装置の間でリトライ待機間隔テーブルを共有しておき、被遠隔管理装置からリトライカウント、送信時刻を送付する。遠隔管理装置でこれらと、リトライカウントに対応するリトライ待機間隔、受信時刻から初回送信時刻を取得する。受信データがＤＢ（デバイス管理テーブル）に登録済みの場合、登録済み情報と比較し、値が等しいか、リトライカウントが１以上小さいか、初回送付時刻がより新しいか調査し、いずれかが該当しない場合のみＤＢに登録する。
【選択図】図１０

Description

本発明は、管理システム、デバイス管理方法、及び遠隔管理装置に関し、例えば、管理対象のデバイス（被遠隔管理装置）の状態を、通信ネットワークで接続された遠隔管理装置により管理するための技術に関するものである。

被遠隔管理装置の状態を、通信ネットワークで接続された遠隔管理装置により管理する遠隔管理システムにおいて、被遠隔管理装置と遠隔管理装置間の通信方法として、ブロードバンドフォーラムのＴＲ(Technical Report)−０６９において定義されたプロトコル（一般に、ＣＷＭＰプロトコルと呼ばれている）がある。ＴＲ−０６９については非特許文献１に記載されているが、ＴＲ−０６９では、初期設定、サービスの動的プロビジョニング、ファームウェア更新や状態監視などの機能が提供される。

また、ＴＲ−０６９を利用したシステムの例が特許文献１に開示されている。特許文献１は、管理されるべきデータを遠隔の箇所より変更することが可能な被遠隔管理装置について開示している。

特願２００８−２９７９３６号公報

TR-069 CPE WAN Management Protocol v1.1, Broadband Forum Technical Report, 2007年12月（http://www.broadband-forum.org/technical/download/TR-069_Amendment-2.pdf）

ところで、被遠隔管理装置の状態情報（イベント情報）が、被遠隔管理装置から遠隔管理装置に対して送信されるが、通常この状態情報の送信が失敗に終わったときには、再度送信（リトライ）が試みられる。上記先行技術文献に示される技術よれば、被遠隔管理装置から遠隔管理装置には、リトライ回数を表すリトライカウントに関する情報と、リトライ時の送信時刻が送信されるようになっている。

しかしながら、上記先行技術文献においては、被遠隔管理装置の状態情報のパラメタを遠隔管理装置に送信してＤＢ（データベース）に登録した後に発生するエラーによって生じるリトライ処理する場合に、ＤＢに登録済みのデータをさらに送信して二重登録してしまうことになり、無駄な処理時間及び処理負荷が掛かってしまう。

本発明はこのような状況に鑑みてなされたものであり、一度で通信が成功する場合だけでなくリトライ時であっても、デバイス情報を格納したＤＢを新しい状態に保ちながら、無駄な状態情報の登録処理を回避することを可能にする遠隔管理技術を提供するものである。

上記目的を達成するために、本発明では、被遠隔管理装置は、デバイス側メモリと、当該被遠隔管理装置の状態情報をデバイス側メモリ上で管理するデバイス側プロセッサと、状態情報を遠隔管理装置に送信するデバイス側通信装置と、を有する。また、遠隔管理装置は、被遠隔管理装置から状態情報を受信するサーバ側通信装置と、サーバ側メモリと、被遠隔管理装置ごとに、装置を特定する情報と、当該装置の状態を示す状態名及び状態値の情報と、被遠隔管理装置から遠隔管理装置への状態情報の再送信回数を示す情報と、を含む装置管理情報をサーバ側メモリ上で管理するサーバ側プロセッサと、を有している。そして、サーバ側プロセッサは、被遠隔管理装置から受信した状態情報と、サーバ側メモリ上で管理する装置管理情報とを比較し、被遠隔管理装置から受信した状態情報が装置管理情報に含まれるか否かを判定する第１の判定処理と、受信した状態情報の値が装置管理情報に含まれる状態情報の値に等しいか否か判定する第２の判定処理と、受信した状態情報に含まれる再送信回数が装置管理情報に含まれる再送信回数より１以上大きいか否か判定する第３の判定処理を、実行する。そして、第１乃至第３の判定処理の結果に基づいて、被遠隔管理装置から受信した状態情報を、新しい装置管理情報として登録する。

また、遠隔管理装置は、さらに、装置管理情報に含まれる情報として、被遠隔管理装置による状態情報の初回送信時刻を管理する。そして、遠隔管理装置は、被遠隔管理装置における状態情報の送信時刻と、状態情報の受信時刻と、再送信処理時の送信待機時間情報と、再送信回数を用いて、初回送信時刻を算出する。

本発明によれば、一度で通信が成功する場合だけでなくリトライ時であっても、デバイス情報を格納したＤＢを新しい状態に保ちながら、無駄な状態情報の登録処理を回避することができる。

なお、上述した以外の課題、構成及び効果は、以下の本発明を実施するための形態および添付図面によって明らかになるものである。

本発明の実施形態における管理システムの概略構成図である。 リトライ待機間隔テーブルの構成例を示す図である。 パラメタテーブルの構成例を示す図である。 デバイス管理テーブルの構成例を示す図である。 管理情報表示プログラムによって表示されるデバイス管理画面（情報収集リクエスト入力画面）の例を示す図である。 管理情報表示プログラムによって表示されるデバイス管理画面（結果表示画面）の例を示す図である。 管理情報表示用シーケンスを説明するための図である。 パラメタ情報送付の正常時シーケンスを説明するための図である。 パラメタ情報送付の一度目のサーバ側通信モジュールのレスポンス送付直前にエラーが発生し、次のリトライにより成功した場合のシーケンスを説明するための図である。 初回送信時刻算出処理を説明するためのフローチャートである。 デバイス管理モジュールによる二重登録防止処理を説明するためのフローチャートである。 デバイス管理モジュールがサーバ側通信モジュールから受信するデータの例であって、既登録と判断されるパラメタ例を示す図である。 デバイス管理モジュールがサーバ側通信モジュールから受信するデータの例であって、未登録と判断されるパラメタ例を示す図である。

以下、添付図面を参照して本発明の実施形態について説明する。ただし、本実施形態は本発明を実現するための一例に過ぎず、本発明の技術的範囲を限定するものではないことに注意すべきである。また、各図において共通の構成については同一の参照番号が付されている。

なお、以後の説明では「テーブル」（図２乃至４等）を用いて本発明で用いる情報について説明しているが、これら情報は必ずしもテーブルによるデータ構造で表現されていなくても良く、リスト、ＤＢ、キュー等のデータ構造やそれ以外で表現されていても良い。そのため、データ構造に依存しないことを示すために「テーブル」、「リスト」、「ＤＢ」、「キュー」等について単に「情報」と呼ぶこともある。

また、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いることが可能であり、これらについてはお互いに置換が可能である。

以後の説明では「プログラム」や「モジュール」を主語として説明を行う場合もあるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御装置）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。プログラムの一部または全ては専用ハードウェアで実現してもよく、また、モジュール化されていても良い。各種プログラムはプログラム配布サーバや記憶メディアによって各計算機にインストールされてもよい。

＜管理システムの構成＞
図１は、本発明の実施形態における管理システム１００の概略構成を示す図である。管理システム１００は、少なくとも１つの管理者端末装置１と、少なくとも１つの遠隔管理装置（遠隔管理計算機）２と、少なくとも１つの被遠隔管理装置（被管理デバイス）３と、を有しており、これらがネットワーク４（例えば、インターネット等のＷＡＮやＬＡＮ）を介して接続されている。当該管理システム１００において、被遠隔管理装置３の状態をサーバ側が監視して、その状態情報をサーバ側で検証することにより、非遠隔管理装置３の例えば補修の要否を判断する。被遠隔管理装置３は、例えば、電気自動車用の充電器が考えられるが、これに限られるものではなく、ネットワーク上で監視すべき装置であればどのような装置であっても対象となる。

管理者端末装置１は、ＣＰＵ１１Ａ及びメモリ１１Ｂを含む端末装置１１と、通信ポート１２と、外部記憶装置１３と、を有している。管理者端末装置１の外部記憶装置１３は、遠隔制御装置にアクセスし、取得した結果を管理者に提供するための管理情報表示プログラム１３Ａを格納している。この管理情報表示プログラム１３Ａは、例えばブラウザやＧＵＩコンソールなどである。

遠隔管理装置２は、ＣＰＵ２１Ａ及びメモリ２１Ｂを含む端末装置２１と、通信ポート２２と、外部記憶装置２３と、を有している。被遠隔管理装置２の外部記憶装置２３は、被遠隔管理装置３で実行されるリトライ処理のリトライ間隔を表すリトライ待機間隔テーブル２３Ｆと、被遠隔管理装置３の情報を管理するデバイス管理テーブル２３Ｅと、ＷＥＢアプリケーションの実行環境をサーバ側通信モジュール２３Ｂ、デバイス管理モジュール２３Ｃ及びＵＩ用モジュール２３Ｄに提供するＷＥＢアプリ制御プラットフォーム２３Ａと、被遠隔管理装置３との通信を行うサーバ側通信モジュール２３Ｂと、デバイス管理テーブル２３Ｅの管理を行うデバイス管理モジュール２３Ｃと、ユーザ（管理者）に対して被遠隔管理装置３の情報を表示するプログラム（管理情報表示プログラム１３Ａ）からのアクセスに対してデバイス管理テーブル２３Ｅの情報を返送するためのＵＩ用モジュール２３Ｄと、を格納している。ここで、ＷＥＢアプリ制御プログラム２３Ａは、例えば、ＪＢｏｓｓなどのＷＥＢコンテナとその動作環境であるＪａｖａ仮想マシンプログラムなどである。

被遠隔管理装置３は、ＣＰＵ３１Ａ及びメモリ３１Ｂを含む端末装置３１と、通信ポート３２と、外部記憶装置３３と、を有している。なお、被遠隔管理装置３は、図示しないカウンタを有し、リトライの回数をカウントしてその数値を管理している。被遠隔管理装置３の外部記憶装置３３は、リトライ間隔を表すリトライ待機間隔テーブル２３Ｆと、被遠隔管理装置の情報を管理するパラメタテーブル３３Ｄと、遠隔管理装置との通信を行うデバイス側通信バンドル（プログラム）３３Ｂと、パラメタテーブル３３Ｄの管理を行うデバイス管理エージェントバンドル（プログラム）３３Ｃと、バンドル（プログラム）の動作環境であるバンドル制御プログラム３３Ａと、を格納している。バンドル制御プログラム３３Ａは、例えば、ＯＳＧｉフレームワーク上で動作するソフトウェアやＪａｖａ仮想マシンプログラムなどである。

＜リトライ待機間隔テーブル＞
図２は、リトライ待機間隔テーブル２３Ｆの構成例を示す図である。リトライ待機間隔テーブル２３Ｆは、リトライ回数を表すリトライカウント２０１と、待機時間の最小間隔を表す最小待機間隔２０２と、待機時間の最大間隔を表す最大待機間隔２０３と、を構成項目として含んでいる。

リトライ間隔は、最小大気間隔２０２と最大待機間隔２０３の間の値が用いられ、用いる値はランダムに決定される。なお、最小待機間隔２０２と最大待機間隔２０３とが同一値であっても良く、また、リトライカウントが１以上のいずれの場合であっても、同一値をとっても良い。また、当該リトライ待機間隔テーブル２３Ｆは、遠隔管理装置２及び被遠隔管理装置３において同一のものが提供されている。ただし、非遠隔管理装置３では、リトライ待機間隔テーブル２３Ｆは、リトライ処理を実行するタイミングを決定するために用いられるのに対し、遠隔管理装置２では、後述のように、リトライ時に初回送信時刻を算出する際に用いられる。

＜パラメタテーブル＞
図３は、パラメタテーブル３３Ｄの構成例を示す図である。パラメタテーブル３３Ｄは、パラメタ名３０１と、パラメタ値３０２と、パラメタ型３０３と、を構成項目として含んでいる。

パラメタ名３０１は、状態を示すパラメタを識別するための情報である。また、パラメタ値３０２は、状態の値を示す情報である。例えば、当該パラメタ値としては、あるプログラムが動作していないときには「０」が設定され、動作中は「１」が設定されるようになっている。さらに、パラメタ型３０３は、パラメタのタイプを示す情報である。本実施形態では、ＪＡＶＡに基づくパラメタのタイプが示されている。

＜デバイス管理テーブル＞
図４は、デバイス管理テーブル２３Ｅの構成例を示す図である。デバイス管理テーブル２３Ｅは、デバイスＩＤ４０１と、パラメタ名４０２と、パラメタ値４０３と、パラメタ型４０４と、送信時刻４０６と、受信時刻４０７と、初回送信時刻４０８と、を構成項目として含んでいる。

デバイスＩＤ４０１は、管理対象となっている被遠隔管理装置３を特定するための情報である。パラメタ名４０２乃至パラメタ型４０４までの情報は当該被遠隔管理装置３の状態（発生したイベント）を示す情報であって、図３に示される情報と同じである。また、リトライカウント４０５は、被遠隔管理装置３から送信されてくる、リトライを何回実行しているかを示す情報である。

送信時刻４０６は、被遠隔管理装置３から状態に関する情報が送信された時刻である。リトライ処理で送られていない場合（初回送信時）は、当該送信時刻４０６は、イベント発生時刻を示している（全く同時ではないが、そのように見做しても問題ないという前提を当該実施形態は採っている）。一方、リトライ処理で送られている場合には、当該送信時刻４０６は、リトライ送信の時刻を示している。

受信時刻４０７は、被遠隔管理装置３から送信されてくる情報を遠隔管理装置２のサーバ側通信モジュール２３Ｂが受信する時刻を示している。よって、受信時刻４０７と送信時刻４０６の差は、ネットワーク４における送信時間（ネットワーク遅延）を示している。

初回送信時刻４０８は、最小初回送信時刻と最大初回送信時刻から構成される情報である。初回送信時刻４０８は、後述の図９により算出される時刻である。なお、リトライカウント値が「０」の場合、初回送信時刻４０８は送信時刻４０６と同じ値となっている。

＜デバイス管理画面＞
図５は、管理者端末装置１の管理情報表示プログラム１３Ａによって表示されるデバイス管理画面の構成例を示す図であり、図５Ａは情報収集リクエスト入力画面例を示し、図５Ｂは結果表示画面例を示している。

図５Ａにおいて、デバイスＩＤ入力欄５０１に、管理者が、管理対象の被遠隔管理装置３のデバイスＩＤを入力（指定）し、送信要求ボタン５０２を押下すると、情報収集リクエストが遠隔管理装置２に送信される。

遠隔管理装置２は、当該リクエストを受信すると、指定された被遠隔管理装置３の、収集した状態情報（イベント発生情報）を、図５Ｂに示されるように、例えば図４と同一の表示形式で、結果表示画面５１０として管理者端末装置１の表示装置に表示される。

＜管理情報表示シーケンス＞
図６は、管理情報表示シーケンスを説明するための図である。管理者から情報収集の指示（リクエスト）を受けると、管理情報表示プログラム１３Ａは、遠隔管理装置２のＵＩ用モジュール２３Ｄと通信を行い、ＵＩ用モジュール２３Ｄに対して、指定したデバイスのパラメタ（状態情報）の一覧取得を要求する（ステップ６０１）。

この要求を受信したＵＩ用モジュール２３Ｄは、デバイス管理モジュール２３Ｃに対して、デバイスＩＤを通知し、パラメタ一覧の取得を要求する（ステップ６０２）。

デバイス管理モジュール２３Ｃは、このデバイスＩＤを基に、デバイス管理テーブル２３Ｅからパラメタ一覧を取得し、これをＵＩ用モジュール２３Ｄに受け渡す（ステップ６０３）。

ＵＩ用モジュール２３Ｄは、取得したパラメタ一覧を基にＧＵＩ画面を作成し、管理情報表示プログラム１３Ａに送信する（ステップ６０４）。

＜正常時のシーケンス＞
図７は、パラメタ情報送信の正常時のシーケンスを説明するための図である。ここで正常時とは、リトライによる送信ではなく、初回送信時の処理であって、その送信が正常に終了した場合をいうものである。

デバイス管理エージェントバンドル３３Ｃは、デバイス側通信バンドル３３Ｂに対し、パラメタ情報送付命令を送る（ステップ７０１）。例えば、パラメタの値が変更されたときなどにこの命令送付が行われる。

命令送付が完了すると、デバイス側通信バンドル３３Ｂは、その戻り値（パラメタ情報送付命令を問題なく受信したか否かを示す値）をデバイス管理エージェントバンドル３３Ｃに返す（ステップ７０２）。この戻り値の返却については、後述のステップ７１１でデバイス側通信バンドル３３Ｂが、レスポンスを受信時直後であっても良い。

次に、デバイス側通信バンドル３３Ｂは、リトライカウントを初期値の０に設定する（ステップ７０３）。また、パラメタ（状態情報）を送信する直前に、被遠隔管理装置３上の時刻を取得し（ステップ７０４）、サーバ側通信モジュール２３Ｂに対してパラメタ情報を送付する（ステップ７０５）。

サーバ側通信モジュール２３Ｂは、パラメタ情報を受信した際、サーバ側通信モジュール２３Ｂ上の時刻を取得する（ステップ７０６）。そして、サーバ側通信モジュール２３Ｂは、被遠隔管理装置３から受信したパラメタ情報、リトライカウント、送信時刻、及びサーバ側通信モジュール２３Ｂで取得した受信時刻を、デバイス管理モジュール２３Ｃに対し送付する（ステップ７０７）。

デバイス管理モジュール２３Ｃは、受信したデータを基に初回送信時刻を算出する（ステップ７０８）。ここでの初回送信時刻は、リトライカウント値が「０」であるから、上記送信時刻に相当するものとなる。

デバイス管理モジュール２３Ｃは、受信したデータ及び初回送信時刻を、デバイス管理テーブル２３Ｅに登録する処理を行い（ステップ７０９）、サーバ側通信モジュール２３Ｂに対して、戻り値を返す（ステップ７１０）。この戻り値の意味は、上述したものと同様である。

サーバ側通信モジュール２３Ｂは、デバイス側通信バンドル３３Ｂに対して、パラメタ送信及び登録が成功したか否かを示すレスポンスを送信する（ステップ７１１）。

デバイス側通信バンドル３３Ｂは、空データをサーバ側通信モジュール２３Ｂに送信し（ステップ７１２）、サーバ側通信モジュール２３Ｂも空データをデバイス側通信バンドル３３Ｂに送信する（ステップ７１３）。なお、ステップ７１２及び７１３における空データ送受信処理は、ＴＲ−０６９で定められているプロトコルに従う処理である。このプロトコルには、それぞれ被遠隔管理装置３及び遠隔管理装置２に送信すべき命令が無い場合に、空のリクエストを投げるように規定されている。例えば、それぞれ遠隔管理装置２がサポートするＲＰＣ一覧を取得するためのGetRPCMethods、被遠隔管理装置３の指定のパラメタの値を設定するためのSetParameterValuesなどである。

空データを受信したデバイス側通信バンドル３３Ｂは、サーバ側通信モジュール２３Ｂとのコネクションを切断し、当該正常時シーケンスを終了する（ステップ７１４）。

＜リトライ実行時のシーケンス＞
図８は、リトライ実行時のシーケンス例を説明するための図である。図８では、パラメタ情報送付の一度目のサーバ側通信モジュールのレスポンス送付直前にエラーが発生し、次のリトライにより成功した場合を想定している。また、ステップ８０１からステップ８１０までは、図７のそれぞれステップ７０１からステップ７１０までと同一であるので説明を省略する。

ステップ８１０の直後にエラーが発生したので、サーバ側通信モジュール２３Ｂは、パラメタ送信及び登録に「失敗」したという情報を含んだレスポンスをデバイス側通信バンドル３３Ｂに送信する（ステップ８１１）。

デバイス側通信バンドル３３Ｂは、リトライカウントを１つ増加させ、リトライ待機間隔テーブル２３Ｆの該当するリトライカウントの時間だけ待機する。例えば、この場合、リトライ数が１で図２のリトライ待機間隔テーブルの場合、待機時間は、５から１０秒のうちランダムに定めたいずれかの時間となる。

待機間隔時間が過ぎた後のステップ８１４からステップ８２４まで処理は、図７のそれぞれステプ７０４からステップ７１４までの処理と同一であるので、説明を省略する。なお、図８のシーケンス例では、１回目のリトライ（２回目の送信時）でパラメタ情報の送信及び登録が成功しているため、ステップ８２３で終了しているが、失敗が連続すれば、同様のリトライ処理が継続されることになる。

＜初回送信時刻算出処理＞
図９は、初回送信時刻４０８を算出する初回送信時刻算出処理を説明するためのフローチャートである。従来、被遠隔管理装置（デバイス）３側の時刻情報として、送信開始時刻のみを遠隔管理装置（監視サーバ）２に通知しているため、リトライ発生時、初回の送信時刻を監視サーバ側で把握できない。このため、本発明の実施形態では、本発明固有の演算処理を実行することにより、初回送信時刻を算出するようにしている。

まず、デバイス管理モジュール２３Ｃは、リトライ待機間隔テーブル２３Ｆの最初のレコードを対象レコードに設定し（ステップ９０１）、待機時間に関する内部的な計算のための変数Twaitに０を設定する（ステップ９０２）。

次に、デバイス管理モジュール２３Ｃは、対象レコードのリトライ数が、受信したデータのリトライ数と一致しているか否か調べる（ステップ９０３）。対象レコードのリトライ数が、受信したデータのリトライ数と一致していない場合（ステップ９０３でＮＯの場合）、デバイス管理モジュール２３Ｃは、Twaitにリトライ待機間隔テーブル２３Ｆの該当レコードの最大値を加算し（ステップ９０３）、リトライ待機間隔テーブル２３Ｆで対象レコードを１進め（ステップ９０５）、ステップ９０３に戻る。

一方、対象レコードのリトライ数が受信したデータのリトライ数と一致している場合（ステップ９０３でＹＥＳの場合）、デバイス管理モジュール２３Ｃは、Tmin=送信時刻-Twait_max-(受信時刻-送信時刻)*リトライカウント*２により、初回送信時刻４０８の最小値（下限値）を計算する（ステップ９０６）。ここで、送信時刻はリトライ時においてはリトライ処理の送信時刻を示しており、Twait_maxはリトライ待機間隔の上限値を示している。また、（受信時刻−送信時刻）によりネットワーク遅延時間が得られる。さらに乗算される数値「２」は往復分を換算したものである。つまり、(受信時刻-送信時刻)*リトライカウント*２は、リトライ処理時に発生するリトライ回数分のネットワーク遅延時間を示している。

続いて、デバイス管理モジュール２３Ｃは、再度リトライ待機間隔テーブル２３Ｆの最初のレコードを対象レコードに設定し（ステップ９０７）、待機時間に関する内部的な計算のための変数Twaitに０を設定する（ステップ９０８）。

次に、デバイス管理モジュール２３Ｃは、対象レコードのリトライ数が、受信したデータのリトライ数と一致しているか否か調べる（ステップ９０９）。一致していない場合、デバイス管理モジュール２３Ｃは、Twaitにリトライ待機間隔テーブル２３Ｆの該当レコードの最小値を加算し（ステップ９１０）、リトライ待機間隔テーブルで対象レコードを１進め（ステップ９１１）、ステップ９０９に処理を戻す。

一方、一致している場合、デバイス管理モジュール２３Ｃは、Tmax=送信時刻-Twait_min-(受信時刻-送信時刻)*リトライカウント*２により、初回送信時刻４０８の最大値（上限値）を計算する（ステップ９１２）。ここで、Twait_minはリトライ待機間隔の下限値を示している。

＜二重登録防止処理＞
図１０は、デバイス管理モジュール２３Ｃによる二重登録防止処理を説明するためのフローチャートである。本発明では、被遠隔管理装置の状態情報のパラメタを遠隔管理装置に送信してＤＢ（データベース）に登録した後に発生するエラーによって生じるリトライ処理する場合に、ＤＢに登録済みのデータをさらに送信して二重登録すると、無駄な処理時間及び処理負荷が掛かってしまう。このため、最新のイベント発生（状態情報）を取得して登録する一方、全ての既登録情報と登録しようとする情報を比較するのではなく、所定の処理により二重登録か否かを判断して、状態情報の無駄な二重登録を防止している。

まず、デバイス管理モジュール２３Ｃは、リトライカウント値が１以上かどうか調べ（ステップ１００１）、1以上で無ければ、初めて受信するデータであるため、デバイス管理テーブルに登録する（ステップ１００７）。

リトライカウント値が１以上であれば、デバイス管理モジュール２３Ｃは、デバイス管理テーブル２３Ｅに登録済みか調べ（ステップ１００２）、未登録の場合（ステップ１００２でＮＯの場合）、ステップ１００７に処理を移行させる。なお、当該テーブルに登録済か否かは、デバイスＩＤとパラメタ名で検査屈して同一パラメタがあるかどうかで判断される。

登録済みの場合（ステップ１００２でＹＥＳの場合）、デバイス管理モジュール２３Ｃは、登録済みレコードのパラメタ値が処理対象データのパラメタ値と同一の値であるか調べ（ステップ１００３）、同一でなければ（ステップ１００３でＮＯの場合）、初めて受信するデータであるため、ステップ１００７に処理を移行させる。パラメタ値が同一か否かは、ステップ１００２で取得したデバイスＩＤのパラメタ値が同一かどうかによって判断される。

同一である場合（ステップ１００３でＹＥＳの場合）、デバイス管理モジュール２３Ｃは、登録済みのレコードのリトライカウントの方が１以上小さいか調べ（ステップ１００４）、小さくない場合、すなわち同一値もしくは大きな値の場合（ステップ１００４でＮＯの場合）は、初めて受信するデータであるため、ステップ１００７に処理を移行させる。ステップ１００４では、データベース（デバイス管理テーブル２３Ｅ）への登録は成功したが、リトライされる場合がある。つまり、戻り値を受信して送信成功となったが、その後何らかの理由によりエラーが起こった場合である。より具体的には、ステップ７１０と７１１の間でエラーが発生し、「失敗」がレスポンスとして返ってきた場合、デバイス側ではリトライすることがあり、そのような場合をステップ１００４では想定している。

１以上小さい場合（ステップ１００４でＹＥＳの場合）、デバイス管理モジュール２３Ｃは、登録済みレコードの初回送信時刻の最小値の方が、処理対象デーアの初回送信時刻の最小値より新しいか調査し（ステップ１００５）、より古い場合（ステップ１００５でＮＯの場合）、ステップ１００７に処理を移行させる。

同一または、新しい場合（ステップ１００５でＹＥＳの場合）、デバイス管理モジュール２３Ｃは、同一レコード（状態情報）がデバイス管理テーブル２３Ｅに既に登録済みと判断し（１００６）、何もせずに処理を終える。

＜パラメタ情報例＞
図１１は、デバイス管理モジュール２３Ｃがサーバ側通信モジュール２３Ｂから受信するデータと、算出した初回送信時刻の例を示す図である。図１１Ａは、デバイス管理テーブル２３Ｅに既登録と判断される例を示し、図１１Ｂは、デバイス管理テーブル２３Ｅに未登録と判断される例を示している。デバイス管理テーブル２３Ｅが図４の状態の場合に、デバイス管理モジュール２３Ｃが１１０１から１１０６のいずれかのデータを受信した場合について以下説明する。

まず、データ１１０１（図１１Ａ）は、図１０のステップ１００６にて、デバイス管理モジュール２３Ｃにより、デバイス管理テーブル２３Ｅに既登録と判断される例である。すなわち、受信したデータが１１０１の場合、ステップ１００１からステップ１００５がＹＥＳと判定され、既に登録済みと判断され（１００６）、何もせずに処理が終わる。

一方、データ１１０２から１１０６は、ステップ１００７にて、デバイス管理モジュールにより、デバイス管理テーブルに未登録と判断される例である。

受信したデータが１１０２の場合、リトライカウントが０であるため、初めて受信するデータであると分かり、ステップ１００１でＮＯと判定されて未登録と判断され、デバイス管理テーブル２３Ｅに登録が行われる。

受信したデータが１１０３の場合、ステップ１００１ではＹＥＳと判定されるが、ｐａｒａｍ３は、デバイス管理テーブル２３Ｅに未登録であり、ステップ１００２でＮＯと判定され、未登録と判断され、デバイス管理テーブル２３Ｅに登録が行われる。これは、リトライカウントが０から４までのパケットが送信された時点で、例えばサーバ側通信モジュール２３Ｂがまだ動作していなかったことなどが原因で、受信されず、リトライカウントが５の時点で初めて受信された場合などである。

受信したデータが１１０４の場合、ステップ１００１から１００２はＹＥＳと判定されるが、パラメタ値が登録済みのデータと異なり、ステップ１００３でＮＯと判定され、未登録と判断され、デバイス管理テーブル２３Ｅに登録が行われる。

受信したデータが１１０５の場合、ステップ１００１から１００３まではＹＥＳと判定されるが、登録済みレコードとリトライカウントが同一であり、ステップ１１０４でＮＯと判定され、未登録と判断され、デバイス管理テーブル２３Ｅに登録が行われる。

受信したデータが１１０６の場合、ステップ１１０１から１１０３まではＹＥＳと判定されるが、登録済みレコードの初回送信時刻の最小値より、処理対象レコードの初回送信時刻の最小値の方がより新しく、ステップ１１０５でＮＯと判定され、未登録と判断され、デバイス管理テーブル２３Ｅに登録が行われる。

なお、二重登録防止の目的を達成する場合には、図７のステップ７０８及び７０９と、図８のステップ８１８及び８１９と、図１０のステップ１００５における初回送信時刻に関する処理は、実行しなくても良い。

＜まとめ＞
本発明では、遠隔管理装置において、被遠隔管理装置から受信した状態情報と、サーバ側メモリ上で管理する装置管理情報（図４：デバイス管理テーブル）とを比較し、被遠隔管理装置から受信した状態情報がデバイス管理テーブルに含まれるか否かを判定し、次に、受信した状態情報の値が装置管理情報に含まれる状態情報の値に等しいか否か判定し、さらに、受信した状態情報に含まれる再送信回数（リトライカウント）がデバイス管理テーブルのリトライカウントより１以上大きいか否か判定し、これらの結果に基づいて、受信した状態情報を、新しい装置管理情報としてデバイス管理テーブルに登録するか判断する。より具体的には、被遠隔管理装置から受信した状態情報がデバイス管理テーブルに含まれ、かつ、受信した状態情報の値がデバイス管理テーブルに含まれる状態情報の値に等しく、かつ、受信した状態情報に含まれるリトライカウトがデバイス管理テーブルのリトライカウントより１以上大きいと判断した場合、受信した状態情報が既に登録済みであると判断して同一情報の登録を排除する。このようにすることにより、デバイス管理テーブルの情報を新しい状態に保ちながら、無駄な登録（二重登録）処理を回避可能である。デバイス管理テーブルは通常ハードディスクドライブ（ＨＤＤ）に格納されているため、ＨＤＤへの無駄な格納処理を回避することができる。

さらに、デバイス管理テーブルでは、被遠隔管理装置による状態情報の初回送信時刻を管理する。リトライ処理がない場合には、当該テーブル上では、被遠隔管理装置からの状態情報の送信時刻は初回送信時刻に等しいが、リトライ処理時はリトライ送信時刻となるため、初回送信時刻を管理できない。そこで、遠隔管理装置では、被遠隔管理装置における状態情報の送信時刻と、状態情報の受信時刻と、再送信処理時の送信待機時間情報と、再送信回数を用いて、初回送信時刻算出する。このようにすることにより、一度で通信が成功する場合だけでなくリトライ時であっても、通信データ量を抑えながら、おおよそのイベント発生時刻をサーバ側で把握可能となる。

なお、本発明は、実施形態そのままに限定されるものではなく、実施段階では、その要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。

また、実施形態で示された各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。また、上記各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能等を実現するプログラム、テーブル、ファイル等の情報は、メモリやハードディスク、ＳＳＤ（Solid State Drive）等の記録或いは記憶装置、またはＩＣカード、ＳＤカード、ＤＶＤ等の記録或いは記憶媒体に格納することができる。

さらに、上述の実施形態において、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。全ての構成が相互に接続されていても良い。

１・・・管理者端末装置
１１Ａ、２１Ａ、３１Ａ・・・ＣＰＵ
１１Ｂ、２１Ｂ、３１Ｂ・・・メモリ
１３、２３、３３・・・外部記憶装置
２・・・遠隔管理装置
３・・・被遠隔管理装置
４・・・インターネット
１３Ａ・・・管理情報表示プログラム
２３Ａ・・・Ｗｅｂアプリ制御プログラム
２３Ｂ・・・サーバ側通信モジュール
２３Ｃ・・・デバイス管理モジュール
２３Ｄ・・・ＵＩ用モジュール
２３Ｅ・・・デバイス管理テーブル
２３Ｆ・・・リトライ間隔テーブル
３３Ａ・・・バンドル制御プログラム
３３Ｂ・・・デバイス側通信モジュール
３３Ｃ・・・デバイス管理エージェントバンドル
３３Ｄ・・・パラメタテーブル
１００・・・管理システム

Claims (11)

1. 少なくとも１つの被遠隔管理装置と、ＣＷＭＰプロトコルを用いて当該被遠隔管理装置とネットワークを介して通信し、前記被遠隔管理装置を管理する遠隔管理装置と、を有する管理システムであって、
   前記被遠隔管理装置は、デバイス側メモリと、当該被遠隔管理装置の状態情報を前記デバイス側メモリ上で管理するデバイス側プロセッサと、前記状態情報を前記遠隔管理装置に送信するデバイス側通信装置と、を有し、
   前記遠隔管理装置は、前記被遠隔管理装置から前記状態情報を受信するサーバ側通信装置と、サーバ側メモリと、被遠隔管理装置ごとに、装置を特定する情報と、当該装置の状態を示す状態名及び状態値の情報と、前記被遠隔管理装置から前記遠隔管理装置への状態情報の再送信回数を示す情報と、を含む装置管理情報を前記サーバ側メモリ上で管理するサーバ側プロセッサと、を有し、
   前記サーバ側プロセッサは、前記被遠隔管理装置から受信した状態情報と、前記サーバ側メモリ上で管理する前記装置管理情報とを比較し、前記被遠隔管理装置から受信した前記状態情報が前記装置管理情報に含まれるか否かを判定する第１の判定処理と、前記受信した状態情報の値が前記装置管理情報に含まれる状態情報の値に等しいか否か判定する第２の判定処理と、前記受信した状態情報に含まれる再送信回数が前記装置管理情報に含まれる再送信回数より１以上大きいか否か判定する第３の判定処理を実行し、前記第１乃至第３の判定処理の結果に基づいて、前記受信した状態情報を、新しい装置管理情報として登録することを特徴とする管理システム。
2. 請求項１の管理システムであって、
   前記サーバ側プロセッサは、前記第１乃至第３の判定処理の結果、前記被遠隔管理装置から受信した前記状態情報が前記装置管理情報に含まれ、かつ、前記受信した状態情報の値が前記装置管理情報に含まれる状態情報の値に等しく、かつ、前記受信した状態情報に含まれる再送信回数が前記装置管理情報に含まれる再送信回数より１以上大きいと判断した場合、前記受信した状態情報が既に登録済みであると判断して同一情報の登録を排除することを特徴とする管理システム。
3. 請求項１の管理システムであって、
   前記サーバ側プロセッサは、さらに、前記装置管理情報に含まれる情報として、前記被遠隔管理装置による前記状態情報の初回送信時刻を管理し、
   前記サーバ側プロセッサは、前記被遠隔管理装置における前記状態情報の送信時刻と、前記状態情報の受信時刻と、再送信処理時の送信待機時間情報と、前記再送信回数を用いて、前記初回送信時刻を算出することを特徴とする管理システム。
4. 請求項３の管理システムであって、
   前記送信待機時間情報は、待機すべき時間の下限値と上限値を、再送信回数ごとに有しており、
   前記サーバ側プロセッサは、前記待機すべき時間の下限値と上限値を用いて、前記初回送信時刻の下限値及び上限値を算出することを特徴とする管理システム。
5. 請求項１の管理システムであって、
   さらに、前記遠隔管理装置から前記装置管理情報を取得し、当該装置管理情報を管理結果として表示画面に表示する管理者端末装置を有することを特徴とする管理システム。
6. 少なくとも１つの被遠隔管理装置と、ＣＷＭＰプロトコルを用いて当該被遠隔管理装置とネットワークを介して通信し、前記被遠隔管理装置を管理する遠隔管理装置と、を有する管理システムにおけるデバイス管理方法であって、
   前記被遠隔管理装置は、
   当該被遠隔管理装置の状態情報をデバイス側メモリ上で管理し、
   前記状態情報を前記遠隔管理装置に送信し、
   前記遠隔管理装置は、
   前記被遠隔管理装置から前記状態情報を受信し、
   被遠隔管理装置ごとに、装置を特定する情報と、当該装置の状態を示す状態名及び状態値の情報と、前記被遠隔管理装置から前記遠隔管理装置への状態情報の再送信回数を示す情報と、を含む装置管理情報をサーバ側メモリ上で管理し、
   前記被遠隔管理装置から受信した状態情報と、前記サーバ側メモリ上で管理する前記装置管理情報とを比較し、
   前記被遠隔管理装置から受信した前記状態情報が前記装置管理情報に含まれるか否かを判定する第１の判定処理と、前記受信した状態情報の値が前記装置管理情報に含まれる状態情報の値に等しいか否か判定する第２の判定処理と、前記受信した状態情報に含まれる再送信回数が前記装置管理情報に含まれる再送信回数より１以上大きいか否か判定する第３の判定処理を、実行し、前記第１乃至第３の判定処理の結果に基づいて、前記受信した状態情報を、新しい装置管理情報として登録する、ことを特徴とするデバイス管理方法。
7. 請求項６のデバイス管理方法であって、
   前記遠隔管理装置は、前記第１乃至第３の判定処理の結果、前記被遠隔管理装置から受信した前記状態情報が前記装置管理情報に含まれ、かつ、前記受信した状態情報の値が前記装置管理情報に含まれる状態情報の値に等しく、かつ、前記受信した状態情報に含まれる再送信回数が前記装置管理情報に含まれる再送信回数より１以上大きいと判断した場合、前記受信した状態情報が既に登録済みであると判断して同一情報の登録を排除することを特徴とするデバイス管理方法。
8. 請求項６のデバイス管理方法であって、
   前記遠隔管理装置は、さらに、
   前記装置管理情報に含まれる情報として、前記被遠隔管理装置による前記状態情報の初回送信時刻を管理し、
   前記被遠隔管理装置における前記状態情報の送信時刻と、前記状態情報の受信時刻と、再送信処理時の送信待機時間情報と、前記再送信回数を用いて、前記初回送信時刻を算出することを特徴とするデバイス管理方法。
9. 請求項８のデバイス管理方法であって、
   前記送信待機時間情報は、待機すべき時間の下限値と上限値を、再送信回数ごとに有しており、
   前記遠隔管理装置は、前記待機すべき時間の下限値と上限値を用いて、前記初回送信時刻の下限値及び上限値を算出することを特徴とするデバイス管理方法。
10. 請求項６のデバイス管理方法であって、
    さらに、前記管理システムに含まれる管理者端末装置が、前記遠隔管理装置から前記装置管理情報を取得し、当該装置管理情報を管理結果として表示画面に表示することを特徴とするデバイス管理方法。
11. ＣＷＭＰプロトコルを用いて、少なくとも１つの被遠隔管理装置と、ネットワークを介して通信し、前記被遠隔管理装置を管理する遠隔管理装置であって、
    前記被遠隔管理装置から、前記被遠隔管理装置の状態情報を受信する通信装置と、
    メモリと、
    被遠隔管理装置ごとに、装置を特定する情報と、当該装置の状態を示す状態名及び状態値の情報と、前記被遠隔管理装置から前記遠隔管理装置への状態情報の再送信回数を示す情報と、を含む装置管理情報を前記メモリ上で管理するプロセッサと、を有し、
    前記プロセッサは、前記被遠隔管理装置から受信した状態情報と、前記メモリ上で管理する前記装置管理情報とを比較し、前記被遠隔管理装置から受信した前記状態情報が前記装置管理情報に含まれるか否かを判定する第１の判定処理と、前記受信した状態情報の値が前記装置管理情報に含まれる状態情報の値に等しいか否か判定する第２の判定処理と、前記受信した状態情報に含まれる再送信回数が前記装置管理情報に含まれる再送信回数より１以上大きいか否か判定する第３の判定処理を、実行し、前記第１乃至第３の判定処理の結果に基づいて、前記受信した状態情報を、新しい装置管理情報として登録することを特徴とする遠隔管理装置。

Images