In another patent thread some time ago I identified what I think is the core problem with software patents, which is abstractability. I used the example of a tractor being generalised into transportation, so I was nodding along with Joel's example.
This is because that's how software development often proceeds. We start with the concrete problem, then notice a pattern that encompasses a class of concrete problems, then a pattern that describes a group of classes of problems and so on. Building abstractions is literally what we do as a profession.
Now, as Joel points out, the rational strategy is to take the highest-level, most abstract version of your invention to the patent office to see what will get passed in. So patent applications are written like matrioshka dolls, with a super general case on the outside, and progressively more concrete descriptions as you go deeper. Somewhere near the bottom is the original thing that started the ball rolling.
This is because that's how software development often proceeds. We start with the concrete problem, then notice a pattern that encompasses a class of concrete problems, then a pattern that describes a group of classes of problems and so on. Building abstractions is literally what we do as a profession.
Now, as Joel points out, the rational strategy is to take the highest-level, most abstract version of your invention to the patent office to see what will get passed in. So patent applications are written like matrioshka dolls, with a super general case on the outside, and progressively more concrete descriptions as you go deeper. Somewhere near the bottom is the original thing that started the ball rolling.