(57)【要約】  ピリオドにより分離されたｎ個のラベルを有するドメイン名を解決するために、信頼すべきネームサーバにおいてリクエストを受信することを含むドメイントラフィックを自動的に決定するための方法。最も左のラベルは第１のラベルであり、トップレベルドメインはｎ番目のラベルである。受信したドメイン名の第１のラベルが文字列 「ｗｗｗ」を含む場合には、次に、ドメイン名に関するｗｗｗヒットカウンタおよび／またはｗｗｗリクエストサーバカウンタがインクリメントされる。受信したドメイン名が２つのラベルのみを有する場合には、次に、ドメイン名に関する一致ヒットカウンタおよび／または一致リクエストサーバカウンタがインクリメントされる。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含まない場合、および受信したドメイン名が２つのラベルのみを有しない場合には、次に、ドメイン名に関する別のヒットカウンタおよび／または別のリクエストサーバカウンタがインクリメントされる。
2012523625.tif 000002
【特許請求の範囲】
【請求項１】
ドメイントラフィックを決定するための自動化された方法であって、
ピリオドにより分離されたｎ個のラベルを有するドメイン名を解決するためのリクエストを信頼すべきネームサーバにおいて受信することであって、最も左のラベルが第１のラベルであり、トップレベルドメインがｎ番目のラベルである、受信することと、
前記受信したドメイン名の前記第１のラベルが文字列「ｗｗｗ」を含む場合に、前記ドメイン名に対するｗｗｗカウンタをインクリメントすることと、
前記受信したドメイン名が２つのラベルのみを有する場合には、前記ドメイン名に対する一致カウンタをインクリメントすることと、
前記受信したドメイン名の前記第１のラベルが文字列「ｗｗｗ」を含まず、かつ前記受信したドメイン名が２つのラベルのみを有しない場合には、前記ドメイン名に対する他のカウンタをインクリメントすることと、
複数の前記カウンタに基づいてドメイントラフィックスコアを算出することと、を含み、
前記ドメイントラフィックスコアを算出することは、前記カウンタのうちの少なくとも１つに重み係数を適用することを含む、方法。
【請求項２】
前記カウンタは、所定期間あたり１カウントの制限を有する、請求項１に記載の方法。
【請求項３】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクを料金サービスの一部としてユーザに提供することと、をさらに含む、請求項１に記載の方法。
【請求項４】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクに基づいて前記ドメインに対する広告価値を算出することと、
前記広告価値をリクエストに応じてユーザに提供することと、をさらに含む、請求項１に記載の方法。
【請求項５】
前記ドメイントラフィックスコアを算出することは、
次式に従って、前記カウンタの各々の平均の日毎の割合を算出することであって、
【数１】
2012523625.tif 000008
【数２】
2012523625.tif 000009
【数３】
2012523625.tif 000010
ここで、Ｗは前記ｗｗｗカウンタであり、Ｅは前記一致カウンタであり、Ｏは前記他のカウンタであり、Ｄは前記ドメインであり、Ｐは期間（｜Ｐ｜は１日のうちの期間の長さ）であり、ＳＷ（ＡＬＬ，Ｄａｙｉ）、ＳＥ（ＡＬＬ，Ｄａｙｉ）、およびＳＯ（ＡＬＬ，Ｄａｙｉ）は、前記信頼すべきネームサーバにおいて、各々、Ｗ、Ｅ、およびＯをクエリする別個のリゾルバの組の全体数である、算出することと、
次式に従って、前記所定期間内の前記ドメインに対する全体スコアを算出することであって、
【数４】
2012523625.tif 000011
ここで、ＷＷ／Ｅ／Ｏはそれぞれ、各標的タイプＷ、Ｅ、および０の前記重みである、算出することとを含む、請求項１に記載の方法。
【請求項６】
ＷＷ＝１、ＷＥ＝０．５、およびＷＯ＝０．２である、請求項５に記載の方法。
【請求項７】
ドメイントラフィックを決定するための自動化された方法であって、
ピリオドにより分離されたｎ個のラベルを有するドメイン名を解決するためのリクエストを信頼すべきネームサーバにおいて受信することであって、最も左のラベルが第１のラベルであり、トップレベルドメインがｎ番目のラベルである、受信することと、
前記受信したドメイン名の前記第１のラベルが文字列「ｗｗｗ」を含む場合には、前記ドメイン名に対するｗｗｗヒットカウンタおよびｗｗｗリクエストサーバカウンタのうちの少なくも１つをインクリメントすることと、
前記受信したドメイン名が２つのラベルのみを有する場合には、前記ドメイン名に対する一致ヒットカウンタおよび一致リクエストサーバカウンタのうちの少なくとも１つをインクリメントすることと、
前記受信したドメイン名の前記第１のラベルが文字列「ｗｗｗ」を含まず、かつ前記受信したドメイン名が２つのラベルのみのものを有しない場合には、前記ドメイン名に対する他のヒットカウンタおよび他のリクエストサーバカウンタのうちの少なくとも１つをインクリメントすることと、
複数の前記カウンタに基づいてドメイントラフィックスコアを算出することと、を含み、
前記ドメイントラフィックスコアを算出することは、前記カウンタのうちの少なくとも１つに重み係数を適用することを含む、方法。
【請求項８】
前記リクエストサーバカウンタは所定期間あたり１カウントの制限を有する、請求項７に記載の方法。
【請求項９】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクを料金サービスの一部としてユーザに提供することと、をさらに含む、請求項７に記載の方法。
【請求項１０】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクに基づいて前記ドメインに対する広告価値を算出することと、
前記広告価値をリクエストに応じてユーザに提供することと、をさらに含む、請求項７に記載の方法。
【請求項１１】
前記ドメイントラフィックスコアを算出することは、
次式に従って、前記カウンタの各々に対する平均の日毎の割合を算出することであって、
【数５】
2012523625.tif 000012
【数６】
2012523625.tif 000013
【数７】
2012523625.tif 000014
ここで、Ｗは前記ｗｗｗカウンタであり、Ｅは前記一致カウンタであり、Ｏは前記他のカウンタであり、Ｄは前記ドメインであり、Ｐは期間（｜Ｐ｜は１日のうちの期間の長さ）であり、ＳＷ（ＡＬＬ，Ｄａｙｉ）、ＳＥ（ＡＬＬ，Ｄａｙｉ）、およびＳＯ（ＡＬＬ，Ｄａｙｉ）は、前記信頼すべきネームサーバにおいて、各々、Ｗ、Ｅ、およびＯをクエリする個別のリゾルバの組の全体数である、算出することと、
次式に従って、前記所定期間内の前記ドメインに対する全体スコアを算出することであって、
【数８】
2012523625.tif 000015
ここで、ＷＷ／Ｅ／Ｏはそれぞれ、各前記カウンタＷ、Ｅ、および０の前記重みである、算出することと、を含む、請求項７に記載の方法。
【請求項１２】
ＷＷ＝１、ＷＥ＝０．５、およびＷＯ＝０．２である、請求項１１に記載の方法。
【請求項１３】
ドメイントラフィックを決定するための自動化された方法であって、
ドメイン名を解決するための複数のリクエストを信頼すべきネームサーバにおいて受信することであって、前記複数のリクエストのうちの少なくとも２つは、ピリオドにより分離された異なる数のラベルを有し、最も左のラベルが第１のラベルであり、トップレベルドメインがｎ番目のラベルである、受信することと、
前記複数のリクエストに基づいて複数のカウンタをインクリメントすることであって、前記カウンタのうちの少なくとも２つが前記異なる数のラベルを有する前記少なくとも２つのリクエストを別々にカウントする、インクリメントすることと、
前記複数のカウンタに基づいてドメイントラフィックスコアを算出することと、を含み、
前記ドメイントラフィックスコアを算出することは、前記複数のカウンタのうちの少なくとも１つに重み係数を適用することを含む、方法。
【請求項１４】
前記複数のカウンタのうちの少なくとも１つは、所定期間あたり１カウントの制限を有する、請求項１３に記載の方法。
【請求項１５】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクを料金サービスの一部としてユーザに提供することと、をさらに含む、請求項１３に記載の方法。
【請求項１６】
前記ドメイン名に対応するドメインのランクを算出することと、
前記ランクに基づいて前記ドメインに対する広告価値を算出することと、
前記広告価値をリクエストに応じてユーザに提供することと、をさらに含む、請求項１３に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ドメイントラフィックランキングに関する。
【背景技術】
【０００２】
インターネット上のユーザ活動の理解は、インターネットが発展し続けるにつれてより重要、かつより困難になってきている。インターネットの商業的利用はこの十年で著しく拡大してきた一分野であり、ユーザ活動の理解、モニタリング、および予測に特別な関心が持たれる分野である。インターネットの商業的利用における重要な一態様に広告がある。広告主は特定のコンテンツを広告するための適切なウェブサイトまたはドメインを決定するために、トラフィックランキングなどのファクタを用いる場合がある。同様に、ウェブサイトオーナは彼らのウェブサイト上で広告するための適切な費用を設定するためにトラフィックランキングを利用する場合がある。当業者に周知のように、インターネット広告はまた、ペイパークリック（ＰＰＣ）の適用といった、特定の広告の有効性を直接実証可能な多くの異なる形態をもとってきた。しかしながら、トラフィックランキングは今もなおインターネットインフラ管理における他の態様と共に、インターネット広告における重要な態様である。例えば、インターネット上のアクティブウェブサイトの増加に伴い、サーバ管理、ウェブ開発、広告の焦点および料金などの決定を通知するために、正確なトラフィック評価に対する要求が大きくなってきた。しかしながら、一般的に、トラフィックスコアを算出するために、ユーザのトラフィックまたはウェブサイトのトラフィックをモニタリングする従来のトラフィックモニタリングサービスの能力には限界がある。
【０００３】
インターネットが本質的に体系化されている方法の記述は、インターネット上の特定のウェブサイトにおけるトラフィックを効果的にモニタリングおよび評価することに関連する課題の理解に有用となる可能性がある。
【０００４】
インターネット上のウェブサイトを構築する作業は、通常、登録者が登録機関を通して特有のドメイン名を登録することから始まる。登録者は、通常、「ｅｘａｍｐｌｅ．ｃｏｍ」といったドメイン名により識別される個人または団体である。登録者は名前登録を処理するために登録機関と連絡を取る。登録機関は必要なドメイン名サービス（ＤＮＳ）情報をレジストリに送信する。登録機関はレジストリに送信した以上の追加的な顧客情報を含むデータベースを維持する場合がある。
【０００５】
レジストリは登録機関からＤＮＳ情報を受信し、その情報を集中データベースに書き込み、そして世界中のユーザがドメイン名を検索可能なようにインターネット上のインターネットゾーンファイルにおいてその情報を伝える。
【０００６】
概して、ＤＮＳは人間が解読可能なドメイン名を、インターネットを通じたＴＣＰ／ＩＰ通信の構築に必要なインターネットプロトコル（ＩＰ）の数値に書き換えるインターネットインフラストラクチャの一部である。つまり、ＤＮＳはインターネット上のコンピュータに割り当てられた「１２３．４．５６．７８」といった数値のＩＰアドレスではなく、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」といった記憶が容易なドメイン名をユーザが用いて、ウェブサイト、および他の情報供給源を参照可能にする。各ドメイン名はドットにより分離された一連の文字列（ラベル）からなる。ドメイン名の最も右側のラベルは、「トップレベルドメイン」（ＴＬＤ）として知られる。周知のＴＬＤの例には、「．ｃｏｍ」、「．ｎｅｔ」、「．ｏｒｇ」などが挙げられる。各ＴＬＤはＴＬＤの左隣りに列記された、例えば「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の「ｅｘａｍｐｌｅ」レベルである第２レベルドメインをサポートする。各第２レベルドメインは第２レベルドメインの左隣りに配置された、例えば「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の「ｗｗｗ」レベルである複数の第３レベルドメインを含むことができる。実質的に制限なく、同様に追加的なレベルのドメインを存在させることができる。例えば、さらなるドメインレベルを有するドメインは、「ｗｗｗ．ｐｈｏｔｏｓ．ｅｘａｍｐｌｅ．ｃｏｍ」にすることができる可能性がある。
【０００７】
ドメイン名を含むユニフォームリソース識別子（「ＵＲＩ」）ストラクチャに追加的なドメイン以外の情報が含まれてもよい。例えば、「パス」部分はフォワードスラッシュ（「／」）により分離された（概念的にディレクトリに類似するが、それらを示す必要は無い）セグメント列である。この情報は「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｂｌｏｇ」における「ｂｌｏｇ」などのドメイン名の右隣りに含まれてもよく、特有のコンテンツまたはラン特定コードを識別および伝達するために、サーバまたは他の受信デバイスにより用いられてもよい。ドメイン以外の他の情報の例は、クエリおよびフラグメントを含んでもよく、その仕様は当業者に理解され、本明細書には詳細を記載しない。この情報の組み合わせは、同一または異なるドメインの一部であってもよい、同一ページの別のセクションまたは別のウェブページにユーザを案内するウェブページのハイパーリンクに含まれてもよい。
【０００８】
関連するドメイン名およびコンテンツは、その各々が異なる有意性を有する、例えば「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」、「ｗｗｗ．ｂｌｏｇ．ｅｘａｍｐｌｅ．ｃｏｍ」、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／ｂｌｏｇ」、または「ｂｌｏｇ．ｅｘａｍｐｌｅ．ｃｏｍ」などの階層化またはネスト化された方式で体系化されてもよい。このような関連ドメインは、種々のドメイン名が解決する実際のＩＰアドレスの類似性を共有する必要は無い。この点において、ドメイン名の一部は所望の特定サーバを表してもよく、例えば、「ｍａｉｌ．ｅｘａｍｐｌｅ．ｃｏｍ」および「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」などは、同一の第２レベルドメインにおいて異なる機能を有する異なるサーバを解決する場合がある。
【０００９】
前述の登録およびインターネットの構造上の態様は、次に、ＤＮＳ解決プロセスを用いてインターネット上の特有の情報供給源を検索するためにエンドユーザ用途に用いられる。ＤＮＳ解決プロセスの態様は、本願の主題の理解に役立つように下記される。
【００１０】
各ＴＬＤを機能させるための責任（ＴＬＤ内の第２レベルドメインにおけるレジストリの維持を含む）は、特定のドメイン名のレジストリに委任される。レジストリは大きなデータベース内のこのような情報を維持し、そのトップレベルドメインを機能させるＤＮＳサーバを通してドメイン名をＩＰアドレスに変換(「解決」)する責任がある。ＤＮＳは「．ｃｏｍ」、「．ｎｅｔ」、「．ｅｄｕ」、および「．ｔｖ」などのＴＬＤにおけるアドレスに対するサービスを容易にするＩＰアドレスおよびドメイン名を保存する。解決することはドメイン名を対応するＩＰ番号に一致させる処理である。解決することは、ネームサーバとも呼ばれる、コンピュータとソフトウェアとを組み合わせたものにより達成され、ＤＮＳ内のデータを用いて、どのＩＰ番号が特定のドメイン名に対応するかを決定する。以下の一般的定義が本明細書に用いられる。
解決：ドメイン名をＩＰアドレスに変換することである。
リゾルバ：ドメイン名を解決するためにクエリを発行するコンピュータである。
ネームサーバ：クエリを受信し、他のネームサーバに対して直接または解決を介してそれらに返答するコンピュータである。
サブネット：ＩＰアドレスのオクテットを共有するＩＰアドレスのグループである。
リゾルバの組：例えばサブネット、地域団体、管理事業体、および他のＩＰアドレス関連団体などの決められた団体に基づいて、一緒であると考えられるリゾルバのグループである。
【００１１】
インターネットドメインは、それらの各々に責任のある異なるレジストリによって、それらのＴＬＤのサフィックス（「．ｃｏｍ」、「．ｎｅｔ」、「．ｃｏ．ｕｋ」など）に従ったグループに分割することができる。例えば、「．ｃｏｍ」および「．ｎｅｔ」のドメインに責任を有するＶｅｒｉＳｉｇｎ（登録商標）レジストリなどのように、１つのレジストリがこれらのグループのいくつかに責任を有する場合がある。
【００１２】
ＤＮＳはクライアントサーバモデルを用いた分散型データベースシステムによって維持される。このデータベースのノードはネームサーバである。各ドメインまたはサブドメインは、そのドメインおよびその下位の任意のドメインのネームサーバに関する情報をパブリッシュする１つ以上の信頼すべきＤＮＳサーバを有する。階層の最上位はルートネームサーバにより供給され、ＴＬＤを検索(解決）する際にサーバはクエリする。
【００１３】
信頼すべきネームサーバを各ドメインに対して指定することにより、ＤＮＳはドメイン名を割り当て、これらのドメイン名をＩＰアドレスにマッピングする責任を分配する。信頼すべきネームサーバはそれらの特定のドメインに責任を有するように割り当てられる。
【００１４】
理論上は、十分な資格を与えられたドメイン名はいくつかの名前セグメント（例えば、「ｗｗｗ．ｏｎｅ．ｔｙｐｅ．ｅｘａｍｐｌｅ．ｃｏｍ．など」）を有してもよい。実際には、ドメイン名は３個丁度のセグメントからなることが多い。クエリする目的のため、名前セグメントは右から左へのセグメントとして通常は解釈される。この方法に沿った各ステップにおいて、対応するＤＮＳサーバはポインタを参照すべき次のサーバに提供するようにクエリされる。
【００１５】
ＤＮＳにより生成された非常に大きなリクエストに起因して、解決プロセスは成功応答後の所定期間中の間キャッシング（すなわち、ＤＮＳクエリ結果の局所的な記録およびその後の参照）をさらに可能にする。リゾルバがＤＮＳ応答をキャッシュする期間（すなわち、ＤＮＳ応答が有効であると考慮される期間）は、有効期間（ＴＴＬ）と呼ばれる値により決定される。ＴＴＬは応答に対処するＤＮＳサーバの管理者が通常は設定する。有効期間はほんの数秒間から数日間、さらには数週間でもよい。
【００１６】
キャッシング機能に加えてＤＮＳストラクチャに基づいて、ネームサーバには一般的に適用される２つの区分、信頼性および再帰性（キャッシング）がある。信頼すべきネームサーバはオリジナルの明確な応答（「信頼すべき」応答）をＤＮＳクエリに与えるネームサーバである。全てのドメイン名が、ドメイン名の解決に責任のある信頼すべきネームサーバの組に割り当てられる。
【００１７】
前述したように、問い合わせ中のドメイン名記録のＴＴＬにより決定された所定期間中のＤＮＳクエリ結果を保存する再帰性のキャッシュサーバをＤＮＳはさらに用いる。通常、このようなキャッシングＤＮＳサーバは、クエリされたドメインにおける信頼すべきネームサーバを通してＤＮＳルートから始まる所定の名前の解決に必要な再帰性のアルゴリズムをさらに実行する。インターネットサービスプロバイダ（ＩＳＰ）は、通常、再帰性のある、キャッシングネームサーバを顧客に提供する。さらに、多くのホームネットワーキングルータはＤＮＳキャッシュおよび再帰を実行し、ローカルネットワークにおける効率を改善する。
【００１８】
ＤＮＳ「スタブ」リゾルバはＤＮＳ名をＩＰアドレスに解決するために、キャッシュレス用途として本質的に動作するものとしても周知である。ＤＮＳスタブリゾルバは、ＤＮＳクエリをワークステーション（または、サーバ）用に構成されたＤＮＳサーバに転送し、ＤＮＳサーバの応答をリクエスト中のソフトウェアに返送する。ＴＴＬの終了前にキャッシングサーバにより保持されている記録に対するキャッシングネームサーバをスタブリゾルバがクエリする場合には、キャッシングサーバは信頼すべきネームサーバからそれを再度読み出さずに、キャッシュした情報供給源の記録を利用して応答する。
【発明の概要】
【発明が解決しようとする課題】
【００１９】
現在、ウェブトラフィック情報の提供に使用されるいくつかの方法がある。周知の方法には、ユーザが選択したサンプルがそれらのウェブトラフィックの使用をモニタリングするクライアントエージェントに提供されるというパネル中心法が含まれる。また、ウェブトラフィック統計値がウェブサイトにおけるウェブサーバから直接収集されるサイト中心法もある。他の方法はＩＳＰに焦点をあて、ウェブデータをクライアントに提供しているＩＳＰのログからウェブ利用トラフィックを収集する。しかし、周知の方法の各々は、データを収集する場所、収集されるデータ量、および／または収集されるデータの重要性に関する欠点がある。例えば、パネル中心法は、モニタリングされる対象が選択されたユーザに限定されるため、インターネット上の活動に対する全体論的観点を得るための能力が限定される。さらに、何十億の個人インターネットユーザの活動を分類整理する任意の試みが仮に可能だとしても、管理不能なレベルに直ぐに到達するような大量のデータが生成される。同様に、個々のウェブサーバに対するトラフィックスコアは、その特定サーバにより収集されたデータの分離された性質に基づいた限定された値のものであるだけでなく、オペレータが大量のトラフィックの報告に興味を持つかもしれない場合に、サーバの報告を検証する潜在的な必要が生じ得る。このようなトラフィックモニタはさらに、トラフィック量に干渉する、および／またはそれを人為的につり上げる種々のタイプの偽装の影響を受けやすい。ＩＳＰを利用する方法は、特定のクライアントベース、地理的な関心、および特定のＩＳＰが内々に関与するトラフィックを本質的または暗に制限する他のファクタに基づく、インターネット上の全体的な活動を特性化する能力もまた限定される。
【００２０】
ドメインに関する正確かつ有意なトラフィックランキングの決定にはさらなる問題もある。通常、インターネットトラフィックはユーザ指向トラフィックと機械指向トラフィックとの２つのグループに分割することができる。ユーザ指向トラフィックは、ユーザブラウジングウェブサイトにより生成された活動と認識することができる。機械指向トラフィックは、自動プロセスおよびサービス（例えば、抗ウイルスの更新、オペレーションシステム更新、ウェブサービスなど）により生成された活動と認識することができる。オンライン広告を含む商業利用目的のため、ウェブサイト内に入り込むユーザが生成したトラフィックの識別は特に重要である。それ故、ユーザ指向トラフィックを測定する方法が望まれる。しかしながらこれは、例えば、着信するクエリ自体からリクエスタの性質に関する情報が得られないために深刻な課題となる。トラフィックタイプの各々を区別する別の課題は、中間ＤＮＳリゾルバにより起動されたクエリを参照する、インターネットＤＮＳシステムのアーキテクチャにより引き起こされる。これはリクエストを起動したエンドユーザの性質を不明にする可能性がある。
【課題を解決するための手段】
【００２１】
本発明の主題はＴＬＤ、ＤＮＳサーバにおいて取得されたＤＮＳトラフィックデータを用いた種々のメカニズムを通じて前述の課題の多くに対処することにある。本発明の態様に従って、周知のシステムが意図または達成しない方法によりインターネットの全体にわたるドメインをランク付けすることができる。実施形態では、いくつかの特性および／または測定結果が種々のドメインに関するＴＬＤ、ＤＮＳサーバに存在するＤＮＳトラフィックから取得される場合があり、トラフィックスコアを算出するために用いられる場合がある。算出されたスコアはドメインのランク付けに用いられてもよい。
【００２２】
ＤＮＳデータを有意かつ有用な形状に変換するという課題がＤＮＳデータのサイズに関連することを発明者らは認識してきた。レジストリは世界の異なる場所に配置された、いくつかの解決サイトを運営する場合がある。１つのレジストリに対するサイトは、１日に３４０億超のクエリに応答する場合がある。この膨大な数のクエリは、生データを分析する試みにおける大きな課題をもたらす。本願はデータの全体量をより処理し易いサイズに低減する場合があるデータ集約に関するシステムおよび方法を提供する。これらの方法に従い、インターネット上の有意な活動におけるより正確な実態が、生トラフィックデータを用いた従来の方法により実現されてきたもの以上に明白とすることができることが見出された。
【００２３】
開示する方法は、例えば、ドメインあたり、１日あたりのいくつかの統計値を列挙する場合があるドメイン要約トラフィック情報、およびＤＮＳクエリに関するより詳細な情報を列挙する場合があるドメイン詳細トラフィック情報を含む、異なる集約フォーマットを含んでもよい。ＤＮＳクエリ情報の特定の有用例が、クエリを生成する複数のリゾルバの組のアイデンティティであることが見出された。
【００２４】
実施形態は、ＤＮＳクエリにおいてリクエストされたアドレスの種類を区別することを含んでもよい。例えば、実施形態は、一致リクエスト、「ｗｗｗ」リクエスト、および他のリクエストを別々に認識できる。本明細書に用いられる場合、一致リクエストは、特定のラベル数などの既定の一基準に一致するリクエストである。一致リクエストは、いかなるプレフィックスをも用いずにリクエストされた一致する第２レベルドメイン名などの２つのラベルを含むものとして実施形態において認識される場合がある。例えば、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」における一致リクエストは、「ｈｔｔｐ：／／ｅｘａｍｐｌｅ．ｃｏｍ／」でもよい。
【００２５】
「ｗｗｗ」リクエストは、文字列「ｗｗｗ」がプレフィックスに含まれるリクエストである。例えば、「ｈｔｔｐ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」、「ｈｔｔｐ：／／ｗｗｗｌ．ｅｘａｍｐｌｅ．ｃｏｍ／」、および「ｈｔｔｐ：／／ＡＡＡ−ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ／」を読み出すリクエストは、「ｗｗｗ」リクエストとして認識される。本明細書に用いられる場合、「他」のリクエストは、「一致」または「ｗｗｗ」基準のいずれも満たさないリクエストである。これはリクエストの一部として他のプレフィックスを含む場合がある。例えば、「ｈｔｔｐ：／／ｊｏｂｓ．ｅｘａｍｐｌｅ．ｃｏｍ／」、「ｈｔｔｐ：／／ｍａｉｌ．ｅｘａｍｐｌｅ．ｃｏｍ／」、および「ｈｔｔｐ：／／ＡＡＡ．ＢＢＢ．ｅｘａｍｐｌｅ．ｃｏｍ／」は、対応する完全一致が識別されない場合には、「他」のリクエストとして認識される。
【００２６】
実施形態では、ドメインに対するＤＮＳクエリに関する下記の例示の属性が取得され、ランキングを算出するのに用いられる場合がある。
ＷＷＷリクエストヒット。これは、第１のラベルが「ｗｗｗ」である、ＤＮＳ記録上のヒットカウントである。
一致リクエストヒット。これは、例えば、「ｅｘａｍｐｌｅ．ｃｏｍ」のみなどの、２つのラベルのみを有するＤＮＳ記録上のヒットカウントである。
他のリクエストヒット。これは、前述のカテゴリのどちらにも分類されない、ＤＮＳ記録上のヒットカウントである。
【００２７】
さらに下記するように、実施形態は、トラフィックおよび／またはランキングスコアの決定において、適切な重み係数をドメインに対する様々なリクエストヒットに適用することをさらに含んでもよい。
【００２８】
実施形態は、ＤＮＳクエリのＩＰアドレス、サブネット、および／または複数のリゾルバの組を作成することに関連する下記の属性を明らかにすること、およびそれらを利用してランキングを算出することを含んでもよい。
ＷＷＷサーバカウント。これは、第１のラベルに「ｗｗｗ」を有する、一意の下位ＩＰアドレスまたはＤＮＳレコードをヒットする複数のリゾルバの組のカウントである。
一致サーバカウント。これは、２つのラベルのみを有する、一意の下位ＩＰアドレスまたはＤＮＳレコードをヒットする複数のリゾルバの組のカウントである。
他のサーバカウント。これは、前述のカテゴリのどちらにも属さない、一意の下位ＩＰアドレスまたはＤＮＳレコードをヒットする複数のリゾルバの組のカウントである。
【００２９】
さらに下記するように、実施形態は、トラフィックおよび／またはランキングスコアの決定において、適切な重み係数をドメインにおける種々のサーバカウントに適用することをさらに含んでもよい。
【００３０】
実施形態は、ドメインに対するＤＮＳレコードのＴＴＬに基づいてトラフィックおよび／またはランキングスコアを算出することを含んでもよい。
【００３１】
実施形態は、ドメイントラフィックを自動的に決定するための方法を含んでもよい。例示の方法は、ピリオドにより分離されたｎ個のラベルを有するドメイン名を解決するためのリクエストを信頼すべきネームサーバにおいて受信することを含んでもよい。最も左のラベルは第１のラベルと考えられてもよく、ＴＬＤはｎ番目のラベルである。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含む場合には、ドメイン名に対するｗｗｗカウンタがインクリメントされてもよい。受信したドメイン名が２つのラベルのみを有する場合には、ドメイン名に対する一致カウンタがインクリメントされてもよい。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含まず、かつ受信したドメイン名がラベル２つのみのものを有しない場合には、ドメイン名に関する他のカウンタがインクリメントされてもよい。ドメイントラフィックスコアは複数のカウンタに基づいて算出されてもよい。ドメイントラフィックスコアの算出は、少なくとも１つのカウンタに重み係数を適用することを含んでもよい。
【００３２】
実施形態は前述のように、ドメイン名を解決するためのリクエストを信頼すべきネームサーバにおいて受信することを含み得る。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含む場合には、次に、ドメイン名に対するｗｗｗヒットカウンタおよびｗｗｗリクエストサーバカウンタの少なくとも１つがインクリメントされてもよい。受信したドメイン名がラベルを２つのみ有する場合には、ドメイン名に対する一致ヒットカウンタおよび一致リクエストサーバカウンタの少なくとも１つがインクリメントされてもよい。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含まず、かつ受信したドメイン名が２つのラベルのみのものを有しない場合には、ドメイン名に関する他のヒットカウンタおよび他のリクエストサーバカウンタの少なくとも１つがインクリメントされてもよい。ドメイントラフィックスコアは複数のカウンタに基づいて算出されてもよい。ドメイントラフィックスコアの算出は、少なくとも１つのカウンタに重み係数を適用することを含んでもよい。
【００３３】
実施形態は、信頼すべきネームサーバがＴＬＤネームサーバである場合を含んでもよい。
【００３４】
実施形態は、所定期間の間、特定のカウンタに記録されるクレメントの数を制限することを含んでもよい。例えば、リクエストサーバカウンタは、２４時間あたり１回のインクリメント（カウント）に制限されてもよい。実施形態は、所定期間後にカウンタをリセットすることを含んでもよい。
【００３５】
実施形態は、ドメインに対する相対トラフィックスコアに基づいてランキングスコアを算出することを含んでもよい。これは、ドメイントラフィックスコアと、他のドメイントラフィックスコアとを比較することを含んでもよい。算出されたトラフィックおよび／またはランキングスコアは、費用サービスの一部として自動的に配信されてもよく、または例えば広告料などの他の項目を決定するために用いられてもよい。
【００３６】
本発明の主題におけるさらなる利点は、下記の好ましい実施形態の詳細な記述を読み、理解すれば、当業者には明らかとなるであろう。
【図面の簡単な説明】
【００３７】
【図１】本発明の実施形態に従った、例示のシステムおよび関連ネットワークを示す図である。
【図２】本発明の実施形態に従った、例示のシステムおよび関連ネットワークを示す図である。
【図３】本発明の実施形態に従った、例示の方法の態様を示す図である。
【図４】本発明の実施形態に従った、例示の方法の態様を示す図である。
【図５】本発明の実施形態に従った、例示の方法の態様を示す図である。
【図６】本発明の実施形態に従った、例示のシステムおよび関連ネットワークを示す図である。
【図７】ドメイントラフィックサイズと、「他」の標的に向かうトラフィックのパーセンテージとの関係を示すグラフである。
【図８】ドメイントラフィックサイズと、「ｗｗｗ」および「一致」の標的に向かうトラフィックのパーセンテージとの関係を示すグラフである。
【図９】本発明の態様に従ってグループ化されたドメイン数を示すグラフである。
【発明を実施するための形態】
【００３８】
下の詳細な記述は、説明および理解を容易にするため、例示的な実施形態を参照して提供される。出願人の発明は開示する実施形態には限定されず、本明細書に記載された説明の全ての範囲に収まる他の変形を含む。
【００３９】
前述したように本発明の実施形態は、図１に示すインターネット環境などのネットワーク上の操作を含んでもよい。クライアントコンピュータデバイス１１０は、再帰性のネームサーバ１３０へのＤＮＳリクエスト１０３を開始してもよい。図１に示すように、ＤＮＳリクエスト１０３は生成するか、またはモバイル機器１２０、無線コンピュータデバイス１２２、他の通信リンク１２４、および／または中間ネットワークサーバ１２６などの種々の起点から再帰性のネームサーバ１３０に送信することができる。ドメイン名を解決するためのＤＮＳリクエストは、通常、ピリオドにより分離されたｎ個のラベルを有する。これらのラベルは、通常、ウェブページなどの、所望のインターネット資源に対する数値のＩＰアドレスよりも記憶するのが容易な形態である。説明を容易にするため、最も左のラベルは第１のラベルと考えられてもよく、ＴＬＤはｎ番目のラベルである。それ故、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」のリクエストでは、ｎ＝３であり、第１のラベルは「ｗｗｗ」、およびＴＬＤは「．ｃｏｍ」である。前述のように、再帰性のネームサーバ１０３は、再帰性の名前解決の一部として、ＤＮＳリクエストを種々の信頼すべきサーバ１４０、１５０、１６０に送信してもよい。代替的に、リクエストされたＤＮＳ情報は、信頼すべきネームサーバ１４０、１５０、１６０を参照することなくクエリが応答されてもよい場合には、ＤＮＳレコードのＴＴＬに従って、再帰性のネームサーバ１３０のキャッシュに存在してもよい。
【００４０】
図２は再帰性のネームサーバ２２０、およびそれと相互作用する信頼すべきネームサーバ２３０、２４、２５０に関するさらなる詳細を示す。図２では、信頼すべきサーバ２３０はルートレベルの信頼すべきサーバである。これらのサーバの各々は、インターネット上の特定のＴＬＤに関する情報を含む。ルートレベルサーバはそれらのＴＬＤ内のドメインに対するリクエストを、ＴＬＤレジストリが管理する他の信頼すべきサーバに導くことができる。例えば、クライアント２１０からのＤＮＳリクエスト２０２は、「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」に関するリクエストを含んでもよい。再帰性のネームサーバ２２０は、対応するＤＮＳレコードに対する内部キャッシュを最初にチェックしてもよい。これが検出されない場合には、ＤＮＳリクエストは２０３を通じてルートレベルの信頼すべきネームサーバ２３０に転送されてもよい。「．ｃｏｍ」に責任のあるサーバ２３０内の信頼すべきルートレベルのサーバは、リクエスタを信頼すべきネームサーバ２４０に導く「ｅｘａｍｐｌｅ．ｃｏｍ」に対してＤＮＳ情報を返送してもよく、この場合、これらのサーバが、「．ｃｏｍ」のレジストリに関するサーバの集まりを表す。本明細書に記載されるように、２０３、２０４、２０５などのＤＮＳリクエストは、２３０、２４０、２５０などの種々の信頼すべきサーバにおいてカウントすることができる。実施形態では、カウンティングは、例えば２３０などのＴＬＤネームサーバにおいて実行されてもよい。他の信頼すべきネームサーバ２４０、２５０はさらに、これらの記録に関してそれぞれのサーバが取り扱うＤＮＳヒットをカウントできる。実施形態は組み合わされたランキングを形成するために、種々のサーバおよび／または「．ｃｏｍ」、「．ｎｅｔ」、「．ｅｄｕ」、「．ｕｋ」などのＴＬＤからのスコアの結合を含んでもよい。
【００４１】
実施形態では、測定は所定のカウンタにおいてリクエストをカウントするか、またはカウントしないで実行されてもよい。例えば、「サーバカウンタ」などの特定のカウンタは、所定期間あたり１カウントに限定されてもよい。図３に示すように、Ｓ３１００においてリクエストは受信されてもよい。Ｓ３２００において関連ヒットカウンタはインクリメントされてもよい。Ｓ３３００において、サーバカウンタをインクリメントするか否かが決定されてもよい。この例では、サーバカウンタの最新のカウントが既定値「Ｘ」と比較されてもよい。サーバカウントがＸ以上である場合には、サーバカウンタを再度インクリメントしないことが決定され、方法はＳ３５００に進んでもよい。サーバカウントがＸ未満である場合には、方法はサーバカウンタがインクリメントされるＳ３４００に進んでもよい。サーバカウントは所定期間後に自動的にリセットされてもよい。サーバカウンタに関連して記述したが、特定のＩＰアドレス、リゾルバの組などに関連するカウンタなどの他のカウンタが類似の方法により制限されてもよい。さらに下記するように、特定のカウンタにおけるカウント制限が、有意なインターネット活動における、より正確な実態を明らかにするために用いられてもよい。これらの制限されたカウンタは全体のウェブトラフィックを管理可能に、かつ正確な表示をユーザに提供するための、単独または組み合わされたヒットカウンタとして考慮される場合がある。例えば、制限されたカウンタの使用は、特定サーバ、リゾルバの組、ＩＰアドレスなどから生じる場合がある、人為的な、または信頼できないトラフィックインジケータの望ましくない効果を低減する場合がある。
【００４２】
図４を参照すると、例示的な方法は、Ｓ４０００において、受信したレクエストに対応して、カウンタをインクリメントするかどうかを判定することを含んでもよい。上に詳述したように、一部の実施形態では、ドメインに対して受信したＤＮＳリクエストについてのヒットカウンタはインクリメントされてもよい。一部の例では、制限されたカウンタがインクリメントされないことが決定されてもよい。問い合わせ中のカウンタがインクリメントする場合には、方法はＳ４１００に継続してもよい。
【００４３】
Ｓ４１００において、受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含むか否かを判定するために、リクエストが評価されてもよい。「ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ」の場合のように、文字列はリクエストされたアドレスの独立部分でもよく、または「ｗｗｗｌ．ｅｘａｍｐｌｅ．ｃｏｍ」などのように、他の文字によってネスト化されていてもよい。第１のラベルが文字列「ｗｗｗ」を含むことが判定された場合には、方法はＳ４２００に進んでもよい。ここでドメイン名についてのｗｗｗカウンタなどのカウンタ「Ａ」はインクリメントされてもよい。受信したドメイン名の第１のラベルが文字列「ｗｗｗ」を含まない場合には、方法はＳ４３００に進んでもよい。
【００４４】
Ｓ４３００において、ラベルが既定の条件「Ｒ（ｒ）」を充足するか否かを判定するために、リクエストは評価されてもよい。Ｒ（ｒ）は既定のラベル数、特定の文字列、またはＤＮＳリクエストの他の特長を含む多くの形態をとることができる。複数のラベルを指定する場合には、記述の実施形態は、Ｒ（２）が２つのラベルである場合を含む。受信したドメイン名が、例えば、「ｅｘａｍｐｌｅ．ｃｏｍ」における２つのラベルなどのように、既定数Ｒ（２）のみのラベルを有する場合には、方法はＳ４４００に進んでもよい。ここでカウンタＢ（ｒ）はドメイン名に対する２つのラベルの「一致」カウンタＢ（２）などのようにインクリメントされる。例えば、ラベルの既定数Ｒが２である場合に２つより多いラベルを有するなどのように、指定された数Ｒのみのラベルをリクエストが有しない場合には、方法はＳ４３１０に進んでもよい。実施形態は、例えば、複数の一致カウンタなどの、複数のＢカウンタを含んでもよい。これらのカウンタは、例えば、Ｒ（ｒ）に対する種々の数のための個別のカウンタ、またはドメイン文字列の一致部分のための「一致」カウンタなどの異なるバージョンなどを含んでもよい。一例として、Ｒ＝３である「ｍａｉｌ．ｅｘａｍｐｌｅ．ｃｏｍ」に対するリクエストに応答して、追加的なカウンタＢ（３）がインクリメントされてもよい。別の例として、例えば、「ｍａｉｌ５．ｅｘａｍｐｌｅ．ｃｏｍ」などの文字列をリクエストが含む場合に、例えば、「ｍａｉｌ」などの特定の文字列を有するリクエストがカウンタＢ（「ｍａｉｌ」）によりカウントされてもよい。これは、追加的な一致カウンタＢ（ｒ）が実装され得るか否かをＳ４３１０において判定することによって実行されてもよい。他の一致カウンタが存在する場合には、この方法は、Ｒ（ｒ）がカウンタＢ（ｒ）に対して新規の値にリセットされてもよいＳ４３２０に進んでもよい。Ｒ（ｒ）がリセットされた後、この方法はリクエストが新規の基準Ｒ（ｒ）を満たす否かを判定するＳ４３００に戻ってもよい。Ｒ（ｒ）が満たされるまでか、または残存する一致カウンタが無くなるまで、Ｓ４３００、Ｓ４３１０、およびＳ４３２０は繰り返すことができる。残存する一致カウンタが無い場合には、この方法はＳ４５００に進んでもよい。
【００４５】
Ｓ４５００において、ドメイン名についての種々雑多なカウンタなどのようなカウンタ「Ｃ」はインクリメントされてもよい。種々雑多なリクエスト、すなわち先行するカテゴリのいずれにも適合しないリクエストをカウントすることは要求されないが、種々雑多なカウンタは検出されたトラフィックの有用性の評価において利点を提供する場合がある。例えば、種々雑多なカウンタは、明らかに人的相互作用により後押しされたトラフィックのパーセンテージを決定するために、ｗｗｗカウンタおよび一致カウンタ（複数可）と比較して用いられる場合がある。
【００４６】
Ｓ４２１０、Ｓ４４１０、および／またはＳ４５１０において、重み係数が決定されてもよく、かつ／またはカウンタＡ、Ｂ（ｒ）および／またはカウンタＣにそれぞれ割り当てられてもよい。重み係数は、ドメインに対するカウンタの全てまたは一部に適用されてもよい。例えば、重み係数は、ドメインに対する１つ、２つ、または全てのカウンタに適用されてもよい。重み係数を割り当てることは、カウンタの性質およびドメインに関連して収集された他の情報に関連するいくつかのファクタに基づいてもよい。重み係数はまた、動的に適用されてもよい。例えば、時間の経過に伴い、ドメインに対する異なるカウンタのカウントは変化してもよく、またはドメインに関する情報が生成されてもよい。これはドメインに対するカウンタに適用された重み係数の１つ以上における変化を促進する場合がある。この方法はＳ４９００に継続してもよい。
【００４７】
Ｓ４９００において、トラフィックスコアなどのようなドメインに対するスコアが算出されてもよい。トラフィックスコアは複数のカウンタに基づいてもよい。関連するカウンタの全てからのカウントを用いる必要は無いことに注意されたい。スコアは考慮される任意の関連する重み係数を用いた１つまたは２つ以上のカウントに基づいて算出される場合がある。それ故、ドメイントラフィックスコアは複数のカウンタに基づいて算出されてもよく、少なくとも１つのカウンタに重み係数を適用することを含んでもよい。
【００４８】
前述したように、再帰性のネームサーバがＤＮＳクエリに対する応答を得た場合には、さらなる利用のためにそれをキャッシュしてもよい。各応答がキャッシュに保存される時間はＴＴＬに基づく。ドメインを標的にしたクエリの総数によるドメイントラフィックの測定が、キャッシング機能およびＤＮＳレコードに対するＴＴＬに基づく不正確さを有する場合があることに発明者らは気付いた。各ドメイン／リゾルバがそのＴＴＬを別々に管理する場合があるという事実に基づいて、キャッシング機能における補正は、大規模な実施の場合には特に困難となる可能性がある。例えば、リゾルバは６時間毎にそのキャッシュをリフレッシュする場合があり、その一方で別のリゾルバは１２時間毎にそのキャッシュをリフレッシュする場合がある。両方のリゾルバが正確な回数、所定のドメインに要求される場合でさえも、そして、両方のリゾルバがドメインに関するユーザ作成型トラフィックにおいて同じ量を表していたとしても、大雑把に言って、第１のリゾルバは、第２のリゾルバと比較して概して２倍多い、このドメインに関するＤＮＳ鎖上にクエリトラフィックを生成することが予期される。発明者らはこの課題に対処するいくつかの特長を開発してきた。
【００４９】
第１の例のように、スコアの重みつけは、ＤＮＳファイルに関するＴＴＬに基づいてＳ４９００において適用されてもよい。これにより、サーバに実際に転送されたリクエストを示すのみの、信頼すべきネームサーバにリンクされたヒットカウンタの制限を多少は補正することができる。サーバに転送されたリクエスト数に基づいて、ＴＴＬに基づいた重み係数を、ドメインに向けられた総トラフィックの見積もりを算出するために用いることができる。一般的に、比較的長いＴＴＬを有するサイトについてのトラフィックは、より短いＴＴＬを有するサイトよりも、より大きい重み係数を受信する場合がある。重み係数は、スコア／ランクされたドメイン中のＴＴＬ比率に基づいて構築することができる。
【００５０】
別の例では、開示する方法は、より少ないノイズ、並びにＴＴＬおよび各個人リゾルバのキャッシングポリシにより少ない依存性を導入することが見出された、別個にクエリされる複数のＩＰアドレス、複数のリゾルバの組などの観測に関連する場合がある。この方法はＴＤＬレベルにおけるトラフィック、および莫大な量の全体のトラフィックを監視する場合がある他の信頼すべきネームサーバを観察する分野において特に有用であることが見出された。一意的にクエリするＩＰアドレス、複数のリゾルバの組などのメトリックはさらに、総計のヒットカウンタにより受信される大きなオフセットを防止することができる。例えば、ヒットカウンタにより反映されたトラフィックの総量に単独で依存するのではなく、各々個別にクエリするＩＰアドレス、複数のリゾルバの組などは、２４時間などの所定期間につき１回のみカウントされてもよい。
【００５１】
この点において、２種類のメトリックを考慮することが有用である。
ヒット（Ｈ）：所定のドメインに対して生成されたクエリの総数である。
リゾルバの組（Ｓ）：所定のドメインに関するクエリを生成する、複数の別個のリゾルバＩＰアドレス、サブネット、リゾルバの組などの数である。
【００５２】
前述のように、所定のクエリは３種類のドメインターゲット、すなわち「ｗｗｗ」、「一致」、「他」のうちの１つをリクエストすることができる。それぞれのリクエストのカウントに基づいてトラフィックの性質を有意に読み取るのに役立ついくつかのファクタに、発明者らは気付いた。これは、例えばウェブサービスなどのような、非ユーザトラフィックとは対照的なユーザトラフィックを特定の種類の各クエリが反映する範囲の理解に役立てることができる。
【００５３】
ｗｗｗクエリに関しては、このような標的を参照する大多数のトラフィックがユーザ指向であることが推測されるかもしれない。しかしながら、ｗｗｗクエリはドメイン内のユーザ指向トラフィックを通常は反映するが、ドメインについてのユーザ指向トラフィックの全てを常に含んでいる訳ではない。一部のドメインにおいて、ユーザ指向トラフィックの一部が「一致」および「他」のメトリック内に存在することが理解される。例えば、一部の人気があるウェブサイトについて、リクエストの１０パーセント未満がｗｗｗカテゴリに含まれることを発明者らは見出した。それ故、ｗｗｗメトリックのみに基づくスコアの算出は、結果としてウェブサイトが示している実際のトラフィックに基づくものよりも、非常に低くランク付けされる特定のウェブサイトになる。これは、「他」のクエリがユーザ指向トラフィックにおいて大きい割合を有する場合がある、大きいドメインの支持の評価に特別に関連することが見出されてきた。例えば、ドメイン「ｅｘａｍｐｌｅ．ｃｏｍ」は、例えば、「ｍａｉｌ．ｅｘａｍｐｌｅ．ｃｏｍ」、「ｇａｍｅｓ．ｅｘａｍｐｌｅ．ｃｏｍ」、「ｎｅｗｓ．ｅｘａｍｐｌｅ．ｃｏｍ」などの人気のあるサブドメインを目的とするほとんどのトラフィックを示す場合がある。
【００５４】
ドメインのサイズ（すなわち、そのトラフィック量）と、その全体のトラフィックから出る「他」のトラフィックのパーセンテージとの間に高い相関関係があることを発明者らは見出した。図７は（ログスペース内の）ドメイントラフィックサイズと、「他」の標的（サブドメイン）に向かうトラフィックのパーセンテージとの関係を示すグラフである。各バーの値がそのバーに位置する全てのドメインのパーセンテージの平均であることに留意されたい。
【００５５】
このグラフは２つのファクタ間の明確な関係を示し、より大きなドメインが「他」のトラフィックにおけるトラフィックの総計においてより大きいパーセンテージを有する傾向があることを示す。それ故、「他」のトラフィックの有意性は、ドメインに対するトラフィックの全体レベルに応じて異なる場合がある。この観察は、本明細書に記載された種々の方法論の公式化に考慮されてきた。例えば、通常では他のトラフィックは一致トラフィックよりも低い重み係数を与えられ得るが、実施形態では、他のトラフィックに関する重み係数は、関連するトラフィック量に従って増大される場合がある。
【００５６】
ユーザによるウェブサイトへの照会の多くでは、「ｗｗｗ」プレフィックスは省略される（例えば、「ｅｘａｍｐｌｅ．ｃｏｍ」）。しかしながら、このようなリクエストに反映されたユーザ指向トラフィックのノンユーザ指向トラフィックに対する比率、およびそれ故「一致」リクエストの有意性は不明確であった。
【００５７】
驚くべきことに、「ｗｗｗ」および「一致」トラフィックメトリックの両方を考慮することが、特に好ましい結果をもたらすことを発明者らは観測してきた。「一致」メトリックそれ自体は明確な傾向または一貫性を示さないが、「ｗｗｗ」メトリックと結合すると明確なパターンが観測される。それ故、図８に示すように、２つのメトリックが予期しない方法により互いに補完することが決定される。
【００５８】
発明者らは所定期間内において入信するトラフィックを、その期間内の全体のトラフィックと比較することにより、所定のドメインの動作を測定するための合理的かつ正確な方法を開発するために、前述の観察を信頼してきた。実施形態では、全ての３つのＤＮＳ標的タイプは、例えば、「ｗｗｗ」（Ｗ）、「一致」（Ｅ）、および「他」（Ｏ）を含んでもよく、その各々が異なる重みを割り当てられてもよい。さらなる特長として、「リゾルバの組」メトリックが単独で、または「ヒット」メトリックと組み合わせて用いられてもよい。例えば、開示する方法論の実施形態を下記する。
【００５９】
所定期間の間の各ドメインのＷ／Ｅ／Ｏ平均の日ごとの比率が算出される。換言すれば、ドメインごとに、別個のリゾルバの組のメトリックと、その日の別個の複数のリゾルバの組の全体数との日ごとの比率の平均が算出される。これは各標的タイプＷ／Ｅ／Ｏに対して別々に実行することができる。
【００６０】
【数１】
2012523625.tif 000003
【００６１】
【数２】
2012523625.tif 000004
【００６２】
【数３】
2012523625.tif 000005
【００６３】
ここで、Ｄはドメインであり、Ｐは期間であり（｜Ｐ｜は１日のうちの期間の長さ）、かつＳＷ／Ｅ／Ｏ（ＡＬＬ，Ｄａｙｉ）は、適切にＷ／Ｅ／Ｏをクエリする別個の複数のリゾルバの組の全体数である。
【００６４】
所定期間内のドメインに関する全体のスコアを算出する。
【００６５】
【数４】
2012523625.tif 000006
【００６６】
ここで、ＷＷ／Ｅ／Ｏは、適切な各標的タイプＷ／Ｅ／〇の重みである。好ましい実施形態では、次の概算の重みが前述の方程式に用いられてもよい。
【００６７】
【数５】
2012523625.tif 000007
【００６８】
他の実施形態では、重み係数はより一般的に記載することができる。例えば、ＷＷ≧ＷＥ≧ＷＯのように記載される。前述のように、ＷＯはトラフィック量に従って調整することができる。例えば、ＷＯはＷＯ’＝（ＷＯＫ）として補正されてもよく、ここで、Ｋはドメイントラフィック量の関連ファクタであり、例えば、Ｋ≧１は比較的大きいトラフィック量を表し、Ｋ≦１は比較的低いトラフィック量を表す。
【００６９】
類似のスコアをグループ化することは種々のユーザに対する情報の実用性を改善することができることを発明者らは認識してきた。例えば、１が最低であり、１００が最高である１００の等しい幅のビンにスコアのログを分割することにより、グループの有用な表示が作成される場合がある。図９は各グループにおけるドメインの数を示す。
【００７０】
実施形態では、広告の価格設定はドメインに対するグループに基づいて決定することができる。例えば、９０〜１００の間のトラフィックグループにおけるドメインは、５０〜６０間のトラフィックグループにおけるドメインとは異なる広告料が適用されてもよい。これらのグループが生のトラフィックスコアデータに限定されず、ＴＬＤサーバのレベルから得られた他の広範な観点だけでなく、本明細書に記載された方法論に基づく、より有意かつ有益なメトリックを表すことが留意される。例えば、本明細書に記載された方法論が、低レベルにおけるトラフィックを生成しつつあるウェブサイトおよびドメインを、従来の方法よりも前に、識別する場合があることを発明者らは観測してきた。ある意味で、インターネット全域にわたるトラフィックの有意性を統合および評価するために、ＴＬＤの能力に基づくこのような結果が部分的に得られる。
【００７１】
図５を参照すると、実施形態はＳ３９９０、Ｓ４９００、および／またはＳ５９００などにおいて算出されたスコアを取得することと、このスコアをドメインのランク付けに用いることとを含んでもよい。例えば、ドメインに対して算出されたトラフィックスコアは、ウェブ上の他のドメインの中でもそのドメインをランク付けするために、Ｓ５９１０において他の算出されたスコアと比較されてもよい。このようなランキングは、特定のドメインにおける広告に対する適切な価格設定または価値を評価するために、より直観的な方法でユーザに対して用いることができる。算出されたランクは有料サービスの一部として配信されてもよく、またはシステム管理などを含む他の目的に用いられてもよい。ドメインランキングは、さらに広告などの商業サービスの状況で、Ｓ５９２０において値を算出するために用いることができる。例えば、特定のドメインにおける広告の価値は、自動オンラインの広告料を提供するランクベースの方程式にリンクしてもよい。現存する方法を用いることができないようなやり方で、著しいトラフィックを示し始めているウェブサイト開発者を評価し、かつそれに報酬を与えるためにこのようなシステムを用いることができる。例えば、ＴＬＤサーバ、または開示されている情報にアクセスを有する他のべンダーは、潜在的な広告主から特定のランキングに適合するドメインに自動的に提案を提供することができる。前述したように、信頼すべきサーバ、特にＴＬＤサーバの立場から見たときにこれが、潜在的な広告主にとって興味深い可能性のある、事前に認識されていない低レベルのトラフィックサイトを識別可能なことを発明者らは見出した。
【００７２】
本発明の実施形態は、記載した方法を実行するためのシステム、ならびに記載した方法を実行するためにコンピュータを作動させる命令がコード化されたコンピュータ可読記憶媒体を含むことができる。例えば、図６に示すように、プロセッサ、メモリ、および電子通信デバイスを含む電子システム６００は、ＩＳＰサーバ６５０を介してＤＮＳ情報をリクエストするように構成されてもよい。システム６００は、ユーザコンピュータシステム、６２０、６７０などの無線通信装置、６３０、６９０などのサブネットワーク、サーバ、または必須の機能的能力を有する任意の他のネットワーク能力を有するデバイスを含んでもよい。サーバ６５２、６５４はレジストリに関連するＤＮＳサーバの一部として、またはＤＮＳサーバとは独立して操作されてもよい。
【００７３】
システム６００は、第１の記憶装置（不図示、一般的に、ランダムアクセスメモリ、すなわち「ＲＡＭ」）と、第２の記憶装置（不図示、一般的に、読み出し専用メモリ、すなわち「ＲＯＭ」）とを含む記憶装置に連結された任意の数のプロセッサ（不図示）を含む。これらの記憶装置の両方は、前に記載および／または言及した、任意の適した種類のコンピュータ可読媒体を含んでもよい。大容量記憶装置（不図示）もさらにプログラム、データなどの保存に用いられてもよく、通常、これは、主記憶装置よりも遅いハードディスクなどの二次的な記憶媒体である。大容量記憶装置に保持された情報は、適切な場合では、仮想メモリとして、主記憶装置の一部として標準的な方法で組み込まれることが理解されるであろう。ＣＤ−ＲＯＭなどの特定の大容量記憶装置もまた、データをプロセッサに一方向で伝達してもよい。
【００７４】
システム６００は、ビデオモニタ、トラックボール、複数のマウス６０４、キーボード、マイクロホン、タッチセンサ式ディスプレイ、トランスデューサカードリーダ、磁気もしくは紙テープ読取装置、タブレット、複数のスタイラス、音声もしくは手書き文字認識装置、または他のコンピュータ６１０を含む、他の周知の入力デバイスなどの１つ以上の入力／出力デバイスを含むインターフェースも含んでもよい。システム６００は概して６０１で示されるようなネットワーク接続を用いて、コンピュータまたは他の電子通信ネットワーク６９０、６８０に接続されてもよい。ネットワークは種々の有線、光、電子、および他の周知のネットワークにより接続することができ、コンピュータ６１０、サーバ６５０、６５２、６５４、無線通信装置６２０、６７０、およびサブネットワーク６９０、６３０間で情報を交換する。このようなネットワーク接続では、システム６００およびその中のプロセッサがネットワークからの情報を受信する場合があり、または前述の方法のステップを実行する過程で情報をネットワークに出力する場合があることが意図される。前述のデバイスおよび器具は、コンピュータハードウェアおよびソフトウェア技術における当業者に周知であると思われ、当業者に理解されるように個々または包括的に記載する必要はない。前述のハードウェア要素は前述の操作を実行するための１つ以上のモジュールとして（通常、一時的に）機能するように構成されてもよい。
【００７５】
さらに、本発明の実施形態は、種々のコンピュータ実行可能な操作を実行するためのプログラム命令を含むコンピュータ可読記憶媒体をさらに含む。媒体は、プログラム命令、データファイル、データ構造、テーブルなどを単独で、またはそれらの組み合わせで含んでもよい。媒体およびプログラム命令は本発明の主題の目的のために特別に設計および構成されたものであってもよく、またはコンピュータソフトウェア技術における技能を有する当業者に利用可能な種類であってもよい。コンピュータ可読記憶媒体の例は、ハードディスク、フロッピー（登録商標）ディスク、および磁気テープなどの磁気媒体、ＣＤ−ＲＯＭディスクなどの光媒体、フロプティカルディスクなどの光磁気媒体、プログラム命令を保存および実行するように特別に構成された、読み出し専用メモリデバイス（ＲＯＭ）およびランダムアクセスメモリ（ＲＡＭ）などのハードウェアデバイスを含む。プログラム命令の例は、コンパイラなどにより生成されたマシンコード、およびインタープリタを利用するコンピュータにより実行され得る、より高いレベルのコードを含むファイルの両方を含む。
【００７６】
本発明は、例示的な実施形態を参照して記述されてきた。記述した実施形態の変形および変更は、当業者がこの明細書を読解および理解すれば明らかである。本発明は、添付の請求項の範囲内に収まるか、またはその均等物である限りにおいて全てのこのような変形および変更を含むように意図される。
【符号の説明】
【００７７】
１０３、ＤＮＳリクエスト
１１０  クライアントコンピュータデバイス
１２０  モバイル機器
１３０  再帰性のネームサーバ
１４０、１５０、１６０  信頼すべきネームサーバ
２０２、２０３、２０４、２０５  ＤＮＳリクエスト
２１０  クライアント
２２０  再帰性のネームサーバ
２３０、２４０、２５０  信頼すべきネームサーバ
【図１】
2012523625.tif 000016
【図２】
2012523625.tif 000017
【図３】
2012523625.tif 000018
【図４】
2012523625.tif 000019
【図５】
2012523625.tif 000020
【図６】
2012523625.tif 000021
【図７】
2012523625.tif 000022
【図８】
2012523625.tif 000023
【図９】
2012523625.tif 000024
【国際調査報告】
2012523625.tif 000025