Expression versus idea

The common view on copyright versus patenting is that copyright protects the expression of an idea, while a patent protects the idea itself. One idea can be expressed in many different ways. In other words, copyright can protect one specific mystery novel, while a patent on the idea of a mystery novel itself will prevent anybody else to write mystery novels. The relevant US statute [34] reads as follows:

Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.

U.S. courts have summarized this principle by stating that patents do not apply to ideas themselves, but to "implementations" of ideas, intending a broader and more inclusive sense of "implementations" than is commonly given in the software development community. It is akin to the notion that copyright protects expressions of ideas rather than ideas themselves [25]. A similar definition can be found in the TRIPS treaty [36] that regulates trade-related aspects of intellectual property rights:

... patents shall be available for any inventions, whether products or processes, in all fields of technology, provided that they are new, involve an inventive step and are capable of industrial application.

Now it happens to be the case that software engineering has its own ideology about the distinction between idea and expression of that idea. A specification of a software system describes the desired functionality of a system and defines what is required. The specification leaves open many options how the specified system will be built (the implementation⁷ of the system).

For a software engineer, it is hard to understand why software patents (supposed to be about ideas, e.g., specification level) end up having detailed flowcharts that belong to the implementation level. This raises the issue how software engineering and the patenting system interfere.

Another observation is that the legal language in patents is about software. Now it also happens to be the case that the topic of software specification has a long history in computer science and, from a computer science perspective, the legal descriptions in patents can in no way be classified as such. In that sense patent texts are technically (but, of course, not legally) unacceptable for software engineers, which has implications for their utility as disclosure documents.

In our opinion, the patenting literature should take good notice of what is known about describing software systems. A crucial observation is here that the notion of formally describing an idea does not occur in the software engineering literature and it will be very hard to achieve this in patent texts. Another observation is that we think that it is unavoidable that patent texts will become machine processable documents that will form an integral part of software in a similar fashion as specification, documentation, test cases and the like form an integral part of a software system.

A final, and also crucial, observation is that the requirement that a patent should make a ``technical contribution'' is hard to reconcile with software that lives in the realm of logical structures. In this way, software patents have to be expressed in unnatural ways that lead to under-protection as well as over-protection of certain inventions.

This is eloquently described by Plotkin [28], he proposes a reinterpretation of the patenting system from a software perspective. His observation is that there are crucial differences between the invention, description and patenting of electromechanical devices as compared to software programs. His key observation is that for electromechanical devices apart from a functional design, deriving a physical structural design is hard and also essential for obtaining patent protection. In the case of software, the logical structures described by the source code are the end point of human invention: the step to their physical realization is fully automated. Plotkin's objectives are the following:

A methodology is proposed for determining how particular areas of law should apply to software. The methodology asks and answers four questions: (1) What is software?, (2) How does software differ from other creative works?, (3) How are such differences legally relevant?, and (4) How should the law treat software in light of such differences? Application of the first half of this methodology reveals that computer programs have the unique quality of being human-readable and computer-executable instructions that describe actions in purely logical terms. Application of the second half of this methodology to patent law and the First Amendment to the US Constitution reveals that software's unique features violate the law's assumptions, leading to results that are at odds with the underlying public policies in each case.

In later work [29] Plotkin proposes software patents in such a way that:

• a software program be claimable solely in terms of its logical structure;
• a software program be patentable if:
  • the inventor provides a written description of the claimed logical structure;
  • the inventor provides a description that enables one of ordinary skill in the art to make and use the claimed program without undue experimentation;
  • the claimed logical structure has a practical utility;
  • the inventor conceives of the claimed logical structure;
  • the claimed logical structure is novel and nonobvious; and
• the scope of a software patent claim be limited to products and processes that embody the claimed logical structure.

Other interesting proposals exist for reforming the patent system or for providing other forms of legal protection for software but they are not further discussed here. A concise summary of the history and current status of software patentability can be found in [18].