(57)【要約】【課題】  ネットワーク上のデバイスを、タイマー処理を用いて管理する際に、正確な時刻が得られているかどうかを判定する手段はこれまでコストが高かったり、ネットワークトラフィックを無駄に増大させたりするものが一般的であった。また時計を修正する権限が必須であり、一旦時計を修正してしまうとその後の時計の正確さが維持されているかを判定できないものもあった。【解決手段】  起動時に管理エージェントが保持しているログに記録されている時刻と内蔵時計の示す現在時刻を比較する。また管理エージェントからの管理操作リクエストを受信する際にそのリクエストに付与された情報処理装置の時計の示す時刻と比較する。これらにより、時計の信頼性が高いか低下しているかを判定する。【選択図】  図１
2011008470.tif 000002
【特許請求の範囲】
【請求項１】
ネットワーク（１０１）と、当該ネットワーク（１０１）に接続されたデバイス（１０２）と、当該デバイス（１０２）上で動作する管理エージェント（１０３）と、
当該ネットワーク（１０１）に接続された情報処理装置（１０４）と、当該情報処理装置（１０４）上で動作し、当該管理エージェント（１０３）に対して、管理行為の実行または実行予定を含む管理操作を指示する管理操作リクエストを送信する管理アプリケーション（１０５）と、
からなるネットワークデバイス管理システムであって、
当該管理エージェント（１０３）は、
自身の実行した管理行為についてその都度ログ時刻を含むログエントリーを必要に応じて生成し、ログ保持領域（２０４）に保存するログモジュールと（２０３）、
また実行する予定の管理行為（３０４）と、当該管理行為を実行する予定時刻（３０３）と、与えられた本来の予定時刻（３０２）とからなる当該管理行為実行予定（２０６）を管理行為実行予定保持領域（２０７）に保持する管理行為実行予定保持機能と、
当該管理行為実行予定保持機能に保持されたいずれかの当該管理行為実行予定（２０６）について、当該デバイスの備える第一の内蔵時計が当該予定時刻に到達した場合に、当該管理行為を実行する管理行為予定実行機能と、
を備えたタイマーモジュール（２０５）と、
当該第一内蔵時計の示す時刻を信頼できるかどうかを判定した結果である時計信頼性管理情報を保持する時計信頼性管理情報保持領域（２０８）と、
当該保持領域（２０８）において少なくとも時計信頼性高状態と時計信頼性低下状態とを区別して保持する時計信頼性管理情報保持機能を備えた時計信頼性管理情報保持モジュール（２０７）と、
を備えており、
また当該管理アプリケーション（１０５）は、当該管理操作リクエストを送信する際に当該情報処理装置（１０４）の備える第二の内蔵時計の示す時刻を、リクエスト時刻情報として送信データに含めることを特徴とし、
また当該管理エージェント（１０３）は、
起動時に当該第一の内蔵時計の示す時刻を取得して起動時時刻とする起動時時刻取得ステップ（Ｓ４０２）と、
当該ログに保存された最後のログエントリーから当該ログ時刻を抽出し最終ログ時刻とする最終ログ時刻抽出ステップ（Ｓ４０３）と、
当該最終ログ時刻抽出ステップにて抽出された当該最終ログ時刻と当該起動時時刻とを比較する起動時時刻比較ステップ（Ｓ４０４）と
当該起動時時刻比較ステップにおいて比較した結果起動時の時刻が最終ログの時刻より逆行しているかどうかを判定する逆行判定ステップ（Ｓ４０５）と、
当該逆行判定ステップにおいて逆行していなかった場合に、当該起動時時刻比較ステップにおいて比較した結果、当該起動時時刻が最終ログの時刻より予め定めてあった閾値を超えて大幅に進行しているかどうかを判定する時間進行幅判定ステップ（Ｓ４０７）と、
時計信頼性低下状態が保持されていた場合において、当該逆行判定ステップにおいて逆行していた場合、あるいは、時間進行幅判定ステップにおいて大幅に進行していた場合に時計信頼性高状態を保持する起動時時計信頼性回復ステップ（Ｓ４１１）と、
当該タイマーモジュール（２０５）に保持されている全ての当該管理行為実行予定（２０６）について、保持されている当該予定時刻を、保持されている当該本来の予定時刻に再設定する、起動時タイマー再設定ステップ（Ｓ４１２）とを備えるとともに、
時計信頼性高状態が保持されていた場合において、当該逆行判定ステップにおいて逆行していた場合、あるいは、時間進行幅判定ステップにおいて大幅に進行していた場合に、時計信頼性低下状態を保持する、起動時時計信頼性低下ステップ（Ｓ４１３）を備えた、
起動時時計信頼性判定モジュール（２１１）と、
当該管理アプリケーション（１０５）から当該管理操作リクエストを受信した際に当該第一の内蔵時計の示す時刻を取得する受信時刻取得ステップ（Ｓ５０２）と
当該送信データに含まれる当該リクエスト時刻情報を抽出するリクエスト時刻抽出ステップ（Ｓ５０３）と、
当該リクエスト時刻抽出ステップにて抽出された当該リクエスト時刻情報と当該受信時刻とを比較する受信時時刻比較ステップ（Ｓ５０４）と、
当該受信時時刻比較ステップにおいて、時刻の差が予め定めてあった閾値を超えているかどうかを判定する、受信時時刻差判定ステップ（Ｓ５０５）と、
時計信頼性低下状態が保持されていた場合において、当該受信時時刻差判定ステップにおいて時刻の差が閾値を超えていた場合に時計信頼性高状態を保持する受信時信頼性回復ステップ（Ｓ５０８）と、
当該タイマーモジュール（２０５）に保持されている全ての当該管理行為実行予定（２０６）について、保持されている当該予定時刻を、保持されている当該本来の予定時刻に再設定する受信時タイマー再設定ステップ（Ｓ５０９）とを備えるとともに、
時計信頼性高状態が保持されていた場合において、当該受信時時刻差判定ステップにおいて時刻の差が閾値を超えていた場合に、時計信頼性低下状態を保持する受信時信頼性低下ステップ（Ｓ５１１）を備えた、
受信時時計信頼性判定モジュール（２１２）と
を含むことを特徴とするネットワークデバイス管理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワークに接続されたデバイスを管理するためのシステムに関するものである。
【背景技術】
【０００２】
ネットワークに接続されたデバイスをデバイスの上で稼動するエージェント型のソフトウェアを用いて管理するシステムでは、様々な局面において時刻を参照する必要がある。この場合、当然ではあるが、その時刻はできる限り正確な日時と一致していることが望ましい。
【０００３】
しかしながらそのようなエージェントが通常参照可能である、デバイスに内蔵された時計は不正確なことがしばしばあり、そのような時計は不正確な時刻を返す。また充分に正確な時計であっても誤差が蓄積することで不正確な時刻を返すようになってしまう可能性をなくすことはできない。
【０００４】
そのような中で、エージェントがより正確な時刻を得るために、ネットワークで接続された外部に存在する基準時刻を保持する情報処理装置に対してリクエストを行い、応答によって基準時刻を得て動作するよう構成されたシステムは存在した。（例えば、特許文献１参照。）
また相互に複数の同種のデバイスがネットワークに接続されていることを利用して、それらデバイス上のエージェントがそれぞれの内蔵時計が示す時刻を交換し平均時刻を算出することでそれを現在時刻として採用するよう構成されたシステムは存在した。（例えば、特許文献２参照。）
あるいはＦＡＸ装置において、時計がまだ手動較正されたことがない時点においてＦＡＸ文書を受信した場合に、当該文書から時刻情報を抽出することが可能である。そのようなＦＡＸ装置に搭載されたエージェントが、当該時刻情報が信頼できるものであるかどうかを判断した後、信頼できるものであればそれを現在日時として採用するようなシステムは存在した。（例えば、特許文献３参照。）
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００１−２４２６１８号公報
【特許文献２】特開平７−１６０３５８号公報
【特許文献３】特開２００６−２１７０１２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、これらのうち、特許文献１の技術では、正確な基準時刻を維持したサーバー装置がネットワーク上に必要であり、運用コストが高くつくという問題があった。またエージェントソフトウェアは正確な時刻を取得するためには毎回自ら当該サーバー装置へ問合せを行わねばならないため、ネットワークトラフィックを無駄に消費するという問題があった。
【０００７】
また特許文献２の技術では、この技術を相互運用可能なように構成したデバイスがネットワーク上に複数存在している必要があるという問題があった。また、これらデバイスが相互にネットワークを経由して時刻取得を繰り返すことで同様にネットワークトラフィックを消費してしまうという問題があった。
【０００８】
一方で特許文献３の技術では、時刻を一度でも手動で設定してしまうと、それ以降受信文書があっても時刻を検証しないという問題があった。さらに、受信文書に含まれている時刻情報の信頼度について判断する際に利用することのできる情報が少ないため精度が低い上、間違った時刻を採用してしまっても後から修正する方法がないという問題があった。
【０００９】
加えて、特許文献３の技術においては、エージェントが内蔵時計を較正する機能を備えている必要があるが、デバイスによっては、エージェントに対して内蔵時計を較正する権限を開放していないため同技術が利用できない、という問題もあった。
【課題を解決するための手段】
【００１０】
これらの課題を解決するために本発明においては、以下のようなネットワークデバイス管理システムを構成する。すなわち、ネットワーク（１０１）と、当該ネットワーク（１０１）に接続されたデバイス（１０２）と、当該デバイス（１０２）上で動作する管理エージェント（１０３）と、当該ネットワーク（１０１）に接続された情報処理装置（１０４）と、当該情報処理装置（１０４）上で動作し、当該管理エージェント（１０３）に対して、管理行為の実行または実行予定を含む管理操作を指示する管理操作リクエストを送信する管理アプリケーション（１０５）と、からなるネットワークデバイス管理システムであって、後述する実施例に記載されるような構成を備えることを特徴とする。
【発明の効果】
【００１１】
本発明のこの構成を採ることによって、ネットワークデバイス管理システムは、基準時刻を保持するサーバーを置かずとも時計の信頼性を管理することが可能になる。
【００１２】
また本発明のネットワーク管理システムでは、管理エージェントは起動時に自身のログとの比較においてデバイスの内蔵する時計の信頼性を判断するために、ネットワーク上にデバイスが一つしか存在しない状況でも判断を行うことが可能であるという利点を持つ。
【図面の簡単な説明】
【００１３】
【図１】ネットワーク管理システムの構成を示す図である。
【図２】管理エージェントのソフトウェアモジュール構成を示す図である。
【図３】管理エージェントの管理する管理行為実行予定の表を示す図である。
【図４】起動時時計信頼性判定モジュールの動作フローチャートである。
【図５】受信時時計信頼性判定モジュールの動作フローチャートである。
【図６】タイマーモジュールのタイマー実行動作のフローチャートである。
【図７】起動時および受信時タイマー再設定ステップの動作フローチャートである。
【図８】第二の実施例の、管理エージェントの起動時時計信頼性判定モジュールの動作フローチャートである。
【図９】第二の実施例の、ログの構成を示す図である。
【図１０】第三の実施例の、ログの構成を示す図である。
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【００１５】
（第一の実施例）
まず、本発明の第一の実施例について説明する。
【００１６】
図１は、本発明の、第一の実施例の、ネットワークデバイス管理システムの構成を示したものである。
【００１７】
１０１はネットワークである。１０２は当該ネットワーク（１０１）に接続され本システムによる管理の対象となるデバイスである。１０３は当該管理対象デバイスのコントローラ上で動作する管理エージェントソフトウェアである。１０４は当該ネットワーク（１０１）に接続された情報処理装置である。１０５は、当該情報処理装置（１０４）の上で動作する管理アプリケーションソフトウェアである。
【００１８】
図２は、本発明の、第一の実施例の、管理エージェント（１０３）のソフトウェアモジュール構成を示したものである。
【００１９】
２０１は全体を制御するためのコントローラーモジュールである。２０２はネットワーク（１０１）を経由して他のネットワークノード、例えば情報処理装置（１０４）と通信を行うためのネットワーク通信モジュールである。２０３は管理エージェント（１０３）の管理行為を実施したログをハンドリングするためのログモジュールである。２０４はそのログの記憶領域である。
【００２０】
２０５は設定された管理行為実行予定を管理すると共に、実行予定に従ってタイマー実行を行うタイマーモジュールであり、２０６はその管理行為実行予定の記憶領域である。
【００２１】
２０７は時計信頼性管理情報をハンドリングする時計信頼性管理情報保持モジュールであり、２０８はその時計信頼性管理情報を保持するための時計信頼性管理情報保持領域である。
【００２２】
２０９はデバイス（１０２）の内蔵時計から時刻情報を取得するための内蔵時計インターフェースである。
【００２３】
２１０は当該管理エージェント（１０３）が様々な管理行為を実行するための管理行為実行モジュールである。
【００２４】
２１１は起動時時計信頼性判定モジュールである。
【００２５】
２１２は受信時時計信頼性判定モジュールである。
【００２６】
図３は、本発明の、第一の実施例の、管理エージェント（１０３）の管理行為実行予定記憶領域（２０６）に格納される管理行為実行予定のデータ形式を示した図である。
【００２７】
３０１は予定番号である。３０２は予定が設定されたときに与えられた本来の予定時刻である。本来の予定時刻は、繰返実行などの指定までを含んでおり、例えば毎週金曜日に実行するよう最初に設定されたのであれば、本来予定時刻（３０２）には「毎金曜日」を示す情報が格納される。３０３は実行予定時刻であり、本来予定時刻（３０２）を元に、次にこの管理行為実行される予定の時刻が格納される。３０４は実行予定管理行為である。
【００２８】
次に本発明の起動時時刻信頼性判定モジュール（２１１）について説明する。
【００２９】
起動時時刻信頼性判定モジュール（２１１）は起動時に内蔵時計の時刻と最終ログに記録された時刻を比較する。
【００３０】
起動時に内蔵時計が最終ログの記録する時刻よりも逆行した時刻を示していた場合、これは何らかのタイミングで当該内蔵時計の指示する時刻が不連続に変化したことを示している。もしも、前回当該管理エージェント（１０３）が、時計の信頼性が低下していると推定している状態であったとしたら、時計の時刻が不連続に変更されたという事実は、何らかの手段で時計が正しい時刻に修正された可能性を期待させる。逆に前回当該管理エージェント（１０３）が、時計の信頼性が高いと推定している状態であったとしたら、時計の時刻が不連続に変更されたという事実は、時計が何らかの原因で狂ってしまった可能性について考慮するべきという推定を導出する。
【００３１】
また、起動時に内蔵時計が最終ログの記録する時刻よりも大きく進んでいた場合、ここで想定されているようなネットワークデバイスが長い間電源を投入されないまま放置される状況を想定するのは難しく、またもや時刻が不連続に変化したと推定せざるを得ない。従って、まったく同様の推論により、時計の信頼性が回復したのか、低下したのかという推定を行うことが可能である。
【００３２】
図４は、本発明の、第一の実施例の、管理エージェント（１０３）の起動時時刻信頼性判定モジュール（２１１）の動作を示したフローチャートである。本図に記述されている動作は、当該デバイス（１０２）が電源を投入され、当該管理エージェント（１０３）が初期状態から動作開始した直後に、当該管理エージェント（１０３）のコントローラーモジュール（２０１）によって呼び出されるものである。
【００３３】
起動時時刻信頼性判定モジュール（２１１）は、ステップＳ４０１から処理を開始する。
【００３４】
そして、ステップＳ４０２にて、まずここで内蔵時計インターフェース（２０９）を通じてデバイス（１０２）の内蔵時計から時刻情報を取得する。（起動時時刻取得ステップ）
続くステップＳ４０３にて、ログモジュール（２０３）を通じて、ログ保持領域（２０４）に記録されている中で前回終了時に最後に記録されたログを取得し、そのデータから最終ログ時刻を抽出する。（最終ログ時刻抽出ステップ）
さらにステップＳ４０４にて、ステップＳ４０２にて取得した内蔵時計の時刻情報と、ステップＳ４０３にて抽出した最終ログの時刻を比較する。（起動時時刻比較ステップ）
そして、ステップＳ４０５にて比較結果が逆行であったかどうか、すなわち、ステップＳ４０２で取得した内蔵時計の時刻情報が、ステップＳ４０３にて抽出した最終ログの時刻よりも、前の時刻を示しているかどうかを判定する。
【００３５】
ステップＳ４０６にて、逆行であった場合には、ステップＳ４０９へ分岐する。逆行でなかった場合、すなわち、内蔵時計の時刻が最終ログの時刻よりも後であった場合には処理はステップＳ４０７へ進む。
【００３６】
ステップＳ４０７にて、今度は内蔵時計の時刻が最終ログの時刻よりもどれくらい後であるかの時刻差分を計算し、その時刻差分があらかじめ定めた閾値を超えているかどうかを判定する。（時間進行幅判定ステップ）
ステップＳ４０８にて、その判定結果により、閾値を超えている場合にはステップＳ４０９へ分岐する。閾値を超えていないと判定された場合にはステップＳ４１４へ進む。
【００３７】
ステップＳ４０９では、時計信頼性管理情報保持モジュール（２０７）を通じて時計信頼性管理情報を参照し、それが時計信頼性高状態であればステップＳ４１３へ分岐する。時計信頼性高状態でなかった場合にはステップＳ４１０へ進む。
【００３８】
ステップＳ４１０では参照した時計信頼性管理情報が時計信頼性低下状態であればステップＳ４１１へ進む。そうでなかった場合にはステップＳ４１４へ進む。
ステップＳ４１１では、時計信頼性管理情報保持モジュール（２０７）を通じて、時計信頼性管理情報を時計信頼性高状態に変更する。そしてステップＳ４１２へ進む。
【００３９】
ステップＳ４１２では管理行為実行予定の設定を、すべて再設定する。（起動時タイマー再設定ステップ）再設定が完了したら処理はステップＳ４１４へ進む。
【００４０】
ステップＳ４０９にて時計信頼性高状態であった場合には処理はステップＳ４１３へ進む。ステップＳ４１３では、時計信頼性管理情報保持モジュール（２０７）を通じて時計信頼性管理情報を時計信頼性低下状態に変更する。そしてステップＳ４１４へ進む。
【００４１】
ステップＳ４１４で起動時時刻信頼性判定モジュール（２１１）の動作が完了する。
【００４２】
次に、本発明の受信時時刻信頼性判定モジュール（２１２）について説明を加える。
【００４３】
ここでは、管理エージェントが受け取った、情報処理装置（１０４）上で動作している管理アプリケーション（１０５）が管理操作リクエストに付与した時刻情報が、内蔵時計の指示する時刻と大きく食い違っている場合を想定する。このような場合、デバイス（１０２）と情報処理装置（１０３）の間でそれぞれの内蔵時計が指示する時刻が食い違っていることから、どちらかの時計が正しくない時刻を指示していることがかなりの確度で推定可能である。この状況でデバイスの内蔵時計の指示する時刻を信頼することは難しい。従って、その時点で時計信頼性が高いと推定している状態であった場合には時計信頼性が低下したと判断する。
【００４４】
あるいは大きく食い違っていない場合には、双方の内蔵時計が偶然同じ時刻を指示するように狂った可能性は小さく見積もることが可能であるため、この状況ではデバイスの内蔵時計の指示する時刻は信頼できると判断することが可能である。その時点で時計信頼性が低下中であると推定していた場合には、時計信頼性が回復したと判断する。
【００４５】
図５は、本発明の、第一の実施例の、管理エージェント（１０３）の受信時時刻信頼性判定モジュール（２１２）の動作を示したフローチャートである。このフローチャートに記述されている動作は、次に述べるような時点において当該管理エージェント（１０３）のコントローラーモジュール（２０１）によって呼び出され実行される。すなわち、当該デバイス（１０２）の稼動中に当該管理エージェント（１０３）のネットワーク通信モジュール（２０２）がネットワーク（１０１）から管理アプリケーション（１０５）によって送信された管理操作リクエストを受信した場合である。
【００４６】
受信時時刻信頼性判定モジュール（２１２）は、呼び出されるとステップＳ５０１から処理を開始する。
【００４７】
まずステップＳ５０２にて内蔵時計インターフェース（２０９）を通じて内蔵時計の時刻情報を取得する。（受信時時刻取得ステップ）
続くステップＳ５０３にてネットワーク通信モジュール（２０２）を通じて、受信した管理操作リクエストに組み込まれた時刻情報を抽出する。（リクエスト時刻抽出ステップ）
そしてステップＳ５０４にてステップＳ５０２にて取得した内蔵時計の時刻情報とステップＳ５０３にて抽出したリクエストに組み込まれた時刻情報を比較する。（受信時時刻比較ステップ）
ステップＳ５０５では比較し、内蔵時計の時刻と、リクエストの時刻の時刻差分を計算した結果として、その時刻差分があらかじめ定めた閾値を超えているかどうかを判定する。（受信時時刻差判定ステップ）
ステップＳ５０６にて当該時刻差分が閾値を超えている場合には処理はステップＳ５１０へ分岐する。閾値を超えていなかった場合にはステップＳ５０７へ進む。
【００４８】
ステップＳ５０７では、時計信頼性管理情報保持モジュール（２０７）を通じて、時計信頼性管理情報を取得した結果時計信頼性低下状態であればステップＳ５０８へ進む。そうでなければステップＳ５１２へ進む。
【００４９】
ステップＳ５０８では、時計信頼性管理情報保持モジュール（２０７）を通じて、時計信頼性管理情報を時計信頼性高状態に変更する。そしてステップＳ５０９へ進む。
【００５０】
ステップＳ５０９では管理行為実行予定の設定をすべて再設定する。（受信時タイマー再設定ステップ）再設定が完了したら処理はステップＳ５１２へ進む。
【００５１】
ステップＳ５１０では、時計信頼性管理情報保持モジュール（２０７）を通じて、時計信頼性管理情報を取得した結果時計信頼性高状態であればステップＳ５１２へ進む。そうでなければステップＳ５１１へ進む。
【００５２】
ステップＳ５１１では、時計信頼性管理情報保持モジュール（２０７）を通じて、時計信頼性管理情報を時計信頼性低下状態に変更する。そしてステップＳ５１２へ進む。
【００５３】
ステップＳ５１２で受信時時刻信頼性判定モジュール（２１２）の動作が完了する。
【００５４】
当該管理エージェント（１０３）においてはタイマーモジュール（２０５）を利用して、タイマーに従って予定にある管理行為を予定時刻に到達したら実行する、という動作が行われる。また、例えば毎週同じ曜日の同じ時刻に繰返管理行為を実行するというような設定が行われることが一般的であるため、このタイマーモジュール（２０５）もそのような設定を許容する。そのような繰返実行は、次のようにして実現される。すなわち、本来設定された繰返の指示を含む予定時刻の指定を、直近の実行予定時刻に変換して両方を保持する。そして、実行予定時刻に到達した再に、本来設定された予定時刻指定から次回の実行予定時刻を算出して再保存する。
【００５５】
図６は、本発明の、第一の実施例の、管理エージェント（１０３）のタイマーモジュール（２０５）のタイマー実行動作を示したフローチャートである。このフローチャートに記述されている動作は、当該管理エージェント（１０３）が動作開始後コントローラーモジュール（２０１）によって呼び出され実行される。
【００５６】
タイマーモジュール（２０５）は呼び出されるとステップＳ６０１から処理を開始する。
【００５７】
まずステップＳ６０２において管理行為実行予定保持領域（２０６）に管理行為実行予定が一つ以上存在しているかどうかを判定する。（管理行為実行予定存在判定ステップ）
ステップＳ６０３にて、管理行為実行予定が存在している場合には処理はステップＳ６０４へ進み、そうでない場合にはステップＳ６１８へ進む。
【００５８】
ステップＳ６０４では、実行検討対象となる管理行為実行予定の実行予定時刻を取得する。（実行予定時刻取得ステップ）
続くステップＳ６０５では、内蔵時計インターフェース（２０９）を通じて内蔵時計の時刻情報を取得する。（現在時刻取得ステップ）
そしてステップＳ６０６にてステップＳ６０４で取得した実行予定時刻と、ステップＳ６０５にて取得した内蔵時計の時刻とを比較する。（実行予定時刻比較ステップ）
そしてステップＳ６０７にて、ステップＳ６０６における比較の結果として現在すでに実行予定時刻に到達しているかどうかを判定し、到達していればステップＳ６０９へ進む。まだ到達していなければステップＳ６１６へ進む。
【００５９】
ステップＳ６０９では、実行検討対象となる管理行為実行予定の実行予定の管理行為を取得する。（実行予定管理行為取得ステップ）
その後続くステップＳ６１０にて、当該管理行為実行予定の本来設定されている実行予定時刻を取得する。（本来予定時刻取得ステップ）
そしてステップＳ６１１において、ステップＳ６１０で取得した本来予約時刻が繰返予約であるかどうかを判定する。（繰返予約判定ステップ）
ステップＳ６１２では繰返予約であるかどうかの判定結果に従い、そうであればステップＳ６１３へ進み、そうでなければステップＳ６１５へ進む。
【００６０】
ステップＳ６１３へ進むと、本来予定時刻に基づいて次回の実行予定時刻を算出する。（次回実行予定時刻算出ステップ）
そして続くステップＳ６１４にて、ステップＳ６１３にて算出された次回実行予定時刻を付与した新たな管理行為実行予定を生成し、管理行為実行予定保持領域（２０６）へ保存する。（次回管理行為実行予定保存ステップ）
続くステップＳ６１５にて、ステップＳ６０９にて取得した実行予定管理行為を実行する。（管理行為実行処理ステップ）この際、ログモジュール（２０３）を通して実行記録をログ保持領域（２０４）に保存する。
【００６１】
ステップＳ６１６にて管理行為実行予定保持領域（２０６）に他に登録されている管理行為実行予定が存在するかどうかを判定する。（次管理行為実行予定存在判定）
ステップＳ６１７にて、ステップＳ６１６にて判定した結果に従い、存在していれば処理はステップＳ６０４へ戻って続行される。存在しない場合には処理はステップＳ６１８へ進む。
【００６２】
ステップＳ６１８ではコントローラーモジュール（２０１）によって終了処理が行われているかどうかを判定する。（終了判定ステップ）
ステップＳ６１９にて、ステップＳ６１８における判定の結果に従い、終了であれば処理はステップＳ６２０へ進む。終了ではなければステップＳ６０２へ戻って処理が続行される。
【００６３】
ステップＳ６２０にてタイマーモジュール（２０５）のタイマー実行動作が完了する。
【００６４】
ところで、このようにしてタイマーによる繰返実行において、例えば、予定時刻として「毎週火曜日の１９：００に実行する」という設定が行われたとする。もしも時計が狂っており「２０１０年３月３日１２：００」を指示していたとすると、実際に次に実行する予定時刻としては「２０１０年３月９日１９：００」と設定される。この状態から内蔵時計が正しい時刻、例えば「２００９年５月２８日２１：００」に修正された場合、２００９年５月２８日から２０１０年３月８日までの間、この管理行為は一切実行されないこととなってしまう。
【００６５】
このことに鑑み、すでに図４にて示した通り、本発明の、第一の実施例の管理エージェント（１０３）は、起動時時計信頼性判定モジュール（２１１）に起動時タイマー再設定ステップ（Ｓ４１２）を備えている。すなわち時計信頼性が低下した状態でセットされた管理行為実行予定がある状態で、時計信頼性が回復した場合には、改めて次回の実行予定時刻を再算出し再設定する。
【００６６】
先述の例においては、ある時点で時計が「２００９年５月２８日２１：００」を指示し、これを取得した管理エージェント（１０３）が時計の信頼性が回復したと判定した場合を考える。このような場合には起動時タイマー再設定ステップ（Ｓ４１２）や受信時タイマー再設定ステップ（Ｓ５０９）は「２０１０年３月９日１９：００」という次回の実行予定時刻を破棄し、再算出された「２００９年６月２日１９：００」に置き換えられる。これにより、この管理行為実行予定は、意図したのに近い時刻に実行されるようになる。
【００６７】
図７は、本発明の、第一の実施例の、起動時時刻信頼性判定モジュール（２１１）における、起動時タイマー再設定ステップ（Ｓ４１２）の動作をフローチャートに示したものである。本ステップは幾つかの内部ステップにより構成されている。以下では内部ステップを単にステップと呼ぶ。
【００６８】
この起動時タイマー再設定ステップ（Ｓ４１２）は、ステップＳ７０１から動作を開始する。
【００６９】
ステップＳ７０２において、タイマーモジュール（２０５）を通じて、管理行為実行予定保持領域（２０６）に実行予定管理行為が存在するかどうかを判定する。（管理行為実行予定存在判定ステップ）
ステップＳ７０３にて、ステップＳ７０２にて判定した結果に従い、存在していればステップＳ７０４へ進む、存在していなければステップＳ７１０へ進む。
【００７０】
ステップＳ７０４にて、存在していたこれから処理の対象となる管理行為実行予定の、実行予定管理行為を取得する。（実行予定管理行為取得ステップ）
続くステップＳ７０５にてその管理行為実行予定にセットされた本来の予定時刻を取得する。（本来予定時刻取得ステップ）
そしてステップＳ７０６にて、ステップＳ７０５にて取得した本来予定時刻に基づいて、現在付与されている実行予定時刻を破棄し、新たに実行予定時刻を算出しなおす。（実行予定時刻際算出ステップ）
ステップＳ７０７にて新たに再算出された実行予定時刻と、ステップＳ７０５にて取得した本来予定時刻、およびステップＳ７０４にて取得した実行予定管理行為を付与して新たに生成した管理行為実行予定を、管理行為実行予定保持領域（２０６）に保存する。（管理行為実行予定保存ステップ）
ステップＳ７０８へ進んだ処理は、さらに処理すべき管理行為実行予定が存在しているかどうかを判定する。（次管理行為実行予定存在判定ステップ）
ステップＳ７０９では、ステップＳ７０８にて判定した結果に従い、次に処理すべき管理行為実行予定が存在していればステップＳ７０４へ進み処理を続行する。そうでなければステップＳ７１０へ進む。
【００７１】
起動時タイマー再設定ステップ（Ｓ４１２）はステップＳ７１０にて処理を完了し、次のステップへ進む。
【００７２】
また同様に、本発明の、第一の実施例では、すでに図５に示したとおり、受信時時刻信頼性判定モジュール（２１２）の処理において、受信時タイマー再設定ステップ（Ｓ５０９）を備えている。受信時タイマー再設定ステップ（Ｓ５０９）の動作は、図７のフローチャートに示したものと同様である。
【００７３】
こうして、本発明の第一の実施例によれば、デバイス（１０２）の内蔵時計の信頼性についてかなりの精度で、信頼性が高いか、低下中であるかを推定することが可能になる。
【００７４】
本発明の、第一の実施例を用いることにより、ネットワーク（１０１）上に基準時刻を保持するサーバーを置かずとも、時計の信頼性について確度の高い推定を行ってそれに基づいた管理を行うことが可能になる。例えば、当該管理エージェント（１０３）自身の生成した最終ログやリクエストを送信してくる管理アプリケーションと時刻情報を照合することで時計の信頼性を推定することが可能である。
【００７５】
また本発明の、第一の実施例においては、同種のデバイスが複数あることを前提としなくても良い。最低限、ネットワーク（１０１）上に当該デバイス（１０２）のみが存在している状況であっても、最終ログ時刻との照合により時計の信頼性を判定することは可能である。
【００７６】
さらに、ここで時計の信頼性の判定に用いているのは、自身の保持している最終ログの時刻情報および、管理アプリケーション（１０５）から送信される管理操作リクエストに付与された時刻情報である。前者についてはネットワーク通信を伴わない。また後者については、本来管理アプリケーション（１０５）が管理操作をリクエストするのは、時計の信頼性の管理とは無関係の動作であり、これにより生じたネットワークトラフィックは、時計の信頼性管理とは無関係に発生しているものである。従って、これら時計の信頼性を推定し管理する操作において、新たにこれまでに存在しなかったネットワークトラフィックを生じることはなく、ネットワークトラフィックを増大させることがない。
【００７７】
加えて本発明の、第一の実施例においては、時計の信頼性の検証はリクエストを受信するたびに行われる。またいったん信頼性が回復したと判定した後であっても、再び時刻を照合して時刻差分が閾値を超えていたりした場合には再度信頼性低下状態であるという推定に回帰する。このため、時計の信頼性について常に見直しが掛かっている状態となり、時計が非常に不安定であるような状況でも時計の信頼性を適切に管理することができている。
【００７８】
またここまでに見てきたとおり、本発明の、第一の実施例は、デバイス（１０２）の内蔵時計については、その指示する時刻情報を内蔵時計インターフェース（２０９）を通じて取得するのみである。すなわち、内蔵時計の指示する時刻を管理エージェント（１０３）自体が修正するということはないため、管理エージェント（１０３）が内蔵時計を修正する権限を持っていなくても本発明を実施することができる。これにより、そのような制限されたケースでも適切に時計の信頼性を管理することができる。
【００７９】
（第二の実施例）
次に本発明の第二の実施例について、図を交えて説明する。
【００８０】
本発明の、第二の実施例の、ネットワークデバイス管理システムの構成は図１に示したものと同様である。
【００８１】
本発明の、第二の実施例の、管理エージェント（１０３）のソフトウェアモジュール較正は図２に示したものと同様である。
【００８２】
本発明の、第二の実施例の、管理エージェント（１０３）の管理行為実行予定記憶領域（２０６）に格納される管理行為実行予定のデータ形式は図３に示したものと同様である。
【００８３】
図８は、本発明の、第二の実施例の、管理エージェント（１０３）の起動時時刻信頼性判定モジュール（２１１）の動作を示したフローチャートである。
【００８４】
また図９は、本発明の、第二の実施例の、管理エージェント（１０３）のログモジュール（２０３）が記録しログ保持領域（２０４）に保存されているログのデータ構造を模式的に示したものである。
【００８５】
９０１はログ番号である。ログが発生した順番に通し番号が振られている。
【００８６】
９０２はログ時刻である。ログが記録された日付と時刻が記録されている。
【００８７】
９０３は時計信頼性である。このログが記録された時点における、時刻信頼性管理情報保持モジュール（２０７）が時刻信頼性管理情報保持領域（２０８）に保持している時刻信頼性管理情報を記録している。
【００８８】
９０４は管理行為である。実際にログに記録される対象となった管理行為を記録している。
【００８９】
９０５は結果である。管理行為を実行した結果を記録している。
【００９０】
図８のフローチャートの一部は図４と同一の流れになっているので説明を省略し、第二の実施例特有の処理についてのみ解説を加える。
【００９１】
起動時時刻信頼性判定モジュール（２１１）はステップＳ４０１から処理を開始する。
【００９２】
ステップＳ４１０にて時計信頼性低下状態である場合には、処理はステップＳ８０１へ進み、当該内蔵時計インターフェース（２０９）を経て取得した時刻情報の日付の確度が高いかどうかを判定する。ここで日付の確度が高いとは、これまでに時計信頼性が高い状態で記録されたログのみに着目し、その時刻に対して逆行しておらず、日付が妥当な範囲に収まっていると認められることを言う。すなわち、図９に示したようなログが残っているときに、現在時刻が、２００９年５月２７日０８時１０分のように、逆行しておらず、日付も自然な範囲に納まっている場合に日付の確度が高いものと判定する。ここで、ログ番号２６０４０９４のログは時計信頼性が低下している間に記録されているため、参照しない。
【００９３】
このようにしてステップＳ８０１にて日付の確度が高いと判定された場合には処理はステップＳ４１１へ進む。そうでない場合にはステップＳ４１４へ進む。
【００９４】
またステップＳ４０８にて時間の進行幅が閾値を超えていないと判定された場合には処理はステップＳ８０２へすすむ。
【００９５】
ステップＳ８０２では時計信頼性が低下状態であるかどうかを判定する。そうであればステップＳ８０３へ進む。そうでなければステップＳ４１４へ進む。
【００９６】
ステップＳ８０３では、日付の確度が高いかどうかをステップＳ８０１と同様に判定する。確度が高い場合にはステップＳ４１１へ進む。そうでなければステップＳ４１４へ進む。
【００９７】
ステップＳ４１４にて起動時時刻信頼性判定モジュール（２１１）の処理が終了する。
【００９８】
本発明の、第二の実施例の、管理エージェント（１０３）の受信時時刻信頼性判定モジュール（２１２）の動作は図５に示したものと同様である。
【００９９】
また本発明の、第二の実施例の、管理エージェント（１０３）のタイマーモジュール（２０５）のタイマー実行動作は図６に示したものと同様である。
【０１００】
さらに、本発明の、第二の実施例の、管理エージェント（１０３）の起動時タイマー再設定ステップ（Ｓ４１２）および受信時タイマー再設定ステップ（５０９）の動作は図７に示したものと同様である。
【０１０１】
これまでに見てきたように、本実施例においては、第一の実施例とは違い、起動時時計信頼性判定モジュール（２１１）は時計信頼性低下状態において単に時刻が逆行したり閾値を超えて進行していたりするだけで信頼性を回復したと判断しない。例えば単に電源を落とすたびに時計がリセットされるような故障を起こしたデバイスが存在していた場合などを考える。この場合第一の実施例では起動されるたびに時計信頼性高状態を推定する動作と時計信頼性低下状態を推定する動作とを繰返すのみとなってしまう。このように第一の実施例のみでは、必ずしも時計の信頼性状態を正しく推定できていないケースがあることが否定できない。
【０１０２】
しかしこのようなケースであっても、デバイスの稼動中に時計が修正されて信頼性が回復する可能性がある場合は、本発明の、第二の実施例を用いれば、その間に記録されたログの時刻を用いることが可能になる。これにより、次回以降の起動時においても時計の信頼性を正しく判定することができる可能性が大きくなる。
【０１０３】
このように、本発明の第二の実施例を用いると、時計の信頼性の、判定の精度をより向上させることができる。
【０１０４】
（第三の実施例）
次に、本発明の、第三の実施例について、図を交えて説明する。
【０１０５】
本発明の、第三の実施例の、ネットワークデバイス管理システムの構成は図１に示したものと同様である。
【０１０６】
本発明の、第三の実施例の、管理エージェント（１０３）のソフトウェアモジュール構成は図２に示したものと同様である。
【０１０７】
さらに本発明の、第三の実施例の、管理エージェント（１０３）の管理行為実行予定記憶領域（２０６）に格納される管理行為実行予定のデータ形式は図３に示したものと同様である。
【０１０８】
図１０は本発明の、第三の実施例の、管理エージェント（１０３）のログモジュール（２０３）が記録しログ保持領域（２０４）に保持されているログのデータ構造を模式的に示したものである。９０１から９０５は図９に示したものと同様であるので説明を省略する。１００１はＰＣ時刻である。このＰＣ時刻は、ログに記録された管理行為が管理アプリケーション（１０５）から管理操作リクエストを受信したものである場合にのみ記録されるものである。このＰＣ時刻として記録されるのは、当該管理操作リクエストに管理アプリケーション（１０５）が付与した、当該情報装置（１０４）の内蔵時計の指示する時刻の情報に基づく時刻である。
【０１０９】
本発明の、第三の実施例の管理エージェント（１０３）の起動時時刻信頼性判定モジュール（２１１）の動作は図８のフローチャートに示したものと同様である。本実施例においては、図８のステップＳ８０１およびステップＳ８０３において、日付の確度が高いかどうかを判定する際に、図１０に示したログデータのＰＣ時刻（１００１）を参照する。ＰＣ時刻の日付と、当該起動時時刻信頼性判定モジュール（２１１）が内蔵時計インターフェース（２１３）から取得した時刻の情報に含まれる日付とが一致するか、非常に近い場合に、日付の確度が高いと判定される。
【０１１０】
もしもログ記録の列の中で近接するログの間でＰＣ時刻の示す日付にバラツキがあり、一定の判定を下すことが難しい状況であれば日付の確度は高くないと判定される。
【０１１１】
本実施例によれば、第二の実施例と同様に起動時時刻信頼性判定モジュール（２１１）において、日付の確度の判定を行うことによって信頼性判定の精度を向上させることができる。
【０１１２】
また本実施例では、第二の実施例のように時計の信頼性が高い状態をすべて参照して日付の確度の判定を行うことをせず、受信時の情報処理装置（１０４）の時刻との比較のみを行う。情報処理装置（１０４）の時刻は、デバイス（１０２）とは独立して計時されているために、デバイス（１０２）の影響を受けにくいという特徴がある。また管理エージェント（１０３）は複数の情報処理装置（１０４）からの管理操作リクエストを受信することがあり得るため、それらの日付が相互に近い値を示している場合にはその信頼性はさらに高いと判断可能である。これらにより、本実施例では、より日付の確度について精度の高い判断基準を得ることが可能になり、全体として時計の信頼性についての判定の精度が向上する。
【符号の説明】
【０１１３】
１０３  管理エージェント
【図１】
2011008470.tif 000003
【図２】
2011008470.tif 000004
【図３】
2011008470.tif 000005
【図４】
2011008470.tif 000006
【図５】
2011008470.tif 000007
【図６】
2011008470.tif 000008
【図７】
2011008470.tif 000009
【図８】
2011008470.tif 000010
【図９】
2011008470.tif 000011
【図１０】
2011008470.tif 000012