[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Be careful - Sun Microsystems asks for prior art for '646
Hmm ... a good point (from Greg below) ... anyone care to comment?
Ern
------- Forwarded Message
Date: Thu, 19 Sep 1996 15:50:04 -0400
From: srctran@world.std.com (Gregory Aharonian)
To: patent-news@world.std.com
Subject: PATNEWS: Be careful - Sun Microsystems asks for prior art for '646
!19960919 Be careful - Sun Microsystems asks for prior art for '646
A short while ago I sent out a news item reporting that some people
in the encryption community were accusing Sun of doing a Dell - that is,
applying for patents on technology discussed/developed by a standards
committee. Sun is denying that it did so, to the extent that they posted
the following message on some of the Internet discussion groups:
====================
There have been recent Internet discussions relating to U.S. Patent
No. 5,548,646 (the '646 patent) assigned to Sun Microsystems, Inc.
("Sun"). In particular, there have been suggestions that there is
prior art that would bring into question the validity of the claims
of the '646 patent.
Sun strongly believes in obtaining and maintaining only those patent
rights that are proper in light of any prior art that may exist.
Sun does not have any interest in enforcing any patent claims having
a scope beyond that to which it is properly and legally entitled.
In keeping with this approach, if anyone is aware of prior art relevant
to the '646 patent, please send information about the prior art to Sun
in care of:
Sun Patent Department
2550 Garcia Avenue, MS-UPAL01-521
Mountain View, CA 94043-1100
If any prior art turns up that is more relevant than the art that was
before the Patent Office during prosecution of the '646 patent, Sun will
take the appropriate steps to bring that art before the Patent Office so
that the Patent Office can reconsider the claims of the '646 patent in
light of the new art.
The Patent Office considered two patent documents during prosecution
of the '646 patent: U.S. Patent No. 5,416,842 and U.S. Patent No.
5,204,961. Sun suggests that those interested in this issue should
first obtain and review both the '842 patent and the '961 patent before
submitting additional art to Sun.
Sincerely,
Sun Microsystems, Inc.
====================
This is a nice publicity stunt by Sun, and I say stunt, because Sun is not
as serious about prior art as it states in this message, ".... in light of
any prior art that exists". It is as serious as most others in the industry,
which is to say, not that serious. Indeed the tone of the above request
reflects the typical attitude that prior art means patent prior art.
In my database of software patents, I pulled out about 25 software patents
awarded to Sun in the 1995/1996 time period. On the average, each patent
cited on the front page 3 non-patent prior art items, half of which cited
0 or 1 non-patent prior art items (for example, 5,379,426 - "Method and
apparatus for object oriented interprocess message switching"). This record
doesn't reflect a real serious commitment by a company with a lot of money
to find much of the relevant prior art. Maybe Sun doesn't know that Stanford
University has libraries.
Sun's request is also disingenous for another reason. The Sun lawyers know
that no potential infringer trusts the current third party reexamination
system, where only the PTO examiner and Sun lawyers would be present to
discuss the newly revealed prior art. It is the same reason few heeded the
PTO's call to submit prior art for the Compton's patent - they wanted to
save the good stuff for any future court action where they could participate.
So if in fact you have any good killer prior art, you might want to consider
saving it for any future court actions, where you control how it is used,
not Sun's lawyers. Know that you have no say in the discussions between
the PTO and Sun during the reexamination - know that Sun's lawyers know this.
Greg Aharonian
Internet Patent News Service
------- End of Forwarded Message
Date: Thu, 19 Sep 1996 13:51:59 -0400
Message-Id: <9609191751.AA18970@dcl.MIT.EDU>
From: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: ipsec@TIS.COM
In-Reply-To: ipsec-approval@neptune.hq.tis.com's message of Wed, 18 Sep 1996
11:33:52 -0700 (PDT), <9609181440.aa23915@neptune.TIS.COM>
Subject: Re: IPsec Minutes from Montreal
Address: 1 Amherst St., Cambridge, MA 02139
Phone: (617) 253-8091
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Date: Wed, 18 Sep 1996 11:33:52 -0700 (PDT)
From: ipsec-approval@neptune.hq.tis.com
Really-from: I'm not sure, since the ipsec list seems mildly broken,
but the message was signed "--tom"
> The second mode uses ephemeral Diffie-Hellman,
> with certificates, in a 2-6 message exchange depending on how much state
> already exists in the end nodes (specifically: 2 messages for Certificate
> Discovery Protocol, 2 messages for Algorithm Discovery Protocol, plus 2
> messages for PFS before the first data packet can be sent)
This is editorializing.
If you insist on counting one-time messages, then the next time someone
says that an SNMP trap is a one message protocol, please be sure to
point out that it's actually a 5 message protocol, "depending on how
much state already exists in the end nodes": 1 for the trap, 2 for the
DNS lookup, and 2 for the ARP request-response.
Actually, no, this is the key part of the difference between SKIP and
ISAKMP. A large part of the dispute centers around how one does the
"counting" of packets. So saying "2-6 messages" is in fact quite fair.
The ISAKMP partisans are claiming that it's not fair to say that SKIP
only takes 2 messages, because using the requirements set up by the wg,
it's not clear that you can always skip these "one-time" messages.
According to this camp, Sun has traditionally architected solutions
which work well for the small LAN case (remember NFS and 8192 byte
packets, with checksumming turned OFF?) that didn't necessarily work
well in the Real World Internet.
Hence, if you are going to be talking to a lot of different sites, it's
not clear that you can *always* cache the all of the certificates,
results of the algorithm negotiation, etc. What's the cache hit ratio?
How big do you let your caches grow to? etc. In addition, if CDP and
ADP are optional and not implemented by all implementations, then you
have really large interoperability problems, which may not surface on
the a small work-group sized LAN, but do on the greater Internet.
It is too much to ask that the minutes accurately and fairly record
what took place at the meeting?
Well, the problem is that any time the minutes say anything good or bad
about either protocol, people are going to claim that the minutes aren't
"fair". According to the ISAKMP camp, saying that SKIP "only" takes 2
messages is a skewed, slanted view. So, it works both ways.
Unfortunately.
- Ted
To: John Gilmore <gnu@toad.com>
Cc: ipsec@TIS.COM
Subject: Re: The WG's inability to choose is good in this case.
In-Reply-To: Your message of "Wed, 18 Sep 1996 18:21:43 PDT."
<9609190719.aa05593@neptune.TIS.COM>
Reply-To: perry@piermont.com
X-Reposting-Policy: redistribute only with permission
Date: Thu, 19 Sep 1996 14:20:31 -0400
From: "Perry E. Metzger" <perry@piermont.com>
Sender: ipsec-approval@neptune.tis.com
Precedence: bulk
Message-ID: <9609191635.aa11629@neptune.TIS.COM>
I believe John has put his finger on something important.
John Gilmore writes:
> We are stuck for a good reason; we don't want to make a good political
> decision. We want to make a good technical decision, and there is no
> good technical choice for securing the Internet right now. The IPSEC
> process is working. It looks too slow because the technical proposals
> and implementations need to evolve faster than they have been, not
> because the consensus process has failed.
I tend to agree.
Perry