[ALAC] Followup meeting on TMCH issues

Tue Nov 27 13:21:27 UTC 2012

Again thank you Alan and Evan. Valuable overview and comments. Really appreciated. A few things

1. Is there an indication on when the details if the strawman proposal will be available?
2. Firmly agree on you comments for point 2 on community participation on the notice development
3. On blocking has there been a substantive indication on what the process for determining genuine use would entail as yet? It might be helpful to ALAC exploring how best to prevent blanket blockades but support truly pro user TM set asides. 

TT

On 27 Nov 2012, at 2:17 AM, 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)