JP5865486B2 - 利用者体感品質推定装置、端末ボトルネック判定装置、類似操作抽出装置、及び方法、並びにプログラム - Google Patents

Description

第１の側面に係る本発明は、利用者体感品質推定装置及び方法に係り、特に、サービス利用者が体感したアプリケーションの品質を利用者の体感待ち時間に基づき推定する利用者体感品質推定装置及び方法に関する。

また、第２の側面に係る本発明は、端末ボトルネック判定装置及び方法に係り、特に、アプリケーション利用時の品質劣化要因を判定するための端末ボトルネック判定装置及び方法及びプログラムに関する。

更に、第３の側面に係る本発明は、アプリケーション実行時の品質劣化判定技術における、類似操作抽出装置及び方法に係り、特に、アプリケーション実行時に、入力として与えられたユーザによる操作と類似した操作を抽出するための類似操作抽出装置及び方法及びプログラムに関する。

第１の側面に関し、アプリケーションに係る利用者の体感待ち時間を取得する方法として、以下の方法が存在する。ここで、利用者の体感待ち時間とは、利用者による画面のクリック操作の後、実行結果が画面表示されるまでの間の時間を意味する。

（Ａ）端末とサーバの間でやりとりされるHTTPメッセージのレスポンスタイム等の、利用者体感待ち時間と近い指標を取得して提示する方法（例えば、非特許文献１参照）。

（Ｂ）端末とサーバ間でパケットが連続的に送受信されている期間から、利用者の体感待ち時間を推定する手法（例えば、特許文献１参照）。

第２の側面に関し、アプリケーションに係るサービス利用時に、利用者における体感待ち時間の長時間化に代表される品質劣化が生じた場合の品質劣化要因が端末にあるか否かという端末ボトルネックを判定するための従来手法として、以下の手法がある。ここでの「体感待ち時間」も前記のとおり、利用者による画面クリック操作のあと、実行結果が画面表示されるまでの間の時間を意味する。

（Ａ）端末のCPU負荷率等のリソースを把握して、ボトルネックとなっているか否かを判定する手法：
例えば、Windows（登録商標） OSに付属する「パフォーマンスモニタ」等のツールを用いて、CPU利用率や空きメモリ量が事前に規定した閾値を超えていないか確認を行う手法がある（例えば、特許文献２参照）。

（Ｂ）端末スペックを確認する手法：
CPU種別、搭載メモリ量等の端末スペック情報に基づいて、当該サービスに適合しているか否かを判定する手法がある（例えば、非特許文献２,３参照）。

（Ｃ）ベンチマークによる事前確認手法：
当該サービスと近い動作を行うベンチマークソフトウェアを動作させ、そのスコアに基づいて当該サービスに適合しているか否かを判定する手法がある（例えば、非特許文献４参照）。

次に、第３の側面に関する背景技術を説明する。

近年、Webアプリケーション等、ネットワークを介して利用するアプリケーションが普及している。当該アプリケーションは、ユーザ端末にアプリケーションをインストールすることなく、Webブラウザや専用のクライアントソフト等を介して、サーバにアクセスすることで、サーバ側で管理されるソフトウェアやデータを利用できるのが特徴である。

しかしながら、サーバやネットワークの遅延によってユーザの体感品質が左右されやすく、一定の体感品質を保証することが難しいという問題が存在する。そこで、ユーザの体感品質を常時監視し、品質劣化があった場合に、適切に対処することが必要である。例えば、クライアント・サーバ間のレスポンスタイムを常時監視し、通常時に比べてレスポンスタイムが長くなった場合、品質劣化として判別する手法がある（例えば、非特許文献５参照）。

また、最近では、動的コンテンツを含むアプリケーションも増えてきている。こういったアプリケーションでは、ユーザ端末での処理量が多くなるため、サーバやネットワークに加え、ユーザ端末の処理性能もユーザ体感品質を左右する大きな要因になっている。そのため、非特許文献６では、ユーザ端末要因を加味した品質監視、すなわち、体感待ち時間を監視する必要性が述べられている。

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

CA Application Performance Management.http://www.ca.com/jp/products/detail/CA-Application-Performance-Management/overview.aspx 金融庁 EDINET書類閲覧用端末要求条件 http://www.fsa.go.jp/singi/edinet/20070427/09.pdf Windows7 端末要求条件 http://windows.microsoft.com/ja-JP/windows7/products/system-requirements ゲームソフトウェア ファイナルファンタジー ベンチマーク http://www.finalfantasyxiv.com/media/benchmark/jp/ Fluke APA http://www.toyo.co.jp/flukenetworks/apa.html 山本浩司, 中村天真, 本多泰理, 池上大介, 高橋玲, "ブラウザベースアプリケーションの品質要因考察", 信学技報, 2012-7. CA APM http://systemwalker.fujitsu.com/jp/caapm/

（第１の側面に関する課題）
第１の側面に関する従来の技術には以下のような課題が存在する。

（１）端末処理時間の影響を考慮できない：
図１は、利用者の操作が行われた際の動作を単純化したものである。この例においては、利用者の操作開始から画面表示が完了する時刻までの時間（t4−t0）は、「端末からのリクエストの発出」⇒「サーバからの応答」⇒「端末での画面生成処理」で構成されている。従来技術においては、リクエスト発出からレスポンス受信までの時間（t3−t0）を検出するものであるため、端末処理時間（t4-t3）が誤差となって生じる。

また、動的コンテンツにおいては端末処理時間が長くなる傾向があり、従来技術の誤差は大きくなる。

（２）通信を伴わない処理への対応：
従来の技術において、図２に示すように、利用者の操作時にサーバに対してリクエストが発出されたが動的コンテンツを構成要素に含むアプリケーションでは、処理がブラウザや専用のクライアントソフト内に閉じて、サーバへのリクエストが発生しないことも多く、従来技術では利用者の操作が行われたことを検知できない。

（３）利用者体感と相関する信号ペアの抽出：
動的コンテンツを構成要素に含むアプリケーションにおいては、図３に示すように、利用者操作が起因の信号とブラウザや専用のクライアントソフト等の利用者操作以外が起因となった信号が混在する。利用者操作が起因となった信号を特定するためには、各アプリケーションの操作に応じた信号パターンを確認する必要がある。アプリケーションの数、並びに、各アプリケーション内操作の数は膨大であり、操作毎の信号パターンを確認することは極めて困難である。

上記のように、従来技術では、端末側の処理時間の影響を考慮できないこと、ブラウザや専用のクライアントソフト内に閉じてサーバとの通信を伴わない利用者操作を外部から検知できないこと、また、利用者体感品質に影響する利用者による操作が起因の通信か否かの分類が外部から困難であること等の問題があり、アプリケーションの利用者体感品質の推定にあたり、精度の高い推定を行うことへの妨げになっていた。

（第２の側面に関する課題）
第２の側面に関する従来の技術には以下の２つの課題がある。

（１）第２の側面に関する上記従来の（Ａ），（Ｂ）の技術は、当該アプリケーションとの相関が低いという問題がある。CPU利用率等のリソースは端末の負荷状態を表す一つの尺度ではあるが、端末負荷が極端に高い状態を除くと、この指標とアプリケーション動作速度の相関は弱い。例えば、然るべき時間間隔のCPU利用率が常に100％であれば端末ボトルネックが疑われるが、80%や60%等の場合には判定がつかない。また、CPU利用率が100％であっても、プロセス優先度の関係で、アプリケーション動作速度に問題がないこともあり得る。

端末スペック規定も同様で、端末スペックという極めて大まかな括りと、様々なアプリケーション種別、操作種別の動作速度との相関をとることは困難である。

（２）上記従来の（Ｂ），（Ｃ）の技術は、品質劣化が生じた際の、端末状態を反映できないという問題がある。利用者が操作する端末では、対象となったアプリケーションのみが動作している訳ではない。例えば、ウィルス探索ソフトウェアによるチェックが同時に行われている際には、動作スペックやベンチマークスコアが規定を満足していたとしてとしても、端末ボトルネックによるサービス品質低下が起こり得る。

（第３の側面に関する課題）
第３の側面に関する従来の技術には以下の課題がある。

ユーザ体感待ち時間は、ユーザがアプリケーション実行時に実施した操作内容によって異なる。これは、アプリケーション実行時にユーザが実施した操作内容により、操作に伴って生じる処理量や、処理の複雑さが異なり、それが処理時間の違い、ひいてはユーザ体感待ち時間の違いにつながるためである。そのため、普段よりも体感待ち時間が長くなった場合に品質劣化と判別する手法では、普段とは異なる操作、特に、アプリケーションの処理量が多く複雑な操作を実施した場合に、処理が長時間化して、ユーザ体感待ち時間が通常より長くなってしまうため、サーバやネットワーク、ユーザ端末にいずれにも品質劣化が生じていないにもかかわらず、誤って品質劣化が生じたと判別してしまうことがある。従って、正しく体感品質の劣化を判別するためには、過去に類似した操作を実施したときの体感待ち時間と比較する必要がある。

例えば、非特許文献７（CA APM http://systemwalker.fujitsu.com/jp/caapm/）では、アプリケーションのメソッド単位でサーバ処理時間を監視する手法を提示しており、過去に同じメソッドを実行したときの処理時間と比較することができる。しかし、前述したように、ユーザの体感待ち時間には、ネットワークやユーザ端末での処理時間も影響するため、サーバ処理時間を監視するだけでは不十分である。また、メソッド内容まで監視するため、ユーザが実施した操作内容が特定されてしまい、ユーザの個人情報保護の観点から鑑みると、当該方法は望ましいとはいえない。

本発明は、第１〜第３の側面に関する上述した課題に鑑みなされたものである。

本発明の第１の目的は、Webブラウザ等のアプリケーションから取得した抽象化された処理種別（Network：データ取得、Scripting：スクリプト実行、Rendering：画面描画）と要した時間データに基づいて、利用者体感品質として、アプリケーションの利用者の体感待ち時間の推定を第三者が行うことを可能とする技術を提供することである。

本発明の第２の目的は、Webブラウザ等のアプリケーションから取得した抽象化された処理種別（Network、Scripting、Rendering）と当該処理に要した時間データに基づいて、端末が利用者体感品質の品質劣化要因か否かの判定を第三者が行うことを可能とする技術を提供することである。

本発明の第３の目的は、アプリケーション実行時の品質劣化判定精度を向上させるために、メソッド内容を監視することなく、利用者がアプリケーション実行時に実施した操作と類似する過去に実施された操作を判別することを可能とする技術を提供することである。

上記の第１の目的を達成するために、本発明の一実施形態によれば、利用者端末におけるアプリケーションの利用者の体感待ち時間を推定するための利用者体感品質推定装置であって、
前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を推定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段と、
前記受信ログ記憶手段から前記推定対象ログを読み出し、該データの継続時間が、所定の短時間処理閾値より短い、または、所定の長時間閾値より長いログを除外したログを出力するログ除外手段と、
前記ログ除外手段から出力されたログに対し、一定時間のタイムスロット内で行われた各処理の個数を多重度として算出する量子化手段と、
前記量子化手段で量子化されたデータから連続領域を抽出する連続領域抽出手段と、
を有し、
前記連続領域抽出手段は、
前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別せずに連続領域を抽出する第１の連続領域抽出手段、または、
前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別して連続領域を抽出する第２の連続領域抽出手段と、を含むことを特徴とする利用者体感品質推定装置が提供される。

上記の第２の目的を達成するために、本発明の一実施形態によれば、アプリケーションサーバから提供されるアプリケーションのサービス利用時に、品質劣化要因が利用者端末にあるか否かを判定するための品質劣化要因判定装置であって、
前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を判定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段と、
前記利用者端末で行われるアプリケーションに対する操作と同様の操作を行った場合のリファレンスログ、または、スクリプト実行や画面描画の処理の連続領域長の経験累積分布のデータと、前記判定対象ログを比較し、評価値を求め、該評価値の合計値と予め設定されている閾値との比較結果に基づいて、該利用者端末に品質劣化要因があるか否かを判定するボトルネック判定手段と、を有することを特徴とする品質劣化要因判定装置が提供される。

上記の第３の目的を達成するために、本発明の一実施形態によれば、アプリケーション実行にあたり、入力として与えられた操作である入力操作と類似する操作を抽出する類似操作抽出装置であって、
アプリケーションログとネットワークログのいずれか一方のみ、もしくは両方の組み合わせから切り出されたユーザ体感待ち時間に対応するログに基づき、特徴量を算出する特徴量算出手段と、
算出した前記特徴量と過去に記憶手段に保存された特徴量、及び予め定められた類似度関数に基づき前記特徴量と前記過去に保存された特徴量との類似度を算出する類似度算出手段と、を有することを特徴とする類似操作抽出装置が提供される。

第１の目的に対応する本発明の一実施形態によれば、端末上のWebブラウザ等のアプリケーションのデータ取得（Network）、スクリプト実行（Scripting）、画面描画（Rendering）の開始／終了時間の時系列情報であるログデータを活用して体感待ち時間推定を行うことで、端末処理時間も含めたアプリケーションの利用者操作に対する実行結果が画面表示されるまでの利用者体感待ち時間の推定が可能となる。また、動的コンテンツを構成要素に含む端末処理時間の比率が高いアプリケーションでは、本発明により利用者体感品質（利用者体感待ち時間）の推定精度が向上する。

また、抽象化された処理種別（Network、Scripting、Rendering)を入力とし、アプリケーション固有の情報を利用しないため、多種多様なアプリケーションに対し、利用者端末以外(利用者体感品質推定装置)からの端末側処理時間の影響を考慮した利用者体感待ち時間の常時推定が可能となり、第三者による利用者体感待ち時間に基づく利用者体感品質の常時監視が実現可能となる。

第２の目的に対応する本発明の一実施形態によれば、端末要因の品質劣化も加味した原因特定オペレーションを構築している。本発明では、端末原因も特定可能な外部（第三者）により利用者の体感品質の推定（監視）を可能とすることにより、切り分けオペレーションの構築が可能となるため、実際のアプリケーションの実行の影響と、障害発生時の端末状態を反映したボトルネック判定を実現可能であり、従来と比較してボトルネック判定の高精度化が可能となる。

第３の目的に対応する本発明の一実施形態によれば利用者がアプリケーション実行時に実施した操作と類似する過去に実施された操作を判別し、抽出することにより、類似する過去の操作に対するユーザ体感待ち時間の取得が可能となる。そして、品質劣化判定対象となるアプリケーション実行時のユーザ体感待ち時間と、前記で抽出した、類似する過去の操作に対するユーザ体感待ち時間の比較により、操作内容の影響を受けず、End-to-Endの品質劣化に起因する体感待ち時間の長時間化のみを検知することが可能となり、品質劣化判定の精度が向上する。

操作から表示までを単純化したモデルである。 通信を伴わない処理の事例である。 非同期通信の事例である。 本発明の第１の実施の形態におけるシステム構成の一例である。 本発明の実施の形態１−１における品質推定装置の構成の一例である。 本発明の実施の形態１−１における受信ログ記憶部に格納されるデータ例である。 本発明の実施の形態１−１における品質推定装置の動作のフローチャートである。 本発明の実施の形態１−１における各種閾値評価のサンプルデータである。 本発明の実施の形態１−１における量子化の例である。 本発明の実施の形態１−１における連続領域抽出処理のフローチャート(その１)である。 本発明の実施の形態１−１における連続領域抽出の例(その１)である。 本発明の実施の形態１−１における連続領域抽出処理のフローチャート（その２）である。 本発明の実施の形態１−１における連続領域抽出の例(その２)である。 本発明の実施の形態１−１における連続領域の整形例である。 本発明の実施の形態１−２における連続領域抽出処理のフローチャート（その１）である。 本発明の実施の形態１−２における各要素の連続領域判定後の和集合処理の例である。 本発明の実施の形態１−２における連続領域抽出処理のフローチャート（その２）である。 本発明の実施の形態１−２におけるNetwork⇒Scripting⇒Renderingの流れで構成される連続領域抽出の例である。 本発明の実施の形態１−２における連続領域抽出処理のフローチャート（その３）である。 本発明の実施の形態１−２におけるNetwork⇒Rendering、Scripting⇒Renderingの流れで構成される連続領域抽出の例である。 本発明の第２の実施の形態におけるシステム構成の一例である。 本発明の実施の形態２−１における端末ボトルネック判定装置の構成例である。 本発明の実施の形態２−１におけるボトルネック判定部に入力されるデータの例である。 本発明の実施の形態２−１におけるリファレンス判定を説明するための図である。 本発明の実施の形態２−１におけるリファレンス判定処理のフローチャートである。 本発明の実施の形態２−１における各種閾値評価のサンプルデータである。 本発明の実施の形態２−１における量子化の例である。 本発明の実施の形態２−１における連続領域抽出処理のフローチャートである。 本発明の実施の形態２−１における連続領域判定方法を示す図である。 本発明の実施の形態２−１におけるボトルネック判定の例である。 本発明の実施の形態２−２における端末ボトルネック判定装置の構成例である。 本発明の実施の形態２−２におけるノンリファレンス判定を説明するための図である。 本発明の実施の形態２−２における連続領域長の経験累積分布である。 本発明の実施の形態２−２における連続領域長の経験累積分布である。 本発明の実施の形態２−２におけるノンリファレンス判定のフローチャートである。 本発明の実施の形態２−２におけるノンリファレンス判定手法の具体例である。 本発明の実施の形態２−２におけるノンリファレンス判定のフローチャートである。 本発明の実施の形態２−２における評価の例である。 本発明の実施の形態２−２におけるアンダーソン・ダーリング検定による評価法（その１）である。 本発明の実施の形態２−２におけるアンダーソン・ダーリング検定による評価法（その２）である。 本発明の実施の形態２−２におけるアンダーソン・ダーリング検定による評価法（その３）である。 本発明の実施の形態２−２におけるボトルネック判定の例である。 本発明の第３の実施の形態におけるシステム構成例である。 本発明の第３の実施の形態における他のシステム構成例である。 本発明の第３の実施の形態におけるログ取得から類似操作抽出までの処理のフローチャートである。 本発明の第３の実施の形態におけるピークの求め方、及びピーク高、ピーク幅の定義を示す図である。 本発明の第３の実施の形態における処理の活性化区間の求め方を示す図である。 本発明の第３の実施の形態におけるピーク位置の分類を示す図である。 本発明の第３の実施の形態におけるピーク位置の分類を示す図である。 本発明の第３の実施の形態におけるピーク位置の分類を示す図である。 本発明の第３の実施の形態におけるピーク位置の分類を示す図である。 本発明の第３の実施の形態におけるピーク位置の分類を示す図である。 第３の実施の形態における一実施例のユーザ端末から取得したアプリケーションログの例である。 第３の実施の形態における一実施例のユーザ端末から取得したネットワークログの例である。 第３の実施の形態における一実施例の推定体感待ち時間の例である。 第３の実施の形態における一実施例の切り出されたアプリケーションログの例である。 第３の実施の形態における一実施例の切り出されたネットワークログの例である。 第３の実施の形態における一実施例の処理種別毎の処理多重度（タイムスロット＝体感待ち時間の長さ÷50）である。 第３の実施の形態における一実施例の処理種別毎の処理多重度(タイムスロット＝体感待ち時間の長さ÷10)である。 第３の実施の形態における一実施例の保存されている特徴量、推定体感待ち時間のデータ例である。 第３の実施の形態における一実施例の類似度の算出結果である。 第３の実施の形態における評価対象である。 第３の実施の形態における評価結果である。

以下図面と共に、本発明の第１〜第３の実施の形態を説明する。本実施の形態では、端末で実行されるアプリケーションがWebブラウザである場合を例として説明しているが、本発明はこの例に限られず、様々なアプリケーションに適用可能である。

（第１の実施の形態）
まず、第１の実施の形態を説明する。第１の実施の形態は、第１の目的に対応する実施の形態である。

本実施の形態では、利用者端末のWebブラウザから抽象化された処理種別（Network、Scripting、Rendering)と要した時間データを時系列で取得し、そのデータからブラウザアプリケーションについて、利用者による操作後（画面クリック後等）、ブラウザアプリケーションのレスポンスを受信して実行結果が画面表示されるまでの間の時間に対する利用者体感品質として、利用者の体感待ち時間の推定を行う。

図４は、本実施の形態のシステム構成の一例を示す。

同図においてシステムは、品質推定装置１１００、利用者端末１２００、ブラウザアプリケーションサーバ１３００から構成される。

利用者端末１２００は、Webブラウザ１２１０、ブラウザログ取得部１２２０、送信部１２３０を有し、Webブラウザ１２１０上でアプリケーションサーバ１３００のコンテンツ１３１０（アプリケーション）を実行する。ブラウザログ取得部１２２０はブラウザの処理情報ログを取得し、送信部１２３０は品質推定装置１１００にデータ送信を行う。

品質推定装置１１００は、受信部１１１０、待ち時間推定部１１２０、推定結果格納・表示部１１３０を有し、利用者端末１２００から送信されたログを受信部１１１０で受信し、待ち時間推定部１１２０で体感待ち時間推定を行い、推定結果格納・表示部１１３０でその結果を格納・表示する。

ブラウザアプリケーションサーバ１３００は、HTTPサーバ１３１０を有し、記憶手段にコンテンツ１３２０が格納されている。なお、以下の実施の形態の例においては、ブラウザアプリケーションとして、動的コンテンツ等を含む業務に係るアプリケーションを想定している。なお、「ブラウザアプリケーション」を「Webアプリケーション」と称してもよい。

［実施の形態１−１］
第１の実施の形態は、実施の形態１−１、及び実施の形態１−２を含む。まず、実施の形態１−１を説明する。図５は、本発明の実施の形態１−１における品質推定装置の構成の一例を示す。

同図に示す品質推定装置１１００は、受信部１１１０で利用者端末１２００からログを受信すると受信ログ記憶部１１０１に格納する。受信ログ記憶部１１０１に格納されるデータは、推定対象期間に、利用者端末１２００のWebブラウザ１２１０で行われたデータ取得（Network）、スクリプト実行（Scripting）、画面描画（Rendering）の全処理を対象とし、以下のような時間を取得する。

Network時間：データ取得セッションの開始終了時間
Scripting時間：Javascript（登録商標）等のスクリプト実行時間
Rendering時間：画面描画時間の開始−終了時間
受信ログ記憶部１１０１に格納されるデータの例を図６に示す。

以下に、品質推定装置１１００の動作を示す。

図７は、本発明の実施の形態１−１における品質推定装置の動作のフローチャートである。

ステップ１１１０） 品質推定装置１１００の待ち時間推定部１１２０は、受信ログ記憶部１１０１からログデータを読み出す。Network、Scripting、Renderingの各処理の継続時間が極めて短い処理については、利用者の体感待ち時間との相関が低いため、予め設定した閾値Lよりも短時間な処理については、読み出したログデータから除外する。

ここで、設定される閾値Lは推定対象のアプリケーション毎に、Network、Scripting、Renderingの各処理の閾値が設定可能である。閾値Lは、例えば、図８に示すような各種閾値の評価のサンプルデータを入力し、継続時間を変化させて得た品質推定結果と実際の利用者の体感品質結果との関係に基づいて、利用者の体感品質の最も近似する継続時間の値の組み合わせを閾値として選定する。例えば、5、10、20、30…ms等の値を入力し、品質推定を行った結果が利用者体感待ち時間と最も合致したものを選択する。具体的には、後に出てくるパラメータも含めて100万程度の組み合わせを設定し、100万通りの品質推定を試行し、利用者体感待ち時間と最も近かった値の組み合わせを利用する。

例えば、アプリケーションＡに対する短時間処理のための閾値Lとして以下の閾値を設定する。なお、閾値Lは、予め決定して待ち時時間推定部１１２０内のメモリ（図示せず）に格納しておくものとする。

Network閾値 10ms
Scripting閾値 5ms
Rendering閾値 3ms
このとき、アプリケーションＡの体感待ち時間推定を行う際には、Network、Scripting、Renderingについて、上記各閾値以下の処理時間のログを除外する。

ステップ１１２０） 次に、上記のステップ１１１０の処理において、閾値L以下のログデータが除外されたログデータのうち、Network、Scripting、Renderingの継続時間が極めて長い処理は、利用者の体感待ち時間との相関が低いため、予め設定した閾値Hよりも長時間となる処理を除外する。なお、推定対象のアプリケーション毎に、Network、Scripting、Renderingの各処理の閾値Hが設定可能である。閾値の設定方法については、ステップ１１１０と同様である。

例えば、アプリケーションＡに対する長時間処理のための閾値として以下の閾値Hを設定する。なお、閾値Hは、予め決定して待ち時間推定部１１２０のメモリ（図示せず）に格納しておくものとする。

Network閾値 10000ms
Scripting閾値 30000ms
Rendering閾値 100000ms
ステップ１１３０） 次に、上記のステップ１１１０、１１２０の処理を経たデータを一定時間間隔で量子化する。量子化の方法は、一定時間のタイムスロットで区切り、このタイムスロット内で行われたNetwork、Scripting、Renderingの各処理の個数を多重度として算出する。なお、タイムスロットの長さはアプリケーションに応じて設定可能である。

図９に量子化の例を示す。同図において、アプリケーションＢに対して、タイムスロット0.1秒を設定する。アプリケーションＢのログに対して、ステップ１１１０，１１２０の処理後に、0.1秒ごとにタイムスロットを設定し、各スロット内の処理数をカウントし、多重度をタイムスロット毎に算出する。

ステップ１１４０） ステップ１１３０で量子化されたデータから、連続領域を抽出する。連続領域の抽出方法として、本実施の形態では、Network、Scripting、Renderingを区別せずに、評価する。なお、Network、Scripting、Renderingを区別して評価する方法については実施の形態１−２で後述する。

Network、Scripting、Renderingを区別せずに評価する方法として、以下の２つの方法がある。

（１）スライディングウィンドウが継続した時間でのみ評価する方法（A−1）：
（２）スライディングウィンドウが継続した時間と多重度で評価する方法(A−2)：
まず、上記の（１）の方法について説明する。

図１０は、本発明の実施の形態１−１における連続領域抽出処理のフローチャート(その１)である。

ステップ１１４１） 入力された検知閾値をメモリ(図示せず)内に設定する。

ステップ１１４２） 入力されたスライディングウィンドウ長をメモリ（図示せず）に設定する。

ステップ１１４３） 先頭タイムスロットから分析を開始する。

ステップ１１４４） 当該タイムスロットからスライディングウィンドウを伸ばし、スライディングウィンドウ内のタイムスロットのうち少なくとも１つのタイムスロットにおいて、検知閾値を超える処理があれば（例：Network、Scripting、Renderingのいずれか１つにおいて検知閾値を超える場合）、当該始点のタイムスロットは連続領域内と判定される。この判定処理を時間が経過する方向に当該タイムスロットを１つずつずらしながら行う。

ステップ１１４５) 最終タイムスロットまで処理を行う。

ステップ１１４６） 連続領域内と判定されたタイムスロットを有するスライディングウィンドウが連続した区間を連続領域として判定する。

上記のステップ１１４６における判定方法の例を図１１に示す。例えば、スライディングウィンドウ長が３で検知閾値が３の場合、当該タイムスロットから時間経過方向で３スロット内に１つでも検知閾値を超える処理を含むタイムスロットがあれば、当該タイムスロットは連続領域内と判定される。

次に、上記の「（２）スライディングウィンドウが継続した時間と多重度で評価する方法」について説明する。

図１２は、本発明の実施の形態１−１における連続領域抽出処理のフローチャート（その２）である。

ステップ１１５１） 入力された検知閾値ｘをメモリ（図示せず）に設定する。

ステップ１１５２） 入力されたスライディングウィンドウ長ｙをメモリ（図示せず）に設定する。

ステップ１１５３） 入力された連続判定閾値ｚをメモリ（図示せず）に設定する。

ステップ１１５４） 時間が経過する方向へタイムスロットTiを＋１進める。

ステップ１１５５） 当該タイムスロットTiを始点としてスライディングウィンドウを伸ばした際に、検知閾値ｘを超えるタイムスロット数（ts）の存在比率（ts／y）が連続判定閾値zを超えている場合はステップ１１５６に移行し、超えていない場合はステップ１１５４に戻る。

例えば、図１３に示す例において、スライディングウィンドウ長が３で連続判定閾値が0.5の場合、当該タイムスロットから時間経過方向で３スロット内に検知閾値（３）を超えるタイムスロット（タイムスロットの数は整数）が２個以上あれば、当該タイムスロットは連続領域内と判定され、検知閾値を超えるタイムスロットが１個以下の場合は連続領域内でないと判定される。

ステップ１１５６） 連続判定閾値を超えたタイムスロットTiを始点とするスライディングウィンドウ長の区間において、始点Tiが連続する領域を連続領域と判定する。

ここで、図７のフローの説明に戻る。

ステップ１１５０） 上記のステップ１１４０で抽出された連続領域に以下のルールに従って整形処理を行う。図１４に整形例を示す。

（１）抽出された連続領域の最終スロットと、次の連続領域の先頭スロットが連続する場合には、一つの連続領域に設定する。

（２）上記の（１）の処理後の連続領域長が、閾値Tmin以下の場合には削除する。

（３）上記の（１）の処理後の連続領域長が、閾値Tmax以上の場合には削除する。

上記の閾値Tminは、利用者が体感できないような待ち時間（0.5〜2秒）を除外する目的で設定する。Tmaxは、システムの応答が停止している状況（フリーズ）を除外することを目的としている。

上記の整形処理を行った後に、連続領域を推定待ち時間として記憶手段に格納する、または、表示手段に表示する。なお、連続領域について、利用者操作の数だけ連続領域（推定待ち時間）が出力される。具体的には、アプリケーションを１０回操作した場合には、連続領域が１０個出現する。

［実施の形態１−２］
実施の形態１−２では、実施の形態１−１の図７のステップ１１４０において、Network、Scripting、Renderingを区別して評価する３つの方法について説明する。

品質推定装置の構成および、ステップ１１４０以外の処理については、実施の形態１−１と同様であるのでその説明を省略する。

実施の形態１−２のステップ１１４０において、Network、Scripting、Renderingを区別して評価する方法では、Network、Scripting、Renderingの各処理で検知閾値等を変更することが可能となり、利用者体感待ち時間抽出の精度の向上が期待できる。ただし、設定が必要なパラメータ数は実施の形態１−１の「（２）スライディングウィンドウが継続した時間と多重度で評価する方法(A−2)」に比べて多くなる。

本実施の形態の第１の方法（B−1）について説明する。

図１５は、本発明の実施の形態１−２における連続領域抽出処理のフローチャート（その１）である。

ステップ１２０１） Network、Scripting、Renderingの各要素に対して、実施の形態１−１のA−2による連続領域判定を行い、各要素の連続領域を抽出する。A−2と同様の処理を行うためには、スラディングウィンドウ長、検知閾値、連続判定閾値の３つのパラメータが必要となるが、Network、Scripting、Renderingの各要素に対して異なる値を設定可能である。

ステップ１２０２） Network、Scripting、Renderingの各要素について、図１６に示すように、連続領域の和集合を連続領域として判定する。

次に、利用者の操作に応じた処理が、Network⇒Scripting⇒Renderingの流れで処理されることに着目し、ステップ１１１０〜１１３０の処理後、このシーケンスの組み合わせを抽出することで、利用者の体感待ち時間と相関性の高い区間を抽出する第２の処理（B−2）について説明する。

図１７は、本発明の実施の形態１−２における連続領域抽出処理のフローチャート（その２）である。図１８において当該フローチャートの処理で抽出される領域を（B−2）と記す。

ステップ１２１１） Network、Scripting、Renderingの各要素に対して、実施の形態１−１のA−２の連続領域判定処理を行い、各要素の連続領域を抽出する。当該処理は、図１５のステップ１２０１と同様に、スライディングウィンドウ長、検知閾値、連続判定閾値の３つのパラメータが必要となるが、Network、Scripting、Renderingの各要素に対して異なる値を設定可能である。

ステップ１２１２） Network処理の連続領域と判定されたタイムスロット範囲内、もしくは、Network処理の連続領域と判定されたタイムスロット範囲に隣接するタイムスロットが開始位置となっているScripting連続領域（図１８のａ）を抽出する。

ステップ１２１３） ステップ１２１２で抽出されたScriptingタイムスロット範囲内(図１８のｂ)、もしくは、当該Scriptingタイムスロット範囲に隣接するタイムスロットが開始位置となっているRendering連続領域（図１８のｂ）を抽出する。

ステップ１２１４） ステップ１２１３で抽出されたRendering連続領域とその元となったScripting、Network領域の論理和を領域（図１８のｃ）として判定する。なお、複数の領域が重複した際には、その論理和を連続領域として設定する。

次に、上記の第２の方法に加えて、Network⇒Renderingのみで行われる処理、Scripting⇒Renderingのみで行われる処理を抽出する第３の方法（B−3）について説明する。

図１９は、本発明の実施の形態における連続領域抽出処理のフローチャート(その３)を示す。図２０において、図１７の処理で抽出された領域を（B−2）、当該フローチャートの処理で抽出される領域を（B−3）と記す。

ステップ１２２１） 図１７に示すB−2の処理を実行し、Network⇒Scripting⇒Renderingの順で構成される連続領域を抽出する。

ステップ１２２２） 上記のステップ１２２１で抽出されなかったNetwork連続領域（図２０のａ）において、そのタイムスロット内、もしくは、Network連続領域の終点のタイムスロットに隣接して開始されるRendering連続領域（図２０のｂ）を抽出する。

ステップ１２２３） ステップ１２２２で抽出されたRendering連続領域と、その元となったNetwork連続領域の論理和を連続領域（図２０のｃ）として判定する。

ステップ１２２４） ステップ１２２３並びにB−2の処理で抽出されなかったScripting連続領域において、Scripting連続領域の終点のタイムスロットに隣接して開始するRendering連続領域（図２０のｄ）を抽出する。

ステップ１２２５） ステップ１２２４で抽出されたRendering連続領域と、その元となったScripting連続領域の論理和を連続領域（図２０のｅ）として判定する。

上記の実施の形態１−１、１−２に示す利用者体感品質推定装置により、多種多用なアプリケーションに対して、利用者体感待ち時間の常時推定が実現可能であり、また、利用者体感品質推定装置による利用者体感品質の常時監視が可能となる。

なお、上記の図５に示す利用者体感品質推定装置の各構成要素の動作をプログラムとして構築し、利用者体感品質推定装置として利用されるコンピュータにインストールする、または、ネットワークを介して流通させることが可能である。

より詳細には、図５に示す利用者体感品質推定装置は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、利用者体感品質推定装置の各部が有する機能は、当該利用者体感品質推定装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

本実施の形態では、例えば、コンピュータを、利用者端末におけるアプリケーションの利用者の体感待ち時間を推定するための利用者体感品質推定装置として機能させる利用者体感品質推定プログラムであり、コンピュータを、
前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を推定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段、
前記受信ログ記憶手段から前記推定対象ログを読み出し、該データの継続時間が、所定の短時間処理閾値より短い、または、所定の長時間閾値より長いログを除外したログを出力するログ除外手段、
前記ログ除外手段から出力されたログに対し、一定時間のタイムスロット内で行われた各処理の個数を多重度として算出する量子化手段、
前記量子化手段で量子化されたデータから連続領域を抽出する連続領域抽出手段、として機能させる利用者体感品質推定プログラムであって、
前記連続領域抽出手段は、前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別せずに連続領域を抽出する第１の連続領域抽出手段、または、前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別して連続領域を抽出する第２の連続領域抽出手段と、を含む利用者体感品質推定プログラムが提供される。

（第２の実施の形態）
次に、第２の実施の形態を説明する。第２の実施の形態は、第２の目的に対応する実施の形態である。

図２１は、本実施の形態のシステム構成の一例を示す。

同図に示すシステムは、端末ボトルネック判定装置２１００、利用者端末２２００、ブラウザアプリケーションサーバ２３００から構成される。

利用者端末２２００は、Webブラウザ２２１０、ブラウザログ取得部２２２０、送信部２２３０を有し、Webブラウザ２２１０上でアプリケーションサーバ２３００のコンテンツ２３１０（アプリケーション）を実行する。ブラウザログ取得部２２２０はブラウザの処理情報ログを取得し、送信部２２３０は端末ボトルネック判定装置２１００にデータ送信を行う。

端末ボトルネック判定装置２１００は、受信部２１１０、ボトルネック判定部２１２０、判定結果格納・表示部２１３０を有し、利用者端末２２００から送信されたログを受信部２１１０で受信し、ボトルネック判定部２１２０で端末ボトルネックの判定を行い、判定結果格納・表示部２１３０でその結果を格納・表示する。

ブラウザアプリケーションサーバ２３００は、HTTPサーバ２３１０を有し、記憶手段にコンテンツ２３２０が格納されている。該コンテンツ２３２０には動的コンテンツ等を含むコンテンツも含まれる。

利用者端末２２００において、Webブラウザから抽象化された処理種別（Network，Scripting、Rendering）と要した時間データを取得し、そのデータを端末ボトルネック判定装置２１００に送出する。

端末ボトルネック判定装置２１００は、当該データから端末ボトルネック判定を行う。端末ボトルネック判定を行うにあたって、比較対象となる入力データを都度与えてボトルネック判定を行うリファレンス判定法と、比較対象となるデータを予め蓄積しておき、蓄積された結果を比較するノンリファレンス判定法の２種類がある。

以下では、リファレンスログ判定法の例を実施の形態２−１とし、ノンリファレンス判定法の例を実施の形態２−２として説明する。

［実施の形態２−１］
図２２は、本発明の実施の形態における端末ボトルネック判定装置の構成例を示す。同図に示す端末ボトルネック判定装置２１００は、受信ログ記憶部２１０１、リファレンスログ記憶部２１０２、受信部２１１０、ボトルネック判定部２１２０、判定結果格納・表示部２１３０から構成される。

受信ログ記憶部２１０１は、利用者端末２２００のブラウザログ取得部２２２０で取得され、受信部２１１０で受信した以下の情報を一時的に格納する。

・Network時間：データ取得セッション開始・終了時間
・Scripting時間：Javascript（登録商標）等のスクリプト実行時間
・Rendering時間：画面描画時間の開始終了時間
図２３に、格納されるデータ例を示す。同図に示すデータは、操作開始０秒後〜１５秒後までのブラウザログの例であり、当該ブラウザログは、開始時間（秒）、継続時間（ミリ秒）、処理種別から構成される。ここで、継続時間とは、ネットワークにおいてはセッション継続時間であり、Renderingは描画時間を示している。通常処理においてはこれらの処理が数ms〜数十ms程度継続したログが大量に出力される。例えば、３分程度ブラウザを操作した際には、上記ログが一万行程度出力される。

リファレンスログ記憶部２１０２には、利用者端末２２００に擾乱要因が全くない状態のログ（リファレンスログ）が一時的に格納される。リファレンスログ判定においては、図２４に示すように、リファレンスログと受信ログ（判定対象ログ）が全く同じ処理であることを前提としているため、受信ログと同じ操作のログが必要となる。同じ操作のログがない場合は、オペレータ等が同じ操作を行ってログを蓄積し、判定対象ログと比較する。実際のアプリケーション利用環境において、全く同じ操作のログを事前準備するのは非現実的であるため、苦情等の申告を受けた際に、オペレータがお客様と同じ操作を行って比較可能なログをリファレンスログとして準備するか、もしくは、標準操作シナリオを規定してお客様に標準操作を行った際のログの提供を依頼する等の方法がある。

以下に、ボトルネック判定部２１２０のリファレンス判定処理について説明する。

図２５は、本発明の実施の形態２−１におけるリファレンス判定のフローチャートである。

なお、受信部２１１０において、判定対象ログを取得し、受信ログ記憶部２１０１に格納し、また、上記のいずれかの方法によりリファレンスログを収集してリファレンスログ記憶部２１０２に格納しているものとする。

ステップ２１１０） ボトルネック判定部２１２０は、受信ログ記憶部２１０１とリファレンスログ記憶部２１０２からそれぞれログを読み出し、Network、Scripting、Renderingの継続時間が極めて短い処理は利用者の体感待ち時間との相関が低いため、予め設定した閾値よりも短時間となる処理は、当該ステップでログから除外する。なお、当該閾値は、図２６に示すようなサンプルデータから経験的に算出したものである。当該閾値は、例えば、任意の値を入力し、品質推定を行った結果が利用者体感待ち時間と最も合致したものを選択している。なお、推定対象のアプリケーション毎に、Network、Scripting、Renderingの各処理の閾値が設定可能である。例として、アプリケーションＡに対する短時間処理閾値の例を以下に示す。

Network閾値： 10ms
Scripting閾値： 5ms
Rendering閾値： 3ms
アプリケーションＡの体感待ち時間推定を行う際には、Network、Scripting、Renderingについて、上記各閾値以下の処理時間のログは当該ステップで除外する。

ステップ２１２０） 次に、Network、Scripting、Renderingの継続時間が極めて長い処理は、除外する。Network、Scripting、Renderingの継続時間が極めて長い処理は、利用者の体感待ち時間との相関が低いため、予め設定した閾値よりも長時間となる。なお、判定対象のアプリケーション毎に、Network、Scripting、Renderingの各処理の閾値が設定可能である。例えば、
Network閾値： 10000ms
Scripting閾値： 30000ms
Rendering閾値： 100000ms
Network、Scripting、Renderingについて、上記各閾値以上の処理時間のログは当該ステップにおいて除外する。

ステップ２１３０） 次に、短時間処理、長時間処理が除外された（ステップ２１１０，２１２０）リファレンスログ及び判定対象ログの両方に対して、統計値による評価を行う。当該評価処理は、利用者端末２２００がボトルネックとなっている場合に、ScriptingとRenderingの処理継続時間が長くなる傾向があることから、以下の評価を行う。

ａ）Scripting処理継続時間による評価：
リファレンスログ、判定対象ログそれぞれの対応する各Scripting処理について、継続時間に対する以下のいずれかの統計値を比較し、判定対象ログの方が長ければ、Scripting処理継続時間による判定対象ログの評価として加点する。なお、各統計値毎の加点値は個別に設定可能である。例えば、以下のように設定する。

・99%値 X%以上長ければ１点加点、Y%（Y＞X）以上なら２点加点
・90%値 X%以下長ければ０点
・平均値 Z%以上短ければ−1点、W%（Ｗ＞Z）以上短ければ−２点
なお、ここでは、代表的な統計値を提示したが、その他統計値を用いても良い。

ｂ）Rendering処理継続時間による評価：
リファレンスログ、判定対象ログそれぞれの対応する各Rendering処理について、継続時間に対する上記Scripting処理と同様の統計値を比較し、判定対象ログの方が長ければRendering処理継続時間による判定対象ログの評価として加点する。なお、各統計値毎の加点値は個別に設定可能である。また、この例に限定されることなく、上記a)と同様に任意の統計値を設定可能である。

当該ステップで求められた加点の合計値は、ステップ２１７０において、評価点に基づくボトルネック判定で利用する。

ステップ２１４０） 次に、リファレンスログ及び判定対象ログの両方に対して量子化を行う。上記のステップ２１１０で短時間処理が除外され、ステップ２１２０で長時間処理が除外されたデータについて、一定時間間隔で量子化する。量子化の方法としては、一定時間のタイムスロットで区切り、このタイムスロット内で行われたNetwork、Scripting、Renderingの各処理個数を多重度として算出する。図２７に量子化の例を示す。同図において、アプリケーションＢに対してタイムスロット0.1秒を設定する。アプリケーションＢのログに対して、0.1秒毎にタイムスロットを設定し、各スロット内の処理数をカウントし、多重度をタイムスロット毎に算出する。

ステップ２１５０） リファレンスログ、判定対象ログの両方に対して、Scripting、Renderingそれぞれの連続領域抽出を行う。以下に連続領域抽出処理の一例を示す。

図２８は、本発明の実施の形態２−１における連続領域抽出処理のフローチャートである。

ステップ２１５１） 入力された検知閾値ｘをメモリ（図示せず）内に設定する。

ステップ２１５２） 入力されたスライディングウィンドウ長ｙをメモリ（図示せず）に設定する。

ステップ２１５３） 入力された連続判定閾値ｚをメモリ（図示せず）設定する。

ステップ２１５４） 時間が経過する方向へタイムスロットTiを＋１進める。

ステップ２１５５） 当該タイムスロットTiを始点としてスライディングウィンドウを伸ばした際に、検知閾値ｘを超えるタイムスロット数（ts）の存在比率（ts／y）が連続判定閾値zを超えている場合はステップ２１５６に移行し、超えていない場合はステップ２１５４に戻る。

ステップ２１５６） 当該タイムスロットは連続領域の範囲内であると判定する。

上記のステップ２１５５における判定方法を図２９に示す。当該タイムスロットからスライディングウィンドウを伸ばした際に、検知閾値を超えたタイムスロットの存在比率で判定を行う。例えば、スライディングウィンドウ長が３で連続判定閾値が0.5の場合、当該タイムスロットから時間経過方向で３スロット内に検知閾値を超えるタイムスロットが２個以上あれば、当該タイムスロットは連続領域内と判定され、タイムスロットが１個以下の場合には連続でないと判断される。

ステップ２１６０） 次に、リファレンスログ、判定対象ログにおけるScripting並びにRenderingの連続領域長の統計値による評価を行う。利用者端末２００がボトルネックとなっている場合に、ScriptingとRenderingの連続領域長が長くなる傾向があることから、以下の評価を行う。

ａ）Scripting処理連続領域長による評価：
リファレンスログ、判定対象ログそれぞれの対応する各Scripting連続領域長に対する以下の統計値を比較し、判定対象ログの方が長ければScripting連続領域長による判定対象ログの評価として加点する。なお、各統計値ごとの加点値は個別に設定可能である。

以下に例を示す。

・最大値 X%以上長ければ１点加算、Y%(Y＞X）以上なら２点加算
・90%値 X%以下長ければ０点
・平均値 Z%以上短ければ−１点、W%（Ｗ＞Z）以上なら−２点
ここでは、代表的な統計値を示したが、この例に限定されることなく、その他統計値であってもよい。また、上記の例のXも様々な値を設定することが可能である。

ｂ）Rendering処理連続領域長による評価：
リファレンスログ、判定対象ログそれぞれの対応する各Rendering処理連続領域に対する上記Scripting処理と同様の統計値を比較し、判定対象ログの方が長ければRendering処理継続時間による判定対象ログの評価として加点する。なお、各統計値毎の加点値は個別に設定可能である。

上記の加点値の合計値は、ステップ２１７０のボトルネック判定で利用される。

ステップ２１７０） 最後に、ステップ２１３０、２１６０までの評価結果に基づいて、利用端末２２００のボトルネック判定を行う。

上記のステップ２１３０による判定対象ログに対する入力情報の統計値による評価及びステップ２１６０の連続領域長の統計値による評価値を合計して、予め設定された閾値以上であるかを判定し、閾値以上であれば端末ボトルネックと判定する。ステップ２１３０における入力情報の統計値による評価と、ステップ２１６０の連続領域長の統計値の重み付けは、ステップ２１３０、ステップ２１６０で加算する値で調整することが可能である。

また、評価点が大きくなるほど端末ボトルネックの可能性が高くなることから、２つの閾値を用いて、端末ボトルネックの可能性が非常に高い端末ボトルネックが疑われるなどの２段階の判断を行うことも可能である。図３０にその判定例を示す。

図３０の判定例１では、１つのボトルネック判定閾値「５」を設定し、ステップ２１３０とステップ２１６０の評価値の合計が「７」であった場合は、５＜７であるので評価結果は「端末ボトルネック」と判定される。同図の判定例２では、端末ボトルネックが強く疑われる閾値「１０」と端末ボトルネックが疑われる閾値「５」が設定されているとき、評価値が「１２」であれば、１０＜１２であるので、評価結果は、「端末ボトルネックが強く疑われる」が得られ、判定結果格納・表示部２１３０から出力される。当該評価結果は、ハードディスク等の記憶媒体やディスプレイ等の表示手段に出力されるものとする。

［実施の形態２−２］
本実施の形態では、ボトルネック判定をノンリファレンス判定で実施する場合の例について説明する。

実施の形態２−１では、判定対象のログと端末擾乱要因なしのログ（リファレンスログ）が同じ操作を行っていることが必要なリファレンス判定について説明したが、本実施の形態では、判定対象ログと端末擾乱要因なしのログが同じ操作を行っている必要がないノンリファレンス判定について説明する。

図３１は、本発明の実施の形態２−２における端末ボトルネック判定装置の構成例を示す。

同図に示す端末ボトルネック判定装置は、図２２に示すリファレンスログＤＢ２１０２の代わりに連続領域長経験累積分布ＤＢ２１０３を用いる点において、図２２に示す端末ボトルネック判定装置と異なる。連続領域長経験累積分布ＤＢ２１０３は予め連続領域長経験累積分布ＤＢ生成部２１４０によって生成され、連続領域長経験累積分布ＤＢ２１０３には、端末の擾乱要因がない状態で、アプリケーションを操作した際のScripting、Rendering継続時間が格納される。連続領域長経験累積分布ＤＢ生成部２１４０は、Scripting、Renderingのログの取得可能な状態で行われたアプリケーション操作におけるログ（端末の擾乱要因がない状態の操作ログ）から、Scripting、Rendering処理の連続長を抽出し、それらの経験累積分布を求め、連続領域長経験累積分布ＤＢ２１０３に登録する。当該アプリケーション操作は、ユーザが全く同じ操作を繰り返すのではなく、通常利用されるであろう様々な操作を繰り返し行うものとする。

本実施の形態では、図３２に示すように、連続領域長経験累積分布ＤＢ２１０３に格納されている端末に擾乱要因が全くない状態でアプリケーションが操作された際の、Scripting連続領域長と、Rendering連続領域長の経験累積分布のデータと、受信ログ記憶部２１０１に格納されている判定対象ログのScripting、Rendering連続領域長の比較を行うことで、判定対象データが端末ボトルネックとなっているかどうかの判定を行う。なお、受信ログ記憶部２１０１に格納される判定対象ログは、実施の形態２−１と同様に、利用者端末２００において利用者の操作によるログデータが格納される。

本実施の形態では、アプリケーション毎のScripting連続領域長と、Rendering連続領域長が一定の分布を示す特徴に着目し、判定対象のログが分布の上方に位置しているのか下方に位置しているかを検定し、端末ボトルネックの判定を行う。

まず、連続領域長経験累積分布ＤＢ２１０３について説明する。

連続領域長経験累積分布ＤＢ２１０３の情報は、端末ボトルネック判定を行う前に、予め、連続領域長経験累積分布ＤＢ生成部２１４０により準備されているものとする。当該ＤＢ２１０３に格納されるデータは、当該アプリケーションを操作した際のScripting連続領域長とRendering連続領域長の経験累積分布であり、データ数が多いほど、判定精度を高めることが可能となる。図３３A、Bに連続領域長の経験累積分布を示す。図３３AはScripting連続領域長の経験累積分布であり、図３３BはRendering連続領域長の経験累積分布である。このような分布を処理前に準備しておくものとする。

以下に、本実施の形態におけるボトルネック判定部２１２０の処理を説明する。なお、受信部２１１０及び判定結果格納・表示部２１３０の処理は、実施の形態２−１と同様である。

ボトルネック判定部２１２０は、以下のような処理を行う。

図３４は、本発明の実施の形態２−２におけるノンリファレンス判定のフローチャートである。

ステップ２２１０） 事前に、連続領域長経験累積分布ＤＢ生成部２１４０において、図３３A、Bに示したような連続領域長の経験累積分布を作成し、連続領域長経験累積分布ＤＢ２１０３に格納しておく。

ステップ２２２０） 実施の形態２−１のステップ２１１０と同様の処理を行う。

ステップ２２３０） 実施の形態２−１のステップ２１２０と同様の処理を行う。

ステップ２２４０） 実施の形態２−１のステップ２１３０と同様の処理を行う。

ステップ２２５０） 実施の形態２−１のステップ２１４０と同様の処理を行う。

ステップ２２６０） ボトルネック判定部２１２０は、上記のステップ２２５０までの処理において得られた連続領域長と、連続領域長経験累積分布ＤＢ２１０３に格納されている経験累積分布との上下判定を行い、判定結果はメモリ（図示せず）に保持する。その判定方法は以下の２つの手法がある。

（１）ステップ２２５０までの処理で得られた判定対象データに含まれる個々の連続領域長が連続領域長経験累積分布ＤＢ２１０３の経験累積分布の上下どちらにあるのかを判定する手法。

（２）アンダーソン・ダーリング検定の手法を用いて判断する手法。

なお、上記の（１）、（２）は一例であり、これら以外にも、経験累積分布との上下判定を実施できる方法であればよい。

図３５に、上記の（１）の判定の手法の一例を示す。ノンリファレンス判定では、判定対象ログに含まれる高々数十個の連続領域長が累積確率分布の上下のいずれに位置しているかの判定を行う。

図３６は、本発明の実施の形態２−２におけるノンリファレンス判定のフローチャートである。

ステップ２２６１） 判定対象ログに含まれる連続領域長データ数を累積比率化する。つまり、個々のデータが連続領域長経験累積分布ＤＢ２１０３の累積確率分布の上下どちらにあるかを判定して、データ全体が分布の上下どちら側にあるのかを判定する。

ステップ２２６２） 個々のデータが累積比率分布よりも上にあれば、＋１、下部にあれば−１の評価値を付与する。具体的には、図３７に示すように、同一比率値における経験累積分布ａからの距離に基づいて評価値を求める、または、同一秒数における経験累積分布ａとの比率差を評価値とする方法が考えられる。また、距離の他に、縦軸の累積比率を揃えて、秒数差を評価する場合には、経験累積分布ａよりも右側にある場合はマイナス、左側にある場合はプラス、というような評価も可能である。

ステップ２２６３） 判定対象ログのScripting領域長全てのデータに対する上下判定評価値を合計する。

ステップ２２６４） 合計値が正の数であれば、経験累積分布よりも上部にあると判定し、負の値であれば下部にあると判定する。

次に、上記の（２）のアンダーソンダーリング検定に基づいて上下判定を行う手法について説明する。アンダーソンダーリング検定による評価方法には、以下の４つの方法がある。

第１の方法は、仮説検定を用いる例である。

図３８は、本発明の実施の形態におけるアンダーソンダーリング検定による評価法（その１）を示す。

（１）通常時のログを入力し、通常時の経験分布に基づく通常時の分布関数を推定する。

（２）試験時のログを入力し、試験時のログ（少数）を経験累積分布として出力する。

（３）上記の（１）、（２）の各出力及び、有意水準に基づいて、仮説検定を実施し、試験時の正常性を判定する。

第２の方法は、通常時のログの経験累積分布を用いる例である。

図３９に示すように、上記のステップ２２２０〜２２５０の処理を経た通常時のログの経験累積分布に基づいて、滑らかな関数として累積分布関数を推定することも可能である（推定される累積分布は処理時間の各値に対し、陽に値を算出可能である）。当該推定方法は、ログデータを初期値とし、境界条件（非負であること）を課した熱方程式の解として推定することにより、図３９（ｂ）に示すように滑らかな関数が得られる。

第３の方法は、試験時のログ（利用者端末から取得したログ以外のログ）を経験累積分布とする例である。

図４０に示すように、小数ではあるが、試験時のログを取得してこれを経験分析分布として出力する。

第４の方法は、帰無仮説により評価する方法である。

当該方法は、「第１の方法の（２）の試験実施時のログを用いて得られた標本は、（１）の通常時の経験分布から求められた分布関数に比して有意に大きい／小さいといえない」、という帰無仮説を用いる。当該帰無仮説に対して、第１の方法の（１）、（２）の各出力（通常時の分布関数、試験時の経験分布）に基づき、仮説検定を実施し、試験時の正常性について判定する。例えば、アンダーソン・ダーリング検定により、有意水準５％で実施する。また、第１の方法の（２）において、標本サイズが小さいことからブートストラップを適用する。ブートストラップｐ値は、以下のアンダーソン・ダーリング統計量Ａを適用して求める。

求められたブートストラップｐ値が、0.05より小さい場合は、帰無仮説を棄却（有意差あり）として、通常時より大きい／小さいと判定する。

求められたブートストラップｐ値が、0.05以上である場合は、帰無仮説を棄却できず（有意差ありとはいえない）として、通常の範囲と判定する。

ここで、図３４のフローの説明に戻る。

ステップ２２７０） 最後に、メモリ（図示せず）に保存されている経験累積分布との上下判定結果に基づいて、図４１に示すようなボトルネック判定を行う。ステップ２２６０において、上下判定評価を採用した場合は、Scripting処理、Rendering処理の各処理における評価値の合計に閾値を設定し、一定値以下であった場合には端末ボトルネックであると判定する。例えば、ボトルネック判定閾値が「−５」であり、評価値が「２」の場合は、『端末ボトルネックではない』と判定し、端末ボトルネックが強く疑われる閾値が「−１０」、端末ボトルネックが疑われる閾値「−５」であり、求められた評価値が「−１２」である場合は、『端末ボトルネックが強く疑われる』と判定する。

一方、ステップ２２６０でアンダーセンダーリング検定を採用した場合は、Scripting処理、Rendering処理の各処理において、経験累積分布よりも下部にあると判定された際には、『端末ボトルネック』と判定し、それ以外のケースでは『端末ボトルネックではない』と判定する。もしくは、Scripting処理、Rendering処理のどちらか一方の処理において、経験累積分布よりも下部にあると判定された際には、『端末ボトルネック』と判定する。

上記のようにして得られた判定結果は、実施の形態２−１と同様に、判定結果格納・表示部２１３０を介して記憶手段または表示手段に出力される。

なお、上記の図２２、図３１に示す端末ボトルネック判定装置の各構成要素の動作をプログラムとして構築し、端末ボトルネック判定装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

より詳細には、図２２に示す端末ボトルネック判定装置、及び図３１に示す端末ボトルネック判定装置はそれぞれ、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、端末ボトルネック判定装置の各部が有する機能は、当該端末ボトルネック判定装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

例えば、本実施の形態では、コンピュータを、アプリケーションサーバから提供されるアプリケーションのサービス利用時に、品質劣化要因が利用者端末にあるか否かを判定するための品質劣化要因判定装置として機能させる品質劣化要因判定プログラムであって、コンピュータを、
前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を判定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段、
前記利用者端末で行われるアプリケーションに対する操作と同様の操作を行った場合のリファレンスログ、または、スクリプト実行や画面描画の処理の連続領域長の経験累積分布のデータと、前記判定対象ログを比較し、評価値を求め、該評価値の合計値と予め設定されている閾値との比較結果に基づいて、該利用者端末に品質劣化要因があるか否かを判定するボトルネック判定手段、として機能させるための品質劣化要因判定プログラムが提供される。

（第３の実施の形態）
次に、第３の実施の形態を説明する。第３の実施の形態は、第３の目的に対応する実施の形態である。

本実施の形態は、アプリケーションをメソッド単位で監視することなく、アプリケーション実行時において、ユーザが実行した操作の類似判定を行うために、入力として与えられたユーザによる操作(以下、「ユーザ入力操作」と記す)に対し、ユーザ入力操作時の実施期間に対応するログから求めた特徴量を用いて類似した操作を抽出する。ここで「ユーザ入力操作」とは、Webサイトへのログイン、リンクのクリック等の外部入出力インタフェースを通じてユーザがアプリケーションに対して実施した操作を指し、過去に実施したユーザによる操作との類似判定の対象となる操作のことであり、ユーザが実行した操作を対象とし、アプリケーションがバックグラウンドで行っている処理は対象外とする。ここで「処理」とは、上記のユーザ入力操作に伴ってユーザ端末で実行される処理を指し、通常の１回のユーザ入力操作に対し、複数の処理が並行して実行される。

図４２は、本実施の形態におけるシステム構成例を示す。

同図に示すシステムは、類似操作抽出装置３１００、ユーザ端末３２００、ＡＰ（アプリケーション)サーバ３３００から構成される。

類似操作抽出装置３１００は、体感待ち時間推定部３１１０、ログ切り出し部３１２０、特徴量算出部３１３０、類似度算出部３１４０、類似操作抽出部３１５０、保存部３１６０、記憶部３１７０を有する。

ユーザ端末３２００は、送信部３２１０、ログ取得部３２２０、Webブラウザ３２３０を有する。

ＡＰサーバ３３００は、HTTPサーバ３３１０、コンテンツ３３２０を有する。

なお、図４２の構成は、類似操作抽出装置３１００とユーザ端末３２００を独立させた構成であるが、この例に限定されることなく、図４３に示すように、ユーザ端末３２００内に類似操作抽出装置３１００を組み込む構成としてもよい。

図４４は、本実施の形態におけるログ取得から類似操作抽出までの処理のフローチャートである。以下では、図４２の構成に基づいて説明する。

ステップ３１００）ユーザ端末３２００のログ取得部３２２０でログを取得し、送信部３２１０を介して類似操作抽出装置３１００に送信する。なお、ここでの「ログ」とは、アプリケーションログとネットワークログのいずれか一方のみ、もしくは両方の組み合わせを指す。以下ではアプリケーションログとネットワークログの双方を利用するものとして説明する。

ステップ３２００） 類似操作抽出装置３１００の体感待ち時間推定部３１１０は、ユーザ端末３２００から取得したアプリケーションログからユーザの体感待ち時間を推定し、記憶部３１７０に格納する。

ステップ３３００） ログ切り出し部３１２０は、体感待ち時間推定部３１１０で推定された体感待ち時間に対応する部分のアプリケーションログとネットワークログを切り出す。

ステップ３４００） 特徴量算出部３１３０は、切り出されたアプリケーションログから算出された処理多重度グラフとネットワークログから算出された受信データ量の少なくともいずれか一方を取得して特徴量を算出する。

ステップ３５００） 類似度算出部３１４０は、特徴量算出部３１３０で算出された特徴量と、記憶部３１７０に格納されている過去の特徴量、及び所定の類似度関数から、算出された特徴量と過去の特徴量との類似度を算出する。

ステップ３６００） 類似操作抽出部３１５０は、類似度算出部３１４０で算出された類似度に基づいて、ユーザ入力操作と類似した操作を抽出する。保存部３１６０は、特徴量に識別番号を付与し、当該識別番号と特徴量の組を記憶部３１７０に格納する。

以下に、上記の各処理について説明する。

類似操作抽出装置３１００の体感待ち時間推定部３１１０は、アプリケーション実行時にWebブラウザやクライアント専用アプリケーション等で行われた処理の多重度が、閾値を超える同期処理実行区間を、「体感待ち時間」として推定してもよいし、ユーザ端末３２００において実際の体感待ち時間を別途測定し、それを類似操作抽出装置３１００へ送信することで代替する等の手段を用いることができる。以下に体感待ち時間の推定方法の具体的例を説明する。

ユーザ端末３２００のログ取得部３２２０において、品質劣化判定対象となるユーザ体感待ち時間前後のログを取得する。なおログ取得部３２２０は、一般的な分析ツールを用いる。アプリケーション分析ツールとしては、例えば、Dynatrace（登録商標）、Goole Developer tool（登録商標）、SpeedTracer（登録商標）、ネットワーク分析ツールとしては、例えば、WireShark（登録商標）等である。

ユーザ端末３２００の送信部３２１０は、取得したログを類似操作抽出装置３１００に送信する。なお、ユーザ端末３２００の送信部３２１０は、一般的な装置やプログラム等で代替可能である。

類似操作抽出装置３１００は、ユーザ端末３２００の送信部３２１０からログを取得する。

体感待ち時間推定部３１１０は、取得したログからユーザの体感待ち時間の開始時刻及び終了時刻を推定する。本実施の形態においては開始時刻と終了時刻は、ある時点からの経過秒数で表現するものとする。具体的には、例えば第１の実施の形態で説明したように、Webブラウザ等のアプリケーションで行われた処理の多重度が、閾値を超えている同期処理実行区間を体感待ち時間として推定する。なお、この他に、体感待ち時間の推定方法としては、ユーザ端末３２００とAPサーバ３３００間でやり取りされるHTTPメッセージのレスポンスタイム等、利用者体感待ち時間と近い指標を取得して提示する方法（例えば、CA Application Performance Management http://www.ca.com/jp/products/detail/CA-Application-Performance-Management/overview.aspx）や、ユーザ端末３２００とAPサーバ３３００間でパケットが連続的に送受信されている期間から、利用者の体感待ち時間を推定する方法等（例えば、特許文献１）の既存の技術を用いることが可能である。

ログ切り出し部３１２０は、取得したログの中から、入力操作による体感待ち時間の開始から終了までの体感待ち時間に該当する部分のログを切り出す。具体的には以下の手順で入力操作の体感待ち部分のログを切り出す。

（１）ログ切り出し部３１２０は、体感待ち時間推定部３１１０で推定されたユーザ入力操作の体感待ち時間の開始時刻及び終了時刻を取得する。

（２）ユーザ端末３２００の送信部３２１０から取得したログのうち、体感待ち時間の開始時刻以降に始まり、終了時刻以前に終了しているログを切り出す。

特徴量算出部３１３０は、ログ切り出し部３１２０で切り出されたログから、特徴量を算出する。特徴量は、例えば、ユーザ端末３２００での受信データ量や、処理種別毎に算出した処理多重度のピークの数、高さ、位置が該当し、特徴量として、少なくとも１つ以上を含んでいればよく、これら全てを含んでもよい。また、ユーザ端末３２００からの送信データ量や、処理種別毎の処理数、処理時間の統計値等を、特徴量としてもよい。

上記の特徴量算出部３１３０における、処理多重度のピークの数、高さ、幅、位置を求める具体的な手順は以下の通りである。

（１）アプリケーションログを、一定時間間隔で量子化する。第１、第２の実施の形態と同様に、量子化はアプリケーションログを時系列に一定時間のタイムスロットで区切り、このタイムスロット内で行われたNetwork(データ取得), Scripting （スクリプト実行）, Rendering（画面描画）の各処理について、各処理の実施総数(多重度)を量子化の値として算出する方法を用いる。なお、タイムスロットは例えば、「体感待ち時間の長さ÷50」等の相対時間で定めてもよいし、「0.1秒」等の絶対時間で定めてもよい。また、複数のタイムスロットを定め、それぞれについてタイムスロット毎に、Network, Scripting, Renderingの各処理の多重度を値として量子化してもよい。

（２）上記の（１）で量子化した結果から、例えば図４５に示すように、Network, Scripting, Renderingの各処理の多重度のピークを求める。但し、ピーク終了時刻から次のピーク開始時刻までの間隔がS_inter以下の場合、後者のピークはピーク数に含めない。

なお、ピーク未開始の状態で、初めて処理多重度がP_min1以上になった時刻をピーク開始時刻、ピーク開始後に始めて処理多重度がP_min2以下になった時刻をピーク終了時刻と定めることにする。また、ピーク高がP_max以下のものについても、ピークとして数えないことにする。ここで、ピーク高とは、ピーク開始時刻からピーク終了時刻までの間における、処理の最大多重度のこととする。なお、ピークの開始、終了時刻の考え方はこの他にもいくつか存在する。例えば、量子化グラフの傾きが、ある角度以上になった場合にピーク開始、ある角度以下になった場合にピーク終了とする方法や、グラフが減少から増加に転じた点をピーク開始及び終了と考える方法などある。

なお、上記のP_min1、P_min2、P_max、S_interの値は予め記憶部３１７０に登録しており、必要に応じて適宜修正可能とする。

（３）上記の（２）で求めたNetwork, Scripting, Renderingの各処理の多重度のピークの発生回数であるピーク数、高さ、幅、位置を、下記の通りとする。

（３−１）数：ピークの数を算出する。

（３−２）高さ：ピーク高を（1つ目のピーク高，2つ目のピーク高，…）の形で算出する。

（３−３）幅：ピーク幅を（1つ目のピーク幅，2つ目のピーク幅，…）の形で算出する。なお、ピーク幅は、各ピークにおける（ピークの終了時刻）−（ピークの開始時刻）で定める。

（３−４）位置：ピークの位置を、（1つ目のピーク位置，2つ目のピーク位置，…）の形で算出する。本実施の形態においては、一例として、各ピークのピーク位置を、Network処理の活性化区間と比較した相対位置で表すことと定義するが、ピーク開始時刻と終了時刻の組や、ピーク開始時刻から終了時刻までの間で処理多重度が最大になった時刻等の、絶対位置で表すよう定義してもよい。

ピーク位置を、Network処理の活性化区間と比較した相対位置として表す場合における、相対位置の決定手順を次に示す。

本実施の形態において、各ピークのピーク位置を表す前記相対位置は、Network処理の活性化区間の位置と比較して、「活性化区間より前」「活性化区間の前半」「活性化区間の中盤」「活性化区間の後半」「活性化区間全体」「活性化区間より後」のいずれかに決定される。ここで「活性化区間」とは、一定数以上の処理が行われている時間帯のことを指し、本実施の形態では、一例として、前記活性化開始時刻と前記活性化終了時刻の間の区間として定義する。

具体的には、以下の手順でNetwork処理の活性化区間と比較した相対位置として、各ピーク位置を決定する例を示す。

（１）図４６に示すように、Network処理の活性化区間を求める。ここで、未活性化の状態で、初めて処理多重度がA_min1以上になった時刻を活性化開始時刻、活性化開始後に初めて処理多重度がA_min2以下になり、その後S_continue以上の時間、処理多重度がA_min2を下回ったとき、その時刻を活性化終了時刻と定めることにする。なお、A_min1，A_min2，S_continueの値は予め記憶部１７に登録しており、必要に応じて適宜修正可能とする。

（２）各ピークに対し、Network処理の活性化区間との位置関係を、図４７A〜図４８Cに示す５パターンに分類する。

（ア）「活性化区間より前」：ピーク終了時刻が、Network処理の活性化開始時刻よりも前であるとき；（図４７Ａ）
（イ）「活性化区間より後」：ピーク開始時刻が、Network処理の活性化終了時刻よりも後であるとき；（図４７Ｂ）
（ウ）「活性化区間の前半」：（ア）（イ）以外で、ピーク終了時刻が、Network処理の活性化区間の前半1/3よりも前であるとき；（図４８Ａ）
（エ）「活性化区間の後半」：（ア）（イ）以外で、ピーク開始時刻が、Network処理の活性化区間の後半1/3よりも後であるとき；（図４８Ｂ）
（オ）「活性化区間の中盤」：（ア）〜（エ）以外のとき；（図４８Ｃ）
（３） 前記（２）で求めた、各ピークとNetwork処理の活性化区間との位置関係を、（1つ目のピークの位置関係，2つ目のピークの位置関係，…）の形で算出する。ただし、次の（ａ）〜（ｃ）に該当する場合は、以下の通りに出力することとする。

（ａ）（ウ）〜（オ）に当てはまるピークがそれぞれ1つ以上あるとき、もしくは（ウ）〜（オ）に当てはまるピークの幅の合計が、Network処理の活性化区間幅の8割を超えるとき；
→ 上記に該当するピークの位置関係を、まとめて「Network処理の活性化区間全体」と出力する。

（ｂ）（ａ）以外で、（ウ）（オ）に当てはまるピークがそれぞれ1つ以上あるとき：
→ 上記に該当するピークの位置関係を、まとめて「活性化区間の前半」と出力する。

（ｃ）（ａ）以外で、（エ）（オ）に当てはまるピークがそれぞれ1つ以上あるとき：
→ 上記に該当するピークの位置関係を、まとめて「活性化区間の後半」と出力する。例えば、上記（２）で1つ目のピークが「活性化区間より前」、2つ目のピークが「活性化区間の中盤」、3つ目のピークが「活性化区間の後半」に分類された場合は、（ｂ）（ｃ）に該当するので、出力は（「活性化区間より前」，「活性化区間の後半」）となる。

上記のように、特徴量算出部３１３０では、ユーザ端末処理の多重度グラフや受信データ量から算出した値のみを特徴量とするため、多様なアプリケーションに適用可能であり、顧客の個人情報に触れることもない。

類似度算出部３１４０では、特徴量算出部３１３０で算出された特徴量と、記憶部３１７０に保存されている過去の特徴量、予め定めた類似度関数を用いて、保存されている過去に特徴量全てに対し算出された特徴量との類似度を算出する。具体的には、算出した特徴量Sと、保存されている過去の特徴量Rを類似度関数SM(S,R)に代入して得られた値を、類似度として算出する。ここで、「類似度関数」は、各特徴量間の類似度を表す関数と、それらを重みづけする関数から構成される。例えば、通信処理量のピークが高い場合には、通信処理量のピークの類似度に大きく重み付けし、ピークが低い場合には、その他の特徴量の類似度を大きく重みづけする。

上記のように、類似度算出部３１４０では、グラフから幾つかの特徴量を算出し、各特徴量間の類似度を求め、重み付けて足し合わせることとで、特徴量全体の類似度を算出することにより、グラフ本体の情報を保持する必要がなくなるため、保存データ量の削減に貢献できる。また、グラフを各時刻で比較するのではなく、特徴量だけを比較すればよいので、類似度算出時の計算量を削減することもできる。

類似操作抽出部３１５０では、過去の特徴量のうち、類似度が抽出閾値を超えている特徴量と組となって保存されている識別番号を抽出する。なお、抽出閾値は、"類似度が保存されている過去の特徴量全体の上位2％に含まれる場合"や、"上位100個に含まれる場合"というように相対値で定めてもよいし、"類似度が80を越えた場合"というように絶対値で定めてもよい。

保存部３１６０は、算出された記憶部３１７０に未保存の特徴量に対して、識別番号を与え、その番号と特徴量を記憶部３１７０に保存する。識別番号は、通算の特徴量数で定めてもよいし、操作実施時の体感待ち時間の開始時刻等で定めてもよい。

なお、識別番号と特徴量だけでなく、切り出したログやそのログから求めた平均スループットや平均処理時間等の統計値、体感待ち時間についても該当する識別番号に対応付けて記憶部３１７０に保存し、これらを識別番号と同時に抽出してもよい。

ここで、識別番号とは、一意の値であり、過去に保存された特徴量と算出された未保存の特徴量とが同一の値の場合であっても、新たに保存される特徴量には全く新しい一意の識別番号が付与される。

また、ログに対し、算出される特徴量の種類は１種類以上であり、いずれも実数で表されるものとする。この算出された１以上の特徴量の値は、算出元のデータであるログに対応付けられる特徴量のベクトルを構成する各構成要素の値であり、記憶部３１７０に保存される特徴量は、当該全構成要素から構成された特徴量のベクトル全体を意味するものであり、当該特徴量の値から構成される特徴量のベクトル全体に対して一意に識別番号を付与するようにしてもよい。

本実施例では、実行されるアプリケーションは、Webブラウザを例として説明する。以下の動作は、前述の図４４のフローチャートに基づいて説明する。以下では、ステップ３３００以降について説明する。

ステップ３３００）ログ切り出し：
ログ切り出し部３１２０では、ユーザ端末３２００から取得したログと体感待ち時間推定部３１１０において推定された体感待ち時間を入力とする。例えば、図４９に示すアプリケーションログ、図５０に示すネットワークログと、図５１に示す推定体感待ち時間が入力されたとする。ログ切り出し部３１２０では、図５２に示すアプリケーションログと、図５３に示すネットワークログを切り出す。ここで切り出されるログは、体感待ち時間により、開始時刻が13.7秒以降かつ終了時刻が15.8秒以前のログである。

ステップ３４００)特徴量算出：
特徴量算出部３１３０にステップ３３００で切り出されたログ(図５２、図５３)が入力されたとする。

Ａ.受信データ量S_thr
ネットワークログから、ユーザ端末３２００が受信したデータ量は、
507.97 + 304.45 = 812.42(Kbit) = 101.55(KB)
と与えられる。

Ｂ．特徴量算出：処理種別ごとの処理多重度のピークの数、高さ、幅、位置
本実施例では、タイムスロットとして「体感待ち時間の長さ÷50」の場合と「体感待ち時間の長さ÷10」の場合のそれぞれについて処理種別毎の処理多重度の値で量子化し、前者については、Network処理のピーク数S_{nw_n}とRendering処理のピーク数S_{ren_n}、Network処理のピーク高S_{nw_h}, S'_{nw_h}、Network処理のピーク幅S_{nw_w}、Scripting処理のピーク位置S_{scr_p}の6つ、後者についてはNetwork処理のピーク高S_{nw_h_10}のみを算出する。上記において、「体感待ち時間÷50」のタイムスロットで求めた多重度グラフだけでは判定が難しい操作があるため、「体感待ち時間÷10」のタイムスロットで求めた多重度グラフの情報を補足として用いている。なお、「体感待ち時間÷10」の場合は、全ての特徴量を算出せず、最も支配的であるネットワーク処理のピーク高のみを求めるものとする。

本実施例では、後者「体感待ち時間÷10」のタイムスロットで求めた多重度グラフの情報は、「体感待ち時間÷50」のタイムスロットで求めた多重度グラフによる判定において、付加的情報として用いるものとする．このため、後者については特徴量すべてではなく、最も支配的である(影響の大きい) Network処理のピーク高のみを算出し、付加的情報とする。

タイムスロットを「体感待ち時間の長さ÷50」とした場合の量子化結果を図５４に、タイムスロットを「体感待ち時間の長さ÷10」とした場合の量子化結果を図５５に示す。

B−1：Network処理S_{nw_n}とRendering処理のピーク数S_{ren_n}
Network処理ではS_inter=5, P_min1=2, P_min2=2, P_max=2, Rendering処理ではS_inter=5, P_min1=0, P_min2=0, P_max =1とすると、図５４の場合、Network処理のピーク数S_{nw_n}は2、Rendering処理のピーク数S_{ren_n}は0と与えられる。

Ｂ−2：Network処理のピーク高S_{nw_h}, S'_{nw_h}, S_{nw_h_10}
図５４の場合、S_inter=5, P_min1=2, P_min2=2, P_max=2とするとNetwork処理のピーク高S_{nw_h}は (5,14)、S_inter=5, P_min1=0, P_min2=0, P_max=1とするとNetwork処理のピーク高S'_{nw_h}は (14)である。当該例において、P_min1=P_min2=0としているため、多重度がはじめ0以上になったときにピーク開始、ピーク開始後に始めて0以下になったときにピーク終了とする。また、P_max＝１であるから、ピーク高が１未満のピークは無視する。よって、図５４でピークとして数えられるのは、時刻13に始まって、時刻45で終了するピークのみで、このピークの高さは"14"となる。図５５の場合、S_inter=5, P_min1=2, P_min2=2, P_max=2とすると、ピーク高S_{nw_h_10}は (15)と与えられる。

B−3：Network処理のピーク幅S_{nw_w}
図５４の場合、ピーク幅の組S_{nw_w}は、(4,15)と与えられる。

B−4：Scripting処理のピーク位置S_{scr_p}
(0) Scripting処理のピーク：
S_inter=5, P_min1=1, P_min2=0, P_max=0とすると、図５４におけるScripting処理のピークは1つで、開始時刻は21、終了時刻は47で与えられる。

(1) Network処理の活性化区間：
S_continue=5, A_min1=1, A_min2=0とすると、図５４におけるNetwork処理の活性化開始時刻は14、活性化終了時刻は45と与えられる。

(2) Scripting処理の各ピークと、Network処理の活性化区間との位置関係
(0)で求めたScripting処理の各ピークと、(1)で求めたNetwork処理の活性化区間との位置関係は、（オ）「活性化区間の中盤」と与えられる。

(3) Scripting処理のピーク位置S_{scr_p}：
(2)より、S_{scr_p}は（「活性化区間の中盤」）と与えられる。

ステップ３５００） 類似度算出
類似度算出部３１４０に、ステップ３４００で求めた特徴量の組S=(S_thr, S_{nw_n}, S_{ren_n}, S_{nw_h}, S'_{nw_h}, S_{nw_h_10}, S_{nw_w}, S_{scr_p})と、図５６に示すように、記憶部３１７０に保存されている特徴量の組R=(R_thr, R_{nw_n}, R_{ren_n}, R_{nw_h}, R'_{nw_h}, R_{nw_h_10}, R_{nw_w}, R_{scr_p})、下記に示す類似度関数が与えられたとする。

類似度関数SM(S, R) = A(S_{nw_h}, R_{nw_h}, S'_{nw_h}, R'_{nw_h})*
{b(S_{nw_h}) * B(S_{nw_n}, R_{nw_n}, S_{nw_h}, R_{nw_h})+
c(S_{nw_h}) * C(S_thr, R_thr) +
d(S_{nw_h}) * D(S_{ren_n}, R_{ren_n}) +
e(S_{nw_h}) * E(S_{scr_p}, R_{scr_p}) +
f(S_{nw_h}) * F(S_{nw_h_10}, R_{nw_h_10}) +
g(S_{nw_h}) * G(S_{nw_w}, R_{nw_w}, S_{nw_h}, R_{nw_h})}
ただし、各特徴量の類似度関数A〜Gと、重みづけ関数 b〜gは下記の通り定められているとする。

A(S_{nw_h}, R_{nw_h}, S'_{nw_h}, R'_{nw_h}) =
(i) 1 (0 < s_{nw_h} < 5かつ、r_{nw_h}*0.8 ≦ s_{nw_h} ≦ r_{nw_h}*1.2またはr_{nw_h}-1 ≦ s_{nw_h}
≦ r_{nw_h}+1の
(ii) 1 (s_{nw_h} = 0, s'_{nw_h} > 0かつ、r_{nw_h}=0, r'_{nw_h} > 0のとき)
1 (s_{nw_h} = s'_{nw_h} = 0かつ、r'_{nw_h} = r_{nw_h}=0のとき)
(iii) 0 (それ以外)
ここで、s_{nw_h}, s'_{nw_h}, r_{nw_h}, r'_{nw_h}は、それぞれS_{nw_h}, S'_{nw_h}, R_{nw_h}, R'_{nw_h}の最大値
B(S_{nw_n}, R_{nw_n}, S_{nw_h}, R_{nw_h})=
(i) 1 (S_{nw_n} = R_{nw_n} = 1のとき)
(ii) 1 (S_{nw_n}, R_{nw_n} > 1で、かつ、s_{nw_h2}*0.9 ≦ r_{nw_h2} ≦ s_{nw_h2}*1.1またはs_{nw_h2}-1 ≦
r_{nw_h2} ≦ s_{nw_h2}+1のとき)
(iii) 0 (それ以外)
ここで、s_{nw_h2}, r_{nw_h2}は、それぞれS_{nw_h}, R_{nw_h}の2番目に大きい値
C(S_thr, R_thr) =
(i) 1 (S_thr*0.8 ≦ R_thr ≦ S_thr*1.2のとき)
(ii) 0（それ以外）
D(S_{ren_n}, R_{ren_n}) =
(i) 1 (S_{ren_n}, R_{ren_n} ≧ 1またはS_{ren_n} = R_{ren_n} = 0のとき)
(ii) 0（それ以外）
E(S_{scr_p}, R_{scr_p}) =
(i) 1 (S_{scr_p} = R_{scr_p}のとき)
(ii) 1 (S_{scr_p}, R_{scr_p}が共に「活性化区間より前」を含むとき、または、共に「活性化区間より後」を含むとき)
(iii) 0.3 ((i)以外で、S_{scr_p}, R_{scr_p}が共に「活性化区間より前」と「活性化区間より後」を含まないとき)
(iv) 0 (それ以外)
F(S_{nw_h_10}, R_{nw_h_10}) =
(i) 1 (s_{nw_h_10}*0.9 ≦ r_{nw_h_10} ≦ s_{nw_h_10}*1.1またはs_{nw_h_10}-1 ≦ r_{nw_h_10} ≦
s_{nw_h_10}+1のとき)
(ii) 0（それ以外）
ここで、s_{nw_h_10}, r_{nw_h_10}は、それぞれS_{nw_h_10}, R_{nw_h_10}の最大値
G(S_{nw_w}, R_{nw_w}, S_{nw_h}, R_{nw_h}) =
(i) 1 (s_{nw_w}*0.7 ≦ r_{nw_w} ≦ s_{nw_w}*1.3またはs_{nw_w}-1 ≦ r_{nw_w} ≦ s_{nw_w}+1のとき)
(ii) 0 (それ以外)
ここで、s_{nw_w}, r_{nw_w}は、それぞれS_{nw_w}, R_{nw_w}のうち、ピーク高が最大になったときのピーク幅
b(S_{nw_h}) =
(i) 30 (s_{nw_h} ≧ 5のとき)
(ii) 20 (0 < s_{nw_h} < 5のとき)
(iii) 0 (s_{nw_h} = 0のとき)
c(S_{nw_h}) =
(i) 20 (s_{nw_h} ≧ 5のとき)
(ii) 20 (0 < s_{nw_h} < 5のとき)
(iii) 40 (s_{nw_h} = 0のとき)
d(S_{nw_h}) =
(i) 10 (s_{nw_h} ≧ 5のとき)
(ii) 10 (0 < s_{nw_h} < 5のとき)
(iii) 30 (s_{nw_h} = 0のとき)
e(S_{nw_h}) =
(i) 10 (s_{nw_h} ≧ 5のとき)
(ii) 20 (0 < s_{nw_h} < 5のとき)
(iii) 30 (s_{nw_h} = 0のとき)
f(S_{nw_h}) =
(i) 20 (s_{nw_h} ≧ 5のとき)
(ii) 20 (0 < s_{nw_h} < 5のとき)
(iii) 0 (s_{nw_h} = 0のとき)
g(S_{nw_h}) =
(i) 10 (s_{nw_h} ≧ 5のとき)
(ii) 10 (0 < s_{nw_h} < 5のとき)
(iii) 0 (s_{nw_h} = 0のとき)
このとき、例えば、ステップ３４００で求めた特徴量と、図５６のNo.1の特徴量の類似度は、1*{30 * 1 + 20 * 1 + 10 * 1 + 10 * 0 + 20 * 1 + 10 * 1} = 90と与えられる。

ステップ３６００） 類似操作抽出
類似操作抽出部３１５０は、記憶部３１７０に保存されている特徴量すべてに対して、ステップ３４００で求められた特徴量との類似度を高い順に並べる。この結果を図５７に示す。図５７において、記憶部３１７０に保存されている特徴量は275個であるので、類似度が上位2%に含まれる特徴量は、No. 1, 148, 264, 164, 56の5個である。したがって、この5個を類似操作として抽出する。

＜本実施の形態の評価＞
本実施の形態に係る技術を用いた類似操作の特定結果に対する妥当性の評価結果は次のとおりである。

類似操作の特定結果の妥当性の評価対象は、図５８に示す条件下で実施した、計276個の操作とその特徴量とする。前記276件の評価対象となる操作の中から選んだ任意の２つの操作について、本実施の形態に係る技術を用いて類似操作であるか否かの特定を行い、全ての操作の組合せ（₂₇₆C₂=37950）に対し、正しい類似操作特定結果が得られた割合を、閾値ごとに正答率として算出した。ここで、任意の2つの操作とは、276個の操作の中から、操作の種類や測定条件に関わらず、無作為に選んだ2つの操作を指す。例えば、「操作の種類：Ａ，ネットワーク負荷：なし，端末負荷：なし，測定回数：１回目」という操作と「操作種類：Ｂ，ネットワーク負荷：あり，端末負荷：あり，測定回数：３回目」という操作を選ぶ場合や、「操作の種類：Ａ，ネットワーク負荷：なし，端末負荷：なし，測定回数：１回目」という操作と「操作種類：Ａ，ネットワーク負荷：あり，端末負荷：あり，測定回数：３回目」という操作を選ぶ場合などがある。前者は、操作の種類が異なるため類似操作ではないという結果が導出されれば正解となる。後者は、測定条件は異なるが操作の種類は同じであるので類似操作であるという結果が導出されれば正解となる。なお、類似度の閾値は50〜150の間を20刻みで設定した。

評価対象となる操作全体に対し、任意の2つの操作を抽出し、本実施の形態の技術により、その2つの操作が類似操作であるか否かを判定した結果が正解である確率を、閾値ごとに確認した結果を図５９に示す。図５９に示すように、類似操作と全ての閾値で正答率は80％を超えており、本実施の形態の技術によって精度よく類似操作を特定できることを確認できた。

なお、図４２または図４３に示す類似操作抽出装置の各構成要素の動作をプログラムとして構築し、類似操作抽出装置として利用されるコンピュータにインストールして実行させる、または、ネットワークを介して流通させることが可能である。

より詳細には、図４２または図４３に示す類似操作抽出装置は、コンピュータに、本実施の形態で説明する処理内容を記述したプログラムを実行させることにより実現可能である。より詳細には、類似操作抽出装置の各部が有する機能は、当該類似操作抽出装置を構成するコンピュータに内蔵されるＣＰＵやメモリ、ハードディスクなどのハードウェア資源を用いて、各部で実施される処理に対応するプログラムを実行することによって実現することが可能である。当該プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、当該プログラムをインターネットや電子メールなど、ネットワークを通して提供することも可能である。

例えば、本実施の形態では、コンピュータを、アプリケーション実行にあたり、入力として与えられた操作である入力操作と類似する操作を抽出する類似操作抽出装置として機能させるための類似操作抽出プログラムであって、コンピュータを、
アプリケーションログとネットワークログのいずれか一方のみ、もしくは両方の組み合わせから切り出されたユーザ体感待ち時間に対応するログに基づき、特徴量を算出する特徴量算出手段、
算出した前記特徴量と過去に記憶手段に保存された特徴量、及び予め定められた類似度関数に基づき前記特徴量と前記過去に保存された特徴量との類似度を算出する類似度算出手段、として機能させるための類似操作抽出プログラムが提供される。

なお、本発明は、上記の第１〜第３の実施の形態に限定されることなく、特許請求の範囲内において種々変更・応用が可能である。

本国際出願は２０１２年３月３０日に出願した日本国特許出願２０１２−８２８０２号、２０１２年３月３０日に出願した日本国特許出願２０１２−８２８０３号、及び２０１２年１０月２４日に出願した日本国特許出願２０１２−２３４７２７号に基づく優先権を主張するものであり、日本国特許出願２０１２−８２８０２号、日本国特許出願２０１２−８２８０３号、及び日本国特許出願２０１２−２３４７２７号の全内容を本国際出願に援用する。

１１００ 品質推定装置
１１０１ 受信ログ記憶部
１１１０ 受信部
１１２０ 待ち時間推定部
１１３０ 推定結果格納・表示部
１２００ 利用者端末
１２１０ Webブラウザ
１２２０ ブラウザログ取得部
１２３０ 送信部
１３００ ブラウザアプリケーションサーバ
１３１０ HTTPサーバ
１３２０ コンテンツ
２１００ 端末ボトルネック判定装置
２１０１ 受信ログ記憶部
２１０２ リファレンスログ記憶部
２１０３ 連続領域長経験累積分布ＤＢ
２１１０ 受信部
２１２０ ボトルネック判定部
２１３０ 判定結果格納・表示部
２１４０ 連続領域長経験累積分布ＤＢ生成部
２２００ 利用者端末
２２１０ Webブラウザ
２２２０ ブラウザログ取得部
２２３０ 送信部
２３００ ブラウザアプリケーションサーバ
２３１０ HTTPサーバ
２３２０ コンテンツ
３１００ 類似操作抽出装置
３１１０ 体感待ち時間推定部
３１２０ ログ切り出し部
３１３０ 特徴量算出部
３１４０ 類似度算出部
３１５０ 類似操作抽出部
３１６０ 保存部
３１７０ 記憶部
３２００ ユーザ端末
３２１０ 送信部
３２２０ ログ取得部
３２３０ Webブラウザ
３３００ APサーバ
３３１０ HTTPサーバ
３３２０ コンテンツ

Claims (26)

1. 利用者端末におけるアプリケーションの利用者の体感待ち時間を推定するための利用者体感品質推定装置であって、
   前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を推定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段と、
   前記受信ログ記憶手段から前記推定対象ログを読み出し、該データの継続時間が、所定の短時間処理閾値より短い、または、所定の長時間閾値より長いログを除外したログを出力するログ除外手段と、
   前記ログ除外手段から出力されたログに対し、一定時間のタイムスロット内で行われた各処理の個数を多重度として算出する量子化手段と、
   前記量子化手段で量子化されたデータから連続領域を抽出する連続領域抽出手段と、
   を有し、
   前記連続領域抽出手段は、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別せずに連続領域を抽出する第１の連続領域抽出手段、または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別して連続領域を抽出する第２の連続領域抽出手段と、
   を含むことを特徴とする利用者体感品質推定装置。
2. 前記第１の連続領域抽出手段は、
   スライディングウィンドウ内のタイムスロットのうち少なくとも1つのタイムスロットにおいて、検知閾値以上の処理があれば、連続領域内と判定する処理を行い、連続領域内との判定がなされたスライディングウィンドウが連続した区間を連続領域とする第１の評価Ａ手段、
   または、
   あるタイムスロットを始点とするスライディングウィンドウ長の区間内における、検知閾値を超えるタイムスロット数の存在比率が所定の連続判定閾値を超える場合に、当該タイムスロットを連続領域内であると判定する処理を各タイムスロットを始点として行い、連続領域内であると判定された始点のタイムスロットが連続する領域を連続領域とする第２の評価Ａ手段
   を含む請求項１記載の利用者体感品質推定装置。
3. 前記第２の連続領域抽出手段は、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、各処理の連続領域の和集合を連続領域とする第１の評価Ｂ手段、
   または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、前記データ取得処理の連続領域、当該データ取得処理の連続領域に隣接する前記スクリプト実行処理の連続領域、及び当該スクリプト実行処理の連続領域に隣接する前記画面描画処理の連続領域を抽出する第２の評価Ｂ手段、
   または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、前記データ取得処理の連続領域、及び当該データ取得処理の連続領域に隣接する前記画面描画処理の連続領域を抽出し、更に、前記スクリプト実行処理の連続領域、及び当該スクリプト実行処理の連続領域に隣接する前記画面描画処理の連続領域を抽出する第３の評価Ｂ手段
   を含む請求項１記載の利用者体感品質推定装置。
4. 前記連続領域抽出手段で抽出された連続領域を、
   前記連続領域抽出手段で抽出された前記連続領域の最終スロットと、次の連続領域の先頭スロットが連続する場合には、一つの連続領域とし、
   前記一つの連続領域が、所定の閾値以下の場合は当該一つの連続領域を削除する、
   または、
   前記一つの連続領域が、所定の閾値以上場合には当該一つの連続領域を削除する、
   ことにより連続領域を整形する連続領域整形手段を更に有する
   請求項１記載の利用者体感品質推定装置。
5. 利用者端末におけるアプリケーションの利用者の体感待ち時間を推定するための利用者体感品質推定方法であって、
   データ受信手段が、前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を推定対象ログとして取得して受信ログ記憶手段に格納するデータ受信ステップと、
   ログ除外手段が、前記受信ログ記憶手段から前記推定対象ログを読み出し、該データの継続時間が、所定の短時間処理閾値より短い、または、所定の長時間閾値より長いログを除外したログを出力するログ除外ステップと、
   量子化手段が、前記ログ除外ステップで出力されたログに対し、一定時間のタイムスロット内で行われた各処理の個数を多重度として算出する量子化ステップと、
   連続領域抽出手段が、前記量子化ステップで量子化されたデータから連続領域を抽出する連続領域抽出ステップと、
   を行い、
   前記連続領域抽出ステップにおいて、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別せずに連続領域を抽出する第１の連続領域抽出ステップと、または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理を区別して連続領域を抽出する第２の連続領域抽出ステップと、
   を含むことを特徴とする利用者体感品質推定方法。
6. 前記第１の連続領域抽出ステップにおいて、
   スライディングウィンドウ内のタイムスロットのうち少なくとも1つのタイムスロットにおいて、検知閾値以上の処理があれば、連続領域内と判定する処理を行い、連続領域内との判定がなされたスライディングウィンドウが連続した区間を連続領域とする第１の評価Ａステップ、
   または、
   あるタイムスロットを始点とするスライディングウィンドウ長の区間内における、検知閾値を超えるタイムスロット数の存在比率が所定の連続判定閾値を超える場合に、当該タイムスロットを連続領域内であると判定する処理を各タイムスロットを始点として行い、連続領域内であると判定された始点のタイムスロットが連続する領域を連続領域とする第２の評価Ａステップを行う
   請求項５記載の利用者体感品質推定方法。
7. 前記第２の連続領域抽出ステップにおいて、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、各処理の連続領域の和集合を連続領域とする第１の評価Ｂステップ、
   または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、前記データ取得処理の連続領域、当該データ取得処理の連続領域に隣接する前記スクリプト実行処理の連続領域、及び当該スクリプト実行処理の連続領域に隣接する前記画面描画処理の連続領域を抽出する第２の評価Ｂステップ、
   または、
   前記データ取得、前記スクリプト実行、前記画面描画の各処理に対して、連続領域を抽出し、前記データ取得処理の連続領域、及び当該データ取得処理の連続領域に隣接する前記画面描画処理の連続領域を抽出し、更に、前記スクリプト実行処理の連続領域、及び当該スクリプト実行処理の連続領域に隣接する前記画面描画処理の連続領域を抽出する第３の評価Ｂステップ
   を行う請求項５記載の利用者体感品質推定方法。
8. 前記連続領域抽出ステップで抽出された連続領域を、
   前記連続領域抽出ステップで抽出された前記連続領域の最終スロットと、次の連続領域の先頭スロットが連続する場合には、一つの連続領域とし、
   前記一つの連続領域が、所定の閾値以下の場合は当該一つの連続領域を削除する、
   または、
   前記一つの連続領域が、所定の閾値以上場合には当該一つの連続領域を削除する、
   ことにより連続領域を整形して出力する連続領域整形ステップを更に行う、
   請求項５記載の利用者体感品質推定方法。
9. コンピュータを、
   請求項１乃至４のいずれか１項に記載の利用者体感品質推定装置の各手段として機能させるための利用者体感品質推定プログラム。
10. アプリケーションサーバから提供されるアプリケーションのサービス利用時に、品質劣化要因が利用者端末にあるか否かを判定するための品質劣化要因判定装置であって、
    前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を判定対象ログとして取得して受信ログ記憶手段に格納するデータ受信手段と、
    前記利用者端末で行われるアプリケーションに対する操作と同様の操作を行った場合のリファレンスログ、または、スクリプト実行や画面描画の処理の連続領域長の経験累積分布のデータと、前記判定対象ログを比較し、評価値を求め、該評価値の合計値と予め設定されている閾値との比較結果に基づいて、該利用者端末に品質劣化要因があるか否かを判定するボトルネック判定手段と、
    を有することを特徴とする品質劣化要因判定装置。
11. 前記ボトルネック判定手段は、
    前記リファレンスログと前記判定対象ログのそれぞれ対応する処理の統計値を比較して、比較結果に応じて点数を付与し、該点数の合計値を求め、該合計値が、利用端末にボトルネックが存在することを意味する少なくとも１つの閾値を超える場合に利用端末にボトルネックがあると判定する手段を含む
    請求項１０記載の品質劣化要因判定装置。
12. 通常利用されるであろう様々な操作を繰り返したスクリプト実行または画面描画の処理のログから該スクリプト実行または画面描画の処理の連続領域長の経験累積分布を、連続領域長記憶手段に登録する連続領域長ＤＢ生成手段を更に有し、
    前記ボトルネック判定手段は、
    前記判定対象ログに含まれる連続領域長データ数を累積比率化し、該累積比率化された判定対象ログのデータについて、前記連続領域長記憶手段の連続領域長の経験累積分布に対する上下関係を判定することによって利用者端末におけるボトルネックを判定する手段を含む
    請求項１０記載の品質劣化要因判定装置。
13. 通常利用されるであろう様々な操作を繰り返したスクリプト実行または画面描画の処理のログから該スクリプト実行または画面描画の処理の連続領域長の経験累積分布を、連続領域長記憶手段に登録する連続領域長ＤＢ生成手段を更に有し、
    前記ボトルネック判定手段は、
    前記判定対象ログに含まれる連続領域長データ数を累積比率化し、該累積比率化された判定対象ログのデータについて、前記連続領域長記憶手段の連続領域長の経験累積分布を参照し、仮説検定を行うことにより、ボトルネックを判定する手段を含む
    請求項１０記載の品質劣化要因判定装置。
14. アプリケーションサーバから提供されるアプリケーションのサービス利用時に、品質劣化要因が利用者端末にあるか否かを判定するための品質劣化要因判定方法であって、
    データ受信手段が、前記利用者端末において推定対象期間に行われたデータ取得、スクリプト実行、画面描画の各処理の継続時間を判定対象ログとして取得して受信ログ記憶手段に格納するデータ受信ステップと、
    ボトルネック判定手段が、前記利用者端末で行われるアプリケーションに対する操作と同様の操作を行った場合のリファレンスログ、または、スクリプト実行や画面描画の処理の連続領域長の経験累積分布のデータと、前記判定対象ログを比較し、評価値を求め、該評価値の合計値と予め設定されている閾値との比較結果に基づいて、該利用者端末に品質劣化要因があるか否かを判定するボトルネック判定ステップと、
    を行うことを特徴とする品質劣化要因判定方法。
15. 前記ボトルネック判定ステップにおいて、
    前記リファレンスログと前記判定対象ログのそれぞれ対応する処理の統計値を比較して、比較結果に応じて点数を付与し、該点数の合計値を求め、該合計値が、利用端末にボトルネックが存在することを意味する少なくとも１つの閾値を超える場合に利用端末にボトルネックがあると判定する
    請求項１４記載の品質劣化要因判定方法。
16. 通常利用されるであろう様々な操作を繰り返したスクリプト実行または画面描画の処理のログから該スクリプト実行または画面描画の処理の連続領域長の経験累積分布を連続領域長記憶手段に登録する連続領域長ＤＢ生成ステップを更に行い、
    前記ボトルネック判定ステップにおいて、
    前記判定対象ログに含まれる連続領域長データ数を累積比率化し、該累積比率化された判定対象ログのデータについて、前記連続領域長記憶手段の連続領域長の経験累積分布に対する上下関係を判定することによって利用者端末におけるボトルネックを判定する
    請求項１４記載の品質劣化要因判定方法。
17. 通常利用されるであろう様々な操作を繰り返したスクリプト実行または画面描画の処理のログから該スクリプト実行または画面描画の処理の連続領域長の経験累積分布を連続領域長記憶手段に登録する連続領域長ＤＢ生成ステップを更に行い、
    前記ボトルネック判定ステップにおいて、
    前記判定対象ログに含まれる連続領域長データ数を累積比率化し、該累積比率化された判定対象ログのデータについて、前記連続領域長記憶手段の連続領域長の経験累積分布を参照し、仮説検定を行うことにより、ボトルネックを判定する
    請求項１４記載の品質劣化要因判定方法。
18. コンピュータを、
    請求項１０乃至１３のいずれか１項に記載の品質劣化要因判定装置の各手段として機能させるための品質劣化要因判定装置プログラム。
19. アプリケーション実行にあたり、入力として与えられた操作である入力操作と類似する操作を抽出する類似操作抽出装置であって、
    アプリケーションログとネットワークログのいずれか一方のみ、もしくは両方の組み合わせから切り出されたユーザ体感待ち時間に対応するログに基づき、特徴量を算出する特徴量算出手段と、
    算出した前記特徴量と過去に記憶手段に保存された特徴量、及び予め定められた類似度関数に基づき前記特徴量と前記過去に保存された特徴量との類似度を算出する類似度算出手段と、
    を有することを特徴とする類似操作抽出装置。
20. 前記類似度算出手段によって算出された類似度から、入力操作と類似した操作を抽出する類似操作抽出手段を更に有する
    請求項１９記載の類似操作抽出装置。
21. 前記特徴量に識別番号を与え、前記識別番号と前記特徴量を前記記憶手段に保存する手段を更に有する
    請求項１９または２０記載の類似操作抽出装置。
22. 前記特徴量算出手段は、
    前記アプリケーションログから算出した値、もしくは、前記ネットワークログから算出した値、もしくはその双方を前記特徴量とする
    請求項１９記載の類似操作抽出装置。
23. 前記類似度算出手段は、
    前記特徴量算出手段で得られた前記特徴量と前記過去に保存された特徴量間の類似度を求め、重み付けして足し合わせた値を前記類似度とする手段を含む
    請求項１９記載の類似操作抽出装置。
24. アプリケーション実行にあたり、入力として与えられた操作である入力操作と類似する操作を抽出する類似操作抽出方法であって、
    特徴量算出手段、類似度算出手段、記憶手段を有する装置において、
    前記特徴量算出手段が、アプリケーションログとネットワークログのいずれか一方のみ、もしくは両方の組み合わせから切り出されたユーザ体感待ち時間に対応するログに基づき、特徴量を算出する特徴量算出ステップと、
    前記類似度算出手段が、前記特徴量算出ステップで算出された前記特徴量と過去に前記記憶手段に保存された特徴量、及び予め定められた類似度関数に基づき前記特徴量と前記過去に保存された特徴量との類似度を算出する類似度算出ステップと、
    を行うことを特徴とする類似操作抽出方法。
25. 類似操作抽出手段を更に有する装置において、
    前記類似操作抽出手段が、前記類似度算出ステップによって算出された類似度から、入力操作と類似した操作を抽出するステップを、更に行う
    請求項２４記載の類似操作抽出方法。
26. コンピュータを、
    請求項１９乃至２３のいずれか１項に記載の類似操作抽出装置の各手段として機能させるための類似操作抽出プログラム。

Images