<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [bc-gnso] BC comment on singular plural
- To: Mari Jo Keukelaar <mj@xxxxxxxxxxxxxxxxx>, "'Smith, Bill'" <bill.smith@xxxxxxxxxxxxxx>, "'Andy Abrams'" <abrams@xxxxxxxxxx>
- Subject: Re: [bc-gnso] BC comment on singular plural
- From: "J. Scott Evans" <jscottevans@xxxxxxxxx>
- Date: Thu, 15 Aug 2013 14:10:27 -0700 (PDT)
Unless you're Google, right?
j. scott evans - head of global brand, domains & copyright - Yahoo! Inc. -
408.349.1385 - jscottevans@xxxxxxxxx
________________________________
From: Mari Jo Keukelaar <mj@xxxxxxxxxxxxxxxxx>
To: "'Smith, Bill'" <bill.smith@xxxxxxxxxxxxxx>; 'Andy Abrams'
<abrams@xxxxxxxxxx>
Cc: jscottevans@xxxxxxxxx; 'bc - GNSO list' <bc-gnso@xxxxxxxxx>
Sent: Thursday, August 15, 2013 11:51 AM
Subject: RE: [bc-gnso] BC comment on singular plural
Clearly, we all agree that the question of confusing similarity of generic
terms is not a trademark matter. I believe that this is supported by what I
have been saying.
Given our universal agreement on that score, Objectors in string similarity
proceedings would have done well not to cite trademark cases in support of
their arguments. Trademark law does not support a concept of "confusing
similarity" as applied to generic words. Between two brands of dog food whose
labels say "dog food" or "food for dogs", there is no principle of trademark
law which will posit consumer confusion between brands as to what is inside the
can.
So if Objectors have used the DuPont or Sleekcraft factor analyses in their
objections, it is no surprise that the arguments are being rejected. Someone
hired trademark lawyers to argue a case which, as we all agree, is not a
trademark issue.
The objectors should simply have made the argument that it is self-evident
common sense instead of muddying the waters by reference to trademark law. But
there again, the objectors would be asking the panelists to make a policy
decision, instead of deciding the case in front of them.
The problem, as I see it, is that this was not addressed as a policy matter,
and we are now expecting the issue to be resolved in a number of one-off
decisions which, as I have also said, is no way to formulate policy. We are
experiencing a failure on our part as a policy making community, and not a
failure of ICANN, the ICC or the panelists.
Indeed the GAC has taken an interest in this matter, as they have in relation
to regionally geographic terms, to the detriment of a prominent Luxembourg TLD
applicant. One might assume that Luxembourg did not have sufficient influence
on behalf of their native TLD applicant. Perhaps if that applicant was a
native US applicant and taxpayer, the US could have been of more assistance to
them, but it is not usually the case that the US government will exert itself
on behalf of foreign entities.
If we, not only as a supporting organization, but as a community as a whole,
rely on the GAC to resolve our policy issues, they may seek to resolve issues
of their own. Then we should not be so quick to jump all over them for what we
perceive as their failure, as we have done, not only to the GAC but to the
panels I have been defending in these posts.
Mari Jo
From:owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of
Smith, Bill
Sent: Wednesday, August 14, 2013 7:03 PM
To: Andy Abrams
Cc: Mari Jo Keukelaar; jscottevans@xxxxxxxxx; bc - GNSO list
Subject: Re: [bc-gnso] BC comment on singular plural
+1
I don't see this as a trademark issue. Rather it is an issue of common sense
and "doing the right thing". It seems we lose on both counts.
On Aug 14, 2013, at 1:34 PM, Andy Abrams <abrams@xxxxxxxxxx> wrote:
Hi Mari Jo,
Thank you for your input - I think we're actually opposite each other in the
other pending car/cars case, so it's good to get other perspectives. You raise
some very valid points, and I think the ICDR will likely agree with your legal
reasoning. But speaking only for myself, my concerns are not based on the
application of trademark law at the top level. Rather, as an Internet policy
matter, I respectfully believe that allowing generic singular-plural TLDs will
be confusing to consumers and bad for businesses that wish to operate websites
on one of the two TLDs. Imagine a case where a legitimate business is faced
with negative PR, or worse, scams/phishing, etc. because half of their
prospective customers mistakenly go to used.cars instead of used.car.
Secondly, simply as a matter of process, if is literally impossible to win a
string confusion objection unless ICANN had already placed the strings in
contention (thereby making the need for an
objection moot), it would have been nice to have that guidance prior to
everyone expending money and resources on these proceedings. I guess we'll
learn very soon whether the remaining singular-plural decisions follow suit...
Best,
Andy
On Wed, Aug 14, 2013 at 12:41 PM, Mari Jo Keukelaar <mj@xxxxxxxxxxxxxxxxx>
wrote:
To be clear: the decisions reached in car/cars and hotel/hotels are actually
more in keeping with present interpretation of trademark law than they are
dissimilar since plurals of generic words are not "confusingly similar" to
other generic words under traditional trademark analysis. We should avoid
applying terminology from trademark law out of context, in what are contests
between strings that are not themselves trademarks.
In these "generic word" disputes, the objecting parties have tended to make
arguments based on trademark confusing similarity analysis. In that analysis,
though, the trademark has already been determined to be distinctive. So those
circumstances involve comparing something to something else which has
established distinctiveness. The point is to avoid erosion of what are already
distinctive marks. That reasoning just does not apply to generic terms.
This has been true for years under the Uniform Domain Name Dispute Policy. No
confusing similarity was found between “Tire Discounter” and “Tire Discounters”
despite the difference of only a single letter in Tire Discounters, Inc. v.
TireDiscounter.com, NAF Claim Number:
FA0604000679485 (“[b]ecause the mark is merely descriptive, small differences
matter”).
Nor was confusing similarity found between the “The Suit Warehouse” mark and a
“SuitWarehouse” domain name because the presence of descriptively common words
necessarily restricts the “confusingly similar” analysis very closely to exact
identity. The Men's Wearhouse Inc. v. Brian Wick d/b/a Defaultdata.com, NAF
Claim Number: FA0208000117861.
The results have been no different under the Lanham Act. In a similarity
analysis between “ENTREPRENEUR” and “ENTREPRENEUR PR” in two internet domain
names, the 9th Circuit declined to find confusing similarity, noting, “[i]n the
Internet context, consumers are aware that domain names for different Web sites
are quite often similar, because of the need for language economy, and that
very small differences matter.” Entrepreneur Media, Inc. v. Smith, 279 F. 3d
1135, 1147 (9th Cir., 2002).
Additionally, the notion that terms lacking distinctiveness are not subject to
"confusing similarity" analysis is also true outside of the US, as the High
Court of Australia opined in Hornsby Building Information Centre Pty Ltd v.
Sydney Building Information Centre Ltd, [1978] HCA 11:
“There is a price to be paid for the advantages flowing from the possession of
an eloquently descriptive trade name. Because it is descriptive it is equally
applicable to any business of a like kind, it’s very descriptiveness ensures
that it is not distinctive of any particular business.”
Of course if you are dealing with established distinctive marks then, yes,
"Verizons" will be confusingly similar to "Verizon". But the scope of
"confusing similarity" has always been delimited by the distinctiveness of the
mark under analysis.
That a panel, applying ordinary principles of application of the trademark term
"confusingly similar" would decline to find such similarity between two generic
words is neither surprising nor unusual. If this was an unexpected result, then
one might just as well ask how lawyer.com and lawyers.com manage to exist under
different ownership (along with cars.com/car.com, house.com/houses.com
dog.com/dogs.com, and many other generic words).
Furthermore, and perhaps even more importantly, under the ICANN rules we are
not merely looking at "confusing similarity" but rather, a higher standard of
"impermissible" confusing similarity. Comparing these string objections to
outcomes in trademark cases is the proverbial mixing of apples and oranges
because the generic strings involved are not, as a threshold matter, even
trademarks. The lack of distinctiveness in generic words drives the result that
they are not entitled to the broad swath of protection afforded that which
would be impermissibly confusing.
ICANN has done much to protect trademark interests and we can all argue as to
whether they have done enough or not. Here, however, we are not even talking
about trademarks; we are dealing with two generic terms. The panels did not
lose sight of that and I wonder why we sit here bashing them for applying the
Policy we all approved and the law over which we’ve little control.
Mari Jo Keukelaar, M.A./J.D.
Name Administration, Inc.
From:owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of Andy
Abrams
Sent: Tuesday, August 13, 2013 7:09 PM
To: Steve DelBianco
Cc: bc - GNSO list
Subject: Re: [bc-gnso] BC comment on singular plural
Update: the first singular-plural decisions have come in. Both singular-plural
decisions have gone against a finding of string confusion (our car/cars
objection against Donuts, and a Hotel Top-Level-Domain S.a.r.l. v. Booking.com
B.V. for hotel/hotels). In the car/cars decision, the Panel stated: "It is
true that
the ICANN visual similarity standards appear quite narrow, but it is not the
role [of] this Panel to substitute for ICANN’s expert technical findings." In
the hotel/hotels decision, the Panel similarly stated: "I find persuasive the
degrees of similarity or dissimilarity between the strings by use of the String
Similarity Assessment Tool, that ICANN did not put the applications for .HOTEL
and .HOTELS in the same contention set." In other words, the early results
suggest that the ICDR may give complete deference to ICANN's earlier refusal to
essentially find any instances of string confusion, no matter how close the
strings.
Andy
On Thu, Apr 11, 2013 at 12:50 AM, Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>
wrote:
Here's what we just told the Board at the Public Forum, on behalf of the BC
ICANN’s String Similarity Panel was to place into contention sets any strings
that create a possibility of user confusion.
But in late February ICANN published contention sets that did NOT include 24
pairs of singular-plural forms of the same string (English and Spanish)
Sport(s) Loan(s) Web(s) Game(s) Hotel(es)
Risks of allowing both singular and plural TLDs for the same word are well
understood.
-confusion
-precedent for the next round
-ICANN looking pretty ridiculous
What’s not understood is how it happened and what we can do about it.
First response is to ask if the panelist follow GNSO Policy on confusingly
similar.
Second response is “Chong” ( Chinese for “Do-over” )
-Do-over on just these 24 pairs
- WIPO Mediation Rules, Article 1 says, “Words used in the singular include the
plural and vice versa, as the context may require.”
Guess we could correct the Guidebook (plurals are confusingly similar)
String Confusion Objections on 7 of these pairs are in the hands of the ICDR
rightnow. If ICSR does the right thing and finds these pairs should be
contention sets, The Board can apply this rule to ALL 24 pairs
Failing that, there’s Formal Reconsideration.
We all worry about threat from inter-governmental groups just waiting for ICANN
to stumble.
We have enough vulnerability to stumble with so many unknowns in the new gTLD
launch.
No need to add to our vulnerability with this self-inflicted wound
--
Andy Abrams | Trademark Counsel
Google | 1600 Amphitheatre Parkway, Mountain View, CA 94043
(650) 669-8752
--
Andy Abrams | Trademark Counsel
Google | 1600 Amphitheatre Parkway, Mountain View, CA 94043
(650) 669-8752
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|