[1484] in cryptography@c2.net mail archive
Re: Netscape SSL Patent
daemon@ATHENA.MIT.EDU (David Jablon)
Mon Sep 15 13:44:59 1997
Date: Mon, 15 Sep 1997 15:55:00 -0400
To: Marc Horowitz <marc@cygnus.com>
From: David Jablon <dpj@world.std.com>
Cc: 3umoelle@informatik.uni-hamburg.de (Ulf =?iso-8859-1?Q?M=F6ller?= ),
cryptography@c2.net
In-Reply-To: <t53en6rp2uo.fsf@rover.cygnus.com>
About the Netscape patent,
At 01:23 AM 9/15/97 -0400, Marc Horowitz wrote:
>David Jablon <dpj@world.std.com> writes:
>
>>> FILED: Aug. 25, 1995
>>>
>>> 3. A method of encrypting and decrypting information
>>> transferred over a network between a client application
>>> program running in a client computer and a server application
>>> program running in a server computer, the method comprising:
>>>
>>> providing a socket application program interface
>>> to an application layer program;
>>> [*] providing encrypted information to transport protocol
>>> layer services;
>>> encrypting information received from an application
>>> layer program; and
>>> decrypting information received from transport protocol
>>> layer services.
>
> Together, IPSEC (including ancestral and related technology, such as
> swIPe and SKIP, which all provide a socket API), and the GSSAPI
> enhanced ONC RPC (which sits between the transport and application
> layers) seem to provide prior art for all the claims in this patent.
> I'm not sure when SOCKS came about, but it would seem to be prior art
> all by itself.
I agree.
>>> Presuming that Netscape intends to enforce this, and
>>> that others might want to challenge it, to survive it
>>> must be novel over newly cited prior art. The main thing
>>> that makes it potentially different than many other
>>> encrypted transport layers is the phrase I marked with a [*].
>>>
>>> It might only take one good example of earlier work that
>>> used any kind of encrypted data to control the
>>> transport layer to invalidate this.
>
> I'm not exactly sure what this phrase means. I think it means
> "passing ciphertext to a transport layer" (I don't see where "control"
> comes in here). This seems to describe pretty much every network
> security system I know of: you have to get the ciphertext out for it
> to do any good. Why do you think this is novel?
Oh, no. I never said it was novel. My first pass at reading the
claims was (as stated) a two-minute analysis, meant to
show how they were overly broad, and thus weak. Generously
to Netscape, I assumed the '*'ed line was *meant* to cover
something more special, like passing encrypted information
to control the actions of some "transport protocol layer".
I must have been blinded by disbelief that they would
try to claim something so much broader.
Clearly my first reading was too narrow. The broader
interpretation of yours, others, and now mine, make the
claims look truly outrageous, regardless of the original
authors' intent.
But someone should probably study all 100 or so pages
of the patent to insure they haven't used strange and
special definitions for the words in the claims.
> Legal question: at what granularity does this stuff work? if I write
> a program which only does a subset of the items listed in a claim, is
> it infringing? ...
No. It must include all elements of the claim to infringe.
(I'm not a lawyer, but these are pretty basic questions.)
> ... Similarly, if I have prior art for a subset of the
> listed items, is that grounds to invalidate the entire claim?
Maybe, in special cases. But the easier way is to show
prior art using all elements.
------------------------------------
David Jablon
Integrity Sciences, Inc.
dpj@world.std.com
<http://world.std.com/~dpj/>
