Decided October 1, 2009
(Appeal 2008-000693, Appl. No. 10/132,492, Tech. Center 2100)
This case involved four different sets of claims: apparatus claims; means-plus-function claims; method claims; and computer-readable medium claims. The technology related to verification of hardware components, using software running on a computer.
All claims were rejected by the Examiner under §102(b). Without reaching the merits of the Examiner's rejection, the Board entered new grounds of rejection for each of the claim sets:
- means-plus-function claims: rejected under §112 Second, following the rationale set out in Aristocrat v. Inter. Game Tech.
- apparatus claims: found to be means-plus-function claims and also rejected under §112 Second, following Aristocrat.
- apparatus claims: alternatively, if not considered to be means-plus-function, rejected under §112 First, enablement.
- method claims and computer-readable medium claims: rejected under §112 First, enablement.
If the Patent Office issues guidelines based on this decision, I predict Ex parte Rodriguez will have a big impact on practitioners that prosecute "software" applications. Method claims have already hit a roadblock with 101/Bilski, but Bilski itself doesn't suggest its application to other claim types. This decision, on the other hand, applies to method claims – possibly even those that pass the Bilski test – and most of the other claim types that are used cover software implementations. The only claim type that isn't directly implicated by this decision appears to be a processor-plus-memory claim.
Although the four new rejections were each slightly different, all are based on the same underlying facts: the claims contained very little structure and instead relied almost completely on functional language; and the specification contained very little detail about how to implement the functions. Therefore, the patent applications that will be most affected by Ex parte Rodriguez are ones that fit this fact pattern.
In this post, I'll discuss how those facts played out in Ex parte Rodriguez in the rejections of the means-plus-function and apparatus claims. In a future post, I'll discuss the rejection of the method and computer-readable-medium claims.
Means-plus-function claims: The specification stated that the various claimed functions could be implemented by a "conventional general purpose digital computer," and also said "appropriate software coding can readily be prepared by skilled software programing." However, the Board found that no specific description of how to generate a system configuration file was provided.
Whenever a general purpose computer is disclosed as the means for implementing a function, an algorithm to implement that function must also be disclosed. This rule – essentially saying that an algorithm serves as the "structure" – was recently set out by the Federal Circuit in Aristocrat, although Aristocrat followed precedent set way back in 1999 by WMS Gaming. Because the spec disclosed no such algorithm, the Board found the means-plus-function claims to be indefinite.
Apparatus claims treated as means-plus-function: An example limitation in the independent apparatus claim is: "a system configuration generator configured to generate a random system configuration file of a structurally variable and complex system." Even though the magic word "means" was not present, this limitation (as well as each of the others) was still subject to §112 ¶6 because the Board found no evidence that the terms in question (e.g. "system configuration generator") connoted structure. Having determined that the apparatus claims were really means-plus-function in disguise, the Board then repeated the Aristocrat analysis set out above to find the claims indefinite.
Apparatus claims treated as NON-means-plus-function: If the apparatus claims did not fall under §112 ¶6, the Board found that these claims were invalid for lack of enablement "because the claim elements are purely functional (i.e., there is no particular structure to support the function being performed)." (Decision, p. 28.) To hold otherwise would allow the claim to "encompass any and all structures for achieving that result, including those which were not what the applicant had invented." (Decision, p. 30.) "Congress permitted [through §112 ¶ 6] the use of purely functional language in claims, but it limited the breadth of such claim language by restricting its scope to the structure disclosed in the specification and equivalents thereof." (Decision, pp. 30-31, quoting Greenberg v. Ethicon, Fed. Cir. 1996.)
The Board found that the "system builder" limitation covered any and all structures that performed the recited function. Since "any and all structures" included ones not described in the specification, the Board then entered an enablement rejection for the apparatus claims.
Method and computer-readable-medium claims: I'll discuss these in a future post.
So Aristocrat says that the spec must have an example algorithm to provide enablement for functional language in claims? There will be thousands of worthless software applications, then. It doesn't make sense at all, because then in the means plus function claims, which, at least in this case, the Examiner read even the apparatus claims as such, are you tied to that one algorithm in the spec. That's the reason we've rarely put algorithms in software specs - one of ordinary skill in the art can come up with several algorithms to perform a particular function. And enablement only requires that one of ordinary skill in the art can implement the invention without undue experimentation. See MPEP 2164.01.
ReplyDelete>Aristocrat says that the spec must have an >example algorithm
ReplyDeleteYes, that's exactly what Aristrocrat said (citing the 1997 decision WMS Gaming).
>to provide enablement for functional language
>in claims?
Nah, it's separate from enablement. The rejection is Indefiniteness.
>And enablement only requires that [a POSITA]
>can implement the invention without undue >experimentation.
Agreed. But 112P6 includes requirements *separate from* enablement: you can write shorthand claims with reference to function as long as you tie that function to structure described in the spec.
Unfortunately the Federal Circuit decided in its infinite wisdom that in the context of a function implemented by a computer, the "structure" is AN ALGORITHM. [I won't even get started on how stupid that sounds to a former software developer like myself...]
>[POSITA] can come up with several algorithms
>to perform a particular function.
Indeed. And your method claim -- if you can get past 101/Bilski -- covers all of them. But your M+F does not.
For example, "sorting the results by score" covers a myriad of sorting algorithms known to a POSITA (bubble sort, quick sort, etc. etc.)
but "means for sorting the results by score" is INVALID if you didn't describe an algorithm for doing this and LIMITED TO the algorithm if you did. As well as the algorithm's equivalents, as specifically provided for in 112P6.
I don't recall a single Fed Cir decision where a software M+F claim was found Valid. Plenty of invalid ones: Aristocrat v. Int'l Gaming; Finistar v. DirecTV; Net MoneyIn v. Verisign; and Blackboard v. Desire2Learn.
The requirement for an example algorithm can be a mathematical formula, detailed flow chart, psuedocode, or source code.
ReplyDeleteThere are plenty of "system" claims reciting "_____ing modules" as elements that will be interpreted as "means plus function" claims. I've written many of them myself, but I am not concerned that any of them will be found lacking a disclosed algorithm because of the detailed flow diagrams that were provided. I'm not happy about the loss of future structural equivalents due to the "means plus function" interpretation, or how that will impact their value. "Worthless?"
broje TINLA IANYL
Broje, great to have you as a contributor.
ReplyDelete>not concerned about lacking an algorithm
>because of the detailed flow diagrams
Are you sure about that? Suppose your claim has 3 M+F elements: MF Xing; MF Ying; and MF Zing. Then under Rodriguez, it's absolutely *not* enough that you have a flow chart with steps X, Y, and Z.
Instead, Rodriguez says should have a flow chart for X, another for Y, and another for Z. Or a single flow chart with multiple steps for X, multiple steps for Y and multiple steps for Z. Or no flow chart at all, but some other sort of description. The important thing being that you describe details of how each claimed function is implemented.
Such details may add no value whatsoever in explaining how the system works. For example, suppose my claim is:
a) MF multiplying a first factor by a second factor to produce a product;
b) MF inserting the product into a list;
c) MF sorting the list;
Under Rodriguez, I have to show an ALGORITHM for multiplying and another ALGORITHM for inserting into a list and another ALGORITHM for sorting the list.
Ridiculous.
>not happy about the loss of future structural
ReplyDelete>equivalents due to the "means plus function"
>interpretation
Are you referring to the "after arising equivalents" rule from Chiuminnata? That rule limits only literal infringement under 112P6. Infringement under DoE is still available if you lose on already-existing-equivalents analysis of literal infringement. See Al-Site Corporation v. Vsi International Inc 174 F3d 1308.