JP2017062547A - デバイス管理装置、デバイス監視システムおよびデバイス管理プログラム - Google Patents

Abstract

【課題】監視対象のデバイスに関する情報収集の迅速性を高める。【解決手段】監視対象のデバイスに関するデバイス情報を取得するデバイス管理装置であって、デバイスからデバイス情報を取得し、当該取得したデバイス情報を外部のサーバーへ送信する制御部を有し、制御部は、デバイス情報の取得のタイミングとして予め指定された取得予定時刻にデバイス管理装置がスリープ状態でない場合、取得予定時刻にデバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングでサーバーへ送信し、取得予定時刻よりも後にデバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始したデバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングでサーバーへ送信する。【選択図】図３

Description

本発明は、デバイス管理装置、デバイス監視システムおよびデバイス管理プログラムに関する。

状態の監視対象となるプリンターに関する情報をネットワークを通じてサーバーが収集することで複数のプリンターを監視するシステムが存在する。このようなシステムにおいては、プリンターに関する情報を、例えば１日に１回、決められたタイミング（取得予定時刻）に取得し、当該取得した情報を前記サーバーへアップロードする管理装置が存在する。
特許文献１には、画像形成装置と、画像形成装置からの情報を収集し監視ホストに対して送信を行う監視装置と、が互いに通信回線を介して接続されたシステムが記載されている。

特開２００７‐１５６６１０号公報

プリンターのユーザーは、上述した取得予定時刻を任意に設定可能であるが、多くのユーザーが同じような時刻を取得予定時刻として設定することがある。情報取得の頻度が１日に１回であれば、多くのユーザーが、例えば午前の就業が終わる正午といった判り易い時刻を取得予定時刻として設定することがある。このような場合、数多くのプリンター（数百台、数千台、あるいはそれ以上の台数のプリンター）に関する情報がアップロードされるサーバーにおいては、各管理装置からの情報のアップロードが１日のある時間帯（例えば正午をやや過ぎた時刻）に集中し易く、その結果、一時的に処理負担が急激に増加してしまうことがあった。

このようなサーバー側の一時的な処理負担の増大を避けるために、各管理装置では、プリンターに関する情報を取得してから当該情報をサーバーへアップロードするまでの間に当該アップロードを待機する待機時間を設けるようした。当該待機時間を管理装置がそれぞれ任意に設けることで、各管理装置からサーバーへの通信の集中が緩和される。

ここで、管理装置は、自身に対する操作が一定時間以上無い場合等に、いわゆるスリープ状態へ移行して消費電力をセーブする。管理装置は、スリープ状態にあっては、プリンターに関する情報の取得を実行しないし、また、上述の待機時間の経過のカウントを停止する。そのため、上述の待機時間を設ける運用を採用した場合、各管理装置がスリープ状態へ移行し得ることと関係して、プリンターに関する情報がサーバーへアップロードされるまでにかなり長い時間を要することがあった。

本発明は上述の課題に鑑みてなされたものであり、監視対象のデバイスに関する情報の迅速な収集に寄与するデバイス管理装置、デバイス監視システムおよびデバイス管理プログラムを提供する。

本発明の態様の１つは、監視対象のデバイスに関するデバイス情報を取得するデバイス管理装置であって、前記デバイスから前記デバイス情報を取得し、当該取得したデバイス情報を外部のサーバーへ送信する制御部を有し、前記制御部は、前記デバイス情報の取得のタイミングとして予め指定された取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、当該取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信し、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信する。

当該構成によれば、デバイス管理装置は、取得予定時刻にスリープ状態であった場合、スリープ状態からの復帰後、デバイス情報を取得し、第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングでデバイス情報をサーバーへ送信（アップロード）する。これにより、デバイス管理装置は、スリープ状態からの復帰後、取得した情報のサーバーへの送信をいたずらに長い時間待機する、といった状況を避けることができる。

本発明の態様の１つは、前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該取得後、待機することなく前記サーバーへ送信するとしてもよい。
当該構成によれば、デバイス管理装置は、スリープ状態からの復帰後、取得した情報のサーバーへの送信を即座に実行することができる。

本発明の態様の１つは、前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、前記取得予定時刻から当該復帰までに要した時間に応じて前記第２の上限時間を決定するとしてもよい。
当該構成によれば、取得予定時刻からスリープ状態の復帰までに要した時間を考慮して第２の上限時間を決定することで、スリープ状態からの復帰後、取得した情報のサーバーへの送信をいたずらに長い時間待機する、といった状況を避けることができる。

本発明の態様の１つは、前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第２の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで前記サーバーへ送信するとしてもよい。
また、前記制御部は、前記取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、前記取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで前記サーバーへ送信するとしてもよい。
これら構成によれば、デバイス管理装置がサーバーへ情報を送信するタイミングを、複数のデバイス管理装置間で分散させることができる。

本発明の態様の１つは、前記制御部は、前記デバイス情報を取得してから当該取得したデバイス情報を前記サーバーへ送信するタイミングになるまでの当該送信の待機中に前記デバイス管理装置がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からの前記デバイス管理装置の復帰後、待機することなく前記サーバーへ前記デバイス情報を送信するとしてもよい。
当該構成によれば、デバイス管理装置は、前記待機中に移行したスリープ状態からの復帰後、サーバーへの情報送信を即座に実行することができる。

本発明の態様の１つは、前記制御部は、前記デバイス情報を取得してから当該取得したデバイス情報を前記サーバーへ送信するタイミングになるまでの当該送信の待機中に前記デバイス管理装置がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からの前記デバイス管理装置の復帰後、当該送信の待機中に移行したスリープ状態の長さに応じて、前記サーバーへ前記デバイス情報を送信するまでに待機する残りの時間を調整するとしてもよい。
当該構成によれば、デバイス管理装置は、前記待機中に移行したスリープ状態からの復帰後、サーバーへの情報送信をいたずらに長い時間待機する、といった状況を避けることができる。

本発明の技術的思想は、デバイス管理装置という物以外によっても実現され、例えば、デバイス管理装置が実行する処理を方法の発明を捉えることも可能である。また、このような方法をハードウェア（例えば、デバイス管理装置としてのコンピューター）に実行させるプログラム（監視対象のデバイスに関するデバイス情報を取得する処理をデバイス管理装置に実行させるデバイス管理プログラム）を発明として捉えることも可能である。また、当該プログラムを記憶したコンピューター読取可能な記憶媒体等を発明として捉えることができる。
さらに、デバイス管理装置と当該デバイス管理装置から情報の送信を受けるサーバーとを含むデバイス監視システムを発明として捉えることも可能である。

デバイス監視システムを例示する図。 デバイス情報取得送信処理の基本的な流れを示す図。 デバイス情報取得送信処理の一例を示すフローチャート。 デバイス情報取得送信処理の他の例を示すフローチャート。 待機処理の一例を示すフローチャート。 待機処理の他の例を示すフローチャート。

以下では、各図面を参照しながら本発明の実施形態を説明する。
図１は、本実施形態にかかるデバイス監視システム（以下、システム）１０を例示している。システム１０は、監視サーバー２０と、複数台のデバイス管理装置３０とを含む。監視サーバー２０と各デバイス管理装置３０とは、ネットワークＮＷ１を介して互いに通信可能である。ネットワークＮＷ１は、例えばインターネットである。本実施形態における通信は、有線／無線を問わない。

デバイス管理装置３０は、自己が担当する１台以上の監視対象のデバイス４０と通信可能に接続しており、デバイス４０に関するデバイス情報をデバイス４０から取得する。監視サーバー２０は、デバイス管理装置３０がそれぞれ取得したデバイス情報の送信（アップロード）をデバイス管理装置３０から受ける。これにより、監視サーバー２０は、複数のデバイス４０のデバイス情報を収集することができる。監視サーバー２０は、このように収集したデバイス４０毎のデバイス情報を内外のデータベース（ＤＢ）２１に記録する。

デバイス管理装置３０は、ＣＰＵやメモリー等を有するＩＣ等で構成された制御部３１を有する。制御部３１は、アプリケーションＡＰを搭載しており、アプリケーションＡＰに従ってデバイス情報取得送信処理を実行する。デバイス情報取得送信処理とは、概略的には、デバイス４０のデバイス情報を取得し、当該取得したデバイス情報を監視サーバー２０へアップロードする処理を指す。デバイス情報取得送信処理の詳細は、図２〜６に基づいて説明する。アプリケーションＡＰは、デバイス管理プログラムの一例である。

デバイス４０は、監視対象（デバイス情報の収集対象）となり得るあらゆるデバイスを指す。一例として、デバイス４０はプリンターである。プリンターとは、プリンターとしての機能を少なくとも有する機器を指す。従って、プリンターとしての機能に加えて、スキャナーやファクシミリ等の複数の機能を併せ持つ複合機もここではプリンターと呼ぶ。本発明が想定する監視対象のデバイスには、プリンターではない電子機器、家電製品も該当するが、以下ではデバイス４０がプリンターである場合を例に説明を行う。

デバイス４０がプリンターである場合、デバイス管理装置３０がデバイス４０から取得するデバイス情報には、例えば、プリンターにおける消耗品の情報が含まれる。消耗品の情報とは、インクやトナーの残量、印刷枚数の情報、等である。このようなデバイス４０毎の消耗品の情報が監視サーバー２０へアップロードされることで、監視サーバー２０を管理する立場の者（システム１０の管理者）は、デバイス４０毎の消耗品の使用状況を把握したり、この使用状況に応じたデバイス４０のユーザーへの課金を行なったりすることができる。また、デバイス情報には、デバイスの故障や不具合に関する情報が含まれるとしてもよい。このようなデバイス情報が監視サーバー２０へアップロードされることで、監視サーバー２０を管理する立場の者は、デバイス４０毎の修理の必要性等を判断することができる。

図１の例では、ネットワークＮＷ１に接続してシステム１０に参加する複数のデバイス管理装置３０のうちの１つであるデバイス管理装置３０ａは、複数のデバイス４０（４０ａ，４０ｂ，４０ｃ…）とネットワークＮＷ２を介して通信可能である。デバイス管理装置３０ａは、アプリケーションＡＰに従ってデバイス情報取得送信処理を実行することにより、自己が担当するデバイス４０として登録済みの複数のデバイス４０ａ，４０ｂ，４０ｃ…の各々からデバイス情報を取得し、これら取得したデバイス情報を監視サーバー２０へアップロードする。例えば、ネットワークＮＷ２は、ある企業Ａ内に構築されたＬＡＮ（Local Area Network）であり、デバイス管理装置３０ａは、当該企業Ａ内に設置されたＰＣである。

また図１の例では、ネットワークＮＷ１に接続してシステム１０に参加するデバイス４０（４０ｉ，４０ｊ…）のそれぞれは、自身がデバイス管理装置３０としても振る舞う。つまり、デバイス４０ｉ，４０ｊ…では、それぞれが有する制御部３１が、デバイス本来の挙動（デバイスがプリンターであれば、プリンターとしての挙動）を制御するとともに、アプリケーションＡＰに従ってデバイス情報取得送信処理も実行する。デバイス４０ｉ，４０ｊ…は、例えば、ある企業Ｂ内に設置されたプリンターである。デバイス４０ｉは、デバイス管理装置３０としても振る舞うことで、デバイス４０ｉつまり自身のデバイス情報を装置内で取得し、監視サーバー２０へアップロードする。同様に、デバイス４０ｊは、デバイス管理装置３０としても振る舞うことで、デバイス４０ｊつまり自身のデバイス情報を装置内で取得し、監視サーバー２０へアップロードする。このように、デバイス管理装置３０は、デバイス４０とは異なる装置であってもよいし、デバイス４０内の１つの機能として存在してもよい。むろん、システム１０に参加するデバイス管理装置３０やデバイス４０の数は、図１に示したものよりも多く、例えば、デバイス４０は、数百台、数千台、あるいはそれ以上の台数が存在する。

図２は、デバイス情報取得送信処理の基本的な流れを時間の経過に沿って示している。制御部３１は、デバイス情報の取得のタイミングとして予め指定された取得予定時刻Ｔ１に、デバイス情報の取得を開始する。つまり、制御部３１は、デバイス情報の取得元となるデバイス４０との通信（例えば、ネットワークＮＷ２を介した通信、あるいは、デバイス４０の装置内での通信）を開始し、所定のネゴシエーションによりデバイス４０のデバイス情報を取得する。

取得予定時刻Ｔ１は、デバイス４０やデバイス管理装置３０のユーザーが、デバイス管理装置３０毎に任意に決めることができる。あるユーザーは、例えば毎日の正午を取得予定時刻Ｔ１としてデバイス管理装置３０に設定する。むろん、デバイス情報をデバイス４０から取得する頻度は１日１回より多くてもよい。あるいは、当該頻度は、２日に１回、あるいは３日に１回といったものであってもよい。デバイス情報の取得に要する時間ＴＡはかなり短く、例えば、１秒未満あるいは１，２秒程度である。従って、取得予定時刻Ｔ１の数秒後には、デバイス情報の取得は完了している。

制御部３１は、デバイス情報の取得後（取得予定時刻Ｔ１から時間ＴＡの経過後）、待機時間ＴＤを設定し、当該設定した待機時間ＴＤを経てから、当該取得したデバイス情報の送信（監視サーバー２０へのアップロード）を実行する。制御部３１は、このような待機時間ＴＤを、ある上限時間（第１の上限時間）内で毎回ランダムに設定する。例えば、第１の上限時間は３０分であるとする。第１の上限時間の設定は、基本的に各デバイス管理装置３０に共通である。このとき、制御部３１は、乱数を発生させることにより０〜３０に含まれるいずれかの整数を選択し、当該選択した数に該当する時間（０分〜３０分に含まれるいずれかの分数）を、待機時間ＴＤとして設定する。仮に、待機時間ＴＤ＝０分と設定した場合は、制御部３１は、実質的に待機せず、つまりデバイス情報の取得後、即座にデバイス情報のアップロードを実行する。また、制御部３１は、待機時間ＴＤ＝１５分と設定した場合は、デバイス情報の取得後１５分待機してからデバイス情報のアップロードを実行し、待機時間ＴＤ＝３０分と設定した場合は、デバイス情報の取得後３０分待機してからデバイス情報のアップロードを実行する。制御部３１は、上限時間内で待機時間ＴＤを分単位ではなく秒単位で設定してもよい。

このように制御部３１は、取得予定時刻Ｔ１にデバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングで監視サーバー２０へ送信する。つまり、仮に取得予定時刻Ｔ１の設定が多くのデバイス管理装置３０間で一致していたとしても、デバイス管理装置３０（制御部３１）が各々ランダムに設定した待機時間ＴＤの経過後にデバイス情報のアップロードを実行するため、各デバイス管理装置３０からの当該アップロードのタイミングの重なりが緩和される。これにより、当該アップロードが集中して監視サーバー２０の処理負担が一時的に増大する事態を避けることができる。

デバイス管理装置３０は、自身に対する操作が一定時間以上無い場合等に、いわゆるスリープ状態へ移行して消費電力をセーブする。スリープ状態は、省電力モード、節電モード、スタンバイモード等とも称される。デバイス管理装置３０は、スリープ状態においては、ＣＰＵのクロック周波数を低下させたり、装置内の各構成への電力供給を停止させたりして、有する機能の殆どを停止させている。スリープ状態では、デバイス管理装置３０はデバイス情報取得送信処理を実行することができない。

スリープ状態に対して、機能の制限や消費電力の低減をしていない装置の状態を、通常状態と称する。スリープ状態である装置は、知られているように、ユーザーによる操作を検知したり他の装置からの通信を検知した場合に、通常状態へ復帰する。なお、デバイス４０ｉ，４０ｊ…のように、デバイス管理装置３０にも該当する装置の場合は、デバイス４０がスリープ状態であればデバイス管理装置３０もスリープ状態であり、デバイス４０が通常状態であればデバイス管理装置３０も通常状態である。

以下に説明するように、本実施形態では、図２を用いて説明したデバイス情報取得送信処理に対して、デバイス管理装置３０のスリープ状態を考慮した処理を組み合わせることにより、さらなる効果を奏するようにした。

図３は、制御部３１がアプリケーションＡＰに従って実行するデバイス情報取得送信処理の一例を示すフローチャートである。当該フローチャートは、制御部３１が、デバイス情報の取得を開始した時に始まる。つまりステップＳ１００では、制御部３１は、デバイス情報の取得元となるデバイス４０との通信により、当該デバイス４０のデバイス情報を取得する。

ステップＳ１１０では、制御部３１は、直近の復帰時刻と上述の取得予定時刻Ｔ１とを比較する。直近の復帰時刻とは、デバイス管理装置３０が直近のスリープ状態から通常状態へ復帰した時刻である。
そして、ステップＳ１２０では、制御部３１は、前記比較の結果、直近の復帰時刻が取得予定時刻Ｔ１よりも早ければ、ステップＳ１３０へ進み、直近の復帰時刻が取得予定時刻Ｔ１よりも遅ければ、ステップＳ１５０へ進む。

直近の復帰時刻が取得予定時刻Ｔ１よりも早いということは、取得予定時刻Ｔ１の時点でデバイス管理装置３０は通常状態であったということになる。その場合、制御部３１は、予定通りの時刻、つまり取得予定時刻Ｔ１にデバイス情報の取得を開始した（当該フローチャートを開始した）ことになる。
一方、直近の復帰時刻が取得予定時刻Ｔ１よりも遅いということは、取得予定時刻Ｔ１の時点でデバイス管理装置３０はスリープ状態であったということになる。その場合、制御部３１は、スリープ状態から復帰したときに、現在の時刻が取得予定時刻Ｔ１を過ぎてしまっているため、即座にデバイス情報の取得を開始すべきと判断し、デバイス情報の取得を開始した（当該フローチャートを開始した）ことになる。

ステップＳ１３０では、制御部３１は、待機時間ＴＤを上限時間（第１の上限時間）内でランダムに設定する。
そして、ステップＳ１４０では、制御部３１は、ステップＳ１３０で設定した待機時間ＴＤが経過するまで待機（待機処理）した上で、ステップＳ１５０へ進む。
ステップＳ１５０では、制御部３１は、ステップＳ１００で取得済みのデバイス情報を監視サーバー２０へアップロードし、当該フローチャートを終える。

図４は、制御部３１がアプリケーションＡＰに従って実行するデバイス情報取得送信処理を示すフローチャートであって、図３とは異なる例を示している。図４は、ステップＳ１２０で直近の復帰時刻が取得予定時刻Ｔ１よりも遅いと判定したとき（ステップＳ１２０において“Ｎｏ”）ステップＳ１２５へ進む点で、図３と異なる。

ステップＳ１２５では、制御部３１は、前記上限時間を、取得予定時刻Ｔ１から通常状態への復帰までに要した時間（取得予定時刻Ｔ１から前記直近の復帰時刻までに要した時間、以下、第１のスリープ時間と呼ぶ。）に応じて調整する。例えば、制御部３１は、第１の上限時間から第１のスリープ時間を差し引いた残りの時間を第２の上限時間に決定し、この第２の上限時間を調整後の上限時間として採用する。例えば、第１の上限時間が３０分であり、第１のスリープ時間が１４分であれば、第２の上限時間は１６分となる。制御部３１は、第１の上限時間から第１のスリープ時間を差し引いた結果が０またはマイナスであれば、第２の上限時間は０と決定する。

ステップＳ１２５を経て実行するステップＳ１３０では、制御部３１は、待機時間ＴＤを、前記調整後の上限時間つまり第２の上限時間内でランダムに設定する。例えば、第２の上限時間は１６分であるとする。このとき、制御部３１は、乱数を発生させることにより０〜１６に含まれるいずれかの整数を選択し、当該選択した数に該当する時間（０分〜１６分に含まれるいずれかの分数）を、待機時間ＴＤとして設定する。ステップＳ１２５で第２の上限時間が０と決定されていれば、ステップＳ１３０で設定する待機時間ＴＤは０分である。待機時間ＴＤが０分であればステップＳ１４０は実質的に実行されない。このように制御部３１は、ステップＳ１２０において“Ｙｅｓ”の判定をしてステップＳ１３０へ進んだ場合には、前記上限時間として第１の上限時間を採用して待機時間ＴＤを設定し、一方、ステップＳ１２５を経てステップＳ１３０へ進んだ場合には、前記上限時間として第１の上限時間よりも短い第２の上限時間を採用して待機時間ＴＤを設定する。

このように図３，４のいずれの例においても、制御部３１は、取得予定時刻Ｔ１にデバイス管理装置３０がスリープ状態でない場合（ステップＳ１２０において“Ｙｅｓ”）、取得予定時刻Ｔ１にデバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得（ステップＳ１００）から第１の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで監視サーバー２０へアップロードする。これにより、各デバイス管理装置３０からの当該アップロードのタイミングの重なりが緩和される。

また、図３，４のいずれの例においても、制御部３１は、取得予定時刻Ｔ１よりも後にデバイス管理装置３０がスリープ状態から復帰した場合（ステップＳ１２０において“Ｎｏ”）、当該復帰して開始したデバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得（ステップＳ１００）から第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングで監視サーバー２０へアップロードする。具体的には、図３の例によれば、制御部３１は、取得予定時刻Ｔ１よりも後にデバイス管理装置３０がスリープ状態から復帰した場合、当該復帰して開始したデバイス情報の取得により得たデバイス情報を、当該取得後、待機することなく（つまりステップＳ１３０，Ｓ１４０を経ることなく）監視サーバー２０へ送信する。これにより、デバイス管理装置３０が取得予定時刻Ｔ１よりも後にスリープ状態から復帰したときには、当該復帰後、可能な限り早くデバイス情報を監視サーバー２０へ届けることができる。

なお、デバイス管理装置３０がスリープ状態へ移行するタイミングおよび通常状態へ復帰するタイミングは、デバイス管理装置３０毎の使用状況に依存しており、デバイス管理装置３０間では全く関連性はない。そのため、取得予定時刻Ｔ１よりも後にスリープ状態から復帰したタイミングでデバイス情報を取得した場合には、制御部３１は、その後にランダムな待機時間ＴＤの設定を行わずとも、デバイス情報のアップロードのタイミングを他のデバイス管理装置３０とずらす効果をほぼ奏することができると言える。

一方、図４の例によれば、制御部３１は、取得予定時刻Ｔ１よりも後にデバイス管理装置３０がスリープ状態から復帰した場合、取得予定時刻Ｔ１から当該復帰までに要した時間（第１のスリープ時間）に応じて第２の上限時間を決定する（ステップＳ１２５）。つまり、第１のスリープ時間の長さに応じて待機時間ＴＤの上限が短く調整される。これにより、デバイス管理装置３０のスリープ状態からの復帰後、取得したデバイス情報の監視サーバー２０へのアップロードをいたずらに（第１のスリープ時間を考慮せずに）長い時間待機する、といった状況を回避できる。さらに図４によれば、制御部３１は、取得予定時刻Ｔ１よりも後にデバイス管理装置３０がスリープ状態から復帰した場合、当該復帰して開始したデバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得（ステップＳ１００）から第２の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで監視サーバー２０へアップロードする。これにより、各デバイス管理装置３０からの当該アップロードのタイミングの重なりが緩和される。

なお、制御部３１がデバイス情報の取得（ステップＳ１００）を終えてから待機処理（ステップＳ１４０）を開始するまでの時間、つまり図３，４におけるステップＳ１１０，Ｓ１２０，Ｓ１３０の処理に要する時間や、図４におけるステップＳ１１０，Ｓ１２０，Ｓ１２５，Ｓ１３０の処理に要する時間は、極めて短い時間（例えば、１秒未満）である。そのため、本実施形態の説明では、このような短い時間は基本的に無視している。ただし、制御部３１は、このような短い時間の存在も考慮して待機時間ＴＤを設定してもよい。例えば、制御部３１は、第１の上限時間内で待機時間ＴＤを設定する際には（ステップＳ１３０）、第１の上限時間よりも１秒短い時間を、そのとき待機時間ＴＤとして設定し得る最長の時間とする。同様に、第２の上限時間内で待機時間ＴＤを設定する際には（ステップＳ１３０）、第２の上限時間よりも１秒短い時間を、そのとき待機時間ＴＤとして設定し得る最長の時間とする。これにより、デバイス情報を取得してから第１の上限時間（あるいは第２の上限時間）が経過するまでのいずれかのタイミングで監視サーバー２０へデバイス情報を送信する、という本実施形態の思想がより確実に担保される。

図５は、図３および図４の待機処理（ステップＳ１４０）の詳細の一例を示すフローチャートである。図３の例では、待機処理で採用される待機時間ＴＤは、第１の上限時間内で設定された待機時間ＴＤであるが、図４の例では、待機処理で採用される待機時間ＴＤは、第１の上限時間内で設定された待機時間ＴＤまたは第２の上限時間内で設定された待機時間ＴＤのいずれかである。

待機処理では、メインスレッド（ステップＳ２００）と、サブスレッド（ステップＳ２１０〜Ｓ２３０）とが並列に実行される。メインスレッド（ステップＳ２００）では、制御部３１は、ステップＳ１３０（図３，４）で設定された待機時間ＴＤが経過するまで待機する。一方、サブスレッドでは、制御部３１は、デバイス管理装置３０がスリープ状態から通常状態へ復帰したか否かを継続的に監視し（ステップＳ２１０）、この監視の結果、当該復帰を検知できなかった場合（ステップＳ２２０において“Ｎｏ”）、サブスレッドはメインスレッドが終了するタイミングで共に終了する。当該復帰を検知できずにサブスレッドを終了する場合とは、待機時間ＴＤの間デバイス管理装置３０が一度もスリープ状態へ陥らなかった、つまり通常状態を維持したまま待機時間ＴＤが経過したことを意味する。

一方、前記監視を継続した結果、前記復帰を検知した場合（ステップＳ２２０において“Ｙｅｓ”）、サブスレッドはステップＳ２３０へ進む。つまり、待機時間ＴＤの間にデバイス管理装置３０がスリープ状態へ陥った場合、その後、通常状態へ復帰したときに当該復帰を制御部３１は検知し、ステップＳ２３０へ進む。ステップＳ２３０では、制御部３１は、待機処理を強制終了させる。

この強制終了（ステップＳ２３０）により、待機処理を開始してから現実の時間経過が待機時間ＴＤを越えていても越えていなくても、待機処理は終わる。例えば、ステップＳ１３０で設定された待機時間ＴＤが１５分であり、ステップＳ１４０の待機処理を開始してから５分後にデバイス管理装置３０はスリープ状態へ陥り、このスリープ状態が７分継続した後、通常状態へ復帰したとする。この場合、当該復帰の時点（ステップＳ２２０において“Ｙｅｓ”と判定した時点）で、待機処理開始からの現実の時間経過は１２分であるが、制御部３１はその場で待機処理を終了させる。また、ステップＳ１３０で設定された待機時間ＴＤが１５分であり、ステップＳ１４０の待機処理を開始してから５分後にデバイス管理装置３０はスリープ状態へ陥り、このスリープ状態が１時間継続した後、通常状態へ復帰したとする。この場合、当該復帰の時点（ステップＳ２２０において“Ｙｅｓ”と判定した時点）で、待機処理開始からの現実の時間経過は１時間５分であり、制御部３１はその場で待機処理を終了させる。

待機処理を開始してから待機時間ＴＤが経過する前にデバイス管理装置３０がスリープ状態へ陥った場合、その後に通常状態へ復帰した時点で、制御部３１は、当該スリープ状態へ陥る直前までの経過時間を、待機時間ＴＤ内での経過時間と認識する。これは、デバイス管理装置３０がスリープ状態である間は、制御部３１は、デバイス情報取得送信処理を中断するためである。例えば、ステップＳ１３０で設定された待機時間ＴＤが１５分であり、待機処理（ステップＳ１４０）を開始してから５分後にデバイス管理装置３０がスリープ状態へ陥り、その後、当該スリープ状態から通常状態へ復帰したとき、制御部３１は、待機処理の開始から５分経過したと認識する。この場合、制御部３１は、待機時間ＴＤの残り時間は１０分と認識している。制御部３１が、仮に上述の強制終了（ステップＳ２３０）をせず、当該残り時間（１０分）の待機を継続する場合、当該残り時間（１０分）が経過する前に再びデバイス管理装置３０がスリープ状態へ陥ったときには、制御部３１が当該残り時間（１０分）の経過を最終的に認識するまでにさらに多くの時間を要する。つまり、待機時間ＴＤの間にスリープ状態への移行と通常状態への復帰とが繰り返されるような環境では、制御部３１が待機時間ＴＤが経過したと認識するまでに、例えば数日を要する（その結果、監視サーバー２０へ数日前に取得されたデバイス情報が届く）ような事例も考えられる。

これに対して、図５の例によれば、制御部３１は、デバイス情報を取得してから当該取得したデバイス情報を監視サーバー２０へ送信するタイミングになるまでの当該送信の待機中（つまりステップＳ１４０の待機処理中）に、デバイス管理装置３０がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からのデバイス管理装置３０の通常状態への復帰後、待機することなく監視サーバー２０へデバイス情報をアップロードする。つまり、デバイス管理装置３０は、待機処理中に移行したスリープ状態からの復帰後は、監視サーバー２０への情報のアップロードを即座に実行するため、監視サーバー２０へのデバイス情報の到達が上述の事例にように大幅に遅れることを、回避することができる。

図６は、図３および図４の待機処理（ステップＳ１４０）の詳細を示すフローチャートであって、図５とは異なる例を示している。図６は、サブスレッドのステップＳ２２０の後に、ステップＳ２３０の前にステップＳ２２２，Ｓ２２４を有する点で図５と異なる。
サブスレッドでは、制御部３１は、デバイス管理装置３０がスリープ状態から通常状態へ復帰したか否かを継続的に監視し（ステップＳ２１０）、この監視の結果、当該復帰を検知した場合（ステップＳ２２０において“Ｙｅｓ”）、ステップＳ２２２へ進む。

ステップＳ２２２では、制御部３１は、当該待機処理中にデバイス管理装置３０が移行したスリープ状態の長さ（以下、第２のスリープ時間と呼ぶ。）に応じて、待機時間ＴＤの残り時間を調整する。例えば、制御部３１は、現在認識している待機時間ＴＤの残り時間から第２のスリープ時間を差し引いた残りを、調整後の残り時間とする。例えば、ステップＳ１３０で設定された待機時間ＴＤが１５分であり、ステップＳ１４０の待機処理を開始してから５分後にデバイス管理装置３０がスリープ状態へ陥り、このスリープ状態が７分継続した後、通常状態へ復帰したとする。この場合、制御部３１は、当該復帰の時点（ステップＳ２２０において“Ｙｅｓ”と判定した時点）で認識している待機時間ＴＤの残り時間（１０分）から第２のスリープ時間（７分）を引いた残り、つまり３分を調整後の残り時間とする。

ステップ２２４では、制御部３１は、ステップＳ２２２による調整後の残り時間が存在するか否か判定し、当該判定に応じて処理を分岐する。例えば、制御部３１は、ステップＳ２２０において“Ｙｅｓ”と判定した時点で認識している待機時間ＴＤの残り時間から第２のスリープ時間を差し引いた結果が０またはマイナスであれば、調整後の残り時間は０、すなわち無しと判定し、ステップＳ２３０へ進む。つまり、第２のスリープ時間が経過した結果、待機処理を開始してからの現実の時間経過が待機時間ＴＤを越えている場合には、制御部３１は、待機処理を強制終了させる。一方、制御部３１は、Ｓ２２０において“Ｙｅｓ”と判定した時点で認識している待機時間ＴＤの残り時間から第２のスリープ時間を差し引いた結果がプラスであれば、調整後の残り時間有りと判定する。調整後の残り時間有りと判定した場合には、制御部３１は、当該調整後の残り時間（例えば、前記例で言えば３分）を、新たな待機時間ＴＤに設定し、当該新たな待機時間ＴＤの待機処理（図６のフローチャート）を開始する。

このような図６の例によれば、制御部３１は、デバイス情報を取得してから当該取得したデバイス情報を監視サーバー２０へ送信するタイミングになるまでの当該送信の待機中（つまりステップＳ１４０の待機処理中）に、デバイス管理装置３０がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からのデバイス管理装置３０の通常状態への復帰後、当該送信の待機中に移行したスリープ状態の長さ（第２のスリープ時間）に応じて、監視サーバー２０へデバイス情報をアップロードするまでに待機する残りの時間を調整する。これにより、デバイス管理装置３０は、待機処理中に移行したスリープ状態からの復帰後、監視サーバー２０への情報のアップロードをいたずらに（第２のスリープ時間を考慮せずに）長い時間待機する、といった状況を避けることができる。

言うまでもなく、図３の例に図５の例を組み合わせた構成、図３の例に図６の例を組み合わせた構成、図４の例に図５の例を組み合わせた構成、図４の例に図６の例を組み合わせた構成、のいずれもが本発明に属する実施形態である。本実施形態は、さらに次のような構成を採用してもよい。

図１の例によれば、デバイス管理装置３０のうちの１つであるデバイス管理装置３０ａは、複数のデバイス４０ａ，４０ｂ，４０ｃ…の各々からデバイス情報を取得する（ステップＳ１００）。このように複数のデバイス４０からデバイス情報を取得するデバイス管理装置３０は、デバイス４０毎にデバイス情報をアップロードするタイミングを分散させてもよい。具体的には、デバイス管理装置３０ａの制御部３１は、ステップＳ１００で複数のデバイス４０ａ，４０ｂ，４０ｃ…の各々からデバイス情報を取得したら、ステップＳ１３０では、待機時間ＴＤを上限時間（第１の上限時間または第２の上限時間）内で、デバイス４０毎にランダムに設定する。そして、当該制御部３１は、デバイス４０毎に設定した待機時間ＴＤの経過を待って（ステップＳ１４０）、デバイス４０毎のデバイス情報を監視サーバー２０へアップロードする（ステップＳ１５０）。

例えば、デバイス４０ａに対応する待機時間ＴＤ、デバイス４０ｂに対応する待機時間ＴＤ、デバイス４０ｃに対応する待機時間ＴＤ、をそれぞれ設定したとする（ステップＳ１３０）。この場合、制御部３１は、ステップＳ１４０の待機処理の開始後、デバイス４０ａに対応する待機時間ＴＤが経過したタイミングでデバイス４０ａのデバイス情報を監視サーバー２０へアップロードする。同様に、制御部３１は、当該待機処理の開始後、デバイス４０ｂに対応する待機時間ＴＤが経過したタイミングでデバイス４０ｂのデバイス情報をアップロードし、デバイス４０ｃに対応する待機時間ＴＤが経過したタイミングでデバイス４０ｃのデバイス情報をアップロードする。このような構成によれば、アップロードを受ける監視サーバー２０側の負担をより平準化することができる。

１０…デバイス監視システム、２０…監視サーバー、２１…データベース、３０，３０ａ…デバイス管理装置、４０，４０ａ，４０ｂ，４０ｃ，４０ｉ，４０ｊ…デバイス、ＡＰ…アプリケーション、ＮＷ１，ＮＷ２…ネットワーク、Ｔ１…取得予定時刻、ＴＤ…待機時間

Claims (9)

1. 監視対象のデバイスに関するデバイス情報を取得するデバイス管理装置であって、
   前記デバイスから前記デバイス情報を取得し、当該取得したデバイス情報を外部のサーバーへ送信する制御部を有し、
   前記制御部は、
   前記デバイス情報の取得のタイミングとして予め指定された取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、当該取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信し、
   前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信する、ことを特徴とするデバイス管理装置。
2. 前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該取得後、待機することなく前記サーバーへ送信することを特徴とする請求項１に記載のデバイス管理装置。
3. 前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、前記取得予定時刻から当該復帰までに要した時間に応じて前記第２の上限時間を決定することを特徴とする請求項１に記載のデバイス管理装置。
4. 前記制御部は、前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第２の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで前記サーバーへ送信することを特徴とする請求項１または請求項３に記載のデバイス管理装置。
5. 前記制御部は、前記取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、前記取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間が経過するまでに含まれるタイミングの中からランダムに選択したタイミングで前記サーバーへ送信することを特徴とする請求項１〜請求項４のいずれかに記載のデバイス管理装置。
6. 前記制御部は、前記デバイス情報を取得してから当該取得したデバイス情報を前記サーバーへ送信するタイミングになるまでの当該送信の待機中に前記デバイス管理装置がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からの前記デバイス管理装置の復帰後、待機することなく前記サーバーへ前記デバイス情報を送信することを特徴とする請求項１〜請求項５のいずれかに記載のデバイス管理装置。
7. 前記制御部は、前記デバイス情報を取得してから当該取得したデバイス情報を前記サーバーへ送信するタイミングになるまでの当該送信の待機中に前記デバイス管理装置がスリープ状態へ移行した場合、当該送信の待機中に移行したスリープ状態からの前記デバイス管理装置の復帰後、当該送信の待機中に移行したスリープ状態の長さに応じて、前記サーバーへ前記デバイス情報を送信するまでに待機する残りの時間を調整することを特徴とする請求項１〜請求項５のいずれかに記載のデバイス管理装置。
8. 監視対象のデバイスに関するデバイス情報を取得するデバイス管理装置と、当該デバイス管理装置から情報の送信を受けるサーバーと、を含むデバイス監視システムであって、
   前記デバイス管理装置は、前記デバイスから前記デバイス情報を取得し、当該取得したデバイス情報を前記サーバーへ送信する制御部を有し、
   前記制御部は、
   前記デバイス情報の取得のタイミングとして予め指定された取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、当該取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信し、
   前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信する、ことを特徴とするデバイス監視システム。
9. 監視対象のデバイスに関するデバイス情報を取得する処理をデバイス管理装置に実行させるデバイス管理プログラムであって、
   前記デバイスから前記デバイス情報を取得し、当該取得したデバイス情報を外部のサーバーへ送信するための機能を有し、
   前記機能は、
   前記デバイス情報の取得のタイミングとして予め指定された取得予定時刻に前記デバイス管理装置がスリープ状態でない場合、当該取得予定時刻に前記デバイス情報の取得を開始して得たデバイス情報を、当該デバイス情報の取得から第１の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信し、
   前記取得予定時刻よりも後に前記デバイス管理装置がスリープ状態から復帰した場合、当該復帰して開始した前記デバイス情報の取得により得たデバイス情報を、当該デバイス情報の取得から前記第１の上限時間よりも短い第２の上限時間が経過するまでのいずれかのタイミングで前記サーバーへ送信する、ことを特徴とするデバイス管理プログラム。

Images