(57)【要約】【課題】ネットワーク全体におけるソフトウェア種別を含む端末情報を、短時間で高い精度をもって推定するのに使用される判定規則を生成する判定規則生成装置を提供する。【解決手段】本判定規則生成装置は、接続された複数の端末に付与されたアドレス毎に、これら端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、複数の端末から発信されたＤＮＳクエリを収集するクエリ収集手段と、ＤＮＳクエリの照会名毎に、ＤＮＳクエリの発信元アドレスの各々について、クエリ発生周期Ｔｑと、少なくともこの周期の分布における分散から決定される周期安定度ＳＴとを逐次算出して更新する発生周期算出手段と、照会名毎に、発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、決定されたクエリ発生周期Ｔｑ及び周期安定度ＳＴとを記録した判定規則を生成する判定規則生成手段とを有する。【選択図】図２
2014011695.tif 000002
【特許請求の範囲】
【請求項１】
ＤＮＳ（Domain Name System）サーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する判定規則生成装置であって、
接続された複数の端末に付与された発信元アドレス毎に、該複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
前記複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
を有することを特徴とする判定規則生成装置。
【請求項２】
収集された各クエリに含まれる照会名及び発信元アドレスを抽出し、当該クエリの発生時刻と当該照会名及び発信元アドレスとを対応付けて記録するクエリ情報取得手段を更に有しており、
前記発生周期算出手段は、当該照会名毎に、抽出された当該発信元アドレスの各々について、当該照会名を含むクエリの発生時間間隔の平均として前記クエリ発生周期を算出し、当該発生時間間隔の分布における分散として前記分散を算出する
ことを特徴とする請求項１に記載の判定規則生成装置。
【請求項３】
前記ソフトウェア種別は、ＯＳ(Operating System)種別及び／又はアプリケーション種別であり、
前記照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の、又は処理実行に必要な情報要求時の接続先アドレスを含む
ことを特徴とする請求項１又は２に記載の判定規則生成装置。
【請求項４】
前記判定規則生成手段は、当該クエリ発生周期を用いて前記多数の端末から発信される単位時間当たりのクエリ数から前記ネットワークに接続された端末数を算出し、当該周期安定度を用いてより高い精度で端末数を推定することを可能とする判定規則を生成することを特徴とする請求項１から３のいずれか１項に記載の判定規則生成装置。
【請求項５】
前記端末情報登録手段は、前記複数の端末に付与された発信元アドレス毎に、該複数の端末の端末種別を更に予め登録し、
前記判定規則生成手段は、当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応した端末種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を更に生成する
ことを特徴とする請求項１から４のいずれか１項に記載の判定規則生成装置。
【請求項６】
当該周期安定度は、当該クエリの発生時間間隔の分布における分散、尖度及び歪度についての所定の平均から決定されることを特徴とする請求項１から５のいずれか１項に記載の判定規則生成装置。
【請求項７】
ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する機能を搭載したルータであって、
接続された複数の端末に付与された発信元アドレス毎に、該複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
前記複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
を有することを特徴とするルータ。
【請求項８】
ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成するようにコンピュータを機能させる判定規則生成プログラムであって、
接続された複数の端末に付与された発信元アドレス毎に、該複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
前記複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
してコンピュータを機能させることを特徴とする判定規則生成プログラム。
【請求項９】
ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する判定規則生成方法であって、
接続された複数の端末に付与された発信元アドレス毎に、該複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段を用い、
前記複数の端末から発信された当該クエリを収集する第１のステップと、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する第２のステップと、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する第３のステップと
を有することを特徴とする判定規則生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の端末が接続されたネットワークの管理・監視の技術に関する。
【背景技術】
【０００２】
ネットワーク管理者は、ネットワークの安定した運用を維持するため、ネットワーク利用者の利用環境及び利用状況を把握しなければならない。この把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【０００３】
しかしながら、ネットワーク管理者が利用者の利用実態を十分に把握することは一般に困難である。例えば、インターネット接続業者（ＩＳＰ：Internet Service Provider）とそのユーザとのように、管理者と利用者とが異なる組織に属している場合、管理者が利用者の利用状況を監視することは困難である。特に、利用者が各々の好みにあった端末を選定して、任意のアプリケーションを自らインストールする場合、管理者は、このような利用者の状況を把握しづらい。
【０００４】
一方、企業内ネットワークのように、利用者のネットワーク利用が厳しく規定されている場合でも、利用者が、許可されていない端末を接続して規定外の利用を行う事態を許してしまう事例が存在する。また、例えば企業内のネットワークが国内外に及ぶ場合、利用状況を物理的に監視して直接把握することは極めて難しい。
【０００５】
このような状況下で、現在、利用者による通信のみを監視し、通信そのものから利用者の利用環境及び利用状況を把握する技術が検討されている。
【０００６】
例えば、非特許文献１及び２には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）における、オペレーティングシステム（ＯＳ: Operating System）に固有の振る舞いを監視することによって、利用者の各端末に搭載されたＯＳ種別を識別する方法が開示されている。
【０００７】
また、非特許文献３には、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダに含まれる、ＯＳ又はアプリケーションに固有の文字列を抽出し組み合わせて、利用者端末に搭載されたウェブブラウザ（Web Browser）種別を識別する技術が開示されている。
【０００８】
さらに、非特許文献４には、ＤＮＳ（Domain Name System）クエリのパターンを分析し、クエリパターンの時間差とパターン出現数との関係から、ＯＳ種別及びウェブブラウザ種別を識別する方法が開示されている。ここで、本方法は、ＩＰｖ４（Internet Protocol version 4）とＩＰｖ６（Internet Protocol version 6）とが混在している通信環境を前提としている。
【０００９】
また、通信ネットワーク上でのパケット監視ではないが、特許文献１には、コンピュータ・ネットワーク上で、ウィルスに感染したファイルやウィルスそのものを検出するため、ウィルスファイルに固有の文字列をシグネチャとして利用する技術が開示されている。ここでは、このシグネチャを予め登録し、このシグネチャを含むファイルをウィルスの含まれたものと判定する。
【００１０】
さらに、特許文献２には、コンピュータ・ウィルス検出用のシグネチャを自動生成する方法が開示されている。ここでは、既知の正常なファイルと既知の不正なファイルとを比較し、ｎグラムアルゴリズムを利用してシグネチャを自動生成する。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】特表平１１−５１３１５３号公報
【特許文献２】特開平６−２５０８６１号公報
【非特許文献】
【００１２】
【非特許文献１】Passive OS Fingerprinting (p0f)、「the new p0f:2.0.8 (2006-09-06)」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://lcamtuf.coredump.cx/p0f.shtml＞
【非特許文献２】Nmap Fingerprint、「Understanding an NmapFingerprint」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://nmap.org/book/osdetect-fingerprint-format.html＞
【非特許文献３】Peter Eckersley、ELECTRONIC FRONTIERFOUNDATION 「How Unique Is Your Web Browser?」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://panopticlick.eff.org/browser-uniqueness.pdf＞
【非特許文献４】川口敬、早稲田大学理工学部コンピュータ・ネットワーク工学科後藤研究室B4 1G06R055-7 卒業論文発表、「ＤＮＳクエリーパターンを用いたＯＳの推定」、［online］、［平成２４年１月１９日検索］、インターネット＜URL:http://www.goto.info.waseda.ac.jp/forB4/pdf-th/2009/0201_kawaguchi.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【００１３】
しかしながら、上述したような従来技術を用いても、ＩＳＰレベルの大規模なネットワーク全体における、端末種別や端末に搭載されたソフトウェア種別（ＯＳ種別及びアプリケーション種別）といった端末情報を推定することは、非常に困難である。
【００１４】
例えば、非特許文献１及び３の技術では、基本的にネットワーク上の通信を全て取得する必要がある。その結果、大規模なネットワークでは導入コスト又は監視負担が増大し実現性が低下する。また、非特許文献１及び２の技術では、ＴＣＰ／ＩＰの特徴を利用するので、ＯＳ種別を識別することしかできない。一方、非特許文献３の技術では、ＨＴＴＰヘッダの特徴を利用するので、ウェブブラウザ種別を識別することしかできない。
【００１５】
さらに、非特許文献４の技術では、ＩＰｖ４とＩＰｖ６とが混在している通信環境であることが前提となるため、ＩＰｖ４又はＩＰｖ６単独の環境では、ＯＳ種別を識別することができない。従って、ＩＰｖ６への全面移行の際には、当該技術は適用不可能となる。
【００１６】
また、端末が携帯電話等のモバイル機器の場合、端末が数分間乃至数時間のオーダで別の通信エリアに移動してしまう可能性が生じる。このため、上述したような従来技術では、実際の端末情報を適宜取得することが更に困難となってしまう。
【００１７】
以上説明したことから、端末種別、ＯＳ種別及びアプリケーション種別、並びにこれらに対応する端末の総数といった端末情報を取得・推定するためには、通信ネットワーク上でのパケット監視を、適切な判定規則に基づいて、できるだけ短時間で行う必要がある。
【００１８】
ここで、特許文献１及び２に記載されたシグネチャを利用したファイル監視方法、及び同シグネチャの自動生成方法は、確かに、シグネチャを含む判定規則を利用してウィルスの検出を行うものである。しかしながら、これらの方法はあくまでコンピュータ・ネットワーク上のファイルを対象としたものである。ここで、例え、通信ネットワーク上でのパケット監視に、このような固有のシグネチャ（文字列）を利用した判定規則を単純に適用しても、以上に述べた課題を解決することはできない。
【００１９】
そこで、本発明は、ネットワーク全体におけるソフトウェア種別を含む端末情報を、短時間で高い精度をもって推定するのに使用される判定規則を生成する判定規則生成装置、ルータ、プログラム及び方法を提供することを目的とする。
【課題を解決するための手段】
【００２０】
本発明によれば、ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する判定規則生成装置であって、
接続された複数の端末に付与された発信元アドレス毎に、これら複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
を有する判定規則生成装置が提供される。
【００２１】
この本発明の判定規則生成装置では、
収集された各クエリに含まれる照会名及び発信元アドレスを抽出し、当該クエリの発生時刻と当該照会名及び発信元アドレスとを対応付けて記録するクエリ情報取得手段を更に有しており、
前記発生周期算出手段は、当該照会名毎に、抽出された当該発信元アドレスの各々について、当該照会名を含むクエリの発生時間間隔の平均として前記クエリ発生周期を算出し、当該発生時間間隔の分布における分散として前記分散を算出することも好ましい。
【００２２】
また、本発明の判定規則生成装置では、ソフトウェア種別は、ＯＳ種別及び／又はアプリケーション種別であり、照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の、又は処理実行に必要な情報要求時の接続先アドレスを含むことも好ましい。
【００２３】
また、本発明の判定規則生成装置において、判定規則生成手段は、当該クエリ発生周期を用いて上記多数の端末から発信される単位時間当たりのクエリ数から上記ネットワークに接続された端末数を算出し、当該周期安定度を用いてより高い精度で端末数を推定することを可能とする判定規則を生成することも好ましい。
【００２４】
さらに、本発明の判定規則生成装置についての他の実施形態として、端末情報登録手段は、複数の端末に付与された発信元アドレス毎に、これら複数の端末の端末種別を更に予め登録し、
判定規則生成手段は、当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応した端末種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を更に生成することも好ましい。
【００２５】
また、本発明の判定規則生成装置において、当該周期安定度は、当該クエリの発生時間間隔の分布における分散、尖度及び歪度についての所定の平均から決定されることも好ましい。
【００２６】
本発明によれば、さらに、ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する機能を搭載したルータであって、
接続された複数の端末に付与された発信元アドレス毎に、これら複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
を有するルータが提供される。
【００２７】
本発明によれば、さらにまた、ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成するようにコンピュータを機能させる判定規則生成プログラムであって、
接続された複数の端末に付与された発信元アドレス毎に、これら複数の端末に搭載されたソフトウェア種別を予め登録する端末情報登録手段と、
複数の端末から発信された当該クエリを収集するクエリ収集手段と、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する発生周期算出手段と、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する判定規則生成手段と
してコンピュータを機能させる判定規則生成プログラムが提供される。
【００２８】
本発明によれば、さらに、ＤＮＳサーバに、ネットワークを介して照会名を含むクエリを発信する多数の端末における端末情報を推定するための判定規則を生成する判定規則生成方法であって、
接続された複数の端末に付与された発信元アドレス毎に、これら複数の端末に搭載されたソフトウェア種別を予め登録した端末情報登録手段を用い、
複数の端末から発信された当該クエリを収集する第１のステップと、
当該クエリの照会名毎に、当該クエリの発信元アドレスの各々について、当該照会名を含むクエリの発生する周期であるクエリ発生周期と、少なくとも当該クエリの発生する周期の分布における分散から決定される周期安定度とを逐次算出して更新する第２のステップと、
当該照会名毎に、当該照会名を含むクエリの発信元アドレスに対応して登録されており当該照会名に対応したソフトウェア種別と、最終的に決定された当該クエリ発生周期及び当該周期安定度とを記録した判定規則を生成する第３のステップと
を有する判定規則生成方法が提供される。
【発明の効果】
【００２９】
本発明の判定規則生成装置、ルータ、プログラム及び方法によれば、ネットワーク全体におけるソフトウェア種別を含む端末情報を、短時間で高い精度をもって推定するのに使用される判定規則を生成することができる。
【図面の簡単な説明】
【００３０】
【図１】本発明による判定規則生成装置が接続されるネットワークの構成図である。
【図２】本発明による判定規則生成装置の一実施形態における機能構成図である。
【図３】本発明による判定規則生成過程で形成される各種のテーブル例である。
【図４】本発明に係る判定規則の一実施形態である。
【図５】本発明による判定規則生成方法の一実施形態を示すフローチャートである。
【図６】本発明に係る判定規則を用いた端末情報推定例を示すフローチャートである。
【発明を実施するための形態】
【００３１】
以下では、本発明の実施形態について、図面を用いて詳細に説明する。
【００３２】
図１は、本発明による判定規則生成装置が接続されるネットワークの構成図である。
【００３３】
図１によれば、判定規則生成装置１は、複数の端末２が接続された有線・無線インタフェース１００ａ及び１００ｂと、判定規則生成部１１４と、プロバイダネットワーク４に接続された通信インタフェース１０１とを有する。
【００３４】
判定規則生成部１１４は、複数の端末２から、プロバイダネットワーク４内の名前解決を受け持つＤＮＳサーバ３宛に発信されたＤＮＳクエリ（query）の解析結果を入力し、多数の端末７に係る端末情報を推定するための「判定規則」を生成する。ここで、複数の端末２は、「判定規則」を生成するために接続された端末である。一方、多数の端末７は、プロバイダネットワーク４に接続された端末であり、端末情報の推定対象である。
【００３５】
プロバイダネットワーク４は、例えばＩＳＰの事業者ネットワークであり、１つ又は複数のアクセスネットワークを含む。このアクセスネットワークは、例えば、３Ｇ（3rd Generation）、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、ＬＴＥ(Long Term Evolution) 、光ファイバ網、ＡＤＳＬ（Asymmetric Digital Subscriber Line）等のネットワークとすることができる。
【００３６】
ここで、各端末２は、搭載されたＯＳ及びアプリケーション等のソフトウェアの更新を適宜実行する。その際、インターネット５を通して定期的に、ソフトウェア種別固有のサイトに更新の確認を試みる。従って、このサイトのアドレスを知る必要が生じる。そこで、各端末２は、このサイトのドメイン名（照会名）を含むＤＮＳクエリを、ソフトウェア種別固有の時間間隔をもって、ＤＮＳサーバ３に送信する。ＤＮＳサーバ３は、ＤＮＳクエリを受け取ると、他のＤＮＳサーバと通信して又は自ら名前を解決して、接続先アドレスを含む応答（リソースレコード）をクエリ発信元の端末２に送信する。
【００３７】
例えば、ＯＳ種別毎の更新確認時の照会名は、以下の通りである。
《ＯＳ種別ＯＳｉ》                  《照会名Ｎｄ》
Windows OS（Microsoft社）          download.windowsupdate.com
Android（Google社）                android.clients.google.com
Mac OS（Apple社）                  swscan.apple.com
iOS（Apple社）                     push.apple.com、phobos.apple.com、
iphone-ld.apple.com
ＯＳ更新確認の時間間隔は、ＯＳ種別にもよるが、例えばApple社のiOSでは、１２時間となる。
【００３８】
また、アプリケーション種別の例として、代表的なウェブブラウザ毎の更新確認時の照会名は、例えば、以下の通りである。
《ウェブブラウザ》                      《照会名Ｎｄ》
Mozilla Firefox（Mozilla Foundation）    www.mozilla.com
Chrome（Google社）                       www.google.com
Opera（Opera Software社）                autoupdate.opera.com
アプリケーション更新確認の時間間隔は、アプリケーション種別にもよるが、例えばアップル（Apple）社の「iCloud」では、１.５時間となる。
【００３９】
さらに、各端末２に搭載されたソフトウェアに関連するＤＮＳクエリの発信は、上述したようなソフトウェア更新確認時のみならず、ソフトウェア処理の実行に必要な情報要求時にも実施される。例えば、時刻合わせのための時刻情報の要求時、電子メールにおけるメールボックスの確認時、各種ソーシャルネットワーク・サービスにおける他者情報のチェック時等にも、ＤＮＳクエリが発信される。即ち、多くのソフトウェアでは、ＤＮＳサーバ３を利用して名前を解決してから通信を開始することが１つのパターンとなっている。
【００４０】
この際の照会名（接続先のドメイン名）には、ソフトウェア種別（ＯＳ種別、アプリケーション種別）、更には端末種別（端末メーカー、型番）に固有のものが多く存在する。さらに、例えば、１つのＯＳ種別（例えば、Google社の提供するAndroidＯＳ）であっても、異なる端末メーカーに搭載される場合が多く存在する。また、端末２に搭載された多くのソフトウェアは、立ち上げ毎に端末メーカーのサイトへアクセスするが、同じ端末メーカーの端末でも型番によって、アクセスするサイトが異なる場合も生じる。従って、各端末２は、ソフトウェア種別に固有の照会先だけでなく、端末種別に固有の照会先をもって、ＤＮＳクエリをＤＮＳサーバ３宛に送信する場合が多く存在する。判定規則生成装置１は、これらの固有の照会先を有するＤＮＳクエリを収集して「判定規則」を生成する。
【００４１】
同じく図１において、判定規則生成装置１の判定規則生成部１１４によって作成された「判定規則」は、端末情報推定装置６が多数の端末７における「端末情報」を推定する際に使用されるデータのテーブルである。ここで、多数の端末７は、プロバイダネットワーク利用者の端末であり、プロバイダネットワーク４を介してインターネット５に接続する。また、「端末情報」とは、端末７の端末種別（端末メーカー名、機種）、並びに端末７に搭載されたソフトウェア種別（ＯＳ種別、アプリケーション種別）、更にはそれらの種別毎の端末数を指す。
【００４２】
端末情報推定装置６は、ＤＮＳサーバ３への回線に設けられたネットワークタップ（又はミラーリングハブ）を介してプロバイダネットワーク４に接続される。これにより、端末情報推定装置６は、多数の端末７がプロバイダネットワーク４を介してＤＮＳサーバ３宛に発信するＤＮＳクエリを全て収集し、ＤＮＳクエリを解析して「端末情報」を推定する。
【００４３】
その際、端末情報推定装置６は、判定規則生成装置１からプロバイダネットワーク４を介して発信された「判定規則」を受信して端末情報推定に利用する。この「判定規則」では、多数の端末７から発信されるＤＮＳクエリを解析する際に用いる所定の文字列（シグネチャ）として、照会名（ドメイン名）が採用されている。
【００４４】
このような「判定規則」を生成するために、端末２は、例えば搭載された１つのＯＳ種別及びアプリケーション種別につき１０〜１００台程度、有線・無線インタフェース１００ａ及び１００ｂに接続されることも好ましい。当然に更に多くの端末２を接続することによって、より精度の高い「判定規則」を生成することも可能となる。
【００４５】
また、信頼性の高い「判定規則」を得るために、端末２は、ＤＮＳクエリが収集される判定規則生成期間中、常時、接続が確立した状態に置かれることも好ましい。いずれにしても、接続される複数の端末２の端末情報（付与されたＩＰ（Internet Protocol）アドレス、端末種別、搭載されたＯＳ種別及びアプリケーション種別等）は、判定規則生成装置１に登録され、「判定規則」の生成に利用される。
【００４６】
判定規則生成装置１は、例えば２４時間〜数ヶ月間連続して、端末２から発信されたＤＮＳクエリの収集を行って「判定規則」を生成することができる。その際、判定規則生成装置１は、ＤＮＳクエリの発信元ＩＰアドレス（端末２に付与されたＩＰアドレス）に対応付けて登録されておりＤＮＳクエリの照会名に対応するソフトウェア種別（ＯＳ種別又はアプリケーション種別）毎に、「クエリ発生周期」と「周期安定度」とを逐次算出し更新する。
【００４７】
ここで、本願発明者等は、多くのソフトウェア種別（ＯＳ種別、アプリケーション種別）において、ソフトウェア更新確認のためのＤＮＳクエリに限らず、種々のＤＮＳクエリの発信タイミングが、ソフトウェア種別固有の「クエリ発生周期」を有し得ることを見出した。
【００４８】
この「クエリ発生周期」は、対象となっているＤＮＳクエリの発生時間間隔の平均値である。ＤＮＳクエリは、定期的なＯＳ更新確認等、対応するソフトウェア種別（照会名）固有の時間間隔（周期）をもって発信される場合が多く、ソフトウェア種別（照会名）毎に「クエリ発生周期」が決定可能である。
【００４９】
但し、実際の名前解決の際には、前回のＤＮＳクエリに対する応答としてキャッシュされたリソースレコードのＴＴＬ（Time To Live）に応じて所定の時間が指定され、この時間内にはクエリは発信されない（このリソースレコードで回答されたドメイン名が再利用される）。このような事情等があって、クエリ発生の時間間隔（周期）には変動が生じる。「周期安定度」は、この変動の少なさに相当し、後述するように、少なくとも「クエリ発生周期」の分布における分散から決定される。
【００５０】
判定規則生成装置１は、以上のようにして最終的に、照会名及びソフトウェア種別毎に「クエリ発生周期」及び「周期安定度」を対応付けた「判定規則」を生成する。
【００５１】
一方、端末情報推定装置６は、受信した「判定規則」のうち「クエリ発生周期」を用いて、多数の端末７から発信される単位時間当たりのＤＮＳクエリ数からプロバイダネットワーク４に接続された端末数（各ソフトウェア種別を搭載した端末７の数）を算出する。また、端末情報推定装置６は、後述するように、算出された端末数を「周期安定度」を用いて加重平均することによって、より高い精度で端末数を推定する。
【００５２】
ここで、「判定規則」は、上述したように、判定規則生成装置１によって、端末情報が把握されている複数の端末２を用い、十分な時間をかけて生成される。その結果、照会名及びソフトウェア種別毎に対応付けられた「クエリ発生周期」及び「周期安定度」も十分に信頼される値とすることができる。その結果、端末情報推定装置６は、相当の短時間で端末数を高い精度をもって推定することができる。即ち、判定規則生成装置１によれば、プロバイダネットワーク４全体におけるソフトウェア種別を含む端末情報を、短時間で高い精度をもって推定するのに使用される「判定規則」が生成可能となる。
【００５３】
尚、以上に述べた判定規則生成装置１は、例えば、企業内ネットワークのルータの位置に設置可能である。また、判定規則生成装置１の機能を備えており且つ複数の端末２のルーティングを行うルータを、判定規則生成装置とすることも可能である。さらに、判定規則生成装置１は、実際に運用されるネットワークから独立した実験系ネットワークと複数の端末２とを仲介するものであってもよい。いずれにしても、判定規則生成装置は、複数の端末２全ての端末情報を管理・登録可能な環境に設置される。
【００５４】
［判定規則生成装置］
図２は、本発明による判定規則生成装置の一実施形態における機能構成図である。また、図３は、本発明による判定規則生成過程で形成される各種のテーブル例であり、図４は、最終的に生成される判定規則の一実施形態である。
【００５５】
図２によれば、判定規則生成装置１は、無線インタフェース１００ａと、有線インタフェース１００ｂと、通信インタフェース１０１と、入力部１０２と、出力部１０３と、クエリ収集部１１０と、クエリ情報取得部１１１と、端末情報登録部１１２と、発生周期算出部１１３と、判定規則生成部１１４とを有する。判定規則生成装置１は、例えばパーソナルコンピュータのようなものであって、この装置１に搭載されたコンピュータを機能させるプログラムを実行することによって、判定規則の生成に係る機能が実現される。
【００５６】
無線インタフェース１００ａ及び有線インタフェース１００ｂは、複数の端末２と接続し、複数の端末２との通信を確立させる。無線インタフェース１００ａとして、例えば、Ｗｉ−Ｆｉ（登録商標）等の無線ＬＡＮ、Bluetooth（登録商標）等のうち１つ以上を採用することができる。また、有線インタフェース１００ｂとして、有線ＬＡＮ（Local Area Network）、ＵＳＢ（Universal Serial Bus）等のうち１つ以上を採用することができる。
【００５７】
通信インタフェース１０１は、端末２によるプロバイダネットワーク４との通信を仲介すると共に、判定規則生成部１１４で生成された判定規則テーブル１１４ｔを、端末情報推定装置６宛に発信する通信を仲介する。
【００５８】
入力部１０２は、端末情報登録部１１２に登録される端末情報を入力する。入力部１０２は、例えば、企業内ネットワークの管理者によって編集された、企業内ネットワークに接続された複数の端末２に係る情報のデータベースを、入力可能とするインタフェースであってもよい。ここで、各端末２に係る情報とは、ＤＨＣＰ（Dynamic Host Configuration Protocol）サーバによって付与されたＩＰアドレス、端末２のＭＡＣ（Media Access Control）アドレス、端末メーカー、機種、及び搭載ソフトウェア（ＯＳ・アプリケーション）種別等である。
【００５９】
尚、複数の端末２にＩＰアドレスを割り当てるＤＨＣＰサーバにおいて、所定のＩＰアドレスを所定のＭＡＣアドレスに付与する設定がなされており、この付与情報が通信インタフェース１０１を介して端末情報登録部１１２に送信されることも好ましい。また、判定規則生成装置１自体がＤＨＣＰサーバ機能を有しており、複数の端末２にＩＰアドレスを付与すると共に、ＩＰアドレスとＭＡＣアドレス等との対応テーブルを端末情報登録部１１２に出力することも好ましい。さらに、企業内ネットワークにおいて、所定のＯＳ又はアプリケーションのみ使用が許可される等のレギュレーションが存在する場合、このレギュレーション情報も入力部１０２を介して入力されることが好ましい。また、入力部は、ＩＰアドレスに対応した端末情報（の一部）を入力するための、キーボード等の入力装置を備えていてもよい。
【００６０】
出力部１０３は、判定規則生成部１１４で生成された判定規則をディスプレイ表示し、紙等の媒体として出力し、又はデータとして外部装置に出力する。
【００６１】
クエリ収集部１１０は、複数の端末２から発信され、無線・有線インタフェース１００ａ及び１００ｂを介して入力したパケットのうち、ＤＮＳサーバ３宛のＤＮＳクエリを識別して収集し、蓄積する。
【００６２】
クエリ情報取得部１１１は、収集された各ＤＮＳクエリに含まれる照会名Ｎｄ、発信元ＩＰアドレス等のクエリ情報を抽出し、このクエリ情報とこのＤＮＳクエリの発生時刻とを対応付けたデータを逐次発生周期算出部１１３に出力し記録する。また、このデータを蓄積したクエリ情報テーブル１１１ｔ（図３（Ａ））を作成・更新することも好ましい。
【００６３】
図３（Ａ）によれば、クエリ情報テーブル１１１ｔでは、ＤＮＳクエリの発生時刻毎に、このＤＮＳクエリに含まれる照会名Ｎｄ、発信元ＩＰアドレス、及びクエリタイプが記録されている。ここで、クエリタイプは、このＤＮＳクエリが要求する情報の種類を表し、例えばタイプＡは、ホストアドレスを要求していることを示す。ここで、以後、クエリタイプがＡである照会名Ｎｄに係る情報のみを使用する、とすることができる。
【００６４】
図２に戻って、端末情報登録部１１２は、複数の端末２に付与されたＩＰアドレスと、各端末２の端末情報（ＭＡＣアドレス、端末メーカー、機種、及び搭載ソフトウェア種別）との対応関係を、端末情報テーブル１１２ｔ（図３（Ｂ））として登録する。
【００６５】
図３（Ｂ）によれば、端末情報テーブル１１２ｔでは、複数の端末２に付与されたＩＰアドレス毎に、この端末２のＭＡＣアドレス、端末２に搭載されたソフトウェア種別（ＯＳ種別ＯＳｉ・アプリケーション種別ＡＰｊ）、端末２のハードウェア種別（端末メーカー、機種等）が記録されている。
【００６６】
図２に戻って、発生周期算出部１１３は、クエリ情報取得部１１１から、ＤＮＳクエリの発生時刻をクエリ情報と対応付けたデータ（又は更新されたクエリ情報テーブル１１１ｔ）を逐次入力する。この際、照会名Ｎｄが新規か否かを判定し、新規であれば、この照会名Ｎｄを新たにクエリ周期テーブル１１３ｔ（図３（Ｃ））にエントリする。一方、新規でなければ、既にクエリ周期テーブル１１３ｔにエントリされている当該照会名Ｎｄの欄を更新する。具体的には、照会名Ｎｄ毎（照会名Ｎｄに対応するソフトウェア種別毎）に、ＤＮＳクエリの発生頻度ｆｑを、クエリ周期テーブル１１３ｔに記録・更新する。
【００６７】
さらに、発生周期算出部１１３は、照会名Ｎｄ毎に、ＤＮＳクエリの発信元ＩＰアドレスの各々について、同一の発信元ＩＰアドレスを有し当該照会名Ｎｄを含むＤＮＳクエリの発生時刻の間隔Δｔｎ（ｎ番目の発生時間間隔）の算出式
（１）  Δｔｎ＝ｔｎ＋１−ｔｎ  （ｔｎ：ＤＮＳクエリのｎ番目の発生時刻）
を用いてΔｔ１をまず算出し、この照会名Ｎｄに対応するソフトウェア種別毎に、クエリ発生周期Ｔｑとして、クエリ周期テーブル１１３ｔに記録する。
【００６８】
次いで、逐次入力されるデータを用いて、発生時間間隔Δｔｎ（ｎ≧１）を順次算出し、その都度、
（２）  Ｔｑ＝Σ（Δｔｍ）／ｎ
として、クエリ周期テーブル１１３ｔのクエリ発生周期Ｔｑを更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和（summation）である。即ち、クエリ発生周期Ｔｑは、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの平均値として順次更新される。
【００６９】
発生周期算出部１１３は、さらに、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における分散Ｖｑを次式
（３）  Ｖｑ＝Σ（Δｔｍ−Ｔｑ（ｎ））２／ｎ
を用いて順次算出し、クエリ周期テーブル１１３ｔにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。また、Ｔｑ（ｎ）は、発生時間間隔Δｔｎまで考慮して算出されたクエリ発生周期である。
【００７０】
発生周期算出部１１３は、また、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における尖度Ｋｑを次式
（４）  Ｋｑ＝Σ（Δｔｍ−（Ｔｑ（ｎ））４）／（ｎＶｑ２）−３
を用いて順次算出し、クエリ周期テーブル１１３ｔにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。一般に、正規分布よりも尖った（扁平な）分布の尖度Ｋｑは、ゼロより大きく（小さく）なる。正規分布相当の分布の尖度はゼロである。
【００７１】
発生周期算出部１１３は、さらに、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における歪度Ｓｑを次式
（５）  Ｓｑ＝Σ（Δｔｍ−Ｔｑ（ｎ））３／（ｎＶｑ１.５）
を用いて順次算出し、クエリ周期テーブル１１３ｔにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。一般に、左側（右側）に偏った分布の歪度Ｓｑは、ゼロより大きく（小さく）なる。左右対称な分布の歪度はゼロである。
【００７２】
発生周期算出部１１３は、さらに、算出された分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑを用いて、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの周期安定度ＳＴを次式
（６ａ）  ＳＴ＝１−ＡＳＴ
（６ｂ）  ＡＳＴ＝Ｎ［（Ｖｑ２＋Ｋｑ２＋Ｓｑ２）０.５］
を用いて順次算出し、クエリ周期テーブル１１３ｔにおいて逐次記録・更新する。ここで上式（６ｂ）の関数Ｎ［Ｘ］は、ゼロ又は正値をとる変数Ｘを０から１までの値に規格化する関数であり、例えば、
（７）  Ｎ［Ｘ］＝−（Ｘ＋１）−１＋１
とすることができる。これにより、ＡＳＴは、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における平均値（クエリ発生周期Ｔｑ）の不安定度（不確からしさ）に相当し、分布がより分散していて、より正規分布から逸脱しており、より偏りが大きいほど、大きな値をとる。
【００７３】
その結果、周期安定度ＳＴの値は、クエリ発生時間間隔が最も安定している場合（不安程度ＡＳＴがゼロの場合）、１となる。一方、クエリ発生時間間隔がクエリ発生周期Ｔｑから変動しがちになるにつれて、ゼロに近づく。このような周期安定度ＳＴの値を導入して端末情報（端末数等）の推定を行うことによって、より精度の高い推定が可能となる。
【００７４】
尚、周期安定度ＳＴは、（６ａ）及び（６ｂ）で規定されるものに限らない。分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑについての上記以外の所定の平均から決定されることも好ましく、又は、分散Ｖｑのみから決定される（例えばＳＴ＝１−Ｎ［Ｖｑ］）ことも可能である。
【００７５】
図３（Ｃ）によれば、クエリ周期テーブル１１３ｔでは、照会名Ｎｄ毎（照会名Ｎｄに対応するソフトウェア種別毎）に、クエリ周期情報（総観測時間、ＤＮＳクエリの発生頻度ｆｑ、クエリ発生周期Ｔｑ、分散Ｖｑ、尖度Ｋｑ、歪度Ｓｑ、及び周期安定度ＳＴ）が記録され、更新されている。具体的には、端末情報登録部１１２（端末情報テーブル１１２ｔ）に登録された、複数の端末２に搭載されているソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）の各々において、対応する照会名Ｎｄの欄に、クエリ周期情報が記録され、逐次更新される。
【００７６】
また、クエリ周期テーブル１１３ｔでは、更に、照会名Ｎｄに対応する端末２のハードウェア種別（端末メーカー、機種等）毎に、クエリ周期情報が記録され逐次更新される。
【００７７】
クエリ周期テーブル１１３ｔのデータの更新（ＤＮＳクエリの収集・解析）は、予め設定されたＤＮＳクエリの総観測時間Ｔｍｅだけ実施される。クエリ周期テーブル１１３ｔのデータは、この総観測時間Ｔｍｅの間更新され、Ｔｍｅ経過後、最終的に決定される。この総観測時間Ｔｍｅは、例えば、２４時間〜数ヶ月間に設定される。
【００７８】
図２に戻って、判定規則生成部１１４は、発生周期算出部１１３から、更新が終了して決定されたデータを有するクエリ周期テーブル１１３ｔを入力する。判定規則生成部１１４は、このクエリ周期テーブル１１３ｔをまとめて、判定規則１１４ｔ（図４）を作成する。
【００７９】
図４によれば、判定規則１１４ｔでは、ソフトウェア種別（ＯＳ種別ＯＳｉ、アプリケーション種別ＡＰｊ）及び照会名Ｎｄ毎に、クエリタイプｔｑ、クエリ発生周期Ｔｑ、及び周期安定度ＳＴが記録されている。
【００８０】
また、判定規則１１４ｔにおいて、ＯＳ種別の１つであるｊＯＳは、対応する３つの照会名Ｎｄ（abc.xxxupdate.com、efg.clients.com、及びhij.klmno.com）を有している。即ち、ｊＯＳを搭載した端末２からは、これら３つの照会名Ｎｄをそれぞれ含む３種のＤＮＳクエリが、それぞれのクエリ発生周期Ｔｑ及び周期安定度ＳＴをもって発生する。
【００８１】
ここで、後に（図６のＳ６０９を用いて）詳述するように、いずれの照会名Ｎｄに対応するデータ（クエリ発生周期Ｔｑ）を用いても、ｊＯＳを搭載した端末数を算出することができる。しかしながら、本発明による周期安定度ＳＴを用いることによって、算出された３つの端末数から、より精度の高い端末数を推定することができるのである。
【００８２】
このような理由から、判定規則１１４ｔにおいては、１つのソフトウェア種別に対し複数の照会名Ｎｄが必ず記録されていて、それぞれの照会名Ｎｄ毎に独立したクエリ発生周期Ｔｑ及び周期安定度ＳＴが規定されていることが好ましい。
【００８３】
尚、最近の傾向では、移動端末に搭載されたＯＳにおいて、ポーリング系のアプリケーションを採用するケースが増加している。このため、１つのソフトウェア種別に対して複数個の照会名を規定し易くなっている。
【００８４】
尚、判定規則１１４ｔにおいて、照会名Ｎｄによっては、この照会名Ｎｄがある特定のソフトウェア種別に固有の文字列である、と見なすことはできず、この照会名Ｎｄに複数のソフトウェア種別が対応する場合も存在する。例えば、図４に示した判定規則１１４ｔによれば、照会名Ｎｄ：klm.bqq.comに対して２つのＯＳ種別：ＮｂｄＯＳ及びＯＳｙｙが対応している。この場合、この判定規則１１４ｔを用い、端末情報推定装置６において照会名Ｎｄ：klm.bqq.comを含むクエリ数をカウントしたとしても、本来、そのカウント数が、ＮｂｄＯＳに係る端末数なのか又はＯＳｙｙに係る端末数なのかを判定することはできない。
【００８５】
しかしながら、ＮｂｄＯＳの場合のクエリ発生周期が５３８.７秒であるのに対し、ＯＳｙｙの場合のクエリ発生周期は１７１８５０.１秒であり桁違いに長くなっている。その結果、端末情報推定装置６において、ＮｂｄＯＳを搭載した端末７の台数とＯＳｙｙを搭載した端末７の台数との比が所定範囲内であるとの見込みの下、照会名Ｎｄ：klm.bqq.comを含むクエリのカウント数を、概ねＮｂｄＯＳに係る端末数に対応すると近似することが可能となる。このように、特定のソフトウェア種別に固有の文字列とはなっていない照会名Ｎｄをも判定規則に登録して、総数（端末数）の推定に有効利用することができる場合が存在する。
【００８６】
さらに、判定規則１１４ｔには、照会名Ｎｄ毎にクエリ発生周期Ｔｑ及び周期安定度ＳＴが規定されるので、周期性の信頼度が高い（周期のばらつきが小さい）照会名Ｎｄを、見出し、確認し、更には選別することも可能となる。例えば、周期安定度ＳＴが所定値以下（例えば０.２以下）である照会名Ｎｄは、端末情報の算出・推定に使用しないとすることも可能である。実際、端末情報の推定においては、精度の高い端末情報（端末数）を得るために、どの照会名Ｎｄを（どの程度）採用するが非常に重要となる。この点、周期安定度ＳＴは、その判断のための強力な指標となる。
【００８７】
図２に戻って、この判定規則１１４ｔは、通信インタフェース１０１を介して端末情報推定装置６に送信される。端末情報推定装置６は、受信した判定規則１１４ｔに記録されたクエリ発生周期Ｔｑを用いて多数の端末７から発信される単位時間当たりのＤＮＳクエリ数からネットワーク４に接続された端末数を算出する。また、判定規則１１４ｔに記録された周期安定度ＳＴを用いてより高い精度で端末数を推定する。
【００８８】
［判定規則生成方法］
図５は、本発明による判定規則生成方法の一実施形態を示すフローチャートである。
【００８９】
（Ｓ５００）最初に、複数の端末２に付与された発信元ＩＰアドレス毎に、端末２に搭載されたソフトウェア種別（ＯＳ種別ＯＳｉ、アプリケーション種別ＡＰｊ）を予め登録する。
【００９０】
（Ｓ５０１）ＤＮＳクエリ情報収集ループ（ステップＳ５０１〜Ｓ５０８）を開始する。総観測時間（収集時間）はＴｍｅとする。
（Ｓ５０２）端末２から発信されたＤＮＳクエリを収集する。
（Ｓ５０３）収集されたＤＮＳクエリに含まれる照会名Ｎｄ及び発信元ＩＰアドレスを抽出する。
【００９１】
（Ｓ５０４）このＤＮＳクエリの発生時刻を、抽出された照会名Ｎｄ及び発信元アドレスに対応付けて記録する。尚、この発生時刻は、ＤＮＳクエリから抽出された時刻情報とすることができる。
（Ｓ５０５）抽出された照会名Ｎｄが、新規であるか否かを判定する。
（Ｓ５０６ａ）抽出された照会名Ｎｄが新規である場合、この照会名Ｎｄを新たにクエリ周期テーブル１１３ｔにエントリする。
（Ｓ５０７ａ）次いで、この照会名Ｎｄに対応する値として（照会名Ｎｄ毎に）、クエリの発信元ＩＰアドレスの各々について、クエリ発生周期Ｔｑ及び周期安定度ＳＴを算出し、クエリ周期テーブル１１３ｔに記録する。
【００９２】
（Ｓ５０６ｂ）一方、抽出された照会名Ｎｄが新規ではない場合、既にエントリされている当該照会名Ｎｄを参照する。
（Ｓ５０７ｂ）次いで、この照会名Ｎｄに対応する値として（照会名Ｎｄ毎に）、クエリの発信元ＩＰアドレスの各々について、クエリ発生周期Ｔｑ及び周期安定度ＳＴを算出し、クエリ周期テーブル１１３ｔに記録されたこれらの値を更新する。
【００９３】
（Ｓ５０８）ＤＮＳクエリ情報収集ループを開始してから、設定された総観測時間Ｔｍｅが経過したか否かを判定し、経過していれば、本ループ（ＤＮＳクエリの収集・解析）を終了する。一方、経過していなければ、Ｓ５０１に戻って本ループを継続して行う。
【００９４】
（Ｓ５０９）照会名Ｎｄ毎に、この照会名Ｎｄを含むクエリの発信元ＩＰアドレスに対応して登録されておりこの照会名Ｎｄに対応したソフトウェア種別と、最終的に決定されたクエリ発生周期Ｔｑ及び周期安定度ＳＴとを記録した判定規則１１４ｔを生成する。
（Ｓ５１０）生成した判定規則１１４ｔを出力する。この際、判定規則１１４ｔを、端末情報推定装置６に送信してもよく、又はディスプレイ表示し、紙等の媒体として出力し、若しくはデータとして外部装置に出力することもできる。
【００９５】
尚、判定規則生成方法の本実施形態（ステップＳ５００〜Ｓ５１０）において、「ソフトウェア種別」に代えて「端末種別」を採用すれば、複数の端末２の端末種別に係る判定規則を生成することができる。この場合、判定規則は、照会名Ｎｄ及び端末種別毎に、最終的に決定されたクエリ発生周期Ｔｑ及び周期安定度ＳＴを記録したものとなる。
【００９６】
［クエリ発生周期Ｔｑ及び周期安定度ＳＴを用いた端末情報推定例］
図６は、本発明に係る判定規則１１４ｔを用いて端末情報を推定した一例を示すフローチャートである。本端末情報推定方法は、端末情報推定装置６（図１）において実施される。
【００９７】
（Ｓ６００）生成された判定規則１１４ｔを入力する。
（Ｓ６０１）判定規則１１４ｔにエントリされたソフトウェア種別、即ち、
ＯＳ種別｛ＯＳ１，ＯＳ２，・・・，ＯＳｉ，・・・，ＯＳｏｓ｝、及び
アプリケーション種別｛ＡＰ１，ＡＰ２，・・・，ＡＰｊ，・・・ＡＰａｐ｝
を予め登録する。次いで、ＯＳ種別ＯＳｉのカウント数ｎｏｓｉの初期値、及びアプリケーション種別ＡＰｊのカウント数ｎａｐｊの初期値をそれぞれゼロとする。
ｎｏｓｉ＝０（ｉ＝１，２，・・・，ｏｓ）、及び
ｎａｐｊ＝０（ｊ＝１，２，・・・，ｓｐ）
【００９８】
（Ｓ６０２）収集したＤＮＳクエリを解析しつつＤＮＳクエリ数をカウントするループを開始する。ここで、クエリ数のカウント時間をｔｃｏとする。
（Ｓ６０３）ＤＮＳサーバ３宛のパケットを収集する。
（Ｓ６０４）収集されたパケットが、登録されたＯＳ種別ＯＳｉ又はアプリケーション種別ＡＰｊに対応した照会名Ｎｄを含むＤＮＳクエリであるか否かを判定する。
【００９９】
（Ｓ６０５ａ）ステップＳ６０４において、収集したパケットが登録されたＯＳ種別ＯＳｉに対応した照会名Ｎｄを含むＤＮＳクエリであるとの判定がなされた際、ＯＳ種別ＯＳｉのカウント数ｎｏｓｉを１だけ増加させる。
（８）  ｎｏｓｉ＝ｎｏｓｉ＋１
（Ｓ６０５ｂ）ステップＳ６０４において、収集したパケットが登録されたアプリケーション種別ＡＰｊに対応した照会名Ｎｄを含むＤＮＳクエリであるとの判定がなされた際、アプリケーション種別ＡＰｊのカウント数ｎａｐｊを１だけ増加させる。
（９）  ｎａｐｊ＝ｎａｐｊ＋１
一方、ステップＳ６０４において、収集したパケットが、登録されたソフトウェア種別に対応した照会名Ｎｄを含むＤＮＳクエリではないとの判定がなされた際、ステップＳ６０６に移行する。
【０１００】
（Ｓ６０６）クエリ数カウントループを開始してから、設定されたカウント時間ｔｃｏが経過したか否かを判定し、経過していれば、本ループを終了する。一方、経過していなければ、Ｓ６０２に戻って、本ループ（ソフトウェア種別毎のＤＮＳクエリのカウントループ）を継続して行う。
【０１０１】
ここで、カウント時間ｔｃｏは、例えば数分〜数時間に設定される。これは、本発明に係る判定規則を利用することによって、短時間でのクエリのカウントによっても精度の高い端末情報（端末数）が得られることを意味している。
【０１０２】
（Ｓ６０７）ＯＳ種別毎のクエリ数
｛ｎｏｓ１，ｎｏｓ２，・・・，ｎｏｓｉ，・・・，ｎｏｓｏｓ｝、及び
アプリケーション種別毎のクエリ数
｛ｎａｐ１，ｎａｐ２，・・・，ｎａｐｊ，・・・，ｎａｐａｐ｝
を記録する。
（Ｓ６０８）各ソフトウェア種別（ＯＳｉ、ＡＰｊ）の総数を算出する総数推定ループに入る。
【０１０３】
（Ｓ６０９）各ソフトウェア種別（ＯＳｉ、ＡＰｊ）毎に、当該ソフトウェア種別の総数を、
（１０）  Ｎｏｓｉ＝ｎｏｓｉ×Ｔｑ（ＯＳｉ）／（６０×ｔｃｏ）
（１１）  Ｎａｐｊ＝ｎａｐｊ×Ｔｑ（ＡＰｊ）／（６０×ｔｃｏ）
として算出する。ここで、Ｔｑ（ＯＳｉ）（秒）及びＴｑ（ＡＰｊ）（秒）は、入力された判定規則１１４ｔから読み出された、それぞれＯＳｉ及びＡＰｊに対応するクエリ発生周期である。また、カウント時間ｔｃｏの単位は分である。
【０１０４】
例えば、Apple社のiOSでは、更新確認時間間隔（クエリ発生周期）Ｔｑ＝１２（時間）＝４３２００（秒）である。ここで、ｔｃｏ＝１０（分間）に、iOSの更新確認先であるiphone-ld.apple.comを照会先ＮｄとしたＤＮＳクエリのカウント数が、ｎ＝１００（回）であったとすると、iOSの総数（従ってiOSを搭載した端末の総数）Ｎは、
Ｎ＝１００×４３２００／（６０×１０）＝７２００
となる。即ち、プロバイダネットワーク４に接続された端末数は、７２００台であると推定される。
【０１０５】
さらに、図４の判定規則１１４ｔに示したように、１つのＯＳ種別ＯＳａ（図４ではｊＯＳ）に対応する照会名Ｎｄｋが複数（図４では、abc.xxxupdate.com、efg.clients.com、及びhij.klmno.comの３つ）存在する場合、周期安定度ＳＴを利用して、より高い精度で端末数を推定することができる。
【０１０６】
このＯＳ種別ＯＳａに対応する複数の照会名Ｎｄｋの各々に対応付けられたクエリ発生周期及び周期安定度を、それぞれＴｑｋ及びＳＴｋとする。この場合、ＯＳａの総数（従ってＯＳａを搭載した端末の総数）Ｎｏｓａを、次式
（１２−１）  Ｎｏｓａ＝Σ（Ｎ（ＯＳａ）ｋ×ＳＴｋ）／ΣＳＴｋ
（１２−２）  Ｎ（ＯＳａ）ｋ＝ｎｋ×Ｔｑｋ／（６０×ｔｃｏ）
を用いて算出することができる。ここで、ｎｋは、照会名Ｎｄｋを含むクエリのカウント数である。また、式（１２−１）の２つのΣはいずれも、ｋについての総和（図４のｊＯＳの場合、ｋ＝１，２，３の総和）である。
【０１０７】
例えば、図４のｊＯＳの場合、ｔｃｏ＝１０（分間）、abc.xxxupdate.comに係るカウント数ｎ１＝１６７２、efg.clients.comに係るカウント数ｎ２＝７、及びhij.klmno.comに係るカウント数ｎ３＝８として、
Ｎ（ｊＯＳ）１＝１６７２×３５０.７／（６０×１０）＝約９７７.２８
Ｎ（ｊＯＳ）２＝７×８６４０５.５／（６０×１０）＝約１００８.０６
Ｎ（ｊＯＳ）３＝８×８６３８９.２／（６０×１０）＝約１１５１.８６
であるから、周期安定度を考慮したより精度の高い総数Ｎｊｏｓは、
Ｎｊｏｓ＝（９７７.２８×０.４２＋１００８.０６×０.３１＋１１５１.８６×０.７５）／（０.４２＋０.３１＋０.７５）＝約１０７２
と算出される。
【０１０８】
（Ｓ６１０）識別された全てのソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｉ）について総数を推定するまで、総数推定ループを繰り返す。
【０１０９】
（Ｓ６１１）ＯＳ種別毎の総数
｛Ｎｏｓ１，Ｎｏｓ２，・・・，Ｎｏｓｉ，・・・，Ｎｏｓｏｓ｝、及び
アプリケーション種別毎の総数
｛Ｎａｐ１，Ｎａｐ２，・・・，Ｎａｐｊ，・・・，Ｎａｐａｐ｝
を蓄積する。
（Ｓ６１２）ステップＳ６１２で蓄積されたデータを表示又は出力する。
【０１１０】
尚、端末情報推定方法の本実施形態（ステップＳ６００〜Ｓ６１２）において、照会名Ｎｄ及び端末種別毎にクエリ発生周期Ｔｑ及び周期安定度ＳＴを記録した判定規則を使用し、「ソフトウェア種別（ＯＳ種別及びソフトウェア種別）」に代えて「端末種別」を採用すれば、複数の端末２の端末種別に係る端末情報（端末数）を推定することもできる。
【０１１１】
以上、本発明に係る判定規則を利用することによって、照会名及びソフトウェア種別毎に対応付けられたクエリ発生周期から、ネットワーク全体における当該ソフトウェア種別及びその総数（搭載した端末数）を算出することができる。また、照会名及びソフトウェア種別毎に対応付けられた周期安定度を用いて、算出された総数からより高い精度で総数（端末数）を推定することが可能となる。即ち、本発明によれば、ネットワーク全体におけるソフトウェア種別を含む端末情報を、短時間で高い精度をもって推定するのに使用される判定規則が生成可能となる。
【０１１２】
特に、発生頻度の高い文字列（照会名）をも含め、周期安定度を考慮して端末数を推定することができるので、より少ないクエリ観測数から（より短時間で）、精度の高い端末数を推定することができる。即ち、本発明によれば、移動端末の通信エリア間又は通信エリア内外への移動等の影響を受けにくい判定規則を生成することができる。
【０１１３】
さらに、以上に説明した本発明に係る判定規則を利用して推定される端末情報は、例えば、ネットワーク管理者にとって、ネットワークの安定した運用を維持するために非常に重要となる。即ち、これら端末情報の把握によって、通信障害の原因となる利用者の行為を未然に防止したり、トラフィックのオフロード状況を把握したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【０１１４】
しかしながら、ネットワーク内では、常に、新たなアプリケーションやＯＳが次々と利用され、各種ソフトウェアの利用者数も大きく変動する。このような状況でも、本発明によれば、適宜、現在の通信状況・利用状況に適合した判定規則を作成し、活用していくことができる。その結果、ネットワーク管理者は、より適切な精度の高い端末情報を入手することができ、より適切な対策を講じることができる。
【０１１５】
以上に述べた本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【符号の説明】
【０１１６】
１  判定規則生成装置
１００ａ  無線インタフェース
１００ｂ  有線インタフェース
１０１  通信インタフェース
１０２  入力部
１０３  出力部
１１０  クエリ収集部
１１１  クエリ情報取得部
１１１ｔ  クエリ情報テーブル
１１２  端末情報登録部
１１２ｔ  端末情報テーブル
１１３  発生周期算出部
１１３ｔ  クエリ周期テーブル
１１４  判定規則生成部
１１４ｔ  判定規則
２、７  端末
３  ＤＮＳサーバ
４  プロバイダネットワーク
５  インターネット
６  端末情報推定装置
【図１】
2014011695.tif 000003
【図２】
2014011695.tif 000004
【図３】
2014011695.tif 000005
【図４】
2014011695.tif 000006
【図５】
2014011695.tif 000007
【図６】
2014011695.tif 000008