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