Software Patent of the Week: Abstraction and Subclassing Are Not Inventions

by on September 8, 2006 · 6 comments

Every week, I look at a software patent that’s been in the news. You can see previous installments in the series here. One of the amazing thing about the software patent issue is just how pervasive software patent litigation is. When I started this project, I was afraid I’d have to scramble to find a new controversy to write about each week. Boy was I wrong. Most weeks, like this one, all I’ve had to do is run a Google News search for “software patent” and there’s new lawsuit on the first page of results. This week’s dispute is between i2 and SAP over seven patents related to project management software. Here is the oldest of the seven patents.

This patent is akin to the Guatemalan database patent and the Friendster patent I covered in previous weeks: it seems to simply describe a software product in great detail, as if a list of mundane features constitutes an invention.

In addition, the patent seems to put a lot of stress on the fact that their project management software is generalizable and extensible:

The modeling needs of these varied activities can be very different. To support those variations, the operation model can be extended via a `process` extension. Different extensions each can add different fields to the operation model. A simple process extension may add a single field such as a fixed amount of time that the operation runs. A more complex process extension may add a fixed time and a per-unit time that is computed proportional to the number of units that operation performed. A much more complex process extension may add a field that is a list of other operations which are performed in sequence in order to perform this operation.

Thus, unlike traditional manufacturing software that separate routings and operations, the present invention allows a routing to be modeled as simply a particular kind of operation–an operation that consists of other operations that are run in sequence. The relationships between those sub-operations can be different depending upon the chosen extension. So, an operation can model a simple routing (a sequence of operations allowed to spread), a flow routing (a sequence of operations which must flow into one another), a set of operations that can be run at the same time, alternates (a set of alternate operations), and other combinations.

This may sound impressive to non-programmers, but this is precisely the sort of design skill that is taught in entry-level computer science classes. Indeed, abstraction (replacing several special-purpose functions or objects with a single, more general function or object) and subclassing (extending a general-purpose function or object by adding case-specific functionality) are two of the most fundamental tools in the programmer’s toolkit. It’s a quintessential example of a technique that’s obvious to those of ordinary skill in the art of computer programming.

The rest of the patent continues in the same vein. It describes the various functions of the software in gory detail. The vast majority of it describes the sort of data models that a CS undergrad would build in an entry-level database class. This patent clearly should have failed the obviousness test.

Comments on this entry are closed.

Previous post:

Next post: