by Chris Perryea
University of Washington

Let us imagine you are developing a game.  In this game, a character runs behind a tree to hide, but the tree partially obscures him.  In drawing both character and tree, how do you ensure the area around the tree is transparent so that you can see the character hiding behind it?  The answer may be obvious.  Employing a technique using "exclusive or" operations to copy the tree onto the screen does the trick.  This technique works in any situation where parts of an onscreen image must be transparent.  There is just one problem with this scenario.

It is illegal.  A company (Cadtrak, now NuGraphics) received a patent on the exclusive or technique [1].  Legally using the technique requires a license from the patent holder -  an expensive proposition.  This implies that only the most affluent software developers would be able to satisfy this demand.  Something about this stinks.

NuGraphics' aforementioned action raises questions.  Why legally protect their software, their intellectual property, from others?  Why do so with a patent?  If they had to protect it, can we develop (or are there) alternatives to patent protection?  What other entities have received software patents?  What do patents on software potentially do to software developers?  Let us address these by first exploring forms of legally backed intellectual property (IP) protection.

Many forms of legal protection for intellectual property exist.  These include trademarks, copyrights, and patents.  The U.S. Patent and Trademark Office (PTO) grants two of these, trademarks and patents, domestically.

A patent, according to PTO, represents property rights for an invention.  People other than the holder cannot use, sell, or make the invention (domestically).  A patent is therefore an absolute monopoly on the invention [1, 2].  The three types of patents are utility, plant, and design patents [6].  Design patents last for 14 years, while utility and plant patents last for 20 years from the filing date of the application [6].  Utility patents are for functional items and design patents are for redesigns of goods.  Patents are non-renewable once they expire.

Trademarks, the other IP protection offered through PTO, amount to a brand name.  They distinguish one product from another.  Trademarks prohibit everyone besides the trademark holder from using the trademark or similar names.  Unlike patents, trademarks are renewable indefinitely [6].

Copyrights cover items that are expressive in nature, rather than functional.  Copyrighted items must be original works, not copied from elsewhere [5].  Copyrights last 75 years from publication, or 100 years from creation, whichever is shorter [7].

NuGraphics is not the only entity to receive a software patent.  The following court cases provide some examples of other entities that have applied for software patents.  In the process, the U.S. court system's and PTO's views of software patentability are evolved and established.

One category of items that PTO can grant patents for are processes involving the transformation of physical material from one state to another [2].  In the 1972 case Gottschalk v. Benson, the Supreme Court heard that PTO denied Benson a patent for processes that converted Binary Coded Decimal numbers to a pure binary form [2].  The Court ruled that since Benson's process did not transform physical matter, it was not patentable.  The Court stipulated that Benson's process was more akin to a scientific principle, which may not be patented [2].  

In 1981, the Supreme Court heard another "process" case, Diamond v. Diehr.  The court ruled that the process, for curing rubber, was patentable.  What is the software connection?  The process made use of computerized calculations to determine when to begin curing [2].  PTO viewed this as free reign to issue patents for software, period [1].  The courts reinforced this view in 1999 with State Street, saying software producing a "useful, concrete, and tangible result" was patentable [3].  Therefore, the patent office sees each new use of a software technique as patentable, even those "obvious" to computer scientists [1].  

Hence, the PTO has issued patents for techniques that they do not understand and do not realize are common [1]. That commonality works against computer scientists, since obvious techniques do not typically merit publication.  This leaves the door open for any entity to obtain a patent to one.  As an example, Stallman and Garfinkle [1] mention a situation at MIT, whereby their X Window System utilized the simple concept of a "backing store" to maintain contents of obscured windows for easy replacement when the obscuring window disappeared.  They mentioned "backing store" solely in a manual, published after AT&T filed a patent application for the technique.  Result: MIT could not legally continue to use something it had developed.

Such debacles give rise again to questions of why to protect software in the first place, and after making that decision, whether to patent it or use some other form of protection instead.  One reason to protect software is to gain an advantage over another entity, for example to prevent competitors from developing like programs [4].  Patents are one way to provide that protection [4].  In my opinion, this is the sole reason for requesting a patent on software.  It is then left to PTO to either grant or reject those applications.

However, software is unique when it comes time to make that decision because it straddles the line between being functional and expressive; in the U.S. (and in Europe mostly) the former is patentable, and the latter is not [5, 3].  Software is functional because it takes input, does processing, and produces results.  On the other hand, software is more than simply functional.  It represents an idea -  intellectual property  -  of how to do the function it performs.  Thus, software possesses characteristics of functionality and expression.  Both patent and copyright, it would seem, provide protection for software.  Copyright, however, is not the absolute monopoly that patent is.  Copyright refers solely to copying - easily done with software - and unlike patent provides no competitive advantage [4].  The dichotomy between function and expression has enveloped software patent protection in the legal quagmire previously exposed.

Daniel Burk, a law professor at the University of Minnesota, examined the patent-software-copyright relationship in his essay "Copyrightable Functions and Patentable Speech" [5].  Burk establishes that software, as a functional item, is patentable but simultaneously is not patentable due to its expressive characteristics.  The contention Burk presents is that software is an expression of its developer; software is the developer's speech.  If patent protects a piece of software, others cannot make the same expression legally [5].  Ergo, the patent holder has infringed the right of other developers to free speech.  Burk's solution to this First Amendment situation is to place software into its own protection category, as copyright and patent can obviously not do the job.

Another lawyer, Robert Plotkin, also acknowledges the problem with applying patent law to software, but for an intrinsically different reason.  Plotkin manipulates patent law logically, beginning with the fact that patent law requires a structural design for a claimed invention [8].  If structure describes a claimed invention, then for the invention to be patentable it must possess a (physical) structure.  This requirement limits the scope of patent claims, and Plotkin believes this serves the purposes of patent law [8].  

Software (in source code form) does not have a physical structure to it.  However, when a machine processes code, it alters its physical structure to perform the tasks specified [8].  The resulting executable clearly has a novel physical structure and accomplishes something useful, making it novel in the patent sense [8].  However, this does not make the software patentable.

Developers do not know what the physical structure associated with code will be.  A developer does not design the physical structure of software.  The machine abstracts away the details, allowing the software developer to focus solely on function [8].  Patents for software can only describe as much as the developer designs.  As software patents do not describe software in terms of physical structure, resulting patents are too broad [8].  The result of this is that "software patent claims may, therefore, preempt most, if not all, technologically desirable and economically feasible implementations of the claimed functions [8]."  Simply, software patents provide more protection than they should.

We have seen that the inability to classify software under current regulations is problematic at best.  People wrestle with this point to different ends globally.  Canadian authorities, for instance, have not issued any software patents, although the Canadian Patent Act does not preclude them [3].  Rather, Canadian courts reduce software to mathematical formulae - abstract theorems - that by definition are not patentable [3].  The U.S. is almost a polar opposite and Europe inhabits a medium in between the two [3].  No state of agreement exists on the issue, although one item is clear: it makes no sense to continue to pigeonhole software into patent law.

Patents are out, copyrights are out, and so where to turn?  Many, such as Larry Woodard and Karen Durell, (a law scholar) have proposed schemes for IP protection [3,7].  While Plotkin does not present an alternative, he does submit guidelines for software protection.  All mesh nicely with Woodard and Durell.  They are:

* There must be a clear understanding of what software is including that software is defined in part due to its invention process and recognition that developers design software for function.
* A clear definition of terms must be made, so that "process," "algorithm," "mathematical formula" and other terms are not confused, and that differing meanings of "software" (example from Plotkin:  Executable software, tangible non-executable designs for software, ideas for designs of software) are not confused.
* A scheme must not be hasty in applying older assumptions to software (an example of this is the expressive/functional dichotomy treated here, also appearing in Plotkin, and in Burk).  [all from 8]

Plotkin sees a modification of patent procedure at the end of the IP protection tunnel, as do Burk, Woodard, and Durell [3,5,7,8].  The justifications Plotkin provides (which I agree with) for sticking with a form of patent protection are that current law allows for: determining novelty/usefulness/non-obviousness, distinguishing between different forms of the same design, a scope of protection which follows the scope of the invention, and public notification of protection [8].  Now, armed with the reasoning and guidelines presented by Plotkin, we can examine the IP protection alternatives of Durell and Woodard.

Durell clarifies Burk's view of software as both expressive and functional.  Software comprises a specific structure, sequence, organization, and presentation; both the content and the structure must be included when addressing "software" [3].  Rather than rely on results provided by software (since a "useful result" is all that is needed to secure a patent), the whole of a piece of software must be checked to ensure utility, non-obviousness, and novelty before a patent is issued [3].  This provides a new category of patentability guidelines (think back to Burk) specifically intended for software.  

According to Durell, shorter patent protection lengths will bring patents in line with the relative speed of the software industry [3]. Likewise, the application process should be shorter so that granted patents will provide protection while the software is still viable; two years from file to grant is too long for code [3].  Additionally, Durell believes in stiffer protection infringement penalties through license enforcement at the corporate level [3].

Woodard recognizes as Durell does "the need of protection that is flexible, short-lived, high-powered, easily obtained, and quickly-implemented as soon as possible [7]."  To this end, Woodard stipulates that an IP protection scheme "must combine the slight scope and ease of obtainability of a copyright with the increased protection and force of efficiency under the "best mode" of a patent [7]."  The foundation of Woodard's system comes from an article by Pamela Samuelson  which says that the behavior of software, its function, is the most valuable part of it and the source code and other elements are not as valuable [7].

For Woodard, the length of the patent depends upon the utilitarian value of software [7].  As an example, granting the design of some software's behavior the longest-running patent as it is the most valuable [7].  On the other hand, an algorithm written into software would get the shortest patent, as it is not as valuable.  The length of the patent also determines the scope of the patent as well as the ease to obtain it [7].  To use Woodard's example, "the standard of proof of novelty, usefulness, and non-obviousness for the one year patent of an algorithm is minute in comparison to the standard for a ten year patent on the industrial design of software [7]."

I am not entirely for a scheme like Woodard's utilitarian based system, although I agree with Woodard when he says that the scheme "must utilize as much legal theory and policy from the current system as possible [7]." I place a higher value on the non-functional aspect of software, particularly the algorithms.  That higher value does not lead me to call for according patent lengths.  On the contrary, the value of an algorithm lies in the knowledge it encapsulates and it must not rot away under the IP protection rock for very long.  An algorithm is an idea; it should not be constrained by legal tape.  I would suggest that applications for algorithm patents be either rejected or granted within a couple of weeks, and if granted, only provides protection for six months.  This I think is consistent with the pace at which the software industry operates.  However, accomplishing such a feat is not easy, considering the PTO's average turnover rate (~24 months) [6].

As in copyright law, software patents should provide for fair use, allowing developers to learn from each other and use acquired knowledge in their programs [3].  Software patents should not be handed out so easily as to impede progress and independent invention.  On rare occasion, there comes along a truly innovative piece of software that deserves IP protection, but again one must consider that such software will probably obsolesce before PTO patents it (under current law).  No practical reason exists to bottle up the software in patent, and prevent others from receiving the benefit of its expression.

Unfortunately, the courts are inconsistent in drawing the line between what software it grants patents for and how far the patentability reaches.  Many, like Samuelson [2] and Burk [5] see the problems underlying this inconsistency.  Others, such as Durell [3], Woodard [7], and Plotkin [8] are formulating solutions for the software patent issue.  A new standard for software patentability is a necessity.  Any standard, though, must ensure that all software developers - not just the largest - can develop software, that algorithms obvious to computer scientists not be patentable, and that independent reinvention and prior art are duly taken into account.  To do any less would severely restrict our intellectual freedom.

References

[1] Stallman, R. and Garfinkle, S.  (1992, January).  Viewpoint:  against software patents. Communications of
    the ACM, 35(1).  17.

[2] Samuelson, P.  (1990, August).  Legally speaking:  should program algorithms be patented.  Communications
of the ACM, 33(8).  23-27.

[3] Durell, K. (2000).  Intellectual property protection for computer software:  how much and what form is
effective.  International Journal of Law and Information Technology, 8(3).  231-262.
 
[4] Mykytyn, K, Mykytyn, P, et al. (2002)  The role of software patents in sustaining IT-enabled
competitive advantage:  a call for research.  Journal of Strategic Information Systems, 11. 59-82.

[5] Burk, D.  (2001, February).  Copyrightable functions and patentable speech.  Communications of the ACM,
44(2).  69-75.

[6] U.S. Patent and Trademark Office.  World Wide Web site.  http://www.uspto.gov/.  Accessed 11/22/03.

[7] Woodard, L.  (1997, Summer).  The West German Smorgasbord Approach to Intellectual Property Protection of
Computer Software.  John Marshall Journal of Computer and Information Law, 15(4).  883.

[8] Plotkin, R.  (2002, June).  Intellectual property and the process of invention: why software is different.  IEEE
2002 International Symposium on Technology and Society (ISTAS'02). Social Implications of Information and Communication Technology. Proceedings.  IEEE.