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?""
Keep in mind, ALL of a patent's claims must apply to your invention. If a single one isn't a match, then you are free of the entire patent.
IANAL.
Filters may be configured on a per port basis, i.e., a filter can be applied to data packets entering or exiting a specific port on a networking device such as a LAN switch
The patent seems to be specific to network switching/routing hardware based solutions, not software based. IANAL, but it could be shown that the intent that Bay had was to do packet level filtering inside of switches on a port-to-port basis (as some of their hardware, like the Accelar series does), and not on a software-ontop-of-an-OS basis as this shows
Referring to FIG. 1, a network device 100 as may be utilized by an embodiment of the present invention is shown. Network device 100 is a LAN switch, however, it is understood by those of ordinary skill in the art that an embodiment of the present invention may be applied to other network devices such as a hub or bridge.
If I'm wrong, then a lot more than IPFilter is in trouble... Checkpoint and Raptor (now Symantec) better watch out!.
Sig (appended to the end of comments you post, 120 chars)
Instead, let patent applicants put up a, say, $5K bond with their application. The patent office makes no attempt to validate the patent (just as presently, you might say :) but merely publish it.
Then, if someone finds any prior art, let them forward it to the patent office to examine it. Then the patent office makes a judgement, pays the bond across to the finder, and marks the patent as cancelled. Interested parties (those suckered into paying licensing fees) get notified by email alert.
Perhaps this would generate a thriving third world industry of people frantically chopping down many of the stupid patents which currently get issued.
Before complaining that putting up $5K would stifle creativity for the small guy, consider whether the current state of affairs actually works in the little guy's behalf or not...
[x] auto-moderate all posts by this user as insightful
Of course, unlike trademarks, the risk that they will try to enforce it remains throught the life of the patent. However, if it really worries you, you can have the patent reexamined or get a declaratory judgement.
It doesn't really matter if they exist anymore or not. Nortel bought all the intelectual properties so now the problem goes to Nortel and beyond.
Screend has roots dating back to 1989.
Check DEC resources or maybe vix.com.
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.
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.
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
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.