Saturday, March 24, 2012

A Modest Proposal on How to Make Software Patents Suck Less

Timothy Lee, who's guest-blogging for Megan McArdle, has a nice condemnation of the US software patent system in general, and software patent lawyers in particular.  I am an inventor in 25 issued patents, all of them having at least a software component to them, so I have some experience in this area.  Here's my opinion:

Software patents suck.  They represent a huge drag on American innovation and are a significant barrier to entry into the technology business.  I wouldn't even think of starting a garage op these days; unless you're capitalized well enough to to a full freedom-to-operate search on your product up front and defend at least one reasonably competent troll, you'd be crazy to do something that you actually wanted to make money selling.  The abysmal swamp that comprises the body of software patent claims is effectively unnavigable.

The biggest problem here is that software method claims have to be written in English, and actual software methods aren't.  Even though every patent attorney I've ever worked with has demanded that I throw a few flowcharts of a preferred embodiment of the idea into the disclosure, the flowcharts can't be used in the claims, nor can pseudocode.  Just English.

There's actually a good reason for this.  Any specific embodiment of a software method that was claimed is trivial to be worked around to avoid infringement, because writing an equivalent algorithm is usually possible.  So you go to great lengths to make your claims as general as possible.

But the result is a nightmare.  First, the claim language,a without cross-referencing it back to the disclosure is just gobbledegook. Second, even after you've finally deciphered the claim language, the odds that it uses any standardized set of terms of art that might be cross-referenceable against other existing claims is vanishingly small.  So patent examiners can't rely on any reasonable keyword system to look for prior art.  Neither can lawyers doing FTO searches.

Bottom line:  If you've written more than about a thousand lines of code in your product, you've probably infringed on somebody.  The good news is that probably nobody will notice, because they can't do a reasonable search to look for art that your product may infringe upon any better than you can look for prior art to avoid infringement in the first place.  The bad news is that anything that you market successfully will cause the sharks to start circling.  Then you'll have zillions of claims that sorta-kinda look like you might be infringing upon them, and you'll have to litigate each one of them or otherwise make them go away.

Over the years, I've thought of several ways that the pain might be reduced.  Here are some of my favorites:
  1. Force all software method claims to be dependent upon an independent apparatus claim.  This would effectively allow somebody to use your idea in an unrelated product.  So, for example, Apple could beat up on Google when an Android phone used "slide to answer", but they couldn't take a medical equipment maker with a touch screen that used "slide to activate" or "slide to access diagnostics".  This also eliminates a favorite attack avenue for trolls, who love to extort companies with completely unrelated products that happen to use some method that peripherally resembles something that they own.
  2. Reduce the term of protection for software methods from 20 years to, say, oh, I don't know, maybe 2 years.  This business moves so fast that if you can't be successful with a two-year jump on your competitors, you're simply not going to be successful.
  3. Finally, let's look into the organization of the USPTO databases for software methods.  Truth be told, I don't really know what they do in this area, but I can fairly confidently tell you that it's not helping very much.  I assume it's mostly keyword-based.  If we had a structured library of objects, we might get a little further.
And it's this last one that got me thinking.

Patent claims have to be written in English.  But there's no reason why you couldn't  write method claims in some kind of high-level language, compile them to an intermediate, structured form, and then drive a code generator off of that intermediate form to produce claims, written in English.

If you can capture the essence of the method's intellectual property in that intermediate form (which is, admittedly, incredibly difficult if you want the information to be both sufficiently general and useful for searching at the same time), then there are a number of huge benefits.  If it's structured properly, you should be able to compare a test proposition against a database of reference intermediate forms to look for possible infringement.

If you're looking for freedom to operate, you can code up your product's methods in the new language, and an automated tool ought to be able to extract areas of potential infringement in one query.  You'll still need a human in the loop, but this would drive down your FTO search costs by at least an order of magnitude.

If you've ever been an inventor attempting to draft a claim, you'll know that you and your attorney play this tedious, horrible what-if game, where you pretend that you're a competitor trying to avoid infringement of the claim you've just written.  You do this to tighten up your wording to make the claim as general as possible.  With this new high-level language, probing your claim is much easier to do, because you can test various infringement-avoidance schemes by writing them up in the language and letting the software tell you if they conflict or not.

If you're an examiner, you'd love this thing.  Of course, the odds are pretty slim of getting legislation through to have the USPTO require that claims be written this way.  But imagine that inventors started attaching the high-level source code to the application, to supplement the formal claims that the source code generated.  The examiner will be much more efficient in understanding your claims and searching for conflicts if he can generate the intermediate form.

Of course, this doesn't help much for the zillions of claims that are already in there, but at least it puts a bound on how bad the problem can get in the future.  Also, I could envision the USPTO embarking upon an effort to reverse-compile existing claims to build up a comprehensive database against which to search.

As I said above, this is really, really hard.  Computer languages are pretty stupid, so encapsulating meaning in a rigorous form is going to be something that the inventor provides to the language, no the other way around.  I can think of some elements and requirements, though:
  • Terms of art.  Software geeks hardly ever use the same terms for the same things, so detecting that two areas of interest overlap is extremely difficult.  If your language formally defines terms of art, at least you can use keyword searches on the definitions to minimize the profusion of jargon.  In the best case, you slowly build up a list of statements like, "a fujiwatt is like a gizmo, except it uses a thingamabob instead of a framjamit."  Everybody understands object-oriented software engineering these days (or at least they won't admit that they don't), so classification of meta-information like this isn't a foreign concept.
  • Referencing enablement in the claim language.  Flipping back and forth between the disclosure and the claims when you're reading any kind of patent is inevitable, but it's worse with software patents.  Incorporating references to hunks of enablement in the construction of the claims would be meta-information that wouldn't make it into the actual claims but which would significantly improve understanding of claims.  It also has the nice property of making sure that you've covered everything you're claiming in some hunk of enablement, since failure to do so can invalidate your patent.
  • Writing algorithms in a scoped form, from the most general to arbitrary levels of specificity.  Your attorney whacks you repeatedly over the head until you learn that anybody can avoid infringement on a claimed algorithm.  The trick is to be able to describe the method in a form that's over-general, then specify its key features at ever-greater levels of detail.  If the language can support this structure, then it can tell you when you've made things just specific enough to have a novel, unobvious, useful claim.  Another goal of such a specification would be to allow dependent claims  to cover varying applications or options.
  • Modeling multiple agents in a system.  I'm a networking/telecommunications geek, and lots of my claims involved systems of software agents interacting with one another.  I expect that lots of software claims work the same way.  You often write sets of claims from the viewpoint of each agent in the system, so that a competitor can't avoid infringement by replacing one component of your system.  The language would need to support that.
I'm sure there are lots of other features.  Feel free to add your favorites.  The odds of my writing such a language are pretty small (compilers are not my thing), but who knows?

1 comment:

ken_anthony said...

I take the extreme view...

Property rights aren't but should be.
IP shouldn't be but is.

IP is the first step down the road to thought police. We just wait on the technology.

Give me liberty or give me death. Govt. says... Ok. Death.

Those that think IP gives them some advantage go along... until the govt. comes for them.