[GNSO-RPM-WG] Q#15 Transparency for the TMCH

Sun Oct 13 04:10:51 UTC 2019

Hi Greg and all,

I am not the only one that heard the concept of filing in jurisdictions that do not have searchable DBs as a basis for wanting to keep the TMCH closed.

I agree that is sounds like a curious practice which is why I asked others who confirmed they also heard it presented (perhaps through a combination of chat and audio statements).   Only after trying to figure out how obtaining a priority date in a closed (non-searchable) jurisdiction would be relevant to the TMCH was the question raised to the group.

Marie’s rationale, as you call it, is a separate basis.  It would be nice to review the transcript and the chat, but we heard the idea floated and it seemed odd and frankly a bit of an overreach.

Clearly this warrants further discussion as we have serious questions regarding the TMCH and having oversight of the DB and the data would be very helpful.  I was hoping we could clarify the opposition’s positions and work to reach consensus, but we may just have to move Michael’s proposal to public comment.

Michael’s point below still worth noting.

Thanks,

Jason Schaeffer
ESQwire.com P.C.

________________________________
From: Michael Karanicolas <mkaranicolas at gmail.com>
Sent: Saturday, October 12, 2019 2:30 PM
To: Greg Shatan
Cc: Jason Schaeffer; gnso-rpm-wg at icann.org
Subject: Re: [GNSO-RPM-WG] Q#15 Transparency for the TMCH

Thanks Greg. Now can you explain to me why a person who wanted to know
this "confidential strategy" wouldn't just go to any registrar, search
for domains corresponding to the trademarks that an entity has
registered, and see when a claims notification pops up, to get an
accurate and complete picture of which marks they have chosen to put
into the TMCH?

On Sat, Oct 12, 2019 at 1:42 PM Greg Shatan <gregshatanipc at gmail.com> wrote:
>
> Jason and all,
>
> This "elaborate scenario" (filing "in “remote” jurisdictions with non-searchable DBs to gain a priority date") is not at all the rationale that was put forth by those in favor of a closed TMCH database.
>
> I believe it's incorrect to say that this scenario was raised (in the chat, by John McElwaine, or otherwise) introduced this concept as part of an argument in favor of a closed TMCH database.
>
> I am not even aware of the use of the strategy as described in its totality.  I think this may be an unfortunate misunderstanding or mis-recollection of the earlier discussions and the surrounding facts.
>
> As I recall, the rationale is much more straightforward: A brand owner's choice of the subset of their trademarks to put in the TMCH is a confidential strategy. Giving third parties knowledge of this strategy allows these third parties to engage in activities that would harm TMCH registrants, which in turn would discourage use of the TMCH.  These activities include:  Targeting the brand owner's marks not in the TMCH for domain name registrations that can then be exploited in various ways; Developing a counter-strategy for TMCH registration (either by registering the same marks in the TMCH to enable contested Sunrises, or by registering the non-TMCH marks to gain advantage in Sunrise); Targeting the non-TMCH marks for counterfeiting, knock-offs, etc. (on the theory that the brand owner is less likely to put resources into policing and enforcing these less important marks), etc.
>
> However, if I'm incorrect about any of this, I'm always happy to learn new facts.
>
> I am aware that some applicants may choose to file in jurisdictions where registrations issue more quickly.  Even this limited scenario is not the practice of any brand owners I have represented or of which I'm specifically aware.  I can't speak to who or what type of applicant engages in even this limited practice.
>
> I do recall that one or a few people or entities have used some aspects of this strategy or something similar to try to "game" Sunrise.  The specific concern about gaming the TMCH and Sunrise is one that I believe we need to deal with. I believe we should do this in a targeted fashion, both to get to consensus in the WG and to avoid disadvantaging legitimate TMCH registrants.
>
> Best regards,
>
> Greg
>
> On Fri, Oct 11, 2019 at 12:52 PM Jason Schaeffer <jason at esqwire.com> wrote:
>>
>> Hi All,
>>
>>
>>
>> Sorry for not being able to address this on yesterday’s call – I was bounced from the Zoom and couldn’t reconnect from my mobile.  After much consideration of the chat comments and statements during the past two calls I’ve parsed together the following strategy concerns that might be at issue.   It seems the opposition to an open/transparent TMCH have set forth the following rationale:
>>
>>
>>
>> Large brand owners like the ability to file in “remote” jurisdictions with non-searchable DBs to gain a priority date that can later be used for priority presumably in the US under a Section 44 application under the Paris Convention.   For example, Party A could “secretly” register in say Mauritius or Jamaica (jurisdictions that I believe do not have searchable DBs), and then file a Section 44 with the USPTO when ready to “go public.”   In this scenario, large brand owner obtains the earlier priority date in the US without having disclosed its “secret” brand plans or strategy.   Alternatively, there may also be a similar use case with a registration in the EU.  This is what I understand the opposition was presenting in the comments last week and again yesterday.
>>
>>
>>
>> This use of the “secret TM priority” filing method is one thing, and I understand the ostensible business intelligence concerns to require such a tactic.   However, we are discussing this in the context of the TMCH.  How can these parties obtain Sunrise protection without proof of use?   This is even more challenging in the case of an EU registration that might not be based on actual use.
>>
>>
>>
>> If the project is top secret and subject to heightened secrecy, how can the party then show legitimate use of the mark and obtain TMCH protection while maintaining its purported heightened secrecy?  What is the POU and what is the declarant stating to the TMCH?  Is this the position that the opposition is proffering to block transparency of the TMCH?
>>
>>
>>
>> In addition, if I am correctly capturing how the method is employed in practice, it would be helpful to know if this practice is really in widespread use or rather an outlier, because I’m not yet seeing an important justification that outweighs the important benefits of an open TMCH.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Jason
>>
>>
>>
>> _______________________________________________
>> GNSO-RPM-WG mailing list
>> GNSO-RPM-WG at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
>> _______________________________________________
>> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> GNSO-RPM-WG mailing list
> GNSO-RPM-WG at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rpm-wg
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rpm-wg/attachments/20191013/3091e41e/attachment.html>