WO2019159822A1

WO2019159822A1 - アクセス元分類装置、アクセス元分類方法及びプログラム

Info

Publication number: WO2019159822A1
Application number: PCT/JP2019/004500
Authority: WO
Inventors: 友香駒井; 小林　正裕; 薫明原田; 石橋　圭介; 川原　亮一
Original assignee: 日本電信電話株式会社
Priority date: 2018-02-13
Filing date: 2019-02-07
Publication date: 2019-08-22
Also published as: JP2019139587A; JP6866322B2; US20210051107A1; US11290384B2

Abstract

アクセス元分類装置は、複数のアクセス元のうちのいずれかのアクセス元による複数のサービスのうちのいずれかのサービスへのアクセスを示すアクセスログの集合に基づいて、各アクセス元による各サービスへのアクセスに関する統計量を算出する第１の算出部と、サービスごとに、当該サービスに係るアクセスログに基づいて、アクセス元別の当該サービスへのアクセス状況の分布を示す指標値を算出し、指標値に基づいて、一部のサービスを抽出する抽出部と、統計量に対してクラスタリング手法を適用して、各アクセス元と抽出部によって抽出された各サービスとの関連度を算出する第２の算出部と、関連度に基づいて、抽出部によって抽出されたいずれかのサービスへのアクセス元を、それぞれが１以上のアクセス元を含むいずれかのグループに分類する分類部と、を有することで、サービスへのアクセス元の端末種別の特定の効率化を支援する。

Description

アクセス元分類装置、アクセス元分類方法及びプログラム

　本発明は、アクセス元分類装置、アクセス元分類方法及びプログラムに関する。

　近年、インターネットのトラヒックを扱う通信事業者等において、ネットワークの輻輳による通信品質の劣化を回避するため、ネットワークの状況を逐次監視し、適切な通信制御や設備計画を行う必要性が生じている。

　特に、適切な通信制御や設備計画を行うための根拠として、トラヒックの発生要因を詳細に把握することが重要となっている。利用端末種別によって特有のアプリケーションのアップデートやサービスの利用傾向があるため、ユーザ（クライアント）の利用端末種別を把握することはトラヒックの発生要因を把握する上で有効である。

　ユーザの利用端末種別を把握するための代表的な手法として、ＤＰＩ（Deep Packet Inspection）によるトラヒック収集・分析方式が存在する。ＤＰＩは、通信のアプリケーションにおけるヘッダ情報を参照する測定方式である。特に、ＨＴＴＰ通信では、ヘッダに含まれるユーザ・エージェントを参照することで利用端末種別を識別できる。

　しかし、ＤＰＩ装置のコストが高いため、通信トラヒック量が多い通信事業者では網羅的な監視が困難である。さらに、ＤＰＩは、通信におけるデータ格納領域（ペイロード）を参照する方式であるため、ネットワーク事業者によってはサービス約款等により実施困難なケースがあり得る。また、ＨＴＴＰＳ通信などペイロードが暗号化されている場合には、ＤＰＩによってユーザ・エージェントを参照することが困難となる。

　上記を解決するために、ＤＮＳクエリを収集し、特定のＯＳ（Operating System）を搭載した端末の数を推定する方式が提案されている（例えば、非特許文献１参照）。この方式は、ネットワーク監視のための装置を全域に配置することなく、ネットワーク内のＤＮＳサーバ付近においてＤＮＳトラヒックを監視し、ＤＮＳクエリにみられるＯＳ毎の特徴を用いて、搭載ＯＳ毎の端末数を推定する。各ＯＳにはそれぞれ、他のＯＳがＤＮＳクエリを送信しない特有のドメインがあり、当該ドメインに対するＤＮＳクエリは一定の時間間隔で送信される特徴がある。そのため、特定のＯＳを搭載した端末数の推定は、事前に把握したＯＳ特有のドメインの送信周期に基づいて行う。このとき、送信周期が想定していたものとずれた場合にも端末数を推定することができる。

DNSトラフィックによるPassive OS Fingerprintingに関する検討, 松中隆志, 山田明, 窪田歩, 2012年電子情報通信学会通信ソサイエティ大会, B-6-76, 2012年9月.

　しかしながら、非特許文献１の方式ではＯＳ特有のドメインを事前に把握しておく必要がある。また、非特許文献１の方式では特有のドメインの送信周期を事前に取得してパラメータとして用いる必要があるが、非特許文献１において、同じＯＳであっても製造ベンダが異なると送信周期にばらつきがあることが報告されており、推定を行う全端末種別に対して送信周期を調査しなければならない。これらにより、特定の対象となる端末全ての事前調査および、新製品の発売開始などにより新規の端末が出現するたびに追加の調査が必要になり、非特許文献１に記載される手法のような全数調査に基づく識別は非効率である。

　本発明は、上記の点に鑑みてなされたものであって、サービスへのアクセス元の端末種別の特定の効率化を支援することを目的とする。

　そこで上記課題を解決するため、アクセス元分類装置は、複数のアクセス元のうちのいずれかのアクセス元による複数のサービスのうちのいずれかのサービスへのアクセスを示すアクセスログの集合に基づいて、各アクセス元による各サービスへのアクセスに関する統計量を算出する第１の算出部と、前記サービスごとに、当該サービスに係る前記アクセスログに基づいて、前記アクセス元別の当該サービスへのアクセス状況の分布を示す指標値を算出し、前記サービスごとに算出した前記指標値に基づいて、前記複数のサービスから一部のサービスを抽出する抽出部と、前記統計量に対してクラスタリング手法を適用して、各アクセス元と前記抽出部によって抽出された各サービスとの関連度を算出する第２の算出部と、前記関連度に基づいて、前記抽出部によって抽出されたいずれかのサービスへのアクセス元を、それぞれが１以上のアクセス元を含むいずれかのグループに分類する分類部と、を有する。

　サービスへのアクセス元の端末種別の特定の効率化を支援することができる。

本発明の実施の形態におけるシステム構成例を示す図である。トラヒック収集装置２０の動作例を示す図である。本発明の実施の形態における分析装置１０のハードウェア構成例を示す図である。本発明の実施の形態における分析装置１０の機能構成例を示す図である。分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。２次元配列の一例を示す図である。クラスタリング手法の出力結果の一例を示す図である。関連度からラベルへの置換結果の一例を示す図である。ラベルが一致するユーザＩＤを同じクラスタとしてクラスタリングする例を示す図である。

　以下、図面に基づいて本発明の実施の形態を説明する。まず、本実施の形態において用いる各用語を以下のように定義する。

　「通信」又は「トラヒック」の各用語は、いずれも「通信トラヒック」と同義であり、ネットワーク上を流れる通信データをいう。

　「端末種別」とは、サービスへのアクセス元である端末（後述のユーザ端末３０）に搭載されているオペレーションシステム（ＯＳ）やユーザ端末３０の形態（デスクトップＰＣ、ノートＰＣ、モバイル端末など）のことをいう。

　「ＤＮＳクエリ」とは、ユーザ端末３０からＤＮＳ（Domain Name System）サーバへ名前解決（ＤＮＳを用いてドメイン名から対応するＩＰアドレスを取得する処理）を行った際の問い合わせのことである。

　「アクセス」とは、ユーザ端末３０における通信の発生をいう。

　「サービス」とは、コンテンツの配信元が提供するサービスをいう。コンテンツサービスプロバイダ（ＣＳＰ）がサーバにより提供しているものである。

　本実施の形態では、サービスへのアクセス元の端末種別と利用サービスとの間には相関があることに注目する。本実施の形態では、ある一定期間に観測されたサービスへのアクセスログを、アクセス元と利用サービスとの相関に基づいて分析することで、アクセス元を端末種別の類似性に基づいて分類する。

　このような分類に基づいて、ユーザが利用するユーザ端末３０の端末種別を特定又は推定することができる。具体的には、端末種別の同じアクセス元でグルーピングすることにより、アクセス元の数が非常に多い場合でもグループ内の一部のアクセス元の特徴を追うことでグループ全体の挙動を把握できる。

　これにより、新規なユーザ端末３０が出現しても、当該ユーザ端末３０が既存のユーザ端末３０（アクセス元）と同じ特徴を持っていれば、識別済みのグループに所属することが期待され、追加の調査が不要となる。また、新規なユーザ端末３０の発生後に識別不能なグループに所属するユーザ端末３０が増えた場合にのみ、当該ユーザ端末３０について調査することで、効率化が図られる。

　図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、ユーザ端末３０ａ、ユーザ端末３０ｂ及びユーザ端末３０ｃ等の複数のユーザ端末３０は、ＬＡＮ（Local Area Network）又はインターネット等のネットワークを介して、ＤＮＳキャッシュサーバ４０及び１以上のコンテンツサーバ５０等に接続される。ＤＮＳキャッシュサーバ４０は、一般的なＤＮＳキャッシュサーバ４０である。コンテンツサーバ５０は、ユーザ端末３０に対してサービスを提供するコンピュータである。１つのコンテンツサーバ５０が複数のサービスを提供してもよい。

　また、ユーザ端末３０とＤＮＳキャッシュサーバ４０又はコンテンツサーバ５０との通信トラヒックを参照可能なように、トラヒック収集装置２０が配置される。トラヒック収集装置２０は、例えば、ユーザ端末３０からサービス（コンテンツサーバ５０）へのアクセスを含む通信ログ（以下、「アクセスログ」という。）を収集し、蓄積する。サービスへのアクセスログとは、サービスに対する直接的なトラヒックに関するログに限られない。例えば、ＤＮＳクエリのログ、ＤＮＳキャッシュのログなどがアクセスログとされてもよい。トラヒック収集装置２０は、例えば、ネットワークのゲートウェイ装置のように、ユーザ端末３０とＤＮＳキャッシュサーバ４０及びコンテンツサーバ５０とを接続するネットワーク回線上に挿入されてもよいし、タップやミラーなどの方法によって外付けされる形態によって設置されてもよい。アクセスログの収集箇所は、ユーザ端末３０とサーバ間の通信を含む条件を満たせば特に限定されない、例えば、コンテンツサーバ５０又はＤＮＳキャッシュサーバ４０等においてアクセスログが収集されてもよい。すなわち、これらのサーバが、トラヒック収集装置２０を兼ねてもよい。

　トラヒック収集装置２０には、ＬＡＮ又はインターネット等のネットワークを介して分析装置１０が接続される。分析装置１０は、トラヒック収集装置２０に蓄積されたアクセスログを参照して分析し、分析結果を出力する。なお、本実施の形態では、トラヒック収集装置２０と分析装置１０とが別個の装置によって構成される例について説明するが、トラヒック収集装置２０と分析装置１０とは、同一の汎用計算装置（コンピュータ）を用いて実現されてもよい。

　図２は、トラヒック収集装置２０の動作例を示す図である。図２において、トラヒック収集装置２０は、ネットワーク間の一切の通信に影響しないようにしながらアクセスログを収集・蓄積する。アクセスログの記録先としてはトラヒック収集装置２０のメインメモリや記録装置を想定しているが、任意である。本実施の形態では、以下の形式でアクセスログが収集されるものとする。

　タイムスタンプは、ユーザ端末３０がサービスにアクセスした日時である。ユーザＩＤは、アクセス元のユーザ端末３０の識別子（例えば、ＩＰアドレスである。）。ここで、ユーザＩＤとユーザ端末３０とは、必ずしも１対１であるとは限らない。例えば、複数のユーザ端末３０によって同じＩＰアドレスが共用される可能性も有るからである。本実施の形態では、このような状況も許容される。サービス名は、アクセス先のサービスの識別子である。具体的には、ＨＴＴＰトラヒックの場合はホスト名、ＤＮＳクエリにおいてはＦＱＤＮ（Fully Qualified Domain Name）がサービス名の一例となる。観測値は、ユーザ端末３０がサービスにアクセスした際に観測できる値である。例えば、サービスに対する直接的なトラヒックのログの場合、該当する通信で発生したトラヒック量をこの観測値とすることが可能である。但し、この観測値は任意であり、観測値を省いてアクセスログとすることも可能である。

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

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

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

　図４は、本発明の実施の形態における分析装置１０の機能構成例を示す図である。図４において、分析装置１０は、前処理部１１及び分析部１２等を有する。これら各部は、分析装置１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。

　前処理部１１は、アクセスログについて、各ユーザＩＤの端末種別の分類及び特定を目的とした、分析に適したデータに加工を行う。

　分析部１２は、加工したデータを入力データとして分析を行い、ユーザＩＤをクラスタリングする。

　以下、分析装置１０が実行する処理手順について説明する。図５は、分析装置１０が実行する処理手順の一例を説明するためのフローチャートである。

　ステップＳ１０１において、前処理部１１は、期間Ｔ（＝終了時刻Ｔｅ－開始時刻Ｔｓ）のアクセスログの集合をタイムスタンプを参照してトラヒック収集装置２０から取得する。Ｔは、分析を行う者により事前に設定される任意の数値である。Ｔが短いほど、該当の時間帯において利用されているユーザ端末３０を把握できる。しかし、ユーザが複数のユーザ端末３０を所持していてもＴ内に同時に利用されていない場合、ユーザが利用するユーザ端末３０を網羅的に把握するという点では不十分となってしまう。一方、Ｔを長くすると、ユーザの複数端末利用を把握することができると考えられるが、必要とするデータ量が増大し、収集や分析にかかるコストが大きくなってしまう。ここで、ユーザによるユーザ端末３０の使用には周期性があると考えられる。例えば、朝はスマートフォンを利用し夜はＰＣを利用する、又は平日はスマートフォンのみ利用し休日はデスクトップＰＣを利用する、などである。そのため、Ｔは１日や１週間などの周期性を考慮して決定されるとよい。

　続いて、前処理部１１は、取得したアクセスログの集合より、分析対象とするアクセスログ群を抽出する（Ｓ１０２）。

　サービスへのアクセス元の端末種別に基づいて、アクセス元をクラスタリングするためには、端末種別と関連のあるサービスに絞ってサービスのアクセスログを用いることが効果的である。一方で、サービスの中には、異なる複数の端末種別からアクセスされ、特定の端末種別との関連が低いサービスが含まれる。このようなサービスに関するアクセスログを、取得したアクセスログの集合から除外することにより、クラスタリングの精度向上を見込むことができる。

　ここで、端末種別と関連のあるサービスは、例えば、ＯＳの更新プログラムやＮＴＰ（Network Time Protocol）に関するサービスを含み、端末が自律的にアクセスしているサービスである場合が多いと考えられる。また、端末種別と関連の低いサービスは、異なる複数の端末種別からアクセスされる、例えば、検索サービスやＳＮＳ（Social Networking Service）等が含まれ、ユーザが意図して利用（アクセス）しているサービス、つまりユーザ行動に関連の強いサービスである場合が多いと考えられる。

　ユーザ端末３０が自律的にアクセスする場合、一定の間隔でアクセスするなど、一定期間（Ｔ）内のサービスへのアクセス回数やアクセス間隔は、ユーザＩＤ間で同程度となる可能性が高い。一方で、ユーザ行動に関連が強いと、アクセス回数や間隔はユーザによって大きく異なる（ユーザによってサービスの利用度合に差がある）ことが考えられる。このことから、各サービスに対するユーザＩＤ毎のアクセス回数や間隔の分布から、サービスと端末種別の関連の強さを推定することができる。

　そこで、まず、前処理部１１は、取得したアクセスログの集合から、サービス名ごとに当該サービス名（「サービス名ｚ」とする。）を含むアクセスログを取り出し、取り出したアクセスログについて、ユーザＩＤ別にアクセス回数（もしくは間隔）ｈ_ｚｒ（ｒ：サービスｚへアクセスした各ユーザＩＤ）を算出する。前処理部１１は、サービス名ｚについてユーザＩＤ別に算出したｈ_ｚｒの分布に基づいて、サービス名ｚへのユーザＩＤ別（アクセス元別）のアクセス状況の分布を示す指標値の一例である特徴値σ_ｚを算出する。特徴値σ_ｚは、例えば、分散や標準偏差とすればよい。

　σ_ｚが閾値ｙ以下の場合、前処理部１１は、サービス名ｚを含むアクセスログを「アクセスログ群」に追加する。閾値ｙは、事前に決定され、例えば、算出した全σ_ｚの中央値などを用いてもよい。

　続いて、前処理部１１は、抽出したアクセスログ群に基づいて、ユーザ端末３０（厳密にはユーザＩＤ）とサービスとの関係性を表現する２次元配列を生成する（Ｓ１０３）。２次元配列は、各ユーザ端末３０のユーザＩＤを縦軸の項目とし、各サービス名を横軸の項目とし、アクセスログ群から得られる統計量を要素とするデータである。ユーザ端末３０が利用するサービスには端末種別と紐付く（相関する）特徴やパターンがあると考えられ、このパターンの近いユーザ端末３０同士（ユーザＩＤ同士）をクラスタリングするために適した配列の要素を算出する必要がある。或るユーザＩＤｕの或るサービスｓに対する統計量ｖは例えば以下の（１）～（３）のいずれかの方法によって算出されてもよい。
（１）ユーザＩＤとサービスの利用関係を基にクラスタリングする場合
　ｖ＝ｂｉｎａｒｙ（ｃｏｕｎｔ（ユーザＩＤ＝ｕ　かつ　サービス名＝ｓのアクセスログ））
（２）ユーザＩＤとサービスの利用度を基にクラスタリングする場合
　ｖ＝ｐｒｏｃｅｓｓ（ｃｏｕｎｔ（ユーザ端ＩＤ＝ｕ　かつ　サービス名＝ｓのアクセスログ））
（３）観測値に基づいてクラスタリングする場合
ｖ＝ｐｒｏｃｅｓｓ（ｓｕｍ（ユーザＩＤ＝ｕ　かつ　サービス名＝ｓのアクセスログの観測値））
　なお、ｂｉｎａｒｙ（ｘ）＝１（ｘ＞０）、０（ｘ＝０）である。また、ｃｏｕｎｔ（）は、該当するアクセスログの数である。ｓｕｍ（）は、該当する値の合計である。ｐｒｏｃｅｓｓ（）は、入力された値を大小関係を保持したまま出力する操作であり、例えば、ｐｒｏｃｅｓｓ（ｘ）＝ｘや、ｐｒｏｃｅｓｓ（ｘ）＝ｌｏｇ（ｘ）などが考えられる。

　（１）は、ユーザＩＤをアクセス元とするサービスへのアクセス有無を１／０で表現したものである。（２）は、ユーザＩＤをアクセス元とするサービスへのアクセス回数である。（３）は、ユーザＩＤをアクセス元とするサービスの利用時に発生させたトラヒックの合計値（トラヒック量）である。

　図６は、２次元配列の一例を示す図である。図６には、上記の（１）の方法により生成された２次元配列の例が示されている。なお、図６において、ユーザ端末３０のＩＰアドレスがユーザＩＤの一例とされており、ＦＱＤＮが、サービス名の一例とされている。

　続いて、前処理部１１は、統計量の合計が相対的に大きいｎ個のサービスのみを抽出する（S１０４）。サービスの種類が非常に多い場合、分析に要する計算時間の増大や分析結果の解釈が困難になるなどの問題が発生する可能性が有る。そのため、端末種別と紐づく特徴やパターンに基づいてユーザＩＤのクラスタリングを行う上で、有用なデータを事前に抽出して分析を行うことが有効である。つまり、分析対象とするサービスの数を絞るとよいと考えられる。分析対象とするサービスの数ｎ個は、任意に決定することが可能である。但し、サービスの数を絞ったことにより分析の対象となるユーザＩＤが大幅に減少してしまうのは防ぐべきであるため、一例として、アクセスログ群における全ユーザＩＤのうち、指定したｎ個のサービスに対してｐ個以上のサービスへのアクセス元であるユーザＩＤの割合を表すユーザカバー率Ｃを導入してｎを決定する方法を採用する。ユーザカバー率Ｃが大きいほど多くのユーザＩＤを対象として分析を行うことを表すため、ユーザカバー率Ｃが予め決定されたある閾値ｔｈｒｅｓｈｏｌｄ以上となるようにｎを決定する。

　ここで、大手のサービスは多くのユーザが利用している一方、大半のサービスはごく少数のユーザのみから利用されるなど、利用サービスには偏りがあることが知られている。多くのユーザから利用されているサービスの方が、ユーザ（ユーザＩＤ）とサービスの関連性を多く表現しているため有用である可能性が高い。そのため、例えば、サービスごとの配列の要素の合計が大きいサービスから順に並べ、ユーザカバー率Ｃがｔｈｒｅｓｈｏｌｄ以上を満たすｎ個のサービス（上位ｋ位～（ｋ＋ｎ－１）位）のみに絞ることとすればよい。ステップS１０４は、必須の処理ではないが、データのサイズを縮小し、効果的に分析できると考えられるため、サービスの種類が多いかつ統計量の多いサービスのみで多くのユーザをカバーできる場合には行うことを推奨する。

　例えば、以下が、ｎ個のサービスを抽出するための擬似コードである。

1: [INPUT: 2次元配列A(ユーザ数N×全サービス数), k(自然数), p(n以下の自然数), threshold]
2: Sort service columns in A
3: i = k, C=0
4: While(C<threshold){
5:　　C = count users(count(each value in k th~i th services > 0) ≧p) / N
6:　　A' = add(i th service columns from A)
7:　　i = i+1
8:}
9:［ＯＵＴＰＵＴ：　２次元配列Ａ'（ユーザ端末３０数Ｎ×ｎ）※ｎ＝ｉ－ｋ］

　上記の擬似コードの各行の先頭の「ｘ:」（ｘ=1～9）は、説明の便宜上付与した行番号である。１行目は、図６に示したような２次元配列Ａ、ｋ、ｐ、ｔｈｒｅｓｈｏｌｄが入力パラメータとして与えられる（入力される）ことを意味する。

　２行目は、２次元配列の列を、各列の要素の合計の降順にソートすることを意味する。３行目は、変数ｉをｋで初期化し、ユーザカバー率Ｃを０で初期化することを意味する。

　４行目は、Ｃがｔｈｒｅｓｈｏｌｄ未満である間、５行目から７行目を繰り返すことを意味する。５行目において、「count(each value in k th~i th services > 0)」は、ｋ番目からｉ番目のサービス（列）において０より大きい値の数をカウントすることを意味し、「count users(count(each value in k th~i th services > 0) ≧p)」は、カウントされた値が、ｐ以上であるユーザＩＤ数をカウントすることを意味する。更に、「C = count users(count(each value in k th~i th services > 0) ≧p) / N」は、ユーザＩＤ数のカウント結果をＮで除することで得られる値がＣに代入されることを意味する。

　６行目は、２次元配列Ａにおいてｉ番目のサービス（列）が２次元配列Ａ'に追加されることを意味する。７行目は、ｉに１が加算されることを意味する。

　ステップＳ１０２は、ステップＳ１０３及びステップＳ１０４とは独立であるため、ステップＳ１０４を実施した後にステップＳ１０２を実施されてもよい。その場合、ステップＳ１０１において取得した全アクセスログの集合をアクセスログ群とし、ステップＳ１０３及びＳ１０４を実施した後、ステップＳ１０２について説明した特徴値σ_ｚを算出し、２次元配列Ａ'のうちσ_ｚがｙ以下となるサービス名ｚを持つ列のみが抽出されてもよい。

　続いて、分析部１２は、前処理部１１において加工したデータ（擬似コードにおける２次元配列Ａ'）を入力データとしてクラスタリング手法を適用する（Ｓ１０５）。

　ここで、クラスタリング手法は、因子分析、ＮＭＦ（Non-negative Matrix Factorization）など、２次元配列を入力としてユーザＩＤをグルーピングできる手法であれば、任意の手法を適用可能である。因子分析については、例えば、「Survey on Independent Component Analysis, Aapo Hyvarinen, Neural Computing Surveys 2, pp. 94-128, 1999.」等が参考とされてもよい。また、ＮＭＦについては、例えば、「Document Clustering Based on Non-negative Matrix Factorization, Wei Xu, Xin Liu, and Yihong Gong, Proc. of Int'l ACM SIGIR Conf. on Research and Development in Information Retrieval, pp. 267-273, 2003.」等が参考とされてもよい。

　図７は、クラスタリング手法の出力結果の一例を示す図である。すなわち、図７は、ステップＳ１０５において出力されるデータの一例を示す。図７に示されるように、クラスタリング手法の出力結果（算出結果）は、ユーザＩＤと任意の数の因子（グループ）との関連度を２次元配列で表現したものである。図７は、ＤＮＳクエリのアクセスログを因子分析によって分析した場合の出力結果の一例を示す。因子数（グループの数）ｍは、クラスタリング手法に適した方法で決定されればよい。

　続いて、分析部１２は、クラスタリング手法の出力結果である２次元配列の各要素を関連度に基づいたラベルに置換する（Ｓ１０６）。例えば、或るユーザＩＤにおいて最も大きい関連度となるグループｅのラベルＬ（ユーザＩＤ，グループｅ）＝１、Ｌ（ユーザＩＤ，ｅ以外のグループ）＝０とする。この方法でのラベリングの結果の一例を図８に示す。

　なお、各要素のラベルへの置換は省略も可（例えば、関連度をそのままラベルとして利用することと同義）であり、置換の方法も上記の方法に限定されない。例えば、各グループにおけるラベル数をｆ（ｌａｂｅｌ_０～ｌａｂｅｌ_ｆ－１のラベルへ置換）とし、予め設定した閾値ｂ_１～ｂ_ｆ－１（ｂ_ｊ＜ｂ_ｊ＋１）を用いて、関連度（ユーザＩＤ，グループｗ）＝ｚ、かつ、ｂｊ＜ｚ＜ｂｊ＋１の時、Ｌ（ユーザＩＤ，グループｗ）＝ｌａｂｅｌ_ｊとされてもよい。

　このように、分析結果は、前述したとおりユーザＩＤとグループ（因子）とを軸とし、配列の要素がラベルである２次元配列である（図８参照）。この２次元配列に基づくユーザＩＤのクラスタリング方法は任意であるが、例えば、各グループのラベルが一致するユーザＩＤを同じクラスタとしてクラスタリングするなどがある。ユーザＩＤのクラスタリングの結果において、同じクラスタのユーザＩＤはサービスの利用パターンが類似しており、端末種別も類似しているといえる。

　図９は、ラベルが一致するユーザＩＤを同じクラスタとしてクラスタリングする例を示す図である。図９に示される２次元配列の各要素は、便宜上、図７及び図８とは無関係である。図９のようにラベルに置換された場合、例えば、「ユーザＩＰアドレス１」、「ユーザＩＰアドレス２」、及び「ユーザＩＰアドレス４」に係るユーザＩＤが同じクラスタに分類される。また、「ユーザＩＰアドレス３」及び「ユーザＩＰアドレス６」に係るユーザＩＤが同じクラスタに分類される。

　ユーザＩＤをアクセス元とする利用サービスの相関に基づいてユーザＩＤを分類することで、ユーザＩＤの端末種別の特定に有用なユーザＩＤの分類ができる。分類結果に基づいて各クラスタから代表ユーザＩＤのデータのみを抽出し、任意の学習機を用いることでユーザＩＤの端末種別の特定を容易に実施することができる。学習機については、例えば、「Support Vector Clustering, Asa Ben-Hur, David Horn, Hava T. Siegelmann, and Vladimir Vapnik, Journal of Machine Learning Research 2, pp. 125-137, 2001.」等が参考とされてもよい。

　なお、図５において説明した一連のモデル（処理手順）は、任意のプログラム言語若しくはスクリプト言語又はそれらの組み合わせで実装可能である。

　上述したように、本実施の形態によれば、サービスへのアクセスログを分析することで、先行文献における課題を解決し、利用する端末種別が類似するアクセス元（ユーザＩＤ）をクラスタリングすることができるようになる。クラスタリングすることにより、ユーザ数が非常に多い場合でも、クラスタ内の一部のユーザの特徴を追うことでクラスタ全体の挙動を把握することができる。したがって、端末種別の特定の効率化を支援することができる。

　なお、本実施の形態において、分析装置１０は、アクセス元分類装置の一例である。前処理部１１は、第１の算出部及び抽出部の一例である。分析部１２は、第２の算出部及び分類部の一例である。

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

１０　　　　　分析装置
１１　　　　　前処理部
１２　　　　　分析部
２０　　　　　トラヒック収集装置
３０　　　　　ユーザ端末
４０　　　　　ＤＮＳキャッシュサーバ
５０　　　　　コンテンツサーバ
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
Ｂ　　　　　　バス

Claims

　複数のアクセス元のうちのいずれかのアクセス元による複数のサービスのうちのいずれかのサービスへのアクセスを示すアクセスログの集合に基づいて、各アクセス元による各サービスへのアクセスに関する統計量を算出する第１の算出部と、
　前記サービスごとに、当該サービスに係る前記アクセスログに基づいて、前記アクセス元別の当該サービスへのアクセス状況の分布を示す指標値を算出し、前記サービスごとに算出した前記指標値に基づいて、前記複数のサービスから一部のサービスを抽出する抽出部と、
　前記統計量に対してクラスタリング手法を適用して、各アクセス元と前記抽出部によって抽出された各サービスとの関連度を算出する第２の算出部と、
　前記関連度に基づいて、前記抽出部によって抽出されたいずれかのサービスへのアクセス元を、それぞれが１以上のアクセス元を含むいずれかのグループに分類する分類部と、
を有することを特徴とするアクセス元分類装置。
　前記指標値は、前記アクセス元別の前記サービスへのアクセス回数の分布又は前記アクセス元による前記サービスへのアクセス間隔の分布に基づく分散、又は前記分布に基づく標準偏差である、
ことを特徴とする請求項１記載のアクセス元分類装置。
　前記第２の算出部は、前記複数のサービスのうち前記統計量の合計が相対的に大きい一部のサービスに係る前記統計量に対して前記クラスタリング手法を適用する、
ことを特徴とする請求項１記載のアクセス元分類装置。
　前記統計量は、前記アクセス元による前記サービスへのアクセスの有無、前記アクセス元による前記サービスへのアクセス回数、又は前記アクセス元による前記サービスの利用時のトラヒック量である、
ことを特徴とする請求項１又は２記載のアクセス元分類装置。
　複数のアクセス元のうちのいずれかのアクセス元による複数のサービスのうちのいずれかのサービスへのアクセスを示すアクセスログの集合に基づいて、各アクセス元による各サービスへのアクセスに関する統計量を算出する第１の算出手順と、
　前記サービスごとに、当該サービスに係る前記アクセスログに基づいて、前記アクセス元別の当該サービスへのアクセス状況の分布を示す指標値を算出し、前記サービスごとに算出した前記指標値に基づいて、前記複数のサービスから一部のサービスを抽出する抽出手順と、
　前記統計量に対してクラスタリング手法を適用して、各アクセス元と前記抽出手順において抽出された各サービスとの関連度を算出する第２の算出手順と、
　前記関連度に基づいて、前記抽出手順において抽出されたいずれかのサービスへのアクセス元を、それぞれが１以上のアクセス元を含むいずれかのグループに分類する分類手順と、
をコンピュータが実行することを特徴とするアクセス元分類方法。
　前記指標値は、前記アクセス元別の前記サービスへのアクセス回数の分布又は前記アクセス元による前記サービスへのアクセス間隔の分布に基づく分散、又は前記分布に基づく標準偏差である、
ことを特徴とする請求項５記載のアクセス元分類方法。
　請求項１乃至４いずれか一項記載の各部としてコンピュータを機能させることを特徴とするプログラム。