(57)【特許請求の範囲】
【請求項１】
クライアント装置がサーバ装置により提供されるサイトのＵＲＬへアクセスした場合に、前記クライアント装置と前記サーバ装置との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する抽出部と、
前記抽出部によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けて記憶部に格納する格納部と、
前記クライアント装置が、前記アクセス元ＵＲＬへアクセスした時間と前記アクセス先ＵＲＬへアクセスした時間との差分を計測する計測部と、
前記記憶部に格納されたアクセス元ＵＲＬとアクセス先ＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定するとともに、前記計測部によって計測された差分を用いて、前記クライアント装置の前記アクセス先ＵＲＬに対するアクセスがクリックによるアクセスか、自動的に発生するアクセスであるかを推定する推定部と、
前記推定部によって推定された前記ＵＲＬ同士の接続関係と、前記アクセス先ＵＲＬに対するアクセスがクリックによるアクセスか自動的に発生するアクセスであるかの推定結果とに基づいて、サイトへアクセスする際に最初にアクセスしたＵＲＬと、前記クリックによりアクセスしたＵＲＬとを入口ＵＲＬとして特定する特定部と、
を有することを特徴とする推定装置。
【請求項２】
前記抽出部は、前記クライアント装置と前記サーバ装置との間で通信されるパケットのヘッダ情報を解析し、該ヘッダ情報のリクエストラインに含まれるアクセス先ＵＲＬと、ヘッダ情報のリファラーに含まれるアクセス元ＵＲＬとを抽出することを特徴とする請求項１に記載の推定装置。
【請求項３】
推定装置で実行する推定方法であって、
クライアント装置がサーバ装置により提供されるサイトのＵＲＬへアクセスした場合に、前記クライアント装置と前記サーバ装置との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する抽出工程と、
前記抽出工程によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けて記憶部に格納する格納工程と、
前記クライアント装置が、前記アクセス元ＵＲＬへアクセスした時間と前記アクセス先ＵＲＬへアクセスした時間との差分を計測する計測工程と、
前記記憶部に格納されたアクセス元ＵＲＬとアクセス先ＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定するとともに、前記計測工程によって計測された差分を用いて、前記クライアント装置の前記アクセス先ＵＲＬに対するアクセスがクリックによるアクセスか、自動的に発生するアクセスであるかを推定する推定工程と、
前記推定工程によって推定された前記ＵＲＬ同士の接続関係と、前記アクセス先ＵＲＬに対するアクセスがクリックによるアクセスか自動的に発生するアクセスであるかの推定結果とに基づいて、サイトへアクセスする際に最初にアクセスしたＵＲＬと、前記クリックによりアクセスしたＵＲＬとを入口ＵＲＬとして特定する特定工程と、
を含んだことを特徴とする推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、推定装置および推定方法に関する。
【背景技術】
【０００２】
近年、インターネット上の悪性なサーバによってセキュリティインシデントが派生する事例が多発している。悪性な通信先の情報をブラックリストとしてあらかじめ保持しておき、通信時に通信先の情報がブラックリストに含まれるかどうかを判別することで、当該通信を遮断するかどうかを判別するフィルタリングが実施されている。
【０００３】
一方、ＵＲＬが悪性かどうかを判断するため、おとりＰＣを用いて実際にＵＲＬへアクセスし攻撃を受けるかどうかで悪性かどうかを判断するＷｅｂクライアントハニーポットという技術がある。Ｗｅｂクライアントハニーポットは、Ｗｅｂブラウザやプラグインなどに脆弱性を残したままセキュリティパッチを適用していない端末であるため、攻撃の標的となりうる被害ＰＣと同等の環境で検査することができる。
【０００４】
例えば、特定のネットワーク機器（ＷｅｂプロキシやＩＤＳ等）においてユーザのＷｅｂアクセスを監視し、アクセスしたＵＲＬが悪性かどうかをシグネチャやブラックリストによって判断する方法がある。また、未知の攻撃コードやＵＲＬを用いた攻撃では前述のシグネチャやブラックリストでは判断できないことから、実際にＷｅｂクライアントハニーポットを利用して対象ＵＲＬにアクセスすることによって検査する手法が考えられる（例えば、非特許文献１、２参照）。
【０００５】
ところで、Ｗｅｂは複数のＵＲＬから構成される場合が多い。例えば、あるＵＲＬにアクセスすると、複数の画像ファイルのＵＲＬへのアクセス、ＪａｖａＳｃｒｉｐｔ（登録商標）のＵＲＬへのアクセス、スタイルシートのＵＲＬへのアクセス等、一つのアクセスＵＲＬから様々なＵＲＬへの派生アクセスが自動的に発生する。
【０００６】
例えば、図１５の例では、最初の入口ＵＲＬ（図１５でいうところのＵＲＬ＿Ａ）を検査（改めてＷｅｂクライアントでアクセス）することで自動的にアクセスが発生するＵＲＬ（派生ＵＲＬ）を検査する事ができる。一方、個別の派生ＵＲＬを検査した場合、正しくＷｅｂブラウザで処理できない場合や、入口ＵＲＬの検査ですでに連鎖的に検査ができているＵＲＬとの検査が重複するなどの問題がある。そこで、アクセスＵＲＬ一覧から入口ＵＲＬだけを抽出することで、無意味な検査や検査の重複を無くし、検査対象ＵＲＬを削減したい。
【０００７】
また、Ｗｅｂページには、ハイパーリンクが記述されていることもあり、それをクリックすることでＵＲＬが遷移することもある。Ｗｅｂの検査を実施することを考慮すると、ハイパーリンクによるアクセス先は自動的なアクセスは発生しないため、入口ＵＲＬとして別途検査をする必要がある。よって自動的なＵＲＬの遷移とハイパーリンクによるＵＲＬの遷移を判別する必要がある。
【０００８】
図１６の例を用いて説明すると、ＵＲＬ＿Ｅへのハイパーリンクをクリックした場合に、図１６の右側に示すようにＵＲＬ＿Ａを起点とする参照関係とＵＲＬ＿Ｅを起点とする参照関係が、さらにＵＲＬ＿ＣとＵＲＬ＿Ｅで接続される。この際に、ＵＲＬ＿ＣからＵＲＬ＿Ｅへのハイパーリンクによる接続関係を識別して、ＵＲＬ＿Ａを入口ＵＲＬとするネットワーク、およびＵＲＬ＿Ｅを入口ＵＲＬとするネットワークに分けたい。ここで、ＵＲＬ＿ＣからＵＲＬ＿Ｅへの接続関係だけではハイパーリンクかどうかを識別できない。
【０００９】
このような入口ＵＲＬを特定する方法として、Ｗｅｂコンテンツの中身を分析することでハイパーリンクによる接続かどうかを識別し、ＵＲＬの接続関係を推定して、入口ＵＲＬを特定する方法が存在する。例えば、ＷｅｂページのＨＴＭＬの構文解析を行うことで、ハイパーリンクによる接続かどうかを識別し、ＵＲＬの接続関係を推定して、入口ＵＲＬを特定する。
【先行技術文献】
【非特許文献】
【００１０】
【非特許文献１】“Capture-HPC”、［online］、［平成２４年６月４日検索］、インターネット＜https://projects.honeynet.org/capture-hpc＞
【非特許文献２】Mitsuaki  Akiyama,  Makoto  Iwamura,  Yuhei  Kawakoya,  Kazufumi  Aoki,  Mitsutaka  Itoh:  Design  and  Implementation  of  High  Interaction  Client  Honeypot  for  Drive-by-Download  Attacks.  IEICE  Transactions  E93-B(5):  1131-1139  (2010)
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、上記した従来のＷｅｂコンテンツの内容を分析してハイパーリンクによる接続かどうかを識別する技術では、効率的に入り口ＵＲＬを特定することができず、Ｗｅｂページの構造を効率的に把握することができないという課題があった。
【００１２】
つまり、上記した技術では、コンテンツの内容を分析するためには、例えば、ＨＴＴＰによって分割されたペイロードを再構築する処理や、ダイナミックＨＴＭＬはスクリプト（ＪａｖａＳｃｒｉｐｔやＶＢｓｃｒｉｐｔ）等をレンダリングする処理を行うので、処理負荷が重くなり、入り口ＵＲＬを効率的に特定することができず、Ｗｅｂページの構造を効率的に把握することができなかった。
【００１３】
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、入り口ＵＲＬを効率的に特定し、Ｗｅｂページの構造を効率的に把握することを目的とする。
【課題を解決するための手段】
【００１４】
上述した課題を解決し、目的を達成するため、推定装置は、クライアント装置がサーバ装置により提供されるサイトのＵＲＬへアクセスした場合に、前記クライアント装置と前記サーバ装置との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する抽出部と、前記抽出部によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けて記憶部に格納する格納部と、前記記憶部に格納されたアクセス元ＵＲＬとアクセス先ＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定する推定部と、前記推定部によって推定された前記ＵＲＬ同士の接続関係に基づいて、サイトへアクセスする際に最初にアクセスするＵＲＬである入口ＵＲＬを特定する特定部と、を有することを特徴とする。
【００１５】
また、推定方法は、推定装置で実行する推定方法であって、クライアント装置がサーバ装置により提供されるサイトのＵＲＬへアクセスした場合に、前記クライアント装置と前記サーバ装置との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する抽出工程と、前記抽出工程によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けて記憶部に格納する格納工程と、前記記憶部に格納されたアクセス元ＵＲＬとアクセス先ＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定する推定工程と、前記推定工程によって推定された前記ＵＲＬ同士の接続関係に基づいて、サイトへアクセスする際に最初にアクセスするＵＲＬである入口ＵＲＬを特定する特定工程と、を含んだことを特徴とする。
【発明の効果】
【００１６】
本願に開示する推定装置および推定方法は、入り口ＵＲＬを効率的に特定し、Ｗｅｂページの構造を効率的に把握することができるという効果を奏する。
【図面の簡単な説明】
【００１７】
【図１】図１は、第一の実施の形態に係る通信システムの全体構成の一例を説明する図である。
【図２】図２は、第一の実施の形態に係る推定装置の構成の一例を示すブロック図である。
【図３】図３は、ヘッダ情報記憶部に記憶されるデータの一例を示す図である。
【図４】図４は、接続関係記憶部に記憶されるデータの一例を示す図である。
【図５】図５は、ＨＴＴＰリクエスタヘッダに含まれる主な情報を示す図である。
【図６】図６は、アクセス間隔について説明する図である。
【図７】図７は、ＨＴＴＰリクエスタヘッダからＵＲＬの接続関係を推定する処理を説明する図である。
【図８】図８は、ＵＲＬの接続関係から入口ＵＲＬを特定する処理を説明する図である。
【図９】図９は、第一の実施の形態に係る推定装置による処理の流れの一例を説明するためのフローチャートである。
【図１０】図１０は、クライアントと推定装置とが接続されている場合の通信システムの全体構成の一例を説明する図である。
【図１１】図１１は、アクセス間隔について説明する図である。
【図１２】図１２は、ゲートウェイに推定装置が含まれる場合の通信システムの全体構成の一例を説明する図である。
【図１３】図１３は、クライアントに推定装置が含まれる場合の通信システムの全体構成の一例を説明する図である。
【図１４】図１４は、推定プログラムを実行するコンピュータを示す図である。
【図１５】図１５は、一般的なＷｅｂページにおけるＵＲＬの参照関係を説明する図である。
【図１６】図１６は、ハイパーリンクをクリックした場合のＵＲＬの参照関係を説明する図である。
【発明を実施するための形態】
【００１８】
以下に、本願に係る推定装置および推定方法の実施形態を図面に基づいて詳細に説明する。なお、この実施形態により本願に係る推定装置および推定方法が限定されるものではない。
【００１９】
［第一の実施の形態］
以下の実施の形態では、第一の実施の形態に係る通信システムの構成、推定装置の構成および処理の流れを順に説明し、最後に第一の実施の形態による効果を説明する。
【００２０】
［第一の実施の形態に係る通信システムの構成］
まず、図１を用いて、第一の実施の形態に係る通信システム１００について説明する。図１は、第一の実施の形態に係る通信システム１００の全体構成の一例を説明するための図である。通信システム１００では、推定装置１０とゲートウェイ２０とクライアント３０Ａ〜３０Ｃとサーバ４０とインターネット５０で構成される。また、クライアント３０Ａ〜３０Ｃとサーバ４０とはゲートウェイ２０およびインターネット５０を介して通信が行われる。なお、複数のクライアント３０Ａ〜３０Ｃについて、特に区別なく説明する場合には、「クライアント３０」と記載して説明する。
【００２１】
推定装置１０は、クライアント３０Ａ〜３０Ｃとサーバ４０との間で通信されるパケットがゲートウェイ２０から送信され、送信されたパケットのヘッダ情報からＵＲＬの接続関係を推定し、入口ＵＲＬを特定する。なお、推定装置１０の詳しい構成や処理については、図２等を用いて後に詳述する。
【００２２】
ゲートウェイ２０は、ＬＡＮ（Local  Area  Network）上のクライアント３０Ａ〜３０Ｃとインターネット５０とを中継する通信装置であって、ゲートウェイ２０とクライアント３０Ａ〜３０Ｃとの間で通信されるパケットを転送するとともに、該パケットを推定装置１０にも送信する。なお、図１の例では、ゲートウェイ２０が１台の場合を例示しているが、これに限定されるものではなく、２台以上であってもよい。
【００２３】
クライアント３０Ａ〜３０Ｃは、企業や大学などの特定のＬＡＮに配置されたユーザ端末である。例えば、クライアント３０Ａ〜３０Ｃは、ＵＲＬにアクセスしてＷｅｂサイトにアクセスする。なお、図１の例では、クライアント３０Ａ〜３０Ｃが３台の場合を例示しているが、これに限定されるものではなく、２台以下であってもよいし、４台以上であってもよい。
【００２４】
サーバ４０は、ＵＲＬによりアクセスされる各種ウェブサイトを提供するサーバ装置である。なお、図１の例では、サーバ４０が１台の場合を例示しているが、これに限定されるものではなく、２台以上であってもよい。
【００２５】
［推定装置の構成］
次に、図２を用いて、図１に示した推定装置１０の構成を説明する。図２は、第一の実施の形態に係る推定装置の構成を示すブロック図である。図２に示すように、この推定装置１０は、通信制御部１１、制御部１２、記憶部１３を有する。以下にこれらの各部の処理を説明する。
【００２６】
通信制御部１１は、接続されるゲートウェイ２０との間でやり取りする各種情報に関する通信を制御する。例えば、通信制御部１１は、クライアント３０Ａ〜３０Ｃとサーバ４０との間で通信されるパケットをゲートウェイ２０から受信する。
【００２７】
記憶部１３は、制御部１２による各種処理に必要なデータおよびプログラムを格納するが、特に本発明に密接に関連するものとしては、ヘッダ情報記憶部１３ａおよび接続関係記憶部１３ｂを備える。
【００２８】
ヘッダ情報記憶部１３ａは、後述する抽出部１２ａによって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けて記憶する。具体的には、ヘッダ情報記憶部１３ａは、図３に例示するように、「リクエストＵＲＬ」と「リソースＵＲＬ」とを対応付けて記憶する。例えば、図３の例を挙げて説明すると、ヘッダ情報記憶部１３ａは、リクエストＵＲＬ「ＵＲＬ＿Ａ」とリソースＵＲＬ「ＵＲＬ＿Ｂ」とを対応付けて記憶する。
【００２９】
接続関係記憶部１３ｂは、後述する推定部１２ｄによって推定されたＵＲＬ同士の接続関係を記憶する。具体的には、接続関係記憶部１３ｂは、ＵＲＬの「接続関係」と、所定のサイトへアクセスする際に最初にアクセスする「入口ＵＲＬ」とを記憶する。例えば、図４の例を挙げて説明すると、接続関係記憶部１３ｂは、接続関係「ＵＲＬ＿Ａ→ＵＲＬ＿Ｂ→ＵＲＬ＿Ｃ」と、入口ＵＲＬ「ＵＲＬ＿Ａ」とを記憶する。
【００３０】
制御部１２は、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行するが、特に本発明に密接に関連するものとしては、抽出部１２ａ、格納部１２ｂ、計測部１２ｃ、推定部１２ｄ、特定部１２ｅを有する。
【００３１】
抽出部１２ａは、クライアント３０がサーバ４０により提供されるサイトのＵＲＬへアクセスした場合に、クライアント３０とサーバ４０との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する。具体的には、抽出部１２ａは、クライアント３０とサーバ４０との間で通信されるパケットを受信すると、クライアント３０とサーバ４０との間で行われるＨＴＴＰ通信において送受信されるパケットのヘッダ情報であるＨＴＴＰリクエストヘッダを解析し、該ＨＴＴＰリクエストヘッダのリクエストラインに含まれるアクセス先ＵＲＬである「リクエストＵＲＬ」と、ヘッダ情報のリファラーに含まれるアクセス元ＵＲＬである「リソースＵＲＬ」とを抽出し、抽出したリクエストＵＲＬおよびリソースＵＲＬを格納部１２ｂに通知する。
【００３２】
ここで、図５を用いて、ＨＴＴＰリクエストヘッダに含まれる主な情報について説明する。図５は、ＨＴＴＰリクエスタヘッダに含まれる主な情報を示す図である。ＲＦＣ２６１６では、ＨＴＴＰリクエストヘッダには、図５に示す情報が含まれると規定されている。図５に示すように、リクエストラインには、ＨＴＴＰメソッドである「メソッド」、アクセス先ＵＲＬである「リクエストＵＲＬ」、ＨＴＴＰのバージョンを示す「ＨＴＴＰバージョン」が含まれ、リファラーには、アクセス元ＵＲＬである「リクエストＵＲＬが得られたリソースのＵＲＬ（リソースＵＲＬ）」が含まれる。つまり、単一のＨＴＴＰリクエストヘッダから、ある２つのＵＲＬの参照関係が抽出できる。また、後述するように、複数のＨＴＴＰリクエストヘッダを分析することで連鎖するＵＲＬ同士の接続関係を導くことができる。
【００３３】
格納部１２ｂは、抽出部によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けてヘッダ情報記憶部１３ａに格納する。具体的には、格納部１２ｂは、抽出部１２ａから受信したリクエストＵＲＬおよびリソースＵＲＬを対応付けてヘッダ情報記憶部１３ａに格納する。
【００３４】
計測部１２ｃは、クライアント３０が、アクセス元ＵＲＬへアクセスした時間とアクセス先ＵＲＬへアクセスした時間との差分であるアクセス間隔を計測する。具体的には、計測部１２ｃは、アクセス元ＵＲＬのリクエストに対するＷｅｂサイトからのリプライがゲートウェイ２０を通過した時刻と、アクセス元ＵＲＬがリファラーとして設定されたアクセス先ＵＲＬのリクエストがゲートウェイ２０を通過した時刻、これらの差分をアクセス間隔として計測する。ここでアクセス間隔とは、アクセス元ＵＲＬのＨＴＴＰリクエストに対するＨＴＴＰリプライを受信したタイムスタンプ、およびアクセス先ＵＲＬのＨＴＴＰリクエストを送信したタイムスタンプの差分である。
【００３５】
ここで図６の例を用いて、アクセス間隔について説明する。図６は、アクセス間隔について説明する図である。図６の例では、ＵＲＬ＿Ａがアクセス元ＵＲＬであり、ＵＲＬ＿Ｂがアクセス先ＵＲＬである。図６に示すように、ＵＲＬ＿Ａのリクエストに対するＷｅｂサイトからのリプライがゲートウェイ２０を通過した時刻と、ＵＲＬ＿Ａがリファラーとして設定されたＵＲＬ＿Ｂのリクエストがゲートウェイ２０を通過した時刻、これらの差分をアクセス間隔として計測する。
【００３６】
推定部１２ｄは、ヘッダ情報記憶部１３ａに格納されたリクエストＵＲＬとリソースＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定する。ここで図７の例を用いて、ＵＲＬの接続関係の推定処理について説明する。図７は、ＨＴＴＰリクエスタヘッダからＵＲＬの接続関係を推定する処理を説明する図である。図７の（１）に示すように、ＵＲＬ＿ＡからＵＲＬ＿Ｂが発生しており、さらにＵＲＬ＿ＢからＵＲＬ＿Ｃが発生している。よって、推定部１２ｄは、ＵＲＬ＿ＡからＵＲＬ＿Ｂ、ＵＲＬ＿Ｃへの一連のアクセスが発生したと推定する。
【００３７】
また、推定部１２ｄは、図７の（２）に示すように、ＵＲＬ＿ＡからＵＲＬ＿Ｂが発生しており、同様にＵＲＬ＿ＣからＵＲＬ＿Ｂへアクセスが発生していることから、推定部１２ｄは、ＵＲＬ＿ＢがＵＲＬ＿ＡおよびＵＲＬ＿Ｃの双方から参照されていると推定する。このように、ヘッダ情報記憶部１３ａに格納されたリクエストＵＲＬとリソースＵＲＬの情報から、どのＵＲＬからどのＵＲＬへ派生したかを一意に推定できる。
【００３８】
ここで、あるＵＲＬから派生する派生ＵＲＬについて説明する。派生ＵＲＬとは、あるＵＲＬを読み込むと自動的にアクセスする他のＵＲＬである。例えば、画像ファイルの読み込み、スクリプトファイルの読み込み、フレームの読み込みなどである。これらはＨＴＭＬにタグとして記述してその読み込み先ＵＲＬをタグの属性として設定しておくことで自動的にＷｅｂブラウザのアクセスを発生する。具体的には、画像であれば“＜img  src=”URL”/＞”，スクリプトの読み込みであれば、“＜script  src=”URL”…/>”である。そのＨＴＭＬを読み込んだＷｅｂブラウザは、自動的に指定されたＵＲＬから指定のコンテンツをＷｅｂページのパーツとして読み込み、それら全体でＷｅｂページを構築する。
【００３９】
また、推定部１２ｄは、ＵＲＬ同士の接続関係を推定するとともに、計測部１２ｃによって計測されたアクセス間隔を用いて、クライアント３０のアクセスがクリックによるアクセスか、自動的に発生するアクセスであるかを推定する。具体的には、推定部１２ｄは、アクセス間隔が所定の閾値より大きい場合には、ハイパーリンクをユーザがクリックしたことによるアクセスであると推定し、また、アクセス間隔が所定の閾値より小さい場合には、自動的に発生するアクセスであると推定する。
【００４０】
つまり、推定部１２ｄは、ハイパーリンクによる遷移と、自動的なアクセスによる遷移を判別するため、ＵＲＬの接続関係とアクセス先およびアクセス元のアクセス間隔を利用する。一般的に、自動的なＷｅｂアクセスはアクセス元のＵＲＬを読み込んだ直後に発生するためアクセス間隔は短いといえる。一方、ハイパーリンクによるＷｅｂアクセスは、アクセス元のＵＲＬを読み込んだ後、当該ハイパーリンクをユーザがマウスもしくはキーボード操作によりクリックすることで発生するため、自動的なＷｅｂアクセスよりもアクセス間隔は長い。よって、アクセス間隔に対して所定の閾値を設定し、所定の閾値を超える場合はハイパーリンクによるＷｅｂアクセス、所定の閾値を下回る場合は自動的なＷｅｂアクセスと推定することとしている。
【００４１】
ここで図８の例を用いて、ＵＲＬの接続関係から入口ＵＲＬを特定する処理について説明する。図８は、ＵＲＬの接続関係から入口ＵＲＬを特定する処理を説明する図である。図８の例では、閾値が「１．０秒」であるものとする。また、図８における矢印の数字は、アクセス間隔を示している。例えば、図８に示すように、アクセス元ＵＲＬ＿Ｃとアクセス先ＵＲＬ＿Ｅとのアクセス間隔が「５．０秒」であり、閾値の「１．０秒」を越えているため、ハイパーリンクによる遷移と推定する。また、その他のアクセス間隔は、閾値の「１．０秒」を下回るので、自動的なＷｅｂアクセスと推定する。
【００４２】
特定部１２ｅは、推定部１２ｄによって推定されたＵＲＬ同士の接続関係に基づいて、サイトへアクセスする際に最初にアクセスするＵＲＬである入口ＵＲＬを特定する。例えば、図８の例では、特定部１２ｅは、入口ＵＲＬとして、最初にアクセスされたＵＲＬ＿Ａを特定する。また、特定部１２ｅは、接続関係だけをみるとＵＲＬ＿Ａが入口ＵＲＬであると推測できるが、アクセス間隔が閾値よりも大きいＵＲＬ＿ＣとＵＲＬ＿Ｅとの間の接続関係については、ハイパーリンクによる遷移とみなして、ＵＲＬ＿Ｅも入口ＵＲＬと特定する。
【００４３】
なお、例えば、クライアント３０が直接ＵＲＬ＿Ｃにアクセスした場合は、ＵＲＬ＿Ｃが入口ＵＲＬになる。ただし、ＵＲＬ＿ＡからみるとＵＲＬ＿Ｃは自動的にアクセスするため、再検査を行う場合にＵＲＬ＿Ａから自動的にＵＲＬ＿Ｃが派生するため、改めてＵＲＬ＿Ｃを検査する必要はない。つまり、ＵＲＬのアクセス遷移に基づいて自動的にアクセスが派生するＵＲＬ群における入口ＵＲＬを特定する方法としては、ＵＲＬアクセス遷移の状況に応じて、ＵＲＬ＿ＡまたはＵＲＬ＿Ｃどちらも入口ＵＲＬとなる場合がありえる。
【００４４】
［推定装置による処理手順］
次に、図９を用いて、第一の実施形態に係る推定装置１０による処理を説明する。図９は、第一の実施の形態に係る推定装置による処理の流れの一例を説明するためのフローチャートである。
【００４５】
図９に示すように、推定装置１０の抽出部１２ａは、クライアント３０とサーバ４０との間で通信される通信パケットをゲートウェイ２０から受信すると（ステップＳ１０１肯定）、パケットのヘッダ情報を取得する（ステップＳ１０２）。
【００４６】
そして、抽出部１２ａは、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する（ステップＳ１０３）。具体的には、抽出部１２ａは、クライアント３０とサーバ４０との間で行われるＨＴＴＰ通信において送受信されるパケットのヘッダ情報であるＨＴＴＰリクエストヘッダを解析し、該ＨＴＴＰリクエストヘッダのリクエストラインに含まれるアクセス先ＵＲＬである「リクエストＵＲＬ」と、ヘッダ情報のリファラーに含まれるアクセス元ＵＲＬである「リソースＵＲＬ」とを抽出する。
【００４７】
そして、格納部１２ｂは、抽出部によって抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けてヘッダ情報記憶部１３ａに格納する（ステップＳ１０４）。続いて、計測部１２ｃは、クライアント３０が、アクセス元ＵＲＬへアクセスした時間とアクセス先ＵＲＬへアクセスした時間との差分であるアクセス間隔を計測する（ステップＳ１０５）。具体的には、計測部１２ｃは、アクセス元ＵＲＬのリクエストに対するＷｅｂサイトからのリプライがゲートウェイ２０を通過した時刻と、アクセス元ＵＲＬがリファラーとして設定されたアクセス先ＵＲＬのリクエストがゲートウェイ２０を通過した時刻、これらの差分をアクセス間隔として計測する。
【００４８】
そして、推定部１２ｄは、ヘッダ情報記憶部１３ａに格納されたリクエストＵＲＬとリソースＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定する（ステップＳ１０６）。また、推定部１２ｄは、ＵＲＬ同士の接続関係を推定するとともに、計測部１２ｃによって計測されたアクセス間隔を用いて、クライアント３０のアクセスがクリックによるアクセスか、自動的に発生するアクセスであるかを推定する（ステップＳ１０７）。
【００４９】
その後、特定部１２ｅは、推定部によって推定された前記ＵＲＬ同士の接続関係に基づいて、サイトへアクセスする際に最初にアクセスするＵＲＬである入口ＵＲＬを特定する（ステップＳ１０８）。
【００５０】
[第一の実施形態に係る推定装置による効果]
上述してきたように、第一の実施形態に係る推定装置１０では、クライアント３０がサーバ４０により提供されるサイトのＵＲＬへアクセスした場合に、クライアント３０とサーバ４０との間で通信されるパケットのヘッダ情報を取得し、該ヘッダ情報からアクセス元ＵＲＬとアクセス先ＵＲＬとを抽出する。そして、推定装置１０は、抽出されたアクセス元ＵＲＬとアクセス先ＵＲＬとを対応付けてヘッダ情報記憶部１３ａに格納する。続いて、推定装置１０は、ヘッダ情報記憶部１３ａに格納されたアクセス元ＵＲＬとアクセス先ＵＲＬとを用いて、ＵＲＬ同士の接続関係を推定する。そして、推定装置１０は、推定されたＵＲＬ同士の接続関係に基づいて、サイトへアクセスする際に最初にアクセスするＵＲＬである入口ＵＲＬを特定する。このように、Ｗｅｂアクセス時のヘッダ情報のみを抽出することにより少ない情報で、効率的にＵＲＬ同士の接続関係を推定することが出来る結果、入り口ＵＲＬを効率的に特定し、Ｗｅｂページの構造を効率的に把握することが可能である。
【００５１】
また、第一の実施形態に係る推定装置１０では、クライアント３０が、アクセス元ＵＲＬへアクセスした時間とアクセス先ＵＲＬへアクセスした時間との差分を計測する。そして、推定装置１０は、ＵＲＬ同士の接続関係を推定するとともに、計測された差分を用いて、クライアント３０のアクセスがクリックによるアクセスか、自動的に発生するアクセスであるかを推定する。これにより、推定装置１０は、クリックによるアクセスか、自動的に発生するアクセスかを適切に判別することが可能となり、入り口ＵＲＬを適切に特定し、Ｗｅｂページの構造を適切に把握することが可能である。
【００５２】
また、第一の実施形態に係る推定装置１０では、クライアント３０とサーバ４０との間で通信されるパケットのヘッダ情報を解析し、該ヘッダ情報のリクエストラインに含まれるアクセス先ＵＲＬと、ヘッダ情報のリファラーに含まれるアクセス元ＵＲＬとを抽出する。これにより、推定装置１０は、Ｗｅｂアクセス時のヘッダ情報のみを抽出することにより少ない情報で、効率的にＵＲＬ同士の接続関係を推定することが可能である。
【００５３】
［推定装置の接続関係等］
上記実施形態では、推定装置１０がゲートウェイ２０に接続されている場合を説明したが、これに限定されるものではなく、クライアント３０と接続されていてもよい。具体的には、図１０に示すように、推定装置１０は、特定のＬＡＮに配置された各クライアント装置３０Ａ〜３０Ｃにそれぞれ接続されており、各クライアント装置３０Ａ〜３０Ｃからサーバ４０との間で通信されるパケットを受信する。
【００５４】
また、クライアント３０と接続されている推定装置１０が計測するアクセス間隔について図１１を用いて説明する。図１１に示すように、推定装置１０は、ＵＲＬ＿Ａのリクエストに対するＷｅｂサイトからのリプライを受信した時刻と、ＵＲＬ＿Ａがリファラーとして設定されたＵＲＬ＿Ｂのリクエストが送信された時刻、これらの差分をアクセス間隔として計測する。
【００５５】
また、上記実施形態では、通信システム１００に推定装置１０が設けられている場合を説明したが、通信システム１００内の装置が推定装置１０の機能を有するようにしてもよい。例えば、図１２に示すように、ゲートウェイ２０が推定装置１０と同様の機能を有してもよい。また、図１３に示すように、各クライアント３０Ａ〜３０Ｃそれぞれが推定装置１０と同様の機能を有するようにしてもよい。これによれば、通信システム１００に推定装置１０を新たに設けることなく、入り口ＵＲＬを効率的に特定し、Ｗｅｂページの構造を効率的に把握することが可能である。
【００５６】
［システム構成］
また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
【００５７】
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。
【００５８】
［プログラム］
また、上記実施形態において説明した推定装置１０が実行する処理をコンピュータが実行可能な言語で記述したプログラムを作成することもできる。例えば、実施形態１に係る推定装置１０が実行する処理をコンピュータが実行可能な言語で記述した推定プログラムを作成することもできる。この場合、コンピュータが推定プログラムを実行することにより、上記実施形態と同様の効果を得ることができる。さらに、かかる推定プログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録され推定プログラムをコンピュータに読み込ませて実行することにより上記実施形態１と同様の処理を実現してもよい。以下に、図２に示した推定装置１０と同様の機能を実現する推定プログラムを実行するコンピュータの一例を説明する。
【００５９】
図１４は、推定プログラムを実行するコンピュータ１０００を示す図である。図１４に例示するように、コンピュータ１０００は、例えば、メモリ１０１０と、ＣＰＵ１０２０と、ハードディスクドライブインタフェース１０３０と、ディスクドライブインタフェース１０４０と、シリアルポートインタフェース１０５０と、ビデオアダプタ１０６０と、ネットワークインタフェース１０７０とを有し、これらの各部はバス１０８０によって接続される。
【００６０】
メモリ１０１０は、図１４に例示するように、ＲＯＭ（Read  Only  Memory）１０１１及びＲＡＭ１０１２を含む。ＲＯＭ１０１１は、例えば、ＢＩＯＳ（Basic  Input  Output  System）等のブートプログラムを記憶する。ハードディスクドライブインタフェース１０３０は、図１４に例示するように、ハードディスクドライブ１０３１に接続される。ディスクドライブインタフェース１０４０は、図１４に例示するように、ディスクドライブ１０４１に接続される。例えば磁気ディスクや光ディスク等の着脱可能な記憶媒体が、ディスクドライブに挿入される。シリアルポートインタフェース１０５０は、図１４に例示するように、例えばマウス１０５１、キーボード１０５２に接続される。ビデオアダプタ１０６０は、図１４に例示するように、例えばディスプレイ１０６１に接続される。
【００６１】
ここで、図１４に例示するように、ハードディスクドライブ１０３１は、例えば、ＯＳ１０９１、アプリケーションプログラム１０９２、プログラムモジュール１０９３、プログラムデータ１０９４を記憶する。すなわち、上記の推定プログラムは、コンピュータ１０００によって実行される指令が記述されたプログラムモジュールとして、例えばハードディスクドライブ１０３１に記憶される。
【００６２】
また、上記実施形態で説明した各種データは、プログラムデータとして、例えばメモリ１０１０やハードディスクドライブ１０３１に記憶される。そして、ＣＰＵ１０２０が、メモリ１０１０やハードディスクドライブ１０３１に記憶されたプログラムモジュール１０９３やプログラムデータ１０９４を必要に応じてＲＡＭ１０１２に読み出し、各種手順を実行する。
【００６３】
なお、推定プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ハードディスクドライブ１０３１に記憶される場合に限られず、例えば着脱可能な記憶媒体に記憶され、ディスクドライブ等を介してＣＰＵ１０２０によって読み出されてもよい。あるいは、推定プログラムに係るプログラムモジュール１０９３やプログラムデータ１０９４は、ネットワーク（ＬＡＮ（Local  Area  Network）、ＷＡＮ（Wide  Area  Network）等）を介して接続された他のコンピュータに記憶され、ネットワークインタフェース１０７０を介してＣＰＵ１０２０によって読み出されてもよい。
【符号の説明】
【００６４】
１０  推定装置
１１  通信制御部
１２  制御部
１２ａ  抽出部
１２ｂ  格納部
１２ｃ  計測部
１２ｄ  推定部
１２ｅ  特定部
１３  記憶部
１３ａ  ヘッダ情報記憶部
１３ｂ  接続関係記憶部
２０  ゲートウェイ
３０Ａ〜３０Ｃ  クライアント
４０  サーバ
５０  インターネット
１００  通信システム
【図１】
0005801256.tif 000002
【図２】
0005801256.tif 000003
【図３】
0005801256.tif 000004
【図４】
0005801256.tif 000005
【図５】
0005801256.tif 000006
【図６】
0005801256.tif 000007
【図７】
0005801256.tif 000008
【図８】
0005801256.tif 000009
【図９】
0005801256.tif 000010
【図１０】
0005801256.tif 000011
【図１１】
0005801256.tif 000012
【図１２】
0005801256.tif 000013
【図１３】
0005801256.tif 000014
【図１４】
0005801256.tif 000015
【図１５】
0005801256.tif 000016
【図１６】
0005801256.tif 000017