JP4937194B2 - アプリケーションの応答不能時を推定するシステム、方法、およびプログラム - Google Patents

Description

本発明は、アプリケーションの応答不能時を推定するシステム、方法、およびプログラムに関する。

アプリケーション使用中にキーボードやマウスからの操作に対して、アプリケーションが応答をしなくなる状態が発生することがあり、一般に、フリーズ又はハングアップ（以下、まとめて応答不能という）といわれる。応答不能が発生した際の対応策は、特殊なキーボード操作によりアプリケーションを強制終了させるか、それも受け付けないようならリセットスイッチを押す等によりコンピュータを再起動するしかない。そのため、応答不能が発生することをユーザが事前に知り、データを保存することや応答不能自体を防ぐことは重要である。

そこで、応答不能を事前にユーザに警告するための方法として、装置のメモリ使用量やガベージコレクション処理間隔を用いて、予め人により設定された応答不能が発生すると予測される閾値を越えた場合に警告する方法がある（例えば、特許文献１、および特許文献２）。
特開２００６−２８５８７１号公報 特開２００７−２２６３９９号公報

しかしながら、上記技術によれば、予め人により設定された閾値を用いて、応答不能が発生するか否かを判断し、警告を行う。そのため、装置の性能が異なる場合やアプリケーションの起動環境が異なる場合等、つまり、閾値を設定した時と応答不能が発生する環境が変わった場合には、閾値が適切でなくなる。また、応答不能を発生する原因は様々あるが、メモリ使用量やガベージコレクション処理間隔では原因を特定することができない。そのため、閾値は様々な原因により起こる応答不能における平均値であり、適切でない場合もある。

そこで、本発明は上記課題に鑑み、応答不能が発生した際の環境毎に、応答不能が発生する閾値を統計学的に求めることにより、適切な閾値を用いて応答不能の発生時を推定することができるアプリケーションの応答不能時を推定するシステム、方法、およびコンピュータ・プログラムを目的とする。

（１） アプリケーションの応答不能時を推定するシステムであって、
前記アプリケーションの起動を検知するアプリケーション検知手段と、
前記アプリケーション検知手段にて起動が検知されたことに応じて、前記アプリケーションに対して行われたユーザからの少なくともキーストローク数を含む操作イベント数をカウントする操作イベントカウント手段と、
前記アプリケーションの応答不能状態の発生を検知する割込検知手段と、
前記割込検知手段により、前記アプリケーションの応答不能が検知されたことに応じて、割り込み処理により前記アプリケーションの起動時から起算した前記操作イベント数および前記アプリケーションの起動時からの実行環境の情報を応答不能ログ情報として前記アプリケーションと関連付けて記憶する応答不能ログ情報記録手段と、
前記応答不能ログ情報記録手段により記憶した前記アプリケーションの実行環境の情報および前記操作イベント数に基づいて、前記応答不能ログ情報を分類して、応答不能となる推定操作イベント数を推定する応答不能推定手段と、
を備えるシステム。

（１）の発明によれば、アプリケーションの起動時から起算した操作イベント数およびアプリケーションの実行環境の情報に基づいて、所定の実行環境におけるアプリケーションが応答不能となる操作イベント数を推定できることにより、実行環境毎に応答不能となる操作イベント数を推定することができる。それにより、実際に応答不能となる操作イベント数に近い推定操作イベント数を推定することができる。

なお、操作イベントとは、アプリケーションに対して行われた操作である。操作イベントは、大きく分けてキーボード操作によるイベントであるキーストロークとマウス操作によるイベントとの２つに分けられる。本発明は、アプリケーションの応答不能に強く関与するキーストロークを操作イベントに少なくとも含むものである。

（２） 前記アプリケーションを起動したことに応じて、前記アプリケーションの実行環境の情報に基づいて前記推定操作イベント数を判定し、前記操作イベント数が、前記推定操作イベント数より少ない所定の閾値に達したことに応じて、前記アプリケーションのユーザにその旨を報知する報知手段と、を更に備える（１）に記載のシステム。

（２）の発明によれば、ユーザの操作イベントを監視し、アプリケーションが応答不能となる推定操作イベント数から求められた所定の閾値に近づくと、ユーザに報知を行う。前記推定操作イベント数より少ない閾値とは、例えば、推定操作イベント数の８０％の値等である。また、報知とは、例えば、メッセージを表示したり、アラームを鳴らすことである。それにより、応答不能が発生することをユーザが事前に知り、データを保存すること等により応答不能が発生した際の影響を最小限に抑えることができる。

（３） 前記推定操作イベント数の判定する要素に、前記アプリケーションの実行環境の情報と合わせて他のアプリケーションの実行状況を用いる（２）に記載のシステム。

（３）の発明によれば、前記システムは、推定操作イベント数の判定する要素に他のアプリケーションの実行状況を合わせて用いる。その結果、前記システムは、推定操作イベント数の判定の際に、応答不能の発生に影響があると考えられる他のアプリケーションの実行状況を合わせて判定を行なうことにより、判定の精度を向上することができる。

（４） 前記応答不能推定手段は、前記推定操作イベント数をサポートベクターとするサポートベクターマシンにより前記応答不能ログ情報を分類する（１）から（３）のいずれかに記載のシステム。

（４）の発明によれば、サポートベクターマシンにより応答不能ログ情報を分類することにより、実行環境等が異なっていても同様の傾向を示す応答不能事例をクラス化することができ、推定操作イベント数はサポートベクターとして得られる。それにより、未知の事例に対して適切な推定操作イベント数を推定することができる。

サポートベクターマシンとは、高次元特徴空間において線形関数の仮説空間を用いる学習システムである。詳細には、１９９５年にＡＴ＆ＴのＶ．Ｖａｐｎｉｋによって統計的学習理論の枠組で提案された学習機械のことであり、高次元特徴空間において線形関数の仮説空間を用いる学習システムである。

（５） 更に、前記割込検知手段により、前記アプリケーションの応答不能が検知されたことに応じて、割り込み処理により前記アプリケーションの起動時から起算した前記操作イベント数を保存する操作イベント数保存手段と、
前記操作イベント数保存手段に保存された前記操作イベント数、および前記アプリケーションの起動時からの実行環境の情報を送信する操作イベント数送信手段と、
を備える（１）から（４）のいずれかに記載のシステム。

（５）の発明によれば、操作イベント数保存手段はアプリケーションの応答不能が検知されたことに応じて、割り込み処理により前記アプリケーションの起動時から起算した前記操作イベント数を保存することにより、応答不能時であっても操作イベント数を保存することができる。また、操作イベント数送信手段を備えることにより、操作イベント数等を１つに集約することができ、応答不能時の統計を取ることができる。

（６） 前記割込検知手段は、前記アプリケーションが停止した場合もしくは、前記アプリケーションの処理が遅滞している場合に応答不能となったと判定する（１）から（５）のいずれかに記載のシステム。

（６）の発明によれば、アプリケーションの処理が停滞している場合も応答不能に含めることで、実質的にアプリケーションが停止している状態についても、本発明を適用することができる。

（７） 前記実行環境の情報は、前記アプリケーションが起動している装置の性能、および同時に起動しているアプリケーションの情報を含む（１）から（６）のいずれかに記載のシステム。

（７）の発明によれば、アプリケーション情報として前記アプリケーションが起動している装置の性能、および平行して起動されている他のアプリケーションの情報と操作イベント数とに基づいて推定操作イベント数が算出される。それにより、アプリケーションの応答不能の発生に影響があると考えられる要因を推定操作イベント数の算出に反映することができる。

（８） コンピュータにより、アプリケーションの応答不能時を推定する方法であって、
前記アプリケーションの起動を検知するステップと、
前記アプリケーションに対して行われたユーザからの少なくともキーストローク数を含む操作イベント数をカウントするステップと、
前記アプリケーションの応答不能状態の発生を検知するステップと、
前記アプリケーションの応答不能が検知されたことに応じて、割り込み処理により前記アプリケーションの起動時から起算した前記操作イベント数および前記アプリケーションの起動時からの実行環境の情報を応答不能ログ情報として前記アプリケーションと関連付けて記憶するステップと、
前記アプリケーションの実行環境の情報および前記操作イベント数に基づいて、前記応答不能ログ情報を分類して、応答不能となる推定操作イベント数を推定するステップと、
を含む方法。

コンピュータに、（８）の方法を実行させることにより、（１）と同様の作用・効果が期待できる。

（９） コンピュータに、アプリケーションの応答不能時を推定させるプログラムであって、
前記アプリケーションの起動を検知するステップと、
前記アプリケーションに対して行われたユーザからの少なくともキーストローク数を含む操作イベント数をカウントするステップと、
前記アプリケーションの応答不能状態の発生を検知するステップと、
前記アプリケーションの応答不能が検知されたことに応じて、割り込み処理により前記アプリケーションの起動時から起算した前記操作イベント数および前記アプリケーションの起動時からの実行環境の情報を応答不能ログ情報として前記アプリケーションと関連付けて記憶するステップと、
前記アプリケーションの実行環境の情報および前記操作イベント数に基づいて、前記応答不能ログ情報を分類して、応答不能となる推定操作イベント数を推定するステップと、
を実行させるプログラム。

コンピュータに、（９）のプログラムを導入して各ステップを実行させることにより、（１）と同様の作用・効果が期待できる。

本発明によれば、応答不能が発生した際の環境毎に、応答不能が発生する閾値を統計学的に求めることにより、適切な閾値を用いて応答不能の発生時を推定することができるアプリケーションの応答不能時を推定するシステム、方法、およびコンピュータ・プログラムを提供することができる。

以下、本発明を実施するための最良の形態について図を参照しながら説明する。なお、これはあくまでも一例であって、本発明の技術的範囲はこれに限られるものではない。

［応答不能時推定システムの全体構成］
図１は、本実施形態に係る応答不能時推定システム１の全体構成を示す図である。応答不能時推定システム１における、クライアント端末２００とサーバ装置１００とは、インターネットやイントラネット等に代表されるネットワークの通信回線を介して接続される。なお、本構成におけるクライアント端末２００およびサーバ装置１００は必ずしも１台とは限らず、複数台で構成されてもよい。また、応答不能時推定システム１を装置として提供してもよいが、応答不能時が発生する閾値を求めるには、多くの事象を用いたほうがよいので、複数のクライアント端末２００が接続されたシステムとするのが望ましい。

［応答不能時推定システムのクライアント端末の機能構成］
図１に示すように、クライアント端末２００は、通信手段２０６および制御手段２１０を備える。制御手段２１０は、アプリケーション検知手段２０１、操作イベントカウント手段２０２、割込検知手段２０３、操作イベント数保存手段２０４、操作イベント数送信手段２０５、アプリケーション監視手段２０７、報知手段２０８を有する。

アプリケーション検知手段２０１は、クライアント端末２００においてアプリケーションが起動されたことを検知する。操作イベントカウント手段２０２は、アプリケーション毎に、ユーザがキーボードやマウスにて行った操作イベント数をカウントする。ただし、操作イベントは少なくともキーストロークを含む。その理由については後述する。

割込検知手段２０３は、アプリケーションの応答不能の発生を検知し、操作イベント数保存手段２０４に応答不能となったアプリケーションの操作イベント数を記憶するように指示を行う。

操作イベント数保存手段２０４は、割込検知手段２０３からの指示により、操作イベントカウント手段２０２から、その時点での操作イベント数を取得し、一時記憶する割込みルーチンを実行する。また、操作イベント数保存手段２０４は、操作イベント数を一時記憶すると、操作イベントカウント手段２０２のカウントをクリアする。なお、応答不能が発生すると、ＣＰＵにて実行されている処理は中断され、操作イベント数保存手段２０４が実行する割込みルーチンが優先して処理を行う。

操作イベント数送信手段２０５は、操作イベント数保存手段２０４にて一時記憶された操作イベント数、応答不能となったアプリケーション情報、およびそのアプリケーションの実行環境の情報を取得し、サーバ装置１００へ送信する情報の準備を行い、通信手段２０６へ渡す。アプリケーションの実行環境の情報とは、クライアント端末２００のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）や仮想メモリのスペック等のクライアント端末２００の性能や応答不能となった日時、平行して起動されているアプリケーションの情報等である。

アプリケーション監視手段２０７は、アプリケーション検知手段２０１にてアプリケーションが起動されたことが検知されると、そのアプリケーションが応答不能となると推定される推定操作イベント数をサーバ装置１００から取得し、推定操作イベント数から求められた閾値を操作イベントカウント手段２０２から取得する操作イベント数が越えているか否か監視する。また、アプリケーション監視手段２０７は、操作イベント数が操作イベント閾値を越えた場合に、報知手段２０８に指示を出す。ここで、閾値とは、推定操作イベント数に基づいてシステム管理者等にて任意に設定された値であり、例えば、推定操作イベント数の８０％の値を閾値とすることができる。なお、操作イベント数は、操作イベントカウント手段２０２から逐次取得する。

報知手段２０８は、アプリケーション監視手段２０７から指示を受けると、ユーザに対して出力部（図示せず）にて警告を行う。制御手段２１０は、アプリケーションが終了した時や、報知手段２０８にて行われた警告に従った操作をユーザが行った際に、操作イベントカウント手段２０２のカウントをクリアする。

［応答不能時推定システムのサーバ装置の機能構成］
図１に示すように、サーバ装置１００は、通信手段１０１、応答不能ログ情報記録手段１０２、応答不能推定手段１１０、推定応答不能情報取得手段１２０、応答不能ログ情報データベース（以下、簡略化のためＤＢとする）１３０、および応答不能推定ＤＢ１３１を備える。応答不能ログ情報記録手段１０２は、通信手段２０６，１０１を介してクライアント端末２００から、応答不能となったアプリケーション情報、そのアプリケーションにおける応答不能時の操作イベント数、およびそのアプリケーションの実行環境の情報を取得し、応答不能ログ情報ＤＢ１３０に記憶する。

応答不能推定手段１１０は、応答不能ログ情報のクラス分類を行うことにより、推定操作イベント数を求めることができる。ここで、応答不能推定手段１１０は、クラス分類を行う学習機械であり、例えば、サポートベクターマシン（ＳＶＭ：Ｓｕｐｐｏｒｔ Ｖｅｃｔｏｒ Ｍａｃｈｉｎｅ）やナイーブベイズがある。本実施形態においては、応答不能推定手段１１０は、サポートベクターマシンである場合について説明する。

本実施形態の一例では、サポートベクターマシンという信頼性のある手段を用いる。ここで、サポートベクターマシンの学習結果は、応答不能ログ情報ＤＢ１３０に記憶されている応答不能ログ情報をクラスに分類する識別面およびサポートベクターを含み、応答不能推定ＤＢ１３１に記憶される。複数のクラスに分類する場合には、複数のサポートベクターマシンを組み合わせる。

推定応答不能情報取得手段１２０は、クライアント端末２００から取得した新たに起動されたアプリケーション情報およびそのアプリケーションの実行環境の情報に基づいて、応答不能推定ＤＢ１３１から推定操作イベント数を取得し、クライアント端末２００へ送信する。

応答不能ログ情報ＤＢ１３０は、応答不能ログ情報、つまり、クライアント端末２００にて応答不能が発生した時のアプリケーションの操作イベント数および実行環境の情報を蓄積する。詳細については後述する。応答不能推定ＤＢ１３１は、応答不能推定手段１１０における学習結果、および応答不能推定手段１１０にて応答不能ログ情報が分類されるクラス毎に推定操作イベント数が蓄積されている。

なお、クライアント端末２００およびサーバ装置１００のハードウェア構成については、後述する。

［応答不能推定手段］
図２は、応答不能推定手段１１０の詳細を示す図である。応答不能推定手段１１０は、クラス生成手段１１１、および推定操作イベント数決定手段１１２を有する。クラス生成手段１１１は、応答不能ログ情報ＤＢ１３０に蓄積されている応答不能ログ情報の特徴解析を行い、応答不能ログ情報のクラス分類を行う。推定操作イベント数決定手段１１２は、クラス生成手段１１１にて作成されたクラス毎に、応答不能が発生する推定操作イベント数を算出する。

ところで、応答不能時の推定を操作イベント数で行うのは、応答不能の原因であるメモリリークの発生を操作イベント数に基づいて予測することができるからである。メモリリークとは、アプリケーションソフトが処理のために占有したメモリ領域を、なんらかの理由で解放しないままの状態であり、操作イベント数が多いほど、開放されないメモリ領域が増える可能性がある。しかし、メモリリークは、メモリ使用量の監視によって発生を検知するのは難しい。なぜならば、プログラムが将来に使うためにメモリの確保をしているものと、そのような将来の使用の予定がないにもかかわらず占有し続けているものと、を区別することができず、単にメモリ使用量が多いからといって、メモリリークが発生しているとは必ずしも言えないからである。そこで、メモリ監視よりも有効な手段として、本発明においては操作イベント数に基づいて応答不能時を推定する。

なお、操作イベントは上述したように、キーボード操作によるイベントであるキーストロークの他に、マウス操作によるイベント等も含まれる。本発明においては、アプリケーションの応答不能に強く関与するイベントとしてキーストロークに注目している。というのも、マウスによるイベントはボタンの押下、ＵＲＬのクリック等多岐にわたるため、メモリ領域の確保、開放との関係が必ずしも明確ではないのに対し、キーストロークはキャラクタ文字の入力、かな漢字変換等、メモリ領域の確保、開放との関係が安定的であり、アプリケーションの応答不能を推定するのに好適であるためである。

［推定応答不能情報取得手段］
図３は、推定応答不能情報取得手段１２０の詳細を示す図である。推定応答不能情報取得手段１２０は、クラス決定手段１２１、および推定操作イベント数抽出手段１２２を有する。クラス決定手段１２１は、推定操作イベント取得要求のあったクライアント端末２００のアプリケーション情報（少なくともアプリケーションＩＤを含む）およびそのアプリケーションの実行環境の情報２に基づいて、それらが属するクラスを決定する。推定操作イベント数抽出手段１２２は、クラス決定手段１２１にて決定されたクラスに基づいて、推定操作イベント数を応答不能推定ＤＢ１３１から取得する。

［応答不能ログ情報ＤＢ］
図４は、応答不能ログ情報ＤＢ１３０の応答不能ログ情報テーブルを示す図である。応答不能ログ情報テーブルは、アプケーションＩＤ（以下、簡略化のためにアプリＩＤという）、アプリケーション名（以下、簡略化のためにアプリ名という）、応答不能時の操作イベント数、応答不能日時に加えて、ＣＰＵ、メモリ容量、および仮想ディスク要領等のアプリケーションの実行環境の情報２を含む項目から構成される。なお、ここに示した項目は例示であり、全てを含まなくとも、また、その他の項目を有してもよい。ただし、応答不能が発生する要因と関係すると考えられる情報であるのが望ましい。

アプリＩＤには、アプリケーションを一意に特定する記号が格納される。なお、アプリＩＤは、サーバ管理者等が任意に決定してもよいし、一般に用いられているアプリＩＤを用いてもよい。アプリ名には、応答不能が発生したアプリケーションの名前が格納される。ただし、クライアント端末２００から取得する情報にアプリ名が含まれていない場合には、アプリＩＤからアプリ名に変換することが必要である。そのため、アプリＩＤとアプリ名の対応を蓄積しているＤＢが必要である。

応答不能時の操作イベント数には、応答不能が発生したアプリケーションにおいて、応答不能までに実行された操作イベント数が格納される。応答不能日時は、応答不能が発生した日時が格納され、この日時は、日本標準時間や世界標準時間である。ＣＰＵ、メモリ容量、仮想ディスク容量は、応答不能が発生したクライアント端末２００に搭載されているＣＰＵ、メモリ、仮想ディスクについての情報が格納される。なお、容量以外に、ＣＰＵ名やメーカー名等を有してもよい。応答不能が発生したときの状況等を記憶しておくことで、統計的に応答不能が発生する時を推定することができる。

［応答不能推定ＤＢ］
図５は、応答不能推定ＤＢ１３１の応答不能推定テーブルを示す図である。応答不能推定テーブルは、クラスＩＤおよび推定操作イベント数等の項目から構成される。なお、ここに示した項目は例示であり、全てを含まなくとも、また、その他の項目を有してもよい。クラスＩＤは、応答不能推定手段１１０にて、応答不能ログ情報を分類するクラスを一意に特定する記号である。推定操作イベント数は、応答不能推定手段１１０にて求められた応答不能が発生すると推定される操作イベント数である。応答不能が起こるすると推定される操作イベント数を記憶しておくことで、新たなアプリケーションが起動された際に、そのアプリケーションに対して応答不能が起こると推定される操作イベント数を容易に提示することができる。

［応答不能ログ情報のクラス分類］
図６は、応答不能推定手段１１０によるＳＶＭのアルゴリズムを用いた機械学習の一例を示す図である。応答不能推定手段１１０は、応答不能ログ情報ＤＢ１３０に記憶された応答不能ログ情報を学習データとして用い、ＳＶＭのアルゴリズムを用いてこれらの学習データから２つのクラスに分類する識別面から最も近い学習データと当該識別面との距離が最大となるような識別面を設定する。そして、当該識別面に最も近い学習データをサポートベクターとして用い、それぞれのクラスにおける推定操作イベント数とする。

例えば、クラス１とクラス２とに分類する場合について説明する。その場合、以下に示す様に、それぞれクラス１およびクラス２に分類された応答不能ログ情報を学習データとしていくつか使用する。
クラス１：アプリケーション：○○ワード、ＣＰＵ：１．５ＧＨｚ、仮想ディスク容量：３ＧＢ、・・・・
クラス２：アプリケーション：○○シート、ＣＰＵ：１．５ＧＨｚ、仮想ディスク容量：３ＧＢ、・・・・

そして、応答不能推定手段１１０は、クラス１の学習データとクラス２の学習データを識別する識別面３０同士の距離（マージン）が最大になるような識別面３０を算出する。識別面３０にもっとも近接するクラス１の学習データ１１とクラス２の学習データ２１をサポートベクターとして用いる。このように、応答不能推定手段１１０は、クラス１の応答不能ログ情報とクラス２の応答不能ログ情報とを学習データとして使用し、クラス１の応答不能ログ情報群１０とクラス２の応答不能ログ情報群２０とを区別するための識別データである識別面を生成するようになっている。そして、学習データ１１はクラス１の推定操作イベント数を与え、学習データ２１はクラス２の推定操作イベント数を与える。このように、サポートベクターマシンを用いることにより、応答不能ログ情報を分類し、また、分類されたクラスの推定操作イベント数を求めることができる。なお、上述したように２以上のクラスの分類についても、複数のサポートベクターマシンを用いて行うことができる。

［応答不能時推定処理］
図７は、応答不能時推定処理のフローチャートである。アプリケーション検知手段２０１が、クライアント端末２００にて、新たなアプリケーションが起動されたことを検知すると処理が開始する。

Ｓ１：アプリケーション検知手段２０１は、アプリケーションが起動したことを検知すると、起動されたアプリケーションを特定するための少なくともアプリＩＤを取得し、操作イベント数のカウント要求を操作イベントカウント手段２０２に行う。

Ｓ２：カウント要求を受け取った操作イベントカウント手段２０２は、アプリケーションにおける操作イベント数をカウントする。なお、複数のアプリケーションが起動されている場合には、アプリケーションそれぞれに対する操作イベント数をカウントする。応答不能はアプリケーション毎に発生し、原因はそのアプリケーションに対して行われた操作イベントによるからである。

Ｓ３：割込検知手段２０３は、アプリケーションに応答不能が発生しているか否かの判断を行い、応答不能が発生したことを検知すると、操作イベント数保存手段２０４に応答不能発生時の操作イベント数の保存要求を行う。

Ｓ４：一方、割込検知手段２０３にて、応答不能が検知されずにアプリケーションがユーザにて終了された場合には、制御手段２１０は、操作イベントカウント手段２０２の操作イベントカウントをリセットする。なお、このときリセットされるのは、終了されたアプリケーションの操作イベント数だけである。操作イベント数は、アプリケーション毎にカウントされているためである。

Ｓ５：ステップＳ４にて、アプリケーションに応答不能が発生し、操作イベント数記憶要求がなされると、操作イベント数保存手段２０４は、割り込みルーチンを実行し、操作イベントカウント手段２０２から取得した応答不能時の操作イベント数をメモリ等に一時記憶する。

Ｓ６：操作イベント数送信手段２０５は、ステップＳ１にて取得されたアプリＩＤ等、ステップＳ５にて一時記憶されている応答不能時の操作イベント数、クライアント端末２００の性能等を取得し、通信手段２０６を介してサーバ装置１００へ送信する。応答不能を解消するために、クライアント端末２００の再起動を行う場合がある。この場合、ステップＳ６にて情報がサーバ装置１００へ送信される前にクライアント端末２００の再起動が行われてしまうと、サーバ装置１００が取得できる情報が少なくなってしまうという問題点が生じる。そのため、ユーザにてクライアント端末２００の再起動が入力された際には、ステップＳ６まで終了した後にクライアント端末２００の再起動がコンピュータにて実行されるようにしておくのが望ましい。

Ｓ７：応答不能ログ情報記録手段１０２は、ステップＳ６にて送信されたアプリＩＤ等、ステップＳ５にて一時記憶されている応答不能時の操作イベント数、クライアント端末２００の性能を通信手段１０１を介して取得し、応答不能ログ情報ＤＢ１３０に記録する。このようにして、サーバ装置１００は、ネットワークを介して接続されているクライアント端末２００にて発生した応答不能の情報を集めることができる。

Ｓ８：応答不能推定手段１１０のクラス生成手段１１１は、上述したＳＶＭのアルゴリズムを用いて、応答不能ログ情報ＤＢ１３０に蓄積されている応答不能ログ情報を学習データとして用いて識別面およびサポートベクターを求める。なお、ステップＳ８が実行されるタイミングは任意でよく、例えば、所定の期間毎に実行するとしてもよいし、サーバ装置管理者によって任意に実行するとしてもよい。ただし、推定操作イベント数は統計学的に求められるため、１つや２つの情報が増えたところで変化は生じない。そのため、ある程度情報が蓄積されたタイミングで実行するのが望ましい。なお、ステップＳ８は、自動的に実行されてもよいし、サーバ装置１００の管理者等により手動で実行してもよい。

Ｓ９：応答不能推定手段１１０の推定操作イベント数決定手段１１２は、ステップＳ８において求めた各クラスのサポートベクターにより、推定操作イベント数を求める。

Ｓ１０：応答不能推定手段１１０は、ステップＳ９にて求めた推定操作イベント数を、応答不能推定ＤＢ１３１に記憶する。このとき推定操作イベント数は、クラスＩＤに対応付けて記憶される。

［応答不能報知処理］
図８は、応答不能報知処理のフローチャートである。アプリケーション検知手段２０１が、クライアント端末２００にて、新たなアプリケーションが起動されたことを検知すると、このアプリケーションにおける応答不能時を報知する処理が開始する。

Ｓ１１：推定応答不能情報取得手段１２０は、通信手段２０６，１０１を介してクライアント端末２００から少なくともアプリＩＤとクライアント端末２００の性能を取得する。なお、アプリＩＤ等はアプリケーション検知手段２０１にて取得され、クライアント端末２００の性能はアプリケーション監視手段２０７にて取得される。

Ｓ１２：推定応答不能情報取得手段１２０のクラス決定手段１２１は、ステップＳ１１にて取得した情報に基づいて、図７におけるステップＳ８にて作成された識別面から、新たに起動されたアプリケーションが応答不能となった場合の応答不能ログ情報が属するクラスを求め、クラスＩＤを特定する。クラスＩＤを特定するのは、応答不能推定ＤＢ１３１を検索するためである。なお、推定応答不能情報取得手段１２０は、ステップＳ１１にて、クライアント端末２００において起動している他のアプリケーションの実行状況も取得し、それも用いてクラスを決定してもよい。

Ｓ１３：推定応答不能情報取得手段１２０の推定操作イベント数抽出手段１２２は、ステップＳ１２にて特定されたクラスＩＤに基づいて、応答不能推定ＤＢ１３１を検索し、推定操作イベント数を取得する。
Ｓ１４：推定応答不能情報取得手段１２０は、ステップＳ１３にて取得された推定操作イベント数をクライアント端末２００のアプリケーション監視手段２０７に送信する。

Ｓ１５：アプリケーション監視手段２０７は、アプリケーションにおける操作イベント数が閾値に達したか否かの監視を行う。アプリケーションにおける操作イベント数は、操作イベントカウント手段２０２から取得する。閾値は、上述したように、推定操作イベント数に基づいてシステム管理者等にて任意に設定された値であり、推定操作イベント数よりも小さい値である。推定操作イベント数ではなく閾値に達したか否かの監視を行うのは、推定操作イベントに達してしまうと応答不能が発生してしまう恐れがあるからである。

Ｓ１６：報知手段２０８は、操作イベント数が閾値に達した場合に、ユーザに対して警告を行う。例えば、文書作成アプリケーションにおける警告であれば、「保存をしてください。」とメッセージを表示したりアナウンスを行う。また、メッセージと合わせて、保存ボタンを表示してもよい。なお、必ずしも、警告を行う必要はなく、警告を行わずに、自動でコンピュータが保存を行ってもよい。

［ハードウェア構成図］
図９は、本実施形態に係る応答不能時推定システムを構成するクライアント端末２００およびサーバ装置１００のハードウェア構成例として情報処理装置５００を示した図である。以下、この情報処理装置５００のハードウェア構成の１例を示す。情報処理装置５００は、制御部３００を構成するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３１０（マルチプロセッサ構成ではＣＰＵ３２０等複数のＣＰＵが追加されてもよい）、バスライン４２０、通信Ｉ／Ｆ（Ｉ／Ｆ：インタフェース）３３０、メインメモリ３４０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）３５０、Ｉ／Ｏコントローラ３６０、ハードディスク３７０、光ディスクドライブ３８０、並びに半導体メモリ３９０を備える。尚、ハードディスク３７０、光ディスクドライブ３８０、並びに、半導体メモリ３９０はまとめて記憶装置４１０と呼ばれる。

制御部３００は、情報処理装置５００を統括的に制御する部分であり、ハードディスク３７０（後述）に記憶された各種プログラムを適宜読み出して実行することにより、上述したハードウェアと協働し、本発明に係る各種機能を実現している。

通信Ｉ／Ｆ３３０は、インターネットを介して情報処理装置５００が情報を送受信する場合のネットワーク・アダプタである。通信Ｉ／Ｆ３３０は、モデム、ケーブル・モデムおよびイーサネット（登録商標）・アダプタを含んでよい。

ＢＩＯＳ３５０は、情報処理装置５００の起動時にＣＰＵ３１０が実行するブートプログラムや、素性語選別装置１がハードウェアに依存するプログラム等を記録する。

Ｉ／Ｏコントローラ３６０には、ハードディスク３７０、光ディスクドライブ３８０、および半導体メモリ３９０等の記憶装置４１０を接続することができる。

ハードディスク３７０は、本ハードウェアを情報処理装置５００として機能させるための各種プログラム、本発明の機能を実行するプログラムおよび後述するテーブルおよびレコードを記憶する。なお、情報処理装置５００は、外部に別途設けたハードディスク（図示せず）を外部記憶装置として利用することもできる。

光ディスクドライブ３８０としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この場合は各ドライブに対応した光ディスク４００を使用する。光ディスク４００から光ディスクドライブ３８０によりプログラム又はデータを読み取り、Ｉ／Ｏコントローラ３６０を介してメインメモリ３４０又はハードディスク３７０に提供することもできる。

なお、本発明でいうコンピュータとは、記憶装置、制御部等を備えた情報処理装置をいい、情報処理装置５００は、記憶装置４１０、制御部３００等を備えた情報処理装置により構成され、この情報処理装置は、本発明のコンピュータの概念に含まれる。

本実施形態に係る応答不能時推定システムの全体構成を示す図である。 応答不能推定手段の詳細を示す図である。 推定応答不能情報取得手段の詳細を示す図である。 応答不能ログ情報ＤＢの応答不能ログ情報テーブルを示す図である。 応答不能推定ＤＢの応答不能推定テーブルを示す図である。 応答不能推定手段によるＳＶＭのアルゴリズムを用いた機械学習の一例を示す図である。 応答不能時推定処理のフローチャートである。 応答不能報知処理のフローチャートである。 本実施形態に係る応答不能時推定システムを構成するクライアント端末およびサーバ装置のハードウェア構成例として情報処理装置を示した図である。

符号の説明

１ 応答不能時推定システム
１００ サーバ装置
１０１ 通信手段
１０２ 応答不能ログ情報記録手段
１１０ 応答不能推定手段
１２０ 推定応答不能情報取得手段
１３０ 応答不能ログ情報ＤＢ
１３１ 応答不能推定ＤＢ
２００ クライアント端末
２０１ アプリケーション検知手段
２０２ 操作イベントカウント手段
２０３ 割込検知手段
２０４ 操作イベント数保存手段
２０５ 操作イベント数送信手段
２０６ 通信手段
２０７ アプリケーション監視手段
２０８ 報知手段
２１０ 制御手段

Claims (9)

1. クライアント端末とサーバ装置とを含んで構成され、前記クライアント端末におけるメモリリークの発生を原因とするアプリケーションの応答不能時を推定するシステムであって、
   前記アプリケーションの起動を検知するアプリケーション検知手段と、
   前記アプリケーション検知手段にて起動が検知されたことに応じて、前記アプリケーションに対して行われたユーザのキーストローク数をカウントする操作イベントカウント手段と、
   前記アプリケーションの応答不能状態の発生を検知する割込検知手段と、
   前記割込検知手段により、前記アプリケーションの応答不能が検知されたことに応じて、応答不能となったアプリケーション情報、当該アプリケーションに対する前記キーストローク数および前記アプリケーションの実行環境の情報を応答不能ログ情報として記憶する応答不能ログ情報記録手段と、
   前記応答不能ログ情報記録手段により記憶した前記応答不能ログ情報に基づいて、アプリケーションが所定の実行環境で起動した場合にメモリリークの発生を原因とする応答不能を推定する推定キーストローク数を算出する応答不能推定手段と、
   を備え、
   前記応答不能推定手段は、
   前記応答不能ログ情報記録手段により記憶した前記応答不能ログ情報を、前記アプリケーションおよび前記アプリケーションの実行環境に基づいてクラス毎に分類する分類手段と、
   前記分類手段が分類したクラス毎に、当該クラスに含まれる前記応答不能ログ情報の前記キーストローク数に基づいて前記推定キーストローク数を算出する推定手段と、
   を備えるシステム。
2. 複数のクライアント端末とサーバ装置とを含んで構成され、前記クライアント端末におけるメモリリークの発生を原因とするアプリケーションの応答不能時を推定するシステムであって、
   前記クライアント端末は、
   前記アプリケーションの起動を検知するアプリケーション検知手段と、
   前記アプリケーション検知手段にて起動が検知されたことに応じて、前記アプリケーションに対して行われたユーザのキーストローク数をカウントする操作イベントカウント手段と、
   前記アプリケーションの応答不能状態の発生を検知する割込検知手段と、
   前記割込検知手段によりアプリケーションの応答不能状態の発生が検知されることを条件に、応答不能となったアプリケーション情報、当該アプリケーションに対する前記キーストローク数および前記アプリケーションの実行環境の情報を前記サーバ装置に送信する操作イベント数送信手段と、
   を備え、
   前記サーバ装置は、
   前記クライアント端末の夫々から受信した前記アプリケーション情報、前記キーストローク数および前記アプリケーションの実行環境を応答不能ログ情報として記憶する応答不能ログ情報記録手段と、
   前記応答不能ログ情報記録手段により記憶した前記応答不能ログ情報に基づいて、アプリケーションが所定の実行環境で起動した場合にメモリリークの発生を原因とする応答不能を推定する推定キーストローク数を算出する応答不能推定手段と、
   を備え、
   前記サーバ装置の前記応答不能推定手段は、
   前記応答不能ログ情報記録手段により記憶した前記応答不能ログ情報を、前記アプリケーションおよび前記アプリケーションの実行環境に基づいてクラス毎に分類する分類手段と、
   前記分類手段が分類したクラス毎に、当該クラスに含まれる前記応答不能ログ情報の前記キーストローク数に基づいて前記推定キーストローク数を算出する推定手段と、
   を備えるシステム。
3. 前記クライアント端末は、
   前記割込検知手段によりアプリケーションの応答不能状態の発生が検知されることを条件に、当該アプリケーションに対する前記キーストローク数を一時記憶する操作イベント数保存手段と、
   前記キーストローク数を前記サーバ装置に送信する前に前記クライアント端末が再起動した場合には、再起動後に前記操作イベント数保存手段に一時記憶されている前記キーストローク数を前記サーバ装置に送信する操作イベント数送信手段と、を備える
   請求項１または２に記載のシステム。
4. 前記クライアント端末は、
   前記アプリケーションを起動したことに応じて、起動したアプリケーションおよび前記アプリケーションの実行環境の情報に応じたクラスの前記推定キーストローク数を取得する推定応答不能情報取得手段と、
   前記キーストローク数が、前記推定キーストローク数より少ない所定の閾値に達したことに応じて、前記アプリケーションのユーザにその旨を報知する報知手段と、
   を更に備える請求項１から３のいずれかに記載のシステム。
5. 前記応答不能推定手段は、前記推定キーストローク数をサポートベクターとするサポートベクターマシンにより前記応答不能ログ情報を分類する請求項１から請求項４のいずれかに記載のシステム。
6. 前記割込検知手段は、前記アプリケーションが停止した場合に応答不能となったと判定する請求項１から請求項５のいずれかに記載のシステム。
7. 前記実行環境の情報は、前記アプリケーションが起動しているクライアント端末の性能、および同時に起動しているアプリケーションの情報を含む請求項１から請求項６のいずれかに記載のシステム。
8. 夫々が記憶部及び制御部を備えるクライアント端末とサーバ装置とを含んで構成されるシステムが、クライアント端末におけるメモリリークの発生を原因とするアプリケーションの応答不能時を推定する方法であって、
   アプリケーション検知手段が、前記アプリケーションの起動を検知するステップと、
   操作イベントカウント手段が、前記アプリケーションに対して行われたユーザのキーストローク数をカウントするステップと、
   割込検知手段が、前記アプリケーションの応答不能状態の発生を検知するステップと、
   応答不能ログ情報記録手段が、前記アプリケーションの応答不能が検知されたことに応じて、応答不能となったアプリケーション情報、当該アプリケーションに対する前記キーストローク数および前記アプリケーションの実行環境の情報を応答不能ログ情報として関連付けて前記サーバ装置の記憶部に記憶するステップと、
   応答不能推定手段が、記憶した前記応答不能ログ情報に基づいて、アプリケーションが所定の実行環境で起動した場合にメモリリークの発生を原因とする応答不能を推定する推定キーストローク数を算出するステップと、
   を含み、
   前記算出するステップは、
   分類手段が、記憶した前記応答不能ログ情報を、前記アプリケーションおよび前記アプリケーションの実行環境に基づいてクラス毎に分類するステップと、
   推定手段が、分類したクラス毎に、当該クラスに含まれる前記応答不能ログ情報の前記キーストローク数に基づいて前記推定キーストローク数を算出するステップと、
   を含む方法。
9. クライアント端末とサーバ装置とを含んで構成されるシステムに、メモリリークの発生を原因とするアプリケーションの応答不能時を推定させるプログラムであって、
   アプリケーション検知手段が、前記アプリケーションの起動を検知するステップ、
   操作イベントカウント手段が、前記アプリケーションに対して行われたユーザのキーストローク数をカウントするステップ、
   割込検知手段が、前記アプリケーションの応答不能状態の発生を検知するステップ、
   応答不能ログ情報記録手段が、前記アプリケーションの応答不能が検知されたことに応じて、応答不能となったアプリケーション情報、当該アプリケーションに対する前記キーストローク数および前記アプリケーションの実行環境の情報を応答不能ログ情報として関連付けて前記サーバ装置の記憶部に記憶するステップ、
   応答不能推定手段が、記憶した前記応答不能ログ情報に基づいて、アプリケーションが所定の実行環境で起動した場合にメモリリークの発生を原因とする応答不能を推定する推定キーストローク数を算出するステップ、
   を実行させ、
   前記算出するステップにおいて、
   分類手段が、記憶した前記応答不能ログ情報を、前記アプリケーションおよび前記アプリケーションの実行環境に基づいてクラス毎に分類するステップ、
   推定手段が、分類したクラス毎に、当該クラスに含まれる前記応答不能ログ情報の前記キーストローク数に基づいて前記推定キーストローク数を算出するステップ、
   を実行させるプログラム。

Images