From: cyberoid@milton.u.washington.edu (Robert Jacobson) Subject: About Patents (LONG) Date: Wed, 9 Oct 1991 09:29:31 GMT Organization: Human Interface Technology Lab, Univ. of Wash., Seattle I have crossposted this article from comp.patents because it is a servicable overview of the computer patent situation in which we find ourselves today. It is not an acutely accurate report by an attorney, so far as I can tell, but rather one layperson's attempt to make sense of things in a way that others can follow. If you have the time, do download and read at your leisure. --------------------------------------------------------------------- Article: 52 of comp.patents From: ritter@cactus.org (Terry Ritter) Subject: Patent Overview Date: 9 Oct 91 09:05:21 GMT Lines: 352 1. Recently, there has been an interesting discussion in comp.compression about a new patent that may limit the LZRW algorithms recently described there. As far as I can tell, the facts are these: a. Ross Williams invents the LZRW series of algorithms in 1989, and has logs and listings of this work. b. Gibson and Graybill apply for patent protection in June 1990 (their date of invention is not known). c. Williams openly publishes in April 1991. d. The Gibson and Graybill patent (U.S. Patent 5,049,881) issues in Sept. 1991. 2. Before opening the discussion, I know that many people on the network disdain "software patents," and perhaps even feel that the government will eventually change this policy. So some of these people may feel that even a cursory knowledge of patent matters will be a waste of their time. However, any discussion of "software patents" inevitably turns to technical patent matters, and then some people imagine that they can get by with their knowledge of words, logic, software, and the world. Alas, the law is not like that. I suggest that anyone interested in the U.S. patent situation obtain a copy of the excellent book: _Patent_it_Yourself_, by Patent Attorney David Pressman (Nolo Press, 950 Parker St., Berkeley, CA 94710, (800) 992-6656), and read it cover-to-cover four or five times. I am only partly kidding. It took me a long while to understand some of the background to, and consequences of, the legal situation. "Software patents" are mentioned only briefly. The book is about *applying* for a patent, but in order to do that one must first know technical details *about* patents, and that is the worth of the book. I have used the Pressman book for a patent application: I personally performed the search, wrote the patent body, constructed the drawing and the claims, and prosecuted the case before the U.S. PTO (through one major and one minor amendment) to successful issuance, all without other legal advice. (That patent is "Dynamic Substitution Combiner and Extractor," U.S. Pat # 4,979,832, issued Dec. 25, 1990.) This patent project took perhaps 4 (non-consecutive) man-months of work. Although I was able to do it myself, I do *not* recommend this course (except, perhaps, once). I now understand that a non-lawyer is at a serious disadvantage in a patent examination (the examiner generally *is* a lawyer, and s/he is not there to help the applicant). On the other hand, I also do *not* recommend simply handing a disclosure to a patent lawyer and then waiting for the patent to issue. If you want to make sure it is done right, you will need to understand the process, and maintain control over both the process and the attorney. The book should be a standard reference in the personal library of any serious commercial designer. In addition, it would be helpful to have a copy of the article: "Should Program Algorithms be Patented" by Pamela Samuelson, in _Communications_of_the_ACM_, 33(8): 23-27. (Aug., 1990). which seems to me to be somewhat biased against "software patents," but which provides a reasonable background for the current situation. 3. As I understand it, a patent is a way in which society socializes (makes available to society) the inherently private act of invention. In effect, society *buys* private inventions, paying only with a non-renewable 17 year monopoly. This monopoly allows the patent holder to exclude others from making, using, or selling the patented invention. I believe that the monopoly over "selling" the invention does indeed extend to free distribution. In the U.S., a patent holder must pay sizable periodic "Maintenance Fees" to the PTO. If this is not done, the patent could expire in as little as 4 years. An alternative to patents is for society to grant no protection to an inventor at all. But then an inventor would have no economic motive to publish the invention, and might well try to retain it as a trade secret (or not develop it at all). This was part of the problem with medieval trade guilds, and trade secrecy is even now the norm for commercial software. (One would conclude, therefore, that most software producers believe that copyright provides insufficient protection to allow the open release of their software source code.) A patent is *not* some sort of official certification of being the first person to *think* of something, or even the first to reduce it to practice. Someone who wants a patent must move toward full and open disclosure of the way the invention is built or done. If the invention is instead held as a trade secret without publication, that inventor may not be allowed a patent on it at a later date. But a different inventor who does move toward disclosure may be granted a patent on that invention, a patent that could be applied against the earlier inventor. Some people blame the U.S. Patent and Trademark Office (PTO) for allowing "software patents," but I think this blame is somewhat misplaced. There is no law which allows "software patents" or even "hardware patents," there is just overall law which allows patents on various classes (and disallows patents on "algorithms"). In the 1972 case "Gottschalk v. Benson," the U.S. Supreme Court decided *for* the Commissioner of Patents (Gottschalk) who wished to deny Benson a patent on a BCD-to-Binary algorithm. Thus, it was PTO policy to *oppose* at least the most blatant "software patents." Various applicants who were refused patents saw this policy as inconsistent and unfair, and took their cases to court. Eventually, one of the cases, "Diamond v. Diehr" resulted in a 1981 Supreme Court decision that a patent claim could not be rejected merely because it contained a mathematical computation or computer program. The PTO then had to take this decision as precedent, and find new rules to implement that decision. Presumably, some very sharp legal minds contributed to those rules, which are, of course, subject to review in the courts, and presumably have been and are being reviewed now. We have had almost a decade of such review. [ Frankly, I do not believe that it will ever be possible to separate "software" protection or non-protection from the digital logic "hardware" which software must use. This is because, when we talk about the execution of software, that execution always takes place on a physical machine. If patent claims are written in the context of a physical machine, then software that performs those operations must infringe. And if we were to state that a software implementation could not infringe, then, to avoid a hardware patent, all one would have to do is to implement the exact same logic in microcode on a fast processor. In this way, many hardware devices would effectively lose patent protection. [ We often speak of software "replacing" hardware, and if these are different things, such equivalent replacement would seem peculiar. I believe that the functioning of "hardware" and "software" are inevitably linked because they are actually one and the same. ] Frequently one also hears that the PTO grants patents that are "obvious" to the normal practitioner in the field, and that this happens because there are few examiners with software experience. In fact, "unobviousness" is one of the main issues to be argued and examined in the application and responses. We do not have an examiner leaning back and saying, "Gee, that sure looks unobvious to me." Instead, we have legal arguments such as: a. Unexpected Results, b. (Previously) Assumed Unworkability, c. Unappreciated Advantage, d. Contrarian Invention, e. New Principle of Operation, etc., etc. (These abbreviations for arguments are taken from pp. 13/20-13/21 of _Patent_it_Yourself_.) Issues of "unobviousness" can be argued in the context of the art as it existed at the time of the application; they can be examined even by examiners trained in another field. The examiner is not out to "help" the applicant. Instead, examination is an adversarial process in which the applicant must succeed in convincing the examiner that the application meets the requirements for a patent. The applicant thus must "sell" the examiner (who represents Society) into "buying" the patent (for monopoly rights). Thousands of patents are issued each week, approved by fallible people as the result of a complex legal process, so it will always be possible to find examples of bad patents. But individual examples of bad patents do not imply that we should close down the current system, any more than bad examples of criminal justice mean that we must close down the justice system. As an aside, I recently went to the store to buy batteries, and came home with a plastic package that included its own battery tester. The tester consists of dried resistive paste in a narrow triangle pattern with a liquid crystal temperature sensor above it. By positioning a battery properly, current can flow through the resistive material, and the narrow end naturally gets hotter than the broad end. Battery strength then can be (and is) measured by the length of material that reaches the liquid crystal critical temperature. This is a patented device. It adds something to the purchase, and surely costs only a few cents. It is probably a significant advantage in the marketplace. But, once seen, even just externally, the principle of the device is "obvious." Many of us could obtain the materials and make a prototype of the device in a day or two. So the Question is, if the device is economically important, and so clearly "obvious," why was it not invented before? And the answer to that is that an invention that is very obvious *after* a problem has been solved, may not have been nearly so obvious before. Thus, this sort of "obviousness" confusion is not limited to software. 4. "Prior Art" can invalidate a patent, but "prior art" is a technical legal term, and refers to *publicly* *available* information, like publication in print. Information retained as a trade secret is not prior art, and private "design logs" are not prior art. (Mere logs are also questionable as evidence, since people have been known to falsify such records. Really!) "Design logs" may not prove much, unless supported by witnesses who could testify to the content and dates of the logs. Of course, if the logs were contemporaneously signed and dated by reliable witnesses, they could be very compelling indeed. As far as I know, the question of whether an object-code only release of a program can be "prior art" has yet to be directly adjudicated. But "prior art" is normally some sort of open publication, and an object-code only release is the usual signature of trade secret software. So getting object-code to be allowed as "prior art" may be quite a stretch. 5. If a patent holder finds an infringement, s/he will inform the infringer. Often the infringer will do a literature search, and then claim "prior art." One response is a very expensive suit by the patent holder. But in the U.S. it is now possible to request a re-examination of the patent in the light of the purported "prior art." (The fee is high, but probably much less than a single day in court.) Then, if the PTO finds that the "prior art" *is not* applicable, that opinion will weigh "almost conclusively" in favor of the patent holder in any litigation. Since the infringer knows this, the process probably will forestall or abort court action. On the other hand, if the PTO finds that the "prior art" *does* apply, then some or all of the claims will be voided, but, again, the expense of the suit may be avoided. 6. As far as I know, the U.S. does indeed still use the "first to invent" system (as opposed to the "first to file"). The way to claim prior invention is to start an "interference" proceeding, which will then establish a legally proven "date of invention" for each party. This will require signed documents and/or witnesses who can testify to the fact and date of invention. Naturally, the other party could *still* have an earlier date of invention, since only the date of the formal application is given in the patent. An interference proceeding is very technical, very expensive, and very speculative. If you win you get the patent, but then unless you enforce the patent, how will you pay for the interference? 7. I expect that, if no open publication occurred before a U.S. application, prior secret invention in another country probably could not interfere with a U.S. Patent, but this is really beyond my depth. 8. It is not necessary to have some sort of new Public Key system to protect your invention and/or patent rights: a. If you do not want the patent, all you need to do is to *openly publish* how to make the invention. Network publication would probably count, provided it was a open and complete publication, and provided also that you had witnesses who could testify to the publication, including its content and date. In addition, you probably should place the release in a repository where many people would have access to it. b. If you do want the patent, the invention should be confidentially disclosed to witnesses who can understand it, and who could testify as to its content and the date. The disclosure might be in the form of a document to be signed and dated on each page by both inventor and witness. Again, if you want to give your invention to society, this is *easy*. Simply publish your source code, with a text description of how to make the invention. Of course, you cannot give away something already owned or claimed by someone else, and it may take a while to find out whether or not this is the case. 9. So, the logic of this is that it is in the interest of Society that inventions be made known as soon as possible. Society could not have known that Mr. Williams had invented LZRW because he did not openly say so, much less that he was going to give it away some day. In the absence of prior publication, Gibson and Graybill formally describe their independent invention, and apply to sell it to Society. In the absence of prior publication or a prior application, their application eventually was accepted. I am truly sorry that the LZRW incident may be one or more personal tragedies, but this is exactly the way the system is supposed to work. If you are only intellectually concerned, then patents should not bother you. Even a patented invention may be investigated and described without infringing the patent. You can have your students implement patented inventions and do research on them. Individuals who make their own things for their own use (and keep their mouth shut about it) are almost never subject to patents. Patents are *economic* rights. They affect distribution in the large. If you are involved in the creative development of this sort of software, and are worried about patents, then you *must* keep adequate legal records, and seek to protect or publish your work openly at the earliest possible moment. There are no guarantees, but in the LZRW case the situation could have been different. On the other hand, if you, or the company you work for, decide to avoid open publication, then you inherently bear the risk that someone else will invent the same thing, patent it, and apply their patent to you. Programmers should be aware of patents, but morbid anxiety and despair are unwarranted. If you infringe someone else's patent unintentionally, you will be informed, and then can try to design around the patent or perhaps license it. Note that patents are normally applied to the manufacturer or distributor, and not the individual programmer (unless they are one and the same). Respect for patents has been required in hardware design for many years, and generally results in little more than irritation; relatively few patent issues are actually contended. As far as I know, in comparison to the economic forces of market condition or competition, few companies are forced out of business by patents. On the other hand, some companies grow to competitive size on the strength of their patents. In my experience, technical people who are inexperienced with patents tend to see them as unwarranted intrusions and disasters, although more experienced designers do not. Business people, who contend with various legal requirements on a daily basis, often see patents as just one more fact of life which they can use to their advantage. But this advantage is also available to the independent programmer or small software firm. In fact, a significant patent may be one of the few things that can allow a tiny software company to face down the huge programming, production, and marketing resources of big-time software. The normal situation today is that software inventions are held secret, in trade secret source code, and that lesser experts than the inventor are not informed about how to make the invention. This is not what we want. I claim that "software patents" are an improvement to the pervasive trade-secrecy of the software industry. If the industry had practiced a full and open disclosure of new technology, much of this would now be "prior art," and "software patents" would be less of an issue. We can expect some conflict as the correction proceeds. I view the whole "software patent" turmoil as the surprisingly effective "response" by one of the conservative institutions in our society to the secrecy abuses of the software industry. --- Terry Ritter cs.utexas.edu!cactus.org!ritter (512) 892-0494 ==================================================================== Peter Treloar - comp.patents Moderator patents@cs.su.oz.au --