<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 8:24 PM, Karen Bernstein <<a href="mailto:kjb@bernsteinip.com" class="">kjb@bernsteinip.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Folks,<br class=""><br class="">For tomorrow’s meeting on WT3, I’d like to share with you my experience with the string confusion contention set I was involved with. <br class=""><br class="">I represented the Government of Montenegro (which provides the .Me ccTLD) against Google’s proposed gTLD for .Meme in a string confusion contention set.<br class=""><br class="">A clueless panelist was appointed who was an admiralty lawyer from British Columbia. Very obscure.<br class=""><br class="">He also made his own conclusions that if the proposed gTLD were to be delegated it would not be confusing because he “thought so,” despite reputable external evidence that there might be collision problems and customer confusion. </div></div></blockquote><div><br class=""></div>Karen,</div><div><br class=""></div><div>The criteria was "confusingly similar", not that there might be collisions or confusions. There can be collision or confusions even considering only the legacy gTLDs, so the bar is not that low. </div><div><br class=""></div><div>From AGB:</div><div>"A DRSP panel hearing a string confusion objection will
consider whether the applied-for gTLD string is likely to result
in string confusion. String confusion exists where a string so
nearly resembles another that it is likely to deceive or cause
confusion. For a likelihood of confusion to exist, it must be
probable, not merely possible that confusion will arise in the
mind of the average, reasonable Internet user. Mere
association, in the sense that the string brings another string
to mind, is insufficient to find a likelihood of confusion."</div><div><br class=""></div><div>Frankly, I believe it was the right outcome for that specific objection... </div><div><br class=""></div><div><br class=""></div><div><blockquote type="cite" class=""><div class=""><div class=""> Should my client have to hire a linguist to prove the point? Apparently, ICANN’s linguists didn’t see a problem with it. Perhaps we can talk about whether it makes sense to include an ICANN-appointed panelist for future string confusion contentions.<br class=""></div></div></blockquote></div><br class=""><div class=""><br class=""></div><div class="">I was in the receiving end of an SCO from the largest TLD as objector, where they hired a linguist. Guess what ? We hired a linguist and a phonetics expert... although the actual objection and response are not published, much can be derived from the determination, available at <a href="https://newgtlds.icann.org/sites/default/files/drsp/25sep13/determination-1-1-1119-71934-en.pdf" class="">https://newgtlds.icann.org/sites/default/files/drsp/25sep13/determination-1-1-1119-71934-en.pdf</a> . </div><div class=""><br class=""></div><div class="">And before we suggest ICANN to appoint panelists, in that case the confusion that was ruled to be non-existent was between words of different languages... so unless ICANN has a stockpile of linguist experts in a million combinations of (Language A, Language B), it might not be practical. </div><div class=""><br class=""></div><div class="">BTW, on SCOs I have to point out that standing was an issue. It's possible that some registrants have difference of opinion when existing registries for a similar TLD propose such. So having *only* the existing registries and applicants as having standing might not be enough... so granting standing for the IO on SCOs might be an alternative to overcome that. It still would be complying with every other IO guidance, of course. </div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Rubens</div><div class=""><br class=""></div></body></html>