New Concepts In Obtaining And Enforcing Software Patents

NEW CONCEPTS IN OBTAINING AND ENFORCING SOFTWARE PATENTS

by Gregory J. Maier *

Background
In view of the rapid increase in the commercial importance of software, the current surge in the filing of applications for software-related inventions should be no surprise. What is surprising to me, after three decades of practice in the field of patent law, is the rapid evolution that the U. S. law in this area has undergone. Fortunately, recent developments in the law eliminate much of the confusion that has existed in the area of software patent protection. New theories of patentability and claiming have emerged from recent decisions of the Court of Appeals for the Federal Circuit (CAFC) that are much more practical and understandable than the concepts previously relied upon. Furthermore, the U. S. PTO has been unusually quick in adopting these new theories in its recently approved Examination Guidelines for Computer-Related Inventions. These new PTO guidelines will strongly impact the manner in which software-related inventions¹ are written, claimed, and examined.

A large body of law exists on the subject of software protection by patent. While I encourage study of all the recent cases, in this paper I plan to treat only a few key issues that all practitioners should understand. Similarly, the new PTO guidelines are both complex and detailed because they significantly change the manner in which computer-related inventions are to be examined. Again, while I encourage a detailed understanding of these guidelines, I will focus on a few key points that I believe are of most interest to practitioners in this field.

A New Look At Patentability
In July of 1994, the CAFC issued its landmark decision in In re Alappat². Although a number of other significant decisions pertaining to software inventions were issued during the last few years, this en banc decision was pivotal in causing the U.S. PTO to entirely revise the manner in which it examines applications for computer software.

The Alappat decision resulted from a flare-up in that thirty-year dispute between the U.S. PTO and the courts over software patentability. The PTO Board of Appeals initially found the Alappat invention patentable, but was then forced by the U.S. Commissioner³ to rehear the case, and ultimately reverse itself . The Federal Circuit, in hearing the case, reviewed all relevant law on the subject including Supreme Court decisions. The Court concluded that the approach to examining software inventions that the U. S. PTO had developed based on earlier Court rulings should be discarded.

The former approach was based on claim analysis, and in particular on determining whether the claims recited and fully preempted a mathematical algorithm⁴. This approach was difficult to apply in practice because the term "mathematical algorithm" lacks precise definition. The new approach offered by the Court in Alappat focuses on the invention as a whole, and seeks to distinguish useful inventions from disembodied mathematical concepts, laws of nature or abstract ideas. In a word, the new approach focuses on utility.

The impact of this new approach to analyzing patentability involves a major shift in emphasis from studying the claims, to studying the entire specification and understanding what the applicant has really invented. In terms of patent practice, this approach, now adopted by the U.S. PTO in its new Examination Guidelines, has shifted emphasis to the content of the specification for determining the practical aspects of the invention, and in particular, determining the utility of the disclosed invention. The claims are important as always, but the specification now carries much more importance in determining the basic question of patentability under 35 U.S.C. §101. Significantly, this approach amounts to treating software inventions according to the same basic principles and legal standards as all other types of inventions, rather than as a unique category of invention. While to some this may seem trivial or obvious, to me it is a major breakthrough that should put an end to decades of uncertainty in this area of law.

Patenting Software As An Independent Product
As important as it was to determining the patentability of software inventions, the Alappat decision did not directly resolve the long-standing question as to whether software products could be claimed independently of a general purpose computer. For decades the U. S. PTO has successfully fought the patentability of software as an independent product. For this reason, software encoded on a floppy disc could not be patented, even though such software has long been recognized as an important and very useful article of commerce. There were, of course, many practical reasons why the U.S. PTO resisted the patenting of such software products. Among these were the lack of skilled software examiners and, more important, the perceived lack of an adequate body of prior art by which to judge standards of software patentability. Of course, a tacit concern of the PTO management was that the explosive growth in software products would drown the PTO in new applications if they were permitted to be patented. For all of these reasons, the U.S. PTO policy was to deny patentability to software products separate from computers.

The legal theory adopted by the U. S. PTO to enforce this policy involved case law pertaining to "printed matter". The idea was that, just as printed words could be ignored by the PTO in assessing the patentability of mechanical inventions, so too could the PTO ignore computer-readable information recorded on media when examining software-related inventions. Although this rationale may have been appropriate when considering conventional printed matter, extending the same rationale to computer-readable media was certainly a questionable step, and had been severely criticized by elements of the software industry.

The Federal Circuit's In re Lowry⁵ decision was a milestone. It held that a particular data structure, as it exists in a computer memory, is entitled to patentable weight since storage of the data imparts physical change to the memory. The Lowry decision formed the basis for a direct attack on the PTO's "printed matter" theory in In re Beauregard⁶. The Beauregard case was dismissed when the PTO conceded that its "printed matter" rejection should not apply to software recorded on a computer readable medium, thus ending its policy against issuing patents to be recorded on computer readable media.

The direct result of the demise of the "printed matter" rejection to software inventions is that a new style of claim, called the computer program product claim, is now appropriate for use in U.S. patent applications. The computer program product claim is simply a claim to software recorded on a computer-readable medium. The claim derives its statutory patentability because it is directed to an article of manufacture, since the computer-readable medium is typically a floppy disk, optical disk, or other type of manufactured item. The computer-readable medium is rendered unobvious from other media by the software encoded on it. The software must be functional software in the sense that it reconfigures a computer to carry out a task. Non-functional software, such as recorded music, recorded video or other digital data which does not reconfigure the computer is not given patentable weight. However, any useful and functional software is clearly patentable in this new format.

The practical impact of Alappat and Beauregard is a stunning reversal of the U.S. PTO's former policy limiting patent protection for software inventions. The entire process of analyzing software applications for patentable subject matter has been changed, as mentioned above. The new standard is more basic and more clearly understandable than the old, and is founded in the most basic principles of U.S. patent law. Essentially, to be patentable software inventions must be useful, unobvious and fall within one of the four basic categories of patentable subject matter established by Congress, namely process, machine, article of manufacture, or composition of matter⁷. On the other hand, abstract ideas, laws of nature, or natural phenomenon remain unpatentable. This straightforward analysis eliminates the need to identify and define "mathematical algorithms", the heart of the earlier method of analysis.

To writers of software applications, the impact of the new standard of software patentability is profound. On the one hand, it opens up for patentability virtually every type of useful software. On the other hand, it focuses new attention on proper disclosure of utility in each application.

Software is essentially the coding of a sequence of algorithms, often mathematical algorithms, for ultimate use in a computer. Unlike most mechanical inventions, software inventions are often highly mathematical and therefore abstract. This abstract quality means that the utility of software inventions is often far more obscure than that of mechanical inventions, for example. Consequently, more attention must be devoted to describing the utility of software inventions than most other types of inventions.

In the most practical sense, this means that one must include in each patent application a discussion of what real-world utility the software achieves. This can be done, for example, by determining why a user would purchase the software being claimed. The motivation to purchase is generally the end use, or practical purpose, of the software. By clearly describing what this is, the utility of the underlying software is explained. The exciting implication of the new standard of patentability is that virtually any useful software is now patentable, provided it is recorded on a computer-readable medium.

Obtaining Patents Under The New Guidelines
The new PTO guidelines overflow with details, many dealing with relatively rare circumstances. Unfortunately the excessive detail may obscure the fundamental points that should be understood by all practitioners. While I encourage careful study of the guidelines, I would like to focus on a few of the basic principles that will be important in all software applications.

It is essential to understand that a good specification is the most important element in obtaining a patent. Certainly the claims are important ultimately, but without a well-written specification that includes a full disclosure of the invention, no claims will be allowed.

The fundamental problem confronted by patent attorneys in most software applications is that the software disclosure presented by the inventor is often highly abstract. Normally the patent attorney's challenge is to tell the story of that software, beginning with its real-world physical application. Convincing the patent examiner, and later judge and jury, that the software has practical utility is one of the most important aspects of the specification, and should be a primary focus for the attorney preparing a software application. One way to accomplish this is to ask the inventor what the ultimate, "real-world" use of the software will be. Once this is understood, the real-world problem to be solved and at least one specific use of the software should be described in the application. The details of the software can then be explained in the conventional manner.

The disclosure must be adequate to enable a skilled artisan to write the actual software code and appropriately configure a computer to operate without unreasonable experimentation. Very often software applications involve more than one field of technology, for example, programming technology and also an end use, such as engine control, medical x-ray analysis or image enhancement. The disclosure is then aimed at persons skilled respectively in these various arts. Accordingly it is unnecessary to disclose specific code or specific algorithms if they would be apparent from the disclosure to a programmer of ordinary skill. On the other hand, if the algorithms are themselves unique, then they must be specifically disclosed. Similarly, the application of the software to a specific technology need be disclosed only at the level of understanding required by one skilled in the application of that technology.

In my view, a good and complete set of drawings is important to a well-written application. Although the addition of many sheets of drawings adds cost to an application, it also adds a great deal of clarity and a certain amount of useful redundancy to the disclosure. It is preferable for every software application to include at least one hardware diagram illustrating the relationship between the software and the specific practical technology it relates to. Although this is technically unnecessary, I find it to be a very good "safety" measure to make sure that the abstract software disclosure is connected to a description of its practical application. It is also helpful if drawings illustrate the real-world utility of the software invention in a readily understandable way, such as by illustrating the result accomplished by the software invention. Furthermore, flow charts should be included to illustrate the logical process of conventional software, or relational diagrams should be provided to illustrate the operation of object-oriented software. To complement the drawings, a detailed description of the operation of the software should also be included. If data structures are important or timing diagrams, they certainly should also be included.

Thus a well-written application includes adequate drawings showing schematically the manner in which the software operates. These illustrations, together with a well-written disclosure that includes a clear description of the practical results achieved by the software, as well as the manner in which the software can be implemented, will result in the issuance of a patent, assuming that the invention is not obvious.

Enforcement of Software Patents
Software patents are generally enforced by the courts in the same manner as all other patents. As more of them reach the courts, there will be more specific opinions dealing with their enforcement and some new law may develop. However, the essence of enforceability is obtaining valid claims. Accordingly, attention to claim style, structure and strategy is important in software cases. Software inventions can usually be claimed by more techniques than other types of inventions. In view of the fact that different law⁸ applies to different claiming styles, it is advisable to include many different types of claims so that as many legal arguments as possible can be used to support claims with respect to potential infringement. Furthermore, the use of different claiming styles will make the potential infringer's task much more difficult in trying to establish that the claims are invalid or unenforceable with respect to his potentially infringing product. Although adding additional claims of different styles and types adds to the cost of an application, carefully crafting a wide range of claims is well worth the expense in protecting important technologies.

If cost is no object, it is desirable to have a selection of claims written in means-plus function language and a parallel set written in plain language. Widely different legal theories apply to these two claiming structures and each will be beneficial under different circumstances. Plain language claims may be broader in scope while the validity of "means" claims may be easier to establish. Similarly, software can often be claimed in three different environments: (1) as a system including programmed computer, (2) as a process for operating a computer, and (3) as an article of manufacture recorded on a computer-readable medium. All three of these techniques should be used if possible and appropriate. By using these different techniques, the claims may apply to a potentially different range of infringing devices and activities, and thus may have widely different values in litigation or licensing. For example, computer system claims would cover a user of the software, while the computer program product claims would also cover the manufacturer and distributor of software.

Another important consideration in obtaining strong and enforceable patents is to ensure that the best available prior art is before the examiner. In the software area, carrying out good searches in software prior art was a problem in the past. Now a number of reliable data bases exist which focus exclusively on prior software disclosures. These are now accessed by PTO examiners so that much better quality searches are obtained. However, the inventor is often aware of the best and most relevant prior art. There is no substitute for obtaining full prior art disclosures from the inventors as to background material that he knows to be relevant. Furthermore, if patents are brought forward for licensing or possible enforcement through litigation, new prior art will very often come to the surface. In that instance it is often useful to request reexamination of the original-issued claims in light of the newly discovered prior art.

Because of the very significant changes in law and practice described here, and because of the inherently complex nature of many software inventions, the personal interview is often crucial to a complete examination within the PTO. Furthermore, it is important to note that the new PTO Guidelines are neither law nor rules, but rather a suggested approach to examination. Consequently, failure to follow the Guidelines is neither petitionable nor appealable. However, the stated policy of the new Guidelines can be brought to the attention of a patent examiner very effectively during a personal interview.

Conclusion

Recent changes in U. S. law and practice have significantly simplified the law of protecting software-related inventions. The new Examination Guidelines adopted by the U. S. PTO are intended to incorporate the new legal principles into Patent Office practice.

*.©Oblon, Spivak, McClelland, Maier & Neustadt, P.C., 1996.

---

Endnotes

---

[1].In this paper I will occasionally use the term "software inventions" or software related inventions synonymously with "computer-related inventions". Although there is technically a difference in these terms, I believe that many practitioners commonly refer to the issues addressed here as questions of protecting software by patent. This is the issue that is the focus of my comments.

[2].31 USPQ2d 1545 (Fed. Cir. 1994).

[3].The Commissioner was Mr. Harry Manbeck. He added four members, including himself, to the Board panel hearing the Alappat appeal to ensure a vote against patentability on rehearing.

[4].This approach is known as the Freeman-Walter-Abele test, named after decisions of the CCPA, predecessor to the CAFC.

[5].32 USPQ2d 1031 (Fed. Cir. 1994).

[6].35 USPQ2d 1383 (Fed. Cir. 1995). This case is not cited in the new PTO Examination Guidelines because the case was withdrawn by the PTO in view of the Lowry opinion before the CAFC had an opportunity to render a full opinion on the issues. The Lowry opinion is evidently considered by the PTO to be the controlling law on this issue.

[7].35 USC 101.

[8].Particularly 35 USC 112, ¶6, which authorizes means-plus-function claims and has been interpreted in In re Donaldson, 29 USPQ2d 1845 (Fed. Cir. 1994).