----- Original Message -----
From: "John Levine" <johnl(_at_)iecc(_dot_)com>
To: <ietf-mxcomp(_at_)imc(_dot_)org>
Cc: <ietf-mxcomp(_at_)imc(_dot_)org>
Sent: Tuesday, September 21, 2004 11:09 PM
Subject: Re: regarding the trademark for "Sender ID"
I thought this trademark issue was resolved at IETF-60. According to
Harry, the Microsoft lawyers investigated it and, unlike terms like
"windows", "word", and "access", they determined that "SenderID" was
generic and could not be trademarked.
Since the USPTO shows two live registrations (from the same company)
for the term SENDERID, I can't say that I'm too reassured by that
legal analysis. I can tell you from experience that if the USPTO
thinks a term is too generic, they won't accept a registration for it.
The UK company has encapulated the IP protection by registering the terms:
SenderID
Trusted SenderID Message
both as a Server Mark and Trademark.
The distinction is important. If there is any weight in the strength, it
would be the "Trusted Sender Message" Service Mark and Trademark.
As a trademark would be a like a product name or brand As a service mark,
it is part of a 'system', like a protocol or API.
With "SenderID" itself, they will have trouble enforcing. The most obvious
would be as a trademark - too generic. As a service mark, they could claim
market confusion and if they can show lost of exclusive income, they might
be able to get a case heard, but it would be difficult to prove with this
just this specific word usage.
The prior art exist. SenderID has been part of our API and channel
communications framework in our Wildcat! telecommunications and data
communications/hosting product since 1987. Here is our C structure for it:
typedef struct tagTWildcatChannelMessage {
DWORD Channel;
DWORD SenderId;
WORD UserData;
WORD DataSize;
BYTE Data[MAX_CHANNEL_MESSAGE_SIZE];
} TWildcatChannelMessage;
No doubt we have a proven case of long term prior usage for many years and
thus they would have difficult enforcing this service or trademark. They
can't stop us from continuing the usage of this single term for our
telecommunication/data products. Plain and simple.
Now as a Trademark, if we did something like "Wildcat! SenderID Protocol"
there could be a risk here for market confusion against the "Trusted
SenderID Message" Trademark, but not as a SenderID service mark.
For Marid, using it in the overall MARID protocol could be open to a
challenge if MARID uses SenderID by itself in documentation/communications.
I doubt the owner could claim a lost, but down the road (years) once it has
been branded, they can claim market confusion and lost of potential
exclusive income.
Again, they have to be able to prove market confusion and lost of exclusive
income.
Here is a very possible situation in these days of age with the growth of
web mail ads and the new borderline unethnical email scanning systems such
as gmail.com:
The UK company has a potential customer who is inquirying about their
"Trusted SenderID Message" product offerings. The user has a gmail.com
account and gmail.com scans the mail for keywords and frames the company's
sales response message back to the user with direct marketing advertisements
pointing to the various and/or fee-paying exclusive competing methods such
a "Microsoft SenderID Protocol" whoi now has embedded the technology in
Microsoft's new Exchange Mail Server. The user sees this new competing
information with interest and eventually foregoes the UK solution for
Microsoft solution.
Back hair will raise when the company does a sales followup and founds out
the user saw an ad about Microsoft's system and opted to go that way. The UK
company will have a big argument for tortious interference against gmail and
trademark infringement against Microsoft claiming market confusion and lost
of sales. Probably lost the trademark suit, but will win the tort claim.
It has already happen with success and good reason.
In the unlikely event that MARID recommends Microsoft's Sender-ID for
standardization in spite of its technical and patent problems, I agree
that it's no big deal at this stage to pick a different name.
This is what I did with Microsoft CallerID for our documentation and
implementation. For our product, we don't call it CallerID. It conflicts
with existing CallerID terminology in our product line. So its called
MCEP - Microsoft Caller ID Protocol.
For MARID, if it wants to keep using SenderID, it needs more words attaches
to it, like "Microsoft SenderID Protocol" or "MARID Sender Identification
Protocol" with a possible acronym MSP or MSIP.
Look people, the only way I will use MARID if at all, is with its CORE only.
In my strong opinion (I already stated this before), the MARID core should
be generic as possible which can service an security augmentaion to the SMTP
protocol.
This will give it the maximum consideration by everyone who might have
interest in one or more protocols, but more importation it allows MARID CORE
to be an "basic specification" for future possible security protocols.
As it is right now, its locked in to a few selected solution and these
solutiion have problems in various forms. If they didn't, they would of been
adopted and implemented by now.
In case, the MARID-CORE can have generic terms such as:
SMTP MAIL SENDER IDENTIFICATION PROTOCOLS
and then have its index or addendix reference the various methods currently
in place.
Again, this allows for future possible ideas to fit in the MARID solution,
thus be a "plug and play" concept for mail server vendors to implement and
offer to this customers.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office