Source Code and the Means-plus-Function Rule
My sister's law school buddy Mark Lemley has been getting a lot of attention with his attack on functional claiming in software patents.
In the context of a facebook discussion thread about this, I suggested that a good way to help enforce the means-plus-function rule in software patents, would be to require that software patents include source code.
This post expands on that idea.
If you don't have the inclination to go read Prof Lemley's paper, I'll summarize the problem with a simple example. Back in 1997, Michael Deering at Sun submitted a patent application on compressing 3D geometry. The patent was granted in 1999. If you read the abstract and the description, it looks like he is patenting a pretty specific way of doing that compression. However, let's look at claim 1:
1. A method for representing 3-D geometry data, wherein said 3-D geometry data includes a first value of a first parameter which corresponds to a first vertex, wherein said first parameter is a surface characteristic of a three-dimensional graphical object which includes said first vertex, said method comprising:
determining a level of resolution for said first value, wherein said level of resolution specifies a number of bits to use in representing said first value;
encoding said level of resolution for said first value in a data stream;
quantizing said first value according to said number of bits specified by said level of resolution, thereby generating a quantized first value; and
encoding said quantized first value in said data stream.
Determining how? Encoding how?
This is a textbook example of functional claiming. Claim 1 is on the function (determining, encoding) and not on the means (how?). Deering has patented the use of quantized numbers to represent vertex locations. Any computer scientist can tell you that all real numbers inside a computer are quantized. So this claim covers representing 3D data the only way it has ever or could ever be represented inside a digital computer. It is an absurd claim.
If you go through the rest of the claims, they get more specific about what you are encoding, but never really address any of the key "how" questions.
The description, on the other hand, is full of "how". In fact, it fully describes algorithms, and gives details like how many bits of quantization should be used. However, the description is just the "preferred embodiment." It is an example of what the patent covers, but is not actually what is patented. Any number of improved compression algorithms would also be covered. This patent effectively cuts off from further research any improvements in 3D compression. (Of course, it didn't have that effect, because nobody takes patent claims like this seriously.)
If we do away with functional claiming, and apply the means-plus-function rule, then the implementation found in the description would be what the patent covered. Instead of 100+ claims adding more and more bits of that implementation to the absurd claim 1, it could simply be:
1. A method for compressing 3-D geometry using the following algorithm: ...
So let's take as a starting point that we're living in the Lemlian utopia where the claim has to actually be on a particular implementation. How should that implementation be described?
The description section of the Deering patent is actually darn close to source code. It even has a "goto" statement! However, as anyone who has ever tried to implement a specification based only on the text will tell you, there is no substitute for actual source code. Whereas a text description can include some amount of hand-waiving, source code cannot. It fully and uniquely describes an implementation of the method.
If you are comparing whether one implementation infringes on the patent held on another implementation, the source code easily guides that decision. Any computer scientist will be able to tell you whether a difference is merely in the style of expression, or differs fundamentally in approach.
Most standards organizations refuse to consider proposals that lack a reference implementation (the W3C actually requires that there be at least two). The USPTO should apply this same rule, for precisely the same reasons. Text is ambiguous. Source code is precise.
The primary reason that patents exist is to ensure that the state of the art will progress. In exchange for telling everyone how you did something (so they can copy it, then improve it), you get exclusive rights to that something. So their copies cannot compete with you, only their improvements.
But, as everyone in the industry knows, unless you share source code, you really haven't enabled anybody to copy you. There are too many little details that the text description of an algorithm easily omits. And these details might mean the difference between an implementation working, versus being too memory or CPU or network intensive to operate.
When it comes to software, diagrams are not enough. If you want to enable someone to copy the idea, you need to show them source code.
In fact, I'll take that further: you need to put that source code in the public domain. After all, if you retain a copyright on it, then they cannot improve on it without being at risk of their work being considered an unauthorized derivative work.
Taking the above into account, my proposal is that the USPTO should require that any software patent include a reference implementation in source code. And that the source code be placed into the public domain, so that its only protection is the patent, and not copyright.
This changes the stakes dramatically. After all, even if the USPTO doesn't grant the patent, the source code has already been disclosed and placed in the public domain! So before submitting a claim, the inventor is going to have to make a serious decision about whether to give up their copyright and trade secret protection. My guess is that this would cut down on the number of patent applications dramatically.
Another benefit, obviously, is that people would be precluded from patenting ideas that have never been implemented. Requiring source code is a great way to ensure the idea actually works — thus filtering out more junk patent applications.
Why Allow Software Patents At All?
Yes, yes. I know that the world would be a better place if software patents simply went away. However, as Prof Lemley has pointed out, lawyers have found ways of getting software patented as early as the 1970s, when software patents were clearly not allowed. Simply banning them will do nothing to stop them, because lawyers will come up with clever ways around whatever rules appear. Plus, it looks politically impossible anyway.
So instead, let's look for ways to make them fit into the purpose of patents: to help advance the state of the art. Applying the Means-plus-Function rule, and then enforcing that rule through source code disclosure seems like a great start.
