What I wish they'd said in Alice was that you can't meet the patentability standards piecemeal. That is, I wish they'd said that you can't have an invention where the novel part isn't patentable subject matter and the patentable part isn't novel, like software + a formulaic definition of an ordinary computer.

I think that's more or less the state of affairs they wanted to get to, but they never quite worked out any comprehensible way to get to that and just kinda punted.

I liked the older subject matter standard (I can't remember the case In Re Alappat, maybe?) where the combination of software and hardware is considered the machine under consideration. Thus, novel software running on conventional hardware is viewed in combination as a novel machine.

This makes sense to me for some reason. I wish this remained the 35 USC 101 standard for software patents, I think it cleanly resolves subject matter problems. Then the courts and Congress could focus on developing better law using 35 USC 102, 103, and 112 rather than trying to use subject matter, which is by design the broadest patent law on the books.

Yes, this creates a very bright line that's easy for lawyers to follow, but in return it allows every trivial act performed on an ordinary computer that someone has not yet submitted to the USPTO to be an "invention."

Given that inventions are not rivalrous and actual practitioners of the art don't generally go around reading patents in the first place (other than, perhaps, those newsworthy due to litigation or sheer idiocy), this makes an area ripe for trivial lawsuits from people taxing the work done by others while providing no actual benefit from the patents themselves.

This leaves the two arms of the scale badly unequal. Supposedly, we derive the benefit of knowledge in exchange for patents. Instead, we're getting "do X on a computer" we already know how to do and make for any given X in exchange for a huge number of lawsuits from patents filed by lawyers who have never actually built a thing, who have at best a vague idea as to how something might be done.

The real work is the implementation. Maybe you could convince me if they actually had to build the software and release it to all alongside the patent so that society benefited from that when it expired, but the patent terms are too long for such software to be useful at the end and the various patent lawyers I've interacted with are adamantly against that idea.

Good points.

However, I think 35 USC 103 (non-obvious requirement) could be used knock out the X plus Computer claims these days.

E.g., If X is not novel and computers are not novel -> no invention because it is obvious to combine them.

Also, I agree that USPTO (and courts) should require more proof of invention/implementation. This could be handled by increasing the requirements for meeting 35 USC 112 (enablement). For example, I think it would reasonable to require more explicit disclosure of pseudo code, data structures, protocols, sequence diagrams, state machines, experimental proof of claimed performance improvements, and such. Quality software patents tend to have a lot of this stuff already. The idea here is to prove the inventors have actually invented the innovations they are claiming not necessarily restrict the invention to one particular data structure or protocol.

Some bio/chem patents have additional requirements when compared to gadget patents. Software patents could be improved similarly.

I would also be open to considering changes in the length of patent terms for certain types of software patents. Not sure how that rule would work though, because there really is no such thing as a software patent. Inventions in so-called software patents are usually described as being part software and part hardware with the assertion that some or all of the software parts could be implemented as hardware or vice versa.

We got into this current mess, because courts latched on the subject matter arguments instead of looking harder at novelty, non-obviousness, and enablement. I am not sure why they didn't rely on obviousness more when they started down this path. The early software patent cases screwed things up back when no one knew how to handle them.

> E.g., If X is not novel and computers are not novel -> no invention because it is obvious to combine them.

This is a fair point, but 'novel' seems to get read as 'someone has already patented this before'.

> This could be handled by increasing the requirements for meeting 35 USC 112 (enablement).

This is also reasonable, enablement right now is kind of a joke, higher standards for that would generally be good. I'd like to see any working implementation of the claimed invention in software for patents that include that. It need not be a fully formed app, but it should compile and demonstrate whatever is claimed, IMHO.

> Some bio/chem patents have additional requirements when compared to gadget patents.

I don't claim to have read many patents in that area, but I'd expect that bio/chem patents should have to give the chemical formulas and synthesis, which should do a lot for enablement.

> I would also be open to considering changes in the length of patent terms for certain types of software patents. Not sure how that rule would work though, because there really is no such thing as a software patent.

Yeah, I know there are complications on defining 'software patent', but generally we understand when someone patents a process performed on an ordinary computer or something similar.

> The early software patent cases screwed things up back when no one knew how to handle them.

They're trying too hard to preserve existing precedent while moving in a new direction. I agree that they need to reform some of those factors to get to a better place and that the existing rulings just aren't very clear.

Reading the EFF's article, it sounds like they want to take a tact much like the one I want. I just wish the Supreme Court had written a clearer holding.