I. Introduction

Software patentability is a controversial and significant issue with effects on software innovation, competition, and the environment in which computer programmers and designers work. For more than twenty years, the U.S. Patent and Trademark Office (USPTO), the courts, and the software industry have been wrestling with the issue of software patents.¹

Traditionally, software developers paid little attention to patent protection for their software. Prior to 1981, the USPTO had routinely resisted issuing such patents.² As a result, the general public viewed software as not patentable. In addition, trade secret and copyright protection rather than patents served as the generally recognized "tried and true" methods of protecting software rights.³ Com-Share, Inc. v. Computer Complex, Inc., 338 F. Supp. 1229 (E.D. Mich. 1971); aff'd 458 F.2d 1341 (6th Cir. 1972); Computer Software Copyright Act of 1980, amending 17 U.S.C. §§ 101, 117; Apple Computer, Inc. v. Franklin Computer Corp., 714 F.2d 1240 (3rd Cir. 1983); (computer programs protectable under the copyright laws whether in source or object form).

Software inventors were thus usually reluctant to invest thousands of dollars in a patent application that might not even hold up against a challenge in court. Consequently, the software industry grew for many years on the basis of a significant amount of non-patented technology.⁴

However, in the past twenty years, software patenting became increasingly prominent, spurring debates by academicians, the patent bar, the USPTO, computer scientists, and corporations in the software industry.

II. The Legal Foundation and History of Software Patents

Patent law originated from statute and falls within the province of Congress. Patentable subject matter in the U.S. includes "any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof." 35 U.S.C. § 101. 'Process'' is defined as a process, art or method, and includes any new use of a known process, machine, manufacture, composition of matter, or material. 35 U.S.C. § 100(b).

Courts have interpreted the Patent Act to exclude "an abstract idea, principle or force, law of nature or natural phenomenon." In re Alappat, 33 F.3rd 1526, 1552 (Fed. Cir. 1994). From 1972 to 1981, two Supreme Court decisions shaped the landscape of software patent law.⁵ In 1972, the Court rejected a patent on a formula for converting binary coded decimal signals to binary form, holding that a process must transform and reduce material to a different state or thing to be patentable. See Gottschalk v. Benson 409 U.S. 63 (1972). The Court stated that computer programs standing alone were not patentable without authorization from Congress. See id.

Then came Diehr, the landmark case for validating software patents. See Diamond v. Diehr, 450 U.S. 175 (1981). The Court there allowed a claim for a method of curing rubber that used a computer for monitoring purposes, holding that although by itself a mathematical formula is not patentable, a claim containing this formula constitutes patentable subject matter when it is implemented in a structure or process that performs a function covered by patent law. See id. From Diehr, the use of a mathematical formula and a programmed digital computer became patentable when construed as part of a process.⁶

III. The Scope of Software Patents

For the past two decades, patents have been granted to protect a range of software from compilers to applications and to provide protection for the underlying process or method performed by a computer program.⁷ See Atari Games Corp. v. Nintendo of America Inc., 975 F.2d 832, 839 (Fed. Cir.1992). A software-related patent is one that claims all or nearly all of its invention some feature, function or process embodied in a computer program executed on a computer.⁸ Patented software includes system software and various types of application software, including business software, user-interactive software, and expert system software.⁹ In general, it is the functional aspects of software that have been patented, such as processes, editing and control functions, and compiling and operating system techniques.¹⁰ Under the category of design patents, icons and electronic font types are also being patented.¹¹

IV. Patents vs. Other Software Protections

Not until the last twenty years did patents begin to play an increasingly significant role in software intellectual property. Developers have long relied on trade secrecy and copyrights to protect their rights. Trade secrecy, by definition, does not prohibit any development work by one who is not aware of the material claimed as trade secret.¹² A computer science engineer who created a program independently of another company who owns the same program as a trade secret owes nothing to that company. Patents, on the other hand, exclude everyone from using the claimed invention, regardless of their knowledge or lack thereof. If the company had patented the program instead of keeping it as a trade secret, the engineer would now be infringing upon the company's patent.

Copyright covers the implementation details of a particular program.¹³ The scope of copyright extends only to the details of expression of a work, not the ideas.¹⁴ Copyright does not cover the features of the program, or the general methods used.¹⁵ Patents, on the other hand, do not cover specific systems or individual programs. Instead, they cover particular techniques that can be used to build systems, or features that systems can offer.¹⁶ Once the technique or feature is patented, other programmers cannot use it in a system without authorization from the patent-holder, even if the programmer implements the technique in a different way.¹⁷ Furthermore, independent creation, a legitimate defense to copyright infringement, gives a programmer no protection against a patent infringement claim.¹⁸

Patents, therefore, are a different and more threatening creature to software developers than their peers in the intellectual property arena. Since computer programs usually utilize many techniques and offer several features, a program can easily infringe numerous patents at once.

V. Common Arguments against Software Patents

Richard Stallman, in his speech at the Cambridge University Computer Lab on the issue of software patents, highlighted some common complaints against software patents.¹⁹

A. The Onerousness of the Patentability Search

One of the greatest obstacles software patenting poses to the industry is the lack of available public information as to which algorithms or techniques have already been patented and are thus off-limits to programmers. A software developer must first determine, via a patentability search, which patents the program violates before releasing the product. Such a search, if done by a hired attorney, is extremely time-consuming and expensive, thus placing it out of the reach of independent software writers. Those who venture to undertake the patentability search encounter an impossibly long list of related matches, compounded because patent language is highly specialized and extremely difficult for an engineer to understand.²⁰

B. The Unreliability of Patentability Searches

In addition to the difficulty of searching for prior patents, since pending patent applications remain confidential for up to eighteen months when they are published, a software developer will not find these applications in a patentability search. See 35 U.S.C. §122; 37 C.F.R 1.14(a). A software engineer may write and release a program within this time frame only to find out later that it infringes on a prior claimed invention. The result is that computer scientists will constantly have to look over their shoulders while they develop their programs for fear of infringing on any possible patents, and yet still be exposed to the risk of a lawsuit when a pending unknown patent application covering the same technique is issued.

C. Reinforced Monopolies

The procurement of a patent is extremely costly. These costs include legal fees paid to attorneys (unless the inventor develops the necessary expertise to file the application himself or herself) and the actual fees required by the USPTO to obtain a patent. Legal fees for filing a patent application vary greatly depending on the complexity of the technology, the quality of the write-up and drawings that the inventor can provide, the patent attorney's rate, and the number of changes that the inventor makes along the way. For moderately complex patent applications in the electronics, computer software, and biotechnology industries, fees ranging from $5,000 to $15,000 are not uncommon.²¹

In addition to the legal fees, all applicants must pay to the USPTO a filing fee from $750 to about $1,300.²² If the patent is approved, the applicant must also pay an issue fee of about $1,250.²³ After issuance, the patent owner must continue to pay maintenance fees at 3.5 years, 7.5 years, and 11.5 years. Failure to pay a maintenance fee would result in termination of the patent rights.²⁴

The cost of obtaining one single patent therefore ranges in the mid- to high-thousands at minimum.²⁵ And even though small business entities (those with less than 500 employees total) receive a fifty percent discount with the USPTO, the costs are often still too great for independent developers.²⁶ Fees spent on legal advice and patent counseling divest significant resources from software development itself. Small companies and individual programmers who can't afford patent searches and litigation are kept out of the game, while big players thrive with more power of exclusion from their patents. With more revenue to pay for exclusive licensing and cross-licensing with other companies, large corporations will eventually transform the market into a monopoly, wiping out young, independent programmers who until now have been the software industry's source of inspiration.

VI. Why Software is Different

The problems advanced above mainly concern the drawbacks of patents in general. To understand why software patents in particular are unsuitable to the programming industry, one must first take a look at the distinguishing characteristics of software development.

A. Computer Programs are Vastly Complex

Software systems have a much larger number of parts than physical systems. Computer programs today are so complex that they contain literally thousands of algorithms and techniques, each considered patentable by the standards of the USPTO.²⁷ To expect a software company to license each of these patens is simply unreasonable. Furthermore, patents granted on combinations of algorithms and techniques that produce a particular feature make the possibility of creating a non-infringing program even more remote.

Compare the pharmaceutical industry, where a patented chemical formula results in one patent per product. The person who developed the product holds the patent. A single software patent, on the other hand, can cover many ideas.²⁸ Because software packages are very big, they combine many ideas, a pair of which might be patented as a combination. Hence there may be thousands of points of vulnerability in an engineer's program, each subject to infringement claims.²⁹

B. Software Development Deals with Idealized Mathematical Objects

It is fundamentally easier to write a program than to design a physical object because software development is free from the perversity of matter.³⁰ A hardware system must be designed using real components. Physical systems have varying costs, limits of operation, or sensitivity to temperature.³¹ They drain power, and they may fail. Mathematical modeling may be proven wrong when the design is constructed.³²

By contrast, computer programs, though immensely complex, are far easier to design. They are built out of ideal mathematical objects whose behavior is defined, not modeled approximately, by abstract rules.³³ When a condition checked by an "if" statement is true, the statement that the programmer intends to be executed never fails to be executed.³⁴

C. Very Low Investment is Involved in Software Development.

Because computer programs are much easier to design than a counterpart of equal complexity, development costs are much lower as well. Richard Stallman discussed in his speech the relative ease of software programming. A program of 100,000 components might be 50,000 lines long and be completed by two programmers in one year. The equipment costs would be less than $10,000. The other costs would be the living expenses of the programmers during the year. Total investment would not exceed $100,000. If done commercially by a larger company, the cost may be double that. On the other hand, an automobile usually consists of 100,000 components, but requires a large team and tens of millions of dollars to design.³⁵

Furthermore, since software programs are not confined to physical form, there is a tremendous simplification and reduction in production and distribution costs.³⁶ Instead of building a factory for the automobile, a software programmer can simply type "copy" or burn the information onto a CD to be duplicated. The result of the low development costs is that the administrative costs of dealing with the patent system - procuring a patent, legal advice, possible litigation - are so much greater that they become a crushing burden to many software companies.³⁷

VII. Problems with Software Patents

Despite the distinguishing characteristics of software development, some may still argue that many other industries involve highly complex inventions, such as airplane manufacture and oil refineries.³⁸ Similarly, several other industries have cottage manufacturers and yet still deal with the patent system. However, many problems exist in the patent system that are unique to software development.

A. Inadequate Examination

One of the biggest complaints of software patenting is the issuance of patents without adequate examination by the USPTO. The lack of computer scientists sitting as Examiners in the PTO often results in patents erroneously issued on obvious software inventions. In addition, imprecise claim drafting by attorneys and granting by inexperienced Examiners make infringement difficult to determine.³⁹

Furthermore, the PTO lacks a workable scheme for classifying software patents. The search classification system was designed for hardware patents only.⁴⁰ Patents are frequently classified by end results, such as "converting iron to steel."⁴¹ However, many patents cover algorithms whose use in a program is entirely separate from the purpose of the program. For instance, a program to analyze human speech may infringe a patent on a speedup in the Fast Fourier Transform, as would a program to perform symbolic algebra in multiplying large numbers.⁴² How one is to find the appropriate category to search for such a patent is very hard to predict.

B. Difficulty with Prior Art Search.

Patent Examiners are often ill prepared to evaluate whether techniques claimed in software patent applications are to be rejected for being either widely known or obvious. Many commonly used software techniques are not found in scientific literature. Some are deemed too obvious to publish; some considered insufficiently general; others were open secrets to the trade.⁴³

The vast extent of the computer science literature further complicates the search for prior art. This literature contains not only academic journals, but also user's manuals, published source code, and popular accounts in magazines.⁴⁴ Compared to a group of chemists working at a major university who might produce twenty to thirty pages of published material a year, a single programmer can easily produce a hundred times more.⁴⁵ The patenting of combinations of algorithms and techniques makes the situation even more complex. Developers often publish new algorithms and techniques, but they almost never publish new ways of combining the old ones.⁴⁶

When an Examiner cannot find prior art due to the impossibility of thoroughly searching the literature for references, or doesn't reject the application on other grounds, the Examiner must issue the patent. The result is numerous software patents that were not original but were granted nonetheless.

C. Lax Obviousness Standard

A patent application will be rejected if it is considered obvious - that is, a person of ordinary skill in the art would find it obvious to modify what is taught by one reference in light of what is taught by another reference. See 35 U.S.C. § 103. The Patent Office interprets obviousness much differently from computer programmers. Examiners are accustomed to considering small, incremental changes as meriting a patent grant.⁴⁷ For instance, the much publicized Polaroid v. Kodak case hinged on the differences in the number and order of layers of chemicals in a film, which the court ruled as an unobvious variation to the previous patents. See Polaroid Corp. v. Eastman Kodak Co., 867 F.2d 1415 (Fed. Cir. 1989). The case is different with software development. Computer scientists solve problems quickly because the medium of programming is tractable. Developers learn to generalize solution principles from one problem to another. For example, one such generalization is that a procedure can be repeated or subdivided.⁴⁸ This concept, considered obvious to programmers, was found novel by the Patent Office when it granted a patent on scrolling multiple strings.⁴⁹ The low threshold of the USPTO's obviousness test results in numerous unoriginal patents being granted and thereby precluding other programmers from using them.

D. Business Methods becoming Patentable

Because of the characteristics of of software development, the potential for abuse of the patent system is greater with software than with other types of technology. Under statute, business practices are not patentable. 35 U.S.C. § 101. However, patent holders have successfully obtained patents on business practices by executing them in software programs, which are patentable.

The Diehr decision, establishing that claims must be considered as a whole to determine their patentability, paved the way for the infamous State Street case. The addition of computer software now permits an otherwise unpatentable business practice claim to be patented. See State Street Bank & Trust Co. v. Signature Financial Group Inc., 149 F. 3d 1368 (Fed. Cir. 1998). The Court granted a patent on formulas applied to various data from a portfolio of mutual funds, essentially making business methods patentable as long as they are implemented in computer programs. See id.

The recent "one-click shopping" patent by Amazon.Com exemplifies the effect of the expansion of software patents into web business methods.⁵⁰ Essentially the equivalent to calling a mail order company with an order number, the "one click shopping" patent is an illustration of a negligible invention leading to an enormous distortion of the market.⁵¹ The possible result is that various non-web business methods for ordering merchandise will be patented so that competitors may not receive orders effectively.

As of April 2000, the Patent Office received over 2,500 applications per year of these "business method software" patents.⁵² Since patents can be used defensively, every web site owner now needs to inquire whether aspects of his web site is patentable or violates another site's patents.

E. Conflicts with Copyright Law

Lotus, Microsoft, WordPerfect, and Novell all reached their status as world leaders in the software publishing industry on the strength of their products without relying on patents to secure funding or to maintain their market position.⁵³ For those who wish to protect their intellectual property, the industry has long relied on the copyright and trade secret systems. Patenting software results in a conflict with existing copyright laws.

Almost all programs today are copyrighted. Copyright prevents users from making copies of a program without authorization. Copyright prevents one from appropriating another's work and selling it as one's own. It does not, however, prevent other programmers from using algorithms or techniques in their own work.⁵⁴ A single technique can be used in different ways to perform different functions, and the programmer still will not be infringing on another's copyright.⁵⁵ By allowing patent protection on the same subject matter, the extended scope of coverage essentially undermines the scheme of copyright protection because companies will eventually choose to patent their algorithms.

Treating machine-readable memory containing a program as a patentable article of manufacture greatly expands the range of activities that may infringe a patent, thereby creating direct conflicts with the Copyright Act.⁵⁶ Under patent law, the mere "booting up" of a program or creation of an archival copy, both permitted under Copyright Act § 117, may constitute "making" and hence patent infringement.⁵⁷ Likewise, a fair use copy made via reverse engineering, legitimate under Section 107 of the Copyright Act, might also amount to infringement of an article of manufacture.⁵⁸ The conflict between patent and copyright laws exists only in the realm of software patent and nowhere else.

F. Restriction on Interoperability

Patents in the software industry also have the potential to restrict interoperability. A patent holder may inhibit interoperability with program elements not covered by the patent.⁵⁹ A computer programmer who encounters a patented algorithm will try to avoid patent infringement by writing or finding another algorithm that is not patented. However, if the patented algorithm is used in a common format that does not support the new unpatented algorithm, users will not be able to use the unpatented version, and this algorithm essentially goes to waste.

Richard Stallman discussed his experience with the patented LZW compression algorithm, which was also used in image formats such as the GIF format. In order to avoid infringement of the LZW patent, Stallman's group used another un-patented algorithm. However, when users of GIF were threatened with patent infringement claims for using GIF files, they could not switch to the unpatented version. The browsers did not support the new format that was patent-free.⁶⁰ The result of this patented algorithm therefore is a restriction on software interoperability.

VIII. Conclusion

From tedious and unreliable patentability searches to the financial strain on small companies, the patent system has several shortcomings. Computer software, being a complex system of ideas and combinations of ideas, is particularly sensitive to the problems with patents. The U.S. Patent and Trademark Office's lack of understanding towards the software industry contributes significantly to the unsatisfactory quality of software patents being issued. Also specific to software patenting is the potential for abuse, where companies can circumvent the statutory bar to patenting business practices by implementing them into computer programs. Software patents not only undermine the scheme of copyright law, but they also restrict interoperability.

IX. Possible Solutions

For the foregoing reasons, the USPTO needs to reform its software patent system. More federal funding should be allocated to the Patent Office, and the costs for procuring patents should be lowered. The Patent Office should also increase its efforts to recruit more computer scientists, as Examiners and implement a more thorough and effective patentability search database for software programs. The Software Patent Institute works to help programmers identify patented materials and prior art. As to the conflict with copyright laws, the legislature should consider clarification and expansion of doctrines such as patent misuse, experimental use, and exhaustion.⁶¹

Finally, one can prevent others from patenting software technology, without the expense of obtaining a patent, by publishing the software technology.⁶² The Software Patent Institute, a nonprofit corporation formed to provide courses and prior art about software technology, publishes submitted information in a database accessible to USPTO and the general public.⁶³ This publication will serve as a "defensive disclosure" and increase the chances that the Patent Office will find and consider this information before granting a patent that might later prove invalid because it was not really new. With the combined efforts of the Patent Office, the computer programming community, and concerned citizens, the problems of software patenting can be solved.

Endnotes

¹ Comments of the American Committee For Interoperable Systems On The Proposed Examination Guidelines For Computer-implemented Inventions. American Committee for Interoperable Systems, Statement of August 18, 1995.
² David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute, 1994. http://www.spi.org/primsrpa.htm
³ American Committee for Interoperable Systems, Statement of August 18, 1995.
⁴ Id.
⁵ John Hoagland, Web Patents: Owning a Piece of the Internet. Web Technology and Counseling Center. http://www.components-online.com/Software/Patents/default.htm
⁶ Id.
⁷ Id.
⁸ David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute. 1994. http://www.spi.org/primsrpa.htm
⁹ Id.
¹⁰ Syrowik & Cole, The Challenge of Software-Related Patents. 1994.
¹¹ Id.
¹² Against Software Patents. The League of Programming Freedom. Feb 28, 1991. http://lpf.ai.mit.edu/
¹³ Id.
¹⁴ Richard Stallman, Software Patents - Obstacles to Software Development. Transcript, University of Cambridge Computer Laboratory, UK. Mar 25, 2002.
¹⁵ Against Software Patents. The League of Programming Freedom. Feb 28, 1991
¹⁶ Id.
¹⁷ Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
¹⁸ Jonathan Rosenoer, Software Patents. Cyberlaw on the World Wide Web. 1994. http://www.cyberlaw.com/cylw894.html
¹⁹ See Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
²⁰ See id.
²¹ D.C. Toedt III, Patent Law Frequently Asked Questions. Lawnotes: Intellectual-Property Law Facts and FAQs. http://www.lawnotes.com/patent/faq_pat.html
²² Id.
²³ Id.
²⁴ Id.
²⁵ Id.
²⁶ Id.
²⁷ Simson L. Garfinkel, Richard M. Stallman & Mitchell Kapor. Why Patents are Bad for Software. Issues in Science and Technology. 1991.
²⁸ Richard Stallman, Software Patents - Obstacles to Software Development. 2002.
²⁹ Id.
³⁰ Id.
³¹ Id.
³² Id.
³³ Id.
³⁴ Id.
³⁵ Id.
³⁶ Id.
³⁷ Id.
³⁸ Debunking Software Myths. Communications to the ACM, June, 1992. http://www.swiss.ai.mit.edu/6805/articles/int-prop/heckel-debunking.html
³⁹ See id.
⁴⁰ See id.
⁴¹ Against Software Patents. The League of Programming Freedom. Feb 28, 1991
⁴² Id.
⁴³ Id.
⁴⁴ Garfinkel, Stallman & Kapor. Why Patents are Bad for Software. 1991.
⁴⁵ Id.
⁴⁶ Against Software Patents. The League of Programming Freedom. Feb 28, 1991
⁴⁷ Id.
⁴⁸ Id.
⁴⁹ Id.
⁵⁰ John Hoagland, Web Patents: Owning a Piece of the Internet. Web Technology and Counseling Center. http://www.components-online.com/Software/Patents/default.htm
⁵¹ Id.
⁵² Seth Shulman, Software Patents Tangle the Web. April 2000. http://www.technologyreview.com/articles/shulman0300.asp
⁵³ Garfinkel, Stallman & Kapor. Why Patents are Bad for Software. 1991.
⁵⁴ Id.
⁵⁵ Id.
⁵⁶ Comments of the American Committee For Interoperable Systems On The Proposed Examination Guidelines For Computer-implemented Inventions. American Committee for Interoperable Systems, Statement of August 18, 1995.
⁵⁷ Id.
⁵⁸ Id.
⁵⁹ Id.
⁶⁰ Richard Stallman, Software Patents - Obstacles to Software Development. Transcript, University of Cambridge Computer Laboratory, UK. Mar 25, 2002.
⁶¹ American Committee for Interoperable Systems, Statement of August 18, 1995.
⁶² David R. Syrowik & Roland J. Cole, The Challenge of Software-Related Patents. Software Patent Institute. 1994. http://www.spi.org/primsrpa.htm
⁶³ The Software Patent Institute. http://www.spi.org

What's inside...