Google was bashed for taking so long to respond, and for not backing their developers on the cases, etc. It turns out, they were taking their time preparing to fight the patents and invalidate them, and in the end, it may be their attack on the patents themselves that saves the day for developers on all platforms.
"Based on our calculations, it takes more than 3 ½ years (43.5 months) for the average case to proceed through the basic reexam process to a final conclusion... A 95% confidence interval suggests an average pendency for appealed cases (again, assuming no rework) is between 5 and 8 years" http://271patent.blogspot.com/2008/05/another-critical-study...
This is to the point where I'm not sure the courts take reexaminations seriously as a defense. In the handful of patent cases I've paid attention to, the fact that a patent was initially rejected in a reexamination had little impact on how the court proceeded with a case. While it's possible the USPTO will fast track this particular case, if I was a developer currently being sued I would not have any confidence that the USPTO will bring any relief before I was due in court.
That generally depends in part on how far along the court case is when the reexamination request is filed.
On one hand, federal judges want to keep their cases moving; they themselves are judged by the peers (reputationally only; they have life tenure) in part by their average time to final disposition. If an accused infringer files a reexamination request in the USPTO just as its infringement case is about to go to trial, the chances are the judge might order the trial to proceed anyway.
On the other hand, a reexamination proceeding could make a case go away, or even just narrow the triable issues significantly. That would free up the judge and his or her law clerks to work on other cases.
And random factors can make a difference. I once had a judge fast-track a patent case about programmable thermostats. He did so because one of his law clerks that year had his undergraduate degree in electrical engineering. The judge wanted to finish the case while that law clerk was still around to help him. The law clerk informed me and the other side of this at the first case management conference; he also noted for the record that my law firm had turned him down the previous year when he applied for a job with us; ouch .... (The case settled soon afterwards for unrelated reasons.)
EDIT: thinking more about this, what if you pushed/popped them with a stack, or FIFO'd them with a queue. Seems there are various ways around the increment semantics.
[1] http://en.wikipedia.org/wiki/Doctrine_of_equivalents
* I am not your lawyer, get a lawyer, etc.
Unfortunately, it sounds like Lodsys still has most of what it needs to lean on the indie developers - the fact that the devs simply can't afford to pay for defense.
1. A device for transportation consisting of two
wheels joined by a frame on which one or more
passengers sit.
2. The device of claim 1 where one of the wheels is in
the front of the vehicle and one of the wheels is in the
back of the vehicle.
Here's an example of a dependent claim depending on another dependent claim:
3. The device of claim 2 where the front wheel is mounted
in a turnable fork for steering the vehicle.It's very common in patents to only really have invented the last claim - all the previous claims are thrown out but the last one stands. It's partly an easy way of getting all your points across logically and partly a tactic of having some ground to give up in a legal battle
> 2. The unit of claim 1, wherein the input reflects a request to schedule maintenance.
An "independent claim" is one that doesn't. E.g.
> 1. A unit, comprising: a memory; a transmitter; and a processor, coupled to the memory and to the transmitter, [...] an input received from the user interface
It's a forest, the roots are independent claims (no parent), all the rest are dependent (have a parent). Um... I don't know if it's allowed for a claim to depend on more than one claim (i.e. have more than one parent; multiple inheritance), but I've never seen one. Cycles are right out.
(example are from the patent in question: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec...)
Sort of, but probably not in the way you're thinking. You can write multiple dependent claims (although they are generally disfavored in the U.S. and cost extra in fees). But say you have something like this:
What is claimed is:
1. A chair comprising a seat and a plurality of legs.
2. The chair of claim 1, wherein said plurality of legs comprises four legs.
3. The chair of any preceding claim, wherein said seat is made of plastic.
So claim 3 is a multiple dependent claim, but the way it would be interpreted is basically as having the scope as if it were written as two separate claims: one depending from claim 1 (thus covering any chair with a plastic seat and some legs), and one depending from claim 2 (thus covering any chair with a plastic seat and four legs). So it's just a concise way of writing something that would logically expand into more than one claim, which isn't really the same thing as multiple inheritance in programming.