Software abstractions and metaphors are extensively used software development. For example, in the database arts, programmers use structural and functional abstractions such tables, fields, record, rows, columns and objects. The functions performed on these entities are themselves abstractions: programs read, write and lock records, sort tables, and delete objects.
When dealing with a specific problem domain, programmers define appropriate abstractions. Thus, a computer system for a financial institution would have accounts, transactions, deposits, withdrawals, transfers, payments and so forth. Grady Booch, one of the pioneers in Object Oriented Programming, describes the fundamental importance of identifying the important abstractions for a computer program:
A key abstraction is a class or object that forms part of the vocabulary of the problem domain. The primary value of such abstractions is that they give boundaries to our problem; they highlight the things that are in the system and therefore relevant to our design, and suppress the things that are outside of the system and therefore superfluous. The identification of key abstractions is highly domain-specific.[1]
Booch goes on to say that:
[T]the identification of key abstractions involves two processes: discovery and invention. Through discovery, we come to recognize the abstractions used by domain experts; if the domain expert talks about it, then the abstraction is usually important. Through invention we create new classes and objects that are not necessarily part of the problem domain, but are useful artifacts in the design or implementation. (emphasis added).
The emphasized statement is key here: Booch is not talking about using obvious abstractions that are inherent in the problem domain, like using a “patent” table in a database for tracking patent applications. Rather, he’s talking about creating abstractions that are not in the problem domain, but which serve a vital function in forming the solution. Thus, the act of abstraction is a key step in the development of computer applications, and can include the act of inventing the appropriate abstractions to present structures and functions in the application. The metaphorical aspects of these abstractions are what provide their meaning, by relating relevant structural and functional aspects of the real world, concrete entities to their computer implemented versions. Thus, what matters when using the metaphor of a “desktop” is that it serves as a space onto which documents and other items can be arranged; the attributes that desks are made of wood or steel are not transferred over to the virtual desktop because they are irrelevant to the functional goal.
Second, software development is about solving real world problems. It is a truism that software is used by businesses in myriad different ways—but it is also a truism that no business buys software—and no business creates software—to process “abstract ideas.” Most specifically, the creation of mechanisms in a computer program to achieve particular useful functions and structures is precisely consistent with the aims of the patent system. In many cases, it is a particular set of functions themselves, when directed toward a useful goal, that have value in the marketplace and that may be “inventive” (i.e., novel and non-obvious)—and not the underlying implementation of those functions, that is the actual programming code. This is the underlying insight of Research Corp. v. Microsoft Corp.[2] “that inventions with specific applications or improvements to technologies in the marketplace are not likely to be so abstract that they override the statutory language and framework of the Patent Act.”
Third, to state the obvious because so many people seem to forget it: software is the mechanism by which physical computers are controlled, nothing more, nothing less. Many years ago, computer programming required mechanical registers and switches using electrical and mechanical parts. The earliest programming languages were very “low level,” using the instruction set of the computer processor to move values into memory registers and add, multiply, etc., thereby directly controlling the processor, memory, storage units and the like. Programs were input into the computer using punch cards or punched tape, not by text entry of keywords and operators as we have it today. Over time, programming languages have been made to appear more like natural language, but even so, the symbols are necessarily represented by electrical signals that control the physical hardware of a computer. That such operations of the machine should be described through high-level functional or structural descriptions does not divorce them from their ultimate operation at the level of the machine.
Fourth, software is not unique in the sciences in its use of abstractions or symbolic representation to describe physical acts. Every scientific discipline depends on both the process of abstraction and the use of abstractions in developing idealized models of physical phenomena. Further, even the physical sciences, such as chemistry, rely on symbolic abstractions to describe physical operations. Chemical formulas are prime example of symbolic notation, both textual and graphical. Thus, methyl alcohol is represented textually as CH4O and graphically as:
Lewis Formula Kekulé Formula
All of these notations are abstractions from the actual physical structure of the chemical, but that does not make the concept of methyl alcohol an abstract intellectual idea. So too, the description of software processes as operations performed on data in a computer does not make such operations any less real. Nor does the use of a “computer language” make the software itself “abstract”—that conclusion confuses the symbolic notation for the thing itself.
Finally, it is well known that anything that can be done in software can be performed by hardware circuit and vice versa; this is known as the Church-Turing thesis. Indeed, it is standard practice today to develop hardware by first defining the functional operations of the hardware using software languages, and then converting the software description to a hardware specification. This is known as Electronic Design Automation. It seems very odd to say that the software is a purely abstract idea that gets “converted” into a physical thing to control a machine.
The problem then with argument that software is a purely abstract idea is that it confuses the concept of abstraction with the concept of abstract idea. As I have explained, patent claims necessarily and properly use abstractions to define inventions. When it comes to software patent claims, it’s necessary to keep the distinction between abstraction (patent-eligible) and abstract ideas (patent-ineligible) front and center to avoid mistaking one for the other. Sadly, this mistake is all too commonly made, both by the courts and by litigants.[3]
[1] Object Oriented Analysis and Design, Benjamin/Cummings Publ. Co. Inc., (1994), Redwood City, CA, p.162.
[2] Research Corp. Technologies v. Microsoft Corp., 627F. 3d 859, 869 (Fed. Cir. 2010).
[3] My thanks to Hersh Reddy for his insightful comments on a early draft of this blog.
