The Board found no conflict, reasoning that: "[if] i is at least occasionally greater than one (as claim 1 requires), it is therefore possible that i could be invariant (as claim 2 requires), and always be equal to two, or three, or any other integer greater than one, without doing violence to the requirement of claim 1."
Ex parte Giacomini
Appeal 200900139, Appl. No. 09/725,7371, Tech. Center 2600
Decided April 15, 2009
The subject matter of the application was web servers. The claims were directed to populating a web cache with resources. One of the issues on appeal was an enablement rejection of dependent claim 2. That claim, and it's parent claim, are shown below, with the relevant language emphasized.
1. A method comprising: populating a cache with a resource only when at least i requests for said resource have been received; wherein i is an integer and is at least occasionally greater than one.
2. The method of claim 1, wherein the value of i is invariant.The Examiner contended that the dependent limitation "i is invariant" conflicted with the independent limitation "[i] is at least occasionally greater than one." In other words, the independent claim recited that i varies, yet the dependent claim recited that i does not vary. The Examiner therefore alleged that the dependent claim was not enabled, since the specification did not describe how to make and use an embodiment in which i was both variable and invariant.
The Board determined that the discrepancy was not a conflict after all because the two limitations captured different embodiments. Referring to teachings in the spec, the Board found that in one embodiment, i varies with time of day, the day of the week, etc. In another embodiment, the value of i does not change over time or as a function of circumstance. The Board then reasoned that:
If i is at least occasionally greater than one (as claim 1 requires), it is therefore possible that i could be invariant (as claim 2 requires), and always be equal to two, or three, or any other integer greater than one, without doing violence to the requirement of claim 1.My two cents: First of all, it seems weird to me that the Examiner issued an enablement rejection. I think an indefiniteness rejection is more appropriate, i.e., I can't tell what the claims mean because two limitations are in conflict with each other.
But the underlying issue is the same whether you couch it in terms of enablement or indefiniteness: how to reconcile a limitation that effectively requires i to vary with another limitation that explicitly requires i to be invariant.
The Board reconciles this by saying that "i is at least occasionally greater than 1" does not in fact require i to vary. The Board's logic has a sort of intuitive appeal. For any particular embodiment, i is either variable or fixed. The independent claim is written to cover both. The dependent claim covers fixed only. I'm on the fence as to whether I think the Applicant was clever and the Board got it right, or the Applicant was too clever and the Board got it wrong.
But forget about the dependent claim. Why didn't the Board issue a new indefiniteness rejection for the independent claim? What does "occasionally greater than one" mean? Consider a method that populates after i=2 requests. Two is definitely greater than one. So whether this method infringes seems to depend on how often the cache is populated after 2 requests. If your method always populates after 2 requests, then are you infringing? Since "always" means i is "invariant", and 2 > 1, this behavior definitely reads on dependent claim 2.
But does this same behavior read on "i is occasionally greater than 1"? I don't know. I don't really know how to parse that. But let's say it does. Let's say that "always > 1" satisfies "occasionally > 1".
But that's the easy case. Consider another method that doesn't always populate after 2 requests, but varies its behavior in some manner, such as time of day. [That's exactly what the claim covers, and what the application describes.] Suppose that when run during a particular time period, under a particular set of 100 inputs, the method populates the cache after 2 requests 90 times, and populates after 1 request 10 times. Does this behavior read on "i is occasionally greater than 1"? That is, does "90% of the time" read on "occasionally"?
You can see where I'm going with this ... does "10% of the time" read on "occasionally"? Where do you draw the line? This is probably the most difficult-to-parse claim that I've run across in a long time.
Related posts: If the name Giacomini sounds familiar, it may be because the Applicant was involved in the Federal Circuit decision In re Giacomini, which involved using the provisional date as the effective filing date of a reference under 102(e). I blogged about that here and here.