Slashdot Mirror
IPFilter Infriging on Bay Network Patent?
jorhan writes "Darren Reed,
the author of IPFilter,
recently posted this message to the IPFilter mailing list. Apparently IPFilter may infringe upon USA patents owned by Bay Networks, specifically, #5790554. The patent might seem to own just about every conceivable way one might wish to filter and forward data packets, but trying to read through all of the "wherein said first condition" started to give me a headache (ObIANAL). But when you read what application the authors specifically had in mind, it really has little to do with network layer firewalling. Even more important is the question Darren's mail indirectly poses, "Anyone know of any prior art?""
I have seen the enemy and it is us... and we attack with a sea of legal papers which will kill us with paper cuts
"Conclusion: Yet another example of the shortcomings of the United States patent system. Sure, it's better than anything else in the world--but that doesn't mean it's perfect. Far from it, infact."
Hmmmm, I'm curious - it's the "best" patent system in the world, but here we have "yet another example" of its failings.
How much do your actually know about the patent systems of every other country in the world?
It'd be nice if someone had a few thousand dollars to hire a lawyer and get a more definitive answer, but it seems like prior art was also mentioned in the (two message) thread, so this isn't (yet) a serious issue.
The patent seems to only apply if you use numeric offsets into fields. If the patent is an intent to patent just about any rule-based firewalling, just about any commercial firewall product -- like FW1 product for Solaris would be simple examples of prior art. If this isn't the case, then it's got too many differences between itself and IPFilter or IPtables to be of much use in shutting down the IPfilter project.
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
Reading the patent, both the abstract and the claims say many things to indicate that this patent covers network devices "such as a switch". Much of the patent is faily specific to forwarding between ports on such a device. I really don't think it can be said to generically cover generic layer-3+ packet filtering (in fact, I think it's pretty specifically layer-2ish).
Now, I'm not a lawyer, but I am a network engineer who deals with packet filtering all the time, and any "expert witness" worth his salt would bring these points up in a patent-suit. Someone should step up to be first on this one (Checkpoint or Cisco would be good choices, but there are many others who would be hurt by having to license this stuff).
On a more general point, I'm sure there are patents out there on just about everything that a modern Linux, BSD, etc system does. Some are already expired, but many are not. We really need to get a game plan here. My personal take is that patents are still a good thing, even on software, but it's the duration and disclosure that kill us. How can we reasonably get patent duration for software down to 2 years and require early disclosure of a pending patent? If those two things happened, patents would actually be a good thing for Open Source!
This patent claim was filed 4 October 1995.
I have a first edition copy of the book, D. Brent Chapman & Elizabeth D. Zwicky, _Building Internet Firewalls_ (Sevastopol, California: O'Reilly and Associates), dated September 1995. Thumbing thru it, I find chapter 6, which is titled ``Packet Filtering". ISTR that September is the month that preceeds October.
Since it takes about a year for a book to go from start of writing, thru production & at last release, I'd say Packet Filtering was a technology very familiar if not much used in late 1994.
Is that satisfactory evidence of prior art?
Geoff
I think I see a trend here. Maybe for them it really would be easier to muzzle the entire internet than to produce p
(* The patent might seem to own just about every conceivable way one might wish to filter and forward data packets, but trying to read through all of the "wherein said first condition" started to give me a headache *)
Laywers should learn how to clean up their source code.
For one, they should give clauses names or ID's. Then they can have phrases like:
"If ($trans and $horgton) or $rollsNice or $tamper5 or ($beforeExpire7 and $gasoline) then coveredUnderStateStatute("Nebraska", 43726)"
Table-ized A.I.
Patents aren't evil by nature. PKWare owns patents that cover the way the inflate/deflate alogrithms work. PKWare also put them in the public domain. Or the RTLinux patent. He wasn't served with papers or told to stop doing what he is doing. IPFilter isn't exactly an unknown piece of code either. I'd assume it's not a problem. Companies don't want to test patents like those becuase they lose all the marbles when they don't win in court.
I hereby patent the process in said application for said patent thereto and hereforth known as patent submission process where as there is a generally vague and ambiguous definition of said patentable process in said application of section 1 and hereto and thereto and whereto and whoto ad naseum carpe diem magna cum lauder and e pluribus unim.
I was using a Digital Equipment Corporation ethernet bridge in the late 80s which was able to selectively move packets from one port to another, by looking at the packets and determining if the destination ethernet address referenced in the packet was known on the network connected to by the second port.
There was also a way of loading configuration information into it to tell it whether to forward certain kinds of packets (multicast, most notably) or not. This sounds like a filter to me, in the definition of the patent.
I wrote ipfirewall, a packet filtering program for BSD/OS in 1993. I released my software via a mailing list (don't recall which one but I'm sure that I can find it) in about September of 1993. It was ported to Linux at around that time by Bob Beck and later by Ugen Antsilevich (Ugen's version is the one that made it into the Linux kernel distribution). The Linux variant was called ipfw. If you look in the kernel source code files netfilter/ipchains_core.c and netfilter/ipfwadm_core.c ipfw, you can still find my copyright:
Copyright (c) 1993 Daniel Boulet
ipfirewall v1.0 was also ported to NetBSD and FreeBSD. I also distributed ipfirewall v2.0 as a shareware product and as part of the Juniper Firewall Toolkit.
The patent is certainly valid but, don't panic just yet. This particular patent, though very general and broad scoped in nature, was actually filed to protect a very nice feature found in Bay / Nortel layer 2/3 and beyond switches. This feature has been in their switches since 1995 and possibly earlier and it allows for the routing/switching of packets based on a specified pattern match of ANY arbitrary portion of a FRAME. Note the specific reference to ATM?
Using this filtering method, you can switch/route a packet or frame from/to any port based on ANY part of the frame. If you wanted, for some bizzar reason, to make your decision based on the crc checksum you can do it. Also, because you are looking at the entire frame/packet, it is not specific to IP. You can filter/switch/route ANY protocol IP, IPX, HTTP, DECNet, APPN, anything. It is extraordinarily powerful, though infrequently used. But it is great to have when you need it. You can find it on most of their switches and routers from the BayStack 450 to the Bay BCN router to the Passport 8600 series layer 3 switches.
I do not feel that IPFilters needs to be concerned as this patent and could possibly be applied to ANY filtering tecnique in use today. Anything from MAC based port blocking to layer 7 web switching. However, even Bay/Nortel has notr choesen to challenge or attempt to enforce the patent on anyone so far.
As an interesting side note. Up until last year Nortel was filing and being awarded patents at a rate of two per day. They patented any and everything that they did. Hell, there is even a patent(not copyright) on a set of icons they designed for you on mobile phone type PDAs. That's right, a patent on a small set of crappy looking icons. Try doing a patent search with keyword Nortel. You'll be amazed.
When reading a patent such as this it's important to keep a few things in mind:
Ignore the abstract. It has no legal effect -- it is illustrative only. The abstract is often drafted by legal (but not technical) staff based on some summaries prepared by technical (but not "legal") staff. A lot is lost in the translation.
Ignore the summary -- skip to the claims. The most important part of a patent is the Claims section. Everything else is illustrative. The summary of the "present embodiment" (ie what was actually built) is only useful in so far as it gives you an idea of what the patentee is trying to protect. But you will almost always see that the claims are far wider and it is the claims that have legal effect.
Concentrate on the base claims. Almost all patents set out 3 or 4 "base claims". The rest of the claims will be derived claims -- they'll start with "The method set forth in claim X, where...". If a base claim is invalid (or not applicable to what you're doing) then all derived claims are also invalid. So, concentrate on them and try to find your points of difference there.
Claims repeat themselves. Generally, you'll find that the earlier base claims are narrow in scope. They'll then refine some of this in derived claims to make the application clearer or cover the most valuable applications of the invention. Then, a new base claim is started, with more generic language. That process tends to continue until the patent is very large. This is deliberate -- the patent attorney is trying to be as broad as possible, but if they're too broad, the patent will be invalid. So the strategy is to repeat the basic claims so that if a broad claim is struck down as invalid the narrower ones can still survive. If you don't infringe the narrowest patent you can often skip the broader claims. This one's a little different -- some of the claims cover different aspects of the "invention".
Get a lawyer if you're serious. A real lawyer properly briefed will do a better job than you're own analysis or general advice from others -- as Darren suggests.
Careful what you write. Finally, if you're doing some kind of patent analysis, never write "we infringe this" or "possible infringement." Instead, draw up two columns -- the list of patents you "do not infringe" (with reasons) and the list of patents "under investigation".
In this case, note that base claim 1 does not require type or offset. Derived claim 2 simply adds that as a possible variation. Like all patents it's difficult to read (it should be taken out back and shot) -- however, it does seem to envisage only a hub, depending on your definition of "destination node" and "destination port." I think claim 1 could be distinguished from IPfilter on that basis. It follows that claims 2 - 13 are also distinguishable and don't apply to IPFilter.
Claim 14 seems overly broad and relates to configuration of the invention under patent. Not easily dismissed based solely on the language of the claim though. Claims 15 - 21 are derived.
Claims 22 and 28 are problematic, and frankly, poorly drafted. 28 seems most likely to cause IPFilter grief, if it applies. But they're both (overly) broad and could be covered by prior art. These two claims need some careful analysis.
Basically, prior art is not the only way to show that you don't infringe a patent. Going the prior art route can require you to go to court to invalidate or modify the patent -- expensive proposition. It's cheaper and easier to invent around the patent by avoiding the base claims.
My two cents.
Linux is not a UNIX. Get used to it.
/proc filesystem, and I print from my WinNT box at work using enscript and lpr because the Solaris machines at work don't have enscript and I don't have root.
UNIX, much like pornography, has gone to a "I know it when I see it" thing.
From the strictest view, one might consider the only UNIX OpenUNIX from Caldera. This is where the UNIX brand name has finally ended up (ATT -> Novell (strangely enough) -> SCO -> caldera). It may die there, caldera's in bad shape. OpenUNIX is changing, becoming very Linux friendly.
Almost all UNIXes (Unices?) have a Linux compatibility layer in the kernel. So Linux is becoming the one all encompassing API, if not the one true UNIX.
UNIX came out of AT & T, back when UNIX was still a research project and they were friendly with educational institutions. BSD was a fork. SVR4 UNIX, the most common "base" variant was basically SVR3 with BSD stuff. FreeBSD/NetBSD takes on the spirit of that work. Is FreeBSD UNIX?
Darwin, The base of MacOS is a Mach Microkernel with FreeBSD/NetBSD. It will be the most distributed "UNIX" ever. Is MacOS UNIX? it's very NeXT based, which was a bastard offshoot.
Linux works like UNIX, has the same design philosophy. Is the only UNIX some folks will ever touch. You have weird hybrids of SVR4/BSDlike systems depending on where Linus and the Distro guys picked and choosed stuff.
I have Cygwin on my Win2000 box. I use a bash shell, have rlogin, gcc tools. Is Win200 Linux? I even have a
Hmm, is POSIX compliance mean UNIX? POSIX was supposed to be the one true UNIX standard. If so than the most POSIX OS is WinNT. MS had a POSIX subsystem, never really worked but was needed to satisfy government regs on OS purchasing. MS WinNT was the only OS ever to get POSIX certified, so it's the one true UNIX, from a point of view.
Don't call folks stupid on things that are just interpretation. I can say OpenUNIX, the *BSD's, or WinNT the only UNIX, depending on what my criterea are. Sayig your interpretation is the only one is just trolling for a flamewar.
I can only confirm everything said in the previous posting.
I've been working with Ugen Antsilevich on the
FreeBSD port of the ipfw in 1992-1993 at Technion,
Israeli Institute of Technology.
Initial version was indeed based on Daniel's BSD/OS version, but was later almost completely redesigned.
The functionality and architecture of the ipfw very much resembles that of the ipfilter, so the claims by Bay seems ridiculous.
Gennady Sorokopud
The key thing is that a court might in future decide that some claims are valid but others are not. So the first couple of claims in a patent might well lay claim to the entire state of the art, and might only be there as a kind of #define macro for subsequent claims. I once read an encryption patent (ISTR it was for a DVD system that didn't get used) where Claim 1 was for XORing the output of a random number generator with the cleartext. This was followed by a series of claims that started "A system as in Claim 1 where the random number generator is...".
So when you see a patent that seems to claim the whole of some technology, don't panic. There is going to be tons of prior art. You just have to work out where the prior art ends and the real invention starts. This is going to be a bit grey on the boundary (thats where patent lawyers make their money), but you can still get a fairly clear idea pretty quickly. You can also get a fair idea just by looking at the claims and thinking about the technology they represent. Once you get to precise descriptions of obscure algorithms then you are into the meat of the patent.
Incidentally, don't be scared of legalese. Just think of it as an unusually verbose and unstructured programming language.
Paul.
You are lost in a twisty maze of little standards, all different.
If a base claim is invalid (or not applicable to what you're doing) then all derived claims are also invalid. So, concentrate on them and try to find your points of difference there.
This is not generally true, and often false. The dependent (you called them derived) claims include all the limitations of their parent independent (you called them base) claims. For this reason, if the parent independent is NOT INFRINGED (because one or more limitation is not present in the accused), the dependent claims are not infringed. (There is an obscure exception to this rule, but it holds almost always).
The converse is not generally true. If a parent claim for A+B+C IS INFRINGED, the dependent claim for A+B+C+D might not be infringed by an accused device with A, B and C, but no D. For similar resons, the corresponding proposition for validity is NOT generally true.
A parent claim for A+B+C can read on a piece of prior art, while one of its dependents for A+B+C+D might not, because the dependent claim could have one or more additional limitations, in this case D, that are not disclosed in the prior art. This happens all the time -- invalidating the broad claim does not put an end to the case if the dependent claims are also infringed.