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@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@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+(ALA...)