Brand and Trademark Protections in the new gTLD program: what should an applicant know?

Brand and trademark protection for applicants in the new gTLD program involves both proactively protecting your own brand by applying for a brand TLD, and reactively defending your trademarks against third-party gTLD applications.

Applicants should know about the following mechanisms and strategic considerations:

🛡️ Proactive Protection: The Brand TLD (.brand)

Applying for a Brand TLD (a "dotBrand," e.g., .google, .nike) is the highest level of digital control and protection for a trademark owner.

1. The .Brand TLD Designation

Closed Registry: The primary characteristic is that the registry is restricted. Only the brand owner and its affiliates or licensees are permitted to register second-level domains (e.g., shop.nike). Third-party registrations are prohibited.

Enhanced Security: This provides unprecedented control, allowing the brand owner to implement high-level security protocols (like DNSSEC) across all domains, significantly reducing phishing and counterfeiting risks.

Eligibility: The applied-for string must typically be identical to a registered trademark owned by the Registry Operator.

2. Specification 13

This is a critical addendum to the Base Registry Agreement that grants special exemptions for Brand TLDs.

Exemptions: It provides relief from certain obligations designed for open registries, such as the mandatory requirement to publish contact information for registrants.

Sunrise Deferral: It defers the mandatory Sunrise period (priority registration for trademark holders) for as long as the TLD remains a closed, qualified Brand TLD. This avoids a public launch process.

⚔️ Defensive Protection: Rights Protection Mechanisms (RPMs)

If you are not applying for your own TLD, you must be prepared to defend your trademarks against other gTLD applications using these tools:

1. Legal Rights Objection (LRO)

This is a pre-delegation dispute resolution procedure to formally challenge a third-party gTLD application.

Grounds: An objection may be filed if the applied-for gTLD string, or the applicant’s potential use of it, would cause impermissible infringement of the objector's existing trademark.

Procedure: LROs are resolved by an independent panel of experts, primarily administered by the WIPO Arbitration and Mediation Center.

2. Trademark Clearinghouse (TMCH)

The TMCH is the central, global database of verified trademark information and is foundational for protection.

Sunrise Services: All new gTLD registries must offer a Sunrise Period (at least 30 days) where verified trademark holders from the TMCH can register corresponding domain names before public access.

Trademark Claims Service: For at least 90 days after general public registration opens, the registry must use the TMCH to provide notice to both the new domain registrant (warning of the conflict) and the trademark holder (if the registration proceeds).

3. Uniform Rapid Suspension System (URS)

This is a post-delegation dispute mechanism for clear-cut cases of trademark infringement (cybersquatting) in a newly delegated TLD.

Process: URS is a faster and less expensive alternative to the Uniform Domain Name Dispute Resolution Policy (UDRP).

Remedy: The only remedy is the temporary suspension of the infringing domain name, making it suitable for quick relief in obvious cases of abuse.

What are the Different gTLD Application Types in the next ICANN new gTLD Round?

The new ICANN gTLD round (often called the Next Round, anticipated for 2026) classifies applications into two main groups: General Applications and Specialized Applications. Within the Specialized category, there are several key types defined by the string itself, the applicant, and/or the intended use.

Here are the different gTLD application types:

1. General Application (Standard)

A General Application is the default type for most commercial or unrestricted gTLDs.
Description: These applications do not fall into any specialized category. They are subject to the standard set of requirements outlined in the Applicant Guidebook (AGB) and do not have additional conditional requirements or special designations.
Intended Use: The registry is typically open for any person or entity to register a second-level domain (e.g., .shop, .app, or a generic name like .auto).

2. Specialized Application Types

Specialized Applications have specific conditional requirements, varying fees, or eligibility standards depending on the string, the applicant, or the intended use.

A. Community Application 🌐
Description: The application is filed by an entity acting on behalf of a clearly delineated community (e.g., cultural, linguistic, or professional).

Requirement: The applicant must demonstrate a clear and strong nexus between the proposed gTLD string and the community it seeks to serve.

Advantage: If the string is contested, the applicant may undergo a Community Priority Evaluation (CPE) to receive priority over other applicants if they score 14 or more out of 16 points.

B. Brand TLD Application ℠
Description: The application is for a gTLD that is the trade name, trademark, or service mark of a single, private entity (e.g., .google, .nike, .bank).

Requirement: The applicant must affirm its intention to operate the gTLD as a closed registry, restricting registration of second-level domains only to itself and its affiliates.

Advantage: Specification 13 in the Registry Agreement provides specific contractual benefits and obligations tailored to protecting corporate brands. This type often involves a conditional evaluation to confirm its status.

C. Geographic Name Application 🗺️

Description: The applied-for gTLD string represents a geographic name (e.g., a city, region, or country).

Requirement: The applicant must obtain specific letters of support or non-objection from the relevant governments or public authorities associated with that geographic name. Without this, the application for a Geographic Name is rejected.

D. Reserved Name Application 🛑

Description: Applications for strings that were reserved from general application in previous rounds due to their special status (e.g., related to inter-governmental organizations or specific humanitarian groups).

Eligible Applicants: Only the entities for whom the names are reserved—such as the Red Cross Red Crescent (RCRC) or International Governmental Organizations (IGOs)—can apply for these strings.

E. Internationalized Domain Name (IDN) Application

Description: Applications for gTLD strings that are not written using the basic 26-letter ASCII (Latin) script, but rather in scripts like Arabic, Chinese, Cyrillic, or Devanagari.

Requirement: The applied-for string must comply with the rules established by the relevant Root Zone Label Generation Rules (RZ-LGR) for that script to ensure technical stability and prevent confusion.

The Applicant Guidebook (AGB) for the Next Round details the specific requirements, fees, and evaluation criteria that apply to each of these application types.

Round 2 of new gTLDs: what are Replacement String and the Replacement Period?

The Replacement String and the Replacement Period are new mechanisms introduced for the next round of new gTLD applications (often informally called "Round 2" or the "Next Round," currently planned for 2026). They are designed to give applicants a mechanism to avoid contention sets and potential auctions.

This feature was developed as a direct result of lessons learned in the 2012 round, where many identical applications were forced into time-consuming and costly private resolutions or auctions.

🔁 Replacement String

A Replacement String is a second-choice Top-Level Domain (TLD) name that an applicant can optionally designate in their original application, in addition to their first-choice Applied-for String (or original string).

• Optional: Applicants are not required to provide a Replacement String, but it is highly recommended as a strategic contingency.
• Irreversible: If an applicant chooses to switch to their Replacement String during the Replacement Period, that string permanently and irreversibly replaces the original string for the remainder of the application process.They cannot switch back.
• No Contention: The primary goal is to provide a backup that is less likely to be contested. If an applicant's Replacement String is identical to the Applied-for String or Replacement String of another applicant, the applicant will not be allowed to switch to it, as this would simply create a new contention set.

🗓️ Replacement Period

The Replacement Period is a defined, short window of time during which applicants must decide whether to switch their application from their original Applied-for String to their pre-designated Replacement String.

• Timing: The period is scheduled to be 14 days following Reveal Day.
• Reveal Day: This is the day when ICANN publishes the public-facing portions of all received gTLD applications, including the original strings and all designated Replacement Strings. On this day, applicants get a clear picture of:
• Which applicants are applying for the identical string as their first choice.
• Which applicants have designated the same string as their Replacement String.
• Decision Window: Applicants in a contention set can use the 14-day Replacement Period to assess their chances in a potential auction or evaluation (like Community Priority Evaluation). They can then strategically opt to switch to their backup string to exit the contention set and proceed faster with evaluation.
• No Rationale Required: The decision to switch is at the applicant's sole discretion, and they are not required to provide ICANN with a rationale.

Strategic Significance

The introduction of the Replacement String and Replacement Period offers applicants a non-auction path to reduce risk and streamline the application process. By providing a low-contention backup name upfront, applicants can potentially save time and significant cost associated with prolonged string contention procedures, especially mandatory ICANN auctions (as private resolutions, which were common in Round 1, are now prohibited in the Next Round).

Would you like to know more about the ICANN Auction process and why applicants would be motivated to avoid it?

What are GAC Member Early Warnings and GAC Consensus Advice in the next ICANN new gTLD Round?

Both GAC Member Early Warnings and GAC Consensus Advice are mechanisms used by the Governmental Advisory Committee (GAC) in the ICANN new gTLD process to raise public policy concerns regarding specific applications.

They differ significantly in their source, purpose, and impact on the application's fate.

⚠️ GAC Member Early Warnings

An Early Warning is a non-binding notice provided by one or more individual GAC members (representing a national government) to an applicant. Its main goal is to provide an early caution about potential issues.

Source: Issued by individual GAC members (one or more governments); it does not require consensus from the full GAC.

Purpose: To signal to the applicant that the applied-for gTLD string is regarded as potentially sensitive or problematic by a specific government or governments, often due to national law, regulatory concerns (like finance or health), or public order issues.

Impact: It is non-binding and does not directly stop the application.

It gives the applicant an early opportunity to address the concerns, potentially through amending the application, proposing changes to their registry policies, or withdrawing the application for an 80% refund of the application fee (a key incentive to withdraw).

It is a strong indicator that the application may be subject to a formal GAC Consensus Advice or an Objection later in the process.

⚖️ GAC Consensus Advice

GAC Consensus Advice is a formal, collective recommendation from the Governmental Advisory Committee to the ICANN Board of Directors, reflecting the consensus position of the governments represented on the GAC.

Source: Issued by the full GAC and requires a consensus among its members.

Purpose: To formally advise the ICANN Board on public policy issues related to an application, often resulting from unresolved concerns raised during the Early Warning phase or during the GAC's own review.

Impact: It carries significant weight and creates a strong presumption that the application should not be approved or should proceed only with specific conditions (remediation).

If the ICANN Board chooses to take an action inconsistent with GAC Consensus Advice, the Board must publicly articulate the reasons for its decision and attempt to find a mutually acceptable solution with the GAC. Historically, the ICANN Board has consistently followed GAC Consensus Advice to reject or place conditions on an application.

The advice must be clearly enunciated, actionable, and accompanied by a rationale.
The mechanisms for the next gTLD round are being refined through the Subsequent Procedures Policy Development Process (SubPro), but the fundamental roles of the Early Warning (precursor, non-binding) and Consensus Advice (binding on the Board, subject to appeal) are expected to remain the same.

Would you like to know about the types of Public Interest Commitments (PICs) an applicant might offer to resolve GAC concerns?

What are new gTLD Community Priority Evaluation?

The Community Priority Evaluation (CPE) is an optional, high-stakes mechanism within the ICANN New gTLD Program designed to resolve contention for a domain name string when one or more of the applicants claim to represent a legitimate community.

Its primary function is to award priority to a community-based application, allowing it to move forward and prevail over all non-community applicants in the contention set, potentially avoiding a competitive auction.

Key Concepts

Contention Resolution CPE is triggered only when multiple parties apply for the exact same gTLD string.

Purpose It grants a community application priority status if it meets a high threshold, thereby resolving the conflict in its favor against commercial or other non-community applications for the same string.

Third-Party Panel The evaluation is conducted by an independent panel of experts (e.g., The Economist Intelligence Unit - EIU in the 2012 round).

The Four Evaluation Criteria

The CPE panel scores the community application based on four criteria, each worth up to 4 points, for a total maximum score of 16. A minimum score of 14 out of 16 points is required to prevail.

1. Community Establishment (Max 4 points)
   This criterion evaluates the existence, organization, and longevity of the claimed community. The panel assesses whether the community is clearly delineated, existed prior to the new gTLD program, and possesses a demonstrable organizational structure.
2. Nexus between Proposed String and Community (Max 4 points)
   This assesses the relevance and association of the applied-for gTLD string to the community it claims to represent. It looks at how closely the string describes the community and whether the name is unique to that community.
3. Registration Policies (Max 4 points)
   This evaluates the applicant's proposed policies for registering second-level domains (e.g., example.community). The panel ensures these policies are commensurate with the purpose and needs of the identified community and support the community's interests.
4. Community Endorsement (Max 4 points)
   This criterion measures the level of support and opposition the application has received. The panel looks for written endorsements from established, legitimate institutions representing the community, and weighs the significance of any opposition.

The Outcome

Prevailing Score (14+ points): The community application is granted priority. It wins the contention set against all non-community applicants and proceeds with the rest of the application process.

Non-Prevailing Score (Less than 14 points): The application loses its priority status. It must then participate in an ICANN Auction to resolve the contention set along with the other competing applications (community or non-community).

The CPE process safeguards names with genuine community significance, awarding them priority over commercial applicants seeking the same string.

Would you like to know more about the ICANN Auction process that resolves contention when CPE is not used or is unsuccessful?

New gTLDs: what are Community Input?

Here is a breakdown of Community Input in the context of the ICANN new gTLD Program.

👂 1. Community Input

1. Community Input is a general mechanism for the public, governments, and other interested parties to provide information, raise issues, and express opinions on a new gTLD application. It is primarily an advisory and informational process.
2. To bring relevant information and issues to the attention of ICANN, applicants, and evaluators.
3. Input is typically submitted via the Application Comment Forum on ICANN's website after applications are published.
4. It is generally non-binding on the evaluators or the ICANN Board, but comments can be used by evaluators to verify facts or by the Governmental Advisory Committee (GAC) to formulate advice.
5. Key Types
1. Application Comments: General public submissions.
2. GAC Member Early Warnings: An early, non-binding signal from a government that an application may be problematic under national law or sensitivities.
3. GAC Consensus Advice: Formal, binding advice from the GAC (representing governments) to the ICANN Board that may lead to rejection or specific conditions on an application.

The key difference from Objections is that Community Input does not trigger a formal, adversarial dispute resolution proceeding.

ICANN new gTLDs: what are Objections and Appeals?

Objections and Appeals are mechanisms within the ICANN new gTLD Program that allow third parties to challenge or seek review of a new Top-Level Domain (gTLD) application. They are designed to ensure that the introduction of new gTLDs is fair and does not infringe on existing rights or contravene public interests.

🛑 Objections

A formal Objection allows a qualified third party to argue that a new gTLD application should be rejected based on one of four specific grounds. These objections initiate a Dispute Resolution Proceeding that is handled by independent third-party Dispute Resolution Service Providers (DRSPs), not ICANN itself.

The four specific grounds for filing a formal Objection are:

1. String Confusion Objection: The applied-for gTLD string is confusingly similar (visually, aurally, or in meaning) to an existing Top-Level Domain (TLD) or another gTLD application in the same round. Standing: Generally, only existing TLD operators or other gTLD applicants in the same round can file.
2. Legal Rights Objection: The applied-for gTLD string infringes the existing legal rights (like a trademark) of the objector. Standing: Must be filed by a rights holder whose rights are being infringed.
3. Limited Public Interest Objection: The applied-for gTLD string is contrary to generally accepted legal norms of morality and public order recognized under principles of international law. Standing: Anyone may file, though frivolous or abusive objections are filtered out.
4. Community Objection: There is substantial opposition to the gTLD application from a significant portion of the community that the string is explicitly or implicitly targeting. Standing: Must be an established institution associated with a clearly defined community.

⚖️ Appeals

An Appeal is the process for seeking review of a final Expert Determination made by a Dispute Resolution Service Provider (DRSP) panel in an objection proceeding.

Who can appeal? The party that was non-successful (the applicant or the objector) in the initial Objection proceeding.

Process: The non-prevailing party can file an appeal with the relevant DRSP, usually within a short timeframe (e.g., 15 days) from the date the initial Expert Determination was issued.

Standard of Review: The appeal is generally considered under a "clearly erroneous" standard of review. This means the appellate panel will not re-hear the case from scratch, but will primarily determine if the initial expert panel made a decision that was clearly wrong based on the evidence and rules.

Outcome: The appeal results in an Appellate Expert Determination, which is the final word on the objection within the ICANN process.