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