*BSD News Article 6140


Return to BSD News archive

Xref: sserve comp.org.eff.talk:9393 misc.int-property:576 comp.unix.bsd:6188
Newsgroups: comp.org.eff.talk,misc.int-property,alt.suit.att-bsdi,comp.unix.bsd
Path: sserve!manuel.anu.edu.au!munnari.oz.au!sgiblab!pacbell.com!decwrl!netcomsv!netcom.com!mcgregor
From: mcgregor@netcom.com (Scott Mcgregor)
Subject: Re: Patents:  What they are.  What they aren't.  Other factors.
Message-ID: <1992Oct6.182846.21881@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
References: <10880.Sep3008.43.0892@virtualnews.nyu.edu> <1992Oct1.090209.9474@netcom.com> <12962.Oct320.42.3592@virtualnews.nyu.edu>
Date: Tue, 6 Oct 1992 18:28:46 GMT
Lines: 76

In article <12962.Oct320.42.3592@virtualnews.nyu.edu> brnstnd@nyu.edu (D. J. Bernstein) writes:

>Scott is saying that any two algorithms which produce the same results
>are, in fact, the same. But this isn't true. According to common sense
>(and the courts) the two algorithms have to produce the same results _in
>the same way_. Otherwise they're not the same.

Actually, I agree with Dan.  But I think the question comes down to
what is meant by "the same way". Not in every last detail. But rather
in respect to every detail specified in the patent claims.  If the
patent is broad (say data compression in the form of "conversion of a
stream digital signals to a shorter stream in a fashion that allows
the longer stream to regenerated from the shorter stream by
reversing the transformation") then you would only have to "the same
way" in the broadest sense. If it goes on to be more specific by
saying "by applying step A, B, and C, in sequential order" then only
those  methods that use A, B and C in sequential order infringe.  If
you use only A, and C, or use them in nonsequential order it isn't
"the same way", because what counts was explicitly stated in the
claim. If your process uses A, A1, B, B1, C and C1. You might say
that's not the same way. But to the patent court it is because it
still has A, B, and C in it in sequential order. The new variant might
be patentable in its own right as an improvement but still infringes
on the old one.

>
>To put it differently: A patent examiner following Scott's recipe for
>determining equivalence would look at insertion sort, and quick sort,
>and not be able to tell the difference.

If the claims for each don't specify SPECIFIC steps, this is correct.
But if they do, then those specific steps must be physically
determinable and become the way to detect if there is a relevant
difference or not.

>You cannot patent all processes which achieve a given result. In
>particular, you can't patent the concept of a faster modem.

Yes, but you can get broad coverage such as getting a patent on
reducing the number of signals rather than on their time intervals, or
rather than sending several signals of different frequencies
simultaneously.  It may be that at this point getting such broad
coverage is impossible.  This is likely to mean more patents (but more
narrowly drawn) may be granted in the future. But at the same time
there is less likelihood of infringement than compared to a broader patent.

>Fine. The burden is now on you to explain how a patent examiner, faced
>with ``The Fast Foo Method of Sorting Data'' and ``The Fast Bar Method
>of Sorting Data,'' can reliably determine whether Foo is prior art for
>Bar, or vice versa.

The method I would use is the one I understand the PTO uses. First, I
would look at the dates of invention for Foo and Bar methods, when
they were published, sold, etc. only one can possibly be prior art for
the other.  I'd then focus on that particular case.  Next I would look
at the claims. Are the specified steps in the claims for the prior one
which aren't in the successor?  If so, then the second doesn't
infringe. If all the claims in the former are a subset of the claims
of the latter, then it is an infringment (but still might be granted
as an improvement patent).   But steps given must be physically
determinable, or they shouldn't be allowed in the claims in the first
place.





-- 

Scott L. McGregor		mcgregor@netcom.com
President			tel: 408-985-1824
Prescient Software, Inc.	fax: 408-985-1936
3494 Yuba Avenue
San Jose, CA 95117