Enablement rejection when problem is complex and disclosure is short

An earlier post introduced Ex parte Rodriguez and discussed the Board's rejection of means-plus-function and apparatus claims. In this post, I'll cover the Board's enablement rejection of the method and computer-readable medium claims.

A claim is enabled when the specification allows a POSITA to "make and use" the claimed invention. Many Examiners and practitioners — and even some BPAI decisions — talk about enablement in terms of "support in the spec." This case is interesting because it uses the proper standard for determining whether claim are enabled: viewing the specification in light of the "Wands factors":

(1) the quantity of experimentation necessary; 
(2) the amount of direction or guidance presented;
(3) the presence or absence of working examples;
(4) the nature of the invention;
(5) the state of the prior art;
(6) the relative skill of those in the art;
(7) the predictability or unpredictability of the art; and
(8) the breadth of the claim.

Even if you've never seen this list before, you can probably guess how the factors work. For example, a spec with working examples (3) balances against unpredictable technology (7), and more disclosure (2) balances against complex technology (5).

The Board found that the three Wands factors relating to the Applicant's spec went against the Applicant:

(1) "the quantity of experimentation necessary" is high;
(2) "the amount of direction and guidance presented" by Appellants is minimal;
(3) there are no "working examples" presented by Appellants in their Specification;
(Decision, p. 42.)

Basically, the Board considered this to be a skimpy disclosure. There are a total of three figures. FIG. 2 is the block diagram that shows the most detail:

FIG. 3 is the only flow chart:

The flow chart doesn't have more than a single block for each step in the independent method claim:

11. A method for automated random verification of structurally variable and complex systems, comprising the steps of:
(A) generating a random system configuration file of said system;
(B) generating one or more parameters of said system in response to said random system configuration file;
(C) generating a system level netlist of said system in response to said random system configuration file;
(D) verifying one or more target modules with said system in response to said system level netlist; and
(E) automatically and randomly adjusting step (D) in response to said random system configuration file.

In the enablement rejection, the Board focused on the disclosure of steps B and C. According to the Summary of Claims in the Appeal Brief, steps B and C correspond to states 208 and 210 in the flowchart, and these steps are performed by the system builder (104 in FIG. 2). However, the Board did not find in the spec any description of how the parameters and netlist were generated.

The spec described, in general terms, what the generated parameters were: system parameters for a particular configuration of the system-under-test. The spec also described the input from which the parameters were generated: a configuration file which described the system in terms of bus functional models, target modules, and their respective interconnections. However, the Board found this basic description of input and output was all that was disclosed.

The spec contained even less detail for step C. The Board noted that the spec did not describe a netlist, but found that a netlist was known in the art to be a data structure which defines connectivity between pins of the various cells of an integrated circuit design. Even so, the Board found that the spec did not describe how to generate the system parameters or the netlist from the claimed inputs:

The Specification does not disclose any specific algorithm that could be implemented on a general purpose computer to provide automated random verification of complex and structurally variable systems." More particularly, Appellants' disclosure lacks even a single embodiment showing how to implement the "system builder" and steps (B) and (C).
(Decision, p. 41.)

Theoretically, a skimpy spec can be outweighed by other factors. Unfortunately, the skimpy spec also included a few statements that went against the Applicant: "factor (4) the nature of the invention" is highly complex as shown by Appellants' description of the significant prior art failings [in the Background] and Appellants' indications [in the Background] that their invention will overcome these failings." (Decision, p. 42.)

Also, factor (8) went against the Applicants: " 'the breadth of the claims" is very broad as it encompasses every way of accomplishing the "generating" results of steps (B) and (C)." (Decision, p. 42.)

The remaining factors were all favorable to the Applicant —less disclosure is required for predictable, well-developed, low-skilled technology:

(5) "the state of the prior art" is well developed as shown by the [reference which we rely on for the meaning of "netlist"];
(6) Appellants contend (without further support) that "the relative skill of those in the art" is high (see Finding of Fact 11 [statement in the spec that functions may be implemented using a conventional computer programmed "according to the teachings of the present specification, as will be apparent to those skilled in the relevant art(s)];
(7) Appellants also contend (without further support) that "the predictability of the art" is above average (see Finding of Fact 12 [statement in the spec that appropriate programming can be applied by programmers "based on the teachings of the present disclosure, as will also be apparent to those skilled in the relevant art(s)."])
(Decision, p. 42.)

When all the factors were considered, the Board found that the method claims were not enabled by the spec. And because the computer-readable medium claims included exactly the same functional language, the same finding applied to those claims as well.

Though the Board considered all the Wands factors, I believe the broad claims and skimpy disclosure were dispositive. Applicant's statement in the Background which described the problem as "complex" was the final nail in the coffin.

The Board strongly criticized the spec for not including "working examples." Unfortunately, the Board did not give any guidance as to what would serve as a "working example" in a software application. Is source code expected? Flow charts for every function? Are block diagrams not enough – or are block diagrams okay if more detail is provided?

I don't know much about this particular area of technology (verification of hardware using software). My sense from having read the spec and file history is that the "system builder" component which the Board focused on – and which had the least detail in the spec – was not the innovative feature. The word "random" appears a lot, and I wonder if the innovation has to do with mixing up the models that are used as input in a random way. If so, perhaps the Applicant could have avoided an enablement rejection by providing more details about the randomization feature. Then if an enablement rejection appeared, the Applicant could offer declaration evidence that a POSITA knows how to generate a netlist from a basic configuration file, and that this basic knowledge coupled with details about the randomizing are enough to practice the method claims.