終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法
【課題】基本ソフトウェアの終了に関するログを正確に取得すること。
【解決手段】クライアント端末１０は、ユーザによる自装置の起動命令に応じて、監視の開始を命令する第一の開始命令を受付ける。クライアント端末１０は、第一の開始命令を受付けた場合に、所定時間毎に基本ソフトから時刻に関する時刻情報を取得する。クライアント端末１０は、所定時間ごとに取得した時刻情報を記憶領域へ格納する。クライアント端末１０は、基本ソフトを終了させる終了命令を受付ける。クライアント端末１０は、終了命令が基本ソフトを用いて終了を命令するものであれば、正常終了情報を記憶領域に格納する。クライアント端末１０は、第二の開始命令を受付けた場合に記憶領域に正常終了情報がなければ、基本ソフトから他の時刻情報を取得し、他の時刻情報と記憶領域内の時刻情報とを比較した結果に基づいて、基本ソフトの終了に関するログ情報を生成する。
【解決手段】クライアント端末１０は、ユーザによる自装置の起動命令に応じて、監視の開始を命令する第一の開始命令を受付ける。クライアント端末１０は、第一の開始命令を受付けた場合に、所定時間毎に基本ソフトから時刻に関する時刻情報を取得する。クライアント端末１０は、所定時間ごとに取得した時刻情報を記憶領域へ格納する。クライアント端末１０は、基本ソフトを終了させる終了命令を受付ける。クライアント端末１０は、終了命令が基本ソフトを用いて終了を命令するものであれば、正常終了情報を記憶領域に格納する。クライアント端末１０は、第二の開始命令を受付けた場合に記憶領域に正常終了情報がなければ、基本ソフトから他の時刻情報を取得し、他の時刻情報と記憶領域内の時刻情報とを比較した結果に基づいて、基本ソフトの終了に関するログ情報を生成する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法に関する。
【背景技術】
【０００２】
情報漏えい対策として、組織等に所属するエンドユーザ（end user）によって利用されるコンピュータ（computer）の操作ログ（log）が採取される。かかるコンピュータの一態様としては、パソコン（personal computer）が挙げられる。このようにパソコンの操作ログを採取することによって、パソコンの監視、情報漏えいが起こった場合の検証、情報漏えいのリスクを管理するための分析などが可能になる。
【０００３】
このような操作ログの一態様としては、パソコンで動作する基本ソフトウェア、例えばＯＳ（Operating System）の終了に関するログが採取される。かかるＯＳの終了に関するログの一例としては、パソコンからのログオフ（log-off）のログやパソコンの終了ログが挙げられる。これらパソコンのログオフ及びパソコンの終了はＯＳによってなされる。このため、ＯＳの終了に関するログを採取するためには、ログ採取を目的とする監視アプリ（application program）にＯＳを監視させることにより、ユーザによってログオフされた時刻やパソコンが終了された時刻などを採取すればよい。
【０００４】
一方、パソコンをシャットダウン（shutdown）して正常終了できなかった場合に、ハード的に強制終了を実行するとともに、正常終了ではないことを示すログを取得する特許文献１の技術がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３３２２５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところが、上記の特許文献１の技術では、ユーザがＯＳの終了指示を入力せずに強制終了した場合には、監視アプリがＯＳの終了に関するログを採取することができない。
【０００７】
例えば、正常終了時には、ＯＳから取得された時刻情報、監視アプリがＯＳから取得して保持する時刻情報を、監視アプリが初期状態に修正するとともに正常終了した旨を示す正常終了ログが監視アプリによって生成される。時刻情報は、例えばＯＳの起動からの経過時間がカウントされたＯＳカウンタなどが考えられる。一方、正常終了されずに強制終了された場合には、監視アプリがＯＳから取得して保持しているＯＳカウンタをゼロに修正する余地はなく、ログを生成する余地もない。よって、監視アプリの起動時には、監視アプリが保持するＯＳカウンタがゼロでなければ、前回の監視アプリの終了時にＯＳの終了に関するログが生成されていないと判断し、監視アプリが前回に計測していた時刻を用いて、前回のＯＳの終了に関するログを生成することが想定される。
【０００８】
しかしながら、監視アプリが保持するＯＳカウンタがゼロであるか否かによってログを生成したのでは、ＯＳの終了に関するログを正確に取得することができないという問題がある。すなわち、監視アプリは、強制終了された場合だけでなく、監視アプリ自らが異常終了した場合にも、自らが保持するＯＳカウンタをゼロに修正することはできない。このため、パソコンが終了していないにもかかわらず、監視アプリが異常終了した場合にも再起動した監視アプリによってパソコンのログオフのログやパソコンの終了ログが生成される結果、誤ったログが生成されてしまうことになる。
【０００９】
開示の技術は、上記に鑑みてなされたものであって、基本ソフトウェアの終了に関するログを正確に取得できる終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
開示の終了ログ取得プログラムは、コンピュータに、ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記基本ソフトウェアを終了させる終了命令情報を受付ける処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納する処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスする処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較する処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理を実行させる。
【発明の効果】
【００１１】
開示の終了ログ取得プログラムの一つの態様によれば、基本ソフトウェアの終了に関するログを正確に取得できるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係る情報漏えい対処システムの構成を示す図である。
【図２】図２は、実施例１に係るクライアント端末の構成を示すブロック図である。
【図３】図３は、ログオンユーザリストの一例を示す図である。
【図４】図４は、ログ情報の一例を示す図である。
【図５】図５は、時刻情報の一例を示す図である。
【図６】図６は、ＯＳ実行部から取得されたＳＩＤリストの一例を示す図である。
【図７】図７は、ログオンユーザリストの更新例を示す図である。
【図８】図８は、ログオンログの生成例を示す図である。
【図９】図９は、ログオンユーザリストの更新例を示す図である。
【図１０】図１０は、ログオフログの生成例を示す図である。
【図１１】図１１は、時刻情報のクリアを説明するための図である。
【図１２】図１２は、実施例１に係るログオンログオフ監視処理の手順を示すフローチャートである。
【図１３】図１３は、実施例１に係る終了ログ取得処理の手順を示すフローチャートである。
【図１４】図１４は、実施例２に係る終了ログ取得プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１４】
［システム構成］
まず、実施例１に係る情報漏えい対処システムについて説明する。図１は、実施例１に係る情報漏えい対処システムの構成を示す図である。なお、図１の例では、組織に所属するエンドユーザ（end user）によって使用されるクライアント端末１０Ａ〜１０Ｃで採取された操作ログ（log）を管理サーバ１０に収集することにより、ユーザによる情報漏えいに対処する例を想定する。
【００１５】
図１に示す情報漏えい対処システム１には、複数のクライアント端末１０Ａ〜１０Ｃと、管理サーバ３０と、コンソール５０とが収容される。なお、図１の例では、３つのクライアント端末、１つの管理サーバ、１つのコンソールをそれぞれ図示したが、開示のシステムは図示の構成に限定されない。すなわち、情報漏えい対処システム１は、任意の数のクライアント端末、管理サーバおよびコンソールを収容できる。以下では、クライアント端末１０Ａ〜１０Ｃの各装置を区別なく総称する場合には、「クライアント端末１０」と記載する。なお、クライアント端末１０Ａが、管理サーバ３０として動作することもでき、また、管理サーバ３０にクライアント端末１０の機能を同居させることもできる。
【００１６】
これらクライアント端末１０Ａ〜１０Ｃと管理サーバ３０とは、ネットワーク（network）３を介して相互に通信可能に接続される。かかるネットワーク３には、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、図１の例では、管理サーバ３０とコンソール５０とが直接接続される場合を例示したが、両者はネットワークを介して接続されることとしてもかまわない。
【００１７】
管理サーバ（server）３０は、クライアント端末１０を管理するサーバ装置である。この管理サーバ３０は、情報漏えいに対処するための情報漏えい対処ソフト（software）をネットワーク３経由で自装置に接続されるクライアント端末１０にそれぞれダウンロードさせた後にインストール（install）させる。かかる情報漏えい対処ソフトには、機能ごとにモジュール化された複数のアプリケーション（application software）が含まれる。なお、以下では、アプリケーションのことを「アプリ」と略記する。
【００１８】
これら情報漏えい対処ソフトに含まれるアプリの一例としては、ログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリなどが挙げられる。このうち、ログオフログオン監視アプリは、一例として、クライアント端末１０で動作するＯＳ（operating system）に対するログオン（log-on）やログオフ（log-off）のログを採取する機能を有する。さらに、ログオフログオン監視アプリは、クライアント端末１０の終了、いわゆるシャットダウン（shutdown）のログを採取する機能を有する。メール監視アプリは、一例として、メール（mail）の送信ログを採取する機能を有する。また、アクセス監視アプリは、一例として、ＷＥＢ（world wide web）のアクセスログを採取する機能を有する。なお、以下では、上記３つのアプリを「監視アプリ」と総称する。
【００１９】
なお、ここでは、クライアント端末１０の操作ログを採取する監視アプリについて例示したが、クライアント端末１０における特定の操作を禁止または制限する監視アプリをインストールさせることとしてもかまわない。また、ここでは、管理サーバ３０からダウンロードされた情報漏えい対処ソフトをクライアント端末１０にインストールさせる場合を説明したが、インストールの形態はこれに限定されない。一例としては、フレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの可搬用の物理媒体を経由して情報漏えい対処ソフトをクライアント端末１０にインストールさせることとしてもよい。他の一例としては、クライアント端末１０に情報漏えい対処ソフトをプリインストールさせることとしてもよい。
【００２０】
このようにしてクライアント端末１０にインストールされた監視アプリによって、管理サーバ３０は、各クライアント端末１０Ａ〜１０Ｃにおける操作ログ、例えばログオンやログオフのログ、終了ログ、メール送信ログやアクセスログを収集する。かかる操作ログの収集は、管理サーバ３０及びクライアント端末１０がネットワーク３を介して接続状態にある場合には、任意のタイミング（timing）で操作ログを収集できる。一例としては、クライアント端末１０で監視アプリによって操作ログが収集される度にその操作ログをリアルタイム（real time）で収集することができる。他の一例としては、クライアント端末１０が起動されたことを契機に監視アプリによって採取されていた操作ログを収集することもできる。
【００２１】
コンソール（console）５０は、管理者権限（administrators）を有する者によって使用される端末である。なお、管理者権限は、システム管理者によって予め設定される。かかるコンソール５０の機能の一例としては、管理サーバ３０に収集された操作ログを閲覧する機能の他、クライアント端末１０で動作する監視アプリによって採取させる操作ログのポリシー（policy）を管理サーバ３０に設定する機能などが挙げられる。なお、ここで言う「ポリシー」とは、クライアント端末１０の操作ログ、例えばログオンログ、ログオフログ、終了ログ、メール送信ログやアクセスログのうちいずれの操作ログの採取をクライアント端末１０で有効または無効とさせるかという方針を指す。
【００２２】
クライアント端末１０は、エンドユーザによって使用される端末装置である。かかるクライアント端末１０の一態様としては、パソコン（ＰＣ：personal computer）を始めとする固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末も採用できる。なお、ここでは、一例として、パソコン、以下「ＰＣ」と略記をクライアント端末１０とする場合を想定して以下の説明を行うが、他の情報処理装置を使用する場合も同様である。
【００２３】
かかるクライアント端末１０には、上述した複数の監視アプリがインストールされる。このようしてクライアント端末１０にインストールされた監視アプリは、ＯＳの起動とともに自動的に起動される。これらの監視アプリは、ＯＳが動作中である限り、互いの生存状況、例えばプロセス（process）の起動の有無を監視する処理を継続する。そして、ある監視アプリの停止が他の監視アプリによって検知された場合には、他の監視アプリは、停止した監視アプリを再起動させる命令、例えばＡＰＩ（Application Program Interface）をクライアント端末１０のＯＳに出す。これによって、各監視アプリは、クライアント端末１０の電源がオン状態である限り、動作し続けることになる。
【００２４】
ここで、本実施例に係るクライアント端末１０は、ログオフログオン監視アプリの起動時に、前回にＯＳが正常に終了されていない場合には、前回の監視アプリの終了がＰＣの強制終了に伴うものであるのか、あるいは監視アプリが異常停止したのかを区別する。すなわち、本実施例に係るクライアント端末１０は、前回に監視アプリがＯＳ経由で取得した後に保持していた終了時刻と、今回の起動時に監視アプリがＯＳ経由で取得した起動時刻とを用いて、前回に監視アプリが終了した原因が上記のいずれであるかを判定する。つまり、本実施例に係るクライアント端末１０は、２つの時刻の差分、すなわち監視アプリの前回の終了時刻から今回の起動時刻までの期間が、他の監視アプリによって本監視アプリが再起動された可能性を否定するに値するものであるか否かを判定する。このとき、本実施例に係るクライアント端末１０は、ＰＣの再起動の所要時間に比べて他の監視アプリによる再起動の所要時間が短いという知見を利用し、他の監視アプリによる再起動が否定された場合に監視アプリの終了の原因がＰＣの強制終了にあると判定する。そして、本実施例に係るクライアント端末１０は、ＰＣの強制終了に伴って終了された場合に限ってＰＣの終了ログを生成したり、また、ＰＣのログオフログを生成したりする。
【００２５】
それゆえ、本実施例に係るクライアント端末１０では、クライアント端末１０が動作中に監視アプリが異常停止した場合に、誤ってＰＣの終了ログを生成したり、また、誤ってＰＣのログオフログを生成したりすることを防止できる。よって、本実施例に係るクライアント端末１０によれば、ＰＣの終了ログやＰＣのログオフログなどの基本ソフトウェアの終了に関するログを正確に取得できる。
【００２６】
［クライアント端末の構成］
続いて、本実施例に係るクライアント端末の構成について説明する。図２は、実施例１に係るクライアント端末の構成を示すブロック図である。図２に示すように、クライアント端末１０は、入力部１１と、通信Ｉ／Ｆ部１２と、記憶部１３と、制御部１４とを有する。なお、クライアント端末１０は、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば表示部などの表示デバイス、音声入力部や音声出力部などの音声デバイス等を有するものとする。
【００２７】
このうち、入力部１１は、各種の情報、例えば後述のＯＳ実行部１５に対する指示入力を受け付ける入力デバイスである。かかる入力部１１の一例としては、英字、かな、数字や記号などのキーを始め、シフトキーやコントロールキーなどの補助キーが整列されたキーボード（keyboard）１１ａが挙げられる。他の一例としては、ポインティングデバイス（pointing device）の一態様であるマウス（mouse）１１ｂが挙げられる。更なる一例としては、ＰＣであるクライアント端末１０の電源を入れたり、強制終了したりする電源ボタン１１ｃが挙げられる。なお、キーボード１１ａ、マウス１１ｂ及び電源ボタン１１ｃは、ＯＳを終了させる終了命令情報を受付ける第二の受付部の一態様である。
【００２８】
通信Ｉ／Ｆ部１２は、他の装置、例えば管理サーバ３０や他のクライアント端末１０との間で通信を行うためのインタフェース（interface）である。
【００２９】
記憶部１３は、例えば、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)やフラッシュメモリ（flash memory）などの半導体メモリ素子などの記憶装置である。なお、記憶部１３は、上記の種類の記憶装置に限定されるものではなく、ハードディスク（hard disk）、光ディスクなどの記憶装置であってもかまわない。
【００３０】
記憶部１３は、制御部１４で実行されるＯＳ（Operating System）や各種の監視アプリの他、汎用アプリなどの各種プログラムを記憶する。さらに、記憶部１３は、制御部１４で実行されるプログラムの実行に必要なデータ、例えば後述の監視アプリ実行部１７に使用される操作ログに関するデータなどを記憶する。一例として、記憶部１３は、ログオンユーザリスト１３ａと、ログ情報１３ｂと、時刻情報１３ｃとを併せて記憶する。
【００３１】
ログオンユーザリスト１３ａは、クライアント端末１０にログオンしているユーザが搭載されるリストである。このログオンユーザリスト１３ａの一態様としては、ユーザＩＤおよびＳＩＤが対応付けて記憶される。ここで言う「ユーザＩＤ」は、クライアント端末１０にログオンするアカウント（account）が付与されたユーザを識別するための識別情報を指す。また、「ＳＩＤ（Session IDentifier）」は、ログオン中のユーザの識別や行動の補足によってセッション管理を行うためにログオン時に発行される識別情報である。なお、ログオンユーザリスト１３ａは、後述のログ生成部１７ｄによってログオンしたユーザのユーザＩＤ及びＳＩＤが追加されたり、また、ログオフしたユーザのユーザＩＤ及びＳＩＤが削除されたりする。
【００３２】
図３は、ログオンユーザリストの一例を示す図である。図３に示す例では、ユーザＩＤ「UserA」を持つユーザがクライアント端末１０にログオン中であり、そのユーザにＳＩＤ「S-1-5-21-1234567890-1234842xxxxxxx」が付与されていることを示す。さらに、図３に示す例では、ユーザＩＤ「UserB」を持つユーザがクライアント端末１０にログオン中であり、そのユーザにＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」が付与されていることを示す。なお、図３の例では、ログオンユーザがリスト形式で登録される場合を例示したが、データ構造は任意の形式を採用できる。
【００３３】
ログ情報１３ｂは、各種の操作ログを表す情報である。かかるログ情報１３ｂの一例としては、クライアント端末１０のログオンログ、クライアント端末１０のログオフログやクライアント端末１０の終了ログなどが挙げられる。これらログオンログ、ログオフログ及び終了ログは、後述のログ生成部１７ｄによって登録される。このうち、終了ログについては、後述のログ生成部１７ｄによって前回にクライアント端末１０が強制終了されたと判定された場合に限って登録される場合を想定する。なお、ここでは、前回にクライアント端末１０が強制終了された場合に限って終了ログが登録される場合を想定するが、前回にクライアント端末１０が正常終了された場合にも終了ログを登録することとしてもかまわない。さらに、ログオフログは、正常終了および強制終了を問わずに取得されることとしても良い。
【００３４】
図４は、ログ情報の一例を示す図である。この図４の例では、ログ情報１３ｂの一例として、ログオンログ及びログオフログを図示している。これらログオンログ及びログオフログは、日時、区分、ユーザ名および備考が対応付けて記憶される。ここで言う「区分」は、ログオンまたはログオフのいずれのログであるかを示す。図４に示す例では、日時「2010/02/25 10:00:15:100」にユーザ名「UserA」のユーザがログオンしていることを表す。さらに、図４に示す例では、日時「2010/02/25 13:10:46:100」にユーザ名「UserB」のユーザがログオンしていることを表す。なお、図４の例では、「備考」のフィールドがブランクである場合を例示したが、「備考」には、ログオンまたはログオフに関する任意の事項を付記できる。かかる「備考」のフィールドに登録される情報の一例としては、ログオンしたユーザがゲストである旨やログオンされた時刻が勤務時間帯ではない旨などが登録される。
【００３５】
時刻情報１３ｃは、ＯＳの起動から経過した時刻を表す情報である。かかる時刻情報１３ｃの一例としては、システム日付やＯＳカウンタなどが挙げられる。ここで言う「システム（system）日付」は、ＯＳによって管理される日付を指す。また、「ＯＳカウンタ（counter）」は、ＯＳの起動時を起点とし、時間の経過にしたがってＯＳが計測したカウンタである。図５は、時刻情報の一例を示す図である。図５に示す例では、ＯＳ実行部１５によって計測されている日付が２０１０年２月２５日の１３時４５分３２秒であり、クライアント端末１０が今回起動してから２０５８２秒経過したことを示す。なお、システム日付及びＯＳカウンタは、後述のＯＳ実行部１５によって管理されているものが後述の取得部１７ａによって取得された後に後述の格納部１７ｂによって格納される。
【００３６】
制御部１４は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路またはＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路である。
【００３７】
制御部１４は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１４は、図２に示すように、ＯＳ実行部１５と、他の監視アプリ実行部１６ａ〜１６ｃと、監視アプリ実行部１７とを有する。なお、以下では、上述したログオフログオン監視アプリ以外のメール監視アプリ、アクセス監視アプリなどの監視アプリを「他の監視アプリ」と呼ぶ。
【００３８】
ＯＳ実行部１５は、コンピュータシステム全体を管理する基本ソフトウェアであるＯＳ（Operating System）の実行を制御する処理部である。
【００３９】
一例としては、ＯＳ実行部１５は、ＯＳの起動や終了に関する処理を実行する。例えば、電源ボタン１１ｃの押下操作を介してＯＳの起動要求を受け付けた場合に、ＯＳを起動する。また、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してクライアント端末１０のシャットダウン要求を受け付けた場合に、ログイン中のユーザのログオフを行ったり、ＯＳやアプリに関する各種の設定を保存した上でＯＳを終了する。この場合には、クライアント端末１０が正常終了されることになる。なお、電源ボタン１１ｃを介してクライアント端末１０が強制終了された場合には、ログイン中のユーザが強制的にログオフされ、ＯＳやアプリに関する各種の設定が保存されずにＯＳが強制終了される。この場合には、クライアント端末１０が強制終了されることになる。
【００４０】
他の一例としては、ＯＳ実行部１５は、ログオン及びログオフに関する処理を実行する。例えば、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してユーザのログオンを受け付けた場合に、ログオン認証を行った上でログオン認証に成功したユーザにＳＩＤを発行することによってユーザをログオンさせる。また、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してユーザのログオフを受け付けた場合に、該当するログイン中のユーザのＳＩＤを破棄することによってユーザをログオフさせる。また、ＯＳ実行部１５は、後述のログ生成部１７ｄからＳＩＤの取得要求を受け付けた場合に、ログオン中のユーザのＳＩＤを応答する。なお、以下では、複数のユーザのログオンを同時に受け付けることが可能なＯＳが実行される場合を想定するが、ユーザのログオンを排他的に受け付けることとしてもよい。
【００４１】
更なる一例としては、ＯＳ実行部１５は、時刻情報を管理する処理を実行する。例えば、ＯＳ実行部１５は、時間経過にしたがってシステム日付を更新したり、また、時間経過にしたがってＯＳカウンタをカウントアップしたりする。また、ＯＳ実行部１５は、後述の取得部１７ａによってシステム日付及びＯＳカウンタの問合せを受け付けた場合に、システム日付及びＯＳカウンタの値を取得部１７ａへ応答する。
【００４２】
他の一例としては、ＯＳ実行部１５は、クライアント端末１０で実行されるログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリ、その他の汎用アプリのプロセスを管理する処理を実行する。例えば、ＯＳ実行部１５は、後述の他の監視アプリ実行部１６ａ〜１６ｃまたは監視アプリ実行部１７から問合せ元以外の監視アプリに関する起動の有無の問合せを受け付けた場合に、問合せ元以外の監視アプリの起動の有無を問合せ元の監視アプリへ応答する。また、ＯＳ実行部１５は、後述の他の監視アプリ実行部１６ａ〜１６ｃまたは監視アプリ実行部１７から問合せ元以外の監視アプリに関する再起動の要求を受け付けた場合に、該当する監視アプリを再起動させる。なお、クライアント端末１０では、上記のログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリ以外のアプリ、例えばワープロソフト、表計算ソフトや作図ソフトなどのプロセスの管理を行うことは言うまでもない。
【００４３】
他の監視アプリ実行部１６ａ〜１６ｃは、ログオフログオン監視アプリ以外のメール監視アプリ、アクセス監視アプリの実行を制御する処理部である。ここでは、他の監視アプリ実行部１６ａ〜１６ｃは、各々１つの監視アプリの実行を制御するものとする。これら他の監視アプリ実行部１６ａ〜１６ｃは、自らが実行する監視アプリ以外の監視アプリの起動の有無をＯＳ実行部１５に問い合わせることによって監視する処理をそれぞれ実行する。このとき、他の監視アプリ実行部１６ａ〜１６ｃは、ＯＳ実行部１５から起動していない監視アプリが存在する旨の応答が得られた場合に、起動していない監視アプリの再起動させるＡＰＩをＯＳ実行部１５へ出力する。なお、以下では他の監視アプリ実行部１６ａ〜１６ｃを総称する場合には「他の監視アプリ実行部１６」と記載する。
【００４４】
監視アプリ実行部１７は、ログオフログオン監視アプリの実行を制御する処理部である。この監視アプリ実行部１７は、図２に示すように、取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄとをさらに有する。
【００４５】
このうち、取得部１７ａは、ＯＳ実行部１５によって計測された時刻情報を取得する処理部である。一例としては、取得部１７ａは、所定の期間、例えば１秒ごとにシステム日付及びＯＳカウンタの問合せをＯＳ実行部１５へ出力する。そして、取得部１７ａは、問合せに対する応答して得られたシステム日付及びＯＳカウンタの値を取得する。なお、ここでは、一定周期で時刻情報を取得する場合を例示したが、開示の装置はこれに限定されない。例えば、一定周期ではなく、時間帯によって周期を可変としてもよいし、定期時刻に時刻情報を取得するようにしてもよい。
【００４６】
格納部１７ｂは、取得部１７ａによって取得された時刻情報を記憶部１３へ格納する処理部である。かかる時刻情報は、ログオンログオフ監視アプリの設定データ、いわゆるレジストリ（registry）として記憶部１３へ格納することとしてもよいし、ファイル（file）として記憶部１３へ格納することとしてもかまわない。
【００４７】
ログ送信部１７ｃは、記憶部１３によって記憶されたログ情報１３ｂを管理サーバ３０へ送信する処理部である。このログ送信部１７ｃは、ログ情報１３ｂを任意のタイミングで管理サーバ３０へ送信できる。一例としては、ログ送信部１７ｃは、後述のログ生成部１７ｄによってログ情報が生成される度にそのログ情報をリアルタイム送信することができる。他の一例としては、ログ送信部１７ｃは、クライアント端末１０が起動されたことや、ネットワークに接続されたことを契機に記憶部１３に記憶されていたログ情報１３ｂを送信することもできる。
【００４８】
ログ生成部１７ｄは、ＯＳの終了に関するログ情報を生成する処理部である。なお、ここでは、ログ生成部１７ｄがクライアント端末１０のログオンログ、クライアント端末１０のログオフログ及びクライアント端末１０の終了ログを生成する場合を例示するが、ログオフログまたは終了ログのいずれかのみを生成することとしてもよい。
【００４９】
一例としては、ログ生成部１７ｄは、所定の期間、例えば格納部１７ｂによって時刻情報が記憶部１３へ格納される度に、ＯＳ実行部１５から取得したログオン中のユーザのＳＩＤに基づいて、ログオンログ及び／又はログオフログを更新する。
【００５０】
これを説明すると、ログ生成部１７ｄは、ＯＳ実行部１５にＳＩＤの取得要求を行ってログオン中のユーザのＳＩＤを取得する。そして、ログ生成部１７は、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在するか否かを判定する。このとき、ログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在する場合には、新たなユーザがログオンしてＳＩＤが追加されたことがわかる。よって、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａに追加した上でそのユーザＩＤ及びＳＩＤをログオンログとしてログ情報１３ｂへ追加登録する。
【００５１】
また、ログ生成部１７ｄは、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａから削除されたＳＩＤが存在するか否かを判定する。このとき、ログオンユーザリスト１３ａから削除されたＳＩＤが存在する場合には、ログオンしていたユーザがログオフしてＳＩＤが削除されたことがわかる。よって、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａから削除した上でそのユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。この構成によって、複数のユーザが同時に１つのクライアントにログオンして、操作を行う形態においても、ユーザごとに独立に各種ログを生成することができる。
【００５２】
ここで、図６〜図１０を用いて、ログオンログ及びログオフログの生成について説明する。図６は、ＯＳ実行部から取得されたＳＩＤリストの一例を示す。図７及び図９は、ログオンユーザリストの更新例を示す図である。図８は、ログオンログの生成例を示す図である。図１０は、ログオフログの生成例を示す図である。
【００５３】
例えば、図６に示すＳＩＤリストがＯＳ実行部１５から取得された場合には、ログ生成部１７ｄは、図３に示したログオンユーザリスト１３ａに比べて、「UserC」のＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」が新たに追加されたことを検知する。この場合には、ログ生成部１７ｄは、図７に示すように、新たに追加された「UserC」のＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」を図３に示したログオンユーザリスト１３ａに追加する。その上で、ログ生成部１７ｄは、図８に示すように、新たに追加されたユーザＩＤ「UserC」及びＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」を区分「ログオン」として図４に示したログ情報１３ｂに追加登録する。
【００５４】
また、図６に示すＳＩＤリストがＯＳ実行部１５から取得された場合には、ログ生成部１７ｄは、図３に示したログオンユーザリスト１３ａに比べて、「UserB」のＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」が削除されたことを検知する。この場合には、ログ生成部１７ｄは、図９に示すように、ログオフによって削除された「UserB」のＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」を図７に示したログオンユーザリスト１３ａから削除する。その上で、ログ生成部１７ｄは、図１０に示すように、ログオフによって削除されたユーザＩＤ「UserB」及びＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」を区分「ログオフ」として図９に示したログ情報１３ｂに追加登録する。
【００５５】
他の一例としては、ログ生成部１７ｄは、ＯＳ実行部１５によってシャットダウン要求が受け付けられた場合に、ログオンログオフ監視アプリの終了処理を行う。例えば、ログ生成部１７ｄは、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤを削除した上でそのユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。また、ログ生成部１７ｄは、時刻情報１３ｃとして記憶されたシステム日付及びＯＳカウンタの値をゼロにクリアする。図１１は、時刻情報のクリアを説明するための図である。図１１に示すように、ログ生成部１７ｄは、ＯＳ実行部１５によってシャットダウン要求が受け付けられた場合に、図５に示した時刻情報１３ｃをゼロクリアする。これによって、次回の監視アプリの起動時に今回の監視アプリの終了がＰＣの終了に伴って終了されたことを検知できる。このように、ログ生成部１７ｄは、終了命令情報がＯＳを用いたＯＳの終了を命令する情報である場合は、正常終了を示す正常終了情報、システム日付及びＯＳカウンタの初期状態である旨の情報を記憶部１３に格納する正常終了情報格納部としても機能する。かかる正常終了情報格納部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５６】
更なる一例として、ログ生成部１７ｄは、ログオンログオフ監視アプリが起動した場合に、記憶部１３に記憶された時刻情報１３ｃと、今回の起動時に取得部１７ａに取得させた時刻情報との差分に基づいて、前回のログオフログ及び終了ログを生成する。かかるログ生成部１７ｄは、ＯＳの終了に関するログ情報を生成するログ生成部の一態様である。なお、ログ生成部１７ｄは、ユーザによるＰＣの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける第一の受付部としても機能する。かかる第一の受付部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５７】
これを説明すると、ログ生成部１７ｄは、監視アプリが起動すると、ＯＳ実行部１５からシステム日付及びＯＳカウンタを取得部１７ａに取得させる。そして、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付及びＯＳカウンタを読み出す。なお、ここでは、起動時に取得部１７ａに取得させたシステム日付の値を「システム日付の取得値」と呼び、起動時に取得部１７ａに取得させたＯＳカウンタの値を「ＯＳカウンタの取得値」と呼ぶ。一方、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付の値を「システム日付の保存値」と呼び、記憶部１３に時刻情報１３ｃとして記憶されたＯＳカウンタの値を「ＯＳカウンタの保存値」と呼ぶ。このように、ログ生成部１７ｄは、記憶部１３の時刻情報が記憶される記憶領域にアクセスするアクセス部としても機能する。かかるアクセス部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５８】
ここで、ログ生成部１７ｄは、システム日付の保存値がゼロであるか否かを判定する。このとき、システム日付の保存値がゼロである場合には、前回の監視アプリの終了がＰＣの正常終了に伴う終了であったとみなすことができる。よって、システム日付の保存値がゼロである場合には、ログ生成部１７ｄは、ログオフログ及び終了ログを生成せずに、ユーザのログオン及びログオフを定期的に監視する処理に移行する。一方、システム日付の保存値がゼロでない場合には、監視アプリが前回に正常終了されていないとみなすことができる。この場合には、クライアント端末１０が強制終了されたか、あるいは監視アプリが異常停止したかのいずれかと推定できる。なお、本実施例では、システム日付の保存値がゼロであるか否かによって前回の監視アプリの終了がＰＣの正常終了に伴う終了であったか否かを推定する場合を説明したが、ＯＳカウンタの保存値がゼロであるか否かによっても同様の推定が可能である。
【００５９】
このため、ログ生成部１７ｄは、システム日付の保存値がゼロでない場合に、システム日付の取得値およびシステム日付の保存値の差分が所定の閾値、例えば１０秒以下であるか否かをさらに判定する。ここで言う「閾値」は、上記の例に限定されるものではなく、他の監視アプリと相互起動する監視アプリが再起動された可能性を否定できる値、言い換えればＰＣが再起動するために要するであろう値であれば任意の値を採用できる。
【００６０】
すなわち、監視アプリは、他の監視アプリと互いの生存状況を監視し、いずれかの監視アプリが異常停止した場合には他の監視アプリによって再起動されるため、監視アプリが異常停止したとしても長期間にわたって停止する可能性は低い。その一方で、ＰＣの再起動には、ＰＣの性能に依存する部分はあるものの、監視アプリの再起動に比べてかなりの時間を要する。つまり、ユーザがＰＣを強制終了させた後に、すぐにＰＣを起動させたとしても、監視アプリの再起動に比べてかなりの時間を要する。さらには、ユーザがＰＣを強制終了させて、時間をおいてＰＣを再起動させた場合は、より長い時間が経過することとなる。このため、監視アプリの再起動所要時間及びＰＣの再起動所要時間の相関関係は、監視アプリの再起動所要時間の方がＰＣの再起動所要時間よりも短いと言える。よって、システム日付の取得値およびシステム日付の保存値の差分が所定値以上である場合には、前回の監視アプリの終了はＰＣの強制終了に伴うものであり、ＰＣの再起動に連動して監視アプリが再起動したものと推定できる。
【００６１】
このことから、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定値以上である場合に、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する。一方、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合には、監視アプリの再起動所要時間＜＜ＰＣの再起動所要時間であるため、システム日付だけからでは監視アプリの異常停止とは限らず、ＰＣが再起動された余地は残る。なぜなら、システム日付は、ＯＳの設定をユーザが変更することで容易に変更される。したがって、ユーザがシステム日付を変更したことによって、差分が所定値未満になってしまうと、正確なログオフログが取得できなくなる。
【００６２】
そこで、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合に、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きいか否かをさらに判定する。すなわち、ＰＣが再起動された場合には、ＯＳ実行部１５によって再起動後のＯＳカウンタはゼロにクリアされる一方で、監視アプリが異常停止した場合には、ＯＳは生存しているのでＯＳカウンタはゼロにクリアされずに継続してカウントアップされる。よって、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合には、前回に監視アプリが異常停止したと推定できる。一方、ＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合には、前回にＰＣが強制終了されたと推定できる。
【００６３】
このため、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合には、ログオフログ及び終了ログを生成せずに、ユーザのログオン及びログオフを定期的に監視する処理に移行する。
【００６４】
また、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合には、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する。
【００６５】
このように、システム日付及びＯＳカウンタの両方を組み合わせてログオフログ及び終了ログの生成を判断した場合には、ＯＳカウンタだけを用いてログオフログ及び終了ログの生成を判断する場合に比べて、次のように正確な判断が可能となる。すなわち、ＰＣ電源のオン操作、ＰＣの強制終了操作、ＰＣ電源のオン操作の順に３つの操作の各々が短い間隔でなされたケースを想定する。このケースでは、２回目のＰＣ電源のオン操作から監視アプリが起動するまでに要した時間が、１回目のＰＣ電源のオン操作からＰＣの強制終了前までに経過した時間よりも大きいと、ＰＣが強制終了された場合でもＯＳカウンタの取得値が保存値より大きくなる場合がある。そこで、システム日付の取得値と保存値の差分によりＰＣの再起動と推定できる場合には、ＯＳカウンタの取得値及び保存値の大小によらず、ログオフログ及び終了ログを生成することによって、上記のケースでログ情報の生成漏れが発生するのを防止できる。
【００６６】
なお、図２を用いて説明してきたように、ログ生成部１７ｄは、他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較する比較部としても機能する。かかる比較部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００６７】
［処理の流れ］
次に、本実施例に係るクライアント端末における処理の流れを説明する。なお、ここでは、クライアント端末１０によって実行される（１）ログオンログオフ監視処理を説明してから、（２）終了ログ取得処理について説明する。
【００６８】
（１）ログオンログオフ監視処理
図１２は、実施例に係るログオンログオフ監視処理の手順を示すフローチャートである。このログオンログオフ監視処理は、監視アプリの起動後に監視アプリが終了されるまで所定の時間ごとに繰り返し実行される処理である。
【００６９】
図１２に示すように、格納部１７ｂは、取得部１７ａによってＯＳ実行部１５から取得されたシステム日付及びＯＳカウンタの値を時刻情報１３ｃとして記憶部１３へ記録する（ステップＳ１０１及びステップＳ１０２）。
【００７０】
続いて、ログ生成部１７ｄは、ＯＳ実行部１５にＳＩＤの取得要求を行ってログオン中のユーザのＳＩＤを取得する（ステップＳ１０３）。そして、ログ生成部１７は、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在するか否か、すなわち今回追加されたセッションがあるか否かを判定する（ステップＳ１０４）。
【００７１】
このとき、今回追加されたセッションがある場合（ステップＳ１０４肯定）には、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａに追加する（ステップＳ１０５）。そして、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンログとして生成し（ステップＳ１０６）、そのログオンログをログ情報１３ｂへ追加登録する。
【００７２】
一方、今回追加されたセッションがない場合（ステップＳ１０４否定）には、新たなユーザがログオンしてＳＩＤが追加されていないので、そのままステップＳ１０７の処理へ移行する。
【００７３】
その後、ログ生成部１７ｄは、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａから削除されたＳＩＤが存在するか否か、すなわち今回削除されたセッションがあるか否かを判定する（ステップＳ１０７）。
【００７４】
このとき、今回削除されたセッションがある場合（ステップＳ１０７肯定）には、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａから削除する（ステップＳ１０８）。その上で、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオフログとして生成し（ステップＳ１０９）、そのログオフログをログ情報１３ｂへ追加登録する。なお、今回削除されたセッションがない場合（ステップＳ１０７否定）には、そのままステップＳ１０１の処理に戻る。
【００７５】
このようにして、監視アプリ実行部１７は、監視アプリが生存している限りは、上記のステップＳ１０１〜ステップＳ１０９までの処理を繰り返し行う。
【００７６】
（２）終了ログ取得処理
図１３は、実施例に係る終了ログ取得処理の手順を示すフローチャートである。この終了ログ取得処理は、ログオンログオフ監視アプリが起動した場合に実行させる処理であり、処理の終了後には上記のログオンログオフ監視処理に移行する。
【００７７】
図１３に示すように、ログ生成部１７ｄは、監視アプリが起動すると、ＯＳ実行部１５からシステム日付及びＯＳカウンタを取得部１７ａに取得させる（ステップＳ３０１及びステップＳ３０２）。
【００７８】
ここで、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付の保存値がゼロであるか否かを判定する（ステップＳ３０３）。このとき、システム日付の保存値がゼロである場合（ステップＳ３０３肯定）には、ログ生成部１７ｄは、前回にＰＣが正常終了されたと判断し（ステップＳ３０４）、ログオフログ及び終了ログを生成せずに処理を終了する。
【００７９】
一方、システム日付の保存値がゼロでない場合（ステップＳ３０３否定）に、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定の閾値、例えば１０秒以下であるか否かをさらに判定する（ステップＳ３０５）。このとき、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合（ステップＳ３０５肯定）に、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きいか否かをさらに判定する（ステップＳ３０６）。
【００８０】
ここで、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合（ステップＳ３０６肯定）には、ログ生成部１７ｄは、次のように判断する。すなわち、ログ生成部１７ｄは、前回に監視アプリの終了が異常停止であったと判断し（ステップＳ３０７）、ログオフログ及び終了ログを生成せずに処理を終了する。
【００８１】
一方、システム日付の取得値およびシステム日付の保存値の差分が所定値よりも大きい場合（ステップＳ３０５否定）またはＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合（ステップＳ３０６否定）には、次のように判断される。すなわち、ログ生成部１７ｄは、前回にＰＣが強制終了されたと判断する（ステップＳ３０８）。
【００８２】
この場合には、ログ生成部１７ｄは、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとして生成し（ステップＳ３０９）、そのログオフログをログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する（ステップＳ３１０）。このようにしてログオフログ及び終了ログを生成後に処理を終了する。
【００８３】
なお、システム日付のみを用いてログオフログ及び終了ログを生成する場合には、上記のステップＳ３０１〜ステップＳ３１０のうち、ステップＳ３０２及びステップＳ３０６を省略することができる。また、ＯＳカウンタのみを用いてログオフログ及び終了ログを生成する場合には、上記のステップＳ３０１〜ステップＳ３１０のうち、ステップＳ３０１及びステップＳ３０５を省略できる。その代わりに、ステップＳ３０３でシステム日付に代えてＯＳカウンタの保存値がゼロであるか否かを判定する。
【００８４】
また、ログ生成部１７ｄは、Ｓ３０５のシステム日付を用いた判定とＳ３０６のＯＳカウンタを用いた判定とを逆で行っても良い。その場合は、ＯＳカウンタの取得値がＯＳカウンタの保存値以下であると判定した場合（ステップＳ３０６肯定）には、ログ生成部１７ｄはＳ３０５の判定を実行する。そして、システム日付の取得値およびシステム日付の保存値の差分が所定値よりも大きい場合（ステップＳ３０５否定）、ログ生成部１７ｄは、前回にＰＣが強制終了されたと判断する。また、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合（ステップＳ３０５肯定）、ログ生成部１７ｄは、前回に監視アプリの終了が異常停止であったと判断する。一方、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合（ステップＳ３０６否定）には、強制終了されたと判断する。
【００８５】
［実施例１の効果］
上述してきたように、本実施例に係るクライアント端末１０は、相互起動する複数アプリのうちの監視アプリは、異常終了後の起動時に、前回終了時刻よりも現時刻が大きければ監視アプリの異常終了であったとして、ＯＳの終了に関するログ情報は生成しない。それゆえ、本実施例に係るクライアント端末１０では、クライアント端末１０が動作中に監視アプリが異常停止した場合に、誤って終了ログを生成したり、また、誤ってログオフログを生成したりすることを防止できる。よって、本実施例に係るクライアント端末１０によれば、ＰＣの終了ログやＰＣのログオフログなどの基本ソフトウェアの終了に関するログを正確に取得できる。
【００８６】
また、本実施例に係るクライアント端末１０は、システム日付間の差分が所定値以上である場合に、ＯＳの終了に関するログ情報を生成する。さらに、本実施例に係るクライアント端末１０は、システム日付間の差分が所定値未満であってもＯＳカウンタの取得値よりもＯＳカウンタの保存値の方が大きい場合に、ＯＳの終了に関するログ情報を生成する。このため、本実施例に係るクライアント端末１０によれば、電源のオン操作、強制終了操作、電源のオン操作の順に３つの操作の各々が短い間隔でなされた場合でも、ログオフログ及びＰＣの終了ログの生成漏れを防止できる。
【００８７】
さらに、本実施例に係るクライアント端末１０は、時刻情報の取得値が時刻情報の保存値よりも小さい場合には、ＯＳの終了に関するログ情報を生成させない。そして、本実施例に係るクライアント端末１０は、時刻情報の保存値よりも時刻情報の取得値の方が大きい場合に、ＯＳの終了に関するログ情報を生成する。よって、本実施例に係るクライアント端末１０によれば、監視アプリが異常停止した場合に誤って終了ログ及びログオフログが生成するのを防止しつつ、クライアント端末１０が強制終了した場合に限ってログオフログ及び終了ログを生成できる。
【実施例２】
【００８８】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８９】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、取得部１７ａ、格納部１７ｂ、ログ送信部１７ｃまたはログ生成部１７ｄをクライアント端末１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、取得部１７ａ、格納部１７ｂ、ログ送信部１７ｃまたはログ生成部１７ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のクライアント端末１０の機能を実現するようにしてもよい。
【００９０】
［終了ログ取得プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１４を用いて、上記の実施例と同様の機能を有する終了ログ取得プログラムを実行するコンピュータの一例について説明する。なお、図１４は、実施例２に係る終了ログ取得プログラムを実行するコンピュータの一例について説明するための図である。
【００９１】
図１４に示すように、実施例２におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【００９２】
ＲＯＭ１６０には、上記の実施例１で示した取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図１４に示すように、取得プログラム１６０ａと、格納プログラム１６０ｂと、ログ送信プログラム１６０ｃと、ログ生成プログラム１６０ｄが記憶される。これらのプログラム１６０ａ〜１６０ｄについては、図２に示したクライアント端末１０の各構成要素と同様、適宜統合又は分離しても良い。なお、ＲＡＭ１６０に格納される各データは、常に全てのデータがＲＡＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＡＭ１６０に格納されれば良い。
【００９３】
そして、ＣＰＵ１５０が、これらのプログラム１６０ａ〜１６０ｄをＲＯＭ１６０から読み出して実行する。これによって、ＣＰＵ１５０は、図１４に示すように、各プログラム１６０ａ〜１６０ｄについては、取得プロセス１５０ａ、格納プロセス１５０ｂ、ログ送信プロセス１５０ｃ及びログ生成プロセス１５０ｄとして機能するようになる。これらプロセス１５０ａ〜１５０ｄは、図２に示した、取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄとにそれぞれ対応する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。そして、ＣＰＵ１５０は、ＲＡＭ１８０に格納された情報を用いて、終了ログ取得プログラムを実行する。
【００９４】
なお、上記の終了ログ取得プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【００９５】
１ 情報漏えい対処システム
３ ネットワーク
１０Ａ〜１０Ｃ クライアント端末
１１ 入力部
１１ａ キーボード
１１ｂ マウス
１１ｃ 電源ボタン
１２ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ ログオンユーザリスト
１３ｂ ログ情報
１３ｃ 時刻情報
１４ 制御部
１５ ＯＳ実行部
１６ａ〜１６ｃ 他の監視アプリ実行部
１７ 監視アプリ実行部
１７ａ 取得部
１７ｂ 格納部
１７ｃ ログ送信部
１７ｄ ログ生成部
３０ 管理サーバ
５０ コンソール
【技術分野】
【０００１】
本発明は、終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法に関する。
【背景技術】
【０００２】
情報漏えい対策として、組織等に所属するエンドユーザ（end user）によって利用されるコンピュータ（computer）の操作ログ（log）が採取される。かかるコンピュータの一態様としては、パソコン（personal computer）が挙げられる。このようにパソコンの操作ログを採取することによって、パソコンの監視、情報漏えいが起こった場合の検証、情報漏えいのリスクを管理するための分析などが可能になる。
【０００３】
このような操作ログの一態様としては、パソコンで動作する基本ソフトウェア、例えばＯＳ（Operating System）の終了に関するログが採取される。かかるＯＳの終了に関するログの一例としては、パソコンからのログオフ（log-off）のログやパソコンの終了ログが挙げられる。これらパソコンのログオフ及びパソコンの終了はＯＳによってなされる。このため、ＯＳの終了に関するログを採取するためには、ログ採取を目的とする監視アプリ（application program）にＯＳを監視させることにより、ユーザによってログオフされた時刻やパソコンが終了された時刻などを採取すればよい。
【０００４】
一方、パソコンをシャットダウン（shutdown）して正常終了できなかった場合に、ハード的に強制終了を実行するとともに、正常終了ではないことを示すログを取得する特許文献１の技術がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３３２２５８号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところが、上記の特許文献１の技術では、ユーザがＯＳの終了指示を入力せずに強制終了した場合には、監視アプリがＯＳの終了に関するログを採取することができない。
【０００７】
例えば、正常終了時には、ＯＳから取得された時刻情報、監視アプリがＯＳから取得して保持する時刻情報を、監視アプリが初期状態に修正するとともに正常終了した旨を示す正常終了ログが監視アプリによって生成される。時刻情報は、例えばＯＳの起動からの経過時間がカウントされたＯＳカウンタなどが考えられる。一方、正常終了されずに強制終了された場合には、監視アプリがＯＳから取得して保持しているＯＳカウンタをゼロに修正する余地はなく、ログを生成する余地もない。よって、監視アプリの起動時には、監視アプリが保持するＯＳカウンタがゼロでなければ、前回の監視アプリの終了時にＯＳの終了に関するログが生成されていないと判断し、監視アプリが前回に計測していた時刻を用いて、前回のＯＳの終了に関するログを生成することが想定される。
【０００８】
しかしながら、監視アプリが保持するＯＳカウンタがゼロであるか否かによってログを生成したのでは、ＯＳの終了に関するログを正確に取得することができないという問題がある。すなわち、監視アプリは、強制終了された場合だけでなく、監視アプリ自らが異常終了した場合にも、自らが保持するＯＳカウンタをゼロに修正することはできない。このため、パソコンが終了していないにもかかわらず、監視アプリが異常終了した場合にも再起動した監視アプリによってパソコンのログオフのログやパソコンの終了ログが生成される結果、誤ったログが生成されてしまうことになる。
【０００９】
開示の技術は、上記に鑑みてなされたものであって、基本ソフトウェアの終了に関するログを正確に取得できる終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法を提供することを目的とする。
【課題を解決するための手段】
【００１０】
開示の終了ログ取得プログラムは、コンピュータに、ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記基本ソフトウェアを終了させる終了命令情報を受付ける処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納する処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスする処理を実行させる。さらに、前記終了ログ取得プログラムは、前記コンピュータに、前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得する処理を実行させる。さらに、前記終了ログ取得プログラムは、前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較する処理を実行させる。前記終了ログ取得プログラムは、前記コンピュータに、比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理を実行させる。
【発明の効果】
【００１１】
開示の終了ログ取得プログラムの一つの態様によれば、基本ソフトウェアの終了に関するログを正確に取得できるという効果を奏する。
【図面の簡単な説明】
【００１２】
【図１】図１は、実施例１に係る情報漏えい対処システムの構成を示す図である。
【図２】図２は、実施例１に係るクライアント端末の構成を示すブロック図である。
【図３】図３は、ログオンユーザリストの一例を示す図である。
【図４】図４は、ログ情報の一例を示す図である。
【図５】図５は、時刻情報の一例を示す図である。
【図６】図６は、ＯＳ実行部から取得されたＳＩＤリストの一例を示す図である。
【図７】図７は、ログオンユーザリストの更新例を示す図である。
【図８】図８は、ログオンログの生成例を示す図である。
【図９】図９は、ログオンユーザリストの更新例を示す図である。
【図１０】図１０は、ログオフログの生成例を示す図である。
【図１１】図１１は、時刻情報のクリアを説明するための図である。
【図１２】図１２は、実施例１に係るログオンログオフ監視処理の手順を示すフローチャートである。
【図１３】図１３は、実施例１に係る終了ログ取得処理の手順を示すフローチャートである。
【図１４】図１４は、実施例２に係る終了ログ取得プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１３】
以下に、本願の開示する終了ログ取得プログラム、終了ログ取得装置及び終了ログ取得方法の実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。そして、各実施例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。
【実施例１】
【００１４】
［システム構成］
まず、実施例１に係る情報漏えい対処システムについて説明する。図１は、実施例１に係る情報漏えい対処システムの構成を示す図である。なお、図１の例では、組織に所属するエンドユーザ（end user）によって使用されるクライアント端末１０Ａ〜１０Ｃで採取された操作ログ（log）を管理サーバ１０に収集することにより、ユーザによる情報漏えいに対処する例を想定する。
【００１５】
図１に示す情報漏えい対処システム１には、複数のクライアント端末１０Ａ〜１０Ｃと、管理サーバ３０と、コンソール５０とが収容される。なお、図１の例では、３つのクライアント端末、１つの管理サーバ、１つのコンソールをそれぞれ図示したが、開示のシステムは図示の構成に限定されない。すなわち、情報漏えい対処システム１は、任意の数のクライアント端末、管理サーバおよびコンソールを収容できる。以下では、クライアント端末１０Ａ〜１０Ｃの各装置を区別なく総称する場合には、「クライアント端末１０」と記載する。なお、クライアント端末１０Ａが、管理サーバ３０として動作することもでき、また、管理サーバ３０にクライアント端末１０の機能を同居させることもできる。
【００１６】
これらクライアント端末１０Ａ〜１０Ｃと管理サーバ３０とは、ネットワーク（network）３を介して相互に通信可能に接続される。かかるネットワーク３には、有線または無線を問わず、インターネット（Internet）、ＬＡＮ（Local Area Network）やＶＰＮ（Virtual Private Network）などの任意の種類の通信網を採用できる。なお、図１の例では、管理サーバ３０とコンソール５０とが直接接続される場合を例示したが、両者はネットワークを介して接続されることとしてもかまわない。
【００１７】
管理サーバ（server）３０は、クライアント端末１０を管理するサーバ装置である。この管理サーバ３０は、情報漏えいに対処するための情報漏えい対処ソフト（software）をネットワーク３経由で自装置に接続されるクライアント端末１０にそれぞれダウンロードさせた後にインストール（install）させる。かかる情報漏えい対処ソフトには、機能ごとにモジュール化された複数のアプリケーション（application software）が含まれる。なお、以下では、アプリケーションのことを「アプリ」と略記する。
【００１８】
これら情報漏えい対処ソフトに含まれるアプリの一例としては、ログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリなどが挙げられる。このうち、ログオフログオン監視アプリは、一例として、クライアント端末１０で動作するＯＳ（operating system）に対するログオン（log-on）やログオフ（log-off）のログを採取する機能を有する。さらに、ログオフログオン監視アプリは、クライアント端末１０の終了、いわゆるシャットダウン（shutdown）のログを採取する機能を有する。メール監視アプリは、一例として、メール（mail）の送信ログを採取する機能を有する。また、アクセス監視アプリは、一例として、ＷＥＢ（world wide web）のアクセスログを採取する機能を有する。なお、以下では、上記３つのアプリを「監視アプリ」と総称する。
【００１９】
なお、ここでは、クライアント端末１０の操作ログを採取する監視アプリについて例示したが、クライアント端末１０における特定の操作を禁止または制限する監視アプリをインストールさせることとしてもかまわない。また、ここでは、管理サーバ３０からダウンロードされた情報漏えい対処ソフトをクライアント端末１０にインストールさせる場合を説明したが、インストールの形態はこれに限定されない。一例としては、フレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの可搬用の物理媒体を経由して情報漏えい対処ソフトをクライアント端末１０にインストールさせることとしてもよい。他の一例としては、クライアント端末１０に情報漏えい対処ソフトをプリインストールさせることとしてもよい。
【００２０】
このようにしてクライアント端末１０にインストールされた監視アプリによって、管理サーバ３０は、各クライアント端末１０Ａ〜１０Ｃにおける操作ログ、例えばログオンやログオフのログ、終了ログ、メール送信ログやアクセスログを収集する。かかる操作ログの収集は、管理サーバ３０及びクライアント端末１０がネットワーク３を介して接続状態にある場合には、任意のタイミング（timing）で操作ログを収集できる。一例としては、クライアント端末１０で監視アプリによって操作ログが収集される度にその操作ログをリアルタイム（real time）で収集することができる。他の一例としては、クライアント端末１０が起動されたことを契機に監視アプリによって採取されていた操作ログを収集することもできる。
【００２１】
コンソール（console）５０は、管理者権限（administrators）を有する者によって使用される端末である。なお、管理者権限は、システム管理者によって予め設定される。かかるコンソール５０の機能の一例としては、管理サーバ３０に収集された操作ログを閲覧する機能の他、クライアント端末１０で動作する監視アプリによって採取させる操作ログのポリシー（policy）を管理サーバ３０に設定する機能などが挙げられる。なお、ここで言う「ポリシー」とは、クライアント端末１０の操作ログ、例えばログオンログ、ログオフログ、終了ログ、メール送信ログやアクセスログのうちいずれの操作ログの採取をクライアント端末１０で有効または無効とさせるかという方針を指す。
【００２２】
クライアント端末１０は、エンドユーザによって使用される端末装置である。かかるクライアント端末１０の一態様としては、パソコン（ＰＣ：personal computer）を始めとする固定端末の他、携帯電話機、ＰＨＳ（Personal Handyphone System）やＰＤＡ（Personal Digital Assistant）などの移動体端末も採用できる。なお、ここでは、一例として、パソコン、以下「ＰＣ」と略記をクライアント端末１０とする場合を想定して以下の説明を行うが、他の情報処理装置を使用する場合も同様である。
【００２３】
かかるクライアント端末１０には、上述した複数の監視アプリがインストールされる。このようしてクライアント端末１０にインストールされた監視アプリは、ＯＳの起動とともに自動的に起動される。これらの監視アプリは、ＯＳが動作中である限り、互いの生存状況、例えばプロセス（process）の起動の有無を監視する処理を継続する。そして、ある監視アプリの停止が他の監視アプリによって検知された場合には、他の監視アプリは、停止した監視アプリを再起動させる命令、例えばＡＰＩ（Application Program Interface）をクライアント端末１０のＯＳに出す。これによって、各監視アプリは、クライアント端末１０の電源がオン状態である限り、動作し続けることになる。
【００２４】
ここで、本実施例に係るクライアント端末１０は、ログオフログオン監視アプリの起動時に、前回にＯＳが正常に終了されていない場合には、前回の監視アプリの終了がＰＣの強制終了に伴うものであるのか、あるいは監視アプリが異常停止したのかを区別する。すなわち、本実施例に係るクライアント端末１０は、前回に監視アプリがＯＳ経由で取得した後に保持していた終了時刻と、今回の起動時に監視アプリがＯＳ経由で取得した起動時刻とを用いて、前回に監視アプリが終了した原因が上記のいずれであるかを判定する。つまり、本実施例に係るクライアント端末１０は、２つの時刻の差分、すなわち監視アプリの前回の終了時刻から今回の起動時刻までの期間が、他の監視アプリによって本監視アプリが再起動された可能性を否定するに値するものであるか否かを判定する。このとき、本実施例に係るクライアント端末１０は、ＰＣの再起動の所要時間に比べて他の監視アプリによる再起動の所要時間が短いという知見を利用し、他の監視アプリによる再起動が否定された場合に監視アプリの終了の原因がＰＣの強制終了にあると判定する。そして、本実施例に係るクライアント端末１０は、ＰＣの強制終了に伴って終了された場合に限ってＰＣの終了ログを生成したり、また、ＰＣのログオフログを生成したりする。
【００２５】
それゆえ、本実施例に係るクライアント端末１０では、クライアント端末１０が動作中に監視アプリが異常停止した場合に、誤ってＰＣの終了ログを生成したり、また、誤ってＰＣのログオフログを生成したりすることを防止できる。よって、本実施例に係るクライアント端末１０によれば、ＰＣの終了ログやＰＣのログオフログなどの基本ソフトウェアの終了に関するログを正確に取得できる。
【００２６】
［クライアント端末の構成］
続いて、本実施例に係るクライアント端末の構成について説明する。図２は、実施例１に係るクライアント端末の構成を示すブロック図である。図２に示すように、クライアント端末１０は、入力部１１と、通信Ｉ／Ｆ部１２と、記憶部１３と、制御部１４とを有する。なお、クライアント端末１０は、図２に示した機能部以外にも既知のコンピュータが有する各種の機能部、例えば表示部などの表示デバイス、音声入力部や音声出力部などの音声デバイス等を有するものとする。
【００２７】
このうち、入力部１１は、各種の情報、例えば後述のＯＳ実行部１５に対する指示入力を受け付ける入力デバイスである。かかる入力部１１の一例としては、英字、かな、数字や記号などのキーを始め、シフトキーやコントロールキーなどの補助キーが整列されたキーボード（keyboard）１１ａが挙げられる。他の一例としては、ポインティングデバイス（pointing device）の一態様であるマウス（mouse）１１ｂが挙げられる。更なる一例としては、ＰＣであるクライアント端末１０の電源を入れたり、強制終了したりする電源ボタン１１ｃが挙げられる。なお、キーボード１１ａ、マウス１１ｂ及び電源ボタン１１ｃは、ＯＳを終了させる終了命令情報を受付ける第二の受付部の一態様である。
【００２８】
通信Ｉ／Ｆ部１２は、他の装置、例えば管理サーバ３０や他のクライアント端末１０との間で通信を行うためのインタフェース（interface）である。
【００２９】
記憶部１３は、例えば、ＲＡＭ（Random Access Memory)、ＲＯＭ（Read Only Memory)やフラッシュメモリ（flash memory）などの半導体メモリ素子などの記憶装置である。なお、記憶部１３は、上記の種類の記憶装置に限定されるものではなく、ハードディスク（hard disk）、光ディスクなどの記憶装置であってもかまわない。
【００３０】
記憶部１３は、制御部１４で実行されるＯＳ（Operating System）や各種の監視アプリの他、汎用アプリなどの各種プログラムを記憶する。さらに、記憶部１３は、制御部１４で実行されるプログラムの実行に必要なデータ、例えば後述の監視アプリ実行部１７に使用される操作ログに関するデータなどを記憶する。一例として、記憶部１３は、ログオンユーザリスト１３ａと、ログ情報１３ｂと、時刻情報１３ｃとを併せて記憶する。
【００３１】
ログオンユーザリスト１３ａは、クライアント端末１０にログオンしているユーザが搭載されるリストである。このログオンユーザリスト１３ａの一態様としては、ユーザＩＤおよびＳＩＤが対応付けて記憶される。ここで言う「ユーザＩＤ」は、クライアント端末１０にログオンするアカウント（account）が付与されたユーザを識別するための識別情報を指す。また、「ＳＩＤ（Session IDentifier）」は、ログオン中のユーザの識別や行動の補足によってセッション管理を行うためにログオン時に発行される識別情報である。なお、ログオンユーザリスト１３ａは、後述のログ生成部１７ｄによってログオンしたユーザのユーザＩＤ及びＳＩＤが追加されたり、また、ログオフしたユーザのユーザＩＤ及びＳＩＤが削除されたりする。
【００３２】
図３は、ログオンユーザリストの一例を示す図である。図３に示す例では、ユーザＩＤ「UserA」を持つユーザがクライアント端末１０にログオン中であり、そのユーザにＳＩＤ「S-1-5-21-1234567890-1234842xxxxxxx」が付与されていることを示す。さらに、図３に示す例では、ユーザＩＤ「UserB」を持つユーザがクライアント端末１０にログオン中であり、そのユーザにＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」が付与されていることを示す。なお、図３の例では、ログオンユーザがリスト形式で登録される場合を例示したが、データ構造は任意の形式を採用できる。
【００３３】
ログ情報１３ｂは、各種の操作ログを表す情報である。かかるログ情報１３ｂの一例としては、クライアント端末１０のログオンログ、クライアント端末１０のログオフログやクライアント端末１０の終了ログなどが挙げられる。これらログオンログ、ログオフログ及び終了ログは、後述のログ生成部１７ｄによって登録される。このうち、終了ログについては、後述のログ生成部１７ｄによって前回にクライアント端末１０が強制終了されたと判定された場合に限って登録される場合を想定する。なお、ここでは、前回にクライアント端末１０が強制終了された場合に限って終了ログが登録される場合を想定するが、前回にクライアント端末１０が正常終了された場合にも終了ログを登録することとしてもかまわない。さらに、ログオフログは、正常終了および強制終了を問わずに取得されることとしても良い。
【００３４】
図４は、ログ情報の一例を示す図である。この図４の例では、ログ情報１３ｂの一例として、ログオンログ及びログオフログを図示している。これらログオンログ及びログオフログは、日時、区分、ユーザ名および備考が対応付けて記憶される。ここで言う「区分」は、ログオンまたはログオフのいずれのログであるかを示す。図４に示す例では、日時「2010/02/25 10:00:15:100」にユーザ名「UserA」のユーザがログオンしていることを表す。さらに、図４に示す例では、日時「2010/02/25 13:10:46:100」にユーザ名「UserB」のユーザがログオンしていることを表す。なお、図４の例では、「備考」のフィールドがブランクである場合を例示したが、「備考」には、ログオンまたはログオフに関する任意の事項を付記できる。かかる「備考」のフィールドに登録される情報の一例としては、ログオンしたユーザがゲストである旨やログオンされた時刻が勤務時間帯ではない旨などが登録される。
【００３５】
時刻情報１３ｃは、ＯＳの起動から経過した時刻を表す情報である。かかる時刻情報１３ｃの一例としては、システム日付やＯＳカウンタなどが挙げられる。ここで言う「システム（system）日付」は、ＯＳによって管理される日付を指す。また、「ＯＳカウンタ（counter）」は、ＯＳの起動時を起点とし、時間の経過にしたがってＯＳが計測したカウンタである。図５は、時刻情報の一例を示す図である。図５に示す例では、ＯＳ実行部１５によって計測されている日付が２０１０年２月２５日の１３時４５分３２秒であり、クライアント端末１０が今回起動してから２０５８２秒経過したことを示す。なお、システム日付及びＯＳカウンタは、後述のＯＳ実行部１５によって管理されているものが後述の取得部１７ａによって取得された後に後述の格納部１７ｂによって格納される。
【００３６】
制御部１４は、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などの電子回路またはＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路である。
【００３７】
制御部１４は、各種の処理手順を規定したプログラムや制御データを格納するための内部メモリを有し、これらによって種々の処理を実行する。制御部１４は、図２に示すように、ＯＳ実行部１５と、他の監視アプリ実行部１６ａ〜１６ｃと、監視アプリ実行部１７とを有する。なお、以下では、上述したログオフログオン監視アプリ以外のメール監視アプリ、アクセス監視アプリなどの監視アプリを「他の監視アプリ」と呼ぶ。
【００３８】
ＯＳ実行部１５は、コンピュータシステム全体を管理する基本ソフトウェアであるＯＳ（Operating System）の実行を制御する処理部である。
【００３９】
一例としては、ＯＳ実行部１５は、ＯＳの起動や終了に関する処理を実行する。例えば、電源ボタン１１ｃの押下操作を介してＯＳの起動要求を受け付けた場合に、ＯＳを起動する。また、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してクライアント端末１０のシャットダウン要求を受け付けた場合に、ログイン中のユーザのログオフを行ったり、ＯＳやアプリに関する各種の設定を保存した上でＯＳを終了する。この場合には、クライアント端末１０が正常終了されることになる。なお、電源ボタン１１ｃを介してクライアント端末１０が強制終了された場合には、ログイン中のユーザが強制的にログオフされ、ＯＳやアプリに関する各種の設定が保存されずにＯＳが強制終了される。この場合には、クライアント端末１０が強制終了されることになる。
【００４０】
他の一例としては、ＯＳ実行部１５は、ログオン及びログオフに関する処理を実行する。例えば、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してユーザのログオンを受け付けた場合に、ログオン認証を行った上でログオン認証に成功したユーザにＳＩＤを発行することによってユーザをログオンさせる。また、ＯＳ実行部１５は、キーボード１１ａやマウス１１ｂを介してユーザのログオフを受け付けた場合に、該当するログイン中のユーザのＳＩＤを破棄することによってユーザをログオフさせる。また、ＯＳ実行部１５は、後述のログ生成部１７ｄからＳＩＤの取得要求を受け付けた場合に、ログオン中のユーザのＳＩＤを応答する。なお、以下では、複数のユーザのログオンを同時に受け付けることが可能なＯＳが実行される場合を想定するが、ユーザのログオンを排他的に受け付けることとしてもよい。
【００４１】
更なる一例としては、ＯＳ実行部１５は、時刻情報を管理する処理を実行する。例えば、ＯＳ実行部１５は、時間経過にしたがってシステム日付を更新したり、また、時間経過にしたがってＯＳカウンタをカウントアップしたりする。また、ＯＳ実行部１５は、後述の取得部１７ａによってシステム日付及びＯＳカウンタの問合せを受け付けた場合に、システム日付及びＯＳカウンタの値を取得部１７ａへ応答する。
【００４２】
他の一例としては、ＯＳ実行部１５は、クライアント端末１０で実行されるログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリ、その他の汎用アプリのプロセスを管理する処理を実行する。例えば、ＯＳ実行部１５は、後述の他の監視アプリ実行部１６ａ〜１６ｃまたは監視アプリ実行部１７から問合せ元以外の監視アプリに関する起動の有無の問合せを受け付けた場合に、問合せ元以外の監視アプリの起動の有無を問合せ元の監視アプリへ応答する。また、ＯＳ実行部１５は、後述の他の監視アプリ実行部１６ａ〜１６ｃまたは監視アプリ実行部１７から問合せ元以外の監視アプリに関する再起動の要求を受け付けた場合に、該当する監視アプリを再起動させる。なお、クライアント端末１０では、上記のログオフログオン監視アプリ、メール監視アプリ、アクセス監視アプリ以外のアプリ、例えばワープロソフト、表計算ソフトや作図ソフトなどのプロセスの管理を行うことは言うまでもない。
【００４３】
他の監視アプリ実行部１６ａ〜１６ｃは、ログオフログオン監視アプリ以外のメール監視アプリ、アクセス監視アプリの実行を制御する処理部である。ここでは、他の監視アプリ実行部１６ａ〜１６ｃは、各々１つの監視アプリの実行を制御するものとする。これら他の監視アプリ実行部１６ａ〜１６ｃは、自らが実行する監視アプリ以外の監視アプリの起動の有無をＯＳ実行部１５に問い合わせることによって監視する処理をそれぞれ実行する。このとき、他の監視アプリ実行部１６ａ〜１６ｃは、ＯＳ実行部１５から起動していない監視アプリが存在する旨の応答が得られた場合に、起動していない監視アプリの再起動させるＡＰＩをＯＳ実行部１５へ出力する。なお、以下では他の監視アプリ実行部１６ａ〜１６ｃを総称する場合には「他の監視アプリ実行部１６」と記載する。
【００４４】
監視アプリ実行部１７は、ログオフログオン監視アプリの実行を制御する処理部である。この監視アプリ実行部１７は、図２に示すように、取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄとをさらに有する。
【００４５】
このうち、取得部１７ａは、ＯＳ実行部１５によって計測された時刻情報を取得する処理部である。一例としては、取得部１７ａは、所定の期間、例えば１秒ごとにシステム日付及びＯＳカウンタの問合せをＯＳ実行部１５へ出力する。そして、取得部１７ａは、問合せに対する応答して得られたシステム日付及びＯＳカウンタの値を取得する。なお、ここでは、一定周期で時刻情報を取得する場合を例示したが、開示の装置はこれに限定されない。例えば、一定周期ではなく、時間帯によって周期を可変としてもよいし、定期時刻に時刻情報を取得するようにしてもよい。
【００４６】
格納部１７ｂは、取得部１７ａによって取得された時刻情報を記憶部１３へ格納する処理部である。かかる時刻情報は、ログオンログオフ監視アプリの設定データ、いわゆるレジストリ（registry）として記憶部１３へ格納することとしてもよいし、ファイル（file）として記憶部１３へ格納することとしてもかまわない。
【００４７】
ログ送信部１７ｃは、記憶部１３によって記憶されたログ情報１３ｂを管理サーバ３０へ送信する処理部である。このログ送信部１７ｃは、ログ情報１３ｂを任意のタイミングで管理サーバ３０へ送信できる。一例としては、ログ送信部１７ｃは、後述のログ生成部１７ｄによってログ情報が生成される度にそのログ情報をリアルタイム送信することができる。他の一例としては、ログ送信部１７ｃは、クライアント端末１０が起動されたことや、ネットワークに接続されたことを契機に記憶部１３に記憶されていたログ情報１３ｂを送信することもできる。
【００４８】
ログ生成部１７ｄは、ＯＳの終了に関するログ情報を生成する処理部である。なお、ここでは、ログ生成部１７ｄがクライアント端末１０のログオンログ、クライアント端末１０のログオフログ及びクライアント端末１０の終了ログを生成する場合を例示するが、ログオフログまたは終了ログのいずれかのみを生成することとしてもよい。
【００４９】
一例としては、ログ生成部１７ｄは、所定の期間、例えば格納部１７ｂによって時刻情報が記憶部１３へ格納される度に、ＯＳ実行部１５から取得したログオン中のユーザのＳＩＤに基づいて、ログオンログ及び／又はログオフログを更新する。
【００５０】
これを説明すると、ログ生成部１７ｄは、ＯＳ実行部１５にＳＩＤの取得要求を行ってログオン中のユーザのＳＩＤを取得する。そして、ログ生成部１７は、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在するか否かを判定する。このとき、ログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在する場合には、新たなユーザがログオンしてＳＩＤが追加されたことがわかる。よって、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａに追加した上でそのユーザＩＤ及びＳＩＤをログオンログとしてログ情報１３ｂへ追加登録する。
【００５１】
また、ログ生成部１７ｄは、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａから削除されたＳＩＤが存在するか否かを判定する。このとき、ログオンユーザリスト１３ａから削除されたＳＩＤが存在する場合には、ログオンしていたユーザがログオフしてＳＩＤが削除されたことがわかる。よって、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａから削除した上でそのユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。この構成によって、複数のユーザが同時に１つのクライアントにログオンして、操作を行う形態においても、ユーザごとに独立に各種ログを生成することができる。
【００５２】
ここで、図６〜図１０を用いて、ログオンログ及びログオフログの生成について説明する。図６は、ＯＳ実行部から取得されたＳＩＤリストの一例を示す。図７及び図９は、ログオンユーザリストの更新例を示す図である。図８は、ログオンログの生成例を示す図である。図１０は、ログオフログの生成例を示す図である。
【００５３】
例えば、図６に示すＳＩＤリストがＯＳ実行部１５から取得された場合には、ログ生成部１７ｄは、図３に示したログオンユーザリスト１３ａに比べて、「UserC」のＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」が新たに追加されたことを検知する。この場合には、ログ生成部１７ｄは、図７に示すように、新たに追加された「UserC」のＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」を図３に示したログオンユーザリスト１３ａに追加する。その上で、ログ生成部１７ｄは、図８に示すように、新たに追加されたユーザＩＤ「UserC」及びＳＩＤ「S-1-5-21-5524773582-726422xxxxxxx」を区分「ログオン」として図４に示したログ情報１３ｂに追加登録する。
【００５４】
また、図６に示すＳＩＤリストがＯＳ実行部１５から取得された場合には、ログ生成部１７ｄは、図３に示したログオンユーザリスト１３ａに比べて、「UserB」のＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」が削除されたことを検知する。この場合には、ログ生成部１７ｄは、図９に示すように、ログオフによって削除された「UserB」のＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」を図７に示したログオンユーザリスト１３ａから削除する。その上で、ログ生成部１７ｄは、図１０に示すように、ログオフによって削除されたユーザＩＤ「UserB」及びＳＩＤ「S-1-5-21-7382364813-7264722xxxxxxx」を区分「ログオフ」として図９に示したログ情報１３ｂに追加登録する。
【００５５】
他の一例としては、ログ生成部１７ｄは、ＯＳ実行部１５によってシャットダウン要求が受け付けられた場合に、ログオンログオフ監視アプリの終了処理を行う。例えば、ログ生成部１７ｄは、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤを削除した上でそのユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。また、ログ生成部１７ｄは、時刻情報１３ｃとして記憶されたシステム日付及びＯＳカウンタの値をゼロにクリアする。図１１は、時刻情報のクリアを説明するための図である。図１１に示すように、ログ生成部１７ｄは、ＯＳ実行部１５によってシャットダウン要求が受け付けられた場合に、図５に示した時刻情報１３ｃをゼロクリアする。これによって、次回の監視アプリの起動時に今回の監視アプリの終了がＰＣの終了に伴って終了されたことを検知できる。このように、ログ生成部１７ｄは、終了命令情報がＯＳを用いたＯＳの終了を命令する情報である場合は、正常終了を示す正常終了情報、システム日付及びＯＳカウンタの初期状態である旨の情報を記憶部１３に格納する正常終了情報格納部としても機能する。かかる正常終了情報格納部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５６】
更なる一例として、ログ生成部１７ｄは、ログオンログオフ監視アプリが起動した場合に、記憶部１３に記憶された時刻情報１３ｃと、今回の起動時に取得部１７ａに取得させた時刻情報との差分に基づいて、前回のログオフログ及び終了ログを生成する。かかるログ生成部１７ｄは、ＯＳの終了に関するログ情報を生成するログ生成部の一態様である。なお、ログ生成部１７ｄは、ユーザによるＰＣの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける第一の受付部としても機能する。かかる第一の受付部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５７】
これを説明すると、ログ生成部１７ｄは、監視アプリが起動すると、ＯＳ実行部１５からシステム日付及びＯＳカウンタを取得部１７ａに取得させる。そして、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付及びＯＳカウンタを読み出す。なお、ここでは、起動時に取得部１７ａに取得させたシステム日付の値を「システム日付の取得値」と呼び、起動時に取得部１７ａに取得させたＯＳカウンタの値を「ＯＳカウンタの取得値」と呼ぶ。一方、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付の値を「システム日付の保存値」と呼び、記憶部１３に時刻情報１３ｃとして記憶されたＯＳカウンタの値を「ＯＳカウンタの保存値」と呼ぶ。このように、ログ生成部１７ｄは、記憶部１３の時刻情報が記憶される記憶領域にアクセスするアクセス部としても機能する。かかるアクセス部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００５８】
ここで、ログ生成部１７ｄは、システム日付の保存値がゼロであるか否かを判定する。このとき、システム日付の保存値がゼロである場合には、前回の監視アプリの終了がＰＣの正常終了に伴う終了であったとみなすことができる。よって、システム日付の保存値がゼロである場合には、ログ生成部１７ｄは、ログオフログ及び終了ログを生成せずに、ユーザのログオン及びログオフを定期的に監視する処理に移行する。一方、システム日付の保存値がゼロでない場合には、監視アプリが前回に正常終了されていないとみなすことができる。この場合には、クライアント端末１０が強制終了されたか、あるいは監視アプリが異常停止したかのいずれかと推定できる。なお、本実施例では、システム日付の保存値がゼロであるか否かによって前回の監視アプリの終了がＰＣの正常終了に伴う終了であったか否かを推定する場合を説明したが、ＯＳカウンタの保存値がゼロであるか否かによっても同様の推定が可能である。
【００５９】
このため、ログ生成部１７ｄは、システム日付の保存値がゼロでない場合に、システム日付の取得値およびシステム日付の保存値の差分が所定の閾値、例えば１０秒以下であるか否かをさらに判定する。ここで言う「閾値」は、上記の例に限定されるものではなく、他の監視アプリと相互起動する監視アプリが再起動された可能性を否定できる値、言い換えればＰＣが再起動するために要するであろう値であれば任意の値を採用できる。
【００６０】
すなわち、監視アプリは、他の監視アプリと互いの生存状況を監視し、いずれかの監視アプリが異常停止した場合には他の監視アプリによって再起動されるため、監視アプリが異常停止したとしても長期間にわたって停止する可能性は低い。その一方で、ＰＣの再起動には、ＰＣの性能に依存する部分はあるものの、監視アプリの再起動に比べてかなりの時間を要する。つまり、ユーザがＰＣを強制終了させた後に、すぐにＰＣを起動させたとしても、監視アプリの再起動に比べてかなりの時間を要する。さらには、ユーザがＰＣを強制終了させて、時間をおいてＰＣを再起動させた場合は、より長い時間が経過することとなる。このため、監視アプリの再起動所要時間及びＰＣの再起動所要時間の相関関係は、監視アプリの再起動所要時間の方がＰＣの再起動所要時間よりも短いと言える。よって、システム日付の取得値およびシステム日付の保存値の差分が所定値以上である場合には、前回の監視アプリの終了はＰＣの強制終了に伴うものであり、ＰＣの再起動に連動して監視アプリが再起動したものと推定できる。
【００６１】
このことから、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定値以上である場合に、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する。一方、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合には、監視アプリの再起動所要時間＜＜ＰＣの再起動所要時間であるため、システム日付だけからでは監視アプリの異常停止とは限らず、ＰＣが再起動された余地は残る。なぜなら、システム日付は、ＯＳの設定をユーザが変更することで容易に変更される。したがって、ユーザがシステム日付を変更したことによって、差分が所定値未満になってしまうと、正確なログオフログが取得できなくなる。
【００６２】
そこで、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合に、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きいか否かをさらに判定する。すなわち、ＰＣが再起動された場合には、ＯＳ実行部１５によって再起動後のＯＳカウンタはゼロにクリアされる一方で、監視アプリが異常停止した場合には、ＯＳは生存しているのでＯＳカウンタはゼロにクリアされずに継続してカウントアップされる。よって、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合には、前回に監視アプリが異常停止したと推定できる。一方、ＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合には、前回にＰＣが強制終了されたと推定できる。
【００６３】
このため、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合には、ログオフログ及び終了ログを生成せずに、ユーザのログオン及びログオフを定期的に監視する処理に移行する。
【００６４】
また、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合には、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとしてログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する。
【００６５】
このように、システム日付及びＯＳカウンタの両方を組み合わせてログオフログ及び終了ログの生成を判断した場合には、ＯＳカウンタだけを用いてログオフログ及び終了ログの生成を判断する場合に比べて、次のように正確な判断が可能となる。すなわち、ＰＣ電源のオン操作、ＰＣの強制終了操作、ＰＣ電源のオン操作の順に３つの操作の各々が短い間隔でなされたケースを想定する。このケースでは、２回目のＰＣ電源のオン操作から監視アプリが起動するまでに要した時間が、１回目のＰＣ電源のオン操作からＰＣの強制終了前までに経過した時間よりも大きいと、ＰＣが強制終了された場合でもＯＳカウンタの取得値が保存値より大きくなる場合がある。そこで、システム日付の取得値と保存値の差分によりＰＣの再起動と推定できる場合には、ＯＳカウンタの取得値及び保存値の大小によらず、ログオフログ及び終了ログを生成することによって、上記のケースでログ情報の生成漏れが発生するのを防止できる。
【００６６】
なお、図２を用いて説明してきたように、ログ生成部１７ｄは、他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較する比較部としても機能する。かかる比較部の機能をログ生成部１７ｄとは別の機能部とすることとしてもかまわない。
【００６７】
［処理の流れ］
次に、本実施例に係るクライアント端末における処理の流れを説明する。なお、ここでは、クライアント端末１０によって実行される（１）ログオンログオフ監視処理を説明してから、（２）終了ログ取得処理について説明する。
【００６８】
（１）ログオンログオフ監視処理
図１２は、実施例に係るログオンログオフ監視処理の手順を示すフローチャートである。このログオンログオフ監視処理は、監視アプリの起動後に監視アプリが終了されるまで所定の時間ごとに繰り返し実行される処理である。
【００６９】
図１２に示すように、格納部１７ｂは、取得部１７ａによってＯＳ実行部１５から取得されたシステム日付及びＯＳカウンタの値を時刻情報１３ｃとして記憶部１３へ記録する（ステップＳ１０１及びステップＳ１０２）。
【００７０】
続いて、ログ生成部１７ｄは、ＯＳ実行部１５にＳＩＤの取得要求を行ってログオン中のユーザのＳＩＤを取得する（ステップＳ１０３）。そして、ログ生成部１７は、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａにあるＳＩＤとは異なるＳＩＤが存在するか否か、すなわち今回追加されたセッションがあるか否かを判定する（ステップＳ１０４）。
【００７１】
このとき、今回追加されたセッションがある場合（ステップＳ１０４肯定）には、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａに追加する（ステップＳ１０５）。そして、ログ生成部１７ｄは、新たに追加されたユーザＩＤ及びＳＩＤをログオンログとして生成し（ステップＳ１０６）、そのログオンログをログ情報１３ｂへ追加登録する。
【００７２】
一方、今回追加されたセッションがない場合（ステップＳ１０４否定）には、新たなユーザがログオンしてＳＩＤが追加されていないので、そのままステップＳ１０７の処理へ移行する。
【００７３】
その後、ログ生成部１７ｄは、ＯＳ実行部１５から取得したＳＩＤの中に、記憶部１３に記憶されたログオンユーザリスト１３ａから削除されたＳＩＤが存在するか否か、すなわち今回削除されたセッションがあるか否かを判定する（ステップＳ１０７）。
【００７４】
このとき、今回削除されたセッションがある場合（ステップＳ１０７肯定）には、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオンユーザリスト１３ａから削除する（ステップＳ１０８）。その上で、ログ生成部１７ｄは、ログオフしたユーザＩＤ及びＳＩＤをログオフログとして生成し（ステップＳ１０９）、そのログオフログをログ情報１３ｂへ追加登録する。なお、今回削除されたセッションがない場合（ステップＳ１０７否定）には、そのままステップＳ１０１の処理に戻る。
【００７５】
このようにして、監視アプリ実行部１７は、監視アプリが生存している限りは、上記のステップＳ１０１〜ステップＳ１０９までの処理を繰り返し行う。
【００７６】
（２）終了ログ取得処理
図１３は、実施例に係る終了ログ取得処理の手順を示すフローチャートである。この終了ログ取得処理は、ログオンログオフ監視アプリが起動した場合に実行させる処理であり、処理の終了後には上記のログオンログオフ監視処理に移行する。
【００７７】
図１３に示すように、ログ生成部１７ｄは、監視アプリが起動すると、ＯＳ実行部１５からシステム日付及びＯＳカウンタを取得部１７ａに取得させる（ステップＳ３０１及びステップＳ３０２）。
【００７８】
ここで、ログ生成部１７ｄは、記憶部１３に時刻情報１３ｃとして記憶されたシステム日付の保存値がゼロであるか否かを判定する（ステップＳ３０３）。このとき、システム日付の保存値がゼロである場合（ステップＳ３０３肯定）には、ログ生成部１７ｄは、前回にＰＣが正常終了されたと判断し（ステップＳ３０４）、ログオフログ及び終了ログを生成せずに処理を終了する。
【００７９】
一方、システム日付の保存値がゼロでない場合（ステップＳ３０３否定）に、ログ生成部１７ｄは、システム日付の取得値およびシステム日付の保存値の差分が所定の閾値、例えば１０秒以下であるか否かをさらに判定する（ステップＳ３０５）。このとき、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合（ステップＳ３０５肯定）に、ログ生成部１７ｄは、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きいか否かをさらに判定する（ステップＳ３０６）。
【００８０】
ここで、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合（ステップＳ３０６肯定）には、ログ生成部１７ｄは、次のように判断する。すなわち、ログ生成部１７ｄは、前回に監視アプリの終了が異常停止であったと判断し（ステップＳ３０７）、ログオフログ及び終了ログを生成せずに処理を終了する。
【００８１】
一方、システム日付の取得値およびシステム日付の保存値の差分が所定値よりも大きい場合（ステップＳ３０５否定）またはＯＳカウンタの取得値がＯＳカウンタの保存値以下である場合（ステップＳ３０６否定）には、次のように判断される。すなわち、ログ生成部１７ｄは、前回にＰＣが強制終了されたと判断する（ステップＳ３０８）。
【００８２】
この場合には、ログ生成部１７ｄは、ログオンユーザリスト１３ａに搭載されているユーザＩＤ及びＳＩＤをログオフログとして生成し（ステップＳ３０９）、そのログオフログをログ情報１３ｂへ追加登録する。さらに、ログ生成部１７ｄは、記憶部１３に記憶されていたシステム日付の保存値を前回のＰＣの終了日付とし、このＰＣの終了日付とともにＰＣが強制終了された旨を表すフラグ等の情報をＰＣの終了ログとしてログ情報１３ｂへ登録する（ステップＳ３１０）。このようにしてログオフログ及び終了ログを生成後に処理を終了する。
【００８３】
なお、システム日付のみを用いてログオフログ及び終了ログを生成する場合には、上記のステップＳ３０１〜ステップＳ３１０のうち、ステップＳ３０２及びステップＳ３０６を省略することができる。また、ＯＳカウンタのみを用いてログオフログ及び終了ログを生成する場合には、上記のステップＳ３０１〜ステップＳ３１０のうち、ステップＳ３０１及びステップＳ３０５を省略できる。その代わりに、ステップＳ３０３でシステム日付に代えてＯＳカウンタの保存値がゼロであるか否かを判定する。
【００８４】
また、ログ生成部１７ｄは、Ｓ３０５のシステム日付を用いた判定とＳ３０６のＯＳカウンタを用いた判定とを逆で行っても良い。その場合は、ＯＳカウンタの取得値がＯＳカウンタの保存値以下であると判定した場合（ステップＳ３０６肯定）には、ログ生成部１７ｄはＳ３０５の判定を実行する。そして、システム日付の取得値およびシステム日付の保存値の差分が所定値よりも大きい場合（ステップＳ３０５否定）、ログ生成部１７ｄは、前回にＰＣが強制終了されたと判断する。また、システム日付の取得値およびシステム日付の保存値の差分が所定値未満である場合（ステップＳ３０５肯定）、ログ生成部１７ｄは、前回に監視アプリの終了が異常停止であったと判断する。一方、ＯＳカウンタの取得値がＯＳカウンタの保存値よりも大きい場合（ステップＳ３０６否定）には、強制終了されたと判断する。
【００８５】
［実施例１の効果］
上述してきたように、本実施例に係るクライアント端末１０は、相互起動する複数アプリのうちの監視アプリは、異常終了後の起動時に、前回終了時刻よりも現時刻が大きければ監視アプリの異常終了であったとして、ＯＳの終了に関するログ情報は生成しない。それゆえ、本実施例に係るクライアント端末１０では、クライアント端末１０が動作中に監視アプリが異常停止した場合に、誤って終了ログを生成したり、また、誤ってログオフログを生成したりすることを防止できる。よって、本実施例に係るクライアント端末１０によれば、ＰＣの終了ログやＰＣのログオフログなどの基本ソフトウェアの終了に関するログを正確に取得できる。
【００８６】
また、本実施例に係るクライアント端末１０は、システム日付間の差分が所定値以上である場合に、ＯＳの終了に関するログ情報を生成する。さらに、本実施例に係るクライアント端末１０は、システム日付間の差分が所定値未満であってもＯＳカウンタの取得値よりもＯＳカウンタの保存値の方が大きい場合に、ＯＳの終了に関するログ情報を生成する。このため、本実施例に係るクライアント端末１０によれば、電源のオン操作、強制終了操作、電源のオン操作の順に３つの操作の各々が短い間隔でなされた場合でも、ログオフログ及びＰＣの終了ログの生成漏れを防止できる。
【００８７】
さらに、本実施例に係るクライアント端末１０は、時刻情報の取得値が時刻情報の保存値よりも小さい場合には、ＯＳの終了に関するログ情報を生成させない。そして、本実施例に係るクライアント端末１０は、時刻情報の保存値よりも時刻情報の取得値の方が大きい場合に、ＯＳの終了に関するログ情報を生成する。よって、本実施例に係るクライアント端末１０によれば、監視アプリが異常停止した場合に誤って終了ログ及びログオフログが生成するのを防止しつつ、クライアント端末１０が強制終了した場合に限ってログオフログ及び終了ログを生成できる。
【実施例２】
【００８８】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【００８９】
［分散および統合］
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、取得部１７ａ、格納部１７ｂ、ログ送信部１７ｃまたはログ生成部１７ｄをクライアント端末１０の外部装置としてネットワーク経由で接続するようにしてもよい。また、取得部１７ａ、格納部１７ｂ、ログ送信部１７ｃまたはログ生成部１７ｄを別の装置がそれぞれ有し、ネットワーク接続されて協働することで、上記のクライアント端末１０の機能を実現するようにしてもよい。
【００９０】
［終了ログ取得プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図１４を用いて、上記の実施例と同様の機能を有する終了ログ取得プログラムを実行するコンピュータの一例について説明する。なお、図１４は、実施例２に係る終了ログ取得プログラムを実行するコンピュータの一例について説明するための図である。
【００９１】
図１４に示すように、実施例２におけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard Disk Drive）１７０と、ＲＡＭ（Random Access Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【００９２】
ＲＯＭ１６０には、上記の実施例１で示した取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄと同様の機能を発揮する制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図１４に示すように、取得プログラム１６０ａと、格納プログラム１６０ｂと、ログ送信プログラム１６０ｃと、ログ生成プログラム１６０ｄが記憶される。これらのプログラム１６０ａ〜１６０ｄについては、図２に示したクライアント端末１０の各構成要素と同様、適宜統合又は分離しても良い。なお、ＲＡＭ１６０に格納される各データは、常に全てのデータがＲＡＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＡＭ１６０に格納されれば良い。
【００９３】
そして、ＣＰＵ１５０が、これらのプログラム１６０ａ〜１６０ｄをＲＯＭ１６０から読み出して実行する。これによって、ＣＰＵ１５０は、図１４に示すように、各プログラム１６０ａ〜１６０ｄについては、取得プロセス１５０ａ、格納プロセス１５０ｂ、ログ送信プロセス１５０ｃ及びログ生成プロセス１５０ｄとして機能するようになる。これらプロセス１５０ａ〜１５０ｄは、図２に示した、取得部１７ａと、格納部１７ｂと、ログ送信部１７ｃと、ログ生成部１７ｄとにそれぞれ対応する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。そして、ＣＰＵ１５０は、ＲＡＭ１８０に格納された情報を用いて、終了ログ取得プログラムを実行する。
【００９４】
なお、上記の終了ログ取得プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【００９５】
１ 情報漏えい対処システム
３ ネットワーク
１０Ａ〜１０Ｃ クライアント端末
１１ 入力部
１１ａ キーボード
１１ｂ マウス
１１ｃ 電源ボタン
１２ 通信Ｉ／Ｆ部
１３ 記憶部
１３ａ ログオンユーザリスト
１３ｂ ログ情報
１３ｃ 時刻情報
１４ 制御部
１５ ＯＳ実行部
１６ａ〜１６ｃ 他の監視アプリ実行部
１７ 監視アプリ実行部
１７ａ 取得部
１７ｂ 格納部
１７ｃ ログ送信部
１７ｄ ログ生成部
３０ 管理サーバ
５０ コンソール
【特許請求の範囲】
【請求項１】
コンピュータに、
ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付け、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得し、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納し、
前記基本ソフトウェアを終了させる終了命令情報を受付け、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理
を実行させることを特徴とする終了ログ取得プログラム。
【請求項２】
前記時刻情報を取得する処理において、前記基本ソフトウェアによって計測されるシステム日付を含む前記時刻情報を取得し、
前記他の時刻情報を取得する処理において、他のシステム日付を含む前記他の時刻情報を取得し、
前記比較する処理において、前記他のシステム日付と、前記記憶領域に格納された前記システム日付とのシステム日付間の差分を算出し、
前記ログ情報を生成する処理において、前記システム日付間の差分が所定値以上である場合、前記基本ソフトウェアを用いずに前記コンピュータが終了された情報を有する前記ログ情報を生成する
ことを特徴とする請求項１記載の終了ログ取得プログラム。
【請求項３】
前記システム日付間の差分が所定値よりも小さい場合に、前記終了命令情報を受付けずに前記監視が終了されたことを判断すると共に、前記ログ情報を生成しないことを特徴とする請求項２記載の終了ログ取得プログラム。
【請求項４】
前記時刻情報を取得する処理において、前記基本ソフトウェアによって計測されるＯＳカウンタを含む前記時刻情報を取得し、
前記他の時刻情報を取得する処理において、他のＯＳカウンタを含む前記他の時刻情報を取得し、
比較する処理において、前記他のＯＳカウンタと前記ＯＳカウンタとを比較し、
前記ログ情報を生成する処理において、前記他のＯＳカウンタが前記ＯＳカウンタよりも小さい場合に、前記基本ソフトウェアを用いずに前記コンピュータが終了された情報を有する前記ログ情報を生成する
ことを特徴とする請求項１乃至請求項３のいずれか一項に記載の終了ログ取得プログラム。
【請求項５】
前記コンピュータに、
前記第二の開始命令情報が、前記ユーザによる前記起動命令によらない他の監視を開始させる命令である場合に、該他の監視を開始する処理を実行させることを特徴とする請求項１乃至請求項４のいずれか一項に記載の終了ログ取得プログラム。
【請求項６】
ユーザによるコンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける第一の受付部と、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得する取得部と、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納する格納部と、
前記基本ソフトウェアを終了させる終了命令情報を受付ける第二の受付部と、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成するログ生成部と、
を有することを特徴とする終了ログ取得装置。
【請求項７】
コンピュータが、
ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付け、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得し、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納し、
前記基本ソフトウェアを終了させる終了命令情報を受付け、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理
を実行することを特徴とする終了ログ取得方法。
【請求項１】
コンピュータに、
ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付け、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得し、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納し、
前記基本ソフトウェアを終了させる終了命令情報を受付け、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理
を実行させることを特徴とする終了ログ取得プログラム。
【請求項２】
前記時刻情報を取得する処理において、前記基本ソフトウェアによって計測されるシステム日付を含む前記時刻情報を取得し、
前記他の時刻情報を取得する処理において、他のシステム日付を含む前記他の時刻情報を取得し、
前記比較する処理において、前記他のシステム日付と、前記記憶領域に格納された前記システム日付とのシステム日付間の差分を算出し、
前記ログ情報を生成する処理において、前記システム日付間の差分が所定値以上である場合、前記基本ソフトウェアを用いずに前記コンピュータが終了された情報を有する前記ログ情報を生成する
ことを特徴とする請求項１記載の終了ログ取得プログラム。
【請求項３】
前記システム日付間の差分が所定値よりも小さい場合に、前記終了命令情報を受付けずに前記監視が終了されたことを判断すると共に、前記ログ情報を生成しないことを特徴とする請求項２記載の終了ログ取得プログラム。
【請求項４】
前記時刻情報を取得する処理において、前記基本ソフトウェアによって計測されるＯＳカウンタを含む前記時刻情報を取得し、
前記他の時刻情報を取得する処理において、他のＯＳカウンタを含む前記他の時刻情報を取得し、
比較する処理において、前記他のＯＳカウンタと前記ＯＳカウンタとを比較し、
前記ログ情報を生成する処理において、前記他のＯＳカウンタが前記ＯＳカウンタよりも小さい場合に、前記基本ソフトウェアを用いずに前記コンピュータが終了された情報を有する前記ログ情報を生成する
ことを特徴とする請求項１乃至請求項３のいずれか一項に記載の終了ログ取得プログラム。
【請求項５】
前記コンピュータに、
前記第二の開始命令情報が、前記ユーザによる前記起動命令によらない他の監視を開始させる命令である場合に、該他の監視を開始する処理を実行させることを特徴とする請求項１乃至請求項４のいずれか一項に記載の終了ログ取得プログラム。
【請求項６】
ユーザによるコンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付ける第一の受付部と、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得する取得部と、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納する格納部と、
前記基本ソフトウェアを終了させる終了命令情報を受付ける第二の受付部と、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成するログ生成部と、
を有することを特徴とする終了ログ取得装置。
【請求項７】
コンピュータが、
ユーザによる前記コンピュータの起動命令に応じて、監視の開始を命令する第一の開始命令情報を受付け、
前記第一の開始命令を受付けた場合に、所定時間ごとに、前記コンピュータで動作される基本ソフトウェアから時刻に関する時刻情報を取得し、
前記所定時間ごとに取得した前記時刻情報を記憶領域へ格納し、
前記基本ソフトウェアを終了させる終了命令情報を受付け、
前記受付けた終了命令情報が、前記基本ソフトウェアを用いた該基本ソフトウェアの終了を命令する情報である場合は、正常終了を示す正常終了情報を前記記憶領域に格納し、
前記第一の開始命令情報とは異なる第二の開始命令情報を受付けた場合に、前記記憶領域にアクセスし、
前記記憶領域に前記正常終了情報が格納されていない場合には、前記基本ソフトウェアから他の時刻情報を取得し、
前記他の時刻情報と、前記記憶領域に格納された前記時刻情報とを比較し、
比較結果に基づいて、前記基本ソフトウェアの終了に関するログ情報を生成する処理
を実行することを特徴とする終了ログ取得方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【公開番号】特開２０１２−７８９４８（Ｐ２０１２−７８９４８Ａ）
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願番号】特願２０１０−２２１７４３（Ｐ２０１０−２２１７４３）
【出願日】平成２２年９月３０日（２０１０．９．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
【公開日】平成２４年４月１９日（２０１２．４．１９）
【国際特許分類】
【出願日】平成２２年９月３０日（２０１０．９．３０）
【出願人】（０００００５２２３）富士通株式会社 (25,993)
【Ｆターム（参考）】
[ Back to top ]