[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: dvd-discuss(at)eon.law.harvard.edu*Subject*: Re: [dvd-discuss] Gedanken Experiment -Unix and Norton*From*: microlenz(at)earthlink.net*Date*: Thu, 10 Jul 2003 18:58:07 -0700*In-reply-to*: <3F0D8493.E0A65050@ia.nsc.com>*Reply-to*: dvd-discuss(at)eon.law.harvard.edu*Sender*: owner-dvd-discuss(at)eon.law.harvard.edu

On 10 Jul 2003 at 9:21, John Zulauf wrote: Date sent: Thu, 10 Jul 2003 09:21:55 -0600 From: "John Zulauf" <johnzu@ia.nsc.com> To: dvd-discuss@eon.law.harvard.edu Subject: Re: [dvd-discuss] Gedanken Experiment -Unix and Norton Send reply to: dvd-discuss@eon.law.harvard.edu > The reason I think we should care about this issue, is until novel, > non-obvious algorithms can be protected. Source code will not be > generally published, as the only protection these algorithms currently > have is "trade-secret". The argument does not follow. Source code is NOT an algorithm it is an implementation OF an algorithm. Bubblesort is an algorithm NOT the source code for one. The SCOTUS rightly stated that algorithms were just mathematical facts and like facts about nature or physical laws NOT patentable or copyrightable. The Cooley Tukey algorithm is nothing more than instead of calculating an DFT directly, compute the terms in this order combinging them this way. It's quicker.Take polynomical evaluation Stupid algorithm says a0 add it to a1*x add that to a2*x*x etc. Better algorithm says take store x as p, a0 add to a1 *p, multiply p by x, etc etc...Horner's algorithm orders them even better an*x + an- 1 etc etc. What's patentable? What's copyrightable? NADA THING. >A "from scratch" reimplementation of an > algorithm is on a derived work, from a copyright point of view > (especially if a clean room approach is used with Team A looking at the > code and documenting the algorithm with Team B implements). Thus "to > promote progress" by reducing the number of trade secrets, one must > afford these trade secrets patent protection. Correctly taking prior > art into account and setting a high standard for novelty and > non-obviousness would clearly be need. > > > microlenz@earthlink.net wrote: > > > > > That's called an algorithm....not copyrightable....I haven't seen the more > > recent case but at one time the Supremes ruled that an algorithm seem to be a > > fact of nature and not even patentable. > > > > This is one where the Supremes got it somewhat backwards. Some things > that are called "algorithms" (incorrectly) are fundamental laws. > Addition, subtraction, square root calculus, linear algebra, "Domain > transforms" (like Fourier, Cosine, LaPlace) are mathematical > "fundamental laws" (question: is Mathematics invented or discovered?). > However, numerical methods (from pivot-row matrix inversion, FFT, to the > humble Riemann's sum) are invented processes to emulate, simulate, or > calculate the results from these "laws" or optimize that computation. > > The only thing patentable in software should be "novel" and > "non-obvious" algorithms. That items can be sorted by value is a > "definitional law" -- a process by which they can be sorted in log or > linear time is an invention. The copyrightable expression of an > algorithm is the manufacture to the algorithmic device in a particular > choice of material of manufacture. > > Mind you, the standard for algorithmic patentability should be high -- > "novel" and "non-obvious" applies to a handful of algorithms over the > course of a decade, and not tied to the application of the algorithm -- > c.f. the "keyframe animation" patent ("use of colocational interpolation > for interpolation postions and orientations of computer animated object" > -- feh!). > > On the short (very) list of what would have been potentially patentable > algorithms: > > * Sorting algorithms: bubblesort, quicksort, heapsort, stupidsort (note > 1) > * Search algorithms: ... > * forms-based quasi-interactive interfaces (note 2) > * raster graphics > * vector graphics > * display list graphics > * Compression: > * General purpose: LZ, LZW et. al. > * Human perception based quantization > * zig-zag RLE encoding of DCT terms > * various delta compressed and predictor/error encoding > * motion estimation technique (a search algorithm) > * finite element (and difference) methods > * matrix inversion techniques > * FFT -- FFT is an optimized technique for a domain transform > * cryptographic ciphers > * routing algorithms > * traveling salesman, airline shedule, Si compiler > > > (note 1) stupidsort (I believe that is the correct name) selects an > order for the list at random, checks to see if the list is in order, and > if not selects another random order. (posited as the "worst possible > sorting algorithm"). Given the combinatorics of the list, the random > number generator would need a very high dynamic range. Ever notice > "freecell" (a windows solitaire program) has only a 16 bit game ID? > This covers a minute fraction of the possibility space for a shuffle > deck. > > (note 2) this would apply to BOTH the IBM 3270 terminals and the Web > Browser-- the IBM mainframe -- terminal control -- forms based terminal > was novel. The WWW wasn't > > NOT suitable for patent > > file formats (not a process but a declaration) > DCT/iDCT transformation (domain transform) > use of XYZ algorithm for ABC application (no application component) >

**Follow-Ups**:**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton***From:*"John Zulauf" <johnzu@ia.nsc.com>

**References**:**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton***From:*"John Zulauf" <johnzu@ia.nsc.com>

- Prev by Date:
**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton** - Next by Date:
**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton** - Previous by thread:
**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton** - Next by thread:
**Re: [dvd-discuss] Gedanken Experiment -Unix and Norton** - Index(es):