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.
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
| Making Linux and Android Get Along (It's Not as Hard as It Sounds) | May 16, 2013 |
| Drupal Is a Framework: Why Everyone Needs to Understand This | May 15, 2013 |
| Home, My Backup Data Center | May 13, 2013 |
| Non-Linux FOSS: Seashore | May 10, 2013 |
| Trying to Tame the Tablet | May 08, 2013 |
| Dart: a New Web Programming Experience | May 07, 2013 |
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- RSS Feeds
- What's the tweeting protocol?
- New Products
- Trying to Tame the Tablet
- Dart: a New Web Programming Experience
- Reply to comment | Linux Journal
14 hours 36 min ago - Reply to comment | Linux Journal
17 hours 9 min ago - Reply to comment | Linux Journal
18 hours 26 min ago - great post
19 hours 1 min ago - Google Docs
19 hours 24 min ago - Reply to comment | Linux Journal
1 day 12 min ago - Reply to comment | Linux Journal
1 day 59 min ago - Web Hosting IQ
1 day 2 hours ago - Thanks for taking the time to
1 day 4 hours ago - Linux is good
1 day 6 hours ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi

It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.



Comments
Thanks for your great post
Thanks for your great post and giving a chance to let us know about the history of patent law. Your post is so informative and I liked it so much. Regards, Mike Hudson, RadientGear
E-commerce is the most
E-commerce is the most wanted thing these days. And thanks to you for letting us all know about patent law history.....Atleast I was unaware of this matter. E-commerce is such a field about which everyone wants to gather as much information as possible.
Bolderdash - I disagree!
Dear Editors,
Thank you for the history of patent law wrt software & the internet.
I found this to be one of the best summaries I've ever seen and very useful.
All your logic and arguments make sense, except when you begin to blurr what a scientific truth is versus an algorithm. I don't see it. I'm fairly well educated and do not intend to go back to college - actually I never left. I'm now working on a PhD, part time. Turing and/or others may have shown that not all "problems" (Note: Not algorithms) can be solved in finite time. However, it doesn't follow that all algorithms are physical laws of nature. For example, which law of nature is it that says you can execute/commit an internet purchase with a single mouse click? I'm not arguing that Amazon's one-click patent will hold up in court, nor that it should have been awarded. I would take issue with this portion of this patent based on its simplicity and obviousness. However, as they say, hind-sight is 20-20.
Try to think of patentable software (some not all) as the distillation of a process into an algorithm that is hardware independent. Obviously it must execute on hardware to be useful, but the essence of the process doesn't really care what type of hardware it executes on, or if practical, even if it's done manually. Many processes that can be implemented in specialized hardware, can also be implemented in software on generic hardware, or done manually. I doubt you would have a problem with patenting a process if it were implemented in specialized hardware. So why argue against patenting the underlying process?
My advice to you is that if you don't see this - don't go back to college. Education is not the issue. My guess is that you have an axe to grind and for some reason you are a bit prejudice against software. I've encoutered this sort of attitude many times in my career over the past 30 years, as software and computers (e.g. generic hardware) has moved to the forefront, often displacing specialized hardware skills. I'm curious, are or were you guy ever hardware engineer(s) or just history buffs?
:-)
Best Regards,
BS-EE + MSCS