This week, the Supreme Court tackled one of the thorniest problems in tech policy: software patents. Virtually everyone agrees that a raft of bad patents makes it easy for trigger-happy litigants to make a quick buck — mostly by suing software companies for infringement and then convincing them to settle before trial. It's often cheaper to buy off the trolls than fight them, a situation that only encourages them to acquire more flimsy patents and launch additional litigation.
The case before the court right now deals with one such patent in particular. Alice Corp. established a way to carry out digitally what business people have long been doing in the physical world: Making sure both sides of a negotiation will uphold their ends of a financial agreement by using an intermediary. Alice is suing another company, CLS Bank, saying CLS is selling something similar to their electronic escrow form and therefore have infringed on Alice's patent.
Among the questions the Supreme Court must decide is whether Alice's patent should have been granted in the first place — did it meet the criteria to be valid? Problem is, the court lacks a strong test for determining this. CLS Bank, among others, say Alice is trying to claim a software patent simply by describing a perfectly ordinary function and then specifying that it be carried out on a computer without elaborating how. Onlookers are hoping that whatever decision comes down, it'll help clarify what types of software should and shouldn't be patented.
But legal experts say designing such a test is going to be really difficult for the court, in part because technology is changing faster than the laws. So here are a few ideas that might serve as alternatives. Some may be more practical than others, but they're all worth thinking about.
Require patent applicants to include their code. Alice Corp.'s lawyer, Carter Phillips, told the court the company didn't include any of its software code because the Patent Office told them not to.
"What we did here is what the Patent and Trademark Office encourages us to do and encourages all software patent writers to do, which is to identify the functions that you want to be provided for with the software and leave it then to the software writers," said Phillips. Later, he added, "It doesn't actually, obviously, put in the code, but that's what the PTO says don't do. Don't put in the code, because nobody understands code."
This seems like a fundamental oversight. As the lawyer for CLS Bank, Mark Perry, responded, Alice's patent simply invoked a "magic box" that described a set of functions and asked the Patent and Trademark Office to trust that the software did what they said it would do.
If software really is a patentable form of art, it deserves the same level of scrutiny that patent examiners trained in physics and chemistry give to physical inventions. To do that, you should be able to take apart a piece of software and understand how it works — not allow patent applicants to shut down the conversation by invoking some Golden Right of Code.
Unfortunately, as two Yale University students pointed out in a 2009 undergraduate paper on software patents, mandating the inclusion of code could be tricky. It might require an act of Congress. And assessing the code could take a lot of work, especially if the code was written by a bad programmer with sloppy habits. Still, it seems unthinkable to grant a software patent based more or less on a reading of the features it claims to provide.
Establish a Bureau of Code inside the USPTO. Patents are examined by very smart people, some of whom may have picked up programming skills over the course of their careers. But knowing how to read and write code is hardly the standard within the Patent Office, according to Mike Newton, an intellectual property lawyer at Alston and Bird.
"In this case," he said, "it would be the examiner who examines the patent. If it gets labeled that it belongs as something in a financial instruments area, that would be the person who looked at it."
Asking an examiner with a background in financial instruments to examine code — even if Alice had provided it — would've been a tall order. What the Patent Office really needs is a panel of programmers whose job it is to pick apart software and judge whether it's the invention the patent application says it is.
Shorten the term for software patents. The typical utility patent lasts for 20 years. In Internet time, that's practically eons. Software inventions that seemed novel and interesting a decade ago — online shopping carts or one-click buying, for instance — are now the standard everywhere.
There are high-profile advocates of shortening patent terms. The legal scholar and U.S. appellate judge Richard Posner has argued that the only industries that deserve long terms are ones that recoup the initial investment in research and development over extended periods, such as pharmaceuticals.
Another possibility may be to simply lean more heavily on existing tests for obviousness and novelty. But that doesn't really change how we tackle the underlying problem.
Abolish software patents altogether. There is a fourth idea, but it requires doing away with all software patents. Critics of software patents say they're more trouble than they're worth, and that we'll actually get more innovation without them.
Some large and established software companies don't like this idea.
"What we urge is to draw a distinction between 'real' software inventions and claims masquerading as software, like the kind in this case," Andy Pincus, a partner at Mayer Brown, told reporters on a conference call with officials from BSA, also known as the Software Alliance. "Technology that allows Photoshop to fix up photos that have a blemish ... Those are real inventions that are complicated, that are innovative uses of new software to do new things."
But ending software patents doesn't mean stripping away all intellectual property protections from developers. They could still get copyright protection for their work. While that means software companies would only be able to sue infringers if they literally copied the original code, word for word, it would give other developers the opportunity to write similar programs with different code. And that would certainly generate more competition.