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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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.

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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.

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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.

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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.

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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(a) or pre-AIA 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).

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(a) or pre-AIA 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).

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(a) or pre-AIA 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).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

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 the 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.

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 labeled 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 the known and disclosed 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).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

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 labeled 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 the known and disclosed 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).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

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 disclosures that fail to include the programmed steps, algorithms or procedures that the computer performs necessary to produce the claimed function. These can be described in any way that would be understood by one of ordinary skill in the art, such as with 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.

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 disclosures that fail to include the programmed steps, algorithms or procedures that the computer performs necessary to produce the claimed function. These can be described in any way that would be understood by one of ordinary skill in the art, such as with 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.

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 the 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, then enablement of the component or components should specifically be challenged by the examiner as part of a 35 U.S.C. 112(a) or pre-AIA 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. 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).

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(a) or pre-AIA 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).

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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(a) or pre-AIA 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).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

For example, where the specification provides in a block diagram disclosure of a complex system that includes a microprocessor and other system components controlled by the microprocessor, a mere reference to a 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 (1) either perform any required calculations or (2) coordinate the other system components in the proper timed sequence to perform the functions disclosed and claimed. If a particular program is disclosed in such a system, the 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. In re Brown, 477 F.2d at 951, 177 USPQ at 695. If (1) the disclosure fails to disclose any program and (2) 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 and should be reviewed on a case-by-case basis. 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 four 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 one to two man years, this would be “a clearly unreasonable requirement” (White Consol. Indus., 713 F.2d at 791, 218 USPQ at 963).

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, where there is 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(a) or pre-AIA 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). The Comstock and Knowlton decisions turned on the appellants’ disclosure of (1) a reference to and reliance on an identified prior art computer system, and (2) an operative computer program for the referenced prior art computer system. 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 cursory 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(a) or pre-AIA 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).

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 the 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.

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 labeled 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 the known and disclosed 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).