(57)【要約】【課題】更新プログラムの有無を確認するタイミングが分散されるように動作することができる電子機器を提供する。【解決手段】実施形態によれば、電子機器は、ポリシー取得部と、乱数生成部と、確認時刻決定部とを具備する。前記ポリシー取得部は、更新プログラムが格納される共有記憶領域を示す情報と、前記共有記憶領域内における前記更新プログラムの有無を確認する時間帯を示す情報とを含むポリシー情報を取得する。前記乱数生成部は、乱数を生成する。前記確認時刻決定部は、前記ポリシー情報に含まれる前記時間帯を所定の時間単位で分割して前記更新プログラムの有無を確認する複数の候補時刻を生成し、前記乱数を用いて前記複数の候補時刻の中から１つを選択し、前記更新プログラムの有無を確認する確認時刻として決定する。【選択図】図３
2020021229.tif 000002
【特許請求の範囲】
【請求項１】
更新プログラムが格納される共有記憶領域を示す情報と、前記共有記憶領域内における前記更新プログラムの有無を確認する時間帯を示す情報とを含むポリシー情報を取得するポリシー取得部と、
乱数を生成する乱数生成部と、
前記ポリシー情報に含まれる前記時間帯を所定の時間単位で分割して前記更新プログラムの有無を確認する複数の候補時刻を生成し、前記乱数を用いて前記複数の候補時刻の中から１つを選択し、前記更新プログラムの有無を確認する確認時刻として決定する確認時刻決定部と、
を具備する電子機器。
【請求項２】
前記確認時刻を用いて前記更新プログラムの有無を確認する予定日時をスケジュールするスケジュール部をさらに具備し、
前記スケジュール部は、
前記更新プログラムの有無の確認が実行された場合、翌日の前記確認時刻に再実行されるように前記予定日時をスケジュールし、
前記電子機器のシステム時刻が前記予定日時を過ぎている場合、前記電子機器の起動時、スリープからの復帰時、または休止からの復帰時か否かを判定し、前記電子機器の起動時、スリープからの復帰時、または休止からの復帰時である場合、前記更新プログラムの有無の確認が、当日または翌日の前記確認時刻に実行されるように前記予定日時をスケジュールする、
請求項１に記載の電子機器。
【請求項３】
前記スケジュール部は、前記システム時刻の時分秒が前記確認時刻を超えているか否かを判定し、超えていない場合、前記更新プログラムの有無の確認が、当日の前記確認時刻に実行されるように前記予定日時をスケジュールする請求項２に記載の電子機器。
【請求項４】
前記スケジュール部は、前記システム時刻の時分秒が前記確認時刻を超えている場合、前記確認時刻決定部に対して、前記システム時刻の時分秒に一定値を加えた時刻から前記ポリシー情報に含まれる前記時間帯の終了時刻までを範囲として前記更新プログラムの有無を確認する確認時刻を決定することを依頼し、前記更新プログラムの有無の確認が、依頼により前記確認時刻決定部で決定される前記確認時刻に実行されるように前記予定日時をスケジュールする請求項２に記載の電子機器。
【請求項５】
電子機器によって実行される更新プログラム確認方法であって、
乱数を生成することと、
更新プログラムが格納される共有記憶領域を示す情報と、前記共有記憶領域内における前記更新プログラムの有無を確認する時間帯を示す情報とを含むポリシー情報に含まれる前記時間帯を所定の時間単位で分割して前記更新プログラムの有無を確認する複数の候補時刻を生成することと、
前記乱数を用いて前記複数の候補時刻の中から１つを選択し、前記更新プログラムの有無を確認する確認時刻として決定することと、
を具備する更新プログラム確認方法。
【請求項６】
前記確認時刻を用いて前記更新プログラムの有無を確認する予定日時をスケジュールすることを具備し、
前記スケジュールすることは、
前記更新プログラムの有無の確認が実行された場合、翌日の前記確認時刻に再実行されるように前記予定日時をスケジュールすることと、
前記電子機器のシステム時刻が前記予定日時を過ぎている場合、前記電子機器の起動時、スリープからの復帰時、または休止からの復帰時か否かを判定し、前記電子機器の起動時、スリープからの復帰時、または休止からの復帰時である場合、前記更新プログラムの有無の確認が、当日または翌日の前記確認時刻に実行されるように前記予定日時をスケジュールすることと、
を含む請求項５に記載の更新プログラム確認方法。
【請求項７】
前記スケジュールすることは、前記システム時刻の時分秒が前記確認時刻を超えているか否かを判定し、超えていない場合、前記更新プログラムの有無の確認が、当日の前記確認時刻に実行されるように前記予定日時をスケジュールすることを含む請求項６に記載の更新プログラム確認方法。
【請求項８】
前記スケジュールすることは、前記システム時刻の時分秒が前記確認時刻を超えている場合、前記確認時刻を決定することに対して、前記システム時刻の時分秒に一定値を加えた時刻から前記ポリシー情報に含まれる前記時間帯の終了時刻までを範囲として前記更新プログラムの有無を確認する確認時刻を決定することを依頼し、前記更新プログラムの有無の確認が、依頼により決定された前記確認時刻に実行されるように前記予定日時をスケジュールすることを含む請求項６に記載の更新プログラム確認方法。
【請求項９】
コンピュータを、
更新プログラムが格納される共有記憶領域を示す情報と、前記共有記憶領域内における前記更新プログラムの有無を確認する時間帯を示す情報とを含むポリシー情報を取得するポリシー取得部、
乱数を生成する乱数生成部、
前記ポリシー情報に含まれる前記時間帯を所定の時間単位で分割して前記更新プログラムの有無を確認する複数の候補時刻を生成し、前記乱数を用いて前記複数の候補時刻の中から１つを選択し、前記更新プログラムの有無を確認する確認時刻として決定する確認時刻決定部、
として機能させるためのプログラム。
【請求項１０】
前記コンピュータを、前記確認時刻を用いて前記更新プログラムの有無を確認する予定日時をスケジュールするスケジュール部としてさらに機能させ、
前記スケジュール部は、
前記更新プログラムの有無の確認が実行された場合、翌日の前記確認時刻に再実行されるように前記予定日時をスケジュールし、
前記コンピュータのシステム時刻が前記予定日時を過ぎている場合、前記コンピュータの起動時、スリープからの復帰時、または休止からの復帰時か否かを判定し、前記コンピュータの起動時、スリープからの復帰時、または休止からの復帰時である場合、前記更新プログラムの有無の確認が、翌日の前記確認時刻に実行されるように前記予定日時をスケジュールする、
請求項９に記載のプログラム。
【請求項１１】
前記スケジュール部は、前記システム時刻の時分秒が前記確認時刻を超えているか否かを判定し、超えていない場合、前記更新プログラムの有無の確認が、当日の前記確認時刻に実行されるように前記予定日時をスケジュールする請求項１０に記載のプログラム。
【請求項１２】
前記スケジュール部は、前記システム時刻の時分秒が前記確認時刻を超えている場合、前記確認時刻決定部に対して、前記システム時刻の時分秒に一定値を加えた時刻から前記ポリシー情報に含まれる前記時間帯の終了時刻までを範囲として前記更新プログラムの有無を確認する確認時刻を決定することを依頼し、前記更新プログラムの有無の確認が、依頼により前記確認時刻決定部で決定される前記確認時刻に実行されるように前記予定日時をスケジュールする請求項１０に記載のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、電子機器、更新プログラム確認方法およびプログラムに関する。
【背景技術】
【０００２】
近年、たとえば企業などにおいて社員が業務に使用する多数のＰＣ（Personal Computer）を一元管理するためのシステムが種々運用されている。この種のシステムの主要な機能の１つとして、管理対象のＰＣにインストールされているプログラムのバーションアップを管理する機能が存在する。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特許第５３７８４５６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
プログラムのバーションアップは、プログラムの販売元から配布される更新プログラムを、そのプログラムがインストールされているＰＣで実行することによって実施する。たとえば、更新プログラムの配布を受けたシステム管理者が、ＬＡＮ（Local Area Network）に接続されるファイルサーバに更新プログラムを格納しておき、各ＰＣが、適用すべき更新プログラムがファイルサーバに存在するか否かを定期的に確認して、存在する場合、その更新プログラムを取得して実行するという運用が考えられる。
【０００５】
この運用の場合、各ＰＣからファイルサーバへのアクセスが発生するので、ＬＡＮが輻輳しないように、そのアクセスを分散させる必要がある。従来、このようなアクセスの分散は、各ＰＣの運用管理を担う運用管理サーバによって制御されている。つまり、このようなアクセスの分散を行うためには、各ＰＣの運用管理を担う運用管理サーバの存在が必須であった。
【０００６】
本発明が解決しようとする課題は、更新プログラムの有無を確認するタイミングが分散されるように動作することができる電子機器、更新プログラム確認方法およびプログラムを提供することである。
【課題を解決するための手段】
【０００７】
実施形態によれば、電子機器は、ポリシー取得部と、乱数生成部と、確認時刻決定部とを具備する。前記ポリシー取得部は、更新プログラムが格納される共有記憶領域を示す情報と、前記共有記憶領域内における前記更新プログラムの有無を確認する時間帯を示す情報とを含むポリシー情報を取得する。前記乱数生成部は、乱数を生成する。前記確認時刻決定部は、前記ポリシー情報に含まれる前記時間帯を所定の時間単位で分割して前記更新プログラムの有無を確認する複数の候補時刻を生成し、前記乱数を用いて前記複数の候補時刻の中から１つを選択し、前記更新プログラムの有無を確認する確認時刻として決定する。
【図面の簡単な説明】
【０００８】
【図１】実施形態の電子機器が置かれ得るいくつかの動作環境例を示す図。
【図２】実施形態の電子機器のハードウェア構成の一例を示す図。
【図３】実施形態の電子機器上で動作する更新プログラム確認ユーティリティの機能ブロックの一例を示す図。
【図４】実施形態の電子機器上で動作する更新プログラム確認ユーティリティによって使用されるポリシー情報の設定画面の一例を示す図。
【図５】実施形態の電子機器上で動作する更新プログラム確認ユーティリティによる更新プログラムの有無の確認時刻の決定規則を説明するための図。
【図６】実施形態の電子機器の更新プログラム有無確認時刻決定時の動作手順を示すフローチャート。
【図７】実施形態の電子機器の更新プログラム有無確認のスケジューリングおよび実行タイミング判定の動作手順を示すフローチャート。
【図８】実施形態の電子機器の臨時の更新プログラムの確認予定日時の決定処理の動作手順を示すフローチャート。
【発明を実施するための形態】
【０００９】
以下、実施の形態について図面を参照して説明する。
図１は、本実施形態の電子機器（クライアントＰＣ）１が置かれ得るいくつかの動作環境例を示す図である。クライアントＰＣ１は、たとえば企業が業務用に社員へ貸与するＰＣである。
ここでは、たとえばクライアントＰＣ１が部外者に持ち去られたとしても、そのクライアントＰＣ１内の情報が漏えいすることがないように、クライアントＰＣ１がストレージへ書き込むデータを暗号化し、また、ストレージから読み出される暗号化されたデータを復号するセキュリティソフトウェア（プログラム）がクライアントＰＣ１にインストールされているものと想定する。このセキュリティソフトウェアがインストールされたクライアントＰＣ１上で動作するアプリケーションプログラムがストレージへデータを書き込もうとすると、そのアプリケーションプログラムが暗号化を意識することなく、当該データが暗号化されてストレージへ書き込まれる。アプリケーションプログラムがストレージからデータを読み出そうとすると、そのアプリケーションプログラムが復号を意識することなく、ストレージから読み出された暗号化されたデータが復号される。このセキュリティソフトウェアは、ログオン時に正規ユーザが認証された場合にのみ作動する。ストレージは、クライアントＰＣ１内のストレージに限らず、たとえばＵＳＢ（Universal Serial Bus）コネクタ経由で外部接続されるストレージも適用対象にすることができる。
【００１０】
クライアントＰＣ１にインストールされたセキュリティソフトウェアのバージョンアップを含む運用管理は、図１に示されるように、大きく分けて、（Ａ）、（Ｂ）、（Ｃ）の３つの形態に分類される。なお、図１には、（Ａ）〜（Ｃ）のそれぞれにおいてクライアントＰＣ１を１つずつ示しているが、クライアントＰＣ１は、多数存在している。
【００１１】
（Ａ）は、セキュリティソフトウェアの運用管理のためのサーバ（運用管理サーバ）を設けない形態であり、（Ｂ）は、セキュリティソフトウェアを導入する企業内にサーバ（運用管理サーバ２Ａ）を設けてＬＡＮ４に接続する形態であり、（Ｃ）は、セキュリティソフトウェアの運用管理サービスを提供する事業者のサーバ（サービス提供サーバ２Ｂ）をインターネット５経由で利用する形態である。
【００１２】
（Ａ）の形態の場合、たとえば、システム管理者が、セキュリティソフトウェアの販売元からのリリース情報を基に更新プログラムを入手して、すべてのクライアントＰＣ１がＬＡＮ４経由でアクセス可能な共有記憶領域である、ファイルサーバ３配下の所定のストレージ内の所定のフォルダ内に格納する。（Ｂ），（Ｃ）の形態の場合も、たとえば、運用管理サーバ２Ａやサービス提供サーバ２Ｂの管理者が、セキュリティソフトウェアの販売元からのリリース情報を基に更新プログラムを入手して、ファイルサーバ３配下の所定のストレージ内の所定のフォルダ内に格納する。
【００１３】
この（Ａ）〜（Ｃ）のいずれの形態下の動作環境に置かれた場合も、クライアントＰＣ１は、管理者ＰＣ２、運用管理サーバ２Ａまたはサービス提供サーバ２Ｂから送られるポリシー情報（ａ１）を受信し（図１：（１））、このポリシー情報に基づき、更新プログラム（ａ２）の有無を確認するためのファイルサーバ３へのアクセス（図１：（２））を定期的に実行する。ここでは、日次処理として実行するものと想定する。ポリシー情報には、更新プログラムが格納されるファイルサーバ３配下の所定のストレージ内の所定のフォルダを示す情報と、更新プログラムの有無を確認する時間帯（開始時刻−終了時刻）を示す情報とが少なくとも含まれている。ポリシー情報は、たとえば社内のすべてのクライアントＰＣ１に共通の１つのポリシー情報が用意されてもよいし、たとえば部署ごとに複数のポリシー情報が用意されてもよい。
【００１４】
更新プログラムが存在する場合、クライアントＰＣ１は、その更新プログラムをファイルサーバ３から取得し（図１：（３））、実行する。これにより、セキュリティソフトウェアのバージョンアップが完了する。（Ａ）の形態の場合、クライアントＰＣ１は、セキュリティソフトウェアのバージョンアップの完了時、その旨をファイルサーバ３配下の所定のストレージ内の所定のフォルダに格納される更新記録ファイル（ａ３）に記録する（図１：（４））。システム管理者は、更新記録ファイルを参照することで、どのクライアントＰＣ１がセキュリティソフトウェアのバージョンアップを完了させているか等を確認することができる。なお、この更新記録ファイルへの記録の実行有無は、ポリシー情報によって切り替えることができる。（Ｂ），（Ｃ）の形態の場合は、ファイルサーバ３に記録される、更新プログラムが格納されるフォルダへのアクセスを行ったクライアントＰＣ１を示す情報が運用管理サーバ２Ａやサービス提供サーバ２Ｂによって取得されて、どのクライアントＰＣ１がセキュリティソフトウェアのバージョンアップを完了させているか等が管理される。
【００１５】
図１に示されるように、（Ａ）〜（Ｃ）のいずれの形態の場合も、更新プログラムの有無の確認時、クライアントＰＣ１からファイルサーバ３へのアクセスが発生する。したがって、ＬＡＮ４が輻輳しないように、そのアクセスを分散させる必要がある。そこで、本実施形態の電子機器（クライアントＰＣ）１は、更新プログラムの有無を確認するタイミングが分散されるように動作する仕組みを備えたものであり、以下、この点について詳述する。
【００１６】
図２は、クライアントＰＣ１のハードウェア構成の一例を示す図である。
図２に示されるように、クライアントＰＣ１は、プロセッサ１１、システムコントローラ１２、主メモリ１３、ＢＩＯＳ（Basic Input/Output System）−ＲＯＭ１４、ストレージデバイス１５を有している。また、クライアントＰＣ１は、ディスプレイデバイス１６、マイク／スピーカ１７、通信デバイス１８、ＵＳＢコネクタ１９、ＥＣ（Embedded Controller）／ＫＢＣ（Keyboard Controller）２０を有している。さらに、クライアントＰＣ１は、キーボード／ポインティングデバイス２１、電源スイッチ２２、ＰＳＣ（Power Supply Controller）２３、バッテリ２４、ＡＣアダプタ２５を有している。
【００１７】
プロセッサ１１は、クライアントＰＣ１内の各コンポーネントを制御するデバイスであって、ストレージデバイス１５に格納される各種プログラムを主メモリ１３にロードして実行することによって、クライアントＰＣ１に様々な処理を実行させる。各種プログラムの中には、ＯＳ（Operating System）や、当該ＯＳの制御下で動作するアプリケーションプログラムが含まれる。前述のセキュリティソフトウェアは、このアプリケーションプログラムの１つである。セキュリティソフトウェアは、常駐プログラムとしてクライアントＰＣ１に組み込まれている。また、プロセッサ１１は、ＢＩＯＳ−ＲＯＭ１４に格納されるＢＩＯＳを実行する。
【００１８】
主メモリ１３は、クライアントＰＣ１の主記憶として利用される、たとえばＤＲＡＭなどのストレージである。ＢＩＯＳ−ＲＯＭ１４は、ＢＩＯＳや各種環境設定値を書き換え可能に格納する、たとえばＥＥＰＲＯＭなどのストレージである。ストレージデバイス１５は、クライアントＰＣ１の外部記憶として利用される、たとえばＳＳＤ（Solid State drive）などのストレージである。
【００１９】
システムコントローラ１２は、クライアントＰＣ１内の各コンポーネントを相互接続するデバイスである。また、システムコントローラ１２は、たとえば主メモリ１３、ＢＩＯＳ−ＲＯＭ１４、ストレージデバイス１５に対するアクセスを制御するコントローラ、ディスプレイデバイス１６への画像表示を制御するコントローラ、マイク／スピーカ１７を介した音声の入出力を制御するコントローラ、通信デバイス１８を介した外部機器との通信を制御するコントローラ、ＵＳＢコネクタ１９に接続されるＵＳＢデバイスとの通信を制御するコントローラ等、様々なコントローラを内蔵している。
【００２０】
ディスプレイデバイス１６は、クライアントＰＣ１が提供するユーザインタフェースのアウトプットを担うデバイスであり、プロセッサ１１が描画した表示画面を表示する。マイク／スピーカ１７は、音声を入力／出力するデバイスである。通信デバイス１８は、たとえば図１に示したＬＡＮ４またはインターネット５経由の外部機器（管理者ＰＣ２，運用管理サーバ２Ａ，サービス提供サーバ２Ｂ，ファイルサーバ３，その他）との間の通信を実行するデバイスである。ＵＳＢコネクタ１９は、たとえばＵＳＢメモリなどのＵＳＢデバイスを着脱自在な連結ユニットである。
【００２１】
ＥＣ／ＫＢＣ２０は、第１に、クライアントＰＣ１が提供するユーザインタフェースのインプットを担うデバイスであるキーボード／ポインティングデバイス２１によるデータ入力を受付けるコントローラである。また、ＥＣ／ＫＢＣ２０は、第２に、ＰＳＣ２３と協働して、電源スイッチ２２の操作に応じてクライアントＰＣ１の電源オン／電源オフを制御するコントローラである。
【００２２】
ＰＳＣ２３は、バッテリ２４またはＡＣアダプタ２５からの電力を用いて、クライアントＰＣ１の各コンポーネントの動作用電力を生成して供給するコントローラである。ＰＳＣ２３は、バッテリ２４の充放電も制御する。ＡＣアダプタ２５からの電力供給がない場合、ＰＳＣ２３は、バッテリ２４を放電させて、バッテリ２４からの電力によって各コンポーネントの動作用電力を生成する。ＡＣアダプタ２５からの電力供給がある場合、ＰＳＣ２３は、ＡＣアダプタ２５からの電力によって各コンポーネントの動作用電力を生成するとともに、ＡＣアダプタ２５からの電力によってバッテリ２４を充電する。なお、ＰＳＣ２３は、クライアントＰＣ１が電源オフの間も動作しており、ＥＣ／ＫＢＣ２０に対する電力供給を継続して実行する。
【００２３】
図３は、以上のようなハードウェア構成のクライアントＰＣ１上で動作する、更新プログラムの有無の確認を行う更新プログラム確認ユーティリティ（プログラム）１００の機能ブロックの一例を示す図である。
更新プログラム確認ユーティリティ１００は、前述のセキュリティソフトウェアの一モジュールとして存在してもよいし、セキュリティソフトウェアに付随して提供される別プログラムとして存在してもよい。更新プログラム確認ユーティリティ１００が実行されることによって、図３に示される、ポリシー取得部１０１、確認時刻決定部１０２、乱数生成部１０３、更新プログラム確認スケジュール部１０４、システム時刻取得部１０５、更新プログラム確認／取得部１０６、プログラム更新処理部１０７の各処理部が、クライアントＰＣ１上に構築される。更新プログラム確認ユーティリティ１００がセキュリティソフトウェアとは別プログラムとして存在する場合、当該更新プログラム確認ユーティリティ１００も、常駐プログラムとしてクライアントＰＣ１に組み込まれる。
【００２４】
ポリシー取得部１０１は、管理者ＰＣ２、運用管理サーバ２Ａまたはサービス提供サーバ２Ｂから送られるポリシー情報を受信する。図１に示した（Ａ）の形態の場合、このポリシー情報を作成するためのユーティリティ（プログラム）が管理者ＰＣ２にインストールされる。図４は、このユーティリティによって管理者ＰＣ２上において表示されるポリシー情報の設定画面の一例を示す図である。
【００２５】
図４に示されるように、ポリシー情報の設定画面には、符号ｂ１で示されるクライアントソフトウェア更新プログラムタグが配置される。システム管理者は、クライアントソフトウェア更新プログラムタグｂ１を選択することによって、クライアントＰＣ１による更新プログラムの有無の確認に関する設定を行うための画面を表示させることができる。図４は、クライアントソフトウェア更新プログラムタグｂ１が選択された場合におけるポリシー情報の設定画面の一例を示している。
【００２６】
クライアントソフトウェア更新プログラムタグｂ１が選択された場合に表示されるポリシー情報の設定画面上には、図４に示されるように、まず、符号ｂ２で示されるチェックボックスが配置される。システム管理者は、更新プログラムの有無の定期的な確認をクライアントＰＣ１に実行させる場合、チェックボックスｂ２をオンにする。チェックボックスｂ２をオフにすると、クライアントＰＣ１による更新プログラムの有無の定期的な確認は実行されないこととなる。
【００２７】
また、このポリシー情報の設定画面上には、更新プログラムが格納されるフォルダのパス（共有資源名）を入力するための入力フィールドｂ３が配置される。さらに、このポリシー情報の設定画面上には、更新プログラムの有無を確認する時間帯（開始時刻−終了時刻）を入力するための入力フィールドｂ４が配置される。たとえば９：００−１８：００が当該時間帯の初期値として設定されている。
【００２８】
また、このポリシー情報の設定画面上には、符号ｂ５で示されるチェックボックスが配置される。システム管理者は、セキュリティソフトウェアのバージョンアップ完了を示すための更新記録ファイルへの記録をクライアントＰＣ１に実行させる場合、チェックボックスｂ５をオンにする。チェックボックスｂ５をオフにすると、クライアントＰＣ１による更新記録ファイルへの記録は実行されないこととなる。また、このポリシー情報の設定画面上には、更新記録ファイルが作成されるフォルダのパス（共有資源名）を入力するための入力フィールドｂ６が配置される。
【００２９】
以上の各項目の入力が行われて、ポリシー情報の設定画面上のＯＫボタンｂ７が選択されると、その項目の入力が反映されたポリシー情報が作成される。作成されたポリシー情報は、管理者ＰＣ２からクライアントＰＣ１へと配信される。ポリシー情報の配信方法については、既知の様々な方法を適用することができる。ここでは、クライアントＰＣ１へ配信されるポリシー情報は、少なくとも更新プログラムの有無の確認は実行する旨を示しているものと想定する。
【００３０】
図３に戻り、更新プログラム確認ユーティリティ１００によってクライアントＰＣ１上に構築される各処理部の説明を続ける。
確認時刻決定部１０２は、乱数生成部１０３によって生成される乱数を用いて、ポリシー取得部１０１によって取得されるポリシー情報に基づき、更新プログラムの有無の確認を実行する時刻を決定する。前述したように、ポリシー情報には、更新プログラムの有無を確認する時間帯が示されている。確認時刻決定部１０２は、この時間帯の範囲内で、更新プログラムの有無の確認を実行する時刻を決定する。その決定規則について、図５を参照して説明する。なお、乱数生成部１０３は、たとえばＰＣで乱数を生成する場合の関数であるBCryptGenRandom APIなどを使用して乱数を生成する。
【００３１】
たとえば、図５（Ａ）に示されるように、ポリシー情報には、更新プログラムの有無を確認する時間帯として、初期値の9:00-18:00が示されているものと想定する。また、ここでは、時間帯を分割する粒度（時間単位）として、分単位が設定されているものと想定する。この粒度の設定値は、たとえば、更新プログラム確認ユーティリティ１００が固定値として保持するものであってもよいし、更新プログラム確認ユーティリティ１００の起動時にパラメータとして与えられるものであってもよい。
【００３２】
9:00-18:00の場合、9:00:00、9:01:00、・・・、17:59:00まで１分間のタイムストロットが５４０個存在する。確認時刻決定部１０２は、更新プログラムの有無の確認のためのファイルサーバ３へのアクセスが、他のクライアントＰＣ１との間で極力重複しないように、乱数を使用して、５４０個のタイムストロットの中から１つを選択し、更新プログラムの有無の確認時刻を決定する。
【００３３】
より詳しくは、生成された乱数を、ポリシー情報で示される時間帯に存在するタイムストロット数で割り算し、その余りの数値で確認時刻を決定する。たとえば、9:00-18:00の場合、図５（Ｂ）に示されるように、余りの数値として取得され得る0-539に５４０個のタイムスロットが一対に割り当てられる。たとえば、余りの数値として１が得られた場合、確認時刻決定部１０２は、更新プログラムの有無の確認時刻を9:01:00に決定する。
【００３４】
つまり、管理者ＰＣ２からポリシー情報を受信する多数のクライアントＰＣ１それぞれが、ポリシー情報で示される時間帯を所定の粒度で分割して複数の候補時刻を生成し、その中からいずれか１つを乱数によって選択することで、当該多数のクライアントＰＣ１による更新プログラムの有無の確認のためのファイルサーバ３へのアクセスを分散させることができる。
【００３５】
図３に戻り、更新プログラム確認ユーティリティ１００によってクライアントＰＣ１上に構築される各処理部の説明を続ける。
更新プログラム確認スケジュール部１０４は、確認時刻決定部１０２によって決定された確認時刻を用いて、更新プログラムの有無を確認する予定日時をスケジュールする。スケジュールした予定日時が到来すると、更新プログラム確認スケジュール部１０４は、更新プログラム確認／取得部１０６に対して、更新プログラムの有無の確認を実行することを依頼する。更新プログラム確認スケジュール部１０４は、たとえば、システム時刻取得部１０５によって取得されるシステム時刻を用いて、スケジュールした予定日時が到来したか否かを判定する。システム時刻取得部１０５は、たとえばシステム時刻を取得するための関数を用いて、クライアントＰＣ１のシステム時刻を取得する。なお、更新プログラム確認スケジュール部１０４自身が当該関数を用いてシステム時刻を取得してもよい。つまり、システム時刻取得部１０５の機能を備えていてもよい。
【００３６】
たとえば、更新プログラム確認／取得部１０６による更新プログラムの有無の確認が実行された場合、更新プログラム確認スケジュール部１０４は、確認時刻が9:01:00に決定されていたならば、翌日の9:01:00に、更新プログラム確認／取得部１０６による更新プログラムの有無の確認が実行されるように予定日時をスケジュールする。更新プログラム確認スケジュール部１０４による予定日時のスケジューリングは、更新プログラム確認／取得部１０６による更新プログラムの有無の確認の成否に関わらずに実行される。
【００３７】
更新プログラム確認／取得部１０６は、ポリシー情報で示されるパス（共有資源名）に基づき、ファイルサーバ３配下の所定のストレージ内の所定のフォルダ内に更新プログラムが存在するか否かを確認する。存在する場合、更新プログラム確認／取得部１０６は、更新プログラムをファイルサーバ３から取得する。プログラム更新処理部１０７は、更新プログラム確認／取得部１０６によって取得された更新プログラムを実行し、セキュリティソフトウェアをアップデートする。
【００３８】
ところで、クライアントＰＣ１が電源オンされた時刻が、更新プログラム確認スケジュール部１０４によってスケジュールされた予定日時を過ぎた後であったとすると、一般的には、その時点で、更新プログラム確認／取得部１０６による更新プログラムの有無の確認を実行する。この仕様だと、たとえば夏季休暇などの全社的な長期休暇明けの出勤初日の始業時刻に多数のクライアントＰＣ１が一斉にファイルサーバ３へアクセスすることになる。そこで、本実施形態のクライアントＰＣ１においては、このような状況下でも、更新プログラムの有無を確認するタイミングが分散されるように動作する仕組みをさらに備える。次に、この点について詳述する。
【００３９】
更新プログラム確認スケジュール部１０４は、クライアントＰＣ１の起動時、スリープからの復帰時、または休止からの復帰時、予定日時とシステム時刻との比較を実行し、以降、この比較を定期的に実行する。スリープとは、主メモリ１３への電力供給を維持しながらクライアントＰＣ１の電力消費を抑えた状態であり、休止とは、主メモリ１３の内容をストレージデバイス１５へ退避し、主メモリ１３への電力供給を遮断して、スリープよりもクライアントＰＣ１の電力消費を抑えた状態である。更新プログラム確認スケジュール部１０４は、システム時刻取得部１０５によって取得されるシステム時刻が、自身がスケジュールした予定日時を過ぎていた場合、その時の予定日時とシステム時刻との比較が、クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものか否かを判定する。クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものでない場合、更新プログラム確認スケジュール部１０４は、スケジュールした予定日時が到来したと判定して、更新プログラムの確認および次回の予定日時のスケジュールを実行する。
【００４０】
一方、クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものであった場合、更新プログラム確認スケジュール部１０４は、クライアントＰＣ１が電源オフ中、スリープ中、または休止中に、スケジュールした予定日時を過ぎたものと判定する。この場合、更新プログラム確認スケジュール部１０４は、システム時刻（時分秒）が、確認時刻決定部１０２によって決定された確認時刻を過ぎているか否かを調べる。過ぎていなければ、更新プログラム確認スケジュール部１０４は、その日の確認時刻に次の予定日時をスケジュールする。予定日時を過ぎていて、システム時刻（時分秒）が確認時刻を過ぎていない場合とは、たとえば、前々日の18:00に電源オフされたクライアントＰＣ１が、その日の11:00に電源オンされて、予定日時が前日の15:00（確認時刻）にスケジュールされていた場合などである。この場合、その日の15:00に予定日時がスケジュールされることになる。
【００４１】
システム時刻（時分秒）が確認時刻を過ぎている場合、更新プログラム確認スケジュール部１０４は、システム時刻に一定時間を加えた時刻から、ポリシー情報で示される時間帯の終了時刻までを範囲として、確認時刻決定部１０２に対して、確認時刻の決定を依頼する。更新プログラム確認スケジュール部１０４は、この時に確認時刻決定部１０２によって決定される確認時刻を用いて、当日に、次の予定日時をスケジュールする。予定日時を過ぎていて、システム時刻（時分秒）が確認時刻を過ぎている場合とは、たとえば、前々日の18:00に電源オフされたクライアントＰＣ１が、その日の11:00に電源オンされて、予定日時が前日の09:30（確認時刻）にスケジュールされていた場合などである。この場合、その日の確認時刻決定部１０２によって臨時的に決定される臨時確認時刻に予定日時がスケジュールされることになる。
【００４２】
このように、クライアントＰＣ１が電源オフ中、スリープ中、または休止中に予定日時が過ぎた場合であっても、クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時に、更新プログラムの有無の確認が即時実行されることはなく、ファイルサーバ３へのアクセスの分散が図られる。
【００４３】
また、予定日時に更新プログラムの確認が実行された場合、更新プログラム確認スケジュール部１０４は、本来の確認時刻を用いて、翌日に、予定日時をスケジュールする。本来の確認時刻を用いることで、更新プログラムの確認時刻が徐々に後ろへ偏っていくことを防止する。
【００４４】
これにより、多くの社員が閾値を超える長期休暇明けにクライアントＰＣ１が電源オンした場合であっても、クライアントＰＣ１からのファイルサーバ３へのアクセスが分散されることになる。また、その日、確認時刻よりも遅くにクライアントＰＣ１が電源オンされた場合においても、その日のうちに更新プログラムの有無が確認され、かつ、この確認についても、ファイルサーバ３へのアクセスを集中させないための処置が施される。
【００４５】
図６は、クライアントＰＣ１の更新プログラム有無確認時刻決定時の動作手順を示すフローチャートである。
クライアントＰＣ１は、ポリシーの確認スケジュールに設定されている開始時間から終了時間までの期間を所定の粒度の複数のタイムスロットに分割する（ステップＡ１）。また、クライアントＰＣ１は、乱数を作成する（ステップＡ２）。なお、ステップＡ１とステップＡ２とは、順序を逆にしてもよいし、並列に実行してもよい。
【００４６】
そして、クライアントＰＣ１は、乱数をタイムスロット数で割り算して得られる余りの数値に対応するタイムスロットを更新プログラムの有無の確認時刻に決定する（ステップＡ３）。
図７は、クライアントＰＣ１の更新プログラム有無確認のスケジューリングおよび実行タイミング判定の動作手順を示すフローチャートである。
【００４７】
まず、クライアントＰＣ１は、更新プログラムの確認予定日時とシステム時刻とを比較する（ステップＢ１）。システム時刻が更新プログラムの確認予定日時を過ぎていない場合（ステップＢ２：ＮＯ）、クライアントＰＣ１は、その時点での更新プログラム有無確認の実行タイミング判定その他の処理を終了する。
【００４８】
一方、システム時刻が更新プログラムの確認予定日時を過ぎている場合（ステップＢ２：ＹＥＳ）、クライアントＰＣ１は、続いて、この処理が、クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものであるか否かを判定する（ステップＢ３）。クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものでない場合（ステップＢ３：ＮＯ）、クライアントＰＣ１は、更新プログラムの確認を実行する（ステップＢ４）。
【００４９】
更新プログラムが存在する場合（ステップＢ５：ＹＥＳ）、クライアントＰＣ１は、その更新プログラムをファイルサーバ３から取得して実行し（ステップＢ６）。更新プログラム確認の実行日時をファイルサーバ３に記録する（ステップＢ７）。クライアントＰＣ１は、翌日の確認時刻に更新プログラムの確認が実行されるように予定日時をスケジュールし（ステップＢ８）、処理を終了する。
【００５０】
クライアントＰＣ１の起動時、スリープ状態からの復帰時、または休止状態からの復帰時のものであった場合は(ステップＢ３：ＹＥＳ)、クライアントＰＣ１は、図８にその動作手順を示す、臨時の更新プログラムの確認予定日時の決定処理を実行し（ステップＢ９）、処理を終了する。
【００５１】
図８は、臨時の更新プログラムの確認予定日時の決定処理の動作手順を示すフローチャートである。
クライアントＰＣ１は、更新プログラムの確認時刻が到来する前か否かを判定する（ステップＣ１）。到来前の場合（ステップＣ１：ＹＥＳ）、クライアントＰＣ１は、当日の確認時刻に更新プログラムの確認が実行されるように予定日時をスケジュールし（ステップＣ２）、処理を終了する。
【００５２】
更新プログラムの確認時刻が到来した後であった場合（ステップＣ１：ＮＯ）、クライアントＰＣ１は、システム時刻に一定時間（α）を加えた時刻から、ポリシー情報で示される時間帯の終了時刻までの期間を所定の粒度の複数のタイムスロットに分割する（ステップＣ３）。また、クライアントＰＣ１は、乱数を作成する（ステップＣ４）。なお、ステップＣ３とステップＣ４とは、順序を逆にしてもよいし、並列に実行してもよい。
【００５３】
次に、クライアントＰＣ１は、乱数をタイムスロット数で割り算して得られる余りの数値に対応するタイムスロットを更新プログラムの有無の臨時確認時刻に決定する（ステップＣ５）。そして、クライアントＰＣ１は、当日の臨時確認時刻に更新プログラムの確認が実行されるように予定日時をスケジュールし（ステップＣ６）、処理を終了する。
【００５４】
以上のように、本実施形態の電子機器（クライアントＰＣ）１は、更新プログラムの有無を確認するタイミングが分散されるように動作する。
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、特許請求の範囲に記載された発明とその均等の範囲に含まれる。
【符号の説明】
【００５５】
１…電子機器、２…管理者ＰＣ、２Ａ…運用管理サーバ、２Ｂ…サービス提供サーバ、３…ファイルサーバ、４…ＬＡＮ、５…インターネット、１１…プロセッサ、１３…主メモリ、１５…ストレージデバイス、１００…更新プログラム確認ユーティリティ、１０１…ポリシー取得部、１０２…確認時刻決定部、１０３…乱数生成部、１０４…更新プログラム確認スケジュール部、１０５…システム時刻取得部、１０６…更新プログラム確認／取得部、１０７…プログラム更新処理部。
【図１】
2020021229.tif 000003
【図２】
2020021229.tif 000004
【図３】
2020021229.tif 000005
【図４】
2020021229.tif 000006
【図５】
2020021229.tif 000007
【図６】
2020021229.tif 000008
【図７】
2020021229.tif 000009
【図８】
2020021229.tif 000010