Internet Patents: Giving Away the Store
Still with me? OK, you're about to find out how we got into this mess. Let's start with patent attorney Giles S. Rich, who in 1952 chaired a congressional commission that rewrote the Patent Act.
The Patent Act's language, dating back to 1790, enumerated patentable subject matter in the following terms: “any new or useful art, machine, manufacture, or process of nature”. In place of “art”, the Giles-led commission recommended that Congress use the word “process” instead. This was no insignificant updating. The history of technology reveals that the term “art” nicely captures the Constitution's intent in that, in this context, it refers to the non-scientific skills and techniques that a successful practitioner uses. In contrast, “process” could include scientific processes, such as those employed in industry. It seems reasonable enough to extend patent protection to industrial processes, but you shouldn't be naïve about Giles' intentions. In the early 1950s, Giles embarked on a single-minded, decades-long campaign to greatly expand the scope of patent protection to “anything under the sun made by man”, as the Giles-led commission put it. Subsequently, Giles fought for the legislation and jurisprudence that enable biotechnology firms to win patent protections for engineered life forms.
Enter computer software—and a great deal of confusion. In a computer program presented for patent protection, it is far from obvious (especially to those new to computing) just how to separate the abstract concepts from their practical application. In the 1972 Benson decision, the computer-illiterate judges tried to deal with a program that converted decimal numbers into binary numbers. Doing its job as charged, the Court attempted to determine whether the patent seeker was attempting to win a patent, not only on the specific application of the underlying idea, but on the idea itself. In its analysis, the Court determined that the underlying idea was the program's algorithm, which it defined as “a procedure for solving a mathematical problem”. The Court rejected the patent, pointing out that granting patent protection to this “mathematical algorithm” would be tantamount to granting a state-guaranteed monopoly on a scientific truth. Scientific truths are not subject to patent protection, the Court affirmed.
The Benson decision paved the way for the patentability of virtually all software algorithms. Almost immediately, the lower courts (and subsequently, the Patent Office) interpreted the Benson decision to mean that only “mathematical algorithms”, those that solve an equation for numerical purposes, are excluded from patentability. All other algorithms became subject to patent protection, even if they appeared to use mathematics. The key determining factor in an algorithm's patentability, the lower courts concluded, was whether the algorithm was intended to perform a numerical computation rather than control or supervise a practical process. In the end, the courts' reasoning led them to embrace patents for most mathematical algorithms as well, excepting only those with no known practical application, such as (presumably) an artificial life simulation.
What's wrong with the Benson decision is immediately obvious to anyone with a modicum of computer literacy. As Turing proved in 1937, there is no defensible boundary that separates mathematical from non-mathematical algorithms. On the contrary, any mathematical or logical problem that is capable of solution can be solved by a simple symbolic processor, which is capable of only a few basic operations, such as advancing and retracting a strip of paper and making or erasing marks on this paper. In short, there is no boundary that clearly separates mathematical from non-mathematical algorithms, such that the mathematical algorithms constitute a program developer's stock in trade of abstract concepts. On the contrary, the programmer's stock in trade consists of algorithms, most of which are used for purposes other than solving equations. For example, when you study programming, you examine a whole series of algorithms that perform tasks such as sorting and searching. Properly defined, an algorithm is a step-by-step procedure for solving a specified problem. Whether the problem is mathematical in nature or not has nothing to do with the level of abstraction involved.
To restrict the abstract conceptual knowledge of programmers and software engineers to mathematical algorithms is not only theoretically indefensible, but flies in the face of everyday professional practice. When you develop a program, you move from a functional specification, a statement of what the program is supposed to do, to a structural specification, a statement of how a particular algorithm, independent of any specific programming language, should be employed in the program's design. To accomplish this, programmers use paper-and-pencil techniques such as pseudo-code or flow charts, or programs that emulate these paper-and-pencil techniques.
Here's the key point. By restricting the abstract concepts of program development to a non-existent class of “mathematical algorithms”, the Benson decision enabled patent seekers, in effect, to win patents on the conceptual knowledge and mental steps that programmers use to create software. I'll return to this point in a bit, but first let's look at how the Court's reasoning in Benson led to Internet patents.
|Speed Up Your Web Site with Varnish||Jun 19, 2013|
|Non-Linux FOSS: libnotify, OS X Style||Jun 18, 2013|
|Containers—Not Virtual Machines—Are the Future Cloud||Jun 17, 2013|
|Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer||Jun 12, 2013|
|Weechat, Irssi's Little Brother||Jun 11, 2013|
|One Tail Just Isn't Enough||Jun 07, 2013|
- Speed Up Your Web Site with Varnish
- Containers—Not Virtual Machines—Are the Future Cloud
- Linux Systems Administrator
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Non-Linux FOSS: libnotify, OS X Style
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- RSS Feeds
- Reply to comment | Linux Journal
2 hours 14 min ago
- Reply to comment | Linux Journal
6 hours 14 min ago
- Yeah, user namespaces are
7 hours 30 min ago
- Cari Uang
11 hours 1 min ago
- user namespaces
13 hours 55 min ago
14 hours 21 min ago
- One advantage with VMs
16 hours 49 min ago
- about info
17 hours 22 min ago
17 hours 23 min ago
17 hours 24 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?