Alpha Geek

Just read these 14 lessons and it reminded me of one of my own: developers should write the user documentation first draft. Why? On many occasions, while I was doing this exercise, I found that I got stuck explaining a work flow in a way that I thought the technical writer would grok. Or I started writing a paragraph explaining some limitations of the software that I thought might trip someone up. And in those cases, I always end up going back and changing the code to be easier to describe, or to remove that limitation. It changes the economics: by making the developer write the docs, you have made them bear the technical debt. If it takes less work to fix the problem than to document the problem, then the problem just gets fixed.

I suspect I may be the only person who has the default app for opening PSD files set to Preview. I just cannot stand how long it takes photoshop to open a file (much less start up if it isn’t running), and more often than not I’m opening a PSD by accident, so I have it set to open with preview.

I may also be the only person who finds it quicker to use the “open” command in the terminal and type/tab/type/tab to enter a file name. But that’s just how I roll.

So put these together, and whenever I open a PSD from the terminal (which never happens by accident), it opens in Preview. And so I drag it from there to the Photoshop icon on the dock. And then go close Preview. Very inefficient!

Today it occurred to me that the “open” command probably had a way of indicating which App to use. And “man open” told me the trick was -a! So now I can type:

% open ~/fml/somefile.psd -a “Adobe Photoshop CS6”

and it works! Fun, right?

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.

Background

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: …

Using Source Code

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 Patent Compact

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.

My Proposal

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.

Ancillary Benefits

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.

I’ve been reading the breathless coverage in the press, and got curious about what the three software patents at issue actually say. Here are the links (finding the full patent numbers was surprisingly hard — I finally had to scour scans of court documents):

‘381

‘915

‘163

If you read the form the jury filled out you see that they actually decided two things. First, that specific claims of these software patents were violated by certain devices, and second, that these claims in the patents are valid.

Here is my reading of what Samsung was found to have violated:

Claim 19 of ‘381 is when you are scrolling a document and you reach the end, you can keep tugging and you see a gray background; then when you let go the gray background goes away, and you just see the document. (Despite press accounts “bouncy” and “springy” are not in there.)

Claim 8 of ‘915 is when you touch the screen, the view will scroll if you are using 1 finger, and it will zoom if you are using more than 1 finger. Notably, it would not apply if 1 finger did not scroll. (Despite press accounts, this is not a patent on “pinch to zoom”. It is a patent on deciding between scrolling and zooming.)

Clam 50 of ‘163 is when you double-tap on a web page and it zooms in so the column you tapped on is centered and fills the screen. I love this feature, although my casual polling has revealed that many people don’t even know it is there. (Despite press accounts, it is not a patent on double-clicking to zoom. Rather, it is a patent on cleverly knowing what to zoom in on, based on what’s on the page and where the user clicked.)

From the Building Windows 8 Blog:

While frame rate is an important metric, it doesn’t tell the whole story. For example, running a benchmark for 10 minutes and getting 60 FPS on average sounds perfect. But, it doesn’t tell us how low the frame rate might have dropped during the test. For example, if the frame rate dips down to 10 FPS momentarily during demanding parts, the animations will stutter. The glitch count metric looks for the total number of times that rendering took more than 1/60 of a second, thus resulting in a reduced frame rate. It also looks at the number of concurrent frames missed. The goal here is to have no missed frames during animations.

Love This!

My latest snag after switching to Mountain Lion was that my attempts to load a local .XML file with an XMLHttpRequest were running into:

Cross origin requests are only supported for HTTP.

I’m familiar with the error from trying to test on Chrome, where the only way to load local XML files is by using a local web server: Chrome will not let you load a file:// protocol XML file, even if it is being loaded from a page/script which was also loaded as a file.

But good news: this new Safari behavior is easily disabled. Just go to the Develop menu item and check “Disable Local File Restrictions”. Magically, the problem disappears!