Software Patent of the Week: Designing a Rational Patent System

by on November 19, 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. This week’s patent comes to us courtesy of Ars Technica, which reports that Comcast has successfully beaten back an attempt by Caritas Technologies to extend this patent to apply to VoIP. This is good news for the IP telephony market.

The patent covers teleconferencing in which control functions are done via the Internet, while the actual calls are placed via the traditional telephone network. I think that’s a pretty obvious idea. But instead of belaboring that point, I’d like to talk about patent scope a little bit.


This patent goes into considerable detail about the implementation of their device:

The Conference Meister station 14 and the switch interface 33 communicate over the TCP/IP transport layer of the Internet 30 using the Internet’s User Datagram Protocol (UDP) with checksum. A common fixed-length interprocess message called the Conference Protocol Data Unit (CDPU), using the software format further described below in Table I, is exchanged between the Conference Meister 14 and the switch interface 33, in the data field of a UDP-Datagram. The switch interface 33 converts the CDPU into Signalling System 7 (SS7) commands which act on the switch 34, and attendantly, on the telephone network 32 to control the conferees telephones 20, 24, 28, 17. SS7 is an internationally recognized telephony standard of 255 commands for controlling telephone calls via switch 34 using standard lookup table procedures. The switch interface 33 interacting with the switch 34 may be implemented incorporating a standard micro-computer such as a Motorola 68705P5 performing the table lookup translation of SS7 commands into CPDU commands stored in its ROM memory. It will be noted that the switch interface 33 is bi-directional, and telephone connection status information as established by the switch 34, i.e. ringing, off-hook, on-hook busy, for all participants is transmitted back via the Internet to the Conference Meister for icon display on his PC.

All fields in the CPDU are ASCII character fields. The CPDU consists of 32 bytes of data as follows:

Session ID—-4 bytes

Conference ID—-2 bytes

Command/Response Code—-2 bytes

Data—-24 bytes

It goes on in this vein for several more paragraphs.

I’d like to step back a bit and talk about why we supposedly have patents in the first place. As I understand it, the theoretical argument for patent law, like copyrigts, is to prevent one inventor from free-riding off of the hard work of another. This is easy to accomplish with copyrights, because it’s easy to determine if I’ve made a copy of somebody else’s novel, song, or movie. Patent law is supposed to perform the same function, but it’s more of a challenge in practice because it’s never clear exactly what the scope of any particular patent ought to be. When Eli Whitney got his cotton gin, should that give him the right to prevent anyone from removing seeds from cotton by any method? Should it just allow him to prevent someone from making an exact replica of his machine? Or is there some point in between, where seed-removal devices that are “too similar” to his are infringing, but devices that work on different principles are non-infringing?

I don’t know enough about patent law to say exactly where this line has been drawn by the courts historically, but it seems to me that the theoretical answer is pretty clear: patents should protect the inventor’s particular implementation, and implementations derived from it, but it should not cover mere lists of features. Mr. Whitney’s patent should prevent others from removing seeds using the same mechanism his machine uses, but if they can find some other way of removing seeds from cotton, more power to them.

Applying this principle to software, I would think that this patent should cover products that provide conference calling functionality using the algorithms described above, or algorithms derived from, or closely related to them. So the patent might only cover teleconferencing products that utilize a Conference Protocol Data Unit, relies on SS7 for signaling, and employs a microcomputer for table lookups.

Obviously, that would render the patent practically worthless, because it’s trivial to “invent around” any or all of those specific implementation details. But I think that’s the point: interpreting software patent scope in a reasonable way would almost always make the patents worthless.

Of course, this isn’t how the courts have ruled in practice. Instead, the patent office and the courts tend to accept broad assertions of patent scope, in which a patent on “wireless email,” say, doesn’t just give the company a monopoly on its particular implementation of the concept, but on the very idea of checking your email with a wireless device.

Companies facing infringement lawsuits often pledge to “invent around” the software patent in order to avoid having to pay royalties. As I argued when RIM made this claim, this is almost always nonsense. If your product offers the functionality that the patent describes, then it’s infringing. There’s no way to “invent around” that unless you turn it into a completely different product.

Of course, I don’t think most judges have thought this through very carefully. Which is probably why RIM went to the trouble of coming up with a “workaround.” The workaround would most likely have been just as infringing as the original implementation, but it would have dragged the process out a few more months, buying precious time for the patent office to finish invalidating NTP’s patents.

Indeed, in a very fundamental sense, a software patent and a program’s source code perform exactly the same function: they describe what a piece of software does. The source code is just a lot more precise and has a lot more detail. So if I were going to design a rational software patent regime, I would require applicants to submit the source code of the software for which they were seeking protection. Source code, after all, is the software analog to the blueprints, schematics, and chemical formulas that are required for other kinds of patents. Then I would limit the scope of patents to cases where it appears that a software product’s source code was derived from the source code listed in the patent. This would ensure that patent scope wasn’t too broad, as programmers would be free to “invent around” a patent by coming up with a new implementation.

There’s just one problem with this idea: we already have a system like that. It’s called copyright, which prevents unauthorized copying of source code. And it works quite well. So what do we need a redundant patent system for?

Comments on this entry are closed.

Previous post:

Next post: