Skip to main content
Resources

レジストリ契約の譲渡

このページは以下の言語でもご覧いただけます。

すべての翻訳されたコンテンツおよび文書の英語版が公式版であり、英語以外の言語の翻訳版は情報提供のみを目的として作成されたものです。

レジストリ契約の譲渡は、レジストリオペレータがレジストリ契約に基づく権利および/または義務のいずれかを現在のレジストリオペレータから他の組織に移転する場合に発生します。これらのトランザクションは、以下のように分類されます。

ICANN組織は、トップレベルドメイン(「TLD」)を運営すると予想される組織を理解・評価し、この組織が引き続きTLDの安全性、安定性、かつ弾力的な運営を可能にするという妥当な保証を得るために適正評価を実施します(たとえば、ICANN組織は財源/運営/技術面の能力および/またはトランザクション構造を評価し、背景審査を実施することがあります)。また、譲渡はレジストリ移行プロセスの対象になります。詳細はレジストリ移行プロセスのWebページをご覧ください。

完了した譲渡を見る

譲渡プロセス

譲渡タイプ別に編成された譲渡要求を提出するための通常の手順を以下に示します。以下の手順は、命名サービスポータル(NSp)でサービス要求のケースを提出する前に、レジストリオペレータが検討するべき重要事項と、レジストリの準備項目を示しています。

提出前の留意点と準備

提出前に、ICANN組織はレジストリオペレータに以下の事項を推奨しています。

  • レジストリ契約の該当セクションを確認する。
  • 以下の譲渡タイプと譲渡で必要となる情報を確認する。
  • 提案する譲渡に適用するタイプを検討する。
  • アカウントマネージャへの電話相談を行い、提案されたトランザクションやタイミングを確認し、質問事項を相談する。電話相談を行うには、命名サービスポータル(NSp)で一般的な問い合わせのケースを開くか、またはアカウントマネージャに直接問い合わせます。*
  • 提出する情報と文書を準備する。サービス要求のケースの提出に関する詳細な手順については、レジストリ向けICANN命名サービスポータルユーザーガイドを確認してください。

*このような問い合わせは、レジストリ契約で要求される譲渡または支配権移転の通知とはみなされません。レジストリオペレータは、ICANN組織との協議を法律、ビジネスまたは税務上の助言として解釈しないものとします。各レジストリオペレータは、提案された譲渡に関する法律、ビジネス、税務などの事項について、自身の弁護士、会計士などの専門の顧問に相談すべきです。

関連する譲受人への譲渡

提案された譲受人が関連する譲受人(レジストリ契約のセクション7.5(f)に定義)であり、関連する譲受人がレジストリ契約の条件を書面にて明示的に引き受けた場合に発生します。

  1. 要求の提出 – NSpでケースを開始するには、譲渡人は「Assignment to Affiliate」を選択する必要があります。譲渡人は、必要な情報と文書をICANN組織に提供し、審査を受けなければなりません。詳細については、譲渡で必要となる情報をご覧ください。
  2. ICANNによる審査 – ICANN組織は、提出された情報、回答、および補足文書を審査します。
  3. 判断 – レジストリオペレータが要件を満たした後、ICANN組織は譲渡確認書をもって譲渡を確認します。ICANNは、該当する譲渡および引受契約の公表を含め、ICANN Webページに譲渡を反映させます。

既存レジストリオペレータへの譲渡

提案された譲受人が少なくとも1つのgTLDの既存レジストリオペレータであり(ただし、その既存レジストリオペレータが、運営対象のgTLDに適用されるレジストリ契約の条件を遵守している場合に限ります)、関連する譲受人でない場合に発生します。

  1. 要求の提出 – NSpでケースを開始するには、譲渡人は「Assignment to Existing Registry Operator」を選択する必要があります。譲渡人は、必要な情報と文書をICANN組織に提供し、審査を受けなければなりません。ICANN組織は、提案された譲受人向けに別のケースを開きます。下記のICANNによる審査に記載されるように、ICANN組織が10暦日以内に要求を審査するために必要な時間を確保するため、提案された譲受人はケースを受け取ってから2暦日以内に、NSpで審査に必要な情報と文書をICANN組織に提供する必要があります。詳細については、譲渡で必要となる情報をご覧ください。

  2. ICANNによる審査 – ICANN組織は、提出された情報、回答、および補足文書を審査し、ICANNが提案された譲渡の通知を受け取ってから10暦日以内に回答します。

  3. 判断 – ICANN組織は、提案された譲渡要求に対して、以下のいずれかの回答を提供します。
    • 条件付き同意 – ICANN組織は、条件付き同意を発行できます。これは、特定の条件を満たすことを条件として、ICANNが譲渡要求を承認するものです。これらの条件は通常、譲渡人と提案された譲受人に対して、譲渡および引受契約、データエスクロー契約および/または継続的運用証書を含む追加文書の提出を要求します。

      なお、このような追加文書は、ICANNの条件付き同意が与えられるまでは実行してはなりません。ICANN組織は追加文書の審査を行い、十分であれば(ただし、提案された譲受人が、条件を満たした時点で運営対象のgTLDに適用されるレジストリ契約の条件を遵守している場合に限ります)、ICANN組織は最終的な同意を与え、同意の条件解除を通じて譲渡要求を承認します。ICANN組織は続いて、該当する譲渡および引受契約の公表を含め、ICANN Webページに譲渡を反映させます。

    • 異議申し立ておよび/または追加情報の要求 – 提出された情報、回答、または文書が、条件付き同意の手続きを進めるには不十分である場合、または適切な期間内に提供されない場合、ICANN組織は提案された譲渡要求に異議を申し立てることがあります。ICANN組織が提案された譲渡をさらに評価するために追加情報を要求した場合、譲渡人は要求された情報を15暦日以内に提供する必要があります。

新規レジストリオペレータへの譲渡

提案された譲受人が既存のレジストリオペレータではなく、また関連する譲受人でない場合に発生します。詳細は、「新規レジストリオペレータへの譲渡:譲渡人の情報」を参照してください。

  1. 要求の提出 – NSpでケースを開始するには、譲渡人は「Assignment to New Registry Operator」を選択する必要があります。譲渡人は、必要な情報と文書をICANN組織に提供し、審査を受けなければなりません。ICANN組織は、提案された譲受人向けに別のケースを開きます。ICANN組織と外部プロバイダが要求を審査するために必要な時間を確保するため、提案された譲受人はケースを受け取ってから5暦日以内に、NSpで審査に必要な情報と文書をICANN組織に提供する必要があります。詳細については、譲渡で必要となる情報をご覧ください。

  2. ICANNによる審査 – 背景審査および財務評価は外部プロバイダによって実施され、提案された譲受人は評価費用を負担します。ICANN組織は、評価結果だけでなく、提出された情報、回答、補足文書を審査し、ICANNが提案された譲渡の通知を受け取ってから30暦日以内に回答します。

  3. 判断 – ICANN組織は、提案された譲渡要求に対して、以下のいずれかの結果を提供します。
    • 条件付き同意 – ICANN組織は、条件付き同意を発行できます。これは、特定の条件を満たすことを条件として、ICANNが譲渡要求を承認するものです。これらの条件は通常、譲渡人と提案された譲受人に対して、譲渡および引受契約、データエスクロー契約および/または継続的運用証書を含む追加文書の提出を要求します。

      なお、このような追加文書は、ICANNの条件付き同意が与えられるまでは実行してはなりません。ICANN組織は追加文書の審査を行い、十分であれば、ICANN組織は最終的な同意を与え、同意の条件解除を通じて譲渡要求を承認します。ICANN組織は続いて、該当する譲渡および引受契約の公表を含め、ICANN Webページに譲渡を反映させます。

    • 同意の保留および/または追加情報の要求 – 提出された情報、回答、または文書が、条件付き同意の手続きを進めるには不十分である場合、または適切な期間内に提供されない場合、ICANN組織は提案された譲渡要求への同意を保留することがあります。ICANN組織が提案された譲渡をさらに評価するために追加情報を要求した場合、譲渡人は要求された情報を15暦日以内に提供する必要があります。

提案された譲受人は、外部プロバイダが実施した評価について発生した費用を負担する責任を負います。費用はトランザクションの性質により異なりますが、一般的には新しいレジストリオペレータへの1回のTLDの譲渡で19,000米ドルを超えることはありません。

リソース

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."