(57)【特許請求の範囲】
【請求項１】
監視対象の通信パケットの情報を取得する通信監視部と、
前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築する通信フロー構築部と、
前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定するトラヒック判定部と、
前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得する端末個体識別情報分析部と、
前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶する情報記憶部と、
を備える識別装置。
【請求項２】
前記通信パケットの特徴を示す情報は、ネットワーク内識別子の情報を含み、
さらに、前記情報記憶部に記憶される情報に基づいて、同一の端末装置個体であるとされる端末装置ごとに、ネットワーク内識別子の情報を出力する端末個体識別部を備える、
請求項１に記載の識別装置。
【請求項３】
前記通信パケットの特徴を示す情報は、さらに、時刻の情報およびネットワークの情報を含み、
前記端末個体識別部は、前記ネットワーク内識別子の情報を、時刻の情報およびネットワークの情報と共に出力する、
請求項２に記載の識別装置。
【請求項４】
前記端末個体識別情報分析部は、
ＨＴＴＰプロトコルにおけるＵｓｅｒ−Ａｇｅｎｔの情報、
または、ＴＣＰのフィンガプリントの情報、
または、Ｗｅｂブラウザが出力するヘッダの情報、インストール済みのプラグインの情報、およびそのプラグインのバージョンの情報、
または、前記端末装置のクロックスキューの情報、
または、前記端末装置のアクセス先のホストの情報、
または、前記端末装置の動画のアプリケーションの閲覧設定の情報、
のうちの１つ以上を取得する、
請求項１から請求項３のいずれか１項に記載の識別装置。
【請求項５】
通信監視部が、監視対象の通信パケットの情報を取得し、
通信フロー構築部が、前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築し、
トラヒック判定部が、前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定し、
端末個体識別情報分析部が、前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得し、
情報記憶部が、前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶する、
識別方法。
【請求項６】
通信監視部が、監視対象の通信パケットの情報を取得するステップと、
通信フロー構築部が、前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築するステップと、
トラヒック判定部が、前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定するステップと、
端末個体識別情報分析部が、前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得するステップと、
情報記憶部が、前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶するステップと、
をコンピュータに実行させるための識別プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、識別装置、識別方法および識別プログラムに関する。
【背景技術】
【０００２】
通信網において相手となる端末装置のＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）等の種類（種別）を識別する方法が多数提案されてきた。
例えば、非特許文献１に係る技術は、識別したい相手の端末装置に対して通信パケットを送出し、その反応を分析することで、相手の端末装置の種類を識別するものである（非特許文献１参照。）。識別に用いる情報としては、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）の各種のヘッダやオプション等が利用される。
【０００３】
また、上述のような動的に相手の端末装置へ通信パケットを送出する方法に加え、非特許文献２に係る技術のように、相手の端末装置の通信内容を静的に監視することで、相手の端末装置の種類を識別する方法も提案されている（非特許文献２参照。）。この方法においても、端末装置の識別にはＴＣＰ／ＩＰの各種のヘッダやオプション等が利用される。
【０００４】
前述のＴＣＰ／ＩＰの情報を用いた識別は一般にＳｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎ（ＳＰＩ）と呼ばれるが、一方で、より上位のアプリケーション層の情報を用いた識別を行うＤｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎ（ＤＰＩ）と呼ばれる方法もある。
Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎを用いることで、例えば非特許文献３に係る技術のように、アプリケーション層の様々な情報を取得し、相手の端末装置の識別を行うことが可能となる（非特許文献３参照。）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】Ｒｅｍｏｔｅ  ＯＳ  ｄｅｔｅｃｔｉｏｎ  ｖｉａ  ＴＣＰ／ＩＰ  Ｓｔａｃｋ  ＦｉｎｇｅｒＰｒｉｎｔｉｎｇ（２ｎｄ  Ｇｅｎｅｒａｔｉｏｎ）、［ｏｎｌｉｎｅ］、［平成２５年２月１２日検索］、インターネット  ＜ＵＲＬ：ｈｔｔｐ：／／ｎｍａｐ．ｏｒｇ／ｂｏｏｋ／ｏｓｄｅｔｅｃｔ．ｈｔｍｌ＞
【非特許文献２】Ｏｆｆｉｃｉａｌ  ｐ０ｆ  ｈｏｍｅｐａｇｅ、［ｏｎｌｉｎｅ］、［平成２５年２月１２日検索］、インターネット  ＜ＵＲＬ：ｈｔｔｐ：／／ｌｃａｍｔｕｆ．ｃｏｒｅｄｕｍｐ．ｃｘ／ｐ０ｆ．ｓｈｔｍｌ＞
【非特許文献３】Ｄｅｅｐ  ｐａｃｋｅｔ  ｉｎｓｐｅｃｔｉｏｎ  ｍｅｅｔｓ‘Ｎｅｔ  ｎｅｕｔｒａｌｉｔｙ，  ＣＡＬＥＡ、［ｏｎｌｉｎｅ］、［平成２５年２月１２日検索］、インターネット  ＜ＵＲＬ：ｈｔｔｐ：／／ａｒｓｔｅｃｈｎｉｃａ．ｃｏｍ／ｈａｒｄｗａｒｅ／ｎｅｗｓ／２００７／０７／Ｄｅｅｐ−ｐａｃｋｅｔ−ｉｎｓｐｅｃｔｉｏｎ−ｍｅｅｔｓ−ｎｅｔ−ｎｅｕｔｒａｌｉｔｙ．ａｒｓ＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで、端末装置の個体の識別（個体識別）を行うことは、広告やマーケティング等において非常に重要であり、その技術が求められている。しかしながら、従来では、端末装置の個体識別を行う場合には端末装置の利用者が能動的に識別情報（ＩＤ）の登録などを行う必要があり、利用者にとって煩雑な手間になってしまうことも多かった。例えば、従来技術における端末装置の識別方法は、ＯＳの種類の判定などを目的としており、端末装置の個体識別には必ずしも適していなかった。
【０００７】
具体的に、上述した技術のうち、Ｓｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎにおいては、ＴＣＰ／ＩＰの各種のヘッダやオプション等の特徴から、該当する端末装置の種類を識別していた。しかしながら、この手法では、ＯＳ種の分類精度が限界であり、端末装置の個体識別を行うためには不十分であった。
一方、Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎにおいては、Ｓｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎより詳細な情報が得られる可能性があるものの、単純なセッション単位のＤｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎのみで得られる情報は限られており、端末装置の個体識別を行うためには不十分であった。
また、端末装置の個体識別を行う場合には、個体識別の精度を向上することが好ましい。
【０００８】
本発明は、このような事情を考慮してなされたもので、端末装置の個体識別を精度良く行うことができる識別装置、識別方法および識別プログラムを提供することを課題とする。
【課題を解決するための手段】
【０００９】
（１）上記の課題を解決するために、本発明に係る識別装置は、監視対象の通信パケットの情報を取得する通信監視部と、前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築する通信フロー構築部と、前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定するトラヒック判定部と、前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得する端末個体識別情報分析部と、前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶する情報記憶部と、を備える。
【００１０】
（２）本発明は、上記した（１）に記載の識別装置において、前記通信パケットの特徴を示す情報は、ネットワーク内識別子の情報を含み、さらに、前記情報記憶部に記憶される情報に基づいて、同一の端末装置個体であるとされる端末装置ごとに、ネットワーク内識別子の情報を出力する端末個体識別部を備える、構成が用いられてもよい。
【００１１】
（３）本発明は、上記した（２）に記載の識別装置において、前記通信パケットの特徴を示す情報は、さらに、時刻の情報およびネットワークの情報を含み、前記端末個体識別部は、前記ネットワーク内識別子の情報を、時刻の情報およびネットワークの情報と共に出力する、構成が用いられてもよい。
【００１２】
（４）本発明は、上記した（１）から上記した（３）のいずれか１つに記載の識別装置において、前記端末個体識別情報分析部は、ＨＴＴＰプロトコルにおけるＵｓｅｒ−Ａｇｅｎｔの情報、または、ＴＣＰのフィンガプリントの情報、または、Ｗｅｂブラウザが出力するヘッダの情報、インストール済みのプラグインの情報、およびそのプラグインのバージョンの情報、または、前記端末装置のクロックスキューの情報、または、前記端末装置のアクセス先のホストの情報、または、前記端末装置の動画のアプリケーションの閲覧設定の情報、のうちの１つ以上を取得する、構成が用いられてもよい。
【００１３】
（５）上記の課題を解決するために、本発明に係る識別方法は、通信監視部が、監視対象の通信パケットの情報を取得し、通信フロー構築部が、前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築し、トラヒック判定部が、前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定し、端末個体識別情報分析部が、前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得し、情報記憶部が、前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶する。
【００１４】
（６）上記の課題を解決するために、本発明に係る識別プログラムは、通信監視部が、監視対象の通信パケットの情報を取得するステップと、通信フロー構築部が、前記通信監視部により取得される通信パケットの情報に基づいて通信フローを再構築するステップと、トラヒック判定部が、前記通信フロー構築部により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定するステップと、端末個体識別情報分析部が、前記トラヒック判定部により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得するステップと、情報記憶部が、前記端末個体識別情報分析部により取得される情報、および、前記通信監視部により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶するステップと、をコンピュータに実行させるための識別プログラムである。
【発明の効果】
【００１５】
本発明によれば、端末装置の個体識別を精度良く行うことができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の一実施形態に係る識別装置の概略的な構成を示すブロック図である。
【図２】本発明の一実施形態に係る識別装置におけるフォアグラウンドトラヒックとバックグラウンドトラヒックを判定する処理の手順の一例を示すフローチャートである。
【図３】本発明の一実施形態に係る端末識別情報データベースに記憶される端末識別情報の一例を示す図である。
【発明を実施するための形態】
【００１７】
以下、図面を参照し、本発明の実施形態について説明する。
本実施形態では、人（利用者）により行われた操作に起因して発生したと推定されるトラヒックをフォアグラウンドトラヒックと言う。フォアグラウンドトラヒックは、例えば、端末装置を操作する人（利用者）が意識して行った操作により発生したと推定されるトラヒックであるとも言える。
また、本実施形態では、人（利用者）により行われる操作に起因しないで発生したと推定されるトラヒックをバックグラウンドトラヒックと言う。バックグラウンドトラヒックは、例えば、端末装置を操作する人（利用者）が意識しない当該端末装置の動作（処理）により発生したと推定されるトラヒックであるとも言える。
ここで、フォアグラウンドトラヒックと、バックグラウンドトラヒックとしては、それぞれ、人（利用者）により行われた操作に起因して発生したトラヒックと、人（利用者）により行われる操作に起因しないで発生したトラヒックとに完全に区別されて判定されるのが好ましい一例であるが、本実施形態では、この区別（判定）に多少の誤差があってもよく、推定されるものと言っている。このため、例えば、フォアグラウンドトラヒックと、バックグラウンドトラヒックとして、それぞれ、人（利用者）により行われた操作に起因して発生したトラヒックと、人（利用者）により行われる操作に起因しないで発生したトラヒックとに完全に区別されて判定される場合も、本実施形態の一構成例として含む。
なお、本実施形態では、説明の便宜上から、フォアグラウンドトラヒックおよびバックグラウンドトラヒックという名称を用いるが、これらの名称としては、他の任意の名称が用いられてもよい。
また、本実施形態などでは、説明の便宜上から、「分析」という語を用いるが、「分析」の代わりに「解析」などの他の語が用いられてもよい。
【００１８】
図１は、本発明の一実施形態に係る識別装置１の概略的な構成を示すブロック図である。
また、図１は、通信パケットを流す回線２を示す。
本実施形態に係る識別装置１は、通信監視部１１と、通信プロトコル分析部１２と、端末識別情報データベース（情報記憶部）１３と、端末個体識別部１４と、を備える。
通信プロトコル分析部１２は、通信フロー構築部３１と、フローデータベース３２と、トラヒック判定部（フォアグラウンド／バックグラウンドトラヒック判定部）３３と、端末個体識別情報分析部３４を備える。
本実施形態に係る識別装置１では、一例として、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）があらかじめ記憶されたソフトウェア（例えば、プログラム）を実行することで、各種の処理や制御が行われる。
【００１９】
本実施形態に係る識別装置１は、回線２と接続される。
ここで、回線２としては、様々なものが用いられてもよく、例えば、コアネットワークの回線や、サービスプロバイダの回線など、様々なネットワークの回線を用いることができる。
【００２０】
なお、本実施形態に係る通信システムでは、識別装置１は、サーバ装置に設けられている。サーバ装置は、回線２と接続される。
また、本実施形態に係る通信システムでは、回線２に、有線通信を行う端末装置や、基地局装置が接続される。
また、本実施形態に係る通信システムでは、無線通信を行う端末装置が、基地局装置と無線により通信することで、当該基地局装置に接続される回線２と接続される。
このような本実施形態に係る通信システムにおいて、有線通信を行う端末装置や、無線通信を行う端末装置は、回線２を介して、通信パケットを通信（送信や受信）する。
【００２１】
本実施形態に係る識別装置１において行われる動作の例を示す。
通信監視部１１は、回線２と接続され、回線２に流れる通信パケット（例えば、そのネットワーク上に流れる通信パケット）を監視する。
本実施形態では、通信監視部１１は、回線２に流れる通信パケット（例えば、そのネットワーク上に流れる通信パケット）をリアルタイムに監視する。
他の構成例として、通信監視部１１は、オフラインで、外部の記憶装置または外部の通信装置などから、あらかじめ電子ファイル等に保存（記憶）された通信パケットを入力して、この通信パケットを監視対象とすることも可能である。
【００２２】
通信監視部１１は、監視対象となる通信パケットを回線２（他の構成例として、外部の記憶装置または外部の通信装置など）から取得すると、取得した通信パケットの情報を、通信プロトコル分析部１２と、端末識別情報データベース１３に、出力する。
本実施形態では、通信監視部１１により監視される通信パケットは、通信プロトコル分析部１２と端末識別情報データベース１３において端末識別情報のデータベースを作成するために使用される。
【００２３】
通信プロトコル分析部１２では、次のような動作が行われる。
通信フロー構築部３１は、通信監視部１１から入力されて得られた通信パケットに基づいてセッション（通信フロー）を構築（再構築）し、再構築したセッションの情報（フロー情報）をトラヒック判定部３３に出力する。
具体例として、通信フロー構築部３１は、通信パケットの属性（例えば、送信元のＩＰアドレスや送信先（宛先）のＩＰアドレス、送信元のポート番号や送信先のポート番号、プロトコル番号等）が共通である通信パケットを同一の通信フローのものとみなして、１つの通信フローの情報とする。このような１つの通信フローの情報は、例えば、通信時刻と共に、トラヒック判定部３３により、フローデータベース３２に記憶させられてもよい。
【００２４】
ここで、通信フロー構築部３１は、例えば、通信パケットに含まれる送信元を特定する情報（例えば、送信元のアドレス）と、当該通信パケットに含まれる送信先を特定する情報（例えば、送信先のアドレス）との組み合わせが一致する通信パケットの集合を用いて、セッションを再構築する。この場合、例えば、送信元の情報同士が一致するとともに送信先の情報同士が一致する複数の通信パケット（つまり、同一の装置間で同一の方向の通信パケット）が集合させられ、さらに、一方の通信パケットの送信元の情報と他方の通信パケットの送信先の情報とが一致しかつ当該一方の通信パケットの送信先の情報と当該他方の通信パケットの送信元の情報とが一致する２個の通信パケット（つまり、同一の装置間で逆の方向の通信パケット）が集合させられてもよい。
なお、２個の通信パケットの送信元または送信先の情報が互いに一致する場合ばかりでなく、例えば、２個の通信パケットの送信元または送信先の情報が互いに類似する場合においても、これら２個の通信パケットが集合させられてもよい。２個の通信パケットの送信元または送信先の情報が互いに類似する場合としては、例えば、アドレスの一部（例えば、＠より後の一部または全部）が一致するが他の部分が一致しない場合が用いられてもよい。
また、通信フロー構築部３１は、例えば、所定の時間の範囲に通信された複数の通信パケットの集合を用いて、セッションを再構築する。所定の時間の範囲としては、様々な範囲が用いられてもよい。
【００２５】
フローデータベース３２は、フロー情報などを記憶する。ここで、フローデータベース３２には、例えば、初期的にフロー情報などが記憶されてもよく、または、運用時にトラヒック判定部３３によりフロー情報などが記憶されてもよく、または、これらの両方においてフロー情報などが記憶されてもよい。例えば、初期的に記憶されるフロー情報などは、初期的に設定される通信フローなどの事例の情報となり、また、運用時に記憶されるフロー情報は、運用時における学習の結果として得られる通信フローなどの事例の情報となる。
【００２６】
トラヒック判定部３３は、通信フロー構築部３１から入力されるフロー情報に基づいて、当該フロー情報に対応するトラヒックが、フォアグラウンドトラヒックであるか、または、バックグラウンドトラヒックであるかを判定する。そして、トラヒック判定部３３は、バックグラウンドトラヒックであると判定したフロー情報を端末個体識別情報分析部３４に出力し、フォアグラウンドトラヒックであると判定したフロー情報を端末個体識別情報分析部３４に出力しない。つまり、本実施形態では、トラヒック判定部３３は、バックグラウンドトラヒックであると判定したフロー情報のみを抽出して端末個体識別情報分析部３４に出力する。
【００２７】
ここで、トラヒック判定部３３は、上記の判定を行う場合に、フローデータベース３２に記憶されたフロー情報（通信フローの事例の情報）などを参照して用いてもよい。なお、他の構成例として、フローデータベース３２に記憶されるフロー情報などを用いずにトラヒック判定部３３が上記の判定を行う構成では、フローデータベース３２は備えられなくてもよい。
フローデータベース３２に記憶されるフロー情報などは、例えば、トラヒック判定部３３により行われる判定において利用され得る情報を含み、初期的に設定される、または、学習により得られる。このフロー情報などには、トラヒック判定部３３により行われる判定において利用され得る様々な情報が含まれてもよい。
【００２８】
端末個体識別情報分析部３４は、トラヒック判定部３３から入力されたフロー情報（バックグラウンドトラヒックであると判定されたフロー情報）に基づいて、当該フロー情報のプロトコルの情報を分析することで、端末装置の個体を識別するための情報（端末個体識別情報）を分析し、当該分析の結果の情報（端末情報）を端末識別情報データベース１３に出力する。
【００２９】
図２を参照して、本発明の一実施形態に係る識別装置１におけるフォアグラウンドトラヒックとバックグラウンドトラヒックを判定する処理の手順の一例を示す。
図２は、本発明の一実施形態に係る識別装置１におけるフォアグラウンドトラヒックとバックグラウンドトラヒックを判定する処理の手順の一例を示すフローチャートである。
【００３０】
（ステップＳ１）
まず、通信監視部１１は、通信パケットを取得（抽出）する。
（ステップＳ２）
次に、通信フロー構築部３１は、通信監視部１１により取得された通信パケットの情報に基づいて、通信フローを構築（再構築）する。
続いて、トラヒック判定部３３は、通信フロー構築部３１により構築された通信フローの情報（フロー情報）に基づいて、次の（ステップＳ３）〜（ステップＳ８）の処理を行う。
【００３１】
（ステップＳ３）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報について、コンテンツの数を検出し、検出したコンテンツの数が所定の閾値（コンテンツの数に関する閾値）より小さいか否かを判定する。
この判定の結果、トラヒック判定部３３は、検出したコンテンツの数が所定の閾値より小さいと判定した場合には（ＹＥＳ）、ステップＳ４の処理へ移行する。一方、トラヒック判定部３３は、検出したコンテンツの数が所定の閾値以上であると判定した場合には（ＮＯ）、ステップＳ８の処理へ移行する。
ここで、コンテンツの数としては、例えば、同時に取得するコンテンツの数が用いられる。また、コンテンツの数としては、例えば、１つの通信フローに含まれるコンテンツの数が用いられる。
【００３２】
（ステップＳ４）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報について、アクセスサーバの数を検出し、検出したアクセスサーバの数が所定の閾値（アクセスサーバの数に関する閾値）より小さいか否かを判定する。
この判定の結果、トラヒック判定部３３は、検出したアクセスサーバの数が所定の閾値より小さいと判定した場合には（ＹＥＳ）、ステップＳ５の処理へ移行する。一方、トラヒック判定部３３は、検出したアクセスサーバの数が所定の閾値以上であると判定した場合には（ＮＯ）、ステップＳ８の処理へ移行する。
ここで、アクセスサーバの数としては、例えば、同時にアクセスするサーバの数が用いられる。また、アクセスサーバの数としては、例えば、１つの通信フローに含まれるアクセスのサーバの数が用いられる。
【００３３】
（ステップＳ５）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報について、通信の周期性（時系列的な周期性）があるか否かを判定する。
この判定の結果、トラヒック判定部３３は、通信の周期性があると判定した場合には（ＹＥＳ）、ステップＳ６の処理へ移行する。一方、トラヒック判定部３３は、通信の周期性がないと判定した場合には（ＮＯ）、ステップＳ８の処理へ移行する。
ここで、トラヒック判定部３３は、例えば、通信フロー構築部３１により得られたフロー情報について、すべての通信が周期的でなくても、周期的な通信が含まれる場合には、通信の周期性があると判定する、構成が用いられてもよい。
なお、通信の周期性としては、例えば、端末装置からの送信の周期性が用いられてもよく、または、端末装置による受信の周期性が用いられてもよく、または、端末装置からの送信と当該端末装置による受信とを合わせた通信（送受信）の周期性が用いられてもよい。また、通信の周期性としては、例えば、所定の通信の開始時刻に関する周期性、または、所定の通信の時間間隔に関する周期性などが用いられてもよい。
また、周期性の有無を判定するときに用いられる時刻としては、例えば、所定の範囲（例えば、５分や１０分など）でずれ（誤差）が許容されてもよい。
また、周期性の有無を判定する場合に、例えば、フーリエ変換の処理が用いられてもよい。
【００３４】
（ステップＳ６）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報について、アップリンク（ＵＬ：Ｕｐ  Ｌｉｎｋ）の通信パケットの数と、ダウンリンク（ＤＬ：Ｄｏｗｎ  Ｌｉｎｋ）の通信パケットの数を検出する。なお、ＵＬは、端末装置から上位の装置（例えば、基地局装置やサーバなど）へ流れるリンクであり、また、ＤＬは、上位の装置から端末装置へ流れるリンクである。
そして、トラヒック判定部３３は、通信パケットの検出結果に基づいて、｛（ＵＬの通信パケットの数）／（ＤＬの通信パケットの数）｝が所定の閾値Ｃ以下である、または、｛（ＤＬの通信パケットの数）／（ＵＬの通信パケットの数）｝が所定の閾値Ｄ以下である、という条件が満たされるか否かを判定する。なお、所定の閾値Ｃおよび所定の閾値Ｄとしては、それぞれ、様々な値が設定されてもよい。
この判定の結果、トラヒック判定部３３は、上記の条件が満たされると判定した場合には（ＹＥＳ）、ステップＳ７の処理へ移行する。一方、トラヒック判定部３３は、上記の条件が満たされないと判定した場合、つまり、｛（ＵＬの通信パケットの数）／（ＤＬの通信パケットの数）｝が所定の閾値Ｃより大きく、かつ、｛（ＤＬの通信パケットの数）／（ＵＬの通信パケットの数）｝が所定の閾値Ｄより大きいと判定した場合には（ＮＯ）、ステップＳ８の処理へ移行する。
【００３５】
（ステップＳ７）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報に対応する通信トラヒックはバックグラウンドトラヒックであると判定する。そして、トラヒック判定部３３は、本フローの処理を終了する。
（ステップＳ８）
トラヒック判定部３３は、通信フロー構築部３１により得られたフロー情報に対応する通信トラヒックはフォアグラウンドトラヒックであると判定する。そして、トラヒック判定部３３は、本フローの処理を終了する。
【００３６】
ここで、図２の例では、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、コンテンツの数が小さいという推定を用いている。一般的に、フォアグラウンドトラヒックは、バックグラウンドトラヒックと比べて、多くのコンテンツを同時に取得する傾向にある。一例として、フォアグラウンドトラヒックとして、人（利用者）により行われる操作で発生するＷｅｂページの閲覧などのトラヒックがある。
【００３７】
また、図２の例では、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、アクセスサーバの数が小さいという推定を用いている。一般的に、フォアグラウンドトラヒックは、バックグラウンドトラヒックと比べて、多くのコンテンツを同時に取得するために、多くのサーバに同時にアクセスする傾向にある。例えば、１枚のＷｅｂページを作成する場合においても、Ｗｅｂページ内の情報ごとにサーバが異なり得て、多数の送信先（リクエスト先）のサーバから情報を取得することがある。
【００３８】
また、図２の例では、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、周期性があるという推定を用いている。一般的に、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、定期的な通信の有無の観点で、周期性を持つ傾向にある。一例として、バックグラウンドトラヒックとして、人（利用者）により行われる操作とは無関係に（自動的に）発生するソフトウェアの自動更新などのトラヒックがある。
例えば、バックグラウンドトラヒックでは、ＯＳやアプリケーションなどによって、自動的に端末装置からサーバにアクセスして更新情報を取得する周期（例えば、１０分に１回、２０分に１回など）が異なる。一例として、目覚まし時計のアプリケーションでは、１日に１回、端末装置がサーバにアクセスして更新情報を取得するものがあり得る。他の一例として、メールのアプリケーションでは、所定の時間間隔で、端末装置がサーバにアクセスして、受信メールの存在の有無の確認や受信を行う場合がある。
逆に、フォアグラウンドトラヒックでは、人（利用者）により行われる操作に起因して、ランダムなタイミングで、（例えば大量の）トラヒックが発生する。
【００３９】
また、図２の例では、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、ＵＬの通信パケットの数とＤＬの通信パケットの数との差が大きい（比率が偏っている）という推定を用いている。一般的に、バックグラウンドトラヒックは、フォアグラウンドトラヒックと比べて、アップロード量とダウンロード量のバランスに関して、いずれかに偏る傾向にある。一例として、サーバから端末装置へ天気などの情報を配信するサービスでは、ダウンロード量（ＤＬの通信パケットの数）の方が多くなる。逆に、一例として、端末装置からサーバへ人（利用者）の測定情報などを送信してサーバで管理するサービスでは、アップロード量（ＵＬの通信パケットの数）の方が多くなる。
【００４０】
なお、図２の例は一例であり、フォアグラウンドトラヒックとバックグラウンドトラヒックを判定する条件としては、様々な条件が用いられてもよく、また、１個以上の様々な数の条件が用いられてもよい。また、フォアグラウンドトラヒックとバックグラウンドトラヒックを判定する条件としては、様々なパラメータを使用する条件が用いられてもよく、様々な統計的な情報やヒューリスティックな情報が用いられてもよい。また、フォアグラウンドトラヒックとバックグラウンドトラヒックを判定する方法としては、例えば、本実施形態のように、複数のパラメータのそれぞれごとに判定を行うフローが用いられてもよく、または、各パラメータに対して重み付けを与えて総和などした値について判定することで、複数のパラメータについて総合的に判定する方法が用いられてもよい。
【００４１】
フォアグラウンドトラヒックとバックグラウンドトラヒックを判定するための他の観点として、例えば、バックグラウンドトラヒックではアプリケーションごとに端末装置が通信する相手のサーバが１つまたは少数に限られる傾向にあるのに対して、フォアグラウンドトラヒックでは人（利用者）の嗜好に応じて端末装置が通信する相手のサーバが様々となる傾向にある、観点がある。
フォアグラウンドトラヒックとバックグラウンドトラヒックを判定するための他の観点として、例えば、バックグラウンドトラヒックは何らかのパターンを有しており、フォアグラウンドトラヒックは当該パターンを有していない傾向にある、観点がある。
【００４２】
フォアグラウンドトラヒックとバックグラウンドトラヒックを判定する処理の他の例として、送信元の情報および送信先の情報の組み合わせごとにセッションをグループ分けし、グループごとに各セッションの生起タイミングに関する自己相関の計算結果に基づいてセッションを識別する（自己相関が高いとバックグラウンドトラヒックであると判定する）処理が用いられてもよい。また、異なるグループのセッションの間における生起タイミングに関する相互相関の計算結果も考慮してセッションを識別する（相互相関が高いとバックグラウンドトラヒックであると判定する）処理が用いられてもよい。また、バックグラウンドトラヒックであると識別されたセッションとの相互相関が高いセッションをバックグラウンドのものと識別する処理が用いられてもよい。
また、各セッションの生起タイミングの差が小さい場合にはフォアグラウンドトラヒックであると判定する処理が用いられてもよい。また、この処理における比較対象のセッションとしてフォアグラウンドトラヒックであると識別されたものを用いる処理が用いられてもよい。
【００４３】
なお、フォアグラウンドトラヒックの傾向や、バックグラウンドトラヒックの傾向は、例えば、端末装置にインストールされているＯＳやアプリケーションなどに応じて異なり得る。フォアグラウンドトラヒックであってもその傾向を満たさないもの（例えば、バックグラウンドトラヒックの傾向を満たすもの）や、バックグラウンドトラヒックであってもその傾向を満たさないもの（例えば、フォアグラウンドトラヒックの傾向を満たすもの）もあり得るが、大きな傾向としては、ノイズとみなすことが可能であり、実用上で十分な精度の判定が可能である。
【００４４】
次に、端末個体識別情報分析部３４により行われる分析について詳しく説明する。
本実施形態では、バックグラウンドトラヒックであると判定されたフロー情報について、端末個体識別情報分析部３４により行われる分析により、通信プロトコル分析部１２における通信プロトコルの情報の分析の結果が得られる。通信プロトコル分析部１２は、この通信プロトコルの情報の分析により、通信プロトコルの情報中のＯＳ情報などの端末情報を取得する。通信プロトコル分析部１２は、取得した端末情報を端末識別情報データベース１３に出力する。
本実施形態では、通信プロトコル分析部１２は、通信プロトコルの情報の分析に際して、通信プロトコルの情報中のアプリケーションの情報などを取得し、取得したアプリケーションの情報などに基づいて、ＯＳ情報などの端末情報を取得する。この取得は、例えば、類推的に行われてもよい。
【００４５】
ここで、一般に、通信プロトコルの情報には、その通信プロトコルを実行する端末装置の種類を示す情報（端末情報）を、そのアプリケーションの情報に、明示的に含むものが存在する。本実施形態では、端末個体識別情報分析部３４は、このような端末情報を取得する。
また、通信プロトコルの情報から端末情報を取得する手順は、例えば、それぞれの通信プロトコルごとに、あらかじめ規定され、プログラムなどの形式で実現される。
このような端末個体識別情報分析部３４の機能は、Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎの機能に相当する。
【００４６】
ここで、端末情報としては、端末装置の種類を示す情報が用いられ、例えば、端末装置に搭載されたＯＳの種類を示す情報（ＯＳ情報）、端末装置の機種名を示す情報（機種名情報）、端末装置の番号を示す情報（番号情報）、などのうちの１つ以上を用いることができる。
【００４７】
一例として、ＴＣＰ／ＩＰの通信プロトコルを用いる場合を示す。ＴＣＰ／ＩＰの通信プロトコルのアプリケーションの情報として、アプリケーションレイヤプロトコルであるＨＴＴＰ（Ｈｙｐｅｒ  Ｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）の情報を用いる。
通信フロー構築部３１は、通信パケットに基づいて通信フローを再構築する処理として、得られた複数の通信パケット（通信パケット群）を並べ替えて、（再送の分を除いて、）ＴＣＰ／ＩＰのセッション（通信フロー）を再現する。そして、端末個体識別情報分析部３４は、そのＴＣＰ／ＩＰのセッション（通信フロー）の上に載っているアプリケーションレイヤプロトコル（ＨＴＴＰ）を分析する。これにより、端末個体識別情報分析部３４は、アプリケーションレベルで通信プロトコルを分析して、端末情報を取得する。
【００４８】
具体的な一例として、ＨＴＴＰのプロトコルにおいては、次のような形式のユーザエージェントヘッダ（Ｕｓｅｒ−Ａｇｅｎｔ：ヘッダ）が含まれることが多い。
【００４９】
（Ｕｓｅｒ−Ａｇｅｎｔ：ヘッダの例）
Ｕｓｅｒ−Ａｇｅｎｔ：  Ｍｏｚｉｌｌａ／５．０（＊＊＊＊＊＊＊；  Ｕ；  ＊＊＊＊＊＊＊  ＮＴ  ６．０；  ｊａ；  ｒｖ：１．９．０．６）  Ｇｅｃｋｏ／２００９０１１９１３  Ｆｉｒｅｆｏｘ／３．０．６  （．ＮＥＴ  ＣＬＲ  ３．５．３０７２９）
【００５０】
ここで、「Ｍｏｚｉｌｌａ／５．０」は、ブラウザのバージョン（ブラウザの種類）を示す情報である。
また、「＊＊＊＊＊＊＊  ＮＴ  ６．０」は、ＯＳのバージョン（ＯＳの種類）を示す情報である。
なお、上記した（Ｕｓｅｒ−Ａｇｅｎｔ：ヘッダの例）およびその説明における「＊＊＊＊＊＊＊」としては、「Ｗｉｎｄｏｗｓ（登録商標）」という文字列が用いられる（但し、「（登録商標）」という部分は、便宜上付したものであり、前記文字列には含まれない。）。
【００５１】
この例では、Ｕｓｅｒ−Ａｇｅｎｔ：ヘッダには、ブラウザのバージョンを示す情報に加えて、ＯＳのバージョンを示す情報が含まれているため、端末個体識別情報分析部３４は、このＵｓｅｒ−Ａｇｅｎｔ：ヘッダから、ＯＳ情報を得ることが可能である。
【００５２】
また、他の例として、ある特定のＯＳだけに提供されているアプリケーションがある場合には、このアプリケーションを使用していることが特定されたときには、端末個体識別情報分析部３４は、この特定のＯＳの情報を得ることができる。
【００５３】
ここで、Ｕｓｅｒ−Ａｇｅｎｔ：ヘッダには、アプリケーションの種類を示す情報や、バージョンを示す番号などの情報や、ＯＳの種類を示す情報などが含まれている。そして、同一のＵｓｅｒ−Ａｇｅｎｔ（Ｕｓｅｒ−Ａｇｅｎｔに含まれる複数の情報の全てが同一であるもの）を使用する端末装置の数は少なく、１個である場合も多い。
【００５４】
具体例として、スマートフォンなどの端末装置では、様々なアプリケーションの中で、ＨＴＴＰを使用していることが多い。一例として、ある端末装置においては「天気予報のアプリケーションであって、第２．３バージョンであるもの」を使用しており、他の端末装置においては「（前記と同じ）天気予報のアプリケーションであって、第４．０バージョンであるもの」を使用している、ということがあり、この場合、これら２つの端末装置を（同一の）天気予報のアプリケーションではあるがそのバージョンの違いで識別することができる。また、他の例として、端末装置が使用する同種のアプリケーション自体が異なる（例えば、天気予報のアプリケーション自体が異なる）ことに基づいて、各端末装置を識別することも可能である。
そして、このようなアプリケーションやバージョンの組み合わせが完全に同じである端末装置は少ないと考えられ、特に、複数のアプリケーションの組み合わせを考慮するとさらに少なくなり、これにより、ある程度（理想的には、１個ずつ）、端末装置を識別（特定）することが可能である。例えば、複数のＵｓｅｒ−Ａｇｅｎｔの情報の組み合わせを用いると、同じ端末装置（例えば、同じＩＰアドレスを使用する端末装置）が使用した複数のアプリケーションに関する情報の組み合わせを識別（特定）することができる。
【００５５】
また、例えば、３ＧＰＰなどの携帯網のアドレス（例えば、ＩＰアドレス）と、ＷｉＦｉ（Ｗｉｒｅｌｅｓｓ  Ｆｉｄｅｌｉｔｙ）網などのアドレス（例えば、ＩＰアドレス）とは異なるため、これらについては、互いに紐付けすることが必要となる。本実施形態では、端末装置の個体を識別（特定）した後に、異なる複数のネットワークの間（例えば、異なる複数のネットワーク内識別子の間）の紐付けを行う。この紐付けは、本実施形態では、端末識別情報データベース１３または端末個体識別部１４で行う。
【００５６】
また、端末個体識別情報分析部３４は、例えば、ＨＴＴＰ以外にも、次のような（情報の例１）〜（情報の例５）のうちの１つ以上の情報を分析してその結果を出力する構成とすることもできて、好ましい。また、他の情報が用いられてもよい。
複数の異なるフィンガプリント（Ｆｉｎｇｅｒｐｒｉｎｔ）の情報を組み合わせて用いると、精度をより高めることができる。
【００５７】
（情報の例１）ＴＣＰのフィンガプリントの情報を用いることができる。
（情報の例２）ブラウザのフィンガプリントの情報を用いることができ、例えば、Ｗｅｂブラウザが出力するヘッダや、インストール済みのプラグインや、プラグインのバージョンなどの情報を用いることができる。
（情報の例３）端末装置のクロックスキュー（Ｃｌｏｃｋ  Ｓｋｅｗ）のフィンガプリントの情報を用いることができ、例えば、クロックスキューを使用したデバイス（Ｄｅｖｉｃｅ）のフィンガプリントの情報を用いることができる。
（情報の例４）端末装置のアクセス先のフィンガプリントの情報を用いることができ、例えば、アクセス先のホスト（Ｈｏｓｔ）の情報を用いることができる。
（情報の例５）端末装置の（ＨＴＴＰ以外の）アプリケーションのフィンガプリントの情報を用いることができ、例えば、動画のアプリケーションの閲覧設定の情報を用いることができる。
【００５８】
端末識別情報データベース１３は、通信監視部１１から入力されて得られた通信パケットの情報および通信プロトコル分析部１２（本実施形態では、端末個体識別情報分析部３４）から入力されて得られた端末情報に基づいて、これらに関する情報を併せて、端末識別情報として、記録して保持（記憶）する。これにより、端末識別情報データベース１３において、端末識別情報のデータベースが作成される。
本実施形態では、端末識別情報データベース１３は、端末識別情報として、通信プロトコル分析部１２から入力されて得られた端末情報と、ネットワーク内識別子の情報を含むネットワーク関連情報（ネットワークに関連する情報）とを対応付けた情報を記録等する。
【００５９】
ここで、ネットワーク内識別子とは、同一のネットワーク内で端末装置を識別することが可能な識別子であり、例えば、アドレスが用いられ、一般のＩＰネットワークではＩＰアドレスが用いられる。
また、ネットワーク関連情報として、例えば、ネットワーク内識別子の情報以外に、ネットワークの情報（ネットワーク情報）や、時刻の情報（時刻情報）を用いることができる。
【００６０】
ネットワーク関連情報は、例えば、端末識別情報データベース１３において、通信監視部１１から入力されて得られる通信パケットの情報から（または、通信プロトコル分析部１２から入力されて得られる端末情報から）取得される。
本実施形態では、端末識別情報データベース１３は、例えば、通信監視部１１から入力されて得られた通信パケットの情報に基づいて得られる通信パケットの特徴を示す情報（例えば、ネットワーク関連情報など）を取得する機能を有する。この機能は、Ｓｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎの機能に相当する。他の構成例として、通信監視部１１にＳｈａｌｌｏｗ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎの機能を備えて、その結果の情報を通信監視部１１から端末識別情報データベース１３に出力することも可能である。
【００６１】
図３は、本発明の一実施形態に係る端末識別情報データベース１３に記憶される端末識別情報の一例を示す図である。
本実施形態では、端末識別情報データベース１３に記憶される端末識別情報は、ネットワーク関連情報と、端末情報とを対応付けて、構成されている。
図３の例では、ネットワーク関連情報として、端末装置に割り当てられたネットワーク内識別子を特定する情報（ネットワーク内識別子の情報）や、端末装置が使用したネットワークを特定する情報（ネットワークの情報）や、端末装置がネットワークを使用した時刻を特定する情報（時刻の情報）を用いている。なお、ネットワーク関連情報としては、様々なものが様々な組み合わせで用いられてもよい。
また、図３の例では、端末情報として、ＨＴＴＰに関する情報や、ＴＣＰのフィンガプリントに関する情報や、Ｗｅｂブラウザの出力ヘッダに関する情報などを用いている。なお、端末情報としては、様々なものが様々な組み合わせで用いられてもよい。
【００６２】
端末個体識別部１４は、端末識別情報データベース１３に記憶される端末識別情報を参照して、これに基づいて、同一の個体の端末装置である（例えば、そのように推定される）と判定（検出）した端末装置に関する情報を出力する。
本実施形態では、端末個体識別部１４は、端末識別情報データベース１３に蓄えられた情報を集計し、同一の個体の端末装置であると判定される端末装置ごとに、ネットワーク内識別子の情報を、時刻の情報（時刻情報）やネットワークの情報（ネットワーク情報）と対応付けて出力する。ネットワーク内識別子としては、例えば、異なるネットワークにおける２個以上のネットワーク内識別子の群であってもよい。
【００６３】
ここで、同一の個体の端末装置であることは、例えば、端末識別情報における端末情報に含まれる複数の情報が全て一致したような場合に、判定する。
また、ネットワーク内識別子の情報や、時刻情報や、ネットワーク情報は、例えば、端末識別情報データベース１３から入力されて得られる端末識別情報におけるネットワーク関連情報から取得される。
【００６４】
一例として、図３の例に係る端末識別情報に基づいて、端末個体識別部１４は、「あるユーザの端末装置は、時刻が００：００：００〜０１：００：００の範囲にある時間帯においてはネットワークＡにおいてアドレスａを使用した通信を行っていたが、時刻が０３：００：００〜０５：００：００の範囲にある時間帯においてはネットワークＢにおいてアドレスｂを使用した通信を行っていた」ということを判定して、その情報を出力する。この場合に、端末個体識別部１４は、ネットワークＡにおいてアドレスａを使用した通信を行っていた端末装置について得られた端末情報と、ネットワークＢにおいてアドレスｂを使用した通信を行っていた端末装置について得られた端末情報とが、全部について、または、あらかじめ定められた一部について、または、あらかじめ定められた閾値（例えば、個数、または、割合など）以上について、一致することを判定した場合に、これらの端末装置が同一の個体の端末装置であると判定する。
なお、具体例として、ＬＴＥ（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ）のシステムや、ＷｉＦｉのシステムなどでは、端末装置が収容されるときに、当該端末装置に一時的な識別情報（アドレス）が付与される。これにより、端末装置で使用される識別情報（アドレス）がシステム（ネットワーク）ごとに変化し得る。
【００６５】
以上のように、本実施形態に係る識別装置１では、例えば、通信内容の静的な監視を行い、Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎを用いて収集した各種の情報を組み合わせることで、端末装置の個体を識別する。本実施形態に係る識別装置１では、例えば、端末装置ごとに固有な通信方法の特徴などを利用することで、端末装置の個体を一意に識別する。これにより、本実施形態に係る識別装置１では、通信監視部１１により得られた通信パケットを通信網（本実施形態では、回線２）に送信（送出）した端末装置の個体を識別することができる。
【００６６】
このように、本実施形態に係る識別装置１によると、端末装置の個体識別を効果的に行うことができ、例えば、高速且つ高精度に、低コストで、端末装置の個体識別を行うことが可能となる。本実施形態に係る識別装置１によると、例えば、１個１個の端末装置を匿名化して特定することも可能である。また、本実施形態に係る識別装置１によると、例えば、３ＧＰＰなどの携帯網やＷｉＦｉ網などのように、異なる複数のネットワークの間においても、同一の端末装置を紐付けすることが可能であり、ネットワークの改善に役立つことができる。
【００６７】
また、本実施形態に係る識別装置１では、フォアグラウンドトラヒックとバックグラウンドトラヒックのうちで、バックグラウンドトラヒックの情報を用いて、端末装置の個体を識別する。
このように、本実施形態に係る識別装置１によると、端末装置の個体識別を精度良く行うことができる。
【００６８】
ここで、フォアグラウンドトラヒックとバックグラウンドトラヒックとを区別することについて、詳しく説明する。
例えば、端末装置の種類やＯＳを特定することばかりでなく、端末装置の個体識別を行うことは有効である。端末装置の個体識別は、例えば、当該端末装置の利用者の能動的なＩＤ登録等を必要とせず、通信内容の静的な監視を行う装置において、Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎを用いて収集した各種の情報を組み合わせることで、可能である。
ところで、スマートフォンやパーソナルコンピュータ（ＰＣ）などの端末装置では、様々なアプリケーションのトラヒックを発生させているが、このようなトラヒックはフォアグラウンドトラヒックとバックグラウンドトラヒックの二種類に大別される。端末装置の個体識別を行うためには、精度良く、通信パケットから端末装置の固有の特徴を抽出することが必要である。一般的には、フォアグラウンドトラヒックでは、端末装置の利用者の気分や関心に影響して、これらの変化によって特性にも変化が現れ、端末装置の個体識別の精度が悪化する場合があると考えられる。したがって、本実施形態では、端末装置の個体識別を行う場合に、すべてのトラヒックを用いるのではなく、バックグラウンドトラヒックのみを用いる構成とした。本実施形態に係る識別装置１では、例えば、端末装置の通信内容の静的な監視を行い、当該端末装置の利用者が意識せずに発生する通信パケットのみを抽出し、Ｄｅｅｐ  Ｐａｃｋｅｔ  Ｉｎｓｐｅｃｔｉｏｎを用いて収集した各種の情報を組み合わせて、端末装置の個体識別を行う。
【００６９】
［以上の実施形態に係る構成例］
ここで、本実施形態に係る（構成例１）〜（構成例６）を示す。
（構成例１）
識別装置１は、監視対象の通信パケットの情報を取得する通信監視部１１と、前記通信監視部１１により取得される通信パケットの情報に基づいて通信フローを再構築する通信フロー構築部３１と、前記通信フロー構築部３１により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒック（本実施形態では、フォアグラウンドトラヒック）に対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒック（本実施形態では、バックグラウンドトラヒック）に対応するかを判定するトラヒック判定部３３と、前記トラヒック判定部３３により前記第２のトラヒックに対応すると判定された前記通信フロー（のみ）の通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得する端末個体識別情報分析部３４と、前記端末個体識別情報分析部３４により取得される情報（例えば、端末情報）、および、前記通信監視部１１により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報（例えば、ネットワーク関連情報）を記憶する端末識別情報データベース（情報記憶部）１３と、を備える。
【００７０】
この（構成例１）に係る識別装置１では、端末識別情報データベース（情報記憶部）１３に記憶される情報により、端末装置の個体を識別することができる。具体的には、この（構成例１）に係る識別装置１では、端末識別情報データベース（情報記憶部）１３に記憶される情報を外部の装置などに出力することにより、当該外部の装置などにおいて、入力される当該情報に基づいて、端末装置の個体を識別することができる。
なお、この（構成例１）に係る識別装置１では、監視対象の通信パケットの情報を取得する通信監視部１１は、例えば、回線（ネットワーク）上に流れる通信パケットを直接処理してもよく、または、他の構成例として、ファイル等に蓄えられた通信パケットの情報に対して処理を行ってもよい。
【００７１】
（構成例２）
上記した（構成例１）に記載した識別装置１において、前記通信パケットの特徴を示す情報は、ネットワーク内識別子の情報を含み、さらに、前記端末識別情報データベース（情報記憶部）１３に記憶される情報に基づいて、同一の端末装置個体であるとされる端末装置ごとに、ネットワーク内識別子の情報を出力する端末個体識別部１４を備える。
【００７２】
（構成例３）
上記した（構成例２）に記載した識別装置１において、前記通信パケットの特徴を示す情報は、さらに、時刻の情報およびネットワークの情報を含み、前記端末個体識別部１４は、前記ネットワーク内識別子の情報を、時刻の情報およびネットワークの情報と共に出力する。
【００７３】
（構成例４）
上記した（構成例１）から上記した（構成例３）のいずれか１つに記載した識別装置１において、前記端末個体識別情報分析部３４は、ＨＴＴＰプロトコルにおけるＵｓｅｒ−Ａｇｅｎｔの情報、または、ＴＣＰのフィンガプリントの情報、または、Ｗｅｂブラウザが出力するヘッダの情報、インストール済みのプラグインの情報、およびそのプラグインのバージョンの情報、または、前記端末装置のクロックスキューの情報、または、前記端末装置のアクセス先のホストの情報、または、前記端末装置の動画のアプリケーションの閲覧設定の情報、のうちの１つ以上を取得する。
【００７４】
（構成例５）
識別装置１において行われる識別方法では、通信監視部１１が、監視対象の通信パケットの情報を取得し、通信フロー構築部３１が、前記通信監視部１１により取得される通信パケットの情報に基づいて通信フローを再構築し、トラヒック判定部３３が、前記通信フロー構築部３１により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定し、端末個体識別情報分析部３４が、前記トラヒック判定部３３により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得し、端末識別情報データベース（情報記憶部）１３が、前記端末個体識別情報分析部３４により取得される情報、および、前記通信監視部１１により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶する。
【００７５】
（構成例６）
識別装置１において用いられて実行されるプログラム（識別プログラム）は、通信監視部１１が、監視対象の通信パケットの情報を取得するステップと、通信フロー構築部３１が、前記通信監視部１１により取得される通信パケットの情報に基づいて通信フローを再構築するステップと、トラヒック判定部３３が、前記通信フロー構築部３１により再構築された通信フローについて、人により行われた操作に起因して発生したと推定される第１のトラヒックに対応するか、または、人により行われる操作に起因しないで発生したと推定される第２のトラヒックに対応するかを判定するステップと、端末個体識別情報分析部３４が、前記トラヒック判定部３３により前記第２のトラヒックに対応すると判定された前記通信フローの通信プロトコルを分析することで、前記通信パケットを送信した端末装置の個体識別に係る情報を取得するステップと、端末識別情報データベース（情報記憶部）１３が、前記端末個体識別情報分析部３４により取得される情報、および、前記通信監視部１１により取得される通信パケットの情報に基づいて得られる前記通信パケットの特徴を示す情報を記憶するステップと、をコンピュータに実行させる。
【００７６】
［以上の実施形態のまとめ］
ここで、以上の実施形態では、ＴＣＰ／ＩＰを用いた通信を例としたが、必ずしもそれに限定されるものではなく、例えば、通信サービス一般に広く適用することが可能である。
同様に、対象とする通信プロトコルについても、特定の通信プロトコルに限定されるものではなく、例えば、端末装置の個体（例えば、種類など）に係る情報を含む通信プロトコル一般に広く適用することが可能である。通信プロトコルの具体例としては、例えば、ＨＴＴＰ以外に、ＳＭＴＰ（Ｓｉｍｐｌｅ  Ｍａｉｌ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）などに適用することが可能である。
【００７７】
また、以上の実施形態では、端末装置の種類を識別する情報として、ＯＳ情報、機種名情報、番号情報を例としたが、他の様々な情報が用いられてもよい。具体的には、端末装置の種類を識別する情報として、例えば、ＯＳを主とする以外に、ミドルウェアのバージョン（ミドルウェアの種類）を示す情報や、特定のアプリケーションのバージョン（特定のアプリケーションの種類）を示す情報などを用いることも可能である。
【００７８】
また、端末装置としては、様々なものが用いられてもよく、例えば、スマートフォンを含む携帯電話、パーソナルコンピュータ（ＰＣ）、ホームゲートウェイ、専用端末などの端末装置を用いることができる。
【００７９】
以上、本発明の実施形態について図面を参照して詳述したが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【００８０】
また、以上に示した実施形態に係る識別装置１の全部または一部の機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して、この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することにより、処理を行ってもよい。
【００８１】
なお、ここで言う「コンピュータシステム」とは、オペレーティング・システム（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ；ＯＳ）や周辺機器等のハードウェアを含むものであってもよい。
また、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスク、光磁気ディスク、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）、フラッシュメモリ等の書き込み可能な不揮発性メモリ、ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｋ）等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記憶装置のことを言う。
【００８２】
さらに、「コンピュータ読み取り可能な記録媒体」とは、インターネット等のネットワークや電話回線等の通信回線を介してプログラムが送信された場合のサーバやクライアントとなるコンピュータシステム内部の揮発性メモリ（例えばＤＲＡＭ（Ｄｙｎａｍｉｃ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ））のように、一定時間プログラムを保持しているものも含むものとする。
また、上記のプログラムは、このプログラムを記憶装置等に格納したコンピュータシステムから、伝送媒体を介して、あるいは、伝送媒体中の伝送波により他のコンピュータシステムに伝送されてもよい。ここで、プログラムを伝送する「伝送媒体」は、インターネット等のネットワーク（通信網）や電話回線等の通信回線（通信線）のように情報を伝送する機能を有する媒体のことを言う。
また、上記のプログラムは、前述した機能の一部を実現するためのものであっても良い。さらに、前述した機能をコンピュータシステムにすでに記録されているプログラムとの組み合わせで実現できるもの、いわゆる差分ファイル（差分プログラム）であっても良い。
【符号の説明】
【００８３】
１…識別装置、２…回線、１１…通信監視部、１２…通信プロトコル分析部、１３…端末識別情報データベース（情報記憶部）、１４…端末個体識別部、３１…通信フロー構築部、３２…フローデータベース、３３…トラヒック判定部（フォアグラウンド／バックグラウンドトラヒック判定部）、３４…端末個体識別情報分析部
【図１】
0006280836.tif 000002
【図２】
0006280836.tif 000003
【図３】
0006280836.tif 000004