JP5868827B2 - 端末のソフトウェア種別情報を推定する端末情報推定装置、ｄｎｓサーバ、プログラム及び方法 - Google Patents

Description

本発明は、複数の端末が接続されたネットワークの管理・監視の技術に関する。

ネットワーク管理者は、ネットワークの安定した運用を維持するため、ネットワーク利用者の利用環境及び利用状況を把握しなければならない。この把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。

しかしながら、ネットワーク管理者が利用者の利用実態を十分に把握することは一般に困難である。例えば、インターネット接続業者（ＩＳＰ：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）のＤＮＳクエリ数Ｎ_ｄ,Ｔｑが４であったとする。照会名テーブル１１２ｔ’’より、Ｔ_ｄ＝８６４００秒、ｐ^Ｌ _ｄ,Ｔｑ＝０.６０、ｐ^Ｏ _ｄ,Ｔｄ＝０.１３、及びμ^Ｌ _ｄ,Ｔｑ＝２.０５となる。これらの値を式（４）に代入して計算することにより、ＯＳがＯＳ１である端末の台数Ｎは約１１台（Ｎ＝約１１.３）であると推定される。

この推定数（１１台）は、上記の式（３）を用いて算出した推定数である１２台を、平均値μ^Ｌ _ｄ,Ｔｑを考慮して更に修正した、より精度の高い値となっている。

以上、クエリ発生周期において変動（不規則性）が生じる確率ｐ^Ｏ _ｄ,Ｔｄ及びｐ^Ｌ _ｄ,Ｔｑ)を考慮することによって、より精度の高い端末数（ソフトウェア数）の推定を実施することが可能となる。また、周期変動の程度を表す平均値μ^Ｌ _ｄ,Ｔｑを更に考慮することによって、推定精度をより向上させることができる。また、これにより、相当の周期変動を有するＤＮＳクエリであっても、端末数（ソフトウェア数）の推定のために使用することが可能となる。

尚、上述した端末数Ｎの算出・推定において、複数の照会名テーブル（の欄）を用いて端末数の推定を行ってもよい。例えば概ね全ての端末に搭載された複数のアプリケーション種別それぞれの照会名毎に、照会名テーブルを用いてアプリケーション数を算出し、そのそれぞれのアプリケーション数の平均値を、端末数Ｎとすることも可能である。

［式（３）及び（４）の導出］
最初に、端末数Ｎを算出するための式（３）の導出を説明する。

理想的な状況として、ＤＮＳクエリの発生がクエリ発生周期Ｔ_ｄから外れないと想定した場合、ＤＮＳクエリが収集期間Ｔ_ｑ内に発生する確率は、
（５） ｐ_ｄ,Ｔｑ＝Ｔ_ｑ／Ｔ_ｄ
と表される。よって収集期間Ｔ_ｑに観測されたＤＮＳクエリ数Ｎ_ｄ,Ｔｑは、Ｎ_ｄ,Ｔｑ＝Ｎ・ｐ_ｄ,Ｔｑを満たす。これより端末数Ｎは以下の式で求められる。
（６） Ｎ＝Ｎ_ｄ,Ｔｑ／ｐ_ｄ,Ｔｑ

次に、ＤＮＳクエリが収集期間Ｔ_ｑよりも短い時間間隔で観測される場合を考える。この場合、観測されるＤＮＳクエリの中に同一の端末から送信されたＤＮＳクエリが複数含まれる可能性がある。これに対し、式（６）は、観測されるＤＮＳクエリはすべて異なる端末から送信されたものであるという前提の下で端末数Ｎを推定する。従って、式（６）において、ＤＮＳクエリ数Ｎ_ｄ,Ｔｑから送信元の端末が重複している分を除いて、推定の精度をより高くする必要がある。

ここで、ＤＮＳクエリが収集期間Ｔ_ｑよりも短い時間間隔で観測される確率をｐ^Ｌ _ｄ,Ｔｑとすると、収集期間Ｔ_ｑ内に同一の端末から複数のＤＮＳクエリが送信される確率ｐ^２ _ｄ,Ｔｑは、
（７） ｐ^２ _ｄ,Ｔｑ＝ｐ_ｄ,Ｔｑ・ｐ^Ｌ _ｄ,Ｔｑ
となる。よって送信元が重複しているＤＮＳクエリの数Ｎ^２ _ｄ,Ｔｑは、
（８） Ｎ^２ _ｄ,Ｔｑ＝Ｎ・ｐ_ｄ,Ｔｑ・ｐ^Ｌ _ｄ,Ｔｑ
となる。

従って、端末数Ｎを求める式（６）は、
（９） Ｎ＝(Ｎ_ｄ,Ｔｑ−Ｎ^２ _ｄ,Ｔｑ)／ｐ_ｄ,Ｔｑ
＝(Ｎ_ｄ,Ｔｑ−Ｎ・ｐ_ｄ,Ｔｑ・ｐ^Ｌ _ｄ,Ｔｑ）／ｐ_ｄ,Ｔｑ
のように修正される。その結果、
（１０） Ｎ＝Ｎ_ｄ,Ｔｑ／(ｐ_ｄ,Ｔｑ・(１＋ｐ^Ｌ _ｄ,Ｔｑ))
となる。

さらに、ＤＮＳクエリがクエリ発生周期Ｔ_ｄよりも長い時間間隔で観測される場合を考える。式（１０）では、全ての端末はクエリ発生周期Ｔ_ｄ内にＤＮＳクエリを送信するという前提の下で収集期間Ｔ_ｑ内にクエリが観測される確率をｐ_ｄ,Ｔｑ＝Ｔ_ｑ／Ｔ_ｄとした。そのため、当該確率に加えて端末が周期Ｔ_ｄ内にＤＮＳクエリを送信する確率を加味する必要がある。

ここで、ＤＮＳクエリがクエリ発生周期Ｔ_ｄよりも長い時間間隔で発生する確率をｐ^Ｏ _ｄ,Ｔｄとすると、端末が収集期間Ｔ_ｑ内にＤＮＳクエリを送信する確率は、ｐ_ｄ,Ｔｑ・(１−ｐ^Ｏ _ｄ,Ｔｄ)となる。よって端末数Ｎを求める式（１０）は以下の通りに変更される。
（１１） Ｎ＝Ｎ_ｄ,Ｔｑ／(ｐ_ｄ,Ｔｑ・(１−ｐ^Ｏ _ｄ,Ｔｄ)・(１＋ｐ^Ｌ _ｄ,Ｔｑ))
上式（１１）は、式（３）に相当する式となる。

さらに、上述したＤＮＳクエリが収集期間Ｔ_ｄよりも短い時間間隔で発生する場合において、同一の端末から収集期間Ｔ_ｑ内に送信されるクエリの数をμ^Ｌ _ｄ,Ｔｑとすると、送信元が重複しているＤＮＳクエリの数は、
（１２） Ｎ^２ _ｄ,Ｔｑ＝Ｎ・ｐ_ｄ,Ｔｑ・(μ^Ｌ _ｄ,Ｔｑ−１)・ｐ^Ｌ _ｄ,Ｔｑ
となる。よって、端末数Ｎは、
（１３） Ｎ＝(Ｎ_ｄ,Ｔｑ−Ｎ^２ _ｄ,Ｔｑ)／ｐ_ｄ,Ｔｑ
＝(Ｎ_ｄ,Ｔｑ−Ｎ・ｐ_ｄ,Ｔｑ・(μ^Ｌ _ｄ,Ｔｑ−１)・ｐ^Ｌ _ｄ,Ｔｑ）／ｐ_ｄ,Ｔｑ
のように修正される。

その結果、
（１４） Ｎ＝Ｎ_ｄ,Ｔｑ／(ｐ_ｄ,Ｔｑ・(１＋(μ^Ｌ _ｄ,Ｔｑ−１)・ｐ^Ｌ _ｄ,Ｔｑ))
となる。さらに、式（１４）に、ＤＮＳクエリがクエリ発生周期Ｔ_ｄより長い時間間隔で送信される場合を加味すると、以下の式が得られる。
（１５） Ｎ＝Ｎ_ｄ,Ｔｑ／(ｐ_ｄ,Ｔｑ・(１−ｐ^Ｏ _ｄ,Ｔｄ)・(１＋(μ^Ｌ _ｄ,Ｔｑ−１)・ｐ^Ｌ _ｄ,Ｔｑ))
上式（１５）は、式（４）に相当する式となる。

図９は、ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔの構成図である。ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔは、図７のＳ７２０において、ＯＳ・ＡＰ・ＮＷ分布蓄積部１１８（図４）が作成するテーブルである。

図９よれば、ＯＳ・ＡＰ・ＮＷ分布テーブル１１８ｔは、ソフトウェア種別（ＯＳ種別ＯＳ_ｉ及びアプリケーション種別ＡＰ_ｊ）毎に、当該ソフトウェア種別の総数と、当該ソフトウェア種別における各アクセスネットワーク種別ＮＷ_ｋの数とが記載されている。

これにより、アクセスネットワーク３０〜３２に接続された端末２に搭載された各ＯＳ種別ＯＳ_ｉの総数の推定値、従ってこのＯＳ_ｉを搭載した端末数の推定値、を得ることができる。また、アクセスネットワーク３０〜３２内でのＯＳ種別ＯＳ_ｉの分布を得ることができる。

また、アクセスネットワーク３０〜３２に接続された端末２に搭載された各アプリケーション種別ＡＰ_ｊの総数の推定値、従ってこのＡＰ_ｊを搭載した端末数の推定値、を得ることができる。また、アクセスネットワーク３０〜３２内でのアプリケーション種別ＡＰ_ｊの分布を得ることができる。

以上、本発明によれば、照会名Ｎ_ｄを含むＤＮＳクエリを収集・解析することによって、ソフトウェア種別（ＯＳ種別ＯＳ_ｉ及びアプリケーション種別ＡＰ_ｊ）を判定する。その結果、大規模なネットワーク全体におけるソフトウェア種別（ＯＳ_ｉ及びＡＰ_ｊ）を、全通信を取得することなく識別することができる。さらに、識別した各ソフトウェア種別の総数を、全通信を取得することなく推定することができる。

また、本発明によれば、自らパケットを送信するといった能動的な検査を必要としない。即ち、ソフトウェア種別情報の識別・推定を受動的に実施することができる。その結果、例えば、端末側に設けられたフィルタリング機構によって検査不能となる事態を引き起こすことがない。

さらに、ＤＮＳクエリを収集する時間Δｔは、更新確認時間間隔（クエリ発生周期）Ｔ_ｏｓｉ及びＴ_ａｐｊに比べて非常に短い時間（例えば１０分）である。従って、本発明によれば、非常に短時間で、各ソフトウェア種別（ＯＳ_ｉ及びＡＰ_ｊ）の総数の推定値を得ることができる。

また、短時間での総数の推定が可能であるので、あるＯＳ種別における異なる時間帯での総数を比較したり、あるＯＳ種別における各時刻での総数の推移を得たり、さらには、各時刻における異なるＯＳ種別間の総数比を比較したりすることができる。例えば、午前１０時からの１０分間についての、あるＯＳ種別ＯＳ_ｉの総数Ｎ_１０と、午後１０時からの１０分間についてのＯＳ種別ＯＳ_ｉの総数Ｎ_２２とを推定して比較することが可能となる。

以上に説明した本発明によって得られる端末情報は、例えば、ネットワーク管理者にとって、ネットワークの安定した運用を維持するために非常に重要となる。即ち、これら端末情報の把握によって、通信障害の原因となる利用者の行為を未然に防止したり、将来の通信量増加の程度を予測し必要な通信設備の増強を図ったりすることが可能となる。

前述した本発明の種々の実施形態について、本発明の技術思想及び見地の範囲の種々の変更、修正及び省略は、当業者によれば容易に行うことができる。前述の説明はあくまで例であって、何ら制約しようとするものではない。本発明は、特許請求の範囲及びその均等物として限定するものにのみ制約される。

１ 端末情報推定装置
１００、１００’ 通信インタフェース
１０１、１０１’ 出力部
１１’ 端末情報推定部
１１０ クエリ収集部
１１１、１１１’ ソフトウェア種別識別部
１１１ａ ＡＰ種別識別部
１１１ｃ クエリ数カウント部
１１１ｄ ＩＰアドレス抽出部
１１１ｎ ネットワーク種別識別部
１１１ｑ 照会名抽出部
１１１ｓ ＯＳ種別識別部
１１２ 照会名登録部
１１２ｔ、１１２ｔ’、１１２ｔ’’ 照会名テーブル
１１３ 共存種別登録部
１１３ｔ 共存可能ソフトウェアテーブル
１１４ ＴＴＬ範囲登録部
１１４ｔ ＴＴＬテーブル
１１５ ネットワーク種別登録部
１１５ｔ アクセスネットワークテーブル
１１６、１１６’ 共存種別判定部
１１７、１１７’ 総数推定部
１１７ａ アプリケーション総数推定部
１１７ｓ ＯＳ総数推定部
１１８、１１８’ ＯＳ・ＡＰ・ＮＷ分布蓄積部
１１８ｔ ＯＳ・ＡＰ・ＮＷ分布テーブル
１２’ 名前解決機能部
２、９ 端末
３０、３１、３２ アクセスネットワーク
４ ＩＭＳ
５ ＤＮＳサーバ
６ ネットワークタップ
７ インターネット
８ 照会名テーブル生成装置

Claims (14)

1. ＤＮＳ（Domain Name System）サーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定装置であって、
   当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
   当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
   蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
   を有することを特徴とする端末情報推定装置。
2. 前記複数の端末に搭載されたソフトウェア種別毎の総数を推定する総数推定手段を更に有しており、
   前記照会名登録手段は、ソフトウェア種別毎にクエリ発生頻度を更に予め登録し、
   前記ソフトウェア種別識別手段は、ソフトウェア種別毎に、所定の収集期間内に収集された、当該ソフトウェア種別に対応するクエリの数をカウントし、
   前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生頻度と、当該所定の収集期間と、カウントされたクエリ数とから当該ソフトウェア種別の総数を算出する
   ことを特徴とする請求項１に記載の端末情報推定装置。
3. 当該ソフトウェア種別毎に、予め登録されたクエリ発生頻度をＴ時間に１回とし、所定の収集期間Δｔ分内にカウントされた、当該ソフトウェア種別に対応するクエリ数をｎ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
   Ｎ＝ｎ・（６０・Ｔ／Δｔ）
   として算出することを特徴とする請求項２に記載の端末情報推定装置。
4. 前記照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、当該クエリ発生周期より長い時間間隔で発生する頻度又は確率とを更に予め登録し、
   前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生周期と、当該所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率とを用いて補正を行うことに相当する計算を行って、当該ソフトウェア種別の総数を算出する
   ことを特徴とする請求項２に記載の端末情報推定装置。
5. 当該ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴ_ｄ秒とし、当該クエリが所定の収集期間Ｔ_ｑ秒以内の時間間隔で発生する確率をｐ^Ｌ _ｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔ_ｄより長い時間間隔で発生する確率をｐ^Ｏ _ｄ,Ｔｄとし、当該所定の収集期間Ｔ_ｑ秒内にカウントされた、当該ソフトウェア種別に対応するクエリ数をＮ_ｄ,Ｔｑ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
   Ｎ＝Ｎ_ｄ,Ｔｑ／((Ｔ_ｑ／Ｔ_ｄ)・(１−ｐ^Ｏ _ｄ,Ｔｄ)・(１＋ｐ^Ｌ _ｄ,Ｔｑ))
   として算出することを特徴とする請求項４に記載の端末情報推定装置。
6. 前記照会名登録手段は、ソフトウェア種別毎に、クエリ発生頻度の逆数に相当するクエリ発生周期と、同一の送信元に係る同一の照会名を含むクエリが、設定された収集期間以内の時間間隔で発生する頻度又は確率と、当該クエリが、クエリ発生周期より長い間隔で発生する頻度又は確率と、当該クエリが設定された収集期間内に発生する回数の平均値とを更に予め登録し、
   前記総数推定手段は、当該ソフトウェア種別毎に、予め登録されたクエリ発生周期と、当該所定の収集期間と、カウントされたクエリ数とを用いて算出される総数値に対し、当該クエリが所定の収集期間以内の時間間隔で発生する確率と、当該クエリがクエリ発生周期より長い時間間隔で発生する確率と、当該クエリが当該所定の収集期間内に発生する回数の平均値とを用いて補正を行うことに相当する計算を行って、当該ソフトウェア種別の総数を算出する
   ことを特徴とする請求項２に記載の端末情報推定装置。
7. 当該ソフトウェア種別毎に、予め登録されたクエリ発生周期をＴ_ｄ秒とし、当該クエリが所定の収集期間Ｔ_ｑ秒以内の時間間隔で発生する確率をｐ^Ｌ _ｄ,Ｔｑとし、当該クエリがクエリ発生周期Ｔ_ｄより長い時間間隔で発生する確率をｐ^Ｏ _ｄ,Ｔｄとし、当該クエリが当該所定の収集期間内に発生する回数の平均値μ^Ｌ _ｄ,Ｔｑをとし、当該所定の収集期間Ｔ_ｑ秒内にカウントされた、当該ソフトウェア種別に対応するクエリ数をＮ_ｄ,Ｔｑ個とすると、前記総数推定手段は、当該ソフトウェア種別の総数Ｎ個を、
   Ｎ＝Ｎ_ｄ,Ｔｑ／((Ｔ_ｑ／Ｔ_ｄ)・(１−ｐ^Ｏ _ｄ,Ｔｄ)・(１＋(μ^Ｌ _ｄ,Ｔｑ−１)・ｐ^Ｌ _ｄ,Ｔｑ))
   として算出することを特徴とする請求項６に記載の端末情報推定装置。
8. １つの端末内で共存可能な複数のソフトウェア種別の組合せを登録する共存種別登録手段と、
   前記クエリの送信元アドレス毎に、異なるソフトウェア種別を含む複数のクエリが受信された際に、前記共存種別登録手段を用いて該異なるソフトウェア種別が共存し得る関係にあるか否かを判定する共存種別判定手段と
   を更に有しており、
   前記ソフトウェア種別識別手段は、前記共存種別判定手段が真の判定を行った際、当該送信元アドレスを含んでおり当該ソフトウェア種別に対応するクエリをカウント対象とする
   ことを特徴とする請求項１から７のいずれか１項に記載の端末情報推定装置。
9. 当該ソフトウェア種別毎に、ＩＰ(Internet Protocol)のＴＴＬ(Time To Live)の測定値可能範囲を予め登録したＴＴＬ範囲登録手段を更に有し、
   前記ソフトウェア種別識別手段は、当該クエリに含まれるＩＰヘッダのＴＴＬの値が、前記ＴＴＬ範囲登録手段に登録された、識別された当該ソフトウェア種別に対応する測定値可能範囲に含まれる場合にのみ、当該ソフトウェア種別を識別したものとする
   ことを特徴とする請求項１から８のいずれか１項に記載の端末情報推定装置。
10. 前記複数の端末の送信元アドレスにおける所定アドレス範囲毎に、アクセスネットワーク種別を予め登録するネットワーク種別登録手段と、
    前記ソフトウェア種別識別手段は、識別対象となるクエリについて、前記ネットワーク種別登録手段を用いて、当該クエリの送信元アドレスからアクセスネットワーク種別を更に識別する
    ことを特徴とする請求項１から９のいずれか１項に記載の端末情報推定装置。
11. 前記ソフトウェア種別は、ＯＳ(Operating System)種別及び／又はアプリケーション種別であり、
    前記照会名は、当該ＯＳ種別及び／又はアプリケーション種別におけるソフトウェア更新確認時の接続先アドレスである
    ことを特徴とする請求項１から１０のいずれか１項に記載の端末情報推定装置。
12. 照会名を含むクエリを発信する複数の端末の情報を推定する機能を搭載したＤＮＳサーバであって、
    当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
    当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
    蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
    を有することを特徴とするＤＮＳサーバ。
13. ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定するようにコンピュータを機能させる端末情報推定プログラムであって、
    当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段と、
    当該端末から発信された当該クエリを収集し蓄積するクエリ収集手段と、
    蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別するソフトウェア種別識別手段と
    してコンピュータを機能させることを特徴とする端末情報推定プログラム。
14. ＤＮＳサーバにネットワークを介して、照会名を含むクエリを発信する複数の端末の情報を推定する端末情報推定方法であって、
    当該照会名毎に、前記複数の端末に搭載されたソフトウェア種別を予め登録する照会名登録手段を用い、
    当該端末から発信された当該クエリを収集し蓄積する第１のステップと、
    蓄積された各クエリに含まれる照会名を抽出し、前記照会名登録手段を用いて当該クエリに対応するソフトウェア種別を識別する第２のステップと
    を有することを特徴とする端末情報推定方法。

Images