Skip to main content
Resources

レジストラ移転の紛争解決ポリシー

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

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

登録データポリシーの実施に必要な変更を反映するため、2024年2月21日に更新。契約当事者は2024年8月21日から更新された本ポリシーを実施することが可能であり、遅くとも2025年8月21日までには実施する必要があります。

注:2020年1月26日、ICANN理事会は、標準認証フォーム(FOA)により移転連絡先からのレジストラ間移転の明示的な認証を得る取得レジストラの要件の契約コンプライアンス執行を延期する決議を可決しました。ICANN契約遵守は、移転ポリシーのI(A)(2.1)項の執行を、現在進行中のGNSO同案件の評議会による移転ポリシーの審査での解決まで延期しており、引き続き延期する予定です。従って、新レジストラの標準承認フォーム(FOA)がない場合、移転紛争解決ポリシーの3.2.4(ii)項に基づく移転の取り消しは裁定されないものとします。

あらゆるレジストラ間のドメイン名移転に関連する紛争においては、第一に、その紛争に関与しているレジストラ間の問題をレジストラで解決することが推奨されます。これで解決されず、いずれかのレジストラが紛争の申し立てを選択する場合には、以下の手続きが適用されます。レジストラでは、紛争の申し立てを行う前に、本書で説明されている移転の紛争解決ポリシー(TDRP)をよく理解しておくことが重要です。移転の紛争解決には相当な料金が必要になる可能性があります。レジストラでは、支払われる必要のある料金について、および当事者のどちらがそれらの料金支払いの責任を負うのか、いつ、どのような方法でそれらの料金が支払われる必要があるのかについて完全に理解しておくことが不可欠です。

TDRPのこのバージョンとそれに対応する手続きは、2016年12月1日以降に提出されたすべての申し立てに適用されます。

  1. 定義

    1.1 申立人

    TDRPに基づいて申し立てを提出する当事者。申立人とは、本ポリシーに基づき、現レジストラ(不正な移転が疑われる場合)または新レジストラ(不適切なNACKの場合)のいずれかです。

    1.2 苦情申し立て

    申立人が被申立人に対して提起した申し立てと請求を提示する、TDRP手続きにおける最初の文書です。

    1.3 紛争解決パネル

    紛争解決パネルとは、TDRPに基づく紛争に関する申し立てを解決するために、紛争解決プロバイダ(「プロバイダ」)が任命する管理パネルのことです。

    1.4 紛争解決プロバイダ

    紛争解決プロバイダは、被申立人、申立人、または紛争に関与しているドメイン名が登録されたレジストリオペレータとは関連も提携関係もない独立した中立の第三者でなければなりません。ICANNは、TDRPに準拠して策定された基準に従って1つまたは複数の独立した中立の紛争解決プロバイダを認定する権限を有するものとします。

    1.5 FOA(承認フォーム)

    新レジストラおよび現レジストラが要求される可能性のある標準の同意フォーム1で、レジストラ間でのドメイン名のスポンサーシップの移転を適切に処理するために、レジストラントから承認を得るために使用されます。

    1.6 新レジストラ

    移転申請を提出することで、管理レジストラになろうとするレジストラ。

    1.7 無効な移転

    移転ポリシーに準拠していないことが判明した移転。

    1.8 現レジストラ

    ドメイン移転申請の提出時に管理レジストラであったレジストラ。

    1.9 NACK

    移転申請の現レジストラによる拒否。

    1.10 レジストラント

    特定のドメイン名を一定期間使用する権利を有する個人、組織、または団体です。

    1.11 管理レジストラ

    レジストリにおいてドメイン名のスポンサーとなっているレジストラです。

    1.12 レジストリ(レジストリオペレータ)

    特定のTLDの登録サービスをICANN認可のレジストラに提供することがICANNによって承認された組織です。

    1.13 被申立人

    苦情を申し立てられた当事者。TDRPの下で、被申立人は、不適切な(NACK)場合には現レジストラとなり、不正な移転が疑われた場合には新レジストラとなり、または管理レジストラとなります。

    1.14 補則

    補則は、TDRPを補完するために、紛争解決手続きを行うプロバイダが採用した規則を意味することとします。補則は、TDRPまたは規則と矛盾しないものであり、料金、語数やページ数の制限とそのガイドライン、プロバイダとの連絡手段、および表紙の書式等を定めるものとします。

    1.15 移転ポリシー

    レジストラとレジストリの間で締結されたレジストリ-レジストラ契約、およびICANNとすべてのICANN認定レジストラとの間で締結されたレジストラ認定契約で言及されている、レジストラ間の登録スポンサーシップの移転を規定するICANNコンセンサスポリシーです。

  2. 紛争解決プロセス

    2.1 苦情の申し立て

    申立人は、紛争解決プロバイダに苦情を申し立てることができます。TDRPの3.4項に従って管轄裁判所に上訴される場合を除き、紛争解決パネルの裁決は最終的なものです。

    2.2 出訴期限

    紛争は、移転ポリシーに対する違反の疑いが生じてから12か月以内に申し立てなければなりません。現レジストラが移転を移転ポリシーの違反として申し立てる場合、移転が完了した日が「違反の申し立て日」とみなされるものとします。新レジストラが移転の不履行を申し立てる場合、レジストリがNACK(以下で定義)を受領した日が「違反の申し立て日」とみなされるものとします。

  3. 紛争手続き

    3.1 レジストラが、執行請求を紛争解決レジストラに申し立てます。

    3.1.1 新レジストラまたは現レジストラのどちらかが申し立てを提出することができます。これは、該当の紛争解決プロバイダが採択した補足規則に従って行われなければなりません。

    3.1.2 申し立ては、紛争解決プロバイダおよび被申立人に電子形式で提出されるものとし、以下の内容であるものとします。

    1. TDRPおよび該当する補則に準拠して申し立てに対して裁定が下されることを要求する。

    2. 申立人、および申立人が認定し、管理手続きで申立人に代わって行動する代理人の氏名、郵送先住所、電子メール アドレス、電話番号、およびファックス番号を提供する。

    3. 被申立人、または被申立人の代理人への連絡方法に関して申立人が知っている、被申立人の氏名およびすべての情報(郵送先住所、電子メールアドレス、電話番号、およびファックス番号を含む)を提供する。

    4. 申し立ての対象であるドメイン名を明記する。

    5. 紛争の原因となったインシデントを明記する。

    6. 移転ポリシーに従って、申し立ての根拠を記述する。特に以下の点を含めて、記述する。

    7. 要求する具体的な是正措置(移転の承認または拒否)を提示する。

    8. 申し立ての対象となるドメイン名に関係または関連して、これまでに開始または終了した他の法的手続きをすべて特定する。

    9. 申し立てのコピーが、プロバイダの補則で規定された表紙と共に、被申立人に送付または送信されたことを証明する。

    10. 以下の声明と申立人またはその委任代理人の署名をもって結ぶ。

      「<申立人の名前を挿入> は、ドメイン名の登録、紛争、または紛争の解決に関する要求および是正措置はもっぱら被申立人に対するものとすることに同意し、意図的な不正行為または重大な過失の場合を除き、紛争解決プロバイダおよびその役員、幹部、従業員、代理人に対する要求も是正措置も行いません。」

      「<申立人の名前を挿入>は、この申し立てに記載されている情報が申立人の知る限りにおいて完全かつ正確であること、この申立書が嫌がらせのような、いかなる不正な目的でも提示されていないこと、この申し立てで主張していることはTDRPおよび適用される法律に基づき正当であること、およびこの申立書は誠実で合理的な主張により存在または展開され得るものであることを保証します。」

    3.1.3 ドメイン名が同一の申立人および被申立人に関与し、かつ申し立てが同一または類似の事実状況から生じている場合、申し立ては複数のドメイン名に対して関連されます。

    3.1.4 申し立てには、以下の証拠書類(該当し、入手可能である場合)を、そのような証拠の一覧表インデックスと共に(可能であれば電子形式で)添付するものとします。

    1. 新レジストラ

      1. 記入済みの承認フォーム(「FOA」)(該当する場合)2

      2. 移転が開始した日付の登録データディレクトリサービス(「RDDS」)出力のコピー(登録名保有者の識別に使用したもの)(該当する場合)3

      3. 使用されている識別情報の証拠のコピー

      4. レジストラの移転と同時に登録名所有者が変更される場合は、双方の同意、紛争解決団体の最終決定、または裁判所命令のコピー

      5. 適用移転申請に関連して現レジストラに対して行われたすべての通信および現レジストラからのすべての回答のコピー
    2. 現レジストラ

      1. 現レジストラからの記入済みFOA

      2. 移転が開始した日付のRDDS出力のコピー(該当する場合、登録データポリシーに従って編集された登録データの値を含む)

      3. 該当する登録に対して行われたRDDSの関連修正履歴(該当する場合、登録データポリシーに従って編集された登録データの値の修正を含む)

      4. 移転が拒否された場合は、以下のいずれかの証拠

        • 不正行為
        • レジストラに通知された係争中のUDRP
        • レジストラに通知されたURS手続きまたはURS凍結
        • 移転紛争解決ポリシーに基づく紛争の保留
        • 管轄裁判所による裁判所命令の受領
        • 移転ポリシーのセクション4 [管理レジストラの要件] に従った登録名所有者の識別情報の紛争
        • 該当する支払いの紛争(登録がHOLDステータスのときに記入された証拠と共に)
        • 登録名保有者からの書面による明示的な異議
        • LOCKステータス(この契約の別紙__のセクション__によって登録名所有者がLOCKステータスを解除する合理的な手段の証拠と共に)
        • レジストラは、レジストラントの変更を受けて、60日間のレジストラ間移転ロックを課しており、登録名保有者は、レジストラントの変更リクエストに先立って、60日間のレジストラ間移転ロックをオプトアウトしなかった
        • 初回登録から60日以内のドメイン名、または
        • 前回移転から60日以内のドメイン名
      5. 適用移転申請に関連して新レジストラに対して行われたすべての通信および新レジストラからのすべての回答のコピー

    3.2 被申立人は、申し立てを受領してから7暦日以内に申し立てへの返答(「返答」)を用意することとします。

    3.2.1 返答は、電子フォームで紛争解決プロバイダおよび申立人の両方に送信されることとし、以下の内容であるものとします。

    1. 申し立てに含まれる供述および陳述に対して明確に返答する (返答のこの部分は紛争解決プロバイダの補則に規定されている字数またはページ数の制限に従うこととする)

    2. 被申立人(非申し立てレジストラ)の名前、郵送先住所、電子メールアドレス、電話番号、およびファックス番号を提供する

    3. 申し立ての対象となるドメイン名に関係または関連して、これまでに開始または終了した他の法的手続きをすべて特定する

    4. 返答のコピーを申立人に送付または送信したことを明記する

    5. 以下の声明と被申立人またはその委任代理人の署名をもって結ぶ

      「<被申立人の名前を挿入>は、この返答に記載されている情報が被申立人の知る限りにおいて完全かつ正確であること、この返答が嫌がらせのような、いかなる不正な目的でも提示されていないこと、この返答で主張していることはこれらのルールおよび適用される法律に基づき正当であること、およびこの返答は誠実で合理的な主張により存在または展開され得るものであることを保証します。」さらに、

    6. 相手方が根拠とする、文書による記録または他の証拠のすべてを、証拠の一覧表とともに添付する

    3.2.2 被申立人の要求により、紛争解決プロバイダは、例外的なケースとして、 返答の提出期間を延長することがありますが、いかなる場合も5暦日を超えて延長されることはありません。提出期限は、紛争解決プロバイダが必要であると認めれば、両当事者間で合意した書面での規定によって延長することもできます。

    3.2.3 被申立人が返答を提出しない場合、特別な事情がない限り、紛争解決プロバイダが任命した紛争解決パネルが、申し立てに従って紛争を裁定するものとします。

    3.2.4 紛争解決プロバイダによって任命された紛争解決パネルは、該当するすべての文書を確認し、レジストラント / 連絡先データを信頼すべきRDDSデータベースのデータと比較し、被申立人から返答を受領してから30日以内に判断する必要があります。

    1. レジストラント / 連絡先データが信頼すべきRDDSのデータと一致しない場合、または登録データポリシーに従って信頼すべきRDDSにおいてレジストラント / 連絡先データが編集されている場合、紛争解決パネルは各レジストラに連絡し、追加書類を要求することとします。

    2. レジストラント / 連絡先データが信頼すべきRDDSに公表されており、新レジストラが、移転申請時に信頼すべきRDDSデータベースに含まれるデータと一致した完全なFOAが必要であるのに提供できない場合、紛争解決パネルは、移転を取り消すことを裁定するものとします。Thick Registryでは、管理レジストラのRDDSがアクセス不能か無効である場合、該当レジストリオペレータのRDDSが使用されます。Thin Registryでは、管理レジストラのRDDSがアクセス不能か無効である場合、紛争解決プロバイダは、かかる問題が解決されるまで、紛争を保留にすることができます。

    3. 現レジストラが移転をNACKする場合、現レジストラは、TDRPの3.1.4(xii)(d)項に定めるNACKが可能となる要因の1つの証拠を提供しなければなりません。現レジストラがいずれかの要因を示す証拠を提供することができず、移転ポリシーのI.A.2項4に従って、移転申請時に信頼すべきRDDSデータベースに含まれていたデータと一致する完全なFOAを新レジストラが紛争解決プロバイダに提供した場合、移転は承認されるものとします。

    4. 紛争解決パネルが「無判定」の裁定を発することはできません。紛争解決パネルは、移転ポリシーに照らして適用可能な証拠を慎重に検討し、証拠の優越、いずれのレジストラが紛争で勝利すべきか、および申し立てに規定された問題が適切に是正されるようにするための解決内容に基づいて裁定しなければなりません。

    5. 紛争解決パネルによる解決の選択肢は以下に限定されます。

      1. 移転の承認

      2. 移転の拒否(これには、すでに移転が実行されている場合のドメイン名の現レジストラへの返還命令が含まれることもある)

    6. 本移転紛争解決ポリシーに定める紛争解決プロセスで裁定される無効な移転によって新レジストラが問題のドメイン名のスポンサーシップを得た場合、新レジストラから第3のレジストラへの移転、およびそれ以降のすべての移転が無効となります。

    7. 無効な移転が発生したと紛争解決パネルが判断した場合、当該ドメインは、無効な移転の直前に管理レジストラであったレジストラに返還されるものとします。

    3.3 紛争解決サービスの料金

    3.3.1 該当する紛争解決プロバイダは、該当する申し立て料金(「申し立て料金」)を決定することとします。具体的な料金および、かかる料金の実際の支払いを規定する条項は、紛争解決プロバイダの補則に含まれるものとします。

    3.3.2 申立人が紛争で勝訴しなかった場合、紛争解決プロバイダが申し立て料金を保持するものとします。

    3.3.3 申立人が紛争で勝訴した場合、被申立人は、かかる裁定から14暦日以内に申し立て料金を紛争解決プロバイダに支払う必要があります。その場合、 紛争解決プロバイダは、被申立人から申し立て料金を受け取ってから14暦日以内に、申立人に申し立て料金を払い戻すものとします。かかる料金は、下記セクション3.4に従って法的審理が開始されているかどうかかかわらず、支払われなければなりません。申し立て料金が紛争解決プロバイダに支払われない場合、 ICANNの認定を失うことがあります。

    3.4 裁判所の手続きの有効性

    上記で規定される手続きは、この紛争処理手続の開始前または終結後に、レジストラが中立的な解決を求めて所轄裁判所に出訴することを妨げるものでありません。紛争解決パネルがドメイン名登録の移転(新レジストラへの移転、または新レジストラから現レジストラへの返還)の裁定を下した場合、かかるレジストラはその裁定の実施を通知後14暦日保留します。この14暦日の間に、対象のドメイン名に関する訴訟が開始されたとの公式文書(裁判所の受領印のある訴状の写し等)を紛争当事者のいずれかから受け取らなければ、レジストリはその裁定を実施します。この14暦日の間に、かかる公式文書をレジストリ(該当する場合)から受け取った場合には、(i)かかる紛争を当事者間で解決したことの証拠が提出されるまで、(ii)当該訴訟を棄却または取り下げられたとの証拠が提出されるまで、または(iii)かかる裁判所からの訴訟取り下げの命令またはドメイン名に関して特定の措置をとるように求める命令の写しを受け取るまで、裁定の実施は見送られます。

    3.5 裁定の公表

    3.5.1.当該紛争解決プロバイダは、TDRPに基づいて開始した移転紛争に関するすべての裁定を公表することとします。本ポリシーに基づくすべての裁定は、例外的に紛争解決プロバイダが招集したパネルが裁定の一部を修正することを決定した場合を除き、その全文がインターネットに公開されます。いかなる場合であっても、申し立てが悪意によるものだという裁定が下されたときには、その裁定部分を公表するものとします。

    3.5.2.裁定レポートには、少なくとも以下を記載することとします。

    1. 紛争中のドメイン名

    2. 紛争当事者の名前

    3. 裁定の全文

    4. 裁定の実施日

    3.5.3 紛争解決プロバイダが裁定を公表すべきではないと考える場合、紛争解決プロバイダは、ICANNと協議し、その指示があれば裁定を公表するものとします。

    3.5.4.公表は、2016年12月1日以前に提出されたTDRP申し立てには適用されません。


1 移転ポリシーのI.A. 2.1.1項を参照。ICANNから求められたデータ転送のための安全な方法が提供されるまでの間、新レジストラが移転の対象となるドメイン名のその時点における登録データにアクセスできない場合、登録名所有者からの「レジストラ移転の最初の承認」というラベルの承認フォームの取得が新レジストラに求められることはありません。

2 移転ポリシーのI.A. 2.1.2.1項を参照

3 移転ポリシーのI.A. 2.1.1項を参照

4 移転ポリシーのI.A.2.1.1項を参照

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."