Go to MPEP - Table of Contents
2164.06(c) Examples of Enablement Issues - Computer Programming Cases [R-5] - 2100 Patentability
2164.06(c) Examples of Enablement Issues - Computer Programming Cases [R-5]
To establish a reasonable basis for questioning the adequacy of a disclosure, the examiner must present a factual analysis of a disclosure to show that a person skilled in the art would not be able to make and use the claimed invention without resorting to undue experimentation.
In computer applications, it is not unusual for the claimed invention to involve two areas of prior art or more than one technology, e.g., an appropriately programmed computer and an area of application of said computer. White Consol. Indus. v. Vega Servo-Control, Inc., 214 USPQ 796, 821 (S.D.Mich. 1982). In regard to the "skilled in the art" standard, in cases involving both the art of computer programming, and another technology, the examiner must recognize that the knowledge of persons skilled in both technologies is the appropriate criteria for determining sufficiency. See In re Naquin, 398 F.2d 863, 158 USPQ 317 (CCPA 1968); In re Brown, 477 F.2d 946, 177 USPQ 691 (CCPA 1973); White Consol. Indus., 214 USPQ at 822, aff'd on related grounds, 713 F.2d 788, 218 USPQ 961 (Fed. Cir. 1983).
In a typical computer application, system components are often represented in a "block diagram" format, i.e., a group of hollow rectangles representing the elements of the system, functionally labeled, and interconnected by lines. Such block diagram computer cases may be categorized into (A) systems which include but are more comprehensive than a computer and (B) systems wherein the block elements are totally within the confines of a computer.
I. BLOCK ELEMENTS MORE COMPREHENSIVE THAN A COMPUTER
The first category of such block diagram cases involves systems which include a computer as well as other system hardware and/or software components. In order to meet his or her burden of establishing a reasonable basis for questioning the adequacy of such disclosure, the examiner should initiate a factual analysis of the system by focusing on each of the individual block element components. More specifically, such an inquiry should focus on the diverse functions attributed to each block element as well as the teachings in the specification as to how such a component could be implemented. If based on such an analysis, the examiner can reasonably contend that more than routine experimentation would be required by one of ordinary skill in the art to implement such a component or components, that component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112, first paragraph rejection. Additionally, the examiner should determine whether certain of the hardware or software components depicted as block elements are themselves complex assemblages which have widely differing characteristics and which must be precisely coordinated with other complex assemblages. Under such circumstances, a reasonable basis may exist for challenging such a functional block diagram form of disclosure. See In re Ghiron, 442 F.2d 985, 169 USPQ 723 (CCPA 1971) and In re Brown, supra. Moreover, even if the applicant has cited prior art patents or publications to demonstrate that particular block diagram hardware or software components are old, it should not always be considered as self-evident how such components are to be interconnected to function in a disclosed complex manner. See In re Scarbrough, 500 F.2d 560, 566, 182 USPQ 298, 301 (CCPA 1974) and In re Forman, 463 F.2d 1125, 1129, 175 USPQ 12, 16 (CCPA 1972). Furthermore, in complex systems including a digital computer, a microprocessor, or a complex control unit as one of many block diagram elements, timing between various system elements may be of the essence and without a timing chart relating the timed sequences for each element, an unreasonable amount of work may be required to come up with the detailed relationships an applicant alleges that he or she has solved. See In re Scarbrough, 500 F.2d at 566, 182 USPQ at 302.
For example, in a block diagram disclosure of a complex claimed system which includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a prior art, commercially available microprocessor, without any description of the precise operations to be performed by the microprocessor, fails to disclose how such a microprocessor would be properly programmed to either perform any required calculations or to coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If, in such a system, a particular program is disclosed, such a program should be carefully reviewed to ensure that its scope is commensurate with the scope of the functions attributed to such a program in the claims. See In re Brown, 477 F.2d at 951, 177 USPQ at 695. If the disclosure fails to disclose any program and if more than routine experimentation would be required of one skilled in the art to generate such a program, the examiner clearly would have a reasonable basis for challenging the sufficiency of such a disclosure. The amount of experimentation that is considered routine will vary depending on the facts and circumstances of individual cases. No exact numerical standard has been fixed by the courts, but the "amount of required experimentation must, however, be reasonable." White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963. One court apparently found that the amount of experimentation involved was reasonable where a skilled programmer was able to write a general computer program, implementing an embodiment form, within 4 hours. Hirschfield v. Banner, 462 F. Supp. 135, 142, 200 USPQ 276, 279 (D.D.C. 1978), aff'd, 615 F.2d 1368 (D.C. Cir. 1986), cert. denied, 450 U.S. 994 (1981). Another court found that, where the required period of experimentation for skilled programmers to develop a particular program would run to 1 to 2 man years, this would be "a clearly unreasonable requirement" (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).
II. BLOCK ELEMENTS WITHIN A COMPUTER
The second category of block diagram cases occurs most frequently in pure data processing applications where the combination of block elements is totally within the confines of a computer, there being no interfacing with external apparatus other than normal input/output devices. In some instances, it has been found that particular kinds of block diagram disclosures were sufficient to meet the enabling requirement of 35 U.S.C. 112, first paragraph. See In re Knowlton, 481 F.2d 1357, 178 USPQ 486 (CCPA 1973), In re Comstock, 481 F.2d 905, 178 USPQ 616 (CCPA 1973). Most significantly, however, in both the Comstock and Knowlton cases, the decisions turned on the appellants' disclosure of (A) a reference to and reliance on an identified prior art computer system and (B) an operative computer program for the referenced prior art computer system. Moreover, in Knowlton the disclosure was presented in such a detailed fashion that the individual program"s steps were specifically interrelated with the operative structural elements in the referenced prior art computer system. The court in Knowlton indicated that the disclosure did not merely consist of a sketchy explanation of flow diagrams or a bare group of program listings together with a reference to a proprietary computer in which they might be run. The disclosure was characterized as going into considerable detail in explaining the interrelationships between the disclosed hardware and software elements. Under such circumstances, the Court considered the disclosure to be concise as well as full, clear, and exact to a sufficient degree to satisfy the literal language of 35 U.S.C. 112, first paragraph. It must be emphasized that because of the significance of the program listing and the reference to and reliance on an identified prior art computer system, absent either of these items, a block element disclosure within the confines of a computer should be scrutinized in precisely the same manner as the first category of block diagram cases discussed above.
Regardless of whether a disclosure involves block elements more comprehensive than a computer or block elements totally within the confines of a computer, USPTO personnel, when analyzing method claims, must recognize that the specification must be adequate to teach how to practice the claimed method. If such practice requires a particular apparatus, then the application must provide a sufficient disclosure of that apparatus if such is not already available. See In re Ghiron, 442 F.2d 985, 991, 169 USPQ 723, 727 (CCPA 1971) and In re Gunn, 537 F.2d 1123, 1128, 190 USPQ 402, 406 (CCPA 1976). When USPTO personnel question the adequacy of computer system or computer programming disclosures, the reasons for finding the specification to be nonenabling should be supported by the record as a whole. In this regard, it is also essential for USPTO personnel to reasonably challenge evidence submitted by the applicant. For example, in In re Naquin, supra, an affiant's statement that the average computer programmer was familiar with the subroutine necessary for performing the claimed process, was held to be a statement of fact as it was unchallenged by USPTO personnel. In other words, unless USPTO personnel present a reasonable basis for challenging the disclosure in view of the record as a whole, a 35 U.S.C. 112, first paragraph rejection in a computer system or computer programming application may not be sustained on appeal. See In re Naquin, supra, and In re Morehouse, 545 F.2d 162, 165-66, 192 USPQ 29, 32 (CCPA 1976).
While no specific universally applicable rule exists for recognizing an insufficiently disclosed application involving computer programs, an examining guideline to generally follow is to challenge the sufficiency of such disclosures which fail to include either the computer program itself or a reasonably detailed flowchart which delineates the sequence of operations the program must perform. In programming applications where the software disclosure only includes a flowchart, as the complexity of functions and the generality of the individual components of the flowchart increase, the basis for challenging the sufficiency of such a flowchart becomes more reasonable because the likelihood of more than routine experimentation being required to generate a working program from such a flowchart also increases.
As stated earlier, once USPTO personnel have advanced a reasonable basis or presented evidence to question the adequacy of a computer system or computer programming disclosure, the applicant must show that his or her specification would enable one of ordinary skill in the art to make and use the claimed invention without resorting to undue experimentation. In most cases, efforts to meet this burden involve submitting affidavits, referencing prior art patents or technical publications, presenting arguments of counsel, or combinations of these approaches.
III. AFFIDAVIT PRACTICE (37 CFR 1.132)
In computer cases, affidavits must be critically analyzed. Affidavit practice at the outset usually involves analyzing the skill level and/or qualifications of the affiant, which should be of the person of ordinary skill in the art (hereinafter "routineer"). When an affiant's skill level is higher than that required by the routineer for a particular application, an examiner may challenge the affidavit since it would not be made by a routineer in the art, and therefore would not be probative as to the amount of experimentation required by a routineer in the art to implement the invention. An affiant having a skill level or qualifications above that of the routineer in the art would require less experimentation to implement the claimed invention than that for the routineer. Similarly, an affiant having a skill level or qualifications below that of the routineer in the art would require more experimentation to implement the claimed invention than that for the routineer in the art. In either situation, the standard of the routineer in the art would not have been met.
In computer systems or programming cases, the problems with a given affidavit, which relate to the sufficiency of disclosure issue, generally involve affiants submitting few facts to support their conclusions or opinions. Some affidavits may go so far as to present conclusions on the ultimate legal question of sufficiency. In re Brandstadter, 484 F.2d 1395, 179 USPQ 286 (CCPA 1973), illustrates the extent of the inquiry into the factual basis underlying an affiant's conclusions or opinions. In Brandstadter, the invention concerned a stored program controller (computer) programmed to control the storing, retrieving, and forwarding of messages in a communications system. The disclosure consisted of broadly defined block diagrams of the structure of the invention and no flowcharts or program listings of the programs of the controller. The Court quoted extensively from the Examiner's Office Actions and Examiner's Answer in its opinion where it was apparent that the Examiner consistently argued that the disclosure was merely a broad system diagram in the form of labelled block diagrams along with statements of a myriad of desired results. Various affidavits were presented in which the affiants stated that all or some of the system circuit elements in the block diagrams were either well-known in the art or "could be constructed" by the skilled design engineer, that the controller was "capable of being programmed" to perform the stated functions or results desired, and that the routineer in the art "could design or construct or was able to program" the system. The Court did consider the affiants' statements as being some evidence on the ultimate legal question of enablement but concluded that the statements failed in their purpose since they recited conclusions or opinions with few facts to support or buttress these conclusions. With reference to the lack of a disclosed computer program or even a flowchart of the program to control the message switching system, the record contained no evidence as to the number of programmers needed, the number of man-hours and the level of skill of the programmers to produce the program required to practice the invention.
It should be noted also that it is not opinion evidence directed to the ultimate legal question of enablement, but rather factual evidence directed to the amount of time and effort and level of knowledge required for the practice of the invention from the disclosure alone which can be expected to rebut a prima facie case of nonenablement. See Hirschfield, 462 F. Supp. at 143, 200 USPQ at 281. It has also been held that where an inventor described the problem to be solved to an affiant, thus enabling the affiant to generate a computer program to solve the problem, such an affidavit failed to demonstrate that the application alone would have taught a person of ordinary skill in the art how to make and use the claimed invention. See In re Brown, 477 F.2d at 951, 177 USPQ at 695. The Court indicated that it was not factually established that the applicant did not convey to the affiant vital and additional information in their several meetings in addition to that set out in the application. Also of significance for an affidavit to be relevant to the determination of enablement is that it must be probative of the level of skill of the routineer in the art as of the time the applicant filed his application. See In re Gunn, 537 F.2d 1123, 1128, 190 USPQ 402, 406 (CCPA 1976). In that case, each of the affiants stated what was known at the time he executed the affidavit, and not what was known at the time the applicant filed his application.
IV. REFERENCING PRIOR ART DOCUMENTS
The commercial availability of an identified prior art computer system is very pertinent to the issue of enablement. But in some cases, this approach may not be sufficient to meet the applicant's burden. Merely citing extracts from technical publications in an affidavit in order to satisfy the enablement requirement is not sufficient if it is not made clear that a person skilled in the art would know which, or what parts, of the cited circuits could be used to construct the claimed device or how they could be interconnected to act in combination to produce the required results. See In re Forman, 463 F.2d 1125, 1129, 175 USPQ 12, 16 (CCPA 1972). This analysis would appear to be less critical where the circuits comprising applicant's system are essentially standard components of an identified prior art computer system and a standard device attached thereto.
Prior art patents are often relied on by applicants to show the state of the art for purposes of enablement. However, these patents must have an issue date earlier than the effective filing date of the application under consideration. See In re Budnick, 537 F.2d 535, 538, 190 USPQ 422, 424 (CCPA 1976). An analogous point was made in In re Gunn, supra, where the court indicated that patents issued after the filing date of the application under examination are not evidence of subject matter known to any person skilled in the art since their subject matter may have been known only to the patentees and the Patent and Trademark Office.
Merely citing prior art patents to demonstrate that the challenged components are old may not be sufficient proof since, even if each of the enumerated devices or labelled blocks in a block diagram disclosure were old, per se, this would not make it self-evident how each would be interconnected to function in a disclosed complex combination manner. Therefore, the specification in effect must set forth the integration of the prior art; otherwise, it is likely that undue experimentation, or more than routine experimentation would be required to implement the claimed invention. See In re Scarbrough, 500 F.2d 560, 565, 182 USPQ 298, 301 (CCPA 1974). The court also noted that any cited patents which are used by the applicant to demonstrate that particular box diagram hardware or software components are old must be analyzed as to whether such patents are germane to the instant invention and as to whether such patents provide better detail of disclosure as to such components than an applicant's own disclosure. Also, any patent or publication cited to provide evidence that a particular programming technique is well-known in the programming art does not demonstrate that one of ordinary skill in the art could make and use correspondingly disclosed programming techniques unless both programming techniques are of approximately the same degree of complexity. See In re Knowlton, 500 F.2d 566, 572, 183 USPQ 33, 37 (CCPA 1974).
V. ARGUMENTS OF COUNSEL
Arguments of counsel may be effective in establishing that an examiner has not properly met his or her burden or has otherwise erred in his or her position. However, it must be emphasized that arguments of counsel alone cannot take the place of evidence in the record once an examiner has advanced a reasonable basis for questioning the disclosure. See In re Budnick, 537 F.2d at 538, 190 USPQ at 424; In re Schulze, 346 F.2d 600, 145 USPQ 716 (CCPA 1965); In re Cole, 326 F.2d 769, 140 USPQ 230 (CCPA 1964). For example, in a case where the record consisted substantially of arguments and opinions of applicant's attorney, the court indicated that factual affidavits could have provided important evidence on the issue of enablement. See In re Knowlton, 500 F.2d at 572, 183 USPQ at 37; In re Wiseman, 596 F.2d 1019, 201 USPQ 658 (CCPA 1979).<
Go to MPEP - Table of Contents