JP6374837B2 - 被疑箇所推定装置及び被疑箇所推定方法 - Google Patents

Description

本発明は、被疑箇所推定装置及び被疑箇所推定方法に関する。

スマートフォンやタブレット端末の普及に伴い、様々なモバイルサービスが利用されるようになってきた。その中でも、特にＷｅｂアプリケーションサービスは多くのユーザが利用しており、需要が高いサービスである。

一方で、モバイル環境においては、常時安定した品質でサービスを受けることが難しい。ユーザの利用中に品質劣化、例えば、要求したページの表示時間が遅いなどが発生した場合、劣化被疑箇所を特定するのは困難である。現在のサービスは、サービス提供事業者、プラットフォーム事業者、通信事業者、端末メーカと、各種事業者に跨って構成されるためである。

定常的にＷｅｂの性能監視を行う技術は現在までに複数提案されている。例えば、非特許文献１では、Ｗｅｂにおける端末処理の比重の高まりが課題として認識され、ブラウザの端末処理（レンダリング、スクリプティング）及びネットワーク処理のログを出力し、分析サーバにおける独自のアルゴリズムにより、表示待ち時間及び表示待ち時間内に占める端末処理時間の比率の算出が実現されている。更に、当該比率に基づいて、品質劣化時の被疑箇所の推定が実現されている。非特許文献２では、所定時間間隔の端末の上り下り方向の通信量を入力として、Ｗｅｂ閲覧時の表示待ち時間推定を実現した。また、非特許文献３では、ユークリッド空間内に特定される点の領域で被疑箇所を選定する技術が実現されている。

山本、中村、本多、池上、高橋：「ブラウザベースアプリケーションの品質要因考察」、信学技報、CQ2012-20, vol.112, no.119, pp.17--22, 2012 本多他、「通信量時系列に基づくWeb表示待ち時間推定」、電子情報通信学会ソサエティ大会2014 本多他、「Navigation Timing APIを用いたWeb品質劣化切り分け」、コミュニケーションクオリティ研究会2014.

しかしながら、非特許文献２では、被疑箇所の推定までは行うことができず、非特許文献１では、被疑箇所の推定に関して、端末側及び網側の２分類でしか切り分けができないことに加え、双方に被疑がある場合について判定することが困難である。また、非特許文献３では、端末・網内・サーバの３分類で切り分けができるが、ユークリッド空間内に特定される点の領域で被疑箇所を選定する技術であるため、一連のフローでの切り分けはできない。また、切り分けに使用するログについて、単一ユーザが同一Ｗｅｂサイトを閲覧した際のログや、同一基地局配下のログに限定されるなど制約がある。

本発明は、上記の点に鑑みてなされたものであって、不特定のログ情報に基づいてＷｅｂページの表示時間に関する品質劣化の要因の被疑箇所の推定を可能とすることを目的とする。

そこで上記課題を解決するため、被疑箇所推定装置は、複数の端末におけるＷｅｂページの表示過程において生成される、前記表示過程における複数の段階のそれぞれの所要時間を含むログ情報を受信する受信部と、いずれかの前記段階に関わる被疑箇所のうち前記端末、基地局、Ｗｅｂサーバの順に、当該被疑箇所が関与した表示過程に係る前記ログ情報が含む、当該被疑箇所に関係する前記段階の所要時間の平均値又は最大値と、当該段階に対する閾値とを比較して、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、を有する。

不特定のログ情報に基づいてＷｅｂページの表示時間に関する品質劣化の要因の被疑箇所の推定を可能とすることができる。

本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。 本発明の実施の形態における被疑箇所推定装置のハードウェア構成例を示す図である。 本発明の実施の形態におけるユーザ端末及び被疑箇所推定装置の機能構成例を示す図である。 ユーザ端末が実行する処理手順の一例を説明するためのフローチャートである。 ユーザ端末から被疑箇所推定装置へ送信されるブラウザログの構成例を示す図である。 Ｗｅｂページの表示処理の処理手順の一例を示す図である。 ブラウザログに含まれる指標値群の一例を示す図である。 被疑箇所推定装置が実行する処理手順の一例を説明するためのフローチャートである。

以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるＷｅｂシステムの構成例を示す図である。図１において、１以上のユーザ端末２０は、１以上の基地局３０のうちのいずれかを介して通信事業者網Ｎ２に接続可能である。また、各ユーザ端末２０は、通信事業者網Ｎ２、ＰＯＩ（Point Of Interface）、及びインターネットＮ１等を介して、１以上のＷｅｂサーバ４０と通信可能である。更に、各ユーザ端末２０は、例えば、通信事業者網Ｎ２を介して、被疑箇所推定装置１０と通信可能である。

ユーザ端末２０は、Ｗｅｂページを表示可能なＷｅｂブラウザ（以下、単に「ブラウザ」という。）を備えた通信端末である。例えば、携帯電話、スマートフォン、タブレット端末、車載機、又はＰＣ（Personal Computer）等が、ユーザ端末２０として利用されてもよい。なお、Ｗｅｂページは、例えば、ＨＴＭＬ（HyperText Markup Language）、ＣＳＳ（Cascading Style Sheets）、及びスクリプト等を含むデータである。

被疑箇所推定装置１０は、ユーザ端末２０に表示されるＷｅｂページに関する表示時間（表示待ち時間）等の品質の劣化に関して、当該劣化の要因となった被疑箇所を推定するコンピュータである。本発明の実施の形態において、被疑箇所は、ユーザ端末２０、基地局３０（又は通信事業者網Ｎ２）、ＰＯＩ（又はインターネットＮ１）、及びＷｅｂサーバ４０の４つの通信箇所のうちのいずれかの通信箇所に切り分けられる。なお、被疑箇所推定装置１０は、例えば、通信事業者に設置されてもよい。

Ｗｅｂサーバ４０は、Ｗｅｂページを記憶又は生成するＷｅｂサイトを実現する１以上のコンピュータである。

図２は、本発明の実施の形態における被疑箇所推定装置のハードウェア構成例を示す図である。図２の被疑箇所推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。

被疑箇所推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って被疑箇所推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。

図３は、本発明の実施の形態におけるユーザ端末及び被疑箇所推定装置の機能構成例を示す図である。図３において、ユーザ端末２０は、Ｗｅｂ表示制御部２１、ログ生成部２２、及びログ送信部２３等を有する。これら各部は、ユーザ端末２０にインストールされた１以上のプログラムが、ユーザ端末２０のＣＰＵに実行させる処理により実現される。ユーザ端末２０は、また、ログ保存部２４を有する。ログ保存部２４は、例えば、ユーザ端末２０が有する補助記憶装置等を用いて実現可能である。

Ｗｅｂ表示制御部２１は、ユーザによるＷｅｂページの表示指示の入力に応じ、Ｗｅｂページのダウンロード及びＷｅｂページの表示等を行う。Ｗｅｂページの表示指示とは、例えば、ＵＲＬ（Uniform Resource Locator）の入力や、既に表示されているＷｅｂページ内のリンクの選択等である。なお、Ｗｅｂ表示制御部２１は、例えば、Ｗｅｂブラウザプログラムが、ユーザ端末２０のＣＰＵに実行させる処理により実現されてもよい。

ログ生成部２２は、Ｗｅｂページの表示指示の入力を契機として、Navigation Timing APIや、ユーザ端末２０のＯＳ（Operating System）が備える標準のＡＰＩ等を呼び出すことにより、Ｗｅｂページが表示されるまでの過程における、複数の段階（複数の区間）の所要時間を計測し、その計測結果を含むログ（以下、「ブラウザログ」という。）を生成する。

近年では、Navigation Timing APIが標準化され、主なＷｅｂブラウザに実装されたことにより、非特許文献１の様な仕組みを構築するまでもなく、標準技術を用いてより詳細なログを取得することができる。すなわち、Ｗｅｂページ表示時のネットワーク通信及び端末処理に関するより詳細なイベントと、その生起時刻とを標準のNavigation Timing APIを通じて取得することが可能である。

ログ保存部２４は、ログ生成部２２によって生成されるブラウザログを保存（記憶）する。

ログ送信部２３は、ログ保存部２４に保存されたブラウザログを、被疑箇所推定装置１０に送信する。

なお、ユーザ端末２０を、ログ生成部２２及びログ送信部２３として機能させるプログラムは、例えば、Ｗｅｂブラウザに対するプラグインとして実装されてもよい。例えば、ユーザ端末２０のユーザから通信事業者に対して、Ｗｅｂページの表示時間の品質劣化の報告が有った場合に、当該通信事業者から当該ユーザ端末２０に対して当該プラグインが転送されてもよい。

被疑箇所推定装置１０は、ログ受信部１１及び推定部１２等を有する。これら各部は、被疑箇所推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。被疑箇所推定装置１０は、また、ログ記憶部１３を利用する。ログ記憶部１３は、補助記憶装置１０２、又は被疑箇所推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。

ログ受信部１１は、ユーザ端末２０から送信されるブラウザログを受信する。ログ受信部１１は、受信したブラウザログをログ記憶部１３に記憶する。したがって、ログ記憶部１３には、ブラウザログが蓄積される。なお、ブラウザログには、ユーザ端末２０におけるＷｅｂページの表示過程を構成する複数の段階の所要時間等が含まれる。

推定部１２は、ログ記憶部１３に記憶されたブラウザログに含まれる、Ｗｅｂページの表示過程を構成する複数の段階の所要時間を、それぞれに関する閾値と比較して、Ｗｅｂページの表示の品質劣化の要因の被疑箇所を推定する。すなわち、本実施の形態では、Navigation Timingの出力情報等に基づいて、より高い粒度（又は精度）で品質劣化の被疑箇所の切り分けが実現される。

なお、第一の実施の形態では、以下の（１）〜（３）が前提とされる。
（１）１つのブラウザログは、単一のユーザ端末２０による同一サイト（Ｗｅｂサーバ４０）へのアクセスに関する情報である。すなわち、ブラウザログは、ユーザ端末２０によるＷｅｂサーバ４０へのアクセス単位で生成される。
（２）ユーザ端末２０が、名前解決に利用するリゾルバ（ＤＮＳ（Domain Name System）サーバ）は、通信事業者網Ｎ２内に設置されている。当該リゾルバがキャッシュを持たないクエリについては、通常のＤＮＳの動作に従い、インターネットＮ１上の権限サーバに対して、リゾルバから名前解決が要求される。
（３）ユーザ端末２０がＷｅｂページをダウンロードする際のＴＣＰ（Transmission Control Protocol）の３ウェイハンドシェイク（３−ｗａｙ ｈａｎｄｓｈａｋｅ）は、インターネットＮ１上のＷｅｂサーバ４０との間で実行される。

以下、ユーザ端末２０及び被疑箇所推定装置１０のそれぞれが実行する処理手順について説明する。図４は、ユーザ端末が実行する処理手順の一例を説明するためのフローチャートである。

ログ生成部２２は、Ｗｅｂブラウザに対するＷｅｂページの表示指示の入力を待機している（Ｓ１０１）。ログ生成部２２は、当該表示指示の入力を検知すると（Ｓ１０１でＹｅｓ）、Navigation Timing APIやＯＳのＡＰＩ等を呼び出し（Ｓ１０２）、当該ＡＰＩによって得られる情報を含むブラウザログを生成する（Ｓ１０３）。ログ生成部２２は、生成したブラウザログをログ保存部２４に保存する。続いて、ログ送信部２３は、ログ保存部２４に保存されたブラウザログを、被疑箇所推定装置１０に送信する（Ｓ１０４）。ログ送信部２３は、送信したブラウザログをログ保存部２４から削除する。なお、被疑箇所推定装置１０へのブラウザログの送信は、定期的に実行されてもよいし、ユーザによる指示の入力に応じて実行されてもよい。これらの場合、送信時期までに生成されたブラウザログがまとめて送信されてもよい。

図５は、ユーザ端末から被疑箇所推定装置へ送信されるブラウザログの構成例を示す図である。図５に示されるように、各ブラウザログは、例えば、日時、端末アドレス、基地局ＩＤ、サーバアドレス、及び指標値群等を含む。

日時は、Ｗｅｂページの表示指示が入力された日時、又はＷｅｂページの表示が完了した日時等である。端末アドレスは、例えば、ユーザ端末２０のＩＰアドレスである。基地局ＩＤは、Ｗｅｂページの表示時にユーザ端末２０がアクセスしていた基地局３０の識別情報である。サーバアドレスは、Ｗｅｂページの提供元のＷｅｂサーバ４０のアドレス情報（例えば、ＩＰアドレス又はＵＲＬ等）である。指標値群は、Ｗｅｂページの表示過程を構成する複数の段階のそれぞれの所要時間である。指標値群の詳細については後述される。

なお、ステップＳ１０２及びＳ１０３に並行して、Ｗｅｂ表示制御部２１は、図６に示されるようなＷｅｂページの表示処理を実行する。

図６は、Ｗｅｂページの表示処理の処理手順の一例を示す図である。なお、図６において、ユーザ端末２０とＤＮＳサーバとの間のネットワークは、通信事業者網Ｎ２であり、ユーザ端末２０とＷｅｂサーバ４０との間のネットワークは、通信事業者網Ｎ２及びインターネットＮ１である。

ステップＳ２０１において、Ｗｅｂ表示制御部２１は、ユーザによって入力されたＵＲＬに関して、ＤＮＳサーバにＤＮＳクエリを送信する。当該ＤＮＳクエリに応じ、ＤＮＳサーバは、名前解決結果を含むＤＮＳ応答を返信する（Ｓ２０２）。続いて、Ｗｅｂ表示制御部２１が、ＳＹＮパケットをＷｅｂサーバ４０に送信すると（Ｓ２０３）、Ｗｅｂサーバ４０は、ＳＹＮ ＡＣＫパケットを返信する（Ｓ２０４）。続いて、Ｗｅｂ表示制御部２１が、ＡＣＫパケットをＷｅｂサーバ４０に送信して（Ｓ２０５）、ＴＣＰ ３ウェイハンドシェイクが完了する。

続いて、Ｗｅｂ表示制御部２１は、ＨＴＴＰのＧＥＴメッセージをＷｅｂサーバ４０に送信すると（Ｓ２０６）、Ｗｅｂページを構成するコンテンツデータのダウンロードが開始される（Ｓ２０７）。

上記のような表示処理に関して、図４のステップＳ１０３では、図７に示される指標値群を含むブラウザログが出力される。

図７は、ブラウザログに含まれる指標値群の一例を示す図である。図７に示されるように、１つのブラウザログには、指標値１〜５が含まれる。

指標値１は、ＤＮＳ応答の受信からＴＣＰのＳＹＮパケットの送出までの所要時間である。指標値２は、ＴＣＰの３ウェイハンドシェイク完了からＨＴＴＰのＧＥＴメッセージの送出までの所要時間である。指標値３は、Ｗｅｂページの表示待ち時間（ＵＲＬの入力からＷｅｂページの表示が完了するまでの所要時間）である。指標値４は、ＴＣＰの３ウェイハンドシェイクの所要時間である。指標値５は、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの所要時間である。

なお、図６には、各指標値が示す所要時間に対応する区間に対して、各指標値の識別子（（１）〜（５））が付されている。

続いて、被疑箇所推定装置１０が実行する処理手順について説明する。図８は、被疑箇所推定装置が実行する処理手順の一例を説明するためのフローチャートである。図８の処理は、例えば、ユーザ端末２０のユーザからの品質劣化の申告や、通信事業者側での品質劣化の検知等に応じて実行されてもよいし、定期的に実行されてもよいし、任意のタイミングで実行されてもよい。

ステップＳ３０１において、推定部１２は、ログ記憶部１３から処理対象とするブラウザログの集合を抽出する。例えば、日時の値が、現在時刻から遡って所定時間内であるブラウザログが処理対象とされてもよい。また、ユーザからの品質劣化の申告や、通信事業者側での品質劣化の検知等において、品質が劣化した日時が或る程度特定されている場合、品質が劣化した日時の前後所定時間内の日時を含むブラウザログが処理対象とされてもよい。

続いて、推定部１２は、抽出されたブラウザログの集合（以下、「集合Ｌ」という。）を、ユーザ端末２０別に分類する（Ｓ３０２）。ユーザ端末２０別への分類は、各ブラウザログの端末アドレスの値に基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｔ」という。

続いて、推定部１２は、集合Ｌｔごとに、指標値１が閾値１を超えているという条件（以下、「条件１」という。）、及び指標値２が閾値２を超えているという条件（以下、「条件２」という。）を判定する（Ｓ３０３）。閾値１又は閾値２と比較される指標値１又は指標値２は、集合Ｌｔごとの平均値であってもよいし、集合Ｌｔごとの最大値であってもよい。

いずれかの集合Ｌｔに関して（すなわち、いずれかのユーザ端末２０に関して）条件１及び条件２の少なくともいずれか一方が満たされる場合（Ｓ３０３でＹｅｓ）、推定部１２は、条件１及び条件２の少なくともいずれか一方が満たされたユーザ端末２０が被疑箇所であると判定する（Ｓ３０４）。この場合、図８の処理は終了する。

一方、全ての集合Ｌｔについて、条件１及び条件２の双方が満たされない場合（Ｓ３０３でＮｏ）、推定部１２は、集合Ｌを、基地局３０別に分類する（Ｓ３０５）。すなわち、ユーザ端末２０別の分類は解除された状態で、基地局３０別への分類が行われる。基地局３０別への分類は、各ブラウザログの基地局ＩＤに基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｂ」という。

続いて、推定部１２は、集合Ｌｂごとに、指標値３が閾値３を超えているという条件（以下、「条件３」という。）を判定する（Ｓ３０６）閾値３と比較される指標値３は、集合Ｌｂごとの平均値であってもよいし、集合Ｌｂごとの最大値であってもよい。

いずれかの集合Ｌｂに関して（すなわち、いずれかの基地局３０に関して）条件３が満たされる場合（Ｓ３０６でＹｅｓ）、推定部１２は、条件３が満たされた基地局３０が被疑箇所であると判定する（Ｓ３０７）。この場合、図８の処理は終了する。

一方、全ての集合Ｌｂについて、条件３が満たされない場合（Ｓ３０６でＮｏ）、推定部１２は、集合Ｌを、Ｗｅｂサーバ４０別に分類する（Ｓ３０２）。すなわち、基地局３０別の分類は解除された状態で、Ｗｅｂサーバ４０別への分類が行われる。Ｗｅｂサーバ４０別への分類は、各ブラウザログのサーバアドレスの値に基づいて行われてもよい。分類後の各集合を、以下「集合Ｌｓ」という。

続いて、推定部１２は、集合Ｌｓごとに、指標値４が閾値４を超えているという条件（以下、「条件４」という。）、及び指標値５が閾値５を超えているという条件（以下、「条件５」という。）を判定する（Ｓ３０９）。閾値４又は閾値５と比較される指標値４又は指標値５は、集合Ｌｓごとの平均値であってもよいし、集合Ｌｓごとの最大値であってもよい。

いずれかの集合Ｌｓに関して（すなわち、いずれかのＷｅｂサーバ４０に関して）条件４及び条件５の少なくともいずれか一方が満たされる場合（Ｓ３０９でＹｅｓ）、推定部１２は、条件４及び条件５の少なくともいずれか一方が満たされたＷｅｂサーバ４０が被疑箇所であると判定する（Ｓ３１０）。この場合、図８の処理は終了する。

一方、全ての集合Ｌｓについて、条件４及び条件５の双方が満たされない場合（Ｓ３０９でＮｏ）、推定部１２は、ＰＯＩが被疑箇所であると判定する（Ｓ３１１）。

なお、図８の処理が、品質の劣化とは無関係なタイミングで実行される場合、ステップＳ３１１においては、被疑箇所は無いと判定されてもよい。

上述したように、本実施の形態によれば、不特定のログ情報に基づいてＷｅｂページの表示時間に関する品質劣化の要因の被疑箇所の推定を可能とすることができる。その結果、サービス事業者、プラットフォーム事業者、通信事業者の各事業者の責任範囲を明確化することができる。また、品質劣化発生時の状況把握と実態把握の迅速化や、監視技術の効率化等を期待することができる。

なお、閾値１〜閾値５は、例えば、経験値に基づいて設定されてもよい。例えば、ユーザ端末２０、基地局３０、ＰＯＩ、Ｗｅｂサーバ４０のそれぞれが被疑箇所である状況において収集されたそれぞれのブラウザログの集合に基づいて閾値１〜閾値５が設定されてもよい。又は、指標値１〜指標値５について、理論的に求まる正常な値と異常な値との境界が、閾値１〜閾値５として設定されてもよい。

なお、本実施の形態において、ユーザ端末２０は、端末の一例である。ブラウザログは、ログ情報の一例である。ログ受信部１１は、受信部の一例である。集合Ｌｔは、第１の集合の一例である。集合Ｌｂは、第２の集合の一例である。集合Ｌｓは、第３の集合の一例である。閾値１、閾値２、閾値３、閾値４、閾値５は、第１の閾値、第２の閾値、第３の閾値、第４の閾値、第５の閾値の一例である。

以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ 被疑箇所推定装置
１１ ログ受信部
１２ 推定部
１３ ログ記憶部
２０ ユーザ端末
２１ Ｗｅｂ表示制御部
２２ ログ生成部
２３ ログ送信部
２４ ログ保存部
３０ 基地局
４０ Ｗｅｂサーバ
１００ ドライブ装置
１０１ 記録媒体
１０２ 補助記憶装置
１０３ メモリ装置
１０４ ＣＰＵ
１０５ インタフェース装置
Ｂ バス
Ｎ１ インターネット
Ｎ２ 通信事業者網

Claims (6)

1. 複数の端末におけるＷｅｂページの表示過程において生成される、前記表示過程における複数の段階のそれぞれの所要時間を含むログ情報を受信する受信部と、
   いずれかの前記段階に関わる被疑箇所のうち前記端末、基地局、Ｗｅｂサーバの順に、当該被疑箇所が関与した表示過程に係る前記ログ情報が含む、当該被疑箇所に関係する前記段階の所要時間の平均値又は最大値と、当該段階に対する閾値とを比較して、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定部と、
   を有することを特徴とする被疑箇所推定装置。
2. 前記推定部は、前記複数のログ情報を、前記ログ情報に含まれている前記端末の識別情報ごとの第１の集合に分類し、前記第１の集合ごとに、前記ログ情報に含まれている、ＤＮＳ応答の受信からＳＹＮパケットの送出までの所要時間について、当該第１の集合の平均値又は当該第１の集合の最大値が、第１の閾値を超えているという第１の条件と、前記ログ情報に含まれている、３ウェイハンドシェイクの完了からＨＴＴＰのＧＥＴメッセージの送出までの第２の所要時間について、当該第１の集合の平均値又は当該第１の集合の最大値が、第２の閾値を超えているという第２の条件と、を判定し、いずれかの前記第１の集合において、前記第１の条件及び前記第２の条件の少なくともいずれか一方が満たされる場合には、前記端末が前記被疑箇所であると推定する、
   ことを特徴とする請求項１記載の被疑箇所推定装置。
3. 前記推定部は、全ての前記第１の集合について、前記第１の条件及び前記第２の条件の双方が満たされない場合には、前記複数のログ情報を、前記ログ情報に含まれている基地局の識別情報ごとの第２の集合に分類し、前記第２の集合ごとに、前記ログ情報に含まれている、Ｗｅｂページの表示待ち時間について、当該第２の集合の平均値又は当該第２の集合の最大値が、第３の閾値を超えているという第３の条件を判定し、いずれかの前記第２の集合において、前記第３の条件が満たされる場合には、前記基地局が前記被疑箇所であると推定する、
   ことを特徴とする請求項２記載の被疑箇所推定装置。
4. 前記推定部は、全ての前記第２の集合について、前記第３の条件が満たされない場合には、前記複数のログ情報に含まれる、Ｗｅｂサーバの識別情報ごとの第３の集合に分類し、前記第３の集合ごとに、前記ログ情報に含まれている、ＴＣＰの３ウェイハンドシェイクの所要時間について、当該第３の集合の平均値又は当該第３の集合の最大値が、第４の閾値を超えているという第４の条件と、前記ログ情報に含まれている、ＨＴＴＰのＧＥＴメッセージの送出から最初の応答パケットの受信までの所要時間について、当該第３の集合の平均値又は当該第３の集合の最大値が、第５の閾値を超えているという第５の条件と、を判定し、いずれかの前記第３の集合において、前記第４の条件及び前記第５の条件の少なくともいずれか一方が満たされる場合には、前記Ｗｅｂサーバが前記被疑箇所であると推定する、
   ことを特徴とする請求項３記載の被疑箇所推定装置。
5. 前記推定部は、全ての前記第３の集合について、前記第４の条件及び前記第５の条件の双方が満たされない場合には、ＰＯＩ又はインターネットが前記被疑箇所であると推定する、
   ことを特徴とする請求項４記載の被疑箇所推定装置。
6. コンピュータが、
   複数の端末におけるＷｅｂページの表示過程において生成される、前記表示過程における複数の段階のそれぞれの所要時間を含むログ情報を受信する受信手順と、
   いずれかの前記段階に関わる被疑箇所のうち前記端末、基地局、Ｗｅｂサーバの順に、当該被疑箇所が関与した表示過程に係る前記ログ情報が含む、当該被疑箇所に関係する前記段階の所要時間の平均値又は最大値と、当該段階に対する閾値とを比較して、前記Ｗｅｂページの表示に関する品質劣化の要因の被疑箇所を推定する推定手順と、
   を実行することを特徴とする被疑箇所推定方法。

Images