Trademark Clearinghouse Update

by Fadi Chehadé on November 16, 2012

This week, I met with a group of stakeholder representatives to work with ICANN staff to complete implementation discussions on the Trademark Clearinghouse and its associated rights protection mechanisms. As I wrote in my previous post from Brussels, these implementation meetings addressed the following topics:

  • The recent IPC/BC proposal for Improvements and Enhancements to the RPMs for new gTLDs [PDF, 68 KB], strictly focusing on implementation versus policy issues.
  • The business and contractual framework for the Clearinghouse.
  • Implementation architecture for Sunrise and Trademark Claims.

Representatives from the Business, Intellectual Property, and ISP constituencies, the Noncommercial, Registrars, and Registries stakeholder groups, and the At Large Advisory Committee joined these discussions in the spirit of reaching implementation solutions. They focused strictly on finding common ground and to advance the discussion on implementation solutions; they were not policy-making meetings.

To kick off the discussion, I introduced an overview of the gTLD Services department ICANN is building, to include staff resources working on DNS industry engagement, gTLD service operations, and gTLD support.

Until the first new gTLD is delegated, Akram Attalah and I will personally oversee the whole New gTLD Program.

BC/IPC Proposals

The group listened and considered the rationale behind the following eight proposals made recently by the BC/IPC:

  1. Extend Sunrise Launch Period from 30 to 60 days with a standardized process.
  2. Extend the TMCH and Claims Notices for an indefinite period; ensure the process is easy to use, secure, and stable.
  3. Complete the URS as a low cost alternative and improve its usefulness – if necessary, ICANN could underwrite for an initial period.
  4. Implement a mechanism for trademark owners to prevent second-level registration of their marks (exact matches, plus character strings previously determined to have been abusively registered or used) across all registries, upon payment of a reasonable fee, with appropriate safeguards for registrants with a legitimate right or interest.
  5. Validate contact information for registrants in WHOIS.
  6. All registrars active in new gTLD registrations must adhere to an amended RAA for all gTLD registrations they sponsor.
  7. Enforce compliance of all registry commitments for Standard applications.
  8. Expand TM Claims service to cover at least strings previously found to have been abusively registered or used.

The group determined that items 5, 6, and 7 above were already under consideration on other tracks and those were deferred for this discussion.

The group discussed a possible decision tree as a tool for considering whether proposed changes were appropriate for policy or implementation processes. ICANN’s policy team will continue to advance this decision tree with the community in a formal way, to create and document these decision-making mechanisms.

For this meeting, the group decided to focus primarily on finding the right solutions, and then later to address how the solutions should be considered, adopted, or implemented. In addition, we acknowledged the need to address separately how elements of these solutions might apply to legacy gTLDs, but did not make this a pre-requisite for developing the strawman solution.

Strawman Model

For the remaining five proposed items, the key points identified were:

  • Duration of the Sunrise and Claims services
  • Scope of the trademarks to be included in Trademark Claims
  • Establishment of a second-level blocking mechanism with safeguards for registrants

The group discussed/collaborated on a possible strawman solution addressing a number of these elements.

Feature Current Applicant Guidebook Strawman Solution
Sunrise period 30 days

30-day sunrise + 30-day advance notification

Trademark Claims period 60 days 90 days + option of additional “Claims 2″ period for 6-12 months
Scope of Trademark Claims Identical Match Identical Match + up to 50 abused variations of trademark

In the strawman model:

  • All new gTLD operators will publish the dates and requirements of their sunrise periods at least 30 days in advance. When combined with the existing (30-day) sunrise period, this supports the goal of enabling rights holders to anticipate and prepare for upcoming launches.
  • A Trademark Claims period, as described in the Applicant Guidebook, will take place for 90 days. During this “Claims 1″ period, a person attempting to register a domain name matching a Clearinghouse record will be displayed a Claims notice (as included in the Applicant Guidebook) showing the relevant mark information, and must acknowledge the notice to proceed. If the domain name is registered, the relevant rightsholders will receive notice of the registration.
  • Rights holders will have the option to pay an additional fee for inclusion of a Clearinghouse record in a “Claims 2″ service where, for an additional 6-12 months, anyone attempting to register a domain name matching the record would be shown a Claims notice indicating that the name matches a record in the Clearinghouse (but not necessarily displaying the actual Claims data). This notice will also provide a description of the rights and responsibilities of the registrant and will incorporate a form of educational add-on to help propagate information on the role of trademarks and develop more informed consumers in the registration process.
  • Where there are domain labels that have been found to be the subject of previous abusive registrations (e.g., as a result of a UDRP or court proceeding), a limited number (up to 50) of these may be added to a Clearinghouse record (i.e., these names would be mapped to an existing record for which the trademark has already been verified by the Clearinghouse). Attempts to register these as domain names will generate the Claims notices as well as the notices to the rights holder.
  • Possible blocking mechanisms were discussed, but were not included in the strawman model.

These phases are outlined here:

Contractual Framework

I provided an update on the expected contractual framework for operation of the Clearinghouse. As announced earlier this year, ICANN staff is working with Deloitte, IBM, and CHIP to deploy the Clearinghouse. The structure was re-designed to give ICANN maximum flexibility and the ability to provide the best possible stewardship of the database.

Technical Session

The group reviewed and discussed a set of questions related to the functional specifications of the interface between the Clearinghouse and registries and registrars. We made significant progress and will publish the results of the discussion on the tmch-tech mailing list. We plan to continue consultations with the community on the remaining questions.

Next Steps

We will have follow-up informational calls in November with the group to do three things. (1) Review any additional feedback from the stakeholder groups, (2) Convey staff’s view on a path forward on some or all elements of the strawman solution, and (3) Convey additional details on the Trademark Clearinghouse contracts.

We are now firmly focused on moving forward with Trademark Clearinghouse implementation to ensure that the New gTLD Program is launched in accordance with our targets.

Next, I will focus on URS and RAA.

Thank you to all the stakeholder groups for the many hours of hard work!



{ 3 comments… read them below or add one }

Werner Staub 11.18.12 at 5:06 am

If the foundations are bad, it does not help to build nicer features on the top of them.

Don’t get me wrong. The hand-picked “stakeholder representatives” identified some good ideas. I like the ideas numbered 1 to 8 in Fadi’s posting. That does not mean they are sufficient. The TMCH is still fundamentally on the wrong footing.

The “benevolent monarch” approach to setting up the TMCH should stop here. I was good Fadi refused to blindly sign the proposed (and secret) TMCH contracts. But there is no point in replacing a murky process with an equally opaque one.

ICANN still wants to give Deloitte a world-wide monopoly. The new proposal simply creates two monopolies (one for Deloitte and one for IBM). That is even worse than before, requiring tripartite ICANN-Deloitte-IBM negotiations even for tiny improvements.

As a monopoly, the TMCH will not only be expensive and dysfunctional, it will do more harm than good.

A monopolistic TMCH is also completely unjustified, even on the grounds of “urgency”. No offense to Deloitte and IBM, ICANN staff, the hand-picked “representatives” and Fadi: all have seem to have lost sight of the cause. The purpose is to build infrastructure. Handing out rents and fiefdoms can be a way to get a job done, but the privileges should never be the objective. If handouts are used, keep them small, reversible and subject to competition.

It is easy to build a distributed system with competitive TMCH providers. Actually, it is easier than the monopolistic approach. ICANN managed to do this for the UDRP dispute resolution service providers. Why is it unable to do the same for TMCH providers?

If there are concerns with timelines, we can start with one TMCH provider and add more of them within months. The essence is to have competition and diversity between them. In the medium term, there should be at least 10 TMCH providers instead of just Deloitte. But the system must be built from the start to allow multiple TMCH providers.

Another concern is the strange silence on data ownership. Why? Has ICANN already sold out to Deloitte? I hope not. All TMCH databases must be ICANN’s property. Providers must be required to deposit it with an escrow agent. Each TMCH provider can of course be escrow agent for other TMCH providers.

Next is data “confidentiality”. By definition, trademarks are not confidential. In certain cases, a new trademark registration needs to remain non-discoverable for some time, lest bad actors misuse its discovery to register it in other jurisdictions. But the TMCH providers should only flag a record as non-discoverable for a limited period, such as 2 years after registration of the underlying mark, and only upon express request by the trademark holder.

Finally, the technical approach. First and foremost, it must support the distributed competitive model. That can easily be done if the TMCH uses the DNS.

The only thing needed is a central zone file, containing NAPTR pointers to each of the TMCH providers holding data regarding a given character string. The TMCH providers themselves can distribute the data with several methods, such as DNS NAPTR records, web services or file distribution. I insist: not using the DNS for the TMCH would be as if a forklift manufacturer used ox carts inside its factories.

Maria Farrell 11.19.12 at 4:26 am

Thank you for the update, Fadi.

As this was a closed, invitation-only meeting in an organisation whose DNA is openness and transparency, I would like to request that the names and affiliations of the individuals participating in the meeting be published.

I am concerned that simply listing the interests represented gives an inaccurate picture of the people present and wrongly suggests that this was a balanced meeting. Specifically, there was a single non-commercial representative present for only part of the meeting, and another dialing in whilst multiple (a dozen?) IP and business constituency representatives attended.

Given that the individuals representing the partisan IPC/BC proposal greatly out numbered other groups, it is only fair for the community at large to have the necessary information to make up its own mind about the numerical imbalance of invited participants.

Veseveus 11.29.12 at 3:59 pm

Im seeing on the other boards that the ipclearinghouse doesnt own Is that a good idea?

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

To prove you're a person (not a spam script), type the security word shown in the picture. Click on the picture to hear an audio file of the word.
Anti-spam image