Examining the Patent Examiners

This article appeared in Light Reading a few days ago: Cisco's Triple Threat. It seems Cisco has bought a patent of Sandstream Communications that claims to cover a "System and method for providing integrated voice, video and data to customer premesis over a single network." As near as I can tell, this patent is completely bogus. It's on par with the XOR cursor patent from the 1980's, Amazon's One-Click ecommerce patent from the 1990's, and Huawei's recent "syslog over SSL" patent.

The first claim of the patent from the PTO web site says:

1. A method for providing integrated voice, video, and data content in an integrated service offering to one or more customer premises, comprising: receiving television programming from a programming source; converting the television programming to a common format for communication over a single network infrastructure using a common communication protocol; receiving data from a data network in the common format of the common communication protocol for communication over the single network infrastructure; receiving telephone communications from a telephone network; converting the telephone communications to the common format for communication over the single network infrastructure using the common communication protocol; communicating the converted television programming, data, and converted telephone communications in the common format over the single network infrastructure using the common communication protocol to one or more customer premises to provide the integrated service offering; and assigning customer premises to multicast domains to support conditional access of the customer premises to content that is selected from the group consisting of selected television programming, video-on-demand, pay-per-view video, near-video-on-demand, audio channels, audio-on-demand, and interactive gaming, wherein the conditional access is implemented using interdiction.

In simple language, this appears to cover the transmission of television, telephone, and data communications over a single network to a customer premise.

Now, before I start ranting, let me first say that I'm not beating up Cisco here. I have needled Cisco for other reasons here before, but this isn't one of those times. Cisco didn't file this patent; they bought some intellectual property of a failed company, the contents of the sale of which probably just included this patent as one item. To my knowledge, Cisco hasn't asserted its patent rights against anybody with respect to this patent and may never do so. The Light Reading article discusses the patent, but doesn't report any bad behavior by Cisco with respect to it.

Thus, let's keep the focus on the real bad guys here: the patent office. The patent examiner who granted this patent needs to be shot. Folks, this is a screaming example of a bogus patent.

For the rest of you (the patent examiners should know this already), not every invention is patentable. There are certain tests an invention must survive before the patent office grants the patent. In particular, an invention must be novel and unobvious for a person having "ordinary skill" in the area of the patent.

What does that mean in plain language? Well, novelty means that nobody has either done it before or communicated publicly about it before. In other words, it has to be new. This patent was filed in the year 2000. Was a single network carrying television, telephony, and data new in the year 2000? I think not. I seem to remember everybody working on such a network back in the early 1990s. At the time, we called it "ATM."

Now, is a network carrying television, telephony, and data exactly unobvious to a person having "ordinary skill" in the year 2000? Again, I think not. Let's see... IP data networks have been around for a long, long time. People were talking about doing video on demand in the 1990s, using IP for the transport. VoIP products were shipping in the 1990s. Seems like right there we have all the ideas "...for providing integrated voice, video, and data content in an integrated service offering."

So, I contend this is another case of the patent examiner not doing his job. This patent needs to be thrown out. At a minimum, it needs to be severely narrowed to cut out all the crap and reduce it to something truly novel and nonobvious. There are other non-trivial claims in the patent and I didn't bother going through each one word-by-word to see if there might actually be something novel and nonobvious lurking; a quick skim didn't reveal anything, however.

Given the shakey ground on which this patent rests, I wouldn't expect Cisco to try to enforce it broadly. If they were to actually try to go up against the carriers or even other manufacturers, the results would be disasterous. What does worry me in such situations is selective enforcement, where a large market leader threatens smaller players for whom the cost of a defense is prohibitive. Patents like this one are a threat to innovation because while the market leaders will have cross-license agreements with each other, they may bully startups who can't expend the energy to fight.

Ultimately, the patent office needs to be taken to task for letting patents like this through its screen. As a holder of five patents myself, I'm not completely anti-patent, but I see many abuses in the system and huge opportunities for reform. That's another discussion entirely, but let's start the reform here: throw out this bogus patent.

Networking Myths: Software, ASICs, and Network Processors

Google managed to dig up a nice Vyatta reference over at Seeking Alpha: The Future of Network Processing Units Doesn't Look Too Rosy. This was an interesting article because it discusses the technological underpinnings of the networking market. What's the best way to get packets from place to place: software-only, network processors, or dedicated ASICs?

All of these approaches have been tried over the past few decades. I have been fortunate to have participated in the design cycles for some of the key products in the industry. I have worked on designs that have used all three approaches. The answer to the question varies at any given point in time because of technology forces at play in the market, and it depends on what you are trying to optimize for.

What has been interesting is watching the reaction to Vyatta in the market place. There are networking users out there that have been so schooled by vendor FUD that they don't believe a given product can do a particular job unless it's implemented with a given technology. With respect to Vyatta, this typically manifests itself in a statement such as, "Everybody knows that software routing can't do the job; Vendor XYZ has ASICs." It's as if some people believe routers must be implemented with ASICs or they somehow won't work.

Now, not to get too theoretical on you here, but let's talk through some of the issues. All network devices (all computers, actually) are simply big state machines. In response to external stimuli (networking packets in the case of networking devices), the machine jumps from state to state and produces output (switched packets, routing updates, etc.). The only difference between software, network processors, and ASICs is how that state machine is implemented and how quickly it runs.

The short rule in the industry is that if it can be implemented in software, it probably should be. If the functionality is at all complex, it is bound to have bugs that need to be fixed, or additional features to be added. Software gives you the ability to change things down the road.

ASICs are interesting for two reasons. First, they are sometimes more cost effective. You can build a machine to do a custom function with fewer logic gates that the millions and millions required to implement a general-purpose CPU. This is offset by higher design costs and lower volumes for specialized silicon, however. Second, dedicated logic can do things in parallel that software might have to implement with a serial design, thus improving performance. Dedicated hardware will be faster, in the abstract, than software running on a general-purpose processor. The question is, how fast is fast enough given all the other tradeoffs (cost, flexibility, etc.)?

Network processors and field-programmable gate arrays (FPGAs) offer an interesting middle ground. Network processors are CPUs tuned for performing networking tasks. While they are sometimes faster for very specific tasks, they achieve that speed by optimizing for a very specific task: network processing. It's very easy to push a network processor outside the sweet spot of its design target by adding new functionality. Once this occurs, the network processor is often slower than a general-purpose processor performing the same task. Network processors often have very low clock speeds, for instance (hundreds of MHz vs. GHz for x86 processors). They often have small instruction code memory or caches that are optimized for very small loops or very structured data sets. Finally, the costs for network processors is often on-par or even more expensive than a general-purpose CPU, since volumes are smaller and the market more specialized.

A good example here might be the old word processor market. When word processing first came on the scene, Wang made dedicated machines that performed the function. They were custom tuned to do word processing and word processing only. They did it well. And then they died when general-purpose PCs became cheap enough to do word processing and spreadsheets and presentation graphics and all the other things that people wanted to do on their desktops besides word processing that Wang's machines were unable to do.

FPGAs offer another interesting middle-ground. FPGAs allow dedicated hardware logic to be implemented in a chip that can be reprogrammed in the field. The reprogramming can be done whenever a bug is found or some additional functionality is desired. While these features are advantageous, there are still limits. Further, FPGAs are relatively expensive compared with ASICs, though they eliminate some of the up-front ASIC design expenses.

What's going to be interesting is watching Vyatta exploit all of these potential hardware avenues. What many of the early "Everybody knows that software routing can't do the job; Vendor XYZ has ASICs," comments miss is that:

1. Software can do the job for a nice sweet spot in the market. Vyatta has demonstrated great price/performance characteristics in the T1 to 2 Gbps segment with its currently-available appliance. This is not to be taken lightly. While dedicated hardware is still advantageous in the low-end, for low cost, or the high-end, for performance, software routing works very well in the mid-range.
2. Vyatta is not limited to running on standard x86 hardware. Vyatta can take advantage of standard CPUs, network processors, ASICs, and FPGAs. Which will we pick? Well, that depends on what we're trying to achieve and for which market segment.

If you have thoughts about these issues, we'd love to hear from you. Feel free to drop me a note directly or join our mailing lists. I'm "dave" at Vyatta.

Cisco has a new logo

Cisco recently changed its logo. The new one (hat tip The Inquirer) looks like it was drawn by a child with a crayon. While the new logo does seem to generate a negative reaction from a majority of people in our office, I'm sure Cisco's corporate marketing folks can take solace in the fact that they paid a LOT of money for it.