JP2013218706A - 限られたリソースの分配を容易にするためのシステムと方法 - Google Patents

Abstract

【課題】限られたリソースを分配する方法を提供する。
【解決手段】方法は、所定の日に期限満了することになる複数の限られたリソースを決定するステップと、複数の限られたリソースを同時に利用可能にするステップと、予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと、限られたリソースと受信されたリソース要求とを相互に関係付けることによって、登録期間の後にリソース要求を処理するステップとを含む。
【選択図】図３

Description

本発明は、限られたリソースの分配に関連し、より詳細には、このようなリソースの分配を容易にするためのサーバと方法に関連する。

背景

ドメイン名は、例えば、ウェブサイトにアクセスするためにコンピューティングデバイス中に入力することができる名前である。グローバルドメイン名システム（ＤＮＳ）中で、ドメイン名がルックアップされ、ＤＮＳは、そのドメイン名に対するインターネットプロトコル（ＩＰ）アドレスを、コンピューティングデバイスに通知する。コンピューティングデバイスは、次に、受信したＩＰアドレスにおいて、サーバにコンタクトすることによって、ウェブサイトにアクセスできる。

“ドメイン保有者”または“登録者”に対して割り当てられているものの、ドメイン名は、ドメイン名レジストリによって制御されている。ドメイン名の一般的な登録について、以下で説明する。各レジストリは、 ．ｃｏｍ、 ．ｏｒｇ、および類似物のような、１つ以上のトップレベルドメインに割り当てられている。ほとんどのドメインレジストリは、ドメイン名を登録するのに、レジストリ−レジストラモデルを実現する。このモデルにおいて、レジストリは、そのレジストラとの関係だけを管理すればよい。代わりに、各レジストラは、その登録者との関係を維持する。

登録者は、レジストラからドメイン名を購入する。レジストラは、レジストリにこの購入を登録する。レジストリは、ＤＮＳを更新して、購入されたドメイン名に対する登録者のＩＰアドレスを反映させる。ドメイン名を使用する権利を維持するために、登録者は年次の期限満了日の前に更新料金を支払う。

レジストラが期限満了日までにドメイン名を更新しない場合、レジストリオペレータによって自動更新が適用されない限り、そのドメイン名は期限満了になる。自動更新に対する猶予期間は、レジストリによって提供されることが多く、自動更新をキャンセルして、そのドメインを削除する削除要求を、レジストラが送ることができるようにしている。

猶予期間の後、レジストラはレジストリからのドメイン名の削除を要求してもよい。削除を要求すると、ドメイン名は、補償猶予期間に入る。補償猶予期間は、一般的に３０日であり、レジストラ（および登録者）が、継続中の削除ステータスからドメイン名を回復させることができるようにし、さらに、彼らが、このドメイン名を更新できるようにする。しかしながら、この期間の間、このドメイン名に関係するすべてのインターネットサービスはディセーブルされる。

補償猶予期間の後、ドメイン名は、ロックされ、補償保持期間に入る。補償保持期間は、一般的に５日間続く。最後の日に、ドメイン名は、レジストリのデータベースから公式にドロップされて、“先着順サービス”のベースで登録に対して利用可能になる。

インターネットの普及によって、ドメイン名は、極めて貴重なマーケティングツールになり得ている。特に、直観的なドメイン名は、一般大衆に情報を利用可能にすることを望む人または会社にとって、非常に有用である。このことは技術的によく知られた概念であり、ドメイン名投機のような実施をもたらしてきた。

したがって、以前に使用されていた、所望のドメイン名が利用可能になるとき、ドメイン名投機に関わる、登録者、および、より一般的には、レジストラは、多額のインセンティブを持ち、対応するレジストリに重い負荷を課す。より詳細には、ドメイン名は、先着順サービスベースで与えられるので、レジストリに対する最も早いアクセス、または、レジストリにアクセスする多くの数の接続を持つ投機者が、以前に使用されていたドメイン名を最初に登録する最良のチャンスを持つことになる。

業界において、大規模な、または、上層のレジストラのいずれにも味方しない、以前に使用されていたドメイン名に対する比較的均等な、または、同等なアクセスを、レジストリが提供することが望ましい。しかしながら、上で説明した先着順サービスモデルを使用することは、複数の代理レジストラを介したレジストリへの最も多数の接続、または、最も強力な機器を有するレジストラに報いている。したがって、このことは、レジストリに対する増加する負荷を絶えず課している、競合レジストラとともに、“武装”レースをエスカレートさせることに帰結し、これによって、レジストリの現在の性能と安定性を脅かしている。

例えば、現在のプロセスを介して、以前に使用されていたドメイン名を捕捉しようとレジストラが試みるときに、レジストリ上で発生される負荷は、通常のレジストリ動作の間に発生されるものより数倍大きい。したがって、レジストリは、それが通常動作に対して一般的に要求されることになるものよりもかなり大きいピーク帯域を収容することを維持しなければならない。この小さい割合の競合するレジストラに対処するために、レジストリにおいてリソースを増加させ続けることは、レジストリに対してエスカレートし続ける追加の費用をもたらすので、不適切な解法である。

さらに、より小さいレジストラは、より大きいレジストラと競合するリソースを持っていないことが多いので、現在のプロセスは、日次ベースでレジストリによって削除されている、以前に使用されていたドメイン名のリストに対する公平かつ均等なアクセスを制限している。

したがって、本発明の目的は、上に説明した少なくともいくつかの問題を未然に防ぐ、または軽減する、以前に使用されていたドメイン名を取得するメカニズムを提供することである。

本発明のある観点にしたがうと、限られたリソースを分配する方法が提供され、方法は、所定の日に期限満了することになる複数の限られたリソースを決定するステップと；複数の限られたリソースを同時に利用可能にするステップと；予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと；限られたリソースと受信されたリソース要求とを相互に関係付けることによって、登録期間の後に、リソース要求を処理するステップとを含む。

本発明のさらなる観点にしたがうと、限られたリソースを分配するシステムが提供され、システムは、標準アプリケーションサーバ機能を提供するように構成されているメインサーバと；限られたリソースに対するリソース要求を受信するように構成されているドロップゾーンサーバと；限られたリソースが、いつメインサーバにおいて期限満了するかを決定し、対応するリソース要求に対してドロップゾーンサーバをパースし、これにしたがって限られたリソースを分配するように構成されているドロップゾーン制御モジュールとを具備する。

上で説明したシステムにおいて、ドロップゾーンサーバは、複数の限られたリソースを同時に利用可能にするようにさらに構成されていてもよい。

本発明の実施形態を、以下の図を参照して、例としての目的のみで、ここで説明する。

図１は、ドロップゾーンインフラストラクチャのブロック図である。 図２は、利用可能になった以前に使用されていたドメイン名に対する登録プロセスを図示するフローチャートである。 図３は、図２の登録要求プロセスをより詳細に図示するフローチャートである。 図４は、図２の登録遂行プロセスをより詳細に図示するフローチャートである。

好ましい実施形態の詳細な説明

利便性のために、詳細な説明中の同じ番号は、図面中の同じ構造を指す。図１を参照して、ドロップゾーンインフラストラクチャを番号１００によって一般的に図示する。ドロップゾーンインフラストラクチャ１００は、１つ以上のレジストラ１０２と、１つ以上のドロップゾーンサーバ１０４と、１つ以上のメインレジストリサーバ１０６と、ドロップゾーン制御モジュール１０８とを含む。

レジストラ１０２は、通信ネットワーク１１０を介して、ドロップゾーンサーバ１０４と、メインレジストリサーバ１０６との両方と通信している。理解されることになるように、通信ネットワーク１１０は、インターネットのようなワイドエリアネットワーク（ＷＡＮ）、または、ローカルエリアネットワーク（ＬＡＮ）であってもよい。

ドロップゾーンサーバ１０４は、ドロップゾーン制御モジュール１０８と通信しており、ドロップゾーン制御モジュール１０８は、メインレジストリサーバ１０６と通信している。ドロップゾーン制御モジュール１０８を個別のデバイスとして図示したが、ドロップゾーンサーバ１０４またはメインレジストリサーバ１０６のいずれかの一部として、ドロップゾーン制御モジュール１０８を組み込むことができることが理解されるだろう。さらに、レジストラ１０２は、ドロップゾーンサーバ１０４またはメインレジストリサーバ１０６のいずれかで、あるいは、ドロップゾーンサーバ１０４とメインレジストリサーバ１０６の両方でセットアップされた、対応するアカウントを持ち、サービスの支払を容易にしている。ドロップゾーンインフラストラクチャ１００の異なる構成が、当業者にとって明らかになるだろう。

事実上、ドロップゾーンサーバ１０４は、限られたレジストリシステムを提供する。したがって、ドロップゾーンサーバは、限られた数のコマンドをサポートする。この実施形態では、ドロップゾーンサーバ１０４は、３つの主要なコマンドをサポートする。すなわち、ログインと；ドメイン作成と；拡張可能供給プロトコル（ＥＰＰ）ハローとである。ＥＰＰは、レジストラ１０２と、メインレジストリサーバ１０６との間で使用するための、標準インターネットドメイン名登録プロトコルを提供する。ＥＰＰは、技術的によく知られており、詳細に説明する必要はない。レジストラ１０２によって、ログインコマンドを使用して、ドロップゾーンサーバ１０４にアクセスする。ドメイン作成を使用して、ドメイン名を要求する。ＥＰＰハローを使用して、レジストラ１０２によるドロップゾーンサーバ１０４に対する接続を確認する。

ドロップゾーン制御モジュール１０８は、利用可能なドメイン名と、ドロップゾーンサーバ１０４に出された登録要求とにしたがって、要求されたドメイン名の分配を制御する。したがって、ＤＮＳレジストリを維持することと、ＤＮＳ解決クエリをサービスすることのようなタスクに対して、メインレジストリサーバ１０６が使用されることが理解されるだろう。ドロップゾーンサーバ１０４に対する接続は、高度に制限することができ、レジストラの間で均等にすることができる。例えば、各レジストラ１０２を、ドロップゾーンサーバ１０４に対する３つの接続に制限することができる。このことは、ドロップゾーンサーバ１０４と、メインレジストリサーバ１０６とに対する、個別の接続ポリシーを維持する能力と、スケーラビリティとを提供する。

さらに、それらの補償保持期間の終わりに到達した、以前に使用されていたドメイン名の同期化されたフル解放を管理するメインレジストリサーバ１０６から分離されたシステムを、ドロップゾーンサーバ１０４が提供することが理解できる。以前に使用されていたドメイン名がドロップゾーンサーバ１０４を介して解放され、すなわち、ドロップされるときに、ドメイン名を得るために、レジストラ１０２が、メインレジストリサーバ１０６に対する多数の接続を維持するインセンティブを持つことがより少なくなり、または、より少ないインセンティブを持つことになる。

図２を参照して、ドロップゾーンインフラストラクチャ１００を使用して、ドメイン名を登録するプロセスを図示するフロー図を、番号２００によって一般的に示す。ステップ２０２において、レジストラは、登録のために利用可能な以前に使用されていたドメイン名に対する登録要求を、ドロップゾーンサーバ１０４に出す。ステップ２０４において、ドロップゾーン制御モジュール１０６は、ドメイン名サーバ１０４によって受信された登録要求をパースして、これにしたがって、以前に使用されていたドメイン名を割り当てる。ステップ２０２と２０４との両方を、図３、および４を参照して、より詳細に説明する。

図３を参照すると、フロー図は、以前に使用されていたドメイン名の登録を要求するステップ２０２をより詳細に図示する。ステップ３０２において、レジストラ１０２は、ドロップゾーンサーバ１０４に接続する。レジストラ１０２は、ＥＰＰハローコマンドを使用して、ドロップゾーンサーバ１０４に対する彼らの接続を最初にテストできる。しかしながら、ドメイン作成コマンドを使用して、以前に使用されていたドメイン名をこの時点において登録しようとすることは、エラーになるだろう。

ステップ３０４において、それに対する補償保持期間がその日に期限満了する、複数の以前に使用されていたドメイン名は、すべてのレジストラに対して同時に、登録のためにアクセス可能にされる。この実施形態では、用語、日は、カレンダー日付を指すが、これは何らかの予め規定された時間期間であってもよいことが理解されるだろう。さらに、この実施形態では、それに対する補償保持期間がその日に期限満了する、すべての以前に所有されていたドメイン名がアクセス可能にされる。

ステップ３０６において、レジストラ１０２がドロップゾーンサーバ１０４との接続を確立できるようにする予め規定された時間において、ドロップゾーンサーバ１０４のステータスに対して変更が行われ、ドロップゾーンサーバ１０４がドメイン名登録に対して開かれる。一度ドロップゾーンサーバ１０４が開かれると、レジストラ１０２は、所望のドメイン名に対する登録要求を出すことができる。レジストラ１０２は、その日の解放に対して列挙されている、以前に使用されていたドメイン名に対してのみ登録してもよい。日次で発行され、すべてのレジストラ１０２に対して提供される、補償保持期間ドメイン報告によって、この情報が、それぞれのレジストラ１０２にとって利用可能になる。

ステップ３０８において、ドロップゾーンサーバ１０４は、受信した登録要求を記録し、これらが受信された順序でこれらを維持する。当業者によって理解されるように、このことは、さまざまな異なる方法で達成することができる。例えば、先入れ先出し方式（ＦＩＦＯ）キューにおいて、登録要求を維持してもよい。代わりに、登録要求とともに、登録要求を受信した時間を記憶させてもよい。この例では、時間の解決が、連続的な登録要求の間を区別するのに十分である。したがって、登録要求の順序が維持されているので、ドロップゾーンサーバ１０４は、複製された登録要求を受け入れる。

この実施形態では、登録要求が、利用可能な以前に使用されていたドメイン名に対するものであることを確かめることは、レジストラ１０２の責任である。レジストラ１０２が、正しくない登録要求、例えば、発行された報告中にないドメイン名に対する登録要求を出した場合、結果はエラーとなり、ドロップゾーン制御モジュール１０８により処理されない。オプション的に、レジストラは、ドロップゾーンサーバ１０４からのエラーメッセージを介して、エラーを忠告される。

ステップ３１０において、予め規定された時間の後に、ドロップゾーンサーバ１０４のステータスに対する変更が行われ、ドロップゾーンサーバ１０４は、その日のドメイン名登録に対して閉じられる。例として、ドロップゾーンサーバ１０４は、２時間の間、開いたままでいる。しかしながら、登録に対して利用可能な、すべての以前に所有されていたドメイン名が同時に解放されるので、これらは、数分間以内に予約済みになってしまうことが多いことが理解されるだろう。

図４を参照すると、以前に所有されていたドメイン名を割り当てるステップ２０４をより詳細に図示するフロー図である。ステップ４０２において、ドロップゾーン制御モジュール１０８は、メインレジストリサーバ１０６によって維持される、以前に所有されていたどのドメイン名が、その日にそれらの補償保持期間を完了しているかを決定する。

ステップ４０４において、それぞれの予め使用されていたドメイン名に対する、補償保持期間が期限満了するとき、ドロップゾーン制御モジュール１０８は、対応する登録要求がドロップゾーンサーバ１０４に対して出されているか否かを決定する。以前に使用されていたドメイン名に対する何の対応する登録要求も受信されていなかった場合、プロセスはステップ４０６に続く。ステップ４０６において、以前に使用されていたドメイン名は、メインレジストリサーバ１０６から削除され、技術的に標準的な方法で解放される。

以前に使用されていたドメイン名に対して、対応する登録要求が受信された場合、プロセスはステップ４０８に続く。ステップ４０８において、ドロップゾーン制御モジュール１０８は、その以前に使用されていたドメイン名に対して、最初に受信された登録要求を検索する。ステップ４１０において、ドロップゾーン制御モジュール１０８は、登録要求を出したレジストラ１０２が、その対応するアカウント中に、登録要求に対して支払うための十分な資金を持っているか否かを決定する。

アカウント中に十分な資金がある場合、ドロップゾーン制御モジュール１０８は、ステップ４１２に続く。ステップ４１２において、ドロップゾーン制御モジュール１０８は、登録要求を処理する。すなわち、以前に使用されていたドメイン名に対する古い登録情報が削除され、レジストラ１０２によって提供された新しい登録情報に置き換えられる。レジストラの対応するアカウントは登録に対して課金される。

しかしながら、アカウント中の資金が不十分である場合、ドロップゾーン制御モジュール１０８は、ステップ４１４に続く。ステップ４１４において、ドロップゾーン制御モジュール１０８は、以前に使用されていたドメイン名に対する、何らかのさらなる登録要求があるか否かを決定する。

以前に使用されていたドメイン名に対する、さらなる登録要求が何もない場合、ドロップゾーン制御モジュール１０８は、ステップ４０６に続き、以前に使用されていたドメインは、上に説明したように解放される。しかしながら、以前に使用されていたドメイン名に対する、さらなる登録要求がある場合、ドロップゾーン制御モジュール１０８は、ステップ４１６に続く。ステップ４１６において、ドロップゾーン制御モジュール１０８は、ドロップゾーンサーバ１０４から次のシーケンシャルな登録要求を検索する。

以前に説明したように、この実施形態では、その中で複製された登録要求がドロップゾーンサーバ１０４によって受信されたシーケンスが維持される。ドロップゾーン制御モジュール１０８は、ステップ４１０に戻って、次のシーケンシャルな登録要求を出したレジストラ１０２が、その対応するアカウント中に、登録要求に対して支払うための十分な資金を持っているか否かを決定する。その特定の日に対する、日次の補償保持期間報告中に列挙されている以前に使用されていたドメイン名に対して、このプロセスは実現される。

レジストラ１０２は、日次の結果報告を介して、登録要求が成功したことを通知される。日次の結果報告は、上で説明した分配プロセスの完了に続いて、結果を列挙する。この実施形態では、日次の結果報告は、それぞれのレジストラ１０２に対する専用のものである。この時点の後に、レジストラ１０２は、メインレジストリサーバ１０６との以前に使用されていたドメイン名の登録を確認できる。

したがって、上に説明したような以前に使用されていたドメイン名の登録が公平性を改善し、この中でドメイン名が分配されることが理解されるだろう。特に、レジストラ１０２による接続の数をかなり制限することができ、複数のドメイン名が同時に利用可能になるので、レジストラ１０２は、彼らが登録しようとすることになる、以前に使用されていたドメイン名に優先順位をつけなければならない。この特徴は、以前に使用されていたドメイン名が、レジストラの間でより公平に分配されることになる見込みを増加させる。

これまでの実施形態は、以前に使用されていたドメイン名の分配に特に関連するが、当業者は、本発明がこのように制限される必要のないことを理解するだろう。むしろ、同じ解法を実現して、類似の問題を解決してもよい。すなわち、限られたリソースに対して競合している、多数の異なる入札者がいるとき、上で説明した解法を実現してもよい。

例えば、限られたリソースが、新しく解放されたドメイン名であるケースを考慮する。このことは、新しいトップレベルドメインの解放に伴って、または、既存のトップレベルドメインのために以前は差し控えられていたドメイン名の解放に伴って発生してもよい。このような解放は、以前に使用されていたドメイン名の解放と同様の問題をもたらすだろう。したがって、上で説明したシステムと方法を実現して、これらのドメイン名の分配を容易にすることができる。

別の例として、限られたリソースが、以前に使用されていたドメイン名というよりはむしろ、オークションのアイテムであるケースを考慮する。所定の時間期間の間に、オークションが期限満了したすべてのアイテムへの入札に対して、ドロップゾーンサーバ１０４を開くことができる。上で説明した実施形態と同様に、入札者は、それぞれのオークションアイテムにフォーカスできるというよりはむしろ、彼らの入札に優先順位をつけなければならないだろう。このことは、代わりに、より多くの入札者が、少なくとも１つの入札において成功することになる見込みを増加させる。

ある特定の実施形態を参照して、本発明を説明したが、本発明のさまざまな修正が、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく当業者に明らかになるだろう。

ある特定の実施形態を参照して、本発明を説明したが、本発明のさまざまな修正が、添付の特許請求の範囲によって規定される本発明の範囲から逸脱することなく当業者に明らかになるだろう。
以下に、本願出願の当初の特許請求の範囲に記載された発明を付記する。
［１］限られたリソースを分配するシステムにおいて、
標準アプリケーションサーバ機能を提供するように構成されているメインサーバと；
前記限られたリソースに対するリソース要求を受信するように構成されているドロップゾーンサーバと；
前記限られたリソースがいつ前記メインサーバにおいて期限満了するかを決定し、対応するリソース要求に対して前記ドロップゾーンサーバをパースし、これにしたがって前記限られたリソースを分配するように構成されているドロップゾーン制御モジュールと
を具備するシステム。
［２］前記ドロップゾーンサーバは、複数の限られたリソースを同時に利用可能にするようにさらに構成されている、上記［１］のシステム。
［３］前記複数の限られたリソースは、所定の日に期限満了するすべての限られたリソースを含む、上記［２］のシステム。
［４］前記ドロップゾーンサーバと前記メインサーバは、異なる接続ポリシーを持つ、上記［２］のシステム。
［５］前記ドロップゾーンサーバ接続ポリシーは、それぞれのクライアントを３つの接続までに制限する、上記［４］のシステム。
［６］前記限られたリソースは、以前に使用されていたドメイン名であり；前記リソース要求は登録要求であり；前記メインサーバは、ドメイン名システム機能を提供するように構成されているメインレジストリサーバである、上記［２］のシステム。
［７］前記限られたリソースは、新しいドメイン名であり；前記リソース要求は登録要求であり；前記メインサーバは、ドメイン名システム機能を提供するように構成されているメインレジストリサーバである、上記［２］のシステム。
［８］前記限られたリソースは、オークションアイテムであり；前記リソース要求は、前記限られたリソースへの入札であり；前記メインサーバは、オークション機能を提供するように構成されているメインオークションサーバである、上記［２］のシステム。
［９］限られたリソースを分配する方法において、
予め定められた期限満了期間の間に期限満了する複数の限られたリソースを決定するステップと；
前記複数の限られたリソースを同時に利用可能にするステップと；
予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと；
前記限られたリソースと、前記受信されたリソース要求とを相互に関係付けることによって、前記登録期間の後に、前記リソース要求を処理するステップと
を含む方法。
［１０］前記複数の限られたリソースは、所定の日の間に期限満了する、すべての限られたリソースを含む、上記［９］の方法。
［１１］前記限られたリソースは、それらが期限満了するときに処理される、上記［９］の方法。
［１２］複製されたリソース要求が維持され、これらが受信されたシーケンスで処理される、上記［９］の方法。
［１３］前記リソース要求のうちの１つが失敗する場合、後続する複製されたリソース要求が処理される、上記［１２］の方法。
［１４］前記リソース要求は、要求しているクライアントの対応するアカウント中の、資金が不十分なためによって失敗する、上記［１３］の方法。
［１５］それぞれのクライアントに割り当てられている、前記リソース要求を出すための接続の数は制限されている、上記［９］の方法。
［１６］前記リソース要求を可能にする以前に接続期間を提供して、クライアントが接続を確立できることをクライアントが確認できるようにするステップをさらに含む、上記［９］の方法。
［１７］前記限られたリソースは、以前に使用されていたドメイン名であり；前記リソース要求は登録要求であり；前記クライアントはレジストラである、上記［９］の方法。
［１８］前記限られたリソースは、新しいドメイン名であり；前記リソース要求は登録要求であり；前記クライアントはレジストラである、上記［９］の方法。
［１９］前記限られたリソースは、オークションアイテムであり；前記リソース要求は前記限られたリソースへの入札であり；前記クライアントは入札者である、上記［９］の方法。
［２０］コンピュータによって実行されるときに、前記コンピュータにステップを実現させる命令を有するコンピュータ読取可能媒体において、
前記ステップは、
所定の日に期限満了する複数の限られたリソースを決定するステップと；
前記複数の限られたリソースを同時に利用可能にするステップと；
予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと；
前記限られたリソースと、前記受信されたリソース要求とを相互に関係付けることによって、前記登録期間の後に、前記リソース要求を処理するステップと
を含むコンピュータ読取可能媒体。

Claims (20)

1. 限られたリソースを分配するシステムにおいて、
   標準アプリケーションサーバ機能を提供するように構成されているメインサーバと；
   前記限られたリソースに対するリソース要求を受信するように構成されているドロップゾーンサーバと；
   前記限られたリソースがいつ前記メインサーバにおいて期限満了するかを決定し、対応するリソース要求に対して前記ドロップゾーンサーバをパースし、これにしたがって前記限られたリソースを分配するように構成されているドロップゾーン制御モジュールと
   を具備するシステム。
2. 前記ドロップゾーンサーバは、複数の限られたリソースを同時に利用可能にするようにさらに構成されている、請求項１記載のシステム。
3. 前記複数の限られたリソースは、所定の日に期限満了するすべての限られたリソースを含む、請求項２記載のシステム。
4. 前記ドロップゾーンサーバと前記メインサーバは、異なる接続ポリシーを持つ、請求項２記載のシステム。
5. 前記ドロップゾーンサーバ接続ポリシーは、それぞれのクライアントを３つの接続までに制限する、請求項４記載のシステム。
6. 前記限られたリソースは、以前に使用されていたドメイン名であり；前記リソース要求は登録要求であり；前記メインサーバは、ドメイン名システム機能を提供するように構成されているメインレジストリサーバである、請求項２記載のシステム。
7. 前記限られたリソースは、新しいドメイン名であり；前記リソース要求は登録要求であり；前記メインサーバは、ドメイン名システム機能を提供するように構成されているメインレジストリサーバである、請求項２記載のシステム。
8. 前記限られたリソースは、オークションアイテムであり；前記リソース要求は、前記限られたリソースへの入札であり；前記メインサーバは、オークション機能を提供するように構成されているメインオークションサーバである、請求項２記載のシステム。
9. 限られたリソースを分配する方法において、
   予め定められた期限満了期間の間に期限満了する複数の限られたリソースを決定するステップと；
   前記複数の限られたリソースを同時に利用可能にするステップと；
   予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと；
   前記限られたリソースと、前記受信されたリソース要求とを相互に関係付けることによって、前記登録期間の後に、前記リソース要求を処理するステップと
   を含む方法。
10. 前記複数の限られたリソースは、所定の日の間に期限満了する、すべての限られたリソースを含む、請求項９記載の方法。
11. 前記限られたリソースは、それらが期限満了するときに処理される、請求項９記載の方法。
12. 複製されたリソース要求が維持され、これらが受信されたシーケンスで処理される、請求項９記載の方法。
13. 前記リソース要求のうちの１つが失敗する場合、後続する複製されたリソース要求が処理される、請求項１２記載の方法。
14. 前記リソース要求は、要求しているクライアントの対応するアカウント中の、資金が不十分なためによって失敗する、請求項１３記載の方法。
15. それぞれのクライアントに割り当てられている、前記リソース要求を出すための接続の数は制限されている、請求項９記載の方法。
16. 前記リソース要求を可能にする以前に接続期間を提供して、クライアントが接続を確立できることをクライアントが確認できるようにするステップをさらに含む、請求項９記載の方法。
17. 前記限られたリソースは、以前に使用されていたドメイン名であり；前記リソース要求は登録要求であり；前記クライアントはレジストラである、請求項９記載の方法。
18. 前記限られたリソースは、新しいドメイン名であり；前記リソース要求は登録要求であり；前記クライアントはレジストラである、請求項９記載の方法。
19. 前記限られたリソースは、オークションアイテムであり；前記リソース要求は前記限られたリソースへの入札であり；前記クライアントは入札者である、請求項９記載の方法。
20. コンピュータによって実行されるときに、前記コンピュータにステップを実現させる命令を有するコンピュータ読取可能媒体において、
    前記ステップは、
    所定の日に期限満了する複数の限られたリソースを決定するステップと；
    前記複数の限られたリソースを同時に利用可能にするステップと；
    予め定められた時間において開始する登録期間の間、複数のクライアントからのリソース要求を可能にするステップと；
    前記限られたリソースと、前記受信されたリソース要求とを相互に関係付けることによって、前記登録期間の後に、前記リソース要求を処理するステップと
    を含むコンピュータ読取可能媒体。

Images