(57)【特許請求の範囲】
【請求項１】
ＤＮＳ（Domain Name System）サーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定装置であって、
当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
を有することを特徴とする端末情報推定装置。
【請求項２】
前記複数の端末に搭載されたソフトウェア種別毎の総数を推定する総数推定手段を更に有しており、
前記照会名登録手段は、ソフトウェア種別毎にクエリ発生頻度を更に予め登録し、
前記ソフトウェア種別識別手段は、ソフトウェア種別毎に、所定の収集期間内に収集された、当該ソフトウェア種別に対応するクエリの数をカウントし、
前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生頻度と、当該所定の収集期間と、カウントされたクエリ数とから当該ソフトウェア種別の総数を算出する
ことを特徴とする請求項１に記載の端末情報推定装置。
【請求項３】
当該ソフトウェア種別毎に、予め登録されたクエリ発生頻度をＴ時間に１回とし、所定の収集期間Δｔ分内にカウントされた、当該ソフトウェア種別に対応するクエリ数をｎ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
Ｎ＝ｎ・（６０・Ｔ／Δｔ）
として算出することを特徴とする請求項２に記載の端末情報推定装置。
【請求項４】
前記照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、当該クエリ発生周期より長い時間間隔で発生する頻度又は確率とを更に予め登録し、
前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生周期と、当該所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率とを用いて補正を行うことに相当する計算を行って、当該ソフトウェア種別の総数を算出する
ことを特徴とする請求項２に記載の端末情報推定装置。
【請求項５】
当該ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴｄ秒とし、当該クエリが所定の収集期間Ｔｑ秒以内の時間間隔で発生する確率をｐＬｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔｄより長い時間間隔で発生する確率をｐＯｄ,Ｔｄとし、当該所定の収集期間Ｔｑ秒内にカウントされた、当該ソフトウェア種別に対応するクエリ数をＮｄ,Ｔｑ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋ｐＬｄ,Ｔｑ))
として算出することを特徴とする請求項４に記載の端末情報推定装置。
【請求項６】
前記照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、クエリ発生周期より長い間隔で発生する頻度又は確率と、当該クエリが設定された収集期間内に発生する回数の平均値とを更に予め登録し、
前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生周期と、当該所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率と、当該クエリが当該所定の収集期間内に発生する回数の平均値とを用いて補正を行うことに相当する計算を行って、当該ソフトウェア種別の総数を算出する
ことを特徴とする請求項２に記載の端末情報推定装置。
【請求項７】
当該ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴｄ秒とし、当該クエリが所定の収集期間Ｔｑ秒以内の時間間隔で発生する確率をｐＬｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔｄより長い時間間隔で発生する確率をｐＯｄ,Ｔｄとし、当該クエリが当該所定の収集期間内に発生する回数の平均値μＬｄ,Ｔｑをとし、当該所定の収集期間Ｔｑ秒内にカウントされた、当該ソフトウェア種別に対応するクエリ数をＮｄ,Ｔｑ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ))
として算出することを特徴とする請求項６に記載の端末情報推定装置。
【請求項８】
１つの端末内で共存可能な複数のソフトウェア種別の組合せを登録する共存種別登録手段と、
前記クエリの送信元アドレス毎に、異なるソフトウェア種別を含む複数のクエリが受信された際に、前記共存種別登録手段を用いて該異なるソフトウェア種別が共存し得る関係にあるか否かを判定する共存種別判定手段と
を更に有しており、
前記ソフトウェア種別識別手段は、前記共存種別判定手段が真の判定を行った際、当該送信元アドレスを含んでおり当該ソフトウェア種別に対応するクエリをカウント対象とする
ことを特徴とする請求項１から７のいずれか１項に記載の端末情報推定装置。
【請求項９】
当該ソフトウェア種別毎に、ＩＰ(Internet Protocol)のＴＴＬ(Time To Live)の測定値可能範囲を予め登録したＴＴＬ範囲登録手段を更に有し、
前記ソフトウェア種別識別手段は、当該クエリに含まれるＩＰヘッダのＴＴＬの値が、前記ＴＴＬ範囲登録手段に登録された、識別された当該ソフトウェア種別に対応する測定値可能範囲に含まれる場合にのみ、当該ソフトウェア種別を識別したものとする
ことを特徴とする請求項１から８のいずれか１項に記載の端末情報推定装置。
【請求項１０】
前記複数の端末の送信元アドレスにおける所定アドレス範囲毎に、アクセスネットワーク種別を予め登録するネットワーク種別登録手段と、
前記ソフトウェア種別識別手段は、識別対象となるクエリについて、前記ネットワーク種別登録手段を用いて、当該クエリの送信元アドレスからアクセスネットワーク種別を更に識別する
ことを特徴とする請求項１から９のいずれか１項に記載の端末情報推定装置。
【請求項１１】
前記ソフトウェア種別は、ＯＳ(Operating System)種別及び／又はアプリケーション種別であり、
前記照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の接続先アドレスである
ことを特徴とする請求項１から１０のいずれか１項に記載の端末情報推定装置。
【請求項１２】
照会名を含むクエリを発信する複数の端末の情報を推定する機能を搭載したＤＮＳサーバであって、
当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
を有することを特徴とするＤＮＳサーバ。
【請求項１３】
ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定するようにコンピュータを機能させる端末情報推定プログラムであって、
当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
してコンピュータを機能させることを特徴とする端末情報推定プログラム。
【請求項１４】
ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定方法であって、
当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段を用い、
当該端末から発信された当該クエリを収集し蓄積する第１のステップと、
蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別する第２のステップと
を有することを特徴とする端末情報推定方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数の端末が接続されたネットワークの管理・監視の技術に関する。
【背景技術】
【０００２】
ネットワーク管理者は、ネットワークの安定した運用を維持するため、ネットワーク利用者の利用環境及び利用状況を把握しなければならない。この把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【０００３】
しかしながら、ネットワーク管理者が利用者の利用実態を十分に把握することは一般に困難である。例えば、インターネット接続業者（ＩＳＰ：Internet Service Provider）とそのユーザとのように、管理者と利用者とが異なる組織に属している場合、管理者が利用者の利用状況を監視することは困難である。特に、ネットワークが国内外に及ぶ場合、利用状況を物理的に監視して直接把握することは極めて難しい。
【０００４】
一方、企業内ネットワークのように、利用者のネットワーク利用が厳しく規定されている場合でも、利用者が、許可されていない端末を接続して規定外の利用を行う事態を許してしまう事例が存在する。
【０００５】
このような状況下で、現在、利用者による通信のみを監視し、通信そのものから利用者の利用環境及び利用状況を把握する技術が検討されている。
【０００６】
例えば、非特許文献１には、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）における、オペレーティングシステム（ＯＳ: Operating System）に固有の振る舞いを監視することによって、利用者の各端末に搭載されたＯＳ種別を識別する方法が開示されている。ここで、ＴＣＰ／ＩＰは、インターネットで標準的に使用されるプロトコルである。また、監視は受動的に（自らパケットを送信せずに）実施される。
【０００７】
さらに、非特許文献２には、同じくＴＣＰ／ＩＰにおけるＯＳ固有の振る舞いを利用するが、受動的監視のみならず能動的な（自らパケットを送信する）検査を実施することによって、より精度の高いＯＳ種別の判別を図った識別方法が開示されている。
【０００８】
また、非特許文献３には、ＨＴＴＰ（Hypertext Transfer Protocol）ヘッダに含まれる、ＯＳ又はアプリケーションに固有の文字列を抽出し組み合わせて、利用者端末に搭載されたウェブブラウザ（Web Browser）種別を識別する技術が開示されている。ここで、ＨＴＴＰは、ウェブブラウザとウェブサーバ（Web Server）との間の通信プロトコルである。
【０００９】
さらに、非特許文献４には、ＤＮＳ（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＞
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、上述したような従来技術を用いても、ＩＳＰレベルの大規模なネットワーク全体における、端末に搭載されたＯＳ及びアプリケーションの利用状況を推定することは、非常に困難である。
【００１２】
例えば、非特許文献１及び３の技術では、基本的にネットワーク上の通信を全て取得する必要がある。その結果、これらの技術を広帯域である基幹回線に適用する場合、導入コストが莫大となり実現性が低下する。一方、大規模ネットワークの末端部に適用する場合、末端部での監視箇所の数が膨大となってしまう。
【００１３】
また、非特許文献１及び２の技術では、ＴＣＰ／ＩＰの特徴を利用するので、ＯＳ種別を識別することしかできず、ＯＳ上で発動するアプリケーション種別までは識別できない。一方、非特許文献３の技術では、ＨＴＴＰヘッダの特徴を利用するので、アプリケーションのうちウェブブラウザ種別を識別することしかできない。
【００１４】
さらに、非特許文献４の技術では、ＩＰｖ４とＩＰｖ６とが混在している通信環境であることが前提となるため、ＩＰｖ４又はＩＰｖ６単独の環境では、ＯＳ種別を識別することができない。従って、ＩＰｖ６への全面移行の際には、当該技術は適用不可能となる。
【００１５】
また、特に、非特許技術２の技術では、管理者が自らパケットを送信するといった能動的な検査を実施する必要がある。その結果、自身の管理下にはないネットワークの利用者に検査用のパケットを送信しようとしても、受け入れられない可能性が高い。さらに、利用者側のネットワークにファイアウォール（Firewall）、又はＮＡＴ（Network Address Translation）等のフィルタリング機構が設けられている場合、非特許技術２の技術は、適用不可能である。
【００１６】
そこで、本発明は、大規模なネットワーク全体における、ＯＳ種別及び／又はアプリケーション種別に係る情報を、受動的に、且つ全通信を検査することなく取得可能な端末情報推定装置、ＤＮＳサーバ、プログラム及び方法を提供することを目的とする。
【課題を解決するための手段】
【００１７】
本発明によれば、ＤＮＳ（Domain Name System）サーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定装置であって、
照会名毎に、複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
端末から発信されたクエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
を有する端末情報推定装置が提供される。
【００１８】
この本発明による端末情報推定装置の一実施形態として、複数の端末に搭載されたソフトウェア種別毎の総数を推定する総数推定手段を更に有しており、
照会名登録手段は、ソフトウェア種別毎にクエリ発生頻度を更に予め登録し、
ソフトウェア種別識別手段は、ソフトウェア種別毎に、所定の収集期間内に収集された、当該ソフトウェア種別に対応するクエリの数をカウントし、
総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生頻度と、当該所定の収集期間と、カウントされたクエリ数とから当該ソフトウェア種別の総数を算出することも好ましい。
【００１９】
さらに、この総数推定手段を有する上記の実施形態で、ソフトウェア種別毎に、予め登録されたクエリ発生頻度をＴ時間に１回とし、所定の収集期間Δｔ分内にカウントされた、当該ソフトウェア種別に対応するクエリ数をｎ個とすると、総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
Ｎ＝ｎ・（６０・Ｔ／Δｔ）
として算出することも好ましい。
【００２０】
さらに、上記の総数推定手段を有する実施形態で、照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、クエリ発生周期より長い時間間隔で発生する頻度又は確率とを更に予め登録し、
総数推定手段は、ソフトウェア種別毎に、予め登録されたクエリ発生周期と、所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率とを用いて補正を行うことに相当する計算を行って、ソフトウェア種別の総数を算出することも好ましい。
【００２１】
また、上記ソフトウェア種別の総数算出の実施形態において、ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴｄ秒とし、当該クエリが所定の収集期間Ｔｑ秒以内の時間間隔で発生する確率をｐＬｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔｄより長い時間間隔で発生する確率をｐＯｄ,Ｔｄとし、所定の収集期間Ｔｑ秒内にカウントされた、ソフトウェア種別に対応するクエリ数をＮｄ,Ｔｑ個とすると、総数推定手段は、ソフトウェア種別の総数Ｎ個を、
Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋ｐＬｄ,Ｔｑ))
として算出することも好ましい。
【００２２】
さらに、上記の総数推定手段を有する実施形態で、照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、クエリ発生周期より長い間隔で発生する頻度又は確率と、当該クエリが設定された収集期間内に発生する回数の平均値とを更に予め登録し、
総数推定手段は、ソフトウェア種別毎に、予め登録されたクエリ発生周期と、所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率と、当該クエリが所定の収集期間内に発生する回数の平均値とを用いて補正を行うことに相当する計算を行って、ソフトウェア種別の総数を算出することも好ましい。
【００２３】
また、上記ソフトウェア種別の総数算出の実施形態において、ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴｄ秒とし、当該クエリが所定の収集期間Ｔｑ秒以内の時間間隔で発生する確率をｐＬｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔｄより長い時間間隔で発生する確率をｐＯｄ,Ｔｄとし、当該クエリが所定の収集期間内に発生する回数の平均値μＬｄ,Ｔｑをとし、所定の収集期間Ｔｑ秒内にカウントされた、ソフトウェア種別に対応するクエリ数をＮｄ,Ｔｑ個とすると、前数推定手段は、ソフトウェア種別の総数Ｎ個を、
Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ))
として算出することも好ましい。
【００２４】
また、本発明による端末情報推定装置の他の実施形態として、１つの端末内で共存可能な複数のソフトウェア種別の組合せを登録する共存種別登録手段と、
クエリの送信元アドレス毎に、異なるソフトウェア種別を含む複数のクエリが受信された際に、共存種別登録手段を用いてこれら異なるソフトウェア種別が共存し得る関係にあるか否かを判定する共存種別判定手段と
を更に有しており、
ソフトウェア種別識別手段は、共存種別判定手段が真の判定を行った際、当該送信元アドレスを含んでおり当該ソフトウェア種別に対応するクエリをカウント対象とすることも好ましい。
【００２５】
さらに、本発明による端末情報推定装置の他の実施形態として、ソフトウェア種別毎に、ＩＰ(Internet Protocol)のＴＴＬ(Time To Live)の測定値可能範囲を予め登録したＴＴＬ範囲登録手段を更に有し、
ソフトウェア種別識別手段は、当該クエリに含まれるＩＰヘッダのＴＴＬの値が、ＴＴＬ範囲登録手段に登録された、識別された当該ソフトウェア種別に対応する測定値可能範囲に含まれる場合にのみ、当該ソフトウェア種別を識別したものとすることも好ましい。
【００２６】
また、本発明による端末情報推定装置の他の実施形態として、複数の端末の送信元アドレスにおける所定アドレス範囲毎に、アクセスネットワーク種別を予め登録するネットワーク種別登録手段と、
ソフトウェア種別識別手段は、識別対象となるクエリについて、ネットワーク種別登録手段を用いて、当該クエリの送信元アドレスからアクセスネットワーク種別を更に識別することも好ましい。
【００２７】
さらに、本発明による端末情報推定装置の他の実施形態として、ソフトウェア種別は、ＯＳ種別及び／又はアプリケーション種別であり、
照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の接続先アドレスであることも好ましい。
【００２８】
本発明によれば、さらに、照会名を含むクエリを発信する複数の端末の情報を推定する機能を搭載したＤＮＳサーバであって、
照会名毎に、複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
端末から発信されたクエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、照会名登録手段を用いてクエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
を有するＤＮＳサーバが提供される。
【００２９】
本発明によれば、また、ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定するようにコンピュータを機能させる端末情報推定プログラムであって、
照会名毎に、複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
端末から発信されたクエリを収集し蓄積するクエリ収集手段と、
蓄積された各クエリに含まれる照会名を抽出し、照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
してコンピュータを機能させる端末情報推定プログラムが提供される。
【００３０】
本発明によれば、さらに、ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定方法であって、
照会名毎に、複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段を用い、
端末から発信されたクエリを収集し蓄積する第１のステップと、
蓄積された各クエリに含まれる照会名を抽出し、照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別する第２のステップと
を有する端末情報推定方法が提供される。
【発明の効果】
【００３１】
本発明の端末情報推定装置、ＤＮＳサーバ、プログラム及び方法によれば、大規模なネットワーク全体における、ＯＳ種別及び／又はアプリケーション種別に係る情報を、受動的に、且つ全通信を検査することなく取得することができる。
【図面の簡単な説明】
【００３２】
【図１】本発明の端末情報推定装置が接続されるネットワークの構成図である。
【図２】照会名テーブル及び共存可能ソフトウェアテーブルの構成図である。
【図３】ＴＴＬテーブル及びアクセスネットワークテーブルの構成図である。
【図４】本発明による端末情報推定装置の一実施形態を示す機能構成図である。
【図５】本発明によるＤＮＳサーバの一実施形態を示す機能構成図である。
【図６】本発明の端末情報推定方法のうち、端末に搭載されたソフトウェア種別の識別方法の一実施形態を示すフローチャートである。
【図７】本発明の端末情報推定方法のうち、端末に搭載されたソフトウェア種別の総数を推定する方法の一実施形態を示すフローチャートである。
【図８】照会名テーブルにおける他の実施形態の構成図である。
【図９】ＯＳ・ＡＰ・ＮＷ分布テーブルの構成図である。
【発明を実施するための形態】
【００３３】
以下では、本発明の実施の形態について、図面を用いて詳細に説明する。
【００３４】
図１は、本発明の端末情報推定装置が接続されるネットワークの構成図である。
【００３５】
図１によれば、端末情報推定装置１は、多数の端末２に搭載されたＯＳ種別及びアプリケーション種別といったソフトウェア種別を識別し、各種別の総数を推定する装置である。ここで、端末２は、スマートフォン、タブレット型コンピュータ、又はパーソナルコンピュータ等の情報機器であり、インターネット７にアクセスネットワーク３０〜３２のいずれかを介して接続される。
【００３６】
アクセスネットワーク３０〜３２はそれぞれ、例えば、固定系ネットワーク、３Ｇ（3rd Generation）、及びＷｉ−Ｆｉ（登録商標）等の無線ＬＡＮである。ここで、固定系ネットワークとして、光ファイバ網、及びＡＤＳＬ（Asymmetric Digital Subscriber Line）等を採用することができる。さらに、アクセスネットワークとして、ＷｉＭＡＸ（Worldwide Interoperability for Microwave Access）、及びＬＴＥ(Long Term Evolution)等の他の無線系ネットワークを採用することも可能である。
【００３７】
また、プロバイダネットワーク３は、例えばＩＭＳ（IP Multimedia Subsystem）４によって、これらアクセスネットワーク３０〜３２を介した通信を制御する事業者ネットワークである。ＩＭＳ４は、これらアクセスネットワーク３０〜３２とインターネット７との間に介在しており、アクセスネットワーク３０〜３２におけるインターネット７を介した通信の確立をコントロールする。ＤＮＳサーバ５は、このマルチメディアサービスを提供するＩＭＳ４と接続されており、アクセスネットワーク３０〜３２を介した名前解決要求を受け付ける。
【００３８】
端末情報推定装置１は、ＤＮＳサーバ５への回線に設けられたネットワークタップ（又はミラーリングハブ）を介してプロバイダネットワーク３に接続される。これにより、端末情報推定装置１は、多数の端末２がプロバイダネットワーク３を介してＤＮＳサーバ５宛に発信するＤＮＳクエリを全て収集し、ＤＮＳクエリを解析して端末情報を推定する。
【００３９】
各端末２は、ＯＳ及びアプリケーション等のソフトウェアで使用されている名前を解決する必要がある場合に、リゾルバとして、ＤＮＳクエリ（query）をＤＮＳサーバ５に送信する。ＤＮＳサーバ５は、ＤＮＳクエリを受け取ると、他のＤＮＳサーバと通信して又は自ら名前を解決して、応答をクエリ送信元の端末２に送信する。
【００４０】
ここで、各端末２に搭載されたＯＳ、及びウェブブラウザ等の多くのアプリケーションは、通常、インターネット７を通して自らの更新を行う。このため、そのソフトウェア種別固有のドメイン名のサイトに定期的に接続を試みる。従って、各端末２は、そのソフトウェア種別固有の時間間隔をもって、この固有のドメイン名を照会名として含むＤＮＳクエリを、ＤＮＳサーバ５宛てに送信する。
【００４１】
端末情報推定装置１は、各端末２から送信されたこれらＤＮＳクエリを収集し、その内容を解析して、端末２に搭載されたＯＳ種別、及びウェブブラウザ等のアプリケーション種別、並びに各種別の総数を推定する。具体的には、
（ａ）ソフトウェア種別識別部１１１が、照会名テーブル１１２ｔを用いて、収集したＤＮＳクエリに含まれる照会名からこのＤＮＳクエリに対応するソフトウェア種別を識別する。さらには、ＴＴＬテーブル１１４ｔを用いて、より確度の高い識別を行うことも好ましい。
【００４２】
（ｂ）この際、共存種別判定部１１６が、ＤＮＳクエリの送信元ＩＰアドレス毎に、異なるソフトウェア種別を含む複数のＤＮＳクエリが受信された際に、これら異なるソフトウェア種別が共存し得る関係にあるか否かを判定することも好ましい。ここで、この判定には、共存可能ソフトウェアテーブル１１３ｔを用い、より確度の高い判定を行う。
【００４３】
（ｃ）さらに、ソフトウェア種別識別部１１１は、ソフトウェア種別（ＯＳ種別及びアプリケーション種別）毎に、所定の収集期間内に収集された、当該ソフトウェア種別に対応するクエリの数をカウントする。その後、総数推定部１１７が、照会名テーブル１１２ｔに予め登録されたクエリ発生周期（クエリ発生頻度）と、カウントされたクエリ数とから、当該ソフトウェア種別の総数（当該ソフトウェアを搭載した端末の総数）を算出する。
【００４４】
（ｄ）さらにまた、ソフトウェア種別識別部１１１は、識別対象となるＤＮＳクエリについて、アクセスネットワークテーブル１１５ｔを用いて、このＤＮＳクエリの送信元ＩＰアドレスから、アクセスネットワーク種別及びその数を更に識別・算出することも好ましい。
【００４５】
尚、端末情報推定装置１は、アクセスネットワーク３０〜３２のゲートウェイ位置に設置されることも可能である。この場合、設置されたアクセスネットワーク内のソフトウェア種別（ＯＳ種別及びアプリケーション種別）及びそれらの総数を推定することになる。
【００４６】
さらに、各端末２に搭載されたソフトウェアに関連するＤＮＳクエリの発信は、上述したようなソフトウェア更新確認時のみならず、ソフトウェア処理の実行に必要な情報要求時にも実施される。例えば、時刻合わせのための時刻情報の要求時、電子メールでのメールボックスの確認時、各種ソーシャルネットワーク・サービスにおける他者情報のチェック時等にも、ＤＮＳクエリが発信される。即ち、多くのソフトウェアでは、ＤＮＳサーバ５を利用して名前を解決してから通信を開始することが１つのパターンとなっている。
【００４７】
この際の照会名（接続先のドメイン名）には、ソフトウェア種別（ＯＳ種別、アプリケーション種別）に固有のものが多く存在する。本願発明者等は、多くのソフトウェア種別（ＯＳ種別、アプリケーション種別）において、ソフトウェア更新確認のためのＤＮＳクエリに限らず、種々のＤＮＳクエリの発信タイミングが、ソフトウェア種別固有の「クエリ発生周期」を有し得ることを見出した。
【００４８】
この「クエリ発生周期」は、対象となっているＤＮＳクエリの発生時間間隔の平均値である。ＤＮＳクエリは、定期的なＯＳ更新確認等、対応するソフトウェア種別（照会名）固有の時間間隔（周期）をもって発信される場合が多く、ソフトウェア種別（照会名）毎に「クエリ発生周期」が決定可能である。
【００４９】
但し、実際の名前解決の際には、前回のＤＮＳクエリに対する応答としてキャッシュされたリソースレコードのＴＴＬ（Time To Live）に応じて所定の時間が指定され、この時間内にはクエリは発信されない（このリソースレコードで回答されたドメイン名が再利用される）。このような事情等があって、クエリ発生の時間間隔（クエリ発生周期）には変動が生じる。後に、このような変動を含むクエリ発生周期の変動に対処すべく、ＤＮＳクエリが収集期間Ｔｑよりも短い又は発生周期よりも長い時間間隔で観測される確率を考慮した端末数推定の方法も説明される。
【００５０】
［識別・推定用テーブル］
図２は、照会名テーブル１１２ｔ、及び共存可能ソフトウェアテーブル１１３ｔの構成図である。また、図３は、ＴＴＬテーブル１１４ｔ、及びアクセスネットワークテーブル１１５ｔの構成図である。
【００５１】
図２（Ａ）に、照会名テーブル（判定規則）１１２ｔのＯＳ種別対応部分を示す。同図によれば、ＤＮＳクエリに含まれる照会名Ｎｄ毎に、対応するＯＳ種別ＯＳｉと、このＯＳ種別ＯＳｉにおけるソフトウェア更新を確認する動作の時間間隔であるクエリ発生周期Ｔｏｓｉとが予め登録されている。
【００５２】
照会名Ｎｄは、端末２に搭載されたＯＳが更新確認の際に接続する接続先のドメイン名である。ＯＳ種別ＯＳｉは、更新確認の際にこの照会名Ｎｄのサイトに接続を試みるＯＳ種別である。また、更新確認時間間隔（クエリ発生周期）Ｔｏｓｉは、ＯＳ種別ＯＳｉが更新確認のため、照会名Ｎｄに接続を試みる、ＯＳ種別ＯＳｉ固有の時間間隔である。ここで、更新確認頻度（クエリ発生頻度）は、Ｔｏｓｉ（時間）に１回となり、更新確認時間間隔（クエリ発生周期）Ｔｏｓｉの逆数（Ｔｏｓｉ−１）で表される。
【００５３】
ＯＳ種別ＯＳｉ毎の更新確認時の照会名Ｎｄは、例えば、以下の通りである。
《ＯＳ種別ＯＳｉ》                  《照会名Ｎｄ》
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」では、１.５時間となる。
【００５９】
図２（Ｃ）に、共存可能ソフトウェアテーブル１１３ｔの構成を示す。同図によれば、テーブル１１３ｔには、１つの端末２内で共存可能な複数のソフトウェア種別の組合せが登録されている。具体的には、識別され得るソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）毎に、１つの端末２内で共存可能な複数のソフトウェア種別が登録されている。
【００６０】
例えば、あるアプリケーション種別は、特定のＯＳ種別上でのみ動作する。この場合、このアプリケーション種別に対応するテーブル欄に、このＯＳ種別が登録され、また、このアプリケーション種別は、他のＯＳ種別に対応するテーブル欄から除外される。さらに、１つの端末２内で互いに共存できないアプリケーション種別も存在する。この場合、この一方のアプリケーション種別は、他方のアプリケーション種別に対応するテーブル欄から除外される。
【００６１】
図３（Ａ）に、ＴＴＬテーブル１１４ｔの構成を示す。同図によれば、識別され得るＯＳ種別ＯＳｉ毎に、ＩＰ(Internet Protocol)のＴＴＬ(Time To Live)の測定値可能範囲ＴＲｉが予め登録されている。ここで、ＴＴＬは、パケットの有効期間を表すための数値であり、ＩＰヘッダ内に格納されている。
【００６２】
ＴＴＬの初期値は、ＯＳに固有の値となっている。例えば、
Microsoft社のWindows OS：ＴＴＬの初期値＝１２８
Linux（登録商標）のKernel 2.6：ＴＴＬの初期値＝６４
であり、互いに異なっている。
【００６３】
このＴＴＬは、ルータを通過する毎に値が１だけ減少する。従って、パケットを収集してＴＴＬを測定した場合、初期値よりも小さな測定値が得られるが、この測定値の範囲を予測することができる。この範囲が、測定値可能範囲ＴＲｉとなる。
【００６４】
図３（Ｂ）に、アクセスネットワークテーブル１１５ｔの構成を示す。同図によれば、送信元ＩＰアドレスにおける所定のアドレス範囲ＡＲｋ毎に、アクセスネットワーク種別ＮＷｋが予め登録されている。
【００６５】
一般に、アクセスネットワーク種別ＮＷｋは、それぞれに固有のＩＰアドレス範囲を有する。ここで、図１に示したアクセスネットワーク３０〜３２の種別をそれぞれ、
アクセスネットワーク３０：光ファイバ網、ＡＤＳＬ等の固定系ネットワーク
アクセスネットワーク３１：３Ｇ、及び
アクセスネットワーク３２：Ｗｉ−Ｆｉ（登録商標）等の無線ＬＡＮ
とすると、アクセスネットワーク３０〜３２は互いに異なる種別であり、それぞれ固有のＩＰアドレス範囲を有する。従って、収集したＤＮＳクエリの送信元ＩＰアドレスにおける所定のアドレス範囲ＡＲｋ毎に、１つのアクセスネットワークが対応するように設定可能となる。
【００６６】
尚、アクセスネットワーク種別としては、他に、ＷｉＭＡＸ、ＬＴＥ等が挙げられる。また、ＩＳＰ毎に異なるアクセスネットワーク種別として識別することも可能である。
【００６７】
［装置機能構成］
図４は、本発明による端末情報推定装置１の一実施形態を示す機能構成図である。
【００６８】
図４に示すように、端末情報推定装置１は、通信インタフェース１００と、出力部１０１と、クエリ収集部１１０と、ソフトウェア種別識別部１１１と、照会名登録部１１２と、共存種別登録部１１３と、ＴＴＬ範囲登録部１１４と、ネットワーク種別登録部１１５と、共存種別判定部１１６と、総数推定部１１７と、ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８とを有する。端末情報推定装置１は、例えばパーソナルコンピュータやサーバのようなものであって、この装置１に搭載されたコンピュータを機能させるプログラムを実行することによって、端末情報の推定に係る機能が実現される。
【００６９】
通信インタフェース１００は、リピータハブ（又はミラーリングハブ）６を介して、ＤＮＳサーバ５宛のパケットを全て受け取る入力部の役割を果たす。クエリ収集部１１０は、通信インタフェース１００を介して入力したパケットのうち、ＤＮＳサーバ５宛のＤＮＳクエリを識別して収集し、蓄積する。
【００７０】
ソフトウェア種別識別部１１１は、蓄積された各ＤＮＳクエリに含まれる照会名Ｎｄを抽出し、照会名テーブル１１２ｔ（図２（Ａ）及び（Ｂ））を有する照会名登録部１１２を用いてこのＤＮＳクエリに対応するソフトウェア種別を識別する。
【００７１】
ソフトウェア種別識別部１１１は、照会名抽出部１１１ｑと、ＯＳ種別識別部１１１ｓと、ＡＰ種別識別部１１１ａと、クエリ数カウント部１１１ｃと、ＩＰアドレス抽出部１１１ｄと、ネットワーク種別識別部１１１ｎとを有する。
【００７２】
照会名抽出部１１１ｑは、蓄積された各ＤＮＳクエリに含まれる照会名Ｎｄを抽出する。ＯＳ種別識別部１１１ｓは、照会名登録部１１２を用いてＯＳ種別ＯＳｉを識別する。ＡＰ種別識別部１１１ａは、照会名登録部１１２を用いてアプリケーション種別ＡＰｊを識別する。クエリ数カウント部１１１ｃは、ソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）毎に、所定の収集期間Δｔ内に収集された、このソフトウェア種別に対応するＤＮＳクエリの数をカウントする。
【００７３】
ＩＰアドレス抽出部１１１ｄは、識別対象となるＤＮＳクエリに含まれる送信元ＩＰアドレスを抽出する。また、ネットワーク種別識別部１１１ｎは、アクセスネットワークテーブル１１５ｔ（図３（Ｂ））を有するネットワーク種別登録部１１５を用いて、このＤＮＳクエリの送信元ＩＰアドレスからアクセスネットワーク種別ＮＷｋを識別する。
【００７４】
照会名登録部１１２は、照会名テーブル１１２ｔを有しており、照会名Ｎｄ毎に、識別され得るソフトウェア種別（ＯＳｉ及びＡＰｊ）を予め登録する。共存種別登録部１１３は、共存可能ソフトウェアテーブル１１３ｔ（図２（Ｃ））を有しており、１つの端末２内で共存可能な複数のソフトウェア種別の組合せを登録する。
【００７５】
ＴＴＬ範囲登録部１１４は、ＴＴＬテーブル１１４ｔ（図３（Ａ））を有しており、ＯＳ種別ＯＳｉ毎に、ＩＰのＴＴＬの測定値可能範囲ＴＲｉを予め登録する。ネットワーク種別登録部１１５は、アクセスネットワークテーブル１１５ｔを有しており、送信元ＩＰアドレスにおける所定アドレス範囲ＡＲｋ毎に、アクセスネットワーク種別ＮＷｋを予め登録する。
【００７６】
共存種別判定部１１６は、ＤＮＳクエリの送信元ＩＰアドレス毎に、異なるソフトウェア種別を含む複数のＤＮＳクエリが受信された際に、これら異なるソフトウェア種別が共存し得る関係にあるか否かを判定する。ここで、共存種別判定部１１６は、この判定を行うため、共存可能ソフトウェアテーブル１１３ｔを有する共存種別登録部１１３を用いる。さらに、共存種別判定部１１６は、送信元ＩＰアドレス毎に、識別されたソフトウェア種別（ＯＳ種別ＯＳｉ又はアプリケーション種別ＡＰｊ）を記憶するソフトウェア種別記録部１１６ｓを有している。
【００７７】
総数推定部１１７は、端末２に搭載されたソフトウェア種別（ＯＳｉ及びＡＰｊ）毎の総数を推定する。具体的には、ＯＳ総数推定部１１７ｓと、アプリケーション総数推定部１１７ａとを有する。ＯＳ総数推定部１１７ｓは、ＯＳ種別ＯＳｉ毎に、照会名テーブル１１２ｔに予め登録された更新確認時間間隔（クエリ発生周期）Ｔｏｓｉと、カウントされたクエリ数とから、このＯＳ種別ＯＳｉの総数、従ってこのＯＳｉを搭載した端末の総数、を算出する。
【００７８】
一方、アプリケーション総数推定部１１７ａは、アプリケーション種別ＡＰｊ毎に、照会名テーブル１１２ｔに予め登録された更新確認時間間隔（クエリ発生周期）Ｔｏｓｉと、カウントされたクエリ数とから、このアプリケーション種別ＡＰｊの総数、従ってこのＡＰｊを搭載した端末の総数を算出する。
【００７９】
さらに、ＯＳ総数推定部１１７ｓは、ネットワーク推定部１１７ｓｎを有することが好ましい。ネットワーク推定部１１７ｓｎは、総数が推定された各ＯＳ種別ＯＳｉにおける、端末２が接続された各アクセスネットワーク種別ＮＷｋの数（又は割合）を推定する。また、アプリケーション総数推定部１１７ａも、ネットワーク推定部１１７ａｎを有することが好ましい。ネットワーク推定部１１７ａｎは、総数が推定された各アプリケーション種別ＡＰｉにおける、端末２が接続された各アクセスネットワーク種別ＮＷｋの数（又は割合）を推定する。
【００８０】
ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８は、総数推定部１１７で推定されたソフトウェア種別（ＯＳｉ及びＡＰｊ）毎の総数と、各ソフトウェア種別における、端末２が接続された各アクセスネットワーク種別ＮＷｋの数（又は割合）とを蓄積し、取り纏めて、ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔを作成する。ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔの構成は、後に図８を用いて説明される。
【００８１】
出力部１０１は、ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８で形成されたＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔを受け取り、この内容をディスプレイ表示し、紙等の媒体として出力し、又はデータとして外部装置に出力する。
【００８２】
図５は、本発明によるＤＮＳサーバ１’の一実施形態を示す機能構成図である。
【００８３】
図５によれば、ＤＮＳサーバ１’は、ＩＭＳ４内に設けられており、ＤＮＳサーバとしての名前解決機能を有すると共に、アクセスネットワーク３０〜３２に接続される多数の端末２における、搭載されたソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）を識別し、さらに各種別の総数を推定する。
【００８４】
ＤＮＳサーバ１’は、通信インタフェース１００’と、出力部１０１’と、端末情報推定部１１’と、名前解決機能部１２’とを有する。ここで、端末情報推定部１１’は、ソフトウェア種別識別部１１１’と、共存種別判定部１１６’と、総数推定部１１７’と、ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８’とを有しており、図４で説明された端末情報推定装置１と同様の機能を果たす。
【００８５】
［端末情報推定方法］
図６は、本発明の端末情報推定方法のうち、端末２に搭載されたソフトウェア種別の識別方法の一実施形態を示すフローチャートである。
【００８６】
（Ｓ６００）最初に、照会名Ｎｄ毎に、
ＯＳ種別｛ＯＳ１，ＯＳ２，・・・，ＯＳｉ，・・・，ＯＳｏｓ｝、及び
アプリケーション種別｛ＡＰ１，ＡＰ２，・・・，ＡＰｊ，・・・ＡＰａｐ｝
を予め登録する。
【００８７】
（Ｓ６０１）ＯＳ種別ＯＳｉ毎に、ＴＴＬの測定値可能範囲ＴＲｉを予め登録する。
（Ｓ６０２）所定アドレス範囲ＡＲｋ毎に、
アクセスネットワーク種別｛ＮＷ１，ＮＷ２，・・・，ＮＷｋ，・・・，ＮＷｎｗ｝
を予め登録する。
【００８８】
（Ｓ６０３）ＯＳ種別ＯＳｉのカウント数ｎｏｓｉの初期値、アプリケーション種別ＡＰｊのカウント数ｎａｐｊの初期値、及びアクセスネットワーク種別ＮＷｋのカウント数ｎ（ＳＷ）ｎｗｋの初期値をそれぞれゼロとする。
ｎｏｓｉ＝０（ｉ＝１，２，・・・，ｏｓ）
ｎａｐｊ＝０（ｊ＝１，２，・・・，ｓｐ）、及び
ｎ（ＳＷ）ｎｗｋ＝０（ｋ＝１，２，・・・，ｎｗ）
ここで、ＳＷは、ソフトウェア種別（ＯＳｉ及びＡＰｊ）であり、ｎ（ＳＷ）ｎｗｋは、ＯＳｉ及びＡＰｊの各々について、ｋ＝１からｋ＝ｎｗまでに対応した値を有する。
【００８９】
（Ｓ６１０）収集したＤＮＳクエリを解析しつつＤＮＳクエリ数をカウントするループを開始する。最初に、時刻ｔ０＝０とし、ＤＮＳクエリの所定の収集期間Δｔ（分）とする。
（Ｓ６１１）ＤＮＳサーバ５宛のパケットを収集する。
（Ｓ６１２）収集したパケットが、ＯＳ又はアプリケーションの更新確認の為のＤＮＳクエリであるか否かを判定する。
【００９０】
（Ｓ６２０）ステップＳ６１２において、収集したパケットがＯＳ更新確認の為のＤＮＳクエリであるとの判定がなされた際、このクエリに含まれる照会名Ｎｄから、照会名テーブル１１２ｔを用いて、ＯＳ種別をＯＳｉと識別する。一方、ステップＳ６１２で偽の判定、即ち更新確認の為のＤＮＳクエリではないとの判定がなされた際、ステップＳ６４３に移行し、カウント時間（ｔ−ｔ０）を確認しつつ、クエリ数カウントループを繰り返す。
【００９１】
尚、Ｓ６２０において、照会名テーブル１１２ｔを用いてもＯＳ種別を識別できない場合、ＯＳ種別は未知として、ステップＳ６４３に移行することも好ましい。
【００９２】
（Ｓ６２１）このＤＮＳクエリのＩＰヘッダにおけるＴＴＬ値を測定する。
（Ｓ６２２）測定されたＴＴＬ値が、ＴＴＬテーブル１１４ｔに登録された、識別されたＯＳ種別ＯＳｉに対応するＴＴＬ測定値可能範囲ＴＲｉに含まれるか否かを判定する。ここで、偽の判定がなされた際、ステップＳ６４３に移行し、カウント時間（ｔ−ｔ０）を確認しつつ、クエリ数カウントループを繰り返す。
【００９３】
（Ｓ６２３）ステップＳ６２２で真の判定がなされた際、このＯＳ種別ＯＳｉを識別したものとする。次いで、このＯＳ種別ＯＳｉが、同一の送信元ＩＰアドレスを含む他のＤＮＳクエリの照会名Ｎｄから識別されたアプリケーション種別ＡＰｊと、１つの端末２内で共存し得るか否かを判定する。
【００９４】
尚、アクセスネットワーク３０〜３２の構成として、端末２側に、１つのＩＰアドレスを複数の端末で共有可能なＮＡＴ（Network Address Translation）が設置されている場合、同一の送信元ＩＰアドレスのパケットが同一の端末２から発信されたものと断定することはできない。実際、（更新確認時間間隔（クエリ発生周期）Ｔｏｓｉよりも十分に小さい）所定の収集期間Δｔ内に、１つのＩＰアドレスから複数のＯＳ更新確認の為のＤＮＳクエリが収集された場合、このＩＰアドレスは複数の端末２に対して使用されている、と判断される。
【００９５】
このような場合、ステップＳ６２３での判定条件を緩和するか、又はステップＳ６２３を省略することが好ましい。緩和された判定条件としては、例えば、１つのＩＰアドレスにおけるＯＳ更新確認の為のＤＮＳクエリの数が、所定の閾値以下であるか否か、とすることが可能である。また、ＯＳ種別ＯＳｉとアプリケーション種別ＡＰｊとの間では、全て共存可能であると判断する、とすることも可能である。
【００９６】
（Ｓ６２４）ステップＳ６２３で真の判定がなされた際、ＯＳ種別ＯＳｉのカウント数ｎｏｓｉを１だけ増加させる。
ｎｏｓｉ＝ｎｏｓｉ＋１
一方、ステップＳ６２３で偽の判定がなされた際、ステップＳ６４３に移行し、カウント時間（ｔ−ｔ０）を確認しつつ、クエリ数カウントループを繰り返す。
【００９７】
（Ｓ６３０）ステップＳ６１２において、収集したパケットがアプリケーション更新確認の為のクエリであるとの判定がなされた際、ＤＮＳクエリに含まれる照会名Ｎｄから、照会名テーブル１１２ｔを用いて、アプリケーション種別をＡＰｉと識別する。
【００９８】
尚、Ｓ６３０において、照会名テーブル１１２ｔを用いてもアプリケーション種別を識別できない場合、アプリケーション種別は未知として、ステップＳ６４３に移行することも好ましい。
【００９９】
（Ｓ６３１）識別されたアプリケーション種別ＡＰｊが、同一の送信元ＩＰアドレスを含む他のＤＮＳクエリの照会名Ｎｄから識別されたＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊと、１つの端末２内で共存し得るか否かを判定する。
【０１００】
尚、端末２側に、１つのＩＰアドレスを複数の端末で共有可能なＮＡＴが設置されている場合に、ステップＳ６３１での判定条件を緩和するか、又はステップＳ６３１を省略することが好ましいことは、ステップＳ６２３と同様である。
【０１０１】
（Ｓ６３２）ステップＳ６３１で真の判定がなされた際、アプリケーション種別ＡＰｊのカウント数ｎａｐｊを１だけ増加させる。
ｎａｐｊ＝ｎａｐｊ＋１
一方、ステップＳ６３２で偽の判定がなされた際、ステップＳ６４３に移行し、カウント時間（ｔ−ｔ０）を確認しつつ、クエリ数カウントループを繰り返す。
【０１０２】
（Ｓ６４０）送信元ＩＰアドレス毎に、識別されたソフトウェア種別（ＯＳ種別ＯＳｉ又はアプリケーション種別ＡＰｊ）を記録する。
【０１０３】
（Ｓ６４１）識別対象であるＤＮＳクエリのＩＰアドレス値から、アクセスネットワークテーブル１１５ｔを用いて、アクセスネットワーク種別をＮＷｋと識別する。
（Ｓ６４２）アクセスネットワーク種別ＮＷｋのカウント数ｎ（ＳＷ）ｎｗｋを１だけ増加させる。
ｎ（ＳＷ）ｎｗｋ＝ｎ（ＳＷ）ｎｗｋ＋１
ここで、ＳＷは、この識別対象であるＤＮＳクエリにおいて識別されたＯＳ種別ＯＳｉ又はアプリケーション種別ＡＰｉであり、カウント数ｎ（ＳＷ）ｎｗｋは、ＯＳｉ又はＡＰｊ毎の値となる。
【０１０４】
（Ｓ６４３）ステップＳ６１０の開始からの時間（ｔ−ｔ０）を計測し、予め設定された所定の収集期間Δｔ（分）未満であれば、ステップＳ６１０に戻って、クエリ数カウントループを繰り返す。一方、（ｔ−ｔ０）≧Δｔであれば、クエリ数カウントループを終了する。
【０１０５】
（Ｓ６５０）ＯＳ種別毎のクエリ数
｛ｎｏｓ１，ｎｏｓ２，・・・，ｎｏｓｉ，・・・，ｎｏｓｏｓ｝、
アプリケーション種別毎のクエリ数
｛ｎａｐ１，ｎａｐ２，・・・，ｎａｐｊ，・・・，ｎａｐａｐ｝、及び
ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊの各々における各アクセスネットワーク種別ＮＷｋのクエリ数
ｎ（ＳＷ）ｎｗｋ（ｋ＝１，２，・・・，ｎｗ）
を蓄積する。
【０１０６】
尚、以上に説明したアプリケーション種別の識別方法のうち、ＴＴＬに関するステップＳ６２１及びステップＳ６２２は、省略することができる。また、ソフトウェア種別の共存判断に関するステップＳ６２３、ステップＳ６３１及びステップＳ６４０も省略可能である。但し、これらのステップを採用することによって、アプリケーション種別をより高い確度で識別することができる。
【０１０７】
実際、照会名Ｎｄに表れるソフトウェア種別の特徴は、端末の改造等によって改変される可能性がゼロではない。従って、端末２のアプリケーション種別情報の取得・推定においては、ＴＴＬ情報及び共存可能情報も考慮し、さらに以下に説明する統計手法を取り入れて、総合的な判断を行うことが好ましい。
【０１０８】
図７は、本発明の端末情報推定方法のうち、端末２に搭載されたソフトウェア種別の総数を推定する方法の一実施形態を示すフローチャートである。
【０１０９】
尚、以下に示す方法は、ステップＳ６５０（図６）で蓄積された、ＯＳ種別ＯＳｉ毎のクエリ数ｎｏｓｉ、アプリケーション種別ＡＰｊ毎のクエリ数ｎａｐｊ、及び各ソフトウェア種別（ＯＳｉ及びＡＰｊ）における各アクセスネットワーク種別ＮＷｋのクエリ数ｎ（ＳＷ）ｎｗｋの情報を用いて実施される。
【０１１０】
（Ｓ７００）ソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）毎に、更新確認時間間隔（クエリ発生周期）Ｔｏｓｉ又はＴａｐｊを予め登録する。
【０１１１】
（Ｓ７１０）各ソフトウェア種別（ＯＳｉ及びＡＰｊ）の総数を算出する総数推定ループに入る。
（Ｓ７１１）各ソフトウェア種別（ＯＳｉ及びＡＰｊ）毎に、当該ソフトウェア種別の総数を、
（１）  Ｎｏｓｉ＝ｎｏｓｉ・（６０・Ｔｏｓｉ／Δｔ）
（２）  Ｎａｐｊ＝ｎａｐｊ・（６０・Ｔａｐｊ／Δｔ）
として算出する。ここで、Ｔｏｓｉ（時間）及びＴａｐｊ（時間）は、更新確認時間間隔（クエリ発生周期）であり、ｎｏｓｉ（個）及びＴａｐｊ（個）は、所定の収集期間Δｔ（分）内にカウントされたクエリ数である。
【０１１２】
例えば、Apple社のiOSでは、更新確認時間間隔（クエリ発生周期）Ｔｏｓｉ＝１２（時間）である。ここで、Δｔ＝１０（分間）に、iOSの更新確認先であるiphone-ld.apple.comを照会先ＮｄとしたＤＮＳクエリのカウント数が、ｎ＝１００（回）であったとすると、iOSの総数（従ってiOSを搭載した端末の総数）Ｎは、
Ｎ＝１００×（６０×１２／１０）＝７２００
となる。即ち、ＤＮＳサーバ５（又は１’）が設置されたＩＭＳ４のコントロール下にあるアクセスネットワーク３０〜３２に接続された端末数は、７２００台であると推定される。
【０１１３】
因みに、ここで推定される端末数は、アクセスネットワーク３０〜３２に接続される端末２のうち、電源がＯＮ状態であって通信機能が起動した状態のものを対象にした数である。
【０１１４】
（Ｓ７１２）各ソフトウェア種別ＳＷ（ＯＳｉ及びＡＰｊ）における、アクセスネットワーク種別ＮＷｋの数を、
Ｎ（ＯＳｉ）ｎｗｋ＝Ｎｏｓｉ・（ｎ（ＯＳｉ）ｎｗｋ／Σｎ（ＯＳｉ）ｎｗｍ）
Ｎ（ＡＰｊ）ｎｗｋ＝Ｎａｐｊ・（ｎ（ＡＰｊ）ｎｗｋ／Σｎ（ＡＰｊ）ｎｗｍ）
として算出する。ここで、Σｎ（ＯＳｉ）ｎｗｍ及びΣｎ（ＡＰｊ）ｎｗｍはそれぞれ、当該ソフトウェア種別（ＯＳｉ及びＡＰｊ）における、アクセスネットワーク種別ＮＷｍのクエリ数ｎ（ＯＳｉ）ｎｗｍ及びｎ（ＡＰｊ）ｎｗｍの総和である。
【０１１５】
（Ｓ７１３）識別された全てのソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｉ）について総数を推定するまで、ステップＳ７１０〜Ｓ７１３を繰り返す。
【０１１６】
（Ｓ７２０）ＯＳ種別毎の総数
｛Ｎｏｓ１，Ｎｏｓ２，・・・，Ｎｏｓｉ，・・・，Ｎｏｓｏｓ｝、
アプリケーション種別毎の総数
｛Ｎａｐ１，Ｎａｐ２，・・・，Ｎａｐｊ，・・・，Ｎａｐａｐ｝、及び
ソフトウェア種別ＳＷ（ＯＳｉ及びＡＰｊ）の各々における、各アクセスネットワーク種別ＮＷｋの数
Ｎ（ＳＷ）ｎｗｋ（ｋ＝１，２，・・・，ｎｗ）
を蓄積する。
【０１１７】
（Ｓ７２１）ステップＳ７２０で蓄積されたデータを表示又は出力する。
【０１１８】
［照会名テーブル：他の実施形態］
図８は、照会名テーブルにおける他の実施形態の構成図である。
【０１１９】
既に述べたように、各ソフトウェア種別に係るＤＮＳクエリのクエリ発生周期には、変動（不規則性）が生じ得る。以下に説明する照会名テーブル１１２ｔ’及び１１２ｔ’’は、このような変動が発生する確率を考慮しており、端末数（ソフトウェア数）の推定の精度を、より向上させることを可能にする。
【０１２０】
図８（Ａ）に、照会名テーブル１１２ｔ’のＯＳ種別対応部分を示す。同図によれば、ＤＮＳクエリに含まれる照会名Ｎｄ毎に、
ａ）対応するＯＳ種別ＯＳｉと、  ｂ）クエリ発生周期Ｔｄと、
ｃ）確率ｐＯｄ,Ｔｄと、  ｄ）クエリ発生頻度分布と
が予め登録されている。
【０１２１】
ここで、照会名Ｎｄは、端末２に搭載されたＯＳが更新確認の際に接続する接続先のドメイン名である。ＯＳ種別ＯＳｉは、更新確認又はその他の動作の際にこの照会名Ｎｄのサイトに接続を試みるＯＳ種別である。また、クエリ発生周期Ｔｄは、ＯＳ種別ＯＳｉが更新確認又はその他の動作のため、照会名Ｎｄに接続を試みる、ＯＳ種別ＯＳｉ固有の時間間隔である。
【０１２２】
さらに、確率ｐＯｄ,Ｔｄは、ＯＳ種別ＯＳｉに係るＤＮＳクエリが周期Ｔｄより長い時間間隔で発生する確率である。また、クエリ発生頻度分布は、各区間内の時間間隔の中で、ＯＳ種別ＯＳｉに係るＤＮＳクエリが発生した回数（頻度）の記録値である。このクエリ発生頻度分布は、例えば累積頻度分布、又は確率分布の形で登録されていてもよい。
【０１２３】
尚、照会名テーブル１１２ｔ’は、ＯＳ種別対応部分だけでなく、アプリケーション種別対応部分を有していてもよく、このＡＰ種別対応部分においても、各アプリケーション種別ＡＰｊに係る同様の項目が記録される。
【０１２４】
図８（Ｂ）に、照会名テーブル１１２ｔ’’のＯＳ種別対応部分を示す。同図によれば、ＤＮＳクエリに含まれる照会名Ｎｄ毎に、
ａ）対応するＯＳ種別ＯＳｉと、  ｂ）クエリ発生周期Ｔｄと、
ｃ）確率ｐＯｄ,Ｔｄと、  ｄ）確率ｐＬｄ,Ｔｑ、及び平均値μＬｄ,Ｔｑと
が予め登録されている。
【０１２５】
ここで、確率ｐＬｄ,Ｔｑは、ＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ以内の時間間隔で発生する確率である。また、平均値μＬｄ,Ｔｑは、同一の送信元（同一のＩＰアドレス）からのＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ内に発生する回数の平均値である。これら確率ｐＬｄ,Ｔｑ及び平均値μＬｄ,Ｔｑは、クエリ発生頻度分布の測定値から算出される。
【０１２６】
尚、照会名テーブル１１２ｔ’’も、ＯＳ種別対応部分だけでなく、アプリケーション種別対応部分を有していてもよく、このＡＰ種別対応部分においても、各アプリケーション種別ＡＰｊに係る同様の項目が記録される。
【０１２７】
このように、照会名テーブル１１２ｔ’’は、照会名テーブル１１２ｔ’に対し、平均値μＬｄ,Ｔｑ情報を更に付加したテーブルとなっている。
【０１２８】
［照会名テーブル生成装置］
これらの照会名テーブル１１２ｔ’（図８（Ａ））及び照会名テーブル１１２ｔ’’（図８（Ｂ））の生成は、照会名テーブル生成装置８（図１）を用いて行うことができる。
【０１２９】
図１によれば、照会名テーブル生成装置８は、照会名テーブルを生成し、生成した照会名デーブルを端末情報推定装置１に送信する装置である。照会名テーブル生成装置８は、例えば、自身に接続された複数の端末９による、いずれかのアクセスネットワーク（図１ではアクセスネットワーク３０）を介した通信を仲介する位置に設置される。次いで、これら複数の端末９から発信されるＤＮＳクエリを解析して照会名テーブルを生成する。
【０１３０】
この際、照会名テーブル生成装置８は、接続された複数の端末９に係る情報（付与されたＩＰ（Internet Protocol）アドレス、端末種別、搭載されたＯＳ種別及びアプリケーション種別等）を予め登録する。次いで、これらの端末９から発信されるＤＮＳクエリを受信し、取得したＤＮＳクエリ毎に、送信元ＩＰアドレス（端末９に付与されたＩＰアドレス）と、照会名Ｎｄと、取得された（発生した）時刻とを対応付けて記録し、各ＩＰアドレス（各（送信元）端末９）における照会名Ｎｄ毎のＤＮＳ発生頻度分布を算出する。この分布における収集期間の区間は、実際にＤＮＳクエリを収集する収集期間及びクエリ発生周期Ｔｄを考慮して決定される。
【０１３１】
このような照会名テーブルを生成するために、端末９は、例えば搭載された１つのＯＳ種別及びアプリケーション種別につき１０〜１００台程度、照会名テーブル生成装置８に接続されることも好ましい。当然に更に多くの端末９を接続することによって、より精度の高い照会名テーブルを生成することも可能となる。また、信頼性の高い照会名テーブルを得るために、端末９は、ＤＮＳクエリが収集される照会名テーブル生成期間中、常時、接続が確立した状態に置かれることも好ましい。
【０１３２】
また、照会名テーブル生成装置８は、例えば２４時間〜数ヶ月間連続して、端末９から発信されたＤＮＳクエリの収集を行って照会名テーブルを生成する。その際、照会名テーブル生成装置８は、ＤＮＳクエリの送信元ＩＰアドレスに対応付けて登録されたソフトウェア種別（ＯＳ種別又はアプリケーション種別）をこのＤＮＳクエリの照会名に対応付けた上で、照会名毎に、ＤＮＳクエリ発生頻度分布を逐次算出し更新する。
【０１３３】
この照会名テーブル生成装置８は、例えば、企業内ネットワークのルータの位置に設置可能である。さらに、照会名テーブル生成装置８は、実際に運用されるネットワークから独立した実験系ネットワークと複数の端末９とを仲介するものであってもよい。いずれにしても、照会名テーブル生成装置８は、複数の端末９全ての端末情報を管理・登録可能な環境に設置される。
【０１３４】
図８（Ａ）及び（Ｂ）に戻って、照会名テーブル１１２ｔ’（１１２ｔ’’）における照会名Ｎｄ毎の確率ｐＯｄ,Ｔｄは、各ＩＰアドレス（（送信元）端末９）における対応するＯＳ種別ＯＳｉに係るＤＮＳクエリが周期Ｔｄより長い時間間隔で発生した回数を、当該ＤＮＳクエリの全発生回数で割ることによって算出することができる。例えば、図８（Ａ）に示した頻度分布が算出された場合、
ｐＯｄ,Ｔｄ＝１５／（６９＋３＋１０＋１８＋１５）＝約０.１３
となる。
【０１３５】
さらに、照会名テーブル１１２ｔ’（１１２ｔ’’）における、照会名Ｎｄ毎の確率ｐＬｄ,Ｔｑは、各ＩＰアドレス（（送信元）端末９）における対応するＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ以内の時間間隔で発生した回数を、当該ＤＮＳクエリの全発生回数で割ることによって算出することができる。例えば、図８（Ａ）に示した頻度分布が算出されており、収集期間Ｔｑが２１６００秒である場合、
ｐＬｄ,Ｔｑ＝６９／（６９＋３＋１０＋１８＋１５）＝０.６０
となる。
【０１３６】
また、照会名テーブル１１２ｔ’’における照会名Ｎｄ毎の平均値μＬｄ,Ｔｑは、各ＩＰアドレス（（送信元）端末９）における対応するＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ内に複数回発生する場合を考慮するための値であり、その発生回数をカウントして、収集期間Ｔｑでの測定毎のカウント値の平均をとることによって算出される。
【０１３７】
［照会名テーブル１１２ｔ’及び１１２ｔ’’を用いた端末数の推定］
次いで、照会名テーブル１１２ｔ’及び１１２ｔ’’を用いた端末数の推定を説明する。
【０１３８】
最初に、照会名テーブル１１２ｔ’（図８（Ａ））を用いて、端末数（ＯＳｉの数）を推定する。端末数（ＯＳｉ数）Ｎは以下の式で算出される。
（３）  Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋ｐＬｄ,Ｔｑ))
ここで、上述したように、ＴｑはＤＮＳクエリの収集期間であり、ｐＯｄ,Ｔｄは、ＯＳ種別ＯＳｉに係るＤＮＳクエリが周期Ｔｄより長い時間間隔で発生する確率であり、ｐＬｄ,Ｔｑは、ＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ以内の時間間隔で発生する確率である。また、Ｎｄ,Ｔｑは、収集期間Ｔｑ内に観測されたＯＳ種別ＯＳｉに係るＤＮＳクエリの数を表す。尚、式（３）の導出は、後に説明する。
【０１３９】
次いで、式（３）を用いて、照会名テーブル１１２ｔ’（図８（Ａ））に基づき、端末数（ＯＳ１数）Ｎを算出する。一例として、ＤＮＳクエリの収集期間Ｔｑを２１６００秒とし、当該収集期間Ｔｑ内に観測されたＯＳ１（照会名：example1.com）のＤＮＳクエリ数Ｎｄ,Ｔｑが４であったとする。照会名テーブル１１２ｔ’より、Ｔｄ＝８６４００秒、ｐＬｄ,Ｔｑ＝０.６０及びｐＯｄ,Ｔｄ＝０.１３となる。これらの値を式（３）に代入して計算することにより、ＯＳがＯＳ１である端末の台数Ｎは、約１２台（Ｎ＝約１１.５）であると推定される。
【０１４０】
この推定数（１２台）は、上述した式（１）に相当するＮ＝Ｎｄ,Ｔｑ・Ｔｄ／Ｔｑから算出される、周期変動を考慮しない推定数である１６台を、クエリ発生周期の変動を考慮して修正した値であり、より精度の高い値となっている。
【０１４１】
次いで、照会名テーブル１１２ｔ’’（図８（Ｂ））を用いて、端末数（ＯＳｉの数）を推定する。端末数（ＯＳｉ数）Ｎは以下の式で算出される。
（４）
Ｎ＝Ｎｄ,Ｔｑ／((Ｔｑ／Ｔｄ)・(１−ｐＯｄ,Ｔｄ)・(１＋(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ))
ここで、上述したように、平均値μＬｄ,Ｔｑは、同一の送信元（同一のＩＰアドレス）からのＯＳ種別ＯＳｉに係るＤＮＳクエリが収集期間Ｔｑ内に発生する回数の平均値である。尚、式（４）の導出も、後に説明する。
【０１４２】
次いで、式（４）を用いて、照会名テーブル１１２ｔ’’（図８（Ｂ））に基づき、端末数（ＯＳ１数）Ｎを算出する。一例として、ＤＮＳクエリの収集期間Ｔｑを２１６００秒とし、当該収集期間Ｔｑ内に観測されたＯＳ１（照会名：example1.com）のＤＮＳクエリ数Ｎｄ,Ｔｑが４であったとする。照会名テーブル１１２ｔ’’より、Ｔｄ＝８６４００秒、ｐＬｄ,Ｔｑ＝０.６０、ｐＯｄ,Ｔｄ＝０.１３、及びμＬｄ,Ｔｑ＝２.０５となる。これらの値を式（４）に代入して計算することにより、ＯＳがＯＳ１である端末の台数Ｎは約１１台（Ｎ＝約１１.３）であると推定される。
【０１４３】
この推定数（１１台）は、上記の式（３）を用いて算出した推定数である１２台を、平均値μＬｄ,Ｔｑを考慮して更に修正した、より精度の高い値となっている。
【０１４４】
以上、クエリ発生周期において変動（不規則性）が生じる確率ｐＯｄ,Ｔｄ及びｐＬｄ,Ｔｑ)を考慮することによって、より精度の高い端末数（ソフトウェア数）の推定を実施することが可能となる。また、周期変動の程度を表す平均値μＬｄ,Ｔｑを更に考慮することによって、推定精度をより向上させることができる。また、これにより、相当の周期変動を有するＤＮＳクエリであっても、端末数（ソフトウェア数）の推定のために使用することが可能となる。
【０１４５】
尚、上述した端末数Ｎの算出・推定において、複数の照会名テーブル（の欄）を用いて端末数の推定を行ってもよい。例えば概ね全ての端末に搭載された複数のアプリケーション種別それぞれの照会名毎に、照会名テーブルを用いてアプリケーション数を算出し、そのそれぞれのアプリケーション数の平均値を、端末数Ｎとすることも可能である。
【０１４６】
［式（３）及び（４）の導出］
最初に、端末数Ｎを算出するための式（３）の導出を説明する。
【０１４７】
理想的な状況として、ＤＮＳクエリの発生がクエリ発生周期Ｔｄから外れないと想定した場合、ＤＮＳクエリが収集期間Ｔｑ内に発生する確率は、
（５）  ｐｄ,Ｔｑ＝Ｔｑ／Ｔｄ
と表される。よって収集期間Ｔｑに観測されたＤＮＳクエリ数Ｎｄ,Ｔｑは、Ｎｄ,Ｔｑ＝Ｎ・ｐｄ,Ｔｑを満たす。これより端末数Ｎは以下の式で求められる。
（６）  Ｎ＝Ｎｄ,Ｔｑ／ｐｄ,Ｔｑ
【０１４８】
次に、ＤＮＳクエリが収集期間Ｔｑよりも短い時間間隔で観測される場合を考える。この場合、観測されるＤＮＳクエリの中に同一の端末から送信されたＤＮＳクエリが複数含まれる可能性がある。これに対し、式（６）は、観測されるＤＮＳクエリはすべて異なる端末から送信されたものであるという前提の下で端末数Ｎを推定する。従って、式（６）において、ＤＮＳクエリ数Ｎｄ,Ｔｑから送信元の端末が重複している分を除いて、推定の精度をより高くする必要がある。
【０１４９】
ここで、ＤＮＳクエリが収集期間Ｔｑよりも短い時間間隔で観測される確率をｐＬｄ,Ｔｑとすると、収集期間Ｔｑ内に同一の端末から複数のＤＮＳクエリが送信される確率ｐ２ｄ,Ｔｑは、
（７）  ｐ２ｄ,Ｔｑ＝ｐｄ,Ｔｑ・ｐＬｄ,Ｔｑ
となる。よって送信元が重複しているＤＮＳクエリの数Ｎ２ｄ,Ｔｑは、
（８）  Ｎ２ｄ,Ｔｑ＝Ｎ・ｐｄ,Ｔｑ・ｐＬｄ,Ｔｑ
となる。
【０１５０】
従って、端末数Ｎを求める式（６）は、
（９）  Ｎ＝(Ｎｄ,Ｔｑ−Ｎ２ｄ,Ｔｑ)／ｐｄ,Ｔｑ
＝(Ｎｄ,Ｔｑ−Ｎ・ｐｄ,Ｔｑ・ｐＬｄ,Ｔｑ）／ｐｄ,Ｔｑ
のように修正される。その結果、
（１０）  Ｎ＝Ｎｄ,Ｔｑ／(ｐｄ,Ｔｑ・(１＋ｐＬｄ,Ｔｑ))
となる。
【０１５１】
さらに、ＤＮＳクエリがクエリ発生周期Ｔｄよりも長い時間間隔で観測される場合を考える。式（１０）では、全ての端末はクエリ発生周期Ｔｄ内にＤＮＳクエリを送信するという前提の下で収集期間Ｔｑ内にクエリが観測される確率をｐｄ,Ｔｑ＝Ｔｑ／Ｔｄとした。そのため、当該確率に加えて端末が周期Ｔｄ内にＤＮＳクエリを送信する確率を加味する必要がある。
【０１５２】
ここで、ＤＮＳクエリがクエリ発生周期Ｔｄよりも長い時間間隔で発生する確率をｐＯｄ,Ｔｄとすると、端末が収集期間Ｔｑ内にＤＮＳクエリを送信する確率は、ｐｄ,Ｔｑ・(１−ｐＯｄ,Ｔｄ)となる。よって端末数Ｎを求める式（１０）は以下の通りに変更される。
（１１）  Ｎ＝Ｎｄ,Ｔｑ／(ｐｄ,Ｔｑ・(１−ｐＯｄ,Ｔｄ)・(１＋ｐＬｄ,Ｔｑ))
上式（１１）は、式（３）に相当する式となる。
【０１５３】
さらに、上述したＤＮＳクエリが収集期間Ｔｄよりも短い時間間隔で発生する場合において、同一の端末から収集期間Ｔｑ内に送信されるクエリの数をμＬｄ,Ｔｑとすると、送信元が重複しているＤＮＳクエリの数は、
（１２）  Ｎ２ｄ,Ｔｑ＝Ｎ・ｐｄ,Ｔｑ・(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ
となる。よって、端末数Ｎは、
（１３）  Ｎ＝(Ｎｄ,Ｔｑ−Ｎ２ｄ,Ｔｑ)／ｐｄ,Ｔｑ
＝(Ｎｄ,Ｔｑ−Ｎ・ｐｄ,Ｔｑ・(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ）／ｐｄ,Ｔｑ
のように修正される。
【０１５４】
その結果、
（１４）  Ｎ＝Ｎｄ,Ｔｑ／(ｐｄ,Ｔｑ・(１＋(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ))
となる。さらに、式（１４）に、ＤＮＳクエリがクエリ発生周期Ｔｄより長い時間間隔で送信される場合を加味すると、以下の式が得られる。
（１５）  Ｎ＝Ｎｄ,Ｔｑ／(ｐｄ,Ｔｑ・(１−ｐＯｄ,Ｔｄ)・(１＋(μＬｄ,Ｔｑ−１)・ｐＬｄ,Ｔｑ))
上式（１５）は、式（４）に相当する式となる。
【０１５５】
図９は、ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔの構成図である。ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔは、図７のＳ７２０において、ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８（図４）が作成するテーブルである。
【０１５６】
図９よれば、ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔは、ソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）毎に、当該ソフトウェア種別の総数と、当該ソフトウェア種別における各アクセスネットワーク種別ＮＷｋの数とが記載されている。
【０１５７】
これにより、アクセスネットワーク３０〜３２に接続された端末２に搭載された各ＯＳ種別ＯＳｉの総数の推定値、従ってこのＯＳｉを搭載した端末数の推定値、を得ることができる。また、アクセスネットワーク３０〜３２内でのＯＳ種別ＯＳｉの分布を得ることができる。
【０１５８】
また、アクセスネットワーク３０〜３２に接続された端末２に搭載された各アプリケーション種別ＡＰｊの総数の推定値、従ってこのＡＰｊを搭載した端末数の推定値、を得ることができる。また、アクセスネットワーク３０〜３２内でのアプリケーション種別ＡＰｊの分布を得ることができる。
【０１５９】
以上、本発明によれば、照会名Ｎｄを含むＤＮＳクエリを収集・解析することによって、ソフトウェア種別（ＯＳ種別ＯＳｉ及びアプリケーション種別ＡＰｊ）を判定する。その結果、大規模なネットワーク全体におけるソフトウェア種別（ＯＳｉ及びＡＰｊ）を、全通信を取得することなく識別することができる。さらに、識別した各ソフトウェア種別の総数を、全通信を取得することなく推定することができる。
【０１６０】
また、本発明によれば、自らパケットを送信するといった能動的な検査を必要としない。即ち、ソフトウェア種別情報の識別・推定を受動的に実施することができる。その結果、例えば、端末側に設けられたフィルタリング機構によって検査不能となる事態を引き起こすことがない。
【０１６１】
さらに、ＤＮＳクエリを収集する時間Δｔは、更新確認時間間隔（クエリ発生周期）Ｔｏｓｉ及びＴａｐｊに比べて非常に短い時間（例えば１０分）である。従って、本発明によれば、非常に短時間で、各ソフトウェア種別（ＯＳｉ及びＡＰｊ）の総数の推定値を得ることができる。
【０１６２】
また、短時間での総数の推定が可能であるので、あるＯＳ種別における異なる時間帯での総数を比較したり、あるＯＳ種別における各時刻での総数の推移を得たり、さらには、各時刻における異なるＯＳ種別間の総数比を比較したりすることができる。例えば、午前１０時からの１０分間についての、あるＯＳ種別ＯＳｉの総数Ｎ１０と、午後１０時からの１０分間についてのＯＳ種別ＯＳｉの総数Ｎ２２とを推定して比較することが可能となる。
【０１６３】
以上に説明した本発明によって得られる端末情報は、例えば、ネットワーク管理者にとって、ネットワークの安定した運用を維持するために非常に重要となる。即ち、これら端末情報の把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。
【０１６４】
前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。
【符号の説明】
【０１６５】
１  端末情報推定装置
１００、１００’  通信インタフェース
１０１、１０１’  出力部
１１’  端末情報推定部
１１０  クエリ収集部
１１１、１１１’  ソフトウェア種別識別部
１１１ａ  ＡＰ種別識別部
１１１ｃ  クエリ数カウント部
１１１ｄ  ＩＰアドレス抽出部
１１１ｎ  ネットワーク種別識別部
１１１ｑ  照会名抽出部
１１１ｓ  ＯＳ種別識別部
１１２  照会名登録部
１１２ｔ、１１２ｔ’、１１２ｔ’’  照会名テーブル
１１３  共存種別登録部
１１３ｔ  共存可能ソフトウェアテーブル
１１４  ＴＴＬ範囲登録部
１１４ｔ  ＴＴＬテーブル
１１５  ネットワーク種別登録部
１１５ｔ  アクセスネットワークテーブル
１１６、１１６’  共存種別判定部
１１７、１１７’  総数推定部
１１７ａ  アプリケーション総数推定部
１１７ｓ  ＯＳ総数推定部
１１８、１１８’  ＯＳ・ＡＰ・ＮＷ分布蓄積部
１１８ｔ  ＯＳ・ＡＰ・ＮＷ分布テーブル
１２’  名前解決機能部
２、９  端末
３０、３１、３２  アクセスネットワーク
４  ＩＭＳ
５  ＤＮＳサーバ
６  ネットワークタップ
７  インターネット
８  照会名テーブル生成装置
【図１】
0005868827.tif 000002
【図２】
0005868827.tif 000003
【図３】
0005868827.tif 000004
【図４】
0005868827.tif 000005
【図５】
0005868827.tif 000006
【図６】
0005868827.tif 000007
【図７】
0005868827.tif 000008
【図８】
0005868827.tif 000009
【図９】
0005868827.tif 000010