JP6746432B2 - 情報処理装置、情報処理装置の制御方法、及びプログラム - Google Patents

Description

本発明は、情報処理装置、情報処理装置の制御方法、及びプログラムに関する。

近年、画像処理装置（例えばＭＦＰ；Multi Function Peripheral）などの情報処理装置では、情報処理装置の稼働時間を記録し、消費電力量やＣＯ２排出量を計算する機能を有し、オフィスにおける環境負荷低減活動に寄与するものがある。ただし、既存の情報処理装置には、前記機能を有さないものも市場に存在しており、そのような情報処理装置を用いているオフィスでは、環境負荷低減活動を行うことができない。

なお、前記情報処理装置は一般的に、スキャナやプリンタなどの各種機能をアプリケーション単位で動作させるアプリケーションプラットフォーム環境を有する。以下、アプリケーションを「アプリ」、プラットフォームを「ＰＦ」、オペレーティングシステムを「ＯＳ」という。このような情報処理装置では、該情報処理装置上で動作するアプリにより、該情報処理装置が起動及び停止した時刻をログとして記録し、当該ログ情報から稼働時間を算出して環境負荷低減活動につなげることが考えられる。

具体的には、前記アプリは、前記情報処理装置のＯＳが記録する前記情報処理装置の起動後経過時間ファイルを参照し、ＯＳの現在時刻からの差分により起動時刻をログとして記録する。なお、前記情報処理装置のＯＳは、一般的には停止時のシャットダウン時刻そのものを管理していない。そのため、前記アプリは、前記情報処理装置がシャットダウン時のログを記録するシャットダウンログファイルの時刻情報を参照することで、前記情報処理装置の停止時刻をログとして記録することが考えられる。

特許文献１には、ＯＳとハードウェアの間のインタフェースの機能を果たす機能部によって、ＯＳシャットダウン後からＯＳ起動時までの情報処理装置の動作履歴を作成して不揮発性記憶部に記憶することにより、情報処理装置の不正使用や不良使用を検知する技術が提案されている。

特開２０１４−０７５１１８号公報

上述のように、情報処理装置の稼働時間をあまり正確に把握できないケースがある。具体例として、アプリが情報処理装置上のＯＳの前述したファイルの時刻を参照してログとして記録する場合、該ファイルが存在しない場合や正常にシャットダウンされず該ファイルが更新されていない場合には、アプリは、情報処理装置の停止時刻をログとして記録することができなくなってしまう。例えば、情報処理装置において瞬断など正常にシャットダウンが行われなかった場合、シャットダウンログファイルが作成されない（もしくは時刻情報が更新されない）場合が起こり得る。このような場合、アプリは、情報処理装置の停止時刻をログに記録できない。このため、情報処理装置の稼働時間を算出できないという事態が発生してしまう。なお、特許文献１の方法は、上述のようなアプリによるログの記録に適用できるものではない。

また、他の事例として、ディープスリープ状態への遷移および復帰に係る情報をアプリが取得できないため、当該時刻情報をログに記録できないという課題がある。ディープスリープ状態とは、スリープ状態（省電力状態）の１つであり、情報処理装置のＣＰＵやハードディスク（ＨＤＤ）への給電が停止される状態を示すものである。

本発明の目的は、上記の問題点を考慮して情報処理装置の稼働時間を適切に把握できるような仕組みを提供することである。

本発明は、アプリケーションがインストールされた情報処理装置であって、前記アプリケーションの機能として、前記情報処理装置の電源がオンされた時刻情報を示すログと、前記情報処理装置の電源がオフされた時刻情報を示すログとをログファイルに記録する第１記録手段と、周期的に現在時刻を用いて、前記情報処理装置の備える記憶装置内の管理ファイルで示す時刻情報を更新する更新手段と、前記アプリケーションが起動された場合に、前記管理ファイルで示す時刻情報と、前記アプリケーションとは異なるプログラムにおいて管理される最新のシャットダウンログで示す時刻情報とを比較する比較手段と、を有し、前記第１記録手段は、前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも前のタイミングを示す場合には、前記最新のシャットダウンログで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録し、前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも後のタイミングを示す場合には、前記管理ファイルで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録する、ことを特徴とする。

本発明によれば、情報処理装置の稼働時間を適切に把握することが可能となる。

本発明の情報処理装置の一実施例を示す画像処理装置のハードウェア構成図 画像処理装置のソフトウェア構成図 ログ取得アプリが記録する電源状態変化ログを説明する図 ログ取得アプリが記録する電源状態変化ログの時刻の種別を説明する図 ログ取得アプリの起動時のフローチャート ログ取得アプリの電源ＯＦＦファイル監視スレッドのフローチャート ログ取得アプリの停止時のフローチャート ログ取得アプリがログを記録した後の電源状態変化ログを説明する図 ログ取得アプリがログを記録した後のディープスリープ遷移ログを説明する図 ログ取得アプリのディープスリープ状態遷移の検知処理を説明するフローチャート

以下、本発明を実施するための形態について図面を用いて説明する。

以下、図１、図２を用いて、本実施例の情報処理装置のシステム構成について説明する。
図１は、本発明の情報処理装置の一実施例を示す画像処理装置100のハードウェア構成を例示する図である。

図１に示すように、画像処理装置100は、パーソナルコンピュータ（ＰＣ）などの他の情報処理装置と通信を行うためのネットワーク装置101を有する。また、画像処理装置100は、キーボードなどユーザ操作を受け付けるユーザ入力装置102、液晶ディスプレイなど操作画面を表示するＵＩ表示装置103を有する。さらに、画像処理装置100は、装置全体を制御するＣＰＵ104、ＣＰＵ104のワークスペースを提供するＲＡＭ105、画像原稿を読み取る読取装置106、画像データを印刷する印刷装置107、各種制御プログラムなどを記憶する記憶装置108を有する。画像処理装置100を構成する各装置は、メインバス109で接続されており、相互にデータの送受信が可能である。なお、ユーザ入力装置102とＵＩ表示装置103を別々の装置として記載しているが、これらの装置が一体となった操作部としてもよい。

以下、画像処理装置100が備えるソフトウェアについて説明する。
図２は、画像処理装置100のソフトウェア構成を例示する図である。なお、図２に示す各機能部は、画像処理装置100が有するＣＰＵ104が、記憶装置108に記憶される制御プログラムを必要に応じてＲＡＭ105上に読み出して実行することで実現される。

図２に示すように、画像処理装置100は、ＯＳ200、システム管理部210、Ｊａｖａ（登録商標）ＶＭ220、アプリＰＦ230、ログ取得アプリ240等を有する。
ＯＳ200は、プロセスの管理、メモリ管理、入出力管理を実行するオペレーティングシステムである。

システム管理部210は、ＯＳ200上で動作し、コピーなど画像処理装置100の基本的な機能を実現するプログラムであり、コントロール部211、機器情報管理部212などを有する。コントロール部211は、コピーやプリンタなど画像処理装置の各機能や、ＵＩ表示装置103に表示する操作画面などのシステムを制御する。機器情報管理部212は、画像処理装置100における機器の表示画面設定やコピーやプリンタ等の各機能設定など、機器のシステム設定情報を管理する。

また、機器情報管理部212は、画像処理装置100上のログ情報を記録したログファイルを管理し、コピーやプリンタなどの各機能の動作や、画像処理装置100の起動、停止に関わる処理動作などのログ情報をログファイルとして記録する。例えば、機器情報管理部212は、ＯＳ200からの通知により、画像処理装置100のシャットダウンを監視して、その時刻をシャットダウンログとして、シャットダウンログファイル（不図示）に記録する。ＯＳ200は、シャットダウンの際に、その旨をシステム管理部210に通知する。なお、正常にシャットダウンが行われることなく画像処理装置100が停止された場合（例えば突然電源プラグが抜かれたなどにより停止された場合）には、シャットダウンログは記録されない。本実施例では、システム管理部210の機器情報管理部212がシャットダウンログファイルを作成、管理する構成を例に説明するが、シャットダウンログファイルは、ＯＳ200が作成、管理する構成であってもよい。

Ｊａｖａ（登録商標）ＶＭ220は、Ｊａｖａ（登録商標）プログラムを実行する仮想マシンであり、アプリＰＦ230の実行基盤である。

アプリＰＦ230は、アプリに対して画像処理装置100を制御する機能を提供するアプリケーションプラットフォームであり、アプリの実行基盤である。アプリＰＦ230は、プラットフォームを構成するクラスライブラリ群231、アプリのライフサイクルや参照関係管理を行うＯＳＧｉ（登録商標）232などを有する。クラスライブラリ群231は、アプリに対し、画像処理装置100を制御するコントロール部211、機器情報管理部212を制御可能とするための機能を提供する。加えて、クラスライブラリ群231は、アプリに対し、Ｊａｖａ（登録商標）ＶＭ220提供機能、及びＯＳＧｉ（登録商標）232管理上の他のアプリ提供の機能を制御可能とするための機能を提供する。

ログ取得アプリ240は、アプリＰＦ230上で動作するアプリケーションである。ログ取得アプリ240は、アプリＰＦ230を介して、システム管理部210における、コピーなどのコントロール制御処理の実行イベントや画像処理装置100の設定情報を取得し、ログファイルとして記録する。また、ログ取得アプリ240は、記録したログファイルを、外部出力する機能（外部出力機能）を有する。外部出力機能とは、例えば、通信部241によりネットワーク装置101を介したＨＴＴＰ通信による外部情報処理装置（不図示）へのログファイルの送信や、画像処理装置100に接続されたＵＳＢ（不図示）に対しログファイルをコピーする等の機能である。

なお、本実施例では、ログ取得アプリ240は、ログファイルに記録するログ情報として、画像処理装置100の起動時刻及び停止時刻も対象としている。以降、ログ取得アプリ240がこれらの時刻情報を示すログ情報を生成して記録したログファイルを「電源状態変化ログ」と表記する。

以下、電源状態変化ログについて図３を用いて説明する。また、図４を用いて、電源状態変化ログに記録する時刻の種別について説明する。

図３は、ログ取得アプリ240が記録する電源状態変化ログ300を説明する図である。
電源状態変化ログ300は、画像処理装置100の電源がオンされた時刻情報を示すログと、画像処理装置100の電源がオフされた時刻情報を示すログとを記録するログファイルであり、記憶装置108に記憶される。

図３に示すように、電源状態変化ログ300は、電源状態変化時刻（Time）301、機器識別番号（Device Serial No.）302、変化後電源状態（Switch Type）303、ログ取得アプリ情報判定フラグ（Appli Flag）304等の情報を含む。

ログ取得アプリ240は、アプリＰＦ230からの指示による自身の起動処理の度に、電源状態変化ログ300に、画像処理装置100の前回停止時刻と起動時刻を一セットとして追記する（例えば、305で示す二行の情報）。ただし、ログ取得アプリ240が初めて起動される場合には、ログ取得アプリ240は、画像処理装置100の前回停止時刻の追記は行わずに、起動時刻の追記を行う。

電源状態変化時刻301は、ログ取得アプリ240が、変化後電源状態303及びログ取得アプリ情報判定フラグ304の状態（後述する図４に示す）に応じて記録する時刻であり、本実施例ではUnix時刻で記録を行うがこれに限定されるものではない。記録する時刻の種別の詳細は、図４にて後述する。

機器識別番号302は、画像処理装置100固有の機器の識別番号であり、本実施例では、８桁の英数文字で構成するものとする。

変化後電源状態303は、画像処理装置100の電源状態の変化を表す。画像処理装置100が起動状態になった時の時刻の場合、ログ取得アプリ240は文字列として"ON"を記録する。また、画像処理装置100が停止状態になった時の時刻の場合、ログ取得アプリ240は文字列として"OFF"を記録する。

ログ取得アプリ情報判定フラグ304は、ログ取得アプリ240が記録する電源状態変化時刻301が、ログ取得アプリ240内部で保持していた時刻を基に記録したかどうかを表すものである。ログ取得アプリ240内部で保持している時刻を電源状態変化時刻301として記録する場合には、ログ取得アプリ240は、文字列として"True"を記録する。また、電源状態変化時刻301としてＯＳ200及び機器情報管理部212から取得した時刻を電源状態変化時刻301として記録する場合には、ログ取得アプリ240は、文字列として"false"を記録する。

図４は、ログ取得アプリ240が電源状態変化ログ300に記録する電源状態変化時刻301について説明する図である。

例えば、変化後電源状態303を"ON"、且つ、ログ取得アプリ情報判定フラグ304を"True"と記録する場合、ログ取得アプリ240は、電源状態変化時刻301に、ログ取得アプリ240が自身の起動時に記録した時刻を記録する（401）。この401に示す時刻は、ログ取得アプリ240がアプリＰＦ230から起動指示を受けた際に、その起動処理の先頭でＯＳ200が有する画像処理装置100の現在時刻を参照することで得られる。

また、変化後電源状態303を"ON"、且つ、ログ取得アプリ情報判定フラグ304を"False"と記録する場合、ログ取得アプリ240は、電源状態変化時刻301に、ＯＳ200の起動時刻を記録する（402）。この402に示す時刻は、ログ取得アプリ240がアプリＰＦ230から起動指示を受けた際に、その起動処理内でＯＳ200が管理する画像処理装置100の現在時刻から起動後経過時間ファイル（不図示）の経過時間の差分を計算することで得られる。

また、変化後電源状態303を"OFF"、且つ、ログ取得アプリ情報判定フラグ304を"True"と記録する場合、ログ取得アプリ240は、電源状態変化時刻301に、ログ取得アプリ240で管理している記憶装置１０８内の電源ＯＦＦファイル（不図示）の時刻情報を記録する（403）。この403に示す時刻は、ログ取得アプリ240がアプリＰＦ230から起動指示を受けた際に、該起動処理内でログ取得アプリ240が前回画像処理装置100起動時に更新した電源ＯＦＦファイルの時刻情報から得られる。電源ＯＦＦファイルは、当該時刻の記録のためにログ取得アプリ240により作成される管理ファイルであり、作成及び更新のタイミングは後述する図５〜図７で説明する。

また、変化後電源状態303を"OFF"、且つ、ログ取得アプリ情報判定フラグ304を"False"と記録する場合、ログ取得アプリ240は、電源状態変化時刻301に、機器情報管理部212で管理しているシャットダウンログファイルの時刻情報を記録する（404）。この404に示す時刻は、ログ取得アプリ240がアプリＰＦ230から起動指示を受けた際に、該起動処理内で機器情報管理部212で管理している記憶装置１０８内の前回画像処理装置100の停止処理のログ情報を記録したシャットダウンログファイルの時刻情報から得られる。

以下、本実施例おけるログ取得アプリ240の起動処理（図５）、電源ＯＦＦファイル監視スレッド処理（図６）及び停止処理（図７）について説明する。なお、図５〜図６に示すフローチャートの処理は、画像処理装置100のＣＰＵ104が記憶装置108に記憶される制御プログラムをＲＡＭ105上に読み出して実行することで実現される。

図５は、ログ取得アプリ240の起動処理を例示するフローチャートである。ログ取得アプリ240は、アプリＰＦ230によって起動指示を受けた際に、本フローチャートに沿って起動処理を実行する。

まず、S500において、ログ取得アプリ240は、ＯＳ200から画像処理装置100のシステムの現在時刻を取得し、アプリ起動時刻としてRAM105に記録する。このアプリ起動時刻は、本フローチャートにおける後の処理（S511）において、図４の401に該当する時刻として用いるために記録されるものである。

次に、S501において、ログ取得アプリ240は、自分自身で管理している記憶装置１０８内のファイルにアプリ再起動フラグファイル（不図示）が存在するかどうかを判定する。アプリ再起動フラグファイルは、後述する図７のログ取得アプリ240の停止処理のフローチャートにて、ログ取得アプリ240がアプリＰＦ230によってアプリ単独の停止指示を受けた際に作成されるものである。なお、S501の判定は、画像処理装置100自体の起動状態が停止、開始されたためにログ取得アプリ240が停止、起動したのか、またはアプリＰＦ230によりログ取得アプリ240のみが単独で停止、起動したのかを判断するために実施されるものである。なお、本実施例では、アプリ再起動フラグファイルを作成することにより、前回のログ取得アプリ240の停止がＯＳ200のシャットダウンに伴う停止ではなかったことを示す構成について説明した。しかし、前回のログ取得アプリ240の停止がＯＳ200のシャットダウンに伴う停止ではなかったことを示す所定の情報を記録する構成であれば、どのような構成であってもよい。

上記S501において、自分自身で管理している記憶装置１０８内のファイルにアプリ再起動フラグファイルが存在すると判定した場合（S501でYesの場合）、すなわち前回、ログ取得アプリ240のみが単独で停止した場合、ログ取得アプリ240は、S520に処理を進める。なお、S520以降の処理については後述する。

一方、上記S501において、自分自身で管理している記憶装置１０８内のファイルにアプリ再起動フラグファイルが存在しないと判定した場合（S501でNoの場合）、すなわち前回、画像処理装置100自体が停止したためにログ取得アプリ240が停止した場合、ログ取得アプリ240は、S502に処理を進める。

S502において、ログ取得アプリ240は、自分自身で管理している記憶装置１０８内のファイルに電源ＯＦＦファイルが存在するかどうか判定する。電源ＯＦＦファイルは、図６のログ取得アプリ240起動後の処理である電源ＯＦＦファイル監視スレッド処理において作成（初回起動時）、更新されるものである。このため、S502の判定では、電源ＯＦＦファイルを、ログ取得アプリ240が初回起動時かどうかを判定するために用いている。

上記S502において、自分自身で管理している記憶装置１０８内のファイルに電源ＯＦＦファイルが存在すると判定した場合（S502でNoの場合）、すなわちログ取得アプリ240が初回起動時でない場合、ログ取得アプリ240は、S503に処理を進める。

S503において、ログ取得アプリ240は、機器情報管理部212で管理している記憶装置１０８内のシャットダウンログファイルと電源ＯＦＦファイルの時刻情報をそれぞれ取得する。
次に、S504において、ログ取得アプリ240は、上記S503で取得した時刻情報の比較を行い、シャットダウンログファイルの時刻情報のほうが新しいかどうかを判定する。

そして、上記S504において、シャットダウンログファイルの時刻情報のほうが新しいと判定した場合（S504でYesの場合）、すなわち画像処理装置100が前回停止時に正常にシャットダウンした場合、ログ取得アプリ240は、シャットダウンログファイルの時刻情報を電源状態変化時刻301とすると判断する（図４の404に該当）。そして、S505において、ログ取得アプリ240は、電源状態変化ログ300に、電源状態変化時刻301としてシャットダウンログファイルの時刻情報、機器識別番号、変化後電源状態303として"OFF"、ログ取得アプリ情報判定フラグ304として"False"を記録する。そして、S507に処理を進める。

一方、上記S504において、シャットダウンログファイルの時刻情報のほうが新しくないと判定した場合（S504でNoの場合）、すなわち画像処理装置100が前回停止時に正常にシャットダウンしなかった場合（異常シャットダウンにより停止した場合）、ログ取得アプリ240は、電源ＯＦＦファイルの時刻情報を電源状態変化時刻301とすると判断する（図４の403に該当）。そして、S506において、ログ取得アプリ240は、電源状態変化ログ300に、電源状態変化時刻301として電源ＯＦＦファイルの時刻情報、機器識別番号、変化後電源状態303として"OFF"、ログ取得アプリ情報判定フラグ304として"True"を記録する。そして、S507に処理を進める。
なお、上記S504での判定の基準に関しては、図７のログ取得アプリ240の停止処理のフローチャートまで述べた段階で詳細に説明する。

また、上記S502において、自分自身で管理している記憶装置１０８内のファイルに電源ＯＦＦファイルが存在しないと判定した場合（S502でYesの場合）、すなわちログ取得アプリ240が初回起動時の場合、ログ取得アプリ240は、画像処理装置100の前回の停止時刻の記録（S503〜S506）を行わず、そのままS507に処理を進める。

次に、S507において、ログ取得アプリ240は、ＯＳ200から、ＯＳ200の起動後経過時間ファイルを取得し、起動後経過時間を記憶するように試みる。
さらに、S508において、ログ取得アプリ240は、上記S507でログ取得アプリ240がＯＳ200の起動後経過時間ファイルを取得できたかどうかを判定する。そして、起動後経過時間ファイルを取得できたと判定した場合（S508でYesの場合）、ログ取得アプリ240は、S509に処理を進める。

S509において、ログ取得アプリ240は、ＯＳ200から画像処理装置100のシステムの現在時刻を取得し、現在時刻から起動後経過時間を減算することでＯＳ起動時間を算出する（図４の402に該当）。
さらに、S510として、ログ取得アプリ240は、電源状態変化ログ300に、電源状態変化時刻301としてＯＳ起動時間、機器識別番号、変化後電源状態303として"ON"、ログ取得アプリ情報判定フラグ304として"False"を記録し、S512に処理を進める。

一方、起動後経過時間ファイルを取得できなかったと判定した場合（S508でNoの場合）、ログ取得アプリ240は、上記S509のようにＯＳ起動時間が算出できないため、上記S500で記憶したアプリ起動時刻をＯＳ起動時間に代替し（図４の401に該当）、S511に処理を進める。
S511において、ログ取得アプリ240は、電源状態変化ログ300に、電源状態変化時刻301としてアプリ起動時刻、機器識別番号、変化後電源状態303として"ON"、ログ取得アプリ情報判定フラグ304として"True"を記録し、S512に処理を進める。

S512において、ログ取得アプリ240は、電源ＯＦＦファイル監視スレッドを作成し、該スレッド処理（図６）を開始し、本フローチャートの処理を終了する。

図６は、ログ取得アプリ240の電源ＯＦＦファイル監視スレッド処理を例示するフローチャートである。

S600において、電源ＯＦＦファイル監視スレッドは、電源ＯＦＦファイルを作成する。この処理は、電源ＯＦＦファイルが存在しない場合（ログ取得アプリ240の初回起動時）に実行される。なお、電源ＯＦＦファイルは、以降のステップでファイルの時刻情報が更新できるものであれば、フォーマット、及びファイルの中身に構成の制限はない。

S601において、電源ＯＦＦファイル監視スレッドは、ログ取得アプリ240からのスレッド停止の指示が通知されているか判定する。この通知は、後述する図７に示すログ取得アプリ240の停止時のフローチャート内で電源ＯＦＦファイル監視スレッドに対し通知される。

そして、上記S601において、ログ取得アプリ240からのスレッド停止の指示が通知されていないと判定した場合（S601でNoの場合）、電源ＯＦＦファイル監視スレッドは、S602に処理を進める。

S602において、電源ＯＦＦファイル監視スレッドは、電源ＯＦＦファイルの更新処理を行い、現在時刻を用いて当該ファイルの時刻情報を更新する。その後、S603において、電源ＯＦＦファイル監視スレッドは、自身の処理を一定時間停止し、該一定時間後、S601に処理を戻す。

一方、上記S601において、ログ取得アプリ240からのスレッド停止の指示が通知さたと判定した場合（S601でYesの場合）、電源ＯＦＦファイル監視スレッドは、S604に処理を進める。

S604において、電源ＯＦＦファイル監視スレッドは、電源ＯＦＦファイルの更新処理を行い、現在時刻を用いて当該ファイルの時刻情報を更新する。その後、電源ＯＦＦファイル監視スレッドは、自身の処理を終了する。すなわち、ログ取得アプリ240の停止処理が実行されるまでは、電源ＯＦＦファイルは定期的（周期的）に更新され、該停止処理時にも更新される。
なお、上記S602、S604における電源ＯＦＦファイルの更新処理では、例えば、現在時刻（例えば年月日時分秒など）を電源ＯＦＦファイルのファイル名に反映させることにより電源ＯＦＦファイルで示す時刻情報を更新するものとする。しかし、電源ＯＦＦファイルで示す時刻情報はファイル名で示される形態に限定されるものではなく、電源ＯＦＦファイルで時刻情報を示すことができれば、いかなる形態であってもよい。

図７は、ログ取得アプリ240の停止時のフローチャート図である。本処理は、ログ取得アプリ240が、アプリＰＦ230により停止指示を受けた際に開始される。なお、アプリＰＦ230がログ取得アプリ240に停止指示を出すタイミングは、ログ取得アプリ240単体の起動を停止させる場合と、画像処理装置100の停止処理に基づくＯＳ200全体のシャットダウン時である。

S700において、ログ取得アプリ240は、ＯＳ200からシャットダウン指示通知がアプリＰＦ230に対して通知されている状態かアプリＰＦ230に対して確認を行う。この確認は、当該停止処理が画像処理装置100の停止処理に基づくＯＳ200全体のシャットダウンであるかどうかの判定のために用いる。

次に、S701において、ログ取得アプリ240は、上記S700の確認結果を基に、ＯＳ200のシャットダウン通知がアプリＰＦ230に対して通知されている状態か否かの判定を行う。

そして、ＯＳ200のシャットダウン通知がアプリＰＦ230に対して通知されている状態ではないと判定した場合（S701でNoの場合）、すなわちアプリＰＦ230がログ取得アプリ240単体に停止指示を出して停止させる場合、ログ取得アプリ240は、S702に処理を進める。S702において、ログ取得アプリ240は、アプリ再起動フラグファイルを作成し、S703に処理を進める。

一方、上記S701において、ＯＳ200のシャットダウン通知がアプリＰＦ230に対して通知されている状態であると判定した場合（S701でYesの場合）、すなわちＯＳ200のシャットダウン処理によりアプリＰＦ230から停止処理を実行する場合、ログ取得アプリ240は、そのままS703に処理を進める。

S703において、ログ取得アプリ240は、電源ＯＦＦファイル監視スレッド（図６）の停止指示を行う。当該ステップにより、電源ＯＦＦファイル監視スレッドは、図６のS601でYesと判定してS604の処理を行い、自身のスレッド処理を停止する。

ここで、図５のS504において行われる、シャットダウンログファイルと電源ＯＦＦファイルの時刻情報の比較による、電源状態変化ログ300の電源状態変化時刻301の記録時刻の変更処理について説明する。

画像処理装置100が通常の停止処理を行う場合、ＯＳ200のシャットダウン処理によりアプリＰＦ230から停止処理を実行する。すなわち、最初にログ取得アプリ240がステップS703までの処理を終えた状態になる。次に、アプリＰＦ230、Ｊａｖａ（登録商標）ＶＭ220、システム管理部210の順でシャットダウン処理が行われ、機器情報管理部212は、このタイミングで、シャットダウンログファイルにログを記録する。そしてＯＳ200のシャットダウンが行われ、画像処理装置100が動作を停止する。従って、ログ取得アプリ240が次回起動時にシャットダウンログファイルと電源ＯＦＦファイルの時刻情報を比較すると、シャットダウンログファイルの方が、時刻情報が新しく、且つ、より画像処理装置100動作停止時刻に近い時刻を有する（図５のS504でYesとなる）。そのため、ログ取得アプリ240は、シャットダウンログファイルの時刻情報を電源状態変化時刻301として記録する（図５のS505）。

しかし、画像処理装置100が瞬断などの電源断が発生し通常の停止処理を行えなかった場合、機器情報管理部212はシャットダウンログファイルにログを記録することができず、シャットダウンログファイルは更新されない。一方、ログ取得アプリ240は、図６のS601〜S603で示したように、電源ＯＦＦファイルを一定時間で更新しているため、前述の電源断発生時にも直前に更新された時刻情報を有する。従って、ログ取得アプリ240が次回起動時にシャットダウンログファイルと電源ＯＦＦファイルの時刻情報を比較すると、電源ＯＦＦファイルの方が、時刻情報が新しく、且つ、より画像処理装置100動作停止時刻に近い時刻を有する（図５のS504でNoとなる）。そのため、ログ取得アプリ240は、電源ＯＦＦファイルの時刻情報を電源状態変化時刻301として記録する（図５のS506）。

図８は、図５のシーケンスによる、ログ取得アプリ240がログを記録した後の電源状態変化ログ300を説明する図である。

まず、上述した図５のS502以降の処理において、S504の判定がYes、かつS508の判定がYesの場合に、ログ取得アプリ240が電源状態変化ログ300に記載するログ情報を図８中800に示す。上記判定により、ログ取得アプリ240は、停止時刻として図４中404、起動時刻として図４中402の情報を、それぞれ時刻として記録する。ここで、ログ取得アプリ240が上記ステップにより記録した停止時刻は画像処理装置100が前回停止した時刻であることから、画像処理装置100の起動時間としては、図８中802で示されるログ情報の時刻の差分が前回の起動時間となる。

次に、図５のS502以降の処理において、S504の判定がNo、かつS508の判定がNoの場合に、ログ取得アプリ240が電源状態変化ログ300に記載するログ情報を図８中801に示す。前記判定により、ログ取得アプリ240は、停止時刻として図４中403、起動時刻として図４中401の情報を、それぞれ時刻として記録する。ここで、ログ取得アプリ240が前記ステップにより記録した停止時刻は画像処理装置100が前回停止した時刻であることから、画像処理装置100の起動時間は図８中803で示されるログ情報の時刻の差分が前回の起動時間となる。

以上のように、画像処理装置100のＯＳ200の停止時刻を、ログ取得アプリ240が電源断発生直前に更新した電源ＯＦＦファイルの時刻情報で代替することで取得可能としている。そして、正常にシャットダウンが行われていない場合、上記電源ＯＦＦファイルの時刻を用いることで、画像処理装置100のＯＳ200の停止時刻の欠落がなくなり、画像処理装置100が起動した時間の算出精度を向上することが可能となる。

なお、本実施例では、ログ取得アプリ240が電源状態変化ログ300に画像処理装置100の起動時刻のログを残すタイミングを、ログ取得アプリ240起動時としている。しかし、ログ取得アプリ240がアプリＰＦ230により停止指示を受ける前に電源状態変化ログ300にログを記録できれば、ログ取得アプリ240起動時以外のタイミングであってもよい。

以下、図５のS520以降の処理について説明する。すなわち、図５のS501において、自分自身で管理している記憶装置１０８内のファイルにアプリ再起動フラグファイル（図７のS702で作成される）が存在すると判定した場合（S501でYesの場合）、すなわち前回、ログ取得アプリ240のみが単独で停止した場合に対応する場合の処理について説明する。

上述したように、図５のS501の判定は、アプリＰＦ230によりログ取得アプリ240が停止、起動された際に、ログ取得アプリ240のみが停止、起動したのか、画像処理装置100自体の起動状態が停止、及び開始されたためなのかを判断するために実施される。ログ取得アプリ240のみが停止、起動された場合、画像処理装置100が停止、及び起動を行っていないにも関わらず、ログ取得アプリ240は起動時刻、停止時刻をログファイルに記録してしまう。そこで、ログ取得アプリ240は、停止処理（図７）においてＯＳ200のシャットダウン状態を確認し（S701）、アプリ再起動フラグファイルを作成する（S702）ことで、次回起動時に前記ログの記録を制御することを可能にしている。

S520において、ログ取得アプリ240は、自身で管理している記憶装置１０８内のアプリ再起動フラグファイルを削除する。
次に、S521において、ログ取得アプリ240は、機器情報管理部212で管理している記憶装置１０８内のシャットダウンログファイルと電源ＯＦＦファイルの時刻情報を各々取得する。当該ステップの処理は、S503の処理と同じである。

次に、S522において、ログ取得アプリ240は、上記S521で取得した時刻情報の比較を行い、シャットダウンログファイルの時刻情報が新しいかどうか判定する。当該ステップの処理は、S504の処理と同じである。

そして、上記S522において、シャットダウンログファイルの時刻情報のほうが新しいと判定した場合（S522でYesの場合）、ログ取得アプリ240は、ログ取得アプリ240は、アプリＰＦ230による自身の再起動処理が完了する前に、画像処理装置100が動作を停止し再起動したと判断し、S523に処理を進める。S523において、ログ取得アプリ240は、電源状態変化ログ300に、電源状態変化時刻301としてシャットダウンログファイルの時刻情報、機器識別番号、変化後電源状態303として"OFF"、ログ取得アプリ情報判定フラグ304として"False"を記録する。そして、S507に処理を進める。S523の処理は、S505の処理と同じである。なお、S507以降の処理は、説明済みのため省略する。

一方、上記S522において、シャットダウンログファイルの時刻情報のほうが新しくないと判定した場合（S522でNoの場合）、アプリＰＦ230により自身の再起動処理が行われたものと判断し、電源状態変化ログ300へのログ記録処理を行わずにS512に処理を進める。なお、S512以降の処理は、説明済みのため省略する。

以上のように、ログ取得アプリ240単体がアプリＰＦ230により再起動された場合であっても、誤った起動時刻、停止時刻を記録しないように制御可能となる。また、ログ取得アプリ240がアプリＰＦ230による再起動完了前に画像処理装置100が停止した場合でも、ログ取得アプリ240の起動時に起動時刻、停止時刻を記録するように制御でき、画像処理装置100の起動時間の算出精度を向上することが可能となる。

ログ取得アプリ240が停止時刻を電源状態変化ログ300に記録する際に図４の403の状態に該当していた場合、電源ＯＦＦファイルの時刻情報そのものを記録するのではなく、電源ＯＦＦファイルの更新周期の時間分時刻を補正して記録するように構成してもよい。これは、例えば、電源ＯＦＦファイルの更新周期が長い場合（１時間おき等の場合）に、電源ＯＦＦファイルの時刻情報と電源断発生時の画像処理装置100の実際の停止時刻との差分が大きくなることを防ぐためである。

具体的には、図５のS506において、ログ取得アプリ240が、電源状態変化ログ300にログ情報を記録する際に、電源ＯＦＦファイルの時刻情報に更新周期の半分の時間を加えて電源状態変化時刻301に記録する。合わせて、ログ取得アプリ240は、電源ＯＦＦファイルの時刻情報更新周期時間、及び電源ＯＦＦファイルの時刻情報に加算した時間を、電源状態変化ログ300に追加したログのレコードに追記する。

なお、上記具体例では、電源ＯＦＦファイルの時刻情報に、該電源ＯＦＦファイルの更新周期の半分の時間を加えることにより補正した時刻情報を、画像処理装置100の前回停止時刻として、電源状態変化ログ300に記録する構成について説明した。なお、上記時刻情報の補正は、電源ＯＦＦファイルの時刻情報に電源ＯＦＦファイルの更新周期の半分の時間を加える補正に限定されるものではない。例えば、電源ＯＦＦファイルの時刻情報を電源ＯＦＦファイルの更新周期に基づいて補正するものであればどのような補正であってもよい。

以上により、実施例２によれば、ログ取得アプリ240が停止時刻を電源ＯＦＦファイルの時刻情報で代替した場合の時刻誤差の影響を低減することが可能となる。また、ログ取得アプリ240が電源ＯＦＦファイルの時刻情報更新周期時間、及び電源ＯＦＦファイルの時刻情報に加算した時間を追記することで、電源状態変化ログ300の利用者に停止時刻が補正されていることを通知できる。

本実施例では、ログ取得アプリ240が、画像処理装置100がディープスリープ状態へ遷移した時刻と、ディープスリープ状態から復帰した時刻を記録するように制御する例について述べる。以降、ログ取得アプリ240がこれらの時刻情報を示すログ情報を生成して記録したログファイルを「ディープスリープ遷移ログ」と表記する。

以下、ディープスリープ遷移ログについて図９を用いて説明する。
図９は、ログ取得アプリ240が記録するディープスリープ遷移ログ900を説明する図である。

ディープスリープ遷移ログ900は、画像処理装置100がディープスリープ状態へ遷移した時刻情報を示すログと、画像処理装置100がディープスリープ状態から復帰した時刻情報を示すログとを記録するログファイルであり、記憶装置108に記憶される。

図９に示すように、ディープスリープ遷移ログ900は、ディープスリープ状態変化時刻（Time）901、機器識別番号（Device Serial No.）902、変化後状態（Change Type）903の情報を含む。

ログ取得アプリ240は、ディープスリープ状態への遷移し復帰する度に、ディープスリープ遷移ログ900に、画像処理装置100のディープスリープ状態への遷移時刻と復帰時刻を一セットとして追記する（例えば、904で示す二行の情報）。

ディープスリープ状態変化時刻901は、ログ取得アプリ240が、変化後状態903の状態に応じて記録する時刻であり、本実施例ではUnix時刻で記録を行うがこれに限定されるものではない。
機器識別番号902は、画像処理装置100固有の機器の識別番号であり、本実施例では、８桁の英数文字で構成するものとする。

変化後状態903は、画像処理装置100のディープスリープ状態の変化を表す。画像処理装置100がディープスリープ状態へ遷移した時の時刻の場合、ログ取得アプリ240は文字列として"Deep Sleep Shift"を記録する。また、画像処理装置100がディープスリープ状態から復帰した時の時刻の場合、ログ取得アプリ240は文字列として"Deep Sleep Wake Up"を記録する。

以下、本実施例おけるログ取得アプリ240によるディープスリープ状態遷移の検知処理について図１０のフローチャートを用いて説明する。なお、図１０に示すフローチャートの処理は、画像処理装置100のＣＰＵ104が記憶装置108に記憶される制御プログラムをＲＡＭ105上に読み出して実行することで実現される。

ログ取得アプリ240は、アプリＰＦ230によって起動指示を受けた際に、本フローチャートに沿ってディープスリープ状態遷移の検知処理を実行する。
まず、S1001において、ログ取得アプリ240は、ＯＳ200から画像処理装置100のシステムの現在時刻を取得し、時刻情報としてRAM105に記録する。

次に、S1002において、ログ取得アプリ240は、一定期間、処理を待機する。例えば、一定期間は数秒から十数秒の程度を想定している。

次に、S1003において、待機処理後、ログ取得アプリ240は、ＯＳ200から画像処理装置100のシステムの現在時刻を取得し、時刻情報としてRAM105に記録する。

続いて、S1004において、ログ取得アプリ240は、RAM105に連続して記録された２つの時刻の差分が、前記S1002での待機時間である一定期間より大きいかどうか比較する。例えば、前記S1001で記憶した時刻と、前記S1003で記憶した時刻とが比較される。時刻の差分が一定期間以下の場合（S1004でNoの場合）、ログ取得アプリ240は、S1006処理を進める。なお、上述したS1001、S1003では、現在の時刻情報をRAM105に記録する構成について説明した。しかし、現在の時刻情報を記録する記憶領域はRAMに限定されるものではなく、現在の時刻情報を、電源ＯＦＦファイルの時刻情報とは別に記録する構成であればよい。

一方で、時刻の差分が一定期間より大きい場合（S1004でYesの場合）、ログ取得アプリ240は、S1005に処理を進める。
S1005において、ログ取得アプリ240は、前記S1001で記憶した時刻を「ディープスリープ遷移時刻」として、ディープスリープ遷移ログ900へ記録する。また、前記S1003で記憶した時刻を「ディープスリープ復帰時刻」として、ディープスリープ遷移ログ900へ記録する。「ディープスリープ遷移時刻」はディープスリープ遷移ログ900において、変化後状態903を"Deep Sleep Shift"と記録する。なお、「ディープスリープ復帰時刻」は変化後状態903を"Deep Sleep Wake Up"と記録する。

前記S1002の待機処理の間に画像処理装置100がディープスリープ状態へ遷移すると、ＣＰＵ104が停止することにより、ログ取得アプリ240の待機処理はディープスリープ状態から復帰するまで動作しない。しかし、画像処理装置100のシステムの時刻は停止しないために、画像処理装置100がディープスリープ状態へ遷移すると、前記S1001で記憶した時刻と、前記S1003で記憶した時刻の差分がS1002で指定した一定期間より大きくなる。前記S1005の処理の後、ログ取得アプリ240は、S1005に処理を進める。

次に、S1006において、ログ取得アプリ240は、前記S1001で記憶した時刻をRAM105から削除し、S1002の処理へ戻る。なお、前記S1003で記憶した時刻はそのままRAM105に保持しておき、次回のS1003にて取得する現在時刻と、S1004の比較処理にて差分の比較対象として使用する。

以上により、ログ取得アプリ240が、情報処理装置におけるディープスリープ状態への遷移、およびディープスリープ状態からの復帰に係る時刻情報を取得することが可能となる。

ログ取得アプリ240がディープスリープ遷移時刻と復帰時刻をディープスリープ遷移ログ900に記録する際に、ＯＳ２００から取得した時刻情報そのものを記録するのではなく、待機処理の一定期間の時間分、時刻を補正して記録するように構成してもよい。これは、例えば、待機処理の一定期間が長い場合（１時間おき等の場合）に、ディープスリープ遷移時刻から復帰時刻までの時間と実際の画像処理装置100のディープスリープ状態の時間との差分が大きくなることを防ぐためである。

具体的には、図１０のS1005において、ログ取得アプリ240が、ディープスリープ遷移ログ900にログ情報を記録する際に、ディープスリープ遷移時刻に待機処理の一定期間の時間分を加算した時間を記録する。或いは、ディープスリープ復帰時刻から待機処理の一定期間の時間分を減算した時間を記録する。この際、ログ取得アプリ240は、これに合わせて、前記待機処理の一定期間（すなわちシステムの現在時刻をRAM105に記録する周期）に基づく補正量（加算又は減算した分の時間）を、ディープスリープ遷移ログ900に追加したログのレコードに追記するようにしてもよい。

以上により、実施例４によれば、ログ取得アプリ240が画像処理装置100のディープスリープ状態の時間の誤差を補正することが可能となる。

以上示したように、本発明によれば、情報処理装置の稼働時間を適切に把握することが可能となる。

なお、上記各実施例では、本発明の情報処理装置の一例として画像処理装置を用いて説明したが、本発明の情報処理装置は画像処理装置に限定されるものではない。例えば、アプリがインストールされた情報処理装置であって、該アプリが該情報処理装置で管理される最新のシャットダウンログで示す時刻情報、起動後経過時間等を取得可能な情報処理装置であれば、本発明を適用可能である。例えば、パーソナルコンピュータやスマートフォンなどであっても、本発明を適用可能である。

以上のように、本発明では、情報処理装置の停止時刻を情報処理装置のシャットダウンログファイルの時刻情報を基に記録するアプリが、シャットダウンログファイルが取得できない（又はシャットダウンログファイルが更新されていない）場合でも、アプリで管理しているファイルの最終更新時刻情報等から停止時刻情報を代替し記録する構成を有する。具体的には、ログ取得アプリが、アプリＰＦからの起動要求時に、時刻情報ファイル（電源ＯＦＦファイル）を作成し一定周期、またはアプリＰＦからの停止要求時に、時刻情報を更新する。ログ取得アプリはまた、アプリＰＦからの起動要求時に、システム管理部が有するシャットダウンログファイルと、自身が有する時刻情報ファイルの時刻情報を比較し、時刻情報が新しい方の時刻を、情報処理装置の前回停止時刻としてログに記録する。このような構成により、プリンタやＰＣなどの情報処理装置にインストールされたアプリが、情報処理装置のＯＳ停止時刻を、正常にシャットダウンが行われていない場合にも取得して記録可能となり、情報処理装置が起動している時間の算出精度を向上することが可能となる。なお、シャットダウンログファイルは、オペレーティングシステム上で動作するシステム管理部が生成、管理する構成であっても、オペレーティングシステムが生成、管理する構成であってもよい。また、シャットダウンログファイルの時刻情報を基に停止時刻等のログを記録するアプリケーションは、上記システム管理部上に構築されるプラットフォーム上で動作するアプリケーションであっても、他の形態で動作するアプリケーションであってもよい。

なお、上述した各種データの構成及びその内容はこれに限定されるものではなく、用途や目的に応じて、様々な構成や内容で構成されていてもよい。
以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。
また、上記各実施例を組み合わせた構成も全て本発明に含まれるものである。

（その他の実施例）
本発明は、上述の実施例の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。
本発明は上記実施例に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施例の有機的な組合せを含む）が可能であり、それらを本発明の範囲から除外するものではない。即ち、上述した各実施例及びその変形例を組み合わせた構成も全て本発明に含まれるものである。
以上のように、本発明は、具体的に開示された実施例に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。

Claims (17)

1. アプリケーションがインストールされた情報処理装置であって、
   前記アプリケーションの機能として、
   前記情報処理装置の電源がオンされた時刻情報を示すログと、前記情報処理装置の電源がオフされた時刻情報を示すログとをログファイルに記録する第１記録手段と、
   周期的に現在時刻を用いて、前記情報処理装置の備える記憶装置内の管理ファイルで示す時刻情報を更新する更新手段と、
   前記アプリケーションが起動された場合に、前記管理ファイルで示す時刻情報と、前記アプリケーションとは異なるプログラムにおいて管理される最新のシャットダウンログで示す時刻情報とを比較する比較手段と、を有し、
   前記第１記録手段は、
   前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも前のタイミングを示す場合には、前記最新のシャットダウンログで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録し、
   前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも後のタイミングを示す場合には、前記管理ファイルで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録する、ことを特徴とする情報処理装置。
2. 前記アプリケーションの機能として、
   前記アプリケーションが停止される場合に、該アプリケーションの停止が前記情報処理装置で動作するオペレーティングシステムのシャットダウンに伴う停止ではない場合には、所定の情報を記録する第２記録手段と、
   前記アプリケーションが起動された際に前記所定の情報が記録されている場合には、該所定の情報を削除する削除手段と、を有し、
   前記第１記録手段は、前記アプリケーションが起動された際に前記所定の情報が記録されている場合、前記管理ファイルで示す時刻情報が前記最新のシャットダウンログで示す時刻情報よりも後のタイミングを示す場合には、前記情報処理装置の電源がオフされた時刻情報を示すログを前記ログファイルに記録しない、ことを特徴とする請求項１に記載の情報処理装置。
3. 前記更新手段は、前記アプリケーションが起動された際に、処理を開始することを特徴とする請求項２に記載の情報処理装置。
4. 前記更新手段は、前記アプリケーションが停止される際、現在時刻を用いて前記管理ファイルで示す時刻情報を更新することを特徴とする請求項３に記載の情報処理装置。
5. 前記第１記録手段は、前記情報処理装置で動作するオペレーティングシステムから取得した該オペレーティングシステムの起動からの経過時間を示す情報に基づく時刻を、前記情報処理装置の電源がオンされた時刻を示すログとしてログファイルに記録することを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記更新手段は、現在時刻を管理ファイルのファイル名に反映させることにより前記管理ファイルで示す時刻情報を更新することを特徴とする請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記時刻情報は、年月日時を示す情報を含むことを特徴とする請求項１〜６のいずれか１項に記載の情報処理装置。
8. 前記第１記録手段は、前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも後のタイミングを示す場合には、前記管理ファイルで示す時刻情報を、前記更新手段が前記管理ファイルで示す時刻情報を更新する周期に基づいて補正した時刻情報を用いて、前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録することを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
9. 前記第１記録手段は、前記周期に基づく補正量を表す情報を、前記情報処理装置の電源がオフされた時刻情報を示すログとともに、前記ログファイルに記録することを特徴とする請求項８に記載の情報処理装置。
10. 前記アプリケーションとは異なるプログラムは、オペレーティングシステム上で動作し、該オペレーティングシステムからの通知によりシャットダウンログを生成するシステム管理部であり、
    前記アプリケーションは、前記システム管理部上に構築されるプラットフォーム上で動作することを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
11. 前記アプリケーションとは異なるプログラムは、オペレーティングシステムであることを特徴とする請求項１〜９のいずれか１項に記載の情報処理装置。
12. 前記アプリケーションの機能として、さらに、
    前記更新手段とは異なる周期で、周期的に、前記更新手段が更新する時刻情報とは別に、現在時刻を時刻情報として記録する第３記録手段と、
    前記第３記録手段により前記時刻情報として連続して記録された２つの時刻の差が、前記第３記録手段で用いる周期を示す値よりも大きい場合に、当該時刻情報を前記記憶装置内のファイルに記録する第４記録手段と、
    を有することを特徴とする請求項１〜１１のいずれか１項に記載の情報処理装置。
13. 前記第３記録手段は、ＲＡＭに対して現在時刻を時刻情報として記録することを特徴とする請求項１２に記載の情報処理装置。
14. 前記第４記録手段は、前記第３記録手段により前記時刻情報として連続して記録された２つの時刻の差が、前記第３記録手段で用いる周期を示す値よりも大きい場合に、当該時刻情報を、前記第３記録手段で用いる周期を示す値に基づいて補正して、前記記憶装置内のファイルに記録することを特徴とする請求項１２又は１３に記載の情報処理装置。
15. 前記第４記録手段は、前記周期を示す値に基づく補正量を、前記時刻情報とともに、前記記憶装置内のファイルに記録することを特徴とする請求項１４に記載の情報処理装置。
16. アプリケーションがインストールされた情報処理装置の制御方法であって、
    前記アプリケーションの機能として実行される、
    前記情報処理装置の電源がオンされた時刻情報を示すログと、前記情報処理装置の電源がオフされた時刻情報を示すログとをログファイルに記録する記録ステップと、
    周期的に現在時刻を用いて、前記情報処理装置の備える記憶装置内の管理ファイルで示す時刻情報を更新する更新ステップと、
    前記アプリケーションが起動された場合に、前記管理ファイルで示す時刻情報と、前記アプリケーションとは異なるプログラムにおいて管理される最新のシャットダウンログで示す時刻情報とを比較する比較ステップと、を有し、
    前記記録ステップでは、
    前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも前のタイミングを示す場合には、前記最新のシャットダウンログで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録し、
    前記管理ファイルで示す時刻情報が、前記最新のシャットダウンログで示す時刻情報よりも後のタイミングを示す場合には、前記管理ファイルで示す時刻情報を用いて前記情報処理装置の電源がオフされた時刻情報を示すログを生成して前記ログファイルに記録する、ことを特徴とする制御方法。
17. コンピュータを、請求項１〜１５のいずれか１項に記載の手段として機能させるためのプログラム。

Images