(57)【特許請求の範囲】
【請求項１】
或るウェブページについてのウェブブラウザでの表示に関する複数回の試行のそれぞれにおける、発生時期が早い順に所定数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、前記試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間とを、所定の推定モデルに学習させる推定モデル生成部と、
ネットワーク上において観測された、前記或るウェブページに関する各ＧＥＴリクエストの相対的な発生時期に、前記所定の推定モデルを適用して、当該ＧＥＴリクエストに関する前記所要時間を推定する推定部と、
を有することを特徴とする推定装置。
【請求項２】
前記複数回の試行のそれぞれにおけるＧＥＴリクエストの数に基づいて、閾値を決定する閾値決定部を有し、
前記推定モデル生成部は、ＧＥＴリクエストの数が前記閾値以上である試行のそれぞれにおける、発生時期が早い順に前記閾値分の数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、当該試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間とを、前記所定の推定モデルに学習させる、
ことを特徴とする請求項１記載の推定装置。
【請求項３】
或るウェブページについてのウェブブラウザでの表示に関する複数回の試行のそれぞれにおける、発生時期が早い順に所定数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、前記試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間とを、所定の推定モデルに学習させる推定モデル生成手順と、
ネットワーク上において観測された、前記或るウェブページに関する各ＧＥＴリクエストの相対的な発生時期に、前記所定の推定モデルを適用して、当該ＧＥＴリクエストに関する前記所要時間を推定する推定手順と、
をコンピュータが実行することを特徴とする推定方法。
【請求項４】
前記複数回の試行のそれぞれにおけるＧＥＴリクエストの数に基づいて、閾値を決定する閾値決定手順を前記コンピュータが実行し、
前記推定モデル生成手順は、ＧＥＴリクエストの数が前記閾値以上である試行のそれぞれにおける、発生時期が早い順に前記閾値分の数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、当該試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間とを、前記所定の推定モデルに学習させる、
ことを特徴とする請求項３記載の推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、推定装置及び推定方法に関する。
【背景技術】
【０００２】
インターネットの利用が普及している中で、ウェブブラウザを快適に利用できるかどうかは、ユーザが「インターネットを快適に利用できるか」に大きく影響する。
【０００３】
そのため、ユーザがウェブページを閲覧する際にブラウザを操作し、ブラウザがデータを読み込み・表示をするまでにかかる時間（以下、「ウェブページ表示時間」という。）を把握し、管理することが品質管理上重要である。
【０００４】
ウェブページ表示時間を把握するため、ブラウザにはNavigationTiming等の仕組みが供えられ、直接表示時間を知る手法なども普及してきている（非特許文献１、非特許文献２）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】本多他、「Navigation Timing APIを用いたWeb品質劣化切り分け」、コミュニケーションクオリティ研究会2014.
【非特許文献２】「Navigation Timing」、［online］、［平成２７年１０月２６日検索］、インターネット（URL：http://www.w3.org/TR/navigation-timing/）
【非特許文献３】H. Drucker, et al.,``Support Vector Regression Machines'',Advances in Neural Information Processing Systems 9, NIPS 1996,
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、NavigationTiming技術については、コンテンツ事業者（ウェブサーバ）やユーザ（クライアント端末）において利用されることが想定されており、データ転送を担当するキャリアが管理するネットワーク上において観測されるデータに対して適用することは困難である。
【０００７】
本発明は、上記の点に鑑みてなされたものであって、ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることを目的とする。
【課題を解決するための手段】
【０００８】
そこで上記課題を解決するため、推定装置は、或るウェブページについてのウェブブラウザでの表示に関する複数回の試行のそれぞれにおける、発生時期が早い順に所定数のＧＥＴリクエストのそれぞれについての試行内での相対的な発生時期と、前記試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータの前記ウェブブラウザへの転送が完了するまでの所要時間とを、所定の推定モデルに学習させる推定モデル生成部と、ネットワーク上において観測された、前記或るウェブページに関する各ＧＥＴリクエストの相対的な発生時期に、前記所定の推定モデルを適用して、当該ＧＥＴリクエストに関する前記所要時間を推定する推定部と、を有する。
【発明の効果】
【０００９】
ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施の形態における推定装置のハードウェア構成例を示す図である。
【図２】本発明の実施の形態における推定装置の機能構成例を示す図である。
【図３】推定装置が実行する処理手順の一例を説明するためのフローチャートである。
【図４】学習データを構成するＨＴＴＰ−ＧＥＴの発生履歴を示す図である。
【図５】学習データを構成する転送完了時間及び表示完了時間の履歴の例を示す図である。
【図６】各試行についての学習閾値分のレコードの抽出結果の一例を示す図である。
【図７】各ＨＴＴＰ−ＧＥＴの発生時刻の相対時刻への変換結果の一例を示す図である。
【図８】試行ごとの転送完了時間又は表示完了時間のベクトルの一例を示す図である。
【発明を実施するための形態】
【００１１】
以下、図面に基づいて本発明の実施の形態を説明する。まず、ウェブページの閲覧・表示におけるプロセスについて説明する。当該プロセスを極めて単純化すると、以下の通りである。
（１）ユーザによるクリック等を起点としたページ取得要求が発生する。
（２）ブラウザが対象ＵＲＬの指すページのｈｔｍｌデータをＨＴＴＰ（HyperText Transfer Protocol）のＧＥＴリクエストでウェブページの転送を要求すると、ｈｔｍｌデータがブラウザに転送される。
（３）ｈｔｍｌデータ内にサブコンテンツ（画像データ、必要ｓｃｒｉｐｔ等）が示されており、ブラウザは、それらを順次解読処理し、ＨＴＴＰのＧＥＴリクエストで取得する（ＨＴＴＰでＧＥＴ）。
（４）ブラウザは順次取得したサブコンテンツを処理して表示する。
【００１２】
一般のウェブページの閲覧では、ｈｔｔｐｓで暗号化されていない場合は、ネットワーク上でのパケットのやり取りを読み取る（パケットキャプチャする）ことで、個別のＨＴＴＰのＧＥＴリクエスト（以下、「ＨＴＴＰ−ＧＥＴ」と表記する。）の送出状況及び送出時刻を把握することが出来る。そこで、（４）の表示処理の分を省略して、少なくとも（１）から（３）までの所要時間（≒ウェブページの表示が指示されてから表示に必要なデータのブラウザへの転送が完了するまでの所要時間）を知ることが出来れば、簡易的に表示完了時間を推定することができる。以下、この「ウェブページの表示が指示されてから表示に必要なデータのブラウザへの転送が完了するまでの所要時間」を、単に、「転送完了時間」という。また、（１）〜（４）までの所要時間を、「表示完了時間」という。
【００１３】
しかし、ＨＴＴＰ−ＧＥＴを観測することで、「転送完了時間」を特定するには以下の２点の問題がある。
（ａ）ウェブページの作りによっては、自動更新等により、ウェブページの表示完了後もＨＴＴＰ−ＧＥＴが継続して発生する。
（ｂ）同じウェブページを同じ端末で繰り返し表示した場合、表示完了までに生じるＨＴＴＰ−ＧＥＴの数が必ずしも一定ではない。
【００１４】
まず、（ａ）により、一つのウェブページに関して「ＨＴＴＰ−ＧＥＴの発生が終了するタイミング」はネットワーク上でＧＥＴリクエストの発生状況を観測する範囲では、判断できないため、そもそも表示用データの転送の完了は、ＨＴＴＰ−ＧＥＴの転送の完了と対応しない。
【００１５】
また、（ｂ）により、ウェブページ毎にＨＴＴＰ−ＧＥＴの数に関して一定の閾値を事前に決定し、ＨＴＴＰ−ＧＥＴのシーケンスを観測して当該閾値にＧＥＴ回数が到達した時点をもってＨＴＴＰ−ＧＥＴの転送の完了と判断することも困難である。
【００１６】
そこで、本実施の形態では、転送完了（上記の（３）の完了）よりも手前の段階（上記の（３）の途中までの段階）でのＨＴＴＰ−ＧＥＴの発生履歴から、転送完了時間又は表示完了時間を推定する。
【００１７】
図１は、本発明の実施の形態における推定装置のハードウェア構成例を示す図である。図１の推定装置１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
【００１８】
推定装置１０での処理を実現するプログラムは、ＣＤ−ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
【００１９】
メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って推定装置１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
【００２０】
なお、推定装置１０は、それぞれが図１に示される構成を有する複数のコンピュータによって構成されてもよい。
【００２１】
図２は、本発明の実施の形態における推定装置の機能構成例を示す図である。図２において、推定装置１０は、学習データ取得部１１、閾値決定部１２、推定モデル生成部１３、及び推定部１４等を有する。これら各部は、推定装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。推定装置１０は、また、学習データ記憶部１５を利用する。学習データ記憶部１５は、例えば、補助記憶装置１０２、又は推定装置１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
【００２２】
学習データ取得部１１は、予め設定されたＵＲＬに係る、評価対象のウェブページ（以下「評価対象ページ」という。）について、転送完了時間又は表示完了時間の推定のための学習データを取得する。推定の対象が転送完了時間であれば、転送完了時間に関する学習データが取得され、推定の対象が表示完了時間であれば、表示完了時間に関する学習データが取得される。推定の対象が、転送完了時間及び表示完了時間のいずれであるかは、予め設定される。学習データは、ネットワークキャプチャデータの取得や、ウェブブラウザにおけるウェブページに関するデータ転送の完了又はウェブページの表示の完了等のタイミングの検知等を並行して実行することで取得される。学習データ取得部１１は、同一の評価対象ページに関して複数回にわたって繰り返し行われるウェブページの表示指示及び表示ついて、ページ転送完了の時刻若しくはページ表示完了の時刻、及び転送されたＨＴＴＰ−ＧＥＴ（ＨＴＴＰのＧＥＴリクエスト）の発生履歴を示す学習データを取得する。取得された学習データは、学習データ記憶部１５に記憶される。
【００２３】
閾値決定部１２は、学習データに基づいて、転送完了時間又は表示完了時間の推定に用いるＨＴＴＰ−ＧＥＴの数（閾値）を決定する。
【００２４】
推定モデル生成部１３は、閾値決定部１２によって決定された閾値の範囲内の学習データを、統計的な推定モデルに学習させる。
【００２５】
推定部１４は、学習データを学習した推定モデルを、ネットワーク上において観測された観測データ（ＧＥＴリクエストの発生履歴）に対して適用して、転送完了時間及び表示完了時間のうち、推定対象として設定された方を推定する。
【００２６】
以下、推定装置１０が実行する処理手順について説明する。図３は、推定装置が実行する処理手順の一例を説明するためのフローチャートである。
【００２７】
ステップＳ１０１において、学習データ取得部１１は、予めそのＵＲＬが設定されている評価対象ページを、推定装置１０内のブラウザに表示させ、その際のＨＴＴＰ−ＧＥＴの発生履歴と、ブラウザによる評価対象ページの転送完了時間又は表示完了時間との実績値を取得する。学習データ取得部１１は、取得されたデータ（学習データ）を、学習データ記憶部１５に記憶する。なお、ＨＴＴＰ−ＧＥＴの発生履歴については、転送の開始から転送完了時間までのものが取得される。すなわち、転送完了時間より後のＨＴＴＰ−ＧＥＴについては、当該発生履歴に含まれない。
【００２８】
ＨＴＴＰ−ＧＥＴの発生履歴については、例えば、推定装置１０内のｔｃｐｄｕｍｐ等のパケットキャプチャツールでパケットデータを取得した後、ｔｓｈａｒｋ等のキャプチャ解析ツールで、当該パケットデータをＨＴＴＰ−ＧＥＴの発生数及び時刻に変換することで取得されてもよい。例えば、キャプチャデータファイル名がｄｕｍｐ．ｐｃａｐであるとすると、以下のコマンドを実行することで、ＨＴＴＰ−ＧＥＴの発生数及び時刻を得ることができる。
%tshark -r dump.pcap -Y http.request.uri -T fields -e frame.time_epoch-e ......
又は、推定装置１０内にプロキシを設定し、ブラウザによるウェブページの表示時のプロキシログからＨＴＴＰ−ＧＥＴ時刻情報のログが取得されてもよい。
【００２９】
一方、ブラウザでの評価対象ページの転送完了時間及び表示完了時間については、例えば、NavigationTimingのＡＰＩ（Application Program Interface）により計測して数値化が可能である。
【００３０】
なお、ステップＳ１０１の１回の実行を、「試行」という。ステップＳ１０１は、事前に設定された試行回数（例えば、１０１回等）分だけ繰り返される。その結果、図４及び図５に示される情報によって構成される学習データが、取得される。
【００３１】
図４は、学習データを構成するＨＴＴＰ−ＧＥＴの発生履歴を示す図である。図４において、ＨＴＴＰ−ＧＥＴの発生履歴は、各試行において検出されたＨＴＴＰ−ＧＥＴごとに、試行番号、ＧＥＴリクエスト、及び時刻等を含む。
【００３２】
試行番号は、何番目の試行において検出されたＧＥＴリクエストであるのかを示す値である。ＧＥＴリクエストは、ＧＥＴリクエストの内容を示す文字列である。時刻は、ＧＥＴリクエストが発生した（検出された）時刻である。なお、試行ごとに、ＧＥＴリクエストの数は異なりうるため、図４において、試行ごとの行数は異なりうる。
【００３３】
図５は、学習データを構成する転送完了時間及び表示完了時間の履歴の例を示す図である。図５には、各試行における、評価対象ページの転送完了時間及び表示完了時間が示されている。なお、推定の対象が転送完了時間である場合、転送完了時間のみが取得されてもよく、表示完了時間である場合、転送完了時間及び表示完了時間が取得されてもよい。
【００３４】
なお、図４と図５とにおいて、試行番号が共通するレコードは、同じ試行番号に関する学習データである。例えば、図５において、試行２（試行番号が２である試行）に関するＨＴＴＰ−ＧＥＴの発生履歴は、図４において試行番号が２であるレコードを参照することで特定できる。
【００３５】
なお、評価対象ページの表示に関する試行は、推定装置１０とは異なる端末において実行されてもよい。この場合、ステップＳ１０１では、学習データが入力されるだけでよい。
【００３６】
続いて、閾値決定部１２は、予め設定されている閾値決定法及びパラメータを、学習データに適用することで、閾値を決定する（ステップＳ１０２）。
【００３７】
まず、閾値決定部１２は、ＨＴＴＰ−ＧＥＴ発生履歴（図４）について、試行ごとのレコード数を集計し、集計結果を昇順にソートする。図４の例では、試行１の集計結果は４であり、試行２の集計結果は５である。
【００３８】
続いて、閾値決定部１２は、予め設定されている閾値決定法及びパラメータに基づいて、閾値を決定する。本実施の形態では、「分布の下位パーセンタイル指定」で、ソートした数字の小さい側から、事前に決められた分位点が閾値として決定される。
【００３９】
例えば、閾値決定法が、「分布の下位５パーセンタイル」であれば、ソート結果の最小値から５％の位置（すなわち、１０１回試行の場合、最小値から６個目の値）が閾値として決定される。
【００４０】
この理由は、最小値を用いると、異常終了してしまったサンプル等が含まれる場合、最小値が極めて小さくなり、推定に必要な適正なデータ数が得られない可能性があるためである。そこで、一定の分位点抽出で対応する。
【００４１】
以上により決定された閾値を、「学習閾値Ｎ」という。
【００４２】
続いて、推定モデル生成部１３は、ＨＴＴＰ−ＧＥＴ発生履歴（図４）について、試行ごとに、時刻の値が小さい方から学習閾値Ｎ個分のレコード（すなわち、発生時期の早い順にＮ個のＧＥＴリクエストに関するレコード）を抽出する（ステップＳ１０３）。なお、レコードの数が学習閾値Ｎ未満である試行については、レコードの抽出は行われない。
【００４３】
図６は、各試行について学習閾値分のレコードの抽出結果の一例を示す図である。図６では、レコードの抽出が行われた試行ごとに、試行番号、Ｎ個分のＨＴＴＰ−ＧＥＴの発生時刻が示されている。なお、図６では、Ｍ個の試行が、学習閾値Ｎ個以上のレコードを含んでいた例に対応する。
【００４４】
続いて、推定モデル生成部１３は、レコードが抽出された試行ごとに、各ＨＴＴＰ−ＧＥＴの発生時刻を、当該試行の最初のＨＴＴＰ−ＧＥＴの発生時刻からの相対値（相対時刻）に変換する（ステップＳ１０４）。すなわち、図６に示される各試行のＧＥＴ−Ｘ（Ｘ＝１〜Ｎ）時刻について、ＧＥＴ−１時刻からの差分（試行内の相対的な発生時期）が算出される。
【００４５】
図７は、各ＨＴＴＰ−ＧＥＴの発生時刻の相対時刻への変換結果の一例を示す図である。図７には、図６に示した各試行の各ＨＴＴＰ−ＧＥＴの発生時刻について、相対時刻への変換結果が示されている。なお、ＧＥＴ−１時刻については、各試行について、相対時刻は常に０となり情報量が無いので破棄する。その結果、各試行の列数はＮ−１となる。
【００４６】
続いて、推定モデル生成部１３は、（ＧＥＴ数がＮ以上であった）試行ごとに、転送完了時間又は表示完了時間のベクトルを生成する（ステップＳ１０５）。
【００４７】
図８は、試行ごとの転送完了時間又は表示完了時間のベクトルの一例を示す図である。図８において、（１）は、図５に示した学習データに基づいて生成された、転送完了時間のベクトルである。（２）は、図５に示した学習データに基づいて生成された、表示完了時間のベクトルである。なお、推定対象が転送完了時間であれば、転送完了時間のベクトルのみが生成されてもよく、推定対象が表示完了時間であれば、表示完了時間のベクトルのみが生成されてもよい。
【００４８】
続いて、推定モデル生成部１３は、予め設定された推定方法に基づいて、推定モデルを生成する（ステップＳ１０６）。本実施の形態では、推定方法として、サポートベクター回帰（ＳＶＲ：SupportVectorRegression）が設定された例について説明する。但し、本実施の形態に適用可能な推定方法は、ＳＶＲに限定されず、他の方法が用いられてもよい。例えば、重回帰等が用いられてもよい。なお、ＳＶＲ自体は、単なる機械学習の既知の手法であり、本実施の形態では、入力データの使い方及び出力とのマッピングがポイントである。
【００４９】
ここでは、学習データ（Ｘ）を以下のように構成する。
Ｘ＝（Ｘ＿１，Ｘ＿２，...，Ｘ＿（Ｎ−１））
但し、
Ｘ＿１＝［各試行のＧＥＴ−２の相対時刻の長さＭのベクトル］
＝［０．０３２，０．２００，...，０．２２２］（図７の例）
Ｘ＿（Ｎ−１）＝［０．２３３，０．６６８，...，１．２２３］
また、学習データ（Ｙ）を以下のように構成する。
転送完了時間が推定対象である場合、
Ｙ＝［転送完了時間の長さＭのベクトル］＝［２．５，２．９，...，４．１］
表示完了時間が推定対象である場合、
Ｙ＝［表示完了時間の長さＭのベクトル］＝［３．１，３．６，...，４．７］
推定モデル生成部１３は、ＳＶＲのモデルＥを生成し、上記のように構成した学習データ（Ｘ）及び学習データ（Ｙ）で学習させる。すなわち、ＸとＹとの関係を、モデルＥに学習させる。
【００５０】
例えば、ＳＶＲの機能を持っているscikit-learnのライブラリにおける、ＳＶＲの使い方（http://scikit-learn.org）に準じれば、以下の記述によって、モデルＥの生成と、学習とを行うことができる。
E=SVR()          #モデル生成
E.fit(X、Y)          #学習データで学習
続いて、推定部１４は、モデルＥを、ネットワーク上の観測データに対して適用し、当該観測データに関して、転送完了時間又は表示完了時間を推定する（ステップＳ１０７）。
【００５１】
具体的には、推定部１４は、ネットワーク上において時系列に観測された評価対象ページに関する各ＨＴＴＰ−ＧＥＴの発生時刻の履歴を取得する。推定部１４は、当該各ＨＴＴＰ−ＧＥＴの発生時刻について、最初のＨＴＴＰ−ＧＥＴの発生時刻からの相対的な発生時期（相対時刻）を算出する。その結果、相対時刻のベクトルＸ＿ｎｅｗが得られる。
【００５２】
例えば、観測された各ＨＴＴＰ−ＧＥＴの発生時刻の履歴が、以下の通りであったとする。
ＧＥＴ発生時刻の履歴：（２３４５．３３３，２３４５．９９９，２３４６．５００，２３４７．０００）
この場合、Ｘ＿ｎｅｗの値は、以下の通りとなる。
Ｘ＿ｎｅｗ＝［０．６６６，１．１６７，...，１．６６７］
推定部１４は、Ｘ＿ｎｅｗを推定モデルＥで推定し、推定値Ｔ＿ｅを得る。
Ｔ＿ｅ＝Ｅ．ｐｒｅｄｉｃｔ（Ｘ＿ｎｅｗ）
このように推定されたＴ＿ｅの値（例えば、３．８）が、観測データに関する「転送完了時間」又は「表示完了時間」の推定値である。すなわち、学習データ（Ｙ）が転送完了時間のベクトルであれば、転送完了時間の推定値が得られる。学習データ（Ｙ）が表示完了時間のベクトルであれば、表示完了時間の推定値が得られる。
【００５３】
なお、転送完了時間及び表示完了時間の双方の推定値が得られてもよい。
【００５４】
また、複数のＵＲＬのそれぞれごとに推定モデルを生成しておき、ネットワークにおいて観測されたＧＥＴリクエストに係るＵＲＬに対応する推定モデルを利用して、転送完了時間又は表示完了時間の推定が行われてもよい。
【００５５】
上述したように、本実施の形態によれば、ネットワーク上の観測データからウェブブラウザの快適性を推定可能とすることができる。
【００５６】
なお、本実施の形態において、評価対象ウェブページは、或るウェブページの一例である。転送完了時間及び表示完了時間は、試行ごとに計測された、前記或るウェブページの表示が指示されてから、少なくとも前記或るウェブページの表示に必要なデータのウェブブラウザへの転送が完了するまでの所要時間の一例である。
【００５７】
以上、本発明の実施例について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【符号の説明】
【００５８】
１０          推定装置
１１          学習データ取得部
１２          閾値決定部
１３          推定モデル生成部
１４          推定部
１５          学習データ記憶部
１００        ドライブ装置
１０１        記録媒体
１０２        補助記憶装置
１０３        メモリ装置
１０４        ＣＰＵ
１０５        インタフェース装置
Ｂ            バス
【図１】
0006280092.tif 000002
【図２】
0006280092.tif 000003
【図３】
0006280092.tif 000004
【図４】
0006280092.tif 000005
【図５】
0006280092.tif 000006
【図６】
0006280092.tif 000007
【図７】
0006280092.tif 000008
【図８】
0006280092.tif 000009