特許第5872396号(P5872396)IP Force 特許公報掲載プロジェクト 2022.1.31 β版

ホーム > 特許ランキング > ＫＤＤＩ株式会社

このエントリーをはてなブックマークに追加

知財求人 - 知財ポータルサイト「IP Force」

▶ ＫＤＤＩ株式会社の特許一覧

特許5872396クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法
<>
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000002
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000003
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000004
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000005
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000006
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000007
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000008
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000009
  • 特許5872396-クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法 図000010
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】5872396
(24)【登録日】2016年1月22日
(45)【発行日】2016年3月1日
(54)【発明の名称】クエリ発生周期の安定度を利用した端末情報推定装置、ＤＮＳサーバ、プログラム及び方法
(51)【国際特許分類】
   G06F 13/00 20060101AFI20160216BHJP
【ＦＩ】
   G06F13/00 353B
【請求項の数】9
【全頁数】27
(21)【出願番号】特願2012-148077(P2012-148077)
(22)【出願日】2012年6月30日
(65)【公開番号】特開2014-10725(P2014-10725A)
(43)【公開日】2014年1月20日
【審査請求日】2015年1月9日
(73)【特許権者】
【識別番号】000208891
【氏名又は名称】ＫＤＤＩ株式会社
(74)【代理人】
【識別番号】100135068
【弁理士】
【氏名又は名称】早原 茂樹
(74)【代理人】
【識別番号】100141313
【弁理士】
【氏名又は名称】辰巳 富彦
(72)【発明者】
【氏名】山田 明
(72)【発明者】
【氏名】山下 公章
(72)【発明者】
【氏名】松中 隆志
(72)【発明者】
【氏名】窪田 歩
【審査官】 田上 隆一
(56)【参考文献】
【文献】 特開２０１１−０７６１８８（ＪＰ，Ａ）
(58)【調査した分野】（Int.Cl.，ＤＢ名）
Ｇ０６Ｆ １３／００
(57)【特許請求の範囲】
【請求項1】
ＤＮＳ（Domain Name System）サーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する端末情報推定装置であって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、前記判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
を有することを特徴とする端末情報推定装置。
【請求項2】
前記判定規則は、当該照会名毎に、当該照会名を含む当該クエリの発生する時間間隔の平均であるクエリ発生周期と、当該クエリの発生する当該時間間隔の分布における分散、尖度及び歪度から決定される周期安定度とを記録していることを特徴とする請求項１に記載の端末情報推定装置。
【請求項3】
前記ソフトウェア種別は、ＯＳ(Operating System)種別及び／又はアプリケーション種別であり、
前記照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の、又は処理実行に必要な情報要求時の接続先アドレスを含む
ことを特徴とする請求項１又は２に記載の端末情報推定装置。
【請求項4】
前記判定規則は、当該照会名毎に、当該照会名に対応する端末種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを更に記録したものであって、該判定規則において少なくとも１組の複数の照会名の各々に同一の端末種別が対応しており、
前記種別識別・計数手段は、さらに、収集された各クエリに含まれる照会名を抽出して、当該照会名に対応する端末種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントし、
前記総数推定手段は、さらに、前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該端末種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該端末種別の総数を推定する
ことを特徴とする請求項１から３のいずれか１項に記載の端末情報推定装置。
【請求項5】
前記ソフトウェア種別は、ＯＳ種別及びアプリケーション種別であり、
前記端末情報推定装置は、
１つの端末内で、当該端末に搭載可能なＯＳ種別と、当該端末に搭載されたＯＳ種別上で動作可能なアプリケーション種別とを含むソフトウェア種別の組合せを、共存可能な複数のソフトウェア種別の組合せとして登録する共存種別登録手段と、
前記クエリの発信元アドレス毎に、異なるソフトウェア種別を含む複数のクエリが受信された際に、前記共存種別登録手段を用いて該異なるソフトウェア種別が共存し得る関係にあるか否かを判定する共存種別判定手段と
を更に有しており、
前記種別識別・計数手段は、前記共存種別判定手段が真の判定を行った際、当該発信元アドレスを含んでおり当該ソフトウェア種別に対応するクエリをカウント対象とする
ことを特徴とする請求項１から４のいずれか１項に記載の端末情報推定装置。
【請求項6】
前記複数の端末の発信元アドレスにおける所定アドレス範囲毎に、ネットワーク種別を予め登録するネットワーク種別登録手段を更に有し、
前記種別識別・計数手段は、識別対象となるクエリについて、前記ネットワーク種別登録手段を用いて、当該クエリの発信元アドレスからネットワーク種別を更に識別する
ことを特徴とする請求項１から５のいずれか１項に記載の端末情報推定装置。
【請求項7】
照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する機能を搭載したＤＮＳサーバであって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、前記判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
を有することを特徴とするＤＮＳサーバ。
【請求項8】
ＤＮＳサーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定するようにコンピュータを機能させる端末情報推定プログラムであって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、前記判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
してコンピュータを機能させることを特徴とする端末情報推定プログラム。
【請求項9】
ＤＮＳサーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する端末情報推定方法であって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段を用い、
当該端末から発信された当該クエリを収集する第１のステップと、
収集された各クエリに含まれる照会名を抽出して、前記判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする第２のステップと、
前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する第３のステップと
を有することを特徴とする端末情報推定方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、複数の端末が接続されたネットワークの管理・監視の技術に関する。
【背景技術】
【0002】
ネットワーク管理者は、ネットワークの安定した運用を維持するため、ネットワーク利用者の利用環境及び利用状況を把握しなければならない。この把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【0003】
しかしながら、ネットワーク管理者が利用者の利用実態を十分に把握することは一般に困難である。例えば、インターネット接続業者（ＩＳＰ：Internet Service Provider）とそのユーザとのように、管理者と利用者とが異なる組織に属している場合、管理者が利用者の利用状況を監視することは難しい。特に、利用者が各々の好みにあった端末を選定して、任意のアプリケーションを自らインストールする場合、管理者は、このような利用者の状況を把握しづらい。
【0004】
一方、企業内ネットワークのように、利用者のネットワーク利用が厳しく規定されている場合でも、利用者が、許可されていない端末を接続して規定外の利用を行う事態を許してしまう事例が存在する。また、例えば企業内のネットワークが国内外に及ぶ場合、利用状況を物理的に監視して直接把握することは極めて難しい。
【0005】
このような状況下で、現在、利用者による通信のみを監視し、通信そのものから利用者の利用環境及び利用状況を把握する技術が検討されている。
【0006】
例えば、非特許文献１には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）における、オペレーティングシステム（ＯＳ: Operating System）に固有の振る舞いを監視することによって、利用者の各端末に搭載されたＯＳ種別を識別する方法が開示されている。ここで、監視は受動的に（自らパケットを送信せずに）実施される。
【0007】
さらに、非特許文献２には、同じくＴＣＰ／ＩＰにおけるＯＳ固有の振る舞いを利用するが、受動的監視のみならず能動的な（自らパケットを送信する）検査を実施することによって、より精度の高いＯＳ種別の判別を図った識別方法が開示されている。
【0008】
また、非特許文献３には、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダに含まれる、ＯＳ又はアプリケーションに固有の文字列を抽出し組み合わせて、利用者端末に搭載されたウェブブラウザ（Web Browser）種別を識別する技術が開示されている。
【0009】
さらに、非特許文献４には、ＤＮＳ（Domain Name System）クエリのパターンを分析し、クエリパターンの時間差とパターン出現数との関係から、ＯＳ種別及びウェブブラウザ種別を識別する方法が開示されている。ここで、本方法は、ＩＰｖ４（Internet Protocol version 4）とＩＰｖ６（Internet Protocol version 6）とが混在している通信環境を前提としている。
【先行技術文献】
【非特許文献】
【0010】
【非特許文献1】Passive OS Fingerprinting (p0f)、「the new p0f:2.0.8 (2006-09-06)」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://lcamtuf.coredump.cx/p0f.shtml＞
【非特許文献2】Nmap Fingerprint、「Understanding an NmapFingerprint」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://nmap.org/book/osdetect-fingerprint-format.html＞
【非特許文献3】Peter Eckersley、ELECTRONIC FRONTIERFOUNDATION 「How Unique Is Your Web Browser?」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://panopticlick.eff.org/browser-uniqueness.pdf＞
【非特許文献4】川口敬、早稲田大学理工学部コンピュータ・ネットワーク工学科後藤研究室B4 1G06R055-7 卒業論文発表、「ＤＮＳクエリーパターンを用いたＯＳの推定」、［online］、［平成２４年１月１９日検索］、インターネット＜URL: http://www.goto.info.waseda.ac.jp/forB4/pdf-th/2009/0201_kawaguchi.pdf＞
【発明の概要】
【発明が解決しようとする課題】
【0011】
しかしながら、上述したような従来技術を用いても、ＩＳＰレベルの大規模なネットワーク全体における、端末種別や端末に搭載されたソフトウェア種別（ＯＳ種別及びアプリケーション種別）といった端末情報を推定することは、非常に困難である。
【0012】
例えば、非特許文献１及び３の技術では、基本的にネットワーク上の通信を全て取得する必要がある。その結果、これらの技術を広帯域である基幹回線に適用する場合、導入コストが莫大となり実現性が低下する。一方、大規模ネットワークの末端部に適用する場合、末端部での監視箇所の数が膨大となってしまう。
【0013】
また、非特許文献１及び２の技術では、ＴＣＰ／ＩＰの特徴を利用するので、ＯＳ種別を識別することしかできず、ＯＳ上で発動するアプリケーション種別までは識別できない。一方、非特許文献３の技術では、ＨＴＴＰヘッダの特徴を利用するので、アプリケーションのうちウェブブラウザ種別を識別することしかできない。
【0014】
さらに、非特許文献４の技術では、ＩＰｖ４とＩＰｖ６とが混在している通信環境であることが前提となるため、ＩＰｖ４又はＩＰｖ６単独の環境では、ＯＳ種別を識別することができない。従って、ＩＰｖ６への全面移行の際には、当該技術は適用不可能となる。
【0015】
また、特に、非特許技術２の技術では、管理者が自らパケットを送信するといった能動的な検査を実施する必要がある。その結果、自身の管理下にはないネットワークの利用者に検査用のパケットを送信しようとしても、受け入れられない可能性が高い。さらに、利用者側のネットワークにファイアウォール（Firewall）、又はＮＡＴ（Network Address Translation）等のフィルタリング機構が設けられている場合、非特許技術２の技術は、適用不可能である。
【0016】
また、端末が携帯電話等のモバイル機器の場合、端末が数分間乃至数時間のオーダで別の通信エリアに移動してしまう可能性が生じる。このため、上述したような従来技術では、実際の端末情報を適宜取得することが更に困難となってしまう。従って、端末種別、ソフトウェア種別、並びにこれらに対応する端末の総数といった端末情報を推定するためには、通信ネットワーク上でのパケット監視・解析を、適切な判定基準に基づいて、できるだけ短時間で行う必要がある。
【0017】
そこで、本発明は、ネットワーク全体におけるソフトウェア種別毎の総数を含む端末情報を、受動的に、短時間で高い精度をもって推定することができる端末情報推定装置、サーバ、プログラム及び方法を提供することを目的とする。
【課題を解決するための手段】
【0018】
本発明によれば、ＤＮＳサーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する端末情報推定装置であって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
上記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
を有する端末情報推定装置が提供される。
【0019】
この本発明の端末情報推定装置として、照会名毎に、当該照会名を含む当該クエリの発生する時間間隔の平均であるクエリ発生周期と、少なくとも当該クエリの発生する当該時間間隔の分布における分散から決定される周期安定度とを記録していることも好ましい。
【0020】
また、本発明の端末情報推定装置として、ソフトウェア種別は、ＯＳ種別及び／又はアプリケーション種別であり、照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の、又は処理実行に必要な情報要求時の接続先アドレスを含むことも好ましい。
【0021】
さらに、本発明の端末情報推定装置における一実施形態として、判定規則は、当該照会名毎に、当該照会名に対応する端末種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを更に記録したものであって、この判定規則において少なくとも１組の複数の照会名の各々に同一の端末種別が対応しており、
種別識別・計数手段は、さらに、収集された各クエリに含まれる照会名を抽出して、当該照会名に対応する端末種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントし、
総数推定手段は、さらに、前記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該端末種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該端末種別の総数を推定することも好ましい。
【0022】
また、本発明の端末情報推定装置における他の実施形態として、ソフトウェア種別は、ＯＳ種別及びアプリケーション種別であり、
本端末情報推定装置は、
１つの端末内で、当該端末に搭載可能なＯＳ種別と、当該端末に搭載されたＯＳ種別上で動作可能なアプリケーション種別とを含むソフトウェア種別の組合せを、共存可能な複数のソフトウェア種別の組合せとして登録する共存種別登録手段と、
クエリの発信元アドレス毎に、異なるソフトウェア種別を含む複数のクエリが受信された際に、共存種別登録手段を用いてこれら異なるソフトウェア種別が共存し得る関係にあるか否かを判定する共存種別判定手段と
を更に有しており、
種別識別・計数手段は、共存種別判定手段が真の判定を行った際、当該発信元アドレスを含んでおり当該ソフトウェア種別に対応するクエリをカウント対象とすることも好ましい。
【0023】
さらに、本発明の端末情報推定装置における他の実施形態として、複数の端末の発信元アドレスにおける所定アドレス範囲毎に、ネットワーク種別を予め登録するネットワーク種別登録手段を更に有し、
種別識別・計数手段は、識別対象となるクエリについて、ネットワーク種別登録手段を用いて、当該クエリの発信元アドレスからネットワーク種別を更に識別することも好ましい。
【0024】
本発明によれば、さらに、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する機能を搭載したＤＮＳサーバであって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
上記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
を有するＤＮＳサーバが提供される。
【0025】
本発明によれば、さらにまた、ＤＮＳサーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定するようにコンピュータを機能させる端末情報推定プログラムであって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、少なくとも当該クエリの発生する時間間隔の分布における分散から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段と、
当該端末から発信された当該クエリを収集するクエリ収集手段と、
収集された各クエリに含まれる照会名を抽出して、判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする種別識別・計数手段と、
上記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する総数推定手段と
してコンピュータを機能させる端末情報推定プログラムが提供される。
【0026】
本発明によれば、さらに、ＤＮＳサーバに、ネットワークを介し、照会名を含むクエリであって、搭載されたソフトウェアで使用される名前を解決するためのクエリを発信する複数の端末における端末情報を推定する端末情報推定方法であって、
当該照会名毎に、当該照会名に対応するソフトウェア種別と、当該クエリの発生する時間間隔であるクエリ発生周期と、当該クエリの発生する当該時間間隔の分布における分散、尖度及び歪度から決定される周期安定度とを記録した判定規則であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した判定規則を登録する判定規則登録手段を用い、
当該端末から発信された当該クエリを収集する第１のステップと、
収集された各クエリに含まれる照会名を抽出して、判定規則登録手段を用いて当該照会名に対応するソフトウェア種別を識別し、当該照会名毎に、所定時間内に収集された当該照会名を含むクエリの数をカウントする第２のステップと、
上記１組に含まれる複数の照会名の各々について、対応するクエリ発生周期とカウントされたクエリ数とから対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、当該複数の照会名の各々に対応する周期安定度をもって加重平均して当該ソフトウェア種別の総数を推定する第３のステップと
を有する端末情報推定方法が提供される。
【発明の効果】
【0027】
本発明の端末情報推定装置、ＤＮＳサーバ、プログラム及び方法によれば、ネットワーク全体におけるソフトウェア種別（ＯＳ種別及び／又はアプリケーション種別）毎の総数を含む端末情報を、受動的に、短時間で高い精度をもって推定することができる。
【図面の簡単な説明】
【0028】
【図1】本発明による端末情報推定装置が接続されるネットワークの構成図である。
【図2】判定規則の一実施形態を示す構成図である。
【図3】本発明による端末情報推定装置の一実施形態を示す機能構成図である。
【図4】端末情報推定に使用する各種テーブルの一実施形態を示す構成図である。
【図5】本発明によるＤＮＳサーバの一実施形態を示す機能構成図である。
【図6】本発明の端末情報推定方法のうち、端末種別及び端末に搭載されたソフトウェア種別の識別・計数方法の一実施形態を示すフローチャートである。
【図7】本発明の端末情報推定方法のうち、端末種別及び端末に搭載されたソフトウェア種別の総数を推定する方法の一実施形態を示すフローチャートである。
【図8】種別分布テーブルの一実施形態を示す構成図である。
【図9】本発明による判定規則生成方法の一例を示すフローチャートである。
【発明を実施するための形態】
【0029】
以下では、本発明の実施形態について、図面を用いて詳細に説明する。
【0030】
［端末情報推定装置が接続されるネットワーク］
図１は、本発明による端末情報推定装置が接続されるネットワークの構成図である。
【0031】
図１によれば、端末情報推定装置１は、多数の端末２に搭載されたソフトウェア種別（ＯＳ種別、アプリケーション種別）及びこれら端末２の端末種別（端末メーカー、型番）といった端末情報を識別し、各種別の総数を推定する装置である。端末情報推定装置１は、後に説明する判定規則生成装置８によって生成された「判定規則」を受信又は取得し、この端末情報の推定に利用する。
【0032】
ここで、端末２は、スマートフォン、タブレット型コンピュータ、又はパーソナルコンピュータ等の情報機器であり、アクセスネットワーク３０〜３２を含むプロバイダネットワーク３を介してインターネット７に接続される。
【0033】
また、アクセスネットワーク３０〜３２はそれぞれ、例えば、固定系ネットワーク、Ｗｉ−Ｆｉ（登録商標）等の無線ＬＡＮ、及び３Ｇ（3rd Generation）である。このうち、固定系ネットワークとして、光ファイバ網、及びＡＤＳＬ（Asymmetric Digital Subscriber Line）等を採用することができる。さらに、アクセスネットワークとして、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、及びＬＴＥ(Long Term Evolution)等の他の無線系ネットワークを採用することも可能である。また、プロバイダネットワーク３は、例えばＩＭＳ（IP Multimedia Subsystem）４によって、これらアクセスネットワーク３０〜３２を介した通信を制御する事業者ネットワークである。
【0034】
ＤＮＳサーバ５は、プロバイダネットワーク３に接続された端末２からの名前解決要求を受け付ける。具体的に、各端末２は、ＯＳ及びアプリケーション等のソフトウェアで使用されている名前を解決する必要がある場合に、ＤＮＳクエリ（query）をＤＮＳサーバ５に送信する。ＤＮＳサーバ５は、ＤＮＳクエリを受け取ると、他のＤＮＳサーバと通信して又は自ら名前を解決して、応答（リソースレコード）をクエリ発信元の端末２に送信する。
【0035】
ここで、各端末２に搭載されたＯＳ、及びウェブブラウザ等の多くのアプリケーションは、通常、インターネット７を通して自らの更新を行う。このため、そのソフトウェア種別固有のドメイン名のサイトに定期的に接続を試みる。従って、各端末２は、そのソフトウェア種別固有の時間間隔をもって、この固有のドメイン名を照会名として含むＤＮＳクエリを、ＤＮＳサーバ５宛てに送信する。
【0036】
例えば、ＯＳ種別毎の更新確認時の照会名は、以下の通りである。
《ＯＳ種別ＯＳｒ》 《照会名Ｎｄ》
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では、１２時間となる。
【0037】
また、アプリケーション種別の例として、代表的なウェブブラウザ毎の更新確認時の照会名は、例えば、以下の通りである。
《ウェブブラウザ》 《照会名Ｎｄ》
Mozilla Firefox（Mozilla Foundation） www.mozilla.com
Chrome（Google社） www.google.com
Opera（Opera Software社） autoupdate.opera.com
アプリケーション更新確認の時間間隔は、アプリケーション種別にもよるが、例えばアップル（Apple）社の「iCloud」では、１.５時間となる。
【0038】
さらに、各端末２に搭載されたソフトウェアに関連するＤＮＳクエリの発信は、上述したようなソフトウェア更新確認時のみならず、ソフトウェア処理の実行に必要な情報要求時にも実施される。例えば、時刻合わせのための時刻情報の要求時、電子メールでのメールボックスの確認時、各種ソーシャルネットワーク・サービスにおける他者情報のチェック時等にも、ＤＮＳクエリが発信される。即ち、多くのソフトウェアでは、ＤＮＳサーバ３を利用して名前を解決してから通信を開始することが１つのパターンとなっている。
【0039】
この際の照会名（接続先のドメイン名）には、ソフトウェア種別（ＯＳ種別、アプリケーション種別）、更には端末種別（端末メーカー、型番）に固有のものが多く存在する。さらに、例えば、１つのＯＳ種別（例えば、Google社の提供するAndroidＯＳ）であっても、異なる端末メーカーに搭載される場合が多く存在する。また、端末２に搭載された多くのソフトウェア種別は、立ち上げ毎に端末メーカーのサイトへアクセスする。ここで、同じ端末メーカーの端末でも型番によって、アクセスするサイトが異なる場合も生じる。従って、各端末２は、ソフトウェア種別に固有の照会先だけでなく、端末種別に固有の照会先をもって、ＤＮＳクエリをＤＮＳサーバ３宛に送信する場合が多く存在する。
【0040】
同じく図１において、判定規則生成装置８は、端末情報を推定するのに利用される「判定規則」を生成し、端末情報推定装置１に送信する。判定規則生成装置８は、例えば、自身に接続された複数の端末９による、いずれかのアクセスネットワーク（図１ではアクセスネットワーク３２）を介した通信を仲介する位置に設置される。次いで、後に（図９を用いて）説明するように、これら複数の端末９から発信されるＤＮＳクエリを解析して「判定規則」を生成する。この際、判定規則生成装置８は、接続された複数の端末９に係る情報（付与されたＩＰ（Internet Protocol）アドレス、端末種別、搭載されたＯＳ種別及びアプリケーション種別等）を予め登録し、「判定規則」の生成に利用する。
【0041】
このような「判定規則」を生成するために、端末９は、例えば搭載された１つのＯＳ種別及びアプリケーション種別につき１０〜１００台程度、判定規則生成装置８に接続されることも好ましい。当然に更に多くの端末９を接続することによって、より精度の高い「判定規則」を生成することも可能となる。また、信頼性の高い「判定規則」を得るために、端末９は、ＤＮＳクエリが収集される判定規則生成期間中、常時、接続が確立した状態に置かれることも好ましい。
【0042】
判定規則生成装置８は、例えば２４時間〜数ヶ月間連続して、端末９から発信されたＤＮＳクエリの収集を行って「判定規則」を生成する。その際、判定規則生成装置８は、ＤＮＳクエリの発信元ＩＰアドレス（端末９に付与されたＩＰアドレス）に対応付けて登録されたソフトウェア種別（ＯＳ種別又はアプリケーション種別）をこのＤＮＳクエリの照会名に対応付けた上で、照会名毎に、「クエリ発生周期」と、「周期安定度」とを逐次算出し更新する。
【0043】
ここで、本願発明者等は、多くのソフトウェア種別（ＯＳ種別、アプリケーション種別）において、ソフトウェア更新確認のためのＤＮＳクエリに限らず、種々のＤＮＳクエリの発信タイミングが、ソフトウェア種別固有の「クエリ発生周期」を有し得ることを見出した。
【0044】
この「クエリ発生周期」は、対象となっているＤＮＳクエリの発生時間間隔の平均値である。ＤＮＳクエリは、定期的なＯＳ更新確認等、対応するソフトウェア種別（照会名）固有の時間間隔（周期）をもって発信される場合が多く、ソフトウェア種別（照会名）毎に「クエリ発生周期」が決定可能である。
【0045】
但し、実際の名前解決の際には、前回のＤＮＳクエリに対する応答としてキャッシュされたリソースレコードのＴＴＬ（Time To Live）に応じて所定の時間が指定され、この時間内にはクエリは発信されない（このリソースレコードで回答されたドメイン名が再利用される）。このような事情等があって、クエリ発生の時間間隔（周期）には変動が生じる。「周期安定度」は、この変動の少なさに相当し、後述するように、少なくとも「クエリ発生周期」の分布における分散から決定される。
【0046】
判定規則生成装置８は、以上のようにして最終的に、照会名毎に、ソフトウェア種別を対応付けた上で、「クエリ発生周期」及び「周期安定度」を記載した「判定規則」を生成する。この判定規則生成装置８は、例えば、企業内ネットワークのルータの位置に設置可能である。さらに、判定規則生成装置８は、実際に運用されるネットワークから独立した実験系ネットワークと複数の端末９とを仲介するものであってもよい。いずれにしても、判定規則生成装置８は、複数の端末９全ての端末情報を管理・登録可能な環境に設置される。
【0047】
一方、同じく図１に示すように、端末情報推定装置１は、プロバイダネットワーク３内におけるＤＮＳサーバ５への回線に設けられたネットワークタップ（又はミラーリングハブ）６を介してネットワークに接続される。端末情報推定装置１は、通信インタフェース１００と、クエリ収集部１１０と、種別識別・計数部１１１と、総数推定部１１７と、種別分布蓄積部１１８と、出力部１０１とを有している。
【0048】
具体的に、端末情報推定装置１は、
（ａ）照会名毎に、後に説明する「クエリ発生周期」と「周期安定度」とを記録した「判定規則」であって、少なくとも１組の複数の照会名の各々に同一のソフトウェア種別が対応した「判定規則」である判定規則１１２ｔを登録し、
（ｂ）クエリ収集部１１０によって、端末２から発信されたＤＮＳクエリを、通信インタフェース１００を介して収集し、
（ｃ）種別識別・計数部１１１によって、収集された各ＤＮＳクエリに含まれる照会名を抽出して、判定規則１１２ｔを用いて当該照会名に対応するソフトウェア種別を識別し、照会名毎に、所定時間内に収集された当該照会名を含むＤＮＳクエリの数をカウントし、
（ｄ）総数推定部１１７によって、上述した１組に含まれる複数の照会名の各々について、対応する「クエリ発生周期」とカウントされたクエリ数とから、対応する当該ソフトウェア種別の仮総数を算出し、算出された複数の当該仮総数を、照会名の組における各照会名に対応する「周期安定度」をもって加重平均することによって、より高い精度で当該ソフトウェア種別の総数を推定する。
【0049】
尚、端末情報推定装置１は、アクセスネットワーク３０〜３２のゲートウェイ位置に設置されることも可能である。この場合、設置されたアクセスネットワーク内の端末種別及びソフトウェア種別、並びにこれら種別毎の総数を推定することになる。
【0050】
［判定規則］
図２は、判定規則の一実施形態を示す構成図である。
【0051】
図２によれば、判定規則１１２ｔでは、照会名Ｎｄ毎に、ソフトウェア種別（ＯＳ種別及びアプリケーション種別）ＳＷｊ、クエリタイプｔｑ、クエリ発生周期Ｔｑ、及び周期安定度ＳＴが記録されている。また、照会名Ｎｄ毎に、端末種別ＴＭｉ、クエリタイプｔｑ、クエリ発生周期Ｔｑ、及び周期安定度ＳＴが記録されている。
【0052】
ここで、クエリ発生周期Ｔｑは、判定規則生成装置８において、端末９から受信したＤＮＳクエリのうち、対象とする照会名Ｎｄを有するクエリの数をカウントする際に測定される、当該クエリ発生の時間間隔の平均値（後述する式（１０））である。また、周期安定度ＳＴは、これらクエリ発生の時間間隔の分布における分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑの所定の平均値から求められる量（後述する式（１４ａ）及び（１４ｂ））であり、クエリ発生の時間間隔（周期）に生じる変動の少なさに相当する。
【0053】
この判定規則１１２ｔにおいて、ＯＳ種別の１つであるｊＯＳは、３つの照会名Ｎｄ（abc.xxxupdate.com、efg.clients.com、及びhij.klmno.com）からなる組の各照会名Ｎｄに対応している。従って、ｊＯＳを搭載した端末２からは、これら３つの照会名Ｎｄをそれぞれ含む３種のＤＮＳクエリが、それぞれのクエリ発生周期Ｔｑ及び周期安定度ＳＴをもって発生する。このように、判定規則１１２ｔでは、少なくとも１組の複数の照会名Ｎｄの各々に、同一のソフトウェア種別ＳＷｊが対応して記録されている。
【0054】
ここで、後に（図７のステップＳ７０１及びＳ７０２を用いて）詳述するように、いずれの照会名Ｎｄに対応するデータ（クエリ発生周期Ｔｑ）を用いても、ｊＯＳを搭載した端末数（仮総数）を算出することができる。しかしながら、本発明による周期安定度ＳＴを用いることによって、算出された３つの端末数から、より精度の高い端末数を推定することができるのである。
【0055】
このような理由から、判定規則１１２ｔにおいては、少なくとも１組の複数の照会名Ｎｄに同一のソフトウェア種別が対応している。さらに、照会名Ｎｄのいずれもが複数の照会名Ｎｄからなる組をなしていてこれらの組の各々に同一のソフトウェア種別が対応していることが好ましい。即ち、１つのソフトウェア種別が必ず複数の照会名Ｎｄに対応した形で記録されていて、それぞれの照会名Ｎｄ毎に独立したクエリ発生周期Ｔｑ及び周期安定度ＳＴが規定されていることが好ましい。
【0056】
尚、最近の傾向では、移動端末に搭載されたＯＳにおいて、ポーリング系のアプリケーションを採用するケースが増加している。このため、１つのソフトウェア種別に対して複数個の照会名を規定し易くなっている。
【0057】
また、判定規則１１２ｔには、照会名Ｎｄ毎にクエリ発生周期Ｔｑ及び周期安定度ＳＴが規定されるので、周期性の信頼度が高い（周期のばらつきが小さい）照会名Ｎｄを、見出し、確認し、更には選別することも可能となる。例えば、周期安定度ＳＴが所定値以下（例えば０.２以下）である照会名Ｎｄは、端末情報の算出・推定に使用しないとすることも可能である。実際、端末情報の推定においては、精度の高い端末情報（端末数）を得るために、どの照会名Ｎｄを（どの程度）採用するが非常に重要となる。この点、周期安定度ＳＴは、その判断のための強力な指標となる。
【0058】
尚、照会名Ｎｄによっては、この照会名Ｎｄがある特定のソフトウェア種別に固有の文字列である、と見なすことはできず、この照会名Ｎｄに複数のソフトウェア種別が対応する場合も存在する。例えば、図２に示した判定規則１１２ｔによれば、照会名Ｎｄ：klm.bqq.comに対して２つのＯＳ種別：ＮｂｄＯＳ及びＯＳｙｙが対応している。この場合、照会名Ｎｄ：klm.bqq.comを含むクエリ数をカウントしても、本来そのカウント数が、ＮｂｄＯＳに係る端末数なのか又はＯＳｙｙに係る端末数なのかを判定することはできない。
【0059】
しかしながら、ＮｂｄＯＳの場合のクエリ発生周期が５３８.７秒であるのに対し、ＯＳｙｙの場合のクエリ発生周期は１７１８５０.１秒であり桁違いに長くなっている。その結果、ＮｂｄＯＳを搭載した端末２の台数とＯＳｙｙを搭載した端末２の台数との比が所定範囲内であるとの見込みの下、照会名Ｎｄ：klm.bqq.comを含むクエリのカウント数を、概ねＮｂｄＯＳに係る端末数に対応すると近似することが可能となる。これにより、特定のソフトウェア種別に固有の文字列とはなっていない照会名Ｎｄをも、総数（端末数）の推定に有効利用することができる場合が存在する。
【0060】
［端末情報推定装置］
図３は、本発明による端末情報推定装置１の一実施形態を示す機能構成図である。また、図４は、端末情報推定に使用する各種テーブルの一実施形態を示す構成図である。
【0061】
図３に示すように、端末情報推定装置１は、通信インタフェース１００と、出力部１０１と、クエリ収集部１１０と、種別識別・計数部１１１と、判定規則登録部１１２と、共存種別登録部１１３と、ＴＴＬ範囲登録部１１４と、ネットワーク（ＮＷ）種別登録部１１５と、共存種別判定部１１６と、総数推定部１１７と、種別分布蓄積部１１８とを有する。端末情報推定装置１は、例えばパーソナルコンピュータやサーバのようなものであって、この装置１に搭載されたコンピュータを機能させるプログラムを実行することによって、端末情報の推定に係る機能が実現される。
【0062】
通信インタフェース１００は、ＤＮＳサーバ５宛のパケットを全て受け取る入力部の役割を果たす。また、この通信インタフェース１００を介して、判定規則生成装置８によって生成された判定規則（１１２ｔ）が受信される。
【0063】
クエリ収集部１１０は、通信インタフェース１００を介して入力したパケットのうち、ＤＮＳサーバ５宛のＤＮＳクエリを識別して収集し、蓄積する。
【0064】
種別識別・計数部１１１は、収集された各ＤＮＳクエリに含まれる照会名Ｎｄを抽出し、通信インタフェース１００を介して入力した判定規則１１２ｔ（図２）を予め登録した照会名登録部１１２を用いて、この照会名Ｎｄに対応するソフトウェア種別ＳＷｊを識別する。さらに、照会名Ｎｄ毎に、所定時間内に収集されたこの照会名Ｎｄを含むクエリの数をカウントする。尚、種別識別・計数部１１１は、収集された各ＤＮＳクエリからクエリタイプも抽出し、クエリタイプが（ホストアドレスを要求するＤＮＳクエリであることを示す）タイプＡである場合にのみ、クエリ数のカウントを行うことも好ましい。
【0065】
種別識別・計数部１１１は、照会名抽出部１１１ｑと、端末種別識別部１１１ｍと、ＳＷ種別識別部１１１ｓと、クエリカウント部１１１ｃと、ＩＰアドレス抽出部１１１ｄと、ネットワーク（ＮＷ）種別識別部１１１ｎとを有する。
【0066】
照会名抽出部１１１ｑは、収集された各ＤＮＳクエリに含まれる照会名Ｎｄを抽出する。端末種別識別部１１１ｍは、判定規則登録部１１２を用いて、抽出された照会名Ｎｄに対応した端末種別ＴＭｉを識別する。ＳＷ種別識別部１１１ｓは、判定規則登録部１１２を用いて、抽出された照会名Ｎｄに対応したソフトウェア種別ＳＷｊを識別する。クエリカウント部１１１ｃは、照会名Ｎｄ毎に、所定のカウント時間ｔｃｏ内に収集された、この照会名Ｎｄを含むＤＮＳクエリの数をカウントする。
【0067】
ＩＰアドレス抽出部１１１ｄは、識別対象となるＤＮＳクエリに含まれる発信元ＩＰアドレスを抽出する。また、ＮＷ種別識別部１１１ｎは、ネットワークテーブル１１５ｔ（図４（Ｃ））を登録したネットワーク種別登録部１１５を用いて、このＤＮＳクエリの発信元ＩＰアドレスからネットワーク種別ＮＷｋを識別する。
【0068】
共存種別登録部１１３は、共存可能テーブル１１３ｔ（図４（Ａ））を予め登録する。この共存可能テーブル１１３ｔを利用することによって、ＤＮＳクエリの発信元ＩＰアドレス毎に、異なるソフトウェア種別を含む複数のＤＮＳクエリが受信された際に、これら異なるソフトウェア種別が共存し得る関係にあるか否かが判定可能となる。
【0069】
ＴＴＬ範囲登録部１１４は、ＴＴＬテーブル１１４ｔ（図４（Ｂ））を予め登録する。このＴＴＬテーブル１１４ｔを利用することによって、ＤＮＳクエリに含まれるＩＰヘッダのＴＴＬの値が、識別されたソフトウェア種別ＳＷｊに対応する測定値可能範囲に含まれる場合にのみ、ソフトウェア種別を識別したものとすることができる。
【0070】
ＮＷ種別登録部１１５は、ネットワークテーブル１１５ｔを予め登録する。このネットワークテーブル１１５ｔを利用することによって、このＤＮＳクエリの発信元ＩＰアドレスから、ネットワーク種別及びその数を更に識別・算出することが可能となる。
【0071】
図４（Ａ）〜（Ｃ）に、これら共存可能テーブル１１３ｔ、ＴＴＬテーブル１１４ｔ及びネットワークテーブル１１５ｔを示す。
【0072】
図４（Ａ）によれば、共存可能テーブル１１３ｔには、１つの端末２内で共存可能な複数のソフトウェア種別の組合せが登録されている。具体的には、識別され得るソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ及びアプリケーション種別ＡＰｓ）毎に、１つの端末２内で共存可能な複数のソフトウェア種別が登録されている。
【0073】
例えば、あるアプリケーション種別は、特定のＯＳ種別上でのみ動作する。この場合、このアプリケーション種別に対応するテーブル欄に、このＯＳ種別が登録され、また、このアプリケーション種別は、他のＯＳ種別に対応するテーブル欄から除外される。さらに、１つの端末２内で互いに共存できないアプリケーション種別も存在する。この場合、この一方のアプリケーション種別は、他方のアプリケーション種別に対応するテーブル欄から除外される。
【0074】
さらに、共存可能テーブル１１３ｔには、識別され得るソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ及びアプリケーション種別ＡＰｓ）毎に、そのソフトウェア種別ＳＷｊを搭載可能な端末種別ＴＭｉが登録されている。
【0075】
図４（Ｂ）によれば、ＴＴＬテーブル１１４ｔには、識別され得るＯＳ種別ＯＳｒ毎に、ＴＴＬの測定値可能範囲ＴＲｒが予め登録されている。ここで、ＴＴＬは、パケットの有効期間を表すための数値であり、ＩＰヘッダ内に格納されている。
【0076】
ＴＴＬの初期値は、ＯＳに固有の値となっている。例えば、
Microsoft社のWindows OS：ＴＴＬの初期値＝１２８
LinuxのKernel 2.6：ＴＴＬの初期値＝６４
であり、互いに異なっている。
【0077】
このＴＴＬは、ルータを通過する毎に値が１だけ減少する。従って、パケットを収集してＴＴＬを測定した場合、初期値よりも小さな測定値が得られるが、この測定値の範囲を予測することができる。この範囲が、測定値可能範囲ＴＲｒとなる。
【0078】
図４（Ｃ）によれば、ネットワークテーブル１１５ｔには、発信元ＩＰアドレスにおけるネットワークアドレスレンジ、即ち、ＩＰアドレス及びネットマスク毎に、ネットワーク種別ＮＷｋと、ＡＳ番号（Autonomous System Number）と、国名と、サービス名と、回線種別とが予め登録されている。
【0079】
一般に、ネットワーク種別ＮＷｋは、それぞれに固有のネットワークアドレスレンジを有する。例えば、ＤＮＳクエリの発信元ＩＰアドレスが１９２.１６８.２４８.３５である場合、図４（Ｃ）のネットワークテーブル１１５ｔによれば、このクエリが「Ａ社内の固定回線」を介して送信されたものである、と識別される。
【0080】
図３に戻って、共存種別判定部１１６は、ＤＮＳクエリの発信元ＩＰアドレス毎に、異なるソフトウェア種別を含む複数のＤＮＳクエリが受信された際に、これら異なるソフトウェア種別が共存し得る関係にあるか否かを判定する。ここで、共存種別判定部１１６は、この判定を行うため、共存可能テーブル１１３ｔを登録した共存種別登録部１１３を用いる。さらに、共存種別判定部１１６は、発信元ＩＰアドレス毎に、識別されたソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ又はアプリケーション種別ＡＰｓ）を記憶するソフトウェア（ＳＷ）種別記録部１１６ｓを有している。
【0081】
総数推定部１１７は、端末２の端末種別ＴＭｉ及び端末２に搭載されたソフトウェア種別ＳＷｊ毎の総数を推定する。具体的には、仮総数算出部１１７ｃと、総数推定部１１７ａと、ネットワーク（ＮＷ）推定部１１７ｎとを有する。
【0082】
仮総数算出部１１７ｃは、照会名Ｎｄ毎に、対応するクエリ発生周期Ｔｑとカウントされたクエリ数とから当該端末種別ＴＭｉ及びソフトウェア種別ＳＷｊの仮総数を算出する。ここで、判定規則１１２ｔにおいて、複数の照会名Ｎｄからなる１つの組に、同一のソフトウェア種別ＳＷｊ（端末種別ＴＭｉ）が対応して記録されている場合、この組の照会名Ｎｄ毎に、ソフトウェア種別ＳＷｊ（端末種別ＴＭｉ）の仮総数が算出されることになる。
【0083】
総数推定部１１７ａは、１つのソフトウェア種別ＳＷｊ（端末種別ＴＭｉ）に複数の仮総数が算出された場合に、これら複数の仮総数を、複数の当該照会名Ｎｄの各々に対応する周期安定度ＳＴをもって加重平均して、ソフトウェア種別ＳＷｊ（端末種別ＴＭｉ）の総数を推定する。ＮＷ推定部１１７ｎは、各ネットワーク種別ＮＷｋにおける、各ソフトウェア種別（端末種別）の数（又は割合）を推定する。
【0084】
種別分布蓄積部１１８は、総数推定部１１７で推定された端末種別及びソフトウェア種別毎の総数と、端末２が接続された各ネットワーク種別ＮＷｋにおける端末種別及びソフトウェア種別の数（又は割合）とを蓄積し、取り纏めて、種別分布テーブル１１８ｔを作成する。種別分布テーブル１１８ｔの構成は、後に図８を用いて説明される。出力部１０１は、種別分布蓄積部１１８で形成された種別分布テーブル１１８ｔを受け取り、この内容をディスプレイ表示し、紙等の媒体として出力し、又はデータとして外部装置に出力する。
【0085】
［ＤＮＳサーバ］
図５は、本発明によるＤＮＳサーバの一実施形態を示す機能構成図である。
【0086】
図５によれば、ＤＮＳサーバ１’は、ＤＮＳサーバとしてプロバイダネットワーク３に接続された端末２からの名前解決要求を処理する名前解決機能を有すると共に、プロバイダネットワーク３に接続された多数の端末２における、搭載された端末種別及びソフトウェア種別を識別し、さらに各種別の総数を推定する。
【0087】
ＤＮＳサーバ１’は、通信インタフェース１００’と、出力部１０１’と、端末情報推定部１１’と、名前解決機能部１２’とを有する。ここで、端末情報推定部１１’は、クエリ収集部１１０’と、種別識別・計数部１１１’と、共存種別判定部１１６’と、総数推定部１１７’と、種別分布蓄積部１１８’とを有しており、図３で説明された端末情報推定装置１と同様の機能を果たす。
【0088】
［端末情報推定方法］
図６は、本発明の端末情報推定方法のうち、端末２の端末種別及び端末２に搭載されたソフトウェア種別の識別・計数方法の一実施形態を示すフローチャートである。
【0089】
（Ｓ６００）生成された判定規則（１１２ｔ）を入力し、登録する。
（Ｓ６０１）ＯＳ種別ＯＳｉ毎に、ＴＴＬの測定値可能範囲ＴＲｉを予め登録する。
（Ｓ６０２）所定アドレスレンジＡＲｋ毎に、ネットワーク種別｛ＮＷ１，ＮＷ２，・・・，ＮＷｋ，・・・，ＮＷｎｗ｝を予め登録する。
【0090】
（Ｓ６０３）端末種別ＴＭｉのカウント数ｎｔｍｉの初期値、ソフトウェア種別ＳＷｊのカウント数ｎｓｗｊの初期値、ネットワーク種別ＮＷｋに係る端末種別ＴＭｉのカウント数ｎｔｍ（ＮＷｋ）ｉの初期値、及びネットワーク種別ＮＷｋに係るソフトウェア種別ＳＷｊのカウント数ｎｓｗ（ＮＷｋ）ｊの初期値をそれぞれゼロとする。
ｎｔｍｉ＝０（ｉ＝１，２，・・・，ｔｍ）
ｎｓｗｊ＝０（ｊ＝１，２，・・・，ｓｗ）、
ｎｔｍ（ＮＷｋ）ｉ＝０（ｉ＝１，２，・・・，ｔｍ、ｋ＝１，２，・・・，ｎｗ）
ｎｓｗ（ＮＷｋ）ｊ＝０（ｊ＝１，２，・・・，ｓｗ、ｋ＝１，２，・・・，ｎｗ）
【0091】
（Ｓ６０４）収集したＤＮＳクエリを解析しつつＤＮＳクエリ数をカウントするループを開始する。ここで、クエリ数のカウント時間をｔｃｏとする。ｔｃｏは、例えば数分〜１０分間程度とすることができる。
（Ｓ６０５）ＤＮＳサーバ５宛のパケットを収集する。
（Ｓ６０６）収集したパケットが、端末種別又はソフトウェア種別に対応した照会名Ｎｄを有するＤＮＳクエリであるか否かを判定する。この際、判定規則１１２ｔを用いて、このクエリに含まれる照会名Ｎｄに対応する端末種別又はソフトウェア種別が存在するか否かを判定する。
【0092】
（Ｓ６０７ａ）ステップＳ６０６において、収集したパケットがソフトウェア種別に対応した照会名Ｎｄを有するＤＮＳクエリであるとの判定がなされた際、ソフトウェア種別を、このクエリに含まれる照会名Ｎｄに対応したＳＷｊと識別する。一方、ステップＳ６０６で偽の判定、即ち登録された端末種別及びソフトウェア種別のいずれに係るＤＮＳクエリでもないとの判定がなされた際、ステップＳ６１５に移行し、カウント時間の経過を確認しつつ、クエリ数カウントループを繰り返す。
【0093】
（Ｓ６０８ａ）このＤＮＳクエリのＩＰヘッダにおけるＴＴＬ値を測定する。
（Ｓ６０９ａ）測定されたＴＴＬ値が、ＴＴＬテーブル１１４ｔに登録された、識別されたＯＳ（ソフトウェア）種別ＯＳｒに対応するＴＴＬ測定値可能範囲ＴＲｒに含まれるか否かを判定する。ここで、偽の判定がなされた際、ステップＳ６１５に移行し、カウント時間の経過を確認しつつ、クエリ数カウントループを繰り返す。また、ＴＴＬ測定値可能範囲が規定できないアプリケーション種別等の場合、このステップの判定を行わず、次のステップＳ６１０ａに移行する。
【0094】
（Ｓ６１０ａ）ステップＳ６０９ａで真の判定がなされた際、このＯＳ種別ＯＳｉを識別したものとする。次いで、ソフトウェア種別ＳＷｊが、同一の発信元ＩＰアドレスを含む他のＤＮＳクエリの照会名Ｎｄから識別されたソフトウェア種別と、１つの端末２内で共存し得るか否かを判定する。
【0095】
尚、プロバイダネットワーク３の構成として、端末２側に、１つのＩＰアドレスを複数の端末で共有可能なＮＡＴ（Network Address Translation）が設置されている場合、同一の発信元ＩＰアドレスのパケットが同一の端末２から発信されたものと断定することはできない。実際、（クエリ発生周期Ｔｑよりも十分に小さい）所定時間ｔｃｏ内に、１つのＩＰアドレスから複数のソフトウェア種別ＳＷｊに係るＤＮＳクエリが収集された場合、このＩＰアドレスは複数の端末２に対応して使用されている、と判断される。このような場合、ステップＳ６１０ａでの判定条件を緩和するか、又はステップＳ６１０ａを省略することが好ましい。緩和された判定条件としては、例えば、１つのＩＰアドレスにおけるあるＯＳ種別ＯＳｒ更新確認の為のＤＮＳクエリの数が、所定の閾値以下であるか否か、とすることが可能である。
【0096】
（Ｓ６１１ａ）ステップＳ６１０ａで真の判定がなされた際、ＳＷ種別ＳＷｊのカウント数ｎｓｗｊを１だけ増加させる。
ｎｓｗｊ＝ｎｓｗｊ＋１
一方、ステップＳ６１０ａで偽の判定がなされた際、ステップＳ６１５に移行し、カウント時間の経過を確認しつつ、クエリ数カウントループを繰り返す。
【0097】
（Ｓ６０７ｂ）ステップＳ６０６において、収集したパケットが端末種別に対応した照会名Ｎｄを有するＤＮＳクエリであるとの判定がなされた際、端末種別を、このクエリに含まれる照会名Ｎｄに対応したＴＭｉと識別する。
【0098】
（Ｓ６０８ｂ）識別された端末種別ＴＭｉが、同一の発信元ＩＰアドレスを含む他のＤＮＳクエリの照会名Ｎｄから識別されたソフトウェア種別ＳＷｊを搭載し得るか否かを判定する。尚、端末２側に、１つのＩＰアドレスを複数の端末で共有可能なＮＡＴが設置されている場合に、ステップＳ６０８ｂでの判定条件を緩和するか、又はステップＳ６０８ｂを省略することが好ましいことは、ステップＳ６１０ａと同様である。
【0099】
（Ｓ６０９ｂ）ステップＳ６０８ｂで真の判定がなされた際、端末種別ＴＭｉのカウント数ｎｔｍｉを１だけ増加させる。
ｎｔｍｉ＝ｎｔｍｉ＋１
一方、ステップＳ６０８ｂで偽の判定がなされた際、ステップＳ６１５に移行し、カウント時間の経過を確認しつつ、クエリ数カウントループを繰り返す。
【0100】
（Ｓ６１２）発信元ＩＰアドレス毎に、照会名Ｎｄと、識別された端末種別ＴＭｉ及びソフトウェア種別ＳＷｊとを記録する。
（Ｓ６１３）識別対象であるＤＮＳクエリのＩＰアドレス値から、ネットワークテーブル１１５ｔを用いて、ネットワーク種別をＮＷｋと識別する。
（Ｓ６１４）識別されたネットワーク種別ＮＷｋに係る識別された端末種別ＴＭｉ又はソフトウェア種別ＳＷｊのカウント数ｎｔｍ（ＮＷｋ）ｉ又はｎｓｗ（ＮＷｋ）ｊを、１だけ増加させる。
ｎｔｍ（ＮＷｋ）ｉ＝ｎｔｍ（ＮＷｋ）ｉ＋１、又は
ｎｓｗ（ＮＷｋ）ｊ＝ｎｓｗ（ＮＷｋ）ｊ＋１
ここで、ＴＭｉは、現時点の解析対象であるＤＮＳクエリにおいて識別された端末種別である。また、ＳＷｊは、現時点の解析対象であるＤＮＳクエリにおいて識別されたソフトウェア種別である。
【0101】
（Ｓ６１５）ステップＳ６１０の開始からの時間を計測し、予め設定された所定時間ｔｃｏ未満であれば、ステップＳ６０４に戻って、クエリ数カウントループを繰り返す。一方、所定時間ｔｃｏが経過しているのであれば、クエリ数カウントループを終了する。
【0102】
（Ｓ６１６）端末種別（照会名）毎のクエリ数ｎｔｍｉｐ及びｎｔｍ（ＮＷｋ）ｉｐ、並びにソフトウェア種別（照会名）毎のクエリ数ｎｓｗｊｑ及びｎｓｗ（ＮＷｋ）ｊｑを蓄積する。ここで、クエリ数における添え字ｐ（ｑ）は、１つの端末種別（ソフトウェア種別）が異なる複数の照会名Ｎｄに対応している場合における、照会名Ｎｄ毎のクエリ数の区別を表す。
【0103】
尚、以上に説明したソフトウェア（ＯＳ）種別の識別方法のうち、ＴＴＬに関するステップＳ６０８ａ及びステップＳ６０９ａは、省略することができる。また、ソフトウェア種別の共存判断に関するステップＳ６１０ａ及びステップＳ６０８ｂも省略可能である。但し、これらのステップを採用することによって、アプリケーション種別をより高い精度で識別することができる。実際、照会名Ｎｄに表れるソフトウェア種別の特徴は、端末の改造等によって改変される可能性がゼロではない。従って、端末２のアプリケーション種別情報の取得・推定においては、ＴＴＬ情報及び共存可能情報も考慮し、さらに以下に説明する統計手法を取り入れて、総合的な判断を行うことが好ましい。
【0104】
図７は、本発明の端末情報推定方法のうち、端末２の端末種別及び端末２に搭載されたソフトウェア種別の総数を推定する方法の一実施形態を示すフローチャートである。
【0105】
尚、以下に示す方法は、ステップＳ６１６（図６）で蓄積された端末種別（照会名）毎のクエリ数ｎｔｍｉｐ及びｎｔｍ（ＮＷｋ）ｉｐ、並びにソフトウェア種別（照会名）毎のクエリ数ｎｓｗｊｑ及びｎｓｗ（ＮＷｋ）ｊｑの情報を用いて実施される。
【0106】
（Ｓ７００）各端末種別ＴＭｉ及び各ソフトウェア種別ＳＷｊの総数を算出・推定する総数推定ループに入る。このループでは、ｉ＝１，２，・・・，ｔｍ、及びｊ＝１，２，・・・，ｓｗを順次指定することになる。
（Ｓ７０１）クエリ発生周期Ｔｑｉｐ及びＴｑｊｑを用いて、照会名Ｎｄ（ＴＭｉｐ）及びＮｄ（ＳＷｊｑ）毎に、当該端末種別ＴＭｉ及びソフトウェア種別ＳＷｊの仮総数Ｍを、
（１） Ｍｔｍｉｐ＝ｎｔｍｉｐ×Ｔｑｉｐ／（６０×ｔｃｏ）
（２） Ｍｓｗｊｑ＝ｎｓｗｊｑ×Ｔｑｊｑ／（６０×ｔｃｏ）
（３） Ｍｔｍ（ＮＷｋ）ｉｐ＝ｎｔｍ（ＮＷｋ）ｉｐ×Ｔｑｉｐ／（６０×ｔｃｏ）
（４） Ｍｓｗ（ＮＷｋ）ｊｑ＝ｎｓｗ（ＮＷｋ）ｊｑ×Ｔｑｊｑ／（６０×ｔｃｏ）
として算出する。
【0107】
ここで、Ｔｑｉｐ（秒）は、端末種別ＴＭｉの対応する照会名Ｎｄ（ＴＭｉｐ）（ｐ：１つの端末種別が対応する１つ以上の照会名を区別する添え字）に対応付けられたクエリ発生周期である。また、Ｔｑｊｑ（秒）は、ソフトウェア種別ＳＷｊの対応する照会名Ｎｄ（ＳＷｊｑ）（ｑ：１つのソフトウェア種別が対応する１つ以上の照会名を区別する添え字）に対応付けられたクエリ発生周期である。また、ｔｃｏの単位は、分である。
【0108】
例えば、１つの例として、Apple社のiOS（＝ＳＷｊ）では、クエリ発生周期（更新確認時間間隔）Ｔｑｊｑ＝１２（時間）＝４３２００（秒）である。ここで、ｔｃｏ＝１０（分間）の下、iOSの更新確認先であるiphone-ld.apple.comを照会先Ｎｄ（ＳＷｊｑ）としたＤＮＳクエリのカウント数が、ｎ＝１００（回）であったとすると、iOSの仮総数（iOSを搭載した端末の仮総数）Ｍは、
Ｍｓｗｊｑ＝１００×４３２００／（６０×１０）＝７２００
となる。即ち、プロバイダネットワーク４に接続されたiOSを搭載した端末の仮総数は、７２００台であると算出される。
【0109】
さらに、別の例として、図２の判定規則１１２ｔに示したように、１つのＯＳ種別ｊＯＳ（＝ＳＷ１）に対応する照会名Ｎｄ（ＳＷ１ｑ）が３つ（ｑ＝１，２，３）存在する場合、即ち、Ｎｄ（ＳＷ１１）＝｛abc.xxxupdate.com｝、Ｎｄ（ＳＷ１２）＝｛efg.clients.com｝、及びＮｄ（ＳＷ１３）＝｛hij.klmno.com｝が存在する場合を考える。クエリ数カウントのカウント時間ｔｃｏを１０（分間）とし、照会名Ｎｄ（ＳＷ１１）に係るカウント数ｎｓｗ１１＝１６７２、照会名Ｎｄ（ＳＷ１２）に係るカウント数ｎｓｗ１２＝７、及び照会名Ｎｄ（ＳＷ１３）に係るカウント数ｎｓｗ１３＝８とすると、ｊＯＳ（ＳＷ１）の仮総数は、
Ｍｓｗ１１＝１６７２×３５０.７／（６０×１０）＝約９７７.２８
Ｍｓｗ１２＝７×８６４０５.５／（６０×１０）＝約１００８.０６
Ｍｓｗ１３＝８×８６３８９.２／（６０×１０）＝約１１５１.８６
と３つ算出される。
【0110】
因みに、このステップで算出される端末数は、プロバイダネットワーク３に接続される端末２のうち、電源がＯＮ状態であって通信機能が起動した状態のものを対象にした数である。
【0111】
（Ｓ７０２）周期安定度ＳＴｉｐ及びＳＴｊｑを用いて、端末種別ＴＭｉ毎及びソフトウェア種別ＳＷｊ毎に、当該種別の総数Ｎを、
（５） Ｎｔｍｉ＝Σ（Ｍｔｍｉｐ×ＳＴｉｐ）／ΣＳＴｉｐ
（６） Ｎｓｗｊ＝Σ（Ｍｓｗｊｑ×ＳＴｊｑ）／ΣＳＴｊｑ
として算出・推定する。
【0112】
ここで、ＳＴｉｐは、端末種別ＴＭｉの対応する照会名Ｎｄ（ＴＭｉｐ）に対応付けられた周期安定度である。また、ＳＴｊｑは、ソフトウェア種別ＳＷｊの対応する照会名Ｎｄ（ＳＷｊｑ）に対応付けられた周期安定度である。さらに、式（５）のΣはいずれもｐ＝１，２，・・・についての総和（summation）である。また、式（６）のΣはいずれもｑ＝１，２，・・・についての総和である。
【0113】
式（５）及び（６）から理解されるように、端末種別毎及びソフトウェア種別毎の当該種別の総数Ｎは、当該種別に係る少なくとも１つの仮総数Ｍを、対応する周期安定度をもって加重平均した値となっている。
【0114】
（Ｓ７０３）ネットワーク種別ＮＷｋの配下にある端末の端末種別ＴＭｉ及びソフトウェア種別ＳＷｊの総数を、
（７） Ｎｔｍ（ＮＷｋ）ｉ＝Σ（Ｍｔｍ（ＮＷｋ）ｉｐ×ＳＴｉｐ）／ΣＳＴｉｐ
（８） Ｎｓｗ（ＮＷｋ）ｊ＝Σ（Ｍｓｗ（ＮＷｋ）ｊｑ×ＳＴｊｑ）／ΣＳＴｊｑ
として算出・推定する。ここで、ｋ＝１，２，・・・，ｎｗの全てについて、式（７）及び式（８）の算出がなされる。さらに、式（７）のΣはいずれもｐ＝１，２，・・・についての総和（summation）である。また、式（８）のΣはいずれもｑ＝１，２，・・・についての総和である。
【0115】
（Ｓ７０４）識別された全ての端末種別ＴＭｉ及びソフトウェア種別ＳＷｊについて総数を推定するまで、総数推定ループを繰り返す。
【0116】
（Ｓ７０５）端末種別毎の総数
｛Ｎｔｍ１，Ｎｔｍ２，・・・，Ｎｔｍｉ，・・・，Ｎｔｍｔｍ｝、
ソフトウェア種別毎の総数
｛Ｎｓｗ１，Ｎｓｗ２，・・・，Ｎｓｗｊ，・・・，Ｎｓｗｓｗ｝、及び
各ネットワーク種別ＮＷｋに係る端末種別ＴＭｉ及びソフトウェア種別ＳＷｊの各々の数
Ｎｔｍ（ＮＷｋ）ｉ（ｉ＝１，２，・・・，ｔｍ、ｋ＝１，２，・・・，ｎｗ）
Ｎｓｗ（ＮＷｋ）ｊ（ｊ＝１，２，・・・，ｓｗ、ｋ＝１，２，・・・，ｎｗ）
を蓄積する。
【0117】
（Ｓ７０６）ステップＳ７０５で蓄積されたデータを表示又は出力する。
【0118】
［種別分布テーブル］
図８は、種別分布テーブル１１８ｔの一実施形態を示す構成図である。種別分布テーブル１１８ｔは、図７のステップＳ７０５において、種別分布蓄積部１１８（図３）が作成するテーブルである。
【0119】
図８によれば、種別分布テーブル１１８ｔでは、ソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ及びアプリケーション種別ＡＰｓ）毎に、当該ソフトウェア種別ＳＷｊの総数が記載されている。これにより、プロバイダネットワーク３に接続された端末２に搭載された各ＳＷ種別ＳＷｊの総数、従ってこのＯＳｒ又はＡＰｓを搭載した端末数、を推定することができる。また、プロバイダネットワーク３内でのＯＳ種別ＯＳｒの分布及びアプリケーション種別ＡＰｓの分布を得ることができる。
【0120】
また、端末種別ＴＭｉ（端末メーカー、型番）毎に、当該端末種別ＴＭｉの総数が記載されている。これにより、プロバイダネットワーク３に接続された端末２の端末種別ＴＭｉの総数、従ってこの端末種別ＴＭｉの端末数、を推定することができる。また、プロバイダネットワーク３内での端末種別ＴＭｉの分布を得ることができる。
【0121】
さらに、種別分布テーブル１１８ｔでは、ネットワーク種別ＮＷｋ毎に、このネットワーク種別ＮＷｋの配下にある各ソフトウェア種別ＳＷｊの総数が記載されている。これにより、各ネットワーク種別ＮＷｋの配下では、どのようなソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ及びアプリケーション種別ＡＰｓ）がどの程度利用されているかを把握することができる。即ち、ネットワーク種別ＮＷｋ毎に、当該ソフトウェア種別ＳＷｊの分布を得ることができる。
【0122】
［判定規則生成方法の例］
図９は、本発明による判定規則生成方法の一例を示すフローチャートである。ここで、本方法は、例えば図１の判定規則生成装置８で実施される。この際、複数の端末９が装置８に接続され、これら複数の端末９にＩＰアドレスが付与される。
【0123】
（Ｓ９００）最初に、複数の端末９に付与された発信元ＩＰアドレス毎に、端末９に搭載されたソフトウェア種別ＳＷｊ（ＯＳ種別ＯＳｒ、アプリケーション種別ＡＰｓ）を予め登録する。
【0124】
（Ｓ９０１）ＤＮＳクエリ情報収集ループ（ステップＳ９０１〜Ｓ９０８）を開始する。総観測時間（収集時間）はＴｍｅとする。Ｔｍｅは、例えば２４時間〜数ヶ月間に設定することができる。
（Ｓ９０２）端末９から発信されたＤＮＳクエリを収集する。
（Ｓ９０３）収集されたＤＮＳクエリに含まれる照会名Ｎｄ及び発信元ＩＰアドレスを抽出する。
【0125】
（Ｓ９０４）このＤＮＳクエリの発生時刻を、抽出された照会名Ｎｄ及び発信元アドレスに対応付けて記録する。尚、この発生時刻は、ＤＮＳクエリから抽出された時刻情報とすることができる。
（Ｓ９０５）抽出された照会名Ｎｄが、新規であるか否かを判定する。
（Ｓ９０６ａ）抽出された照会名Ｎｄが新規である場合、この照会名Ｎｄを新たにクエリ周期テーブルにエントリする。
【0126】
ここで、クエリ周期テーブルは、エントリされた照会名Ｎｄ毎に、当該クエリが発生する時間間隔の平均値であるクエリ発生周期Ｔｑと、周期安定度ＳＴとを記録するものである。この周期安定度ＳＴは、後述するようにクエリ発生の時間間隔の分布における分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑから算出される。
（Ｓ９０７ａ）次いで、この照会名Ｎｄに対応する値として、クエリ発生周期Ｔｑ及び周期安定度ＳＴを算出し、クエリ周期テーブルに記録する。これらの値の算出は以下の通りに実行される。
【0127】
最初に、照会名Ｎｄ毎に、各発信元ＩＰアドレスについて、対応するＤＮＳクエリの発生時刻の間隔Δｔｎ（ｎ番目の発生時間間隔）の算出式
（９） Δｔｎ＝ｔｎ＋１−ｔｎ （ｔｎ：ＤＮＳクエリのｎ番目の発生時刻）
を用いてΔｔ１をまず算出し、このΔｔ１を、照会名Ｎｄ毎に、クエリ発生周期Ｔｑとしてクエリ周期テーブルに記録する。
【0128】
次いで、逐次入力されるデータを用いて、発生時間間隔Δｔｎ（ｎ≧１）を順次算出し、その都度、
（１０） Ｔｑ＝Σ（Δｔｍ）／ｎ
として、クエリ周期テーブルのクエリ発生周期Ｔｑを更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和（summation）である。即ち、クエリ発生周期Ｔｑは、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの平均値として順次更新される。
【0129】
さらに、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における分散Ｖｑを次式
（１１） Ｖｑ＝Σ（Δｔｍ−Ｔｑ（ｎ））２／ｎ
を用いて順次算出し、クエリ周期テーブルにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。また、Ｔｑ（ｎ）は、発生時間間隔Δｔｎまで考慮して算出されたクエリ発生周期である。
【0130】
次いで、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における尖度Ｋｑを次式
（１２） Ｋｑ＝Σ（Δｔｍ−（Ｔｑ（ｎ））４）／（ｎＶｑ２）−３
を用いて順次算出し、クエリ周期テーブルにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。一般に、正規分布よりも尖った（扁平な）分布の尖度Ｋｑは、ゼロより大きく（小さく）なる。正規分布相当の分布の尖度はゼロである。
【0131】
また、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における歪度Ｓｑを次式
（１３） Ｓｑ＝Σ（Δｔｍ−Ｔｑ（ｎ））３／（ｎＶｑ１.５）
を用いて順次算出し、クエリ周期テーブルにおいて逐次記録・更新する。ここで、Σはｍ＝１，２，・・・，ｎについての総和である。一般に、左側（右側）に偏った分布の歪度Ｓｑは、ゼロより大きく（小さく）なる。左右対称な分布の歪度はゼロである。
【0132】
さらに、算出された分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑを用いて、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの周期安定度ＳＴを次式
（１４ａ） ＳＴ＝１−ＡＳＴ
（１４ｂ） ＡＳＴ＝Ｎ［（Ｖｑ２＋Ｋｑ２＋Ｓｑ２）０.５］
を用いて順次算出し、クエリ周期テーブルにおいて逐次記録・更新する。ここで上式（１４ｂ）の関数Ｎ［Ｘ］は、ゼロ又は正値をとる変数Ｘを０から１までの値に規格化する関数であり、例えば、
（１５） Ｎ［Ｘ］＝−（Ｘ＋１）−１＋１
とすることができる。これにより、ＡＳＴは、発生時間間隔Δｔ１、Δｔ２、・・・、Δｔｎの分布における平均値（クエリ発生周期Ｔｑ）の不安定度（不確からしさ）に相当し、分布がより分散していて、より正規分布から逸脱しており、より偏りが大きいほど、大きな値をとる。
【0133】
その結果、周期安定度ＳＴの値は、クエリ発生時間間隔が最も安定している場合（不安程度ＡＳＴがゼロの場合）、１となる。一方、クエリ発生時間間隔がクエリ発生周期Ｔｑから変動しがちになるにつれて、ゼロに近づく。このような周期安定度ＳＴの値を導入して端末情報（端末数等）の推定を行うことによって、より精度の高い推定が可能となる。
【0134】
尚、周期安定度ＳＴは、（１４ａ）及び（１４ｂ）で規定されるものに限らない。分散Ｖｑ、尖度Ｋｑ及び歪度Ｓｑについての上記以外の所定の平均から決定されることも好ましく、又は、分散Ｖｑのみから決定される（例えばＳＴ＝１−Ｎ［Ｖｑ］）ことも可能である。
【0135】
（Ｓ９０６ｂ）一方、抽出された照会名Ｎｄが新規ではない場合、既にエントリされている当該照会名Ｎｄを参照する。
（Ｓ９０７ｂ）次いで、この照会名Ｎｄ毎に、上述したようにクエリ発生周期Ｔｑ及び周期安定度ＳＴを算出し、クエリ周期テーブルに記録されたこれらの値を更新する。
【0136】
（Ｓ９０８）ＤＮＳクエリ情報収集ループを開始してから、設定された総観測時間Ｔｍｅが経過したか否かを判定し、経過していれば、本ループ（ＤＮＳクエリの収集・解析）を終了する。一方、経過していなければ、Ｓ９０１に戻って本ループを継続して行う。
【0137】
（Ｓ９０９）照会名Ｎｄ毎に、ソフトウェア種別ＳＷｊを対応付けた上で、最終的に決定されたクエリ発生周期Ｔｑ及び周期安定度ＳＴを記録した判定規則（１１２ｔ）を生成する。
（Ｓ９１０）生成した判定規則（１１２ｔ）を出力する。この際、この判定規則を、端末情報推定装置１に送信してもよく、又はディスプレイ表示し、紙等の媒体として出力し、若しくはデータとして外部装置に出力することもできる。
【0138】
尚、判定規則生成方法の本実施形態（ステップＳ９００〜Ｓ９１０）において、「ソフトウェア種別」に代えて「端末種別」を採用すれば、複数の端末２の端末種別ＴＭｉに係る判定規則を生成することができる。この場合、判定規則は、照会名Ｎｄ毎に、端末種別ＴＭｉを対応付けた上で、最終的に決定されたクエリ発生周期Ｔｑ及び周期安定度ＳＴを記録したものとなる。
【0139】
以上、本発明によれば、判定規則を利用することによって、照会名Ｎｄに対応したクエリ発生周期Ｔｑから、ネットワーク全体における端末種別、ソフトウェア種別及び各種別の仮総数を算出することができる。また、照会名に対応した周期安定度ＳＴを用いることによって、算出された仮総数からより高い精度で総数（端末数）を推定することが可能となる。即ち、本発明によれば、ネットワーク全体における端末種別、ソフトウェア種別及び各種別の総数を含む端末情報をより高い精度をもって推定することができる。
【0140】
ここで、特に、周期安定度ＳＴを考慮して端末数を推定することができるので、より短時間で（より少ないクエリ観測数から）、精度の高い端末数を推定することができる。実際、ＤＮＳクエリを収集する時間ｔｃｏは、クエリ発生周期Ｔｑに比べて非常に短い時間（例えばｔｃｏ＝数分〜１０分）とすることが可能である。従って、本発明によれば、例えば、移動端末の通信エリア間又は通信エリア内外への移動による影響を受けにくい端末情報の推定が可能となる。
【0141】
また、このように短時間での総数の推定が可能であるので、あるソフトウェア種別における異なる時間帯での総数を比較したり、あるソフトウェア種別における各時刻での総数の推移を得たり、さらには、各時刻における異なるソフトウェア種別間の総数比を比較したりすることができる。例えば、午前１０時からの１０分間についての、あるＯＳ種別ＯＳｒの総数Ｎ１０と、午後１０時からの１０分間についてのこのＯＳ種別ＯＳｒの総数Ｎ２２とを推定して比較することが可能となる。
【0142】
さらに、本発明によれば、大規模なネットワーク全体における端末種別、ソフトウェア種別を、全通信を取得することなく識別することができる。また、識別した各端末種別、各ソフトウェア種別の総数を、全通信を取得することなく高い精度で推定することができる。
【0143】
また、本発明によれば、自らパケットを送信するといった能動的な検査を必要としない。即ち、ソフトウェア種別情報の識別・推定を受動的に実施することができる。その結果、例えば、端末側に設けられたフィルタリング機構によって検査不能となる事態を引き起こすことがない。
【0144】
さらに、以上に説明した本発明によって推定される端末情報は、例えば、ネットワーク管理者にとって、ネットワークの安定した運用を維持するために非常に重要となる。即ち、これら端末情報の把握によって、通信障害の原因となる利用者の行為を未然に防止したり、トラフィックのオフロード状況を把握したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【0145】
しかしながら、ネットワーク内では、常に、新たなアプリケーションやＯＳが次々と利用され、各種ソフトウェアの利用者数も大きく変動する。このような状況でも、本発明によれば、適宜、現在の通信状況・利用状況に適合した判定規則を活用して端末情報を推定することができる。その結果、ネットワーク管理者は、より適切な精度の高い端末情報を入手することができ、より適切な対策を講じることができる。
【0146】
尚、以上に述べた本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【符号の説明】
【0147】
１ 端末情報推定装置
１００、１００’ 通信インタフェース
１０１、１０１’ 出力部
１１’ 端末情報推定部
１１０、１１０’ クエリ収集部
１１１、１１１’ 種別識別・計数部
１１１ｃ クエリ数カウント部
１１１ｄ ＩＰアドレス抽出部
１１１ｍ 端末種別識別部
１１１ｎ ネットワーク種別識別部
１１１ｑ 照会名抽出部
１１１ｓ ソフトウェア種別識別部
１１２ 判定規則登録部
１１２ｔ 判定規則
１１３ 共存種別登録部
１１３ｔ 共存可能テーブル
１１４ ＴＴＬ範囲登録部
１１４ｔ ＴＴＬテーブル
１１５ ネットワーク種別登録部
１１５ｔ ネットワークテーブル
１１６、１１６’ 共存種別判定部
１１７、１１７’ 総数推定部
１１７ａ 総数推定部
１１７ｃ 仮総数算出部
１１７ｎ ネットワーク推定部
１１８、１１８’ 種別分布蓄積部
１１８ｔ 種別分布テーブル
１２’ 名前解決機能部
２、９ 端末
３ プロバイダネットワーク
４ ＩＭＳ
５ ＤＮＳサーバ
６ ネットワークタップ
７ インターネット
８ 判定規則生成装置
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
Copyright © 2010-2025 Science Impact Inc. All Rights Reserved.