In 1998 the Federal Circuit did away with the ridiculous software-is-just-hardware fiction by ruling in State Street Bank & Trust vs Signature Financial Group that software was patentable as long it yields a "useful, concrete, and tangible result." As you might expect, this resulted in a flood of patents on software, and generally kicked off the software patent controversy in the public eye. Fast forward to more recent memory, and the Federal Circuit decided to backtrack in a 2008 case called In re Bilski, which reversed State Street and instead articulated something called the "machine-or-transformation" test as the sole standard for patentability. That case was ultimately overturned by the Supreme Court in 2010's Bilski vs. Kappos: the Court not-so-helpfully said that while the machine-or-transformation is "a useful and important clue" in determining patentability, it's not the only possible test.

Ask 10 patent attorneys where we stand after Bilski and you'll get 10 different answers: while it's generally agreed that software patents are still valid, a look at how new software patent applications are being drafted makes it seem like we're back to pretending that software is just hardware again. Either way, it doesn’t matter: no matter what rules the courts and the USPTO issue, clever patent attorneys will be able to find a way to draft claims around them — that's how we ended up pretending software was hardware in the first place.

Does that all seem super boring and insanely complicated to you? It should, because it is. Our court system is designed to resolve conflicts, not make laws, and trying to arrive at cohesive and consistent software patent guidelines through five decades of litigation is more or less like trying to build a skyscraper by throwing dirt at a tree. You can't complain that the system is broken when we barely have a system.

The solution is simple, of course: we just have to add a real software patent section to Title 35. What would it look like? Well, we could try and define what a "software patent" actually is — that's never really been done in a meaningful way. We could also directly address the relationship between software and "just math," and try to find a balance between protecting the research and investment it takes to push the industry forward, while taking proper notice of the fact that there are some foundational principles of software development that are as fundamental as any other kind of math. We might also sharply limit the term of software patents to better reflect the pace of the industry and the lower fixed costs of software development — software costs less to create and distribute than physical goods, so it's probably fair to give companies a shorter period of time to profit from their inventions. Amazon CEO Jeff Bezos wrote an open letter calling for patent reform in 2000 that covered most of these points and proposed a term of 3-5 years. Maybe it’s time we dusted that off.

This need for fundamental software patent reform isn’t just wishful thinking — it’s understood at the highest levels of the judiciary. The legendary Judge Richard Posner just threw out the whole of the Apple vs. Motorola patent infringement case, saying that neither side had adequately proven what damages any alleged infringements had cost. In a followup interview with Reuters, Posner bluntly said “it’s not clear that we really need patents in most industries,” and specifically discussed the lower costs of software development as compared to pharmaceutical research as a reason to limit the IP protections afforded to the tech industry. But Posner is a judge, not a legislator, and he can’t write the law from the bench. That’s up to us — and ultimately, Congress.

Now, I'm not a software developer, mathematician, or patent expert, and I haven’t drafted a perfect software patent law that will protect real innovation and exempt mathematical principles while maintaining or even lowering the overall costs of the system. But I can damn well tell you that it's imperative that we actually try to deal with software for what it actually is, instead of pretending that it's magic fairy dust that changes computers into specialized machines or throwing in the towel and giving up. Admitting you have a problem is the first step towards recovery.