(57)【要約】【課題】端末の種別を識別する。【解決手段】ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、を有することを特徴とする。【選択図】図３
2019036830.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、
前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、
を有することを特徴とする端末識別装置。
【請求項２】
予め蓄積された通信トラヒックから、該通信トラヒックの発生元の第２の端末と、該第２の端末の通信先ホストとの集合を作成する集合作成部と、
前記集合作成部が作成した集合に対して、前記第２の端末の端末種別を示す正解ラベルを割り当てることで、学習データを作成する学習データ作成部と、
前記学習データ作成部が作成した学習データを用いて、機械学習の手法により、前記端末種別を識別するための識別器を作成する識別器作成部と、を有し、
前記識別部は、
前記リスト作成部が作成した通信先ホストのリストと、前記識別器作成部が作成した識別器とから、前記第１の端末の端末種別を識別する、ことを特徴とする請求項１に記載の端末識別装置。
【請求項３】
前記集合作成部は、
前記通信トラヒックの発生元の第２の端末と、該第２の端末の通信先ホストと、前記第２の端末の端末種別との集合を作成し、
前記学習データ作成部は、
前記集合作成部が作成した集合に対して、該集合に含まれる端末種別のうち、最も出現回数が多い端末種別又はユーザにより選択された端末種別のいずれかを示す正解ラベルを割り当てることで、学習データを作成する、ことを特徴とする請求項２に記載の端末識別装置。
【請求項４】
前記通信トラヒックは、ＨＴＴＰ通信、ＨＴＴＰＳ通信及びＤＮＳ通信のうちの少なくとも１つの通信により発生する通信トラヒックである、ことを特徴とする請求項１乃至３の何れか一項に記載の端末識別装置。
【請求項５】
ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成手順と、
前記リスト作成手順が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別手順と、
をコンピュータが実行することを特徴とする端末識別方法。
【請求項６】
ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成手順と、
前記リスト作成手順が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別手順と、
をコンピュータに実行させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、端末識別装置、端末識別方法及びプログラムに関する。
【背景技術】
【０００２】
インターネットの利用ユーザ数の増加やＩｏＴ（Internet of Things）機器を始めとする通信端末の多様化等に伴い、通信事業者において、特定のアプリケーションや端末の仕様、通信挙動等が原因となり、ネットワークの適切な運用に支障が生じる場合がある。
【０００３】
例えば、ある特定の種別の端末が同時刻に一斉に通信を行う仕様である場合、端末数が多いとネットワーク輻輳の原因となることがある。このため、ネットワークの適切な運用に支障が生じる原因となるようなリスクを有する端末やアプリケーションの種別を調査し、必要に応じて端末やアプリケーションの開発元に仕様変更の打診を行ったり、ネットワークレベルでの通信制限の措置を講じたりすることが求められている。
【０００４】
また、ある特定の種別の端末を対象とするマルウェアの大規模感染が生じた場合等には、影響を最小限に抑える必要がある。このため、通信事業者は、マルウェアに関する通信トラヒックを検出した際に、原因となっている端末の種別を早期に特定し、注意喚起や通信制限等の措置を講じる必要がある。
【０００５】
このように、通信事業者は、ネットワークの適切な運用に影響を及ぼす可能性のある通信トラヒックの発生原因となっている端末やアプリケーションの種別を早期に特定する必要がある。以降では、ある特定のプログラム（ＯＳ（Operating System）やアプリケーションソフトウェア、ミドルウェア、ファームウェア、端末の製造元ベンダ等によりプリインストールされる固有のプログラム等も含む）が搭載された端末を特定すること（すなわち、端末の種別を識別すること）を「端末識別」と称する。
【０００６】
ここで、通信事業者が各ユーザの端末の種別を個別に全数調査することは困難である。そこで、通信トラヒック（以降、単に「トラヒック」とも表す。）から端末識別を行うことが考えられる。
【０００７】
トラヒックから端末識別を行う方法として、パケットのアプリケーション・ヘッダに含まれる端末識別情報（例えば、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダのＵｓｅｒ−Ａｇｅｎｔフィールド）を参照する方法が知られている。しかしながら、通信が暗号化される場合には、アプリケーション・ヘッダも暗号化されるため、端末識別を行うことができないことがある。
【０００８】
これに対して、例えばＩＰ（Internet Protocol）ヘッダやＴＣＰ（Transmission Control Protocol）／ＵＤＰ（User Datagram Protocol）ヘッダ等から端末の種別を推定する方法が知られている（例えば非特許文献１）。非特許文献１に開示されている方法では、パケットのヘッダの一部のフィールドに設定されるネットワーク・パラメータ（例えば、ウィンドウサイズ、ＴＴＬ（Time To Live）等）がＯＳやアプリケーション固有のパラメータに依存することに着目し、これらのネットワーク・パラメータを特徴量（フィンガプリント）として端末識別を行う。
【先行技術文献】
【非特許文献】
【０００９】
【非特許文献１】Zalewski, Michal. "p0f: Passive OS Fingerprinting tool.", [online], インターネット＜ＵＲＬ：http://lcamtuf.coredump.cx/p0f.shtml/＞
【発明の概要】
【発明が解決しようとする課題】
【００１０】
ここで、非特許文献１に開示されている方法では、特定したい端末の種別毎に、ＩＰヘッダやＴＣＰ／ＵＤＰヘッダの一部のフィールドに設定されるネットワーク・パラメータが異なる必要がある。
【００１１】
しかしながら、近年では、モバイル端末やＩｏＴ端末等の各種端末で用いられるネットワーク・パラメータの共通化が進んでいる。このため、特定したい端末の種別毎に、ネットワーク・パラメータに差異が生じない場合があり、非特許文献１に開示されている方法で端末識別を行うことができないことがある。
【００１２】
本発明の実施の形態は、上記の点に鑑みてなされたもので、端末の種別を識別することを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するため、ネットワークに収容される第１の端末の通信トラヒックから、該第１の端末の通信先を示す通信先ホストのリストを作成するリスト作成部と、前記リスト作成部が作成した通信先ホストのリストと、予め作成された識別器とから、前記第１の端末の端末種別を識別する識別部と、を有することを特徴とする。
【発明の効果】
【００１４】
端末の種別を識別することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施の形態における端末識別装置が含まれるシステムの全体構成の一例を示す図である。
【図２】本発明の実施の形態における端末識別装置のハードウェア構成の一例を示す図である。
【図３】本発明の実施の形態における端末識別の概略を説明する図である。
【図４】通信トラヒックから抽出する情報の一例を説明する図である。
【図５】本発明の実施の形態における端末識別処理部の機能構成の一例を示す図である。
【図６】端末識別処理部の学習フェーズにおける処理の一例を示すフローチャートである。
【図７】端末識別処理部の識別フェーズにおける処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１６】
以下、本発明の実施の形態について、図面を参照しながら説明する。
【００１７】
＜全体構成＞
まず、本発明の実施の形態において端末識別を行う端末識別装置１０が含まれるシステムの全体構成について、図１を参照しながら説明する。図１は、本発明の実施の形態における端末識別装置１０が含まれるシステムの全体構成の一例を示す図である。
【００１８】
図１に示すように、内部ネットワークＥ１は、利用ユーザＡの端末２１Ａ、利用ユーザＢの端末２１Ｂ、利用ユーザＣの端末２１Ｃ等の複数の端末２１を収容する。また、内部ネットワークＥ１には、種々の通信機器２２が収容されていても良い。以降では、内部ネットワークＥ１に収容される端末２１や通信機器２２を区別しない場合は、「ユーザ端末２０」とも表す。
【００１９】
内部ネットワークＥ１は、例えば、企業内のネットワーク環境やＩＳＰ（Internet Services Provider）内のネットワーク環境等である。内部ネットワークＥ１では、例えばＩＰアドレスや加入者ＩＤ等を用いて、収容されている各ユーザ端末２０を特定することができる。
【００２０】
内部ネットワークＥ１に収容される各端末２１としては、例えば、ＰＣ（パーソナルコンピュータ）やスマートフォン、タブレット端末、ゲーム機器等が挙げられる。また、各通信機器２２としては、例えば、ファクシミリ、コピー機、プリンタ、車載機（例えばカーナビ等）、監視カメラ、家電製品等の種々の通信可能な機器が挙げられる。
【００２１】
各ユーザ端末２０は、ＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）、ｍａｃＯＳ（登録商標）、Ａｎｄｒｏｉｄ（登録商標）、Ｌｉｎｕｘ（登録商標）等）で端末種別を分類できるものとする。なお、各ユーザ端末２０は、更に、例えば、モバイル端末であるか、固定端末であるか等により端末種別を分類できても良い。
【００２２】
また、内部ネットワークＥ１には、各ユーザ端末２０の端末種別を識別する端末識別装置１０と、各ユーザ端末２０のトラヒックを収集するトラヒック収集装置３０と、ドメイン名からＩＰアドレスへの名前解決を提供するＤＮＳ（Domain Name System）キャッシュサーバ４０とが含まれる。
【００２３】
一方で、外部ネットワークＥ２は、ユーザ端末２０がアクセスする通信先ホストサーバ５０が含まれるネットワーク環境である。通信先ホストサーバ５０は、例えば、Ｗｅｂサーバやクラウドサーバ等のコンテンツサーバであり、例えば、ユーザ端末２０に搭載されているＯＳ毎に存在する。ユーザ端末２０は、インターネットを介して、通信先ホストサーバ５０にアクセスすることで、例えば、ＯＳのバージョンアップやＯＳ固有のアプリケーションデータの同期等を行う。
【００２４】
ＤＮＳキャッシュサーバ４０は、ユーザ端末２０が通信先ホストサーバ５０にアクセスするための名前解決を行うサーバである。ＤＮＳキャッシュサーバ４０は、内部ネットワークＥ１に設置されている場合に限られず、例えば、外部ネットワークＥ２にも設置されていて良い。この場合、ユーザ端末２０は、内部ネットワークＥ１又は外部ネットワークＥ２のいずれかに設置されているＤＮＳキャッシュサーバ４０を選択的に利用すれば良い。
【００２５】
なお、後述する学習フェーズ及び識別フェーズで必要な情報をＨＴＴＰ又はＨＴＴＰＳ（Hypertext Transfer Protocol Secure）通信のトラヒックから収集する場合には、ＤＮＳキャッシュサーバ４０が設置されていなくても良い。
【００２６】
トラヒック収集装置３０は、ユーザ端末２０が通信先ホストサーバ５０にアクセスする際のトラヒック（ＨＴＴＰ／ＨＴＴＰＳ通信のトラヒック）と、これに先立って発生するＤＮＳ通信（すなわち、名前解決のためのＤＮＳキャッシュサーバ４０への問い合せ通信）のトラヒックとを端末識別装置１０に転送する。このため、トラヒック収集装置３０は、ユーザ端末２０から通信先ホストサーバ５０へのトラヒックと、ユーザ端末２０からＤＮＳキャッシュサーバ４０へのトラヒックとを収集可能な場所に設置される。
【００２７】
トラヒック収集装置３０は、例えば、通信トラヒックの複製（ミラーリング）機能を有するネットワーク・スイッチやタップ等を用いて実現可能である。すなわち、ミラーリング機能を有するネットワーク・スイッチやタップ等において、該当のトラヒックを端末識別装置１０に転送する設定を行うことで、トラヒック収集装置３０が実現される。
【００２８】
端末識別装置１０は、各ユーザ端末２０がアクセスする通信先ホストサーバ５０を示す情報（通信先ホスト）から、これら各ユーザ端末２０の端末種別を識別する１以上のコンピュータである。端末識別装置１０は、端末識別処理部１００を有する。端末識別処理部１００は、端末識別装置１０にインストールされた１以上のプログラム（スクリプトも含む）が、後述するＣＰＵ１６に実行させる処理により実現される。
【００２９】
また、端末識別装置１０は、通信記録ＤＢ１１０と、識別結果ＤＢ１２０とを有する。これら各ＤＢは、例えば、後述する補助記憶装置１８を用いて実現可能である。なお、これら各ＤＢのうちの少なくとも１つのＤＢが、端末識別装置１０とネットワークを介して接続される記憶装置等を用いて実現されていても良い。
【００３０】
端末識別装置１０は、端末識別処理部１００により、トラヒック収集装置３０から転送されたトラヒックから、通信先ホスト等が含まれる所定の情報を抽出した上で、通信記録ＤＢ１１０に格納する。そして、端末識別装置１０は、端末識別処理部１００により、通信記録ＤＢ１１０に格納されている情報を用いて、ユーザ端末２０の通信先ホストから端末種別を識別した上で、識別結果を識別結果ＤＢ１２０に格納する。
【００３１】
なお、図１に示すシステムの全体構成は一例であって、他の構成であっても良い。例えば、端末識別装置１０及びトラヒック収集装置３０は、内部ネットワークＥ１と外部ネットワークＥ２との間に存在する中継ネットワーク内に設置されていても良い。また、この場合、ＤＮＳキャッシュサーバ４０も中継ネットワーク内に設置されていても良い。
【００３２】
＜ハードウェア構成＞
次に、本発明の実施の形態における端末識別装置１０のハードウェア構成について、図２を参照しながら説明する。図２は、本発明の実施の形態における端末識別装置１０のハードウェア構成の一例を示す図である。
【００３３】
図２に示すように、本発明の実施の形態における端末識別装置１０は、入力装置１１と、表示装置１２と、外部Ｉ／Ｆ１３と、ＲＡＭ（Random Access Memory）１４と、ＲＯＭ（Read Only Memory）１５と、ＣＰＵ（Central Processing Unit）１６と、通信Ｉ／Ｆ１７と、補助記憶装置１８とを有する。これら各ハードウェアは、それぞれがバスＢを介して通信可能に接続されている。
【００３４】
入力装置１１は、例えばキーボードやマウス、タッチパネル等であり、ユーザが各種操作を入力するのに用いられる。表示装置１２は、例えばディスプレイ等であり、端末識別装置１０の処理結果を表示する。なお、端末識別装置１０は、入力装置１１及び表示装置１２の少なくとも一方を有していなくても良い。
【００３５】
外部Ｉ／Ｆ１３は、外部装置とのインタフェースである。外部装置には、記録媒体１３ａ等がある。端末識別装置１０は、外部Ｉ／Ｆ１３を介して、記録媒体１３ａ等の読み取りや書き込みを行うことができる。
【００３６】
記録媒体１３ａには、例えば、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disk）、ＳＤ（Secure Digital）メモリカード、ＵＳＢ（Universal Serial Bus）メモリカード等がある。
【００３７】
ＲＡＭ１４は、プログラムやデータを一時保持する揮発性の半導体メモリである。ＲＯＭ１５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリである。ＲＯＭ１５には、例えば、ＯＳ設定やネットワーク設定等が格納されている。
【００３８】
ＣＰＵ１６は、ＲＯＭ１５や補助記憶装置１８等からプログラムやデータをＲＡＭ１４上に読み出して、処理を実行する演算装置である。
【００３９】
通信Ｉ／Ｆ１７は、他の装置と通信を行うためのインタフェースである。端末識別装置１０は、通信Ｉ／Ｆ１７を介して、トラヒック収集装置３０からトラヒックを受信する。
【００４０】
補助記憶装置１８は、例えばＨＤＤ（Hard Disk Drive）やＳＳＤ（Solid State Drive）等であり、プログラムやデータを格納している不揮発性の記憶装置である。補助記憶装置１８に格納されているプログラムやデータには、例えば、ＯＳ、当該ＯＳ上において各種機能を実現するアプリケーションプログラム、端末識別処理部１００を実現するプログラム等がある。
【００４１】
本発明の実施の形態における端末識別装置１０は、図２に示すハードウェア構成を有することにより、後述する各種処理を実現することができる。
【００４２】
＜端末識別の概略＞
ここで、端末識別装置１０の端末識別処理部１００による端末識別の概略について、図３を参照しながら説明する。図３は、本発明の実施の形態における端末識別の概略を説明する図である。
【００４３】
端末識別処理部１００による端末識別は、端末種別の識別に用いられる端末識別器２００を作成するための「学習フェーズ」と、端末識別器２００を用いて実際に端末種別を識別する「識別フェーズ」とがある。
【００４４】
≪学習フェーズ≫
Ｓ１１）トラヒック収集装置３０からトラヒックが転送されると、端末識別処理部１００は、当該トラヒックから所定の情報（通信時刻、通信元アドレス、通信先ホスト及び端末種別）を抽出した上で、抽出した情報を対応付けて通信記録ＤＢ１１０に格納する。
【００４５】
通信記録ＤＢ１１０には、例えば所定の期間の間にトラヒック収集装置３０から転送されたトラヒックの通信時刻、通信元アドレス、通信先ホスト及び端末種別が対応付けて格納されている。
【００４６】
Ｓ１２）端末識別処理部１００は、通信記録ＤＢ１１０に格納されている情報（通信時刻、通信元アドレス、通信先ホスト及び端末種別）から端末識別器２００を作成する。端末識別器２００は、識別フェーズにおいて通信先ホストから端末種別を識別するための中間データであり、例えば、バイナリデータやテキストデータの形式で作成される。
【００４７】
≪識別フェーズ≫
Ｓ２１）トラヒック収集装置３０からトラヒックが転送されると、端末識別処理部１００は、当該トラヒックから所定の情報（通信時刻、通信元アドレス及び通信先ホスト）を抽出した上で、抽出した情報を対応付けて通信記録ＤＢ１１０に格納する。
【００４８】
Ｓ２２）端末識別処理部１００は、端末識別器２００を用いて、通信記録ＤＢ１１０に格納されている通信先ホストから端末種別を識別する。そして、端末識別処理部１００は、識別した端末種別と、通信元アドレスとを対応付けて識別結果ＤＢ１２０に格納する。これにより、通信元アドレスにより特定されるユーザ端末２０の端末種別が識別される。
【００４９】
≪通信トラヒックから抽出する情報≫
ここで、学習フェーズ及び識別フェーズにおいて通信トラヒックから抽出する情報について、図４を参照しながら説明する。図４は、通信トラヒックから抽出する情報の一例を説明する図である。
【００５０】
上述したように、学習フェーズでは、（ａ）通信時刻、（ｂ）通信元アドレス、（ｃ）通信先ホスト、及び（ｄ）端末種別が通信トラヒックから抽出される。一方で、識別フェーズでは、（ａ）通信時刻、（ｂ）通信元アドレス、及び（ｃ）通信先ホストが通信トラヒックから抽出される。
【００５１】
このとき、（ａ）通信時刻としては、例えば、（ａ−１）ＨＴＴＰ／ＨＴＴＰＳ通信開始時のパケットをトラヒック収集装置３０が収集した時刻、又は（ａ−２）ＤＮＳ通信のパケットをトラヒック収集装置３０が収集した時刻、のいずれか１つを用いれば良い。
【００５２】
また、（ｂ）通信元アドレスとしては、例えば、（ｂ−１）ＨＴＴＰ／ＨＴＴＰＳ通信のクライアント側ＩＰアドレス、又は（ｂ−２）ＤＮＳ通信の送信元ＩＰアドレス、のいずれか１つを用いれば良い。
【００５３】
また、（ｃ）通信先ホストとしては、（ｃ−１）ＨＴＴＰヘッダのＨｏｓｔフィールド、（ｃ−２）ＤＮＳ通信のＦＱＤＮ（Fully Qualified Domain Name）、又は（ｃ−３）ＨＴＴＰ通信のＳＮＩ（Server Name Indication）情報、のいずれか１つを用いれば良い。
【００５４】
更に、（ｄ）端末種別としては、（ｄ−１）ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールド、又は（ｄ−２）通信元アドレスと端末種別とが対応付けられた外部ＤＢ等を参照して得られる端末種別、のいずれか１つを用いれば良い。
【００５５】
このため、例えば、トラヒック収集装置３０がＨＴＴＰ通信のトラヒックを収集することができる場合には、学習フェーズでは、（ａ−１）、（ｂ−１）、（ｃ−１）及び（ｄ−１）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス、（ｃ）通信先ホスト、及び（ｄ）端末種別の情報として抽出すれば良い。
【００５６】
一方で、例えば、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、学習フェーズでは、（ａ−２）、（ｂ−２）及び（ｃ−２）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。このとき、ＤＮＳ通信のトラヒックには、端末種別に相当する情報が含まれないため、（ｄ−１）通信元アドレスと端末種別とが対応付けられた外部ＤＢ等を参照して得られる端末種別を（ｄ）端末種別の情報として抽出する。
【００５７】
外部ＤＢとは、例えば、企業等の組織内で、ユーザ端末２０のＩＰアドレスと、当該ユーザ端末２０の端末種別とを対応付けて管理しているＤＢ（データベース）である。したがって、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、端末識別装置１０（又はトラヒック収集装置３０）は、上記のような外部ＤＢにアクセスできる必要がある。
【００５８】
また、例えば、トラヒック収集装置３０がＨＴＴＰ通信のトラヒックを収集することができる場合には、識別フェーズでは、（ａ−１）、（ｂ−１）及び（ｃ−１）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。なお、このとき、ＨＴＴＰＳ通信である場合には、（ｃ−１）の代わり、（ｃ−３）の情報を（ｃ）通信先ホストの情報として抽出すれば良い。
【００５９】
一方で、トラヒック収集装置３０がＤＮＳ通信のトラヒックのみを収集することができる場合には、識別フェーズでは、（ａ−２）、（ｂ−２）及び（ｃ−２）の情報を、それぞれ（ａ）通信時刻、（ｂ）通信元アドレス及び（ｃ）通信先ホストの情報として抽出すれば良い。
【００６０】
このように、トラヒック収集装置３０が収集可能なトラヒックの種類に応じて、端末識別処理部１００は、学習フェーズや識別フェーズで必要な情報を当該トラヒックから抽出する。なお、例えば、トラヒック収集装置３０がＨＴＴＰ通信及びＤＮＳ通信の両方のトラヒックを収集することができる場合には、抽出する項目に応じて、抽出する対象のトラヒックの種別を異ならせても良い。例えば、（ａ）通信時刻及び（ｂ）通信元アドレスはＤＮＳ通信のトラヒックから抽出し、（ｃ）通信先ホスト及び（ｄ）端末種別はＨＴＴＰ通信のトラヒックから抽出する等である。
【００６１】
なお、以降では、学習フェーズの処理を開始する前に、学習フェーズに必要な情報（すなわち、通信時刻、通信元アドレス、通信先ホスト及び端末種別）が通信記録ＤＢ１１０に格納されているものとする。同様に、識別フェーズを開始する前に、識別フェーズに必要な情報（すなわち、通信時刻、通信元アドレス及び通信先ホスト）が通信記録ＤＢ１１０に格納されているものとする。
【００６２】
＜機能構成＞
次に、本発明の実施の形態における端末識別処理部１００の機能構成について、図５を参照しながら説明する。図５は、本発明の実施の形態における端末識別処理部１００の機能構成の一例を示す図である。
【００６３】
図５に示すように、本発明の実施の形態における端末識別処理部１００には、集合作成部１０１と、学習データ作成部１０２と、識別器作成部１０３と、識別部１０４とが含まれる。
【００６４】
集合作成部１０１は、学習フェーズにおいて、予め決められた時間ウインドウＴ（すなわち、予め決められた時間幅）毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈと、端末種別ｄとを取得する。そして、集合作成部１０１は、通信元アドレスａ毎に、通信先ホストｈと、端末種別ｄとの組の集合Ｒｔ，ａを作成する。
【００６５】
ここで、ｔは、時間ウインドウＴ毎に取得された通信元アドレスａと、通信先ホストｈと、端末種別ｄとを代表する時刻である。例えば、ある時刻をＴ１として、Ｔ１以上、Ｔ１＋Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ１≦ｔ＜Ｔ１＋Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ１）とすれば良い。また、例えば、Ｔ１＋Ｔ以上、Ｔ１＋２Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ１＋Ｔ≦ｔ＜Ｔ１＋２Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ１＋Ｔ）とすれば良い。同様に、例えば、Ｔ１＋ｎＴ以上、Ｔ１＋（ｎ＋１）Ｔ未満の通信時刻に対応付けられていた通信元アドレスａ、通信先ホストｈ及び端末種別ｄのｔは、Ｔ１＋ｎＴ≦ｔ＜Ｔ１＋（ｎ＋１）Ｔを満たす任意の時刻（例えば、ｔ＝Ｔ１＋ｎＴ）とすれば良い。
【００６６】
また、集合作成部１０１は、識別フェーズにおいて、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈとを取得する。そして、集合作成部１０１は、通信元アドレスａ毎に、通信先ホストｈの集合Ｓｔ，ａを作成する。
【００６７】
学習データ作成部１０２は、学習フェーズにおいて、集合作成部１０１により作成された集合Ｒｔ，ａに対して正解ラベルｄ´を割り当てることで学習データを作成する。正解ラベルｄ´とは、当該集合Ｒｔ，ａの代表となる端末種別のことである。正解ラベルｄ´は、例えば、端末種別を表す文字又は文字列で表される。
【００６８】
識別器作成部１０３は、学習フェーズにおいて、学習データ作成部１０２により作成された学習データを用いて、機械学習の手法により端末識別器２００を作成する。識別器作成部１０３により作成された端末識別器２００は、例えば、補助記憶装置１８等に記憶される。
【００６９】
識別部１０４は、識別フェーズにおいて、端末識別器２００を用いて、集合作成部１０１により作成された集合Ｓｔ，ａから、当該通信元アドレスａにより特定されるユーザ端末２０の端末種別ｄ´を識別する。
【００７０】
＜学習フェーズにおける処理の詳細＞
次に、端末識別処理部１００の学習フェーズにおける処理の詳細について、図６を参照しながら説明する。図６は、端末識別処理部１００の学習フェーズにおける処理の一例を示すフローチャートである。
【００７１】
ステップＳ６０１）集合作成部１０１は、集合Ｒｔ，ａを作成する。集合作成部１０１は、以下のようにして集合Ｒｔ，ａを作成することができる。
【００７２】
まず、集合作成部１０１は、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈと、端末種別ｄとを取得する。このとき、通信元アドレスａと、通信先ホストｈと、端末種別ｄとの組を示すレコードを識別する変数をｉとすれば、ｔにおけるレコードｒｔ，ｉの集合Ｒｔは、以下の数１で表される。
【００７３】
【数１】
2019036830.tif 000003
なお、ａｔ，ｉ、ｈｔ，ｉ及びｄｔ，ｉは、それぞれｔにおけるｉ番目のレコードｒｔ，ｉに含まれる通信元アドレスａ、通信先ホストｈ及び端末種別ｄである。
【００７４】
次に、集合作成部１０１は、通信元アドレスａ毎に各ｒｔ，ｉを集約することで、通信先ホストｈと、端末種別ｄとの組を示すレコードを作成する。このとき、通信先ホストｈと、端末種別ｄとの組を示すレコードを識別する変数をｊとすれば、ｊ番目のレコードｒｔ，ａ，ｊの集合Ｒｔ，ａは、以下の数２で表される。
【００７５】
【数２】
2019036830.tif 000004
なお、ｈｔ，ａ，ｊ及びｄｔ，ａ，ｊは、それぞれｔにおいて通信元アドレスａでレコードｒｔ，ｉを集約した場合におけるｊ番目のレコードｒｔ，ａ，ｊに含まれる通信先ホストｈ及び端末種別ｄである。
【００７６】
ステップＳ６０２）学習データ作成部１０２は、上記のステップＳ６０１で作成された集合Ｒｔ，ａに対して正解ラベルｄ´を割り当てることで学習データを作成する。学習データ作成部１０２は、以下のように学習データを作成することができる。
【００７７】
まず、学習データ作成部１０２は、集合Ｒｔ，ａに含まれる各端末種別ｄを抽象化する。これは、例えば、ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドを端末種別として用いた場合等には、端末種別を示す表記が統一されていない場合があるためである。
【００７８】
より具体的に説明すると、ユーザ端末２０の端末種別が「Ｌｉｎｕｘ」であっても、あるユーザ端末２０ではＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに「ｌｉｎｕｘ」と設定され、別のあるユーザ端末２０ではＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに「ｕｂｕｎｔｕ」と設定されることがある。したがって、この場合、例えば、「ｌｉｎｕｘ」や「ｕｂｕｎｔｕ」等を、統一的な表記である「Ｌｉｎｕｘ」に抽象化する必要がある。
【００７９】
次に、学習データ作成部１０２は、集合Ｒｔ，ａに対して正解ラベルｄ´を割り当てる。ここで、集合Ｒｔ，ａには、端末種別が不明であることを示す情報が含まれるレコードｒｔ，ａ，ｊが存在することがある。また、集合Ｒｔ，ａには、それぞれ異なる端末種別ｄが含まれるレコードｒｔ，ａ，ｊが存在することがある。このため、学習データ作成部１０２は、集合Ｒｔ，ａに対して正解ラベルｄ´を一意に決定できないことがある。
【００８０】
そこで、学習データ作成部１０２は、任意の方法で、集合Ｒｔ，ａに存在するレコードｒｔ，ａ，ｊの中から正解ラベルｄ´を選択すれば良い。例えば、集合Ｒｔ，ａに存在するレコードｒｔ，ａ，ｊの中で、最も数が多い（すなわち、最も出現回数が多い）端末種別ｄを正解ラベルｄ´としても良いし、人間の経験則に基づいて手動で正解ラベルｄ´を選択しても良い。
【００８１】
正解ラベルｄ´が選択された場合、学習データ作成部１０２は、集合Ｒｔ，ａに対して正解ラベルｄ´を割り当てる。これにより、学習データが作成される。すなわち、学習データは、集合Ｒｔ，ａと、正解ラベルｄ´との組で表される。
【００８２】
ただし、学習データには、集合Ｒｔ，ａに含まれる端末種別ｄが不要である場合もある。この場合、学習データは、通信先ホストｈｔ，ａ，ｊの集合と、正解ラベルｄ´との組であっても良い。
【００８３】
ステップＳ６０３）識別器作成部１０３は、上記のステップＳ６０２で作成された学習データを用いて、機械学習の手法により端末識別器２００を作成する。すなわち、識別器作成部１０３は、機械学習の手法により、学習データに含まれる通信先ホストｈの集合と、正解ラベルｄ´との関係性を学習させることで、端末識別器２００を作成する。
【００８４】
端末識別器２００には、通信先ホストｈの集合を入力として、正解ラベルｄ´を推定するために必要なデータが含まれる。端末識別器２００のデータ形式等は、識別器作成部１０３が利用する機械学習アルゴリズム又はその実装により異なる。機械学習アルゴリズムの要件は、以下の数３に示す関数ｆのように、通信先ホストｈのリスト（集合）から端末種別ｄ´を推定する処理を実施できることである。
【００８５】
【数３】
2019036830.tif 000005
機械学習アルゴリズムとしては、一般に、多クラス分類問題を解くができる任意のアルゴリズムを利用可能である。このようなアルゴリズムの一例としては、ランダムフォレストが挙げられる。ランダムフォレストについては、例えば「A. Liaw and M. Wiener (2002). Classification and Regression by randomForest. R News 2(3), 18-22.」等に開示されている。
【００８６】
以上により、本発明の実施の形態における端末識別装置１０は、識別フェーズにおいてユーザ端末２０の通信先ホストから端末種別を識別するための端末識別器２００を作成することができる。
【００８７】
＜識別フェーズにおける処理の詳細＞
次に、端末識別処理部１００の識別フェーズにおける処理の詳細について、図７を参照しながら説明する。図７は、端末識別処理部１００の識別フェーズにおける処理の一例を示すフローチャートである。
【００８８】
ステップＳ７０１）集合作成部１０１は、集合Ｓｔ，ａを作成する。集合作成部１０１は、以下のようにして集合Ｓｔ，ａを作成することができる。
【００８９】
まず、集合作成部１０１は、予め決められた時間ウインドウＴ毎に、通信記録ＤＢ１１０に格納されている通信元アドレスａと、通信先ホストｈとを取得する。このとき、通信元アドレスａと、通信先ホストｈとの組を示すレコードを識別する変数をｋとすれば、ｔにおけるレコードｒｔ，ｋの集合Ｓｔは、以下の数４で表される。
【００９０】
【数４】
2019036830.tif 000006
なお、ａｔ，ｋ及びｈｔ，ｋ及びｄｔ，ｉは、それぞれｔにおけるｋ番目のレコードｒｔ，ｋに含まれる通信元アドレスａ及び通信先ホストｈである。
【００９１】
次に、集合作成部１０１は、通信元アドレスａ毎に各ｒｔ，ｋを集約することで、通信先ホストｈを示すレコードを作成する。このとき、通信先ホストｈを示すレコードを識別する変数をｍとすれば、ｍ番目のレコードｒｔ，ａ，ｍの集合Ｓｔ，ａは、以下の数５で表される。
【００９２】
【数５】
2019036830.tif 000007
なお、ｈｔ，ａ，ｍは、ｔにおいて通信元アドレスａでレコードｒｔ，ｋを集約した場合におけるｍ番目のレコードｒｔ，ａ，ｍに含まれる通信先ホストｈである。
【００９３】
ステップＳ７０２）識別部１０４は、端末識別器２００を用いて、上記のステップＳ７０１で作成された集合Ｓｔ，ａから端末種別ｄ´を識別する。すなわち、識別部１０４は、端末識別器２００を用いて、集合Ｓｔ，ａに含まれる通信先ホストｈｔ，ａ，ｍの集合から端末種別ｄ´を識別する。
【００９４】
そして、識別部１０４は、通信元アドレスａと、端末種別ｄ´とを対応付けて識別結果ＤＢ１２０に格納する。
【００９５】
以上により、本発明の実施の形態における端末識別装置１０は、通信先ホストから端末種別を識別することができる。このため、本発明の実施の形態における端末識別装置１０では、例えば、ユーザ端末２０の製造元ベンダ等によりプリインストールされたアプリケーションプログラム等に依存した通信先ホストサーバ５０の差異によって、ユーザ端末２０の端末種別を識別することができる。同様に、例えば、ユーザ端末２０の利用形態（例えば、モバイル端末や固定端末等）に伴う利用サービスの差異（すなわち、通信先ホストサーバ５０の差異）によっても、ユーザ端末２０の端末種別を識別することができる。
【００９６】
したがって、本発明の実施の形態における端末識別装置１０によれば、例えば、ユーザ端末２０間でネットワーク・パラメータが共通であったとしても、端末種別に応じて通信先ホストに差異があれば、ユーザ端末２０の端末種別を識別することができるようになる。
【００９７】
＜具体例＞
以降では、本発明の実施の形態における端末識別の具体例について述べる。ＨＴＴＰ通信とＤＮＳ通信との両方のトラヒックをトラヒック収集装置３０による収集対象とした上で、数千ユーザ規模の１２時間分のトラヒックから通信時刻、通信元アドレス、通信先ホスト及び端末種別を抽出して通信記録ＤＢ１１０に格納した。また、端末識別処理部１００が通信記録ＤＢ１１０から情報を抽出する際の時間ウインドウＴは５分とした。このとき、通信先ホストは、約３万件を抽出した。
【００９８】
更に、図６のステップＳ６０２において、ＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列と、抽象化後の端末種別（正解ラベル）との関係は以下の（１）〜（４）の通りとした上で、学習データを作成した。Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列を判定する際、大文字と小文字の区別はないものとした。なお、いずれの端末種別にも抽象化できない場合には、識別不能を示す正解ラベルとした。
【００９９】
（１）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「ｉＰｈｏｎｅ（登録商標）」、「ｉＰａｄ（登録商標）」、「ｉＰｏｄ（登録商標）」、「ｗａｔｃｈＯＳ（登録商標）」、又は「Ａｐｐｌｅ  ＴＶ（登録商標）」（空白を除外した文字列（例えば、「ＡｐｐｌｅＴＶ」）も含む。）のいずれかである場合には、端末種別「ｉＯＳ（登録商標）」とする。
【０１００】
（２）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ａｎｄｒｏｉｄ」である場合には、端末種別「Ａｎｄｒｏｉｄ」とする。
【０１０１】
（３）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ｌｉｎｕｘ」又は「Ｕｂｕｎｔｕ（登録商標）」である場合には、端末種別「Ｌｉｎｕｘ」とする。
【０１０２】
（４）Ｕｓｅｒ−Ａｇｅｎｔフィールドに含まれる文字列が大文字と小文字を区別せず「Ｍｉｃｒｏｓｏｆｔ（登録商標）」又は「Ｗｉｎｄｏｗｓ」である場合には、端末種別「Ｗｉｎｄｏｗｓ」とする。
【０１０３】
そして、上記で作成した学習データを用いて、端末識別器２００を作成した。続いて、ＤＮＳ通信のＦＱＤＮをユーザ端末２０毎の通信先ホストとして識別フェーズを行った結果、以下の（Ａ）〜（Ｃ）の通信元アドレスと端末種別との識別結果が得られた。
【０１０４】
（Ａ）通信元アドレス「ａ．ａ．ａ．ａ」のユーザ端末２０は端末種別「ｉＯＳ」
（Ｂ）通信元アドレス「ｂ．ｂ．ｂ．ｂ」のユーザ端末２０は端末種別「Ａｎｄｒｏｉｄ」
（Ｃ）通信元アドレス「ｃ．ｃ．ｃ．ｃ」のユーザ端末２０は端末種別「Ｗｉｎｄｏｗｓ」
上記の（Ａ）〜（Ｃ）の識別結果は、別途平行して収集したＨＴＴＰ通信におけるＨＴＴＰヘッダのＵｓｅｒ−Ａｇｅｎｔフィールドに設定されている端末種別と一致していることを確認した。このため、本発明の実施の形態における端末識別装置１０によれば、高い精度で、通信先ホストから端末種別を識別できていることがわかる。
【０１０５】
＜同一のネットワーク・パラメータを有するユーザ端末２０における端末識別＞
ここで、同一のネットワーク・パラメータを有するユーザ端末２０における端末識別について補足する。ネットワーク・パラメータとＯＳとに関する調査文献（例えば、「MONTIGNY-LEBOEUF, De, et al. A multi-packet signature approach to passive operating system detection. DEFENCE RESEARCH AND DEVELOPMENT CANADAOTTAWA (ONTARIO), 2005.」）によれば、例えば、Ｌｉｎｕｘ２．４．０とＭａｃＯＳ１０．２．６とは、環境によっては、同一の初期ＴＴＬ値と、ＴＣＰパラメータ又はＳＹＮヘッダパラメータとを有する（ただし、実際にはカーネル・パラメータやパッチの適用状態等で異なる場合もある。）。
【０１０６】
このため、Ｌｉｎｕｘ２．４．０とＭａｃＯＳ１０．２．６とは、非特許文献１に開示されているパケットシグネチャを用いる方法では区別することができない。仮に、ＯＳの設定によりネットワーク・パラメータが変化した場合においても、この変化はＬｉｎｕｘ２．４．０及びＭａｃＯＳ１０．２．６の両者で発生する可能性がある。このため、ＯＳの設定による変化を、Ｌｉｎｕｘ２．４．０及びＭａｃＯＳ１０．２．６の両者を区別するシグネチャとして用いるのは困難である。
【０１０７】
一方で、例えば、Ｌｉｎｕｘには、固有の通信先ホスト（例えば、ＯＳリポジトリ・サーバ、各ソフトウェアのバージョン更新用のサーバ等）が存在する。同様に、ＭａｃＯＳにも固有の通信先ホスト（例えば、ＯＳバージョン確認用のサーバ、クラウドアプリの同期用サーバ等）が存在する。
【０１０８】
したがって、本発明の実施の形態における端末識別装置１０では、各ＯＳ固有の通信先ホストの差異を特徴として、これらのＯＳを識別することができる。
【０１０９】
本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。
【符号の説明】
【０１１０】
１０      端末識別装置
２０      ユーザ端末
３０      トラヒック収集装置
４０      ＤＮＳキャッシュサーバ
５０      通信先ホストサーバ
１００    端末識別処理部
１０１    集合作成部
１０２    学習データ作成部
１０３    識別器作成部
１０４    識別部
１１０    通信記録ＤＢ
１２０    識別結果ＤＢ
【図１】
2019036830.tif 000008
【図２】
2019036830.tif 000009
【図３】
2019036830.tif 000010
【図４】
2019036830.tif 000011
【図５】
2019036830.tif 000012
【図６】
2019036830.tif 000013
【図７】
2019036830.tif 000014