[ALAC] Followup meeting on TMCH issues

Carlton Samuels carlton.samuels at gmail.com
Tue Nov 27 01:56:35 UTC 2012

Thanks for this guys.  Seems we've made some progress.  And I'm guided by
both your take on matters.

- Carlton

Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*

On Mon, Nov 26, 2012 at 7:17 PM, Alan Greenberg <alan.greenberg at mcgill.ca>wrote:

> Evan and I attended a follow-on teleconference on the TMCH issues
> today. The following note is written in the first person, but has the
> full support or Evan.
> The first part was on the progress related to the negotiation of
> contracts with Deloitte who will perform the TM validation process
> and deal with TM holders and IBM who will operate the Clearinghouse
> and interface with registrars and registries.
> The contract with Deloitte is close to finalized. The price for
> registering a single trademark will be $150 (with some variations due
> to currencies and such) and there will be substantive discounts for
> multi-year registrations and for bult registrations. ICANN will have
> access to Deloitte costs and revenue figures and the right to audit
> Deloitte, all to ensure that their profit margins are kept reasonable
> (and specifically a contractual profit cap). Although Deloitte has
> exclusivity until after the first 10 sunrises (ensuring that the
> protocols and TMCH are functioning well), after that point, ICANN
> could invite other applicants to play a similar role - a marked
> change from the original plans.
> The contract with IBM should be complete within a week or so. As
> already noted, ICANN will retain all use rights to the data in the
> TMCH, so although IBM will be able to market other services, they can
> only do so with the express permission of ICANN. Similarly, ICANN can
> offer the data to other parties for competing services (all subject
> to whatever the TM holders agree to when they deposit their
> information in the CH).
> Although the details of the "strawman" proposal are not yet agreed
> to, both contractors have agreed that what ever is there (presumably
> based on what ins in the current strawman), the contracts already
> will include that.
> These could not have been an easy contracts to negotiate, and are the
> most rational from an ICANN and user standpoint that I have ever seen
> at ICANN. To make it clear, I am impressed.
> On the strawman proposal, Fadi divided the issues into three sections:
> 1. Adding a 30 day "announcement period before the formal 30 day sunrise.
> 2. a) Extending the 60 TM Claims period to 90 days, and b) tacking on
> a new, for-fee TM Claims process for 6-12 months (to be decided) with
> a lighter, less legalistic notice and no requirement to acknowledge
> receipt.
> 3. All up to 50 additional character strings associated with a TM to
> be entered into the TMCH (for a fee). The names would typically be
> typos or the TM plus related strings (products or services associate
> with the mark).
> Following extensive staff discussions, the following Implementation
> vs Policy recommendations are being made (along with my and Evan's
> take on them)
> 1. The original policy was silent on sunrise timing, and certainly
> did not either mention or prohibit a prior announcement period. This
> is deemed to be implementation.
> Comment: No argument at all. I did point out that despite this new 30
> day period, between now and the first sunrise, ICANN has a real need
> to get out there and let TM holders know this is coming.
> 2. Both the extension of 60 to 90 days and the addition of the new
> lighter TM Claims process were deemed to be implementation.
> Comment: There was little discussion about the first part, but much
> more about the second. I for one was rather surprised as were a
> number of others. Fadi said that there was a lot of discussion on
> this point, and he believes that their rationale, which will be made
> available very shortly will explain why. Regardless of the
> implementation vs policy issue, this extension of TM Claims is
> something that the ALAC supported in its minority report to the STI,
> and the change to a lighter form of notice should adequately address
> the concerns that the ALAC did have about such extension. I did point
> out that it was important for the community to be involved in wording
> this new notice.
> 3. The additional of "related" strings was deemed to be policy. Only
> strings that have been the subject of UDRP or Court decisions would
> be allow (and specifically not URS).
> Comment: No disagreement here. Fadi will be writing to the GNSO to
> tell them that they need to offer guidance on this.
> The TM folks on the call took the opportunity to raise the issue of
> blocking (or making very difficult) registration on marks and
> marks+related-strings that have been found to have been abused in the
> past. Fadi was adamant that such a process was not something that he
> could imagine approving in a process like the current one. I added
> that it was sufficiently counter to other decisions that have been
> made in the past that it would need to be the result of substantive
> community-based policy discussion. The TM folks did not seem please
> with this position and we may want to explicitly support Fadi on this one.
> On the substance of the blocking proposal, At-Large has traditionally
> been sympathetic to the needs/desires of the TM holders. Although
> At-Large has a keen interest in Registrant rights, when they may
> conflict with User issues, we have tended to side with the needs of
> Users. In this case, the registrations that the TM owners are worried
> about tend to be used for monetized pages, phishing, deceptive web
> site or out-and-out fraud. In all of these cases, fighting such uses
> is generally pro-user. So we are not necessarily completely against
> the concept. But it would need to be implemented in such a way as to
> not unreasonably interfere with valid registrations. To date, none of
> the proposed implementations have come anywhere near this, and they
> specifically all have tended to be "block until the prospective
> registrant can demonstrate that they have a legitimate need" - which
> has a very "guilty until proven innocent" tone to it and with the
> demonstration being a slow and possibly expensive process.
> Alan
> Alan
> _______________________________________________
> ALAC mailing list
> ALAC at atlarge-lists.icann.org
> https://atlarge-lists.icann.org/mailman/listinfo/alac
> At-Large Online: http://www.atlarge.icann.org
> ALAC Working Wiki:
> https://community.icann.org/display/atlarge/At-Large+Advisory+Committee+(ALAC)

More information about the ALAC mailing list