[kbutler]

How many patentable steps are there in useful chemical production paths?

I expect that any trivial software application has many (many) orders of magnitude more patent-vulnerable elements than the most complex commercially produced chemicals.

Software is much more free to include complexity because of the low cost of each element - there's no need to create a physical plant that implements the software.

This makes progress in software much more vulnerable to impedance by patents, because patents cause a greater increase in the relative cost of each element and because there are more elements involved.

And I think if we only allowed patents on "ground breaking" inventions, there would be many fewer patents and much less basis for anti-patent opinions.

[spartango]

Having worked in the pharmaceutical industry, I'll comment that synthetic biochemistry (and now metabolic engineering) have a substantial number of patent vulnerable steps, perhaps comparable to software.

It's kind of neat actually; synthetic chemistry in many ways shares its algorithmic and design-oriented nature with software engineering. Rational drug design will only add to the similarities and overlaps going forward.

[AnthonyMouse]

>This makes progress in software much more vulnerable to impedance by patents, because patents cause a greater increase in the relative cost of each element and because there are more elements involved.

I think you're possibly understating the problem. The idea that there are "more elements" implies that there are something like ten or a hundred times as many in software as in other industries, but it's worse than that.

The problem is that software uses categories where other industries use instances. Everything is designed as an abstraction on purpose. The result is that patent claim limitations that would be actual limitations in other industries are in software de facto claims of the entire class.

For example, if a claim limitation requires a network connection -- even a specific kind of network connection (e.g. stream sockets or unix domain sockets) -- and you're writing a piece of software intended for use with files on disk, you might think you're safe because you can't infringe that claim. But you're not, because the system calls that work on file descriptors also work on socket descriptors, and socket descriptors can be associated with any supported kind of connection. Your users can run your program and give it the name of a "file" which is really a socket and wham, your software is infringing. The abstractions we use to make things scalable and efficient also cause a combinatorial explosion in the scope of possible infringement.

In the extreme case, general purpose programming tools can in concept infringe any software patent. A user merely needs to type the claim limitations into the source file and the interpreter is happy to infringe. Naturally that case is probably too extreme to find much sympathy in the courts (or they'll come up with something like "substantial non-infringing use"), but the problem is that there is no line. Can we really draw a reasoned distinction between a bash interpreter that allows you to infringe a software patent by typing a twelve line shell script, and a web page that allows you to infringe a software patent with twelve mouse clicks?

It reminds me of this (http://boingboing.net/2012/08/23/civilwar.html) re: DRM. "Make me a general purpose computer that runs all programs except for one program that freaks me out." That's not how computers work. It's not how software works, and it's not how software is designed. You make software to have all the features users want by abstracting everything and making it modular so that anyone can plug in alternatives as they come about. Software patents come in and say "make the software have all possible combinations of features in the world, except this one combination which is covered by these claims." It just doesn't work that way.