The PTO addresses Bilski and software patents

No readers like this yet.
open source button on keyboard

Opensource.com

When the Supreme Court decided the Bilski case, it didn't speak directly to the issue of software patents.  But the Bilski majority  emphasized that abstract ideas are not patentable, and recognized that allowing patents for abstract ideas could hinder innovation.  Thus there's still room for discussion of the legal standard for when, if ever, there should be patents on software. 

The Patent and Trademark Office is on the front line of the issue, since it has the duty of deciding whether to grant patent applications.  Whatever interpretation of Bilski it adopts, its decision will affect the patent landscape.  It was good, then, to see that this summer the PTO invited public comments on its proposed interpretation of the Bilski case. 

This is an issue that Red Hat has been involved in, having previously submitted an amicus brief in Bilski. Earlier this week, Red Hat responded to the PTO's request and submitted an understanding of Bilski that would mitigate some of the harm caused by poor quality software patents.  Here's the main part of the message that Red Hat sent to the PTO:

Today there are hundreds of thousands of patents relating to software, and tens of thousands continue to be granted each year. In many cases, these patents have vague and uncertain boundaries. Thus it is virtually impossible to determine whether a new software product could be deemed to infringe an existing patent. This means that introducing any innovative software product entails a risk of a lawsuit based on a vague patent. Such lawsuits often cost millions of dollars to defend, along with the risk of actual damages, treble damages, and injunctions. Far from encouraging innovation, vague software patents discourage it. The problem of vagueness is so endemic in software patents that it warrants action at the threshold level of subject matter eligibility.

In view of this serious problem, Red Hat submits that the Interim Guidance should be revised to recognize that software patents will ordinarily fail to satisfy the requirements of 35 U.S.C. Section 101 as interpreted in Bilski and prior Supreme Court cases. Software is essentially nothing more than a set of mathematical algorithms expressed in a particular programming or machine language. As the Bilski Court recognized, mathematical algorithms, by themselves, are abstract ideas that are not patentable.

As the Supreme Court found in Diehr and reiterated in Bilski, an application of a mathematical formula (as opposed to the formula by itself) may be entitled to patent protection. This does not mean, however, that merely storing or running software on a general purpose computer justifies granting a patent on an otherwise unpatentable algorithm. This is clear from the Supreme Court's Benson decision, which rejected as an unpatentable abstract idea a mathematical algorithm capable of being used in programming a general purpose computer. Thus the statement in the Interim Guidance that “recitation of some structure, such as a machine . . . will in most cases limit the claim to such an application” is overly broad and subject to misinterpretation.

The Bilski Court strongly reaffirmed that abstract ideas, including mathematical algorithms, are not patentable. In applying Bilski, the Patent and Trademark Office should recognize the applicability of this principle to software patents. This course is consistent both with the Supreme Court's teachings and the core patent objective of encouraging innovation.

Tags
User profile image.
Rob Tiller is vice president and assistant general counsel for Red Hat, where he manages patent, trademark, and copyright matters. He is a frequent speaker and writer on open source legal issues. Before coming to Red Hat, he was a partner with the law firm of Helms, Mulliss & Wicker, PLLC, where he specialized in commercial and IP litigation.

11 Comments

I'm still sitting on the fence.

It's clear from recent patent litigation that software patents are being interpreted overly broadly. But it's a stretch to refer to every software process as a "mathematical algorithm" that, by its nature, is an abstract idea. The best approach to reining in software patents may be to require that the code and machine be coupled in the application - and that there be enough specificity to the machine that use of the code for some other clearly different "machine" not automatically be considered infringing.

I think it's been clearly enough stated elsewhere that, just because a machine pushes electrons rather than pistons, it's still a machine.

What you describe sounds like copyright on binary programs, which I'm pretty sure RedHat and open source advocates are in favor of. I would go even further, and grant rights to a machine independent expression of an algorithm (just not the algorithm itself). Lo and behold, copyright already does that too!

Bad analogy time: No one resents the copyright on Harry Potter, but suing wanna be writers for creating stories involving boy wizards would be like a software patent. The abstract idea is "boy wizard". As a matter of fact, if your plot comes out almost exactly like Harry Potter, IANAL, but I believe that is not allowed, even if you tell it differently (unless it's parody). So there is some grey area, just like with software. And there is some real creativity possible, like telling the story from the point of view of another character (Snape comes to mind) that is blocked for that reason.

I think the separation of patents and copyrights is important. I will agree that copyrights *seem* to be under-emphasized in the software world, or at least are getting much less press. I also agree that there is an appropriate use of copyright in software, namely the visible representation of a concept. Amazon's shopping cart should have been copyrighted, not patented.

But suppose I invent a new search process: a certain way of aggregating web data, identifying key elements, representing it in an internal data environment, correlating it to query parameters, and returning results. The only truly copyrightable portion of that is the presentation of the results. The rest is process, and it should be patentable.

It is at best self-serving to call it a "purely mathematical algorithm" (PMA) simply because there's a community out there that would prefer that no software be patented. The PMA argument is a very blunt instrument and I'm not sure the Supreme Court has resolved anything in a practical sense.

"But suppose I invent a new search process: a certain way of aggregating web data, identifying key elements, representing it in an internal data environment, correlating it to query parameters, and returning results. The only truly copyrightable portion of that is the presentation of the results. The rest is process, and it should be patentable."

All the code you write to make that process concrete is automatically copyrighted. That is why we call running the program "processing". If you haven't made your process concrete, and tied down all the specifics, then it is an abstract idea. It is not useful until someone sits down and grinds out all the details for a specific application. That concrete realization is automatically copyrighted in the US. (I realize that you might never publish the search engine implementation - in which case it is a trade secret.)

Just like with physical inventions you have to have a concrete implementation to patent ("a machine to extract seeds from cotton" doesn't cut it, you have to show a specific implementation), so with software you have to have a specific fully realized design. But the wonder of computers is that merely writing out the design *in full* with all details specified, is "all" you need to do. With a cotton gin, you still need to manufacture the thing. With a computer program or a book, you just need to copy it. A machine "runs" it.

Hence, patents give you rights to the manufacture, and copyrights give you rights to the copying. For software, copying *is* the manufacture. With the advent of 3D printers, there is a convergence between copyright and patent. With a 3D printer in hand, say one that sinters a metal alloy, the concrete design of an invention fashioned from metal is all you need. "Manufacture" now consists of feeding power and powdered metal to the printer along with the design - just like feeding ink and paper to a printer along with the text.

When a book is copyrighted, you can't just change a few words here and there and publish it as your "own" work. You can't just rename variables in a copyrighted computer program and publish it as your "own". So your copyright covers a huge set of programs that are "nearly the same as" as judged by the courts. Translating into another language does not avoid copyright on a book, and translating into another computer language does not avoid copyright on a program.

If there were a valid software "patent", it would have to be machine executable to meet the same standards as physical inventions. But that concrete realization is already copyrighted. That is why all software patents are "overly broad". Because if they weren't they would be copyrights.

<em>I also agree that there is an appropriate use of copyright in software, namely the visible representation of a concept. Amazon's shopping cart should have been copyrighted, not patented.</em>

Actually, there is a special type of patent used to protect icons and screen layouts. It’s called a design patent. Here is an example of one of Amazon’s design patents. http://bit.ly/amazondesignpatent

"Just like with physical inventions you have to have a concrete implementation to patent..." This is not actually the case. You can patent an invention without a working prototype. The classic example is the PTO's assertion many decades ago that they would no longer accept patent applications for perpetual motion machines without a working example. In general the PTO neither asks for nor approves based on a working implementation, nor does the presence of one affect patent protection after the fact (except as "prior art" in invalidating a patent).

"When a book is copyrighted, you can't just change a few words here and there and publish it as your "own" work. You can't just rename variables in a copyrighted computer program and publish it as your "own"." This is grossly simplistic and ignores the difference between code (which, while copyrightable, is never seen by the end user) and written works. Most coding environments provide a rich set of tools. I could set two people down with a description of a process and they might write very different code to implement it. But it's still MY process.

I'm going to request something here. You're not going to like it. I would like people in this space to stop arguing this subject as though it were obvious and simple to resolve. It isn't. It would be very helpful for software innovation if the requirements for the patentability of software-based systems were more clearly defined. But it's ineffective, insulting, and likely counter-productive to continue to pursue the theory that NO software is patentable - which, when you cut through their response to the PTO, is what RedHat is professing. It isn't going to work, and it's doing some damage along the way.

You said,
"Just like with physical inventions you have to have a concrete implementation to patent..." This is not actually the case. You can patent an invention without a working prototype.

I didn't say "working prototype". A concrete implementation says *how* to build a prototype, but is not the (working or not) prototype itself. In the case of software, the program might not actually do what is claimed, but it is a concrete implementation.

You also said,
"This is grossly simplistic and ignores the difference between code (which, while copyrightable, is never seen by the end user) and written works."

A screen play is also (usually - just like with source code) never seen by the end user (the viewer of the movie). You keep making this distinction between machine code and source code, as if one would only want to copyright/patent machine code, when source code is the more abstract. Maybe I'm jumping to conclusions, but it sounds like you want to "copyright"/"patent" the function of the machine code, and never release the source, thus defeating the purpose of patents (if patented), or abuse copyright by broadly prohibiting an entire class of functionality.

Firmware blobs are copyrighted, is this what you mean? That they should be patentable because they are tied to specific hardware? I agree (and the judge does too), because it might convince the company to patent and release the internal workings of the corresponding *hardware*, and would remove the need for reverse engineering the firmware (and provide the limited monopoly). But then they might as well copyright the source code as well.

But "patenting" *only* a firmware blob on the basis of providing some abstract function in conjunction with trade secret hardware defeats the purpose of patents, doesn't meet the "concrete" requirement of a patent, and is just wrong.

The whole idea of a patent is to reveal trade secrets in return for a limited monopoly. Patenting machine code does not accomplish this purpose, unless it is in conjunction with trade secret hardware it controls.

My personal feelings are that there should be no patents for software; zip, zero, nada.
Patents should be the domain of tangible objects in the physical world.
If you come up with a way to express yourself via software, or any other art form, good for you; do something with it or don't but please don't try to get in my way. Software is basically a process, a means to an end; you can't touch it or use it without channeling it though another object. I don't believe business processes should be able to get a patent or copyright either, and I personally don't feel the people who judge what is able to achieve that status have a firm grasp of technology.
Locking your car is a process, the lock is an object. Would that be a possible business process?
What may seem profound to somebody in the USPTO may seem like the next logical step to hundreds of other people working in that field.
And lets not forget that patents have as much to do with money as ideas, if you can't pony up the cash to defend your ideas then you will most likely fail against the large patent trolls in the end.
So it is simple, patents on software stifle innovation. With this type of resource there is a possible shelf life that should be considered because there are many people smarter than you who may have better ideas that are stopped in their tracks because of some snippet of code, a snippet of code they also thought up on their own.
If you are designing the software to fill a need you should have a market hopefully, so sell it. If somebody else comes up with a similar idea then hopefully your product is better.
And another reason to just say no to software patents is a lot of the world won't observe them. They will use them to build on and come up with ideas the original creator had not considered, and that is usually how it goes. We all get there on the backs of others, so deal with it.

no one actually looks at software patents (as that triples damages), so they don't stop anyone in their tracks. Patent lawsuits only go after companies with cash, and those typically have their own arsenal of software patents to fire back with. A few small software writers (notice I don't say "inventor") get caught in the crossfire.

This would be a typical game for the rich and powerful - except for Patent Trolls. These entities don't actually write anything themselves - so they are immune to any counter arsenal of software patents. This spoils the game, and now a lot of big players are not so enamored with software patents anymore. Patent Trolls also highlight the inanity of patenting stuff that you write (for which copyright was designed).

Hi,

I am glad that the blog owner has chosen a very interesting matter about Invalidation search. Invalidation search is done to identify documents or prior use that may reduce the claim scope for one or more claims of a granted patent or to invalidate a granted patent. The information on this blog is very helpful in that it helps by spreading a great deal of knowledge among people. I would like to congratulate for this hard work to the blog owner and would like to be part of this site by submitting comments.

As a patent agent specializing in software and business methods, I can report that Bilski is not a problem. Inventors and patent examiners can usually work out suitable language pretty quickly.

The critical issue continues to be prior art. The more thoroughly an inventor searches the prior art before filing, the easier it is to get a patent allowed later on.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.