DETAILED ACTION
Remarks
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office Action is filed in response to Applicant’s Request for Continued Examination dated April 6, 2026. Claims 1, 10, and 11 are currently amended and claims 1-11 remain pending in the application and have been fully considered by Examiner.
Applicant's arguments with respect to the rejections of claims 1-11 under 35 USC 101 have been fully considered, but are not persuasive, as addressed below in the 35 USC 101 Arguments – Rejections section.
Applicant's arguments with respect to the prior art rejections have been considered, but are moot in view of the new grounds of rejection presented herein.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on April 6, 2026, has been entered.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Arguments -- 35 USC 101
Applicant’s arguments with respect to the 35 USC 101 rejections have been fully considered by Examiner, but are not persuasive, as follows:
With respect to claims 1, 10, and 11, Applicant first argues “the elaboration represented by this amendment on how the environment model limits the state space cannot be performed in the human mind because the limitation of the state space as recited in the amended claims is a technological improvement that can only be performed in the execution environment of a computer processing system.”1 Examiner respectfully disagrees.
The relevant portions of the claim recites “wherein the environment model is provided in a form of a native environment model program code, wherein the environment model limits the state space through a content relating to a physics as to what is physically possible for the automated driving function and to a behavior of other drivers in order to prevent a reporting of a false error”. Under the broadest reasonable interpretation (BRI), “native environment model program code” may be human-readable source code2. Thus, the BRI of this limitation includes (1) a human developer using only pen and paper to draft source code of a model with boundary conditions for constraining the model-checking state space to physically possible state changes for AV software and other vehicles, e.g., prohibiting instant movement; (2) the developer using this model to create a human-readable transition system specification that is used to verify human-readable AV function source code. This is not an “overbroad” reading of the claim or reliance of “generic computing components without adequate explanation,” but rather a specific example that falls within the BRI of the claim, which could be performed with no more than pen and paper.
Regarding Applicant’s following arguments concerning Enfish3, Examiner notes that there is a critical distinction between Enfish and the instant case, namely that in Enfish the claim recited specific details of a data structure and its use in a computer system that could not have been accomplished with pen and paper. The instant claims on the other hand broadly recite structures that could be used to perform model checking using only pen and paper, as detailed in the previous paragraph.
Applicant further argues “In the present case, therefore, characterizing the amended claims as involving ‘a human translating human-readable source code and a finite-state model into a model for verification’ (Office Action at 3) is precisely the very sort of ‘high level...abstraction’ that Enfish condemned for being ‘untethered from the language of the claims...’ In particular, this characterization by the Patent Office is untethered from the claim language because it could be applied to a whole host of differently worded claims, without regard to the specific wording used in the claim to reflect the technological improvement captured within its scope. Thus, the approach that the Patent Office takes is the sort of ‘overbroad reasoning’ that relies on a bowdlerized version of the claims recast at a ‘high level of generality’ that ‘eschew[s] the clear teachings of Enfish.’”4 Examiner first notes that the explanation of how the claim limitations may be performed with no more than pen and paper is not simply “a human translating human-readable source code and a finite-state model into a model for verification”. As detailed below the Claim Rejections – 35 USC 101 section, a human developer could (1) draft human-readable5 source code of a model with boundary conditions for constraining the model-checking state space to physically possible state changes for AV software and other vehicles, e.g., prohibiting instant movement; (2) translate human-readable6 source code of an AV function; (3) translate the human-readable source code of the model for constraining model-checking; (4) translate human-readable source code of the AV function; (5) based on steps (1)-(4), generate a transition system specification with only physically possible properties being checked; and (6) manually verify the AV function using the transition system specification. This is not “overbroad” or “untethered from the language of the claims”. Rather it specifically corresponds to the particular claim limitations. Examiner further emphasizes that the relevant questions is whether the claim interpretation is “overbroad” and not merely “broad”. Here, the interpretation is reasonable because it is rooted in Applicant’s own specification and the plain meaning of the terms. For example, according to Applicant’s specification, the claimed “native environment model program code” and “native program code” can be human-readable source code7. If Applicant would like a narrower claim interpretation, Examiner suggests amending the claims to include limitations that could not be performed using only pen and paper and do not merely apply the mental process using a generic computer or generally link the use of the mental process to a particular technological environment or field of use.
Applicant further argues “Simply scribbling some lines of human understandable pseudo code on paper is not tantamount to actually performing this state space limitation in a computing execution environment. To hold otherwise would effectively relegate any software invention beyond the reach of Section 101 since all software is capable of representation at some level of generality as writing on paper.”8 In response, Examiner notes that it is not “scribbling pseudo code” that falls within the BRI of the claim, but rather drafting human-readable source code. Furthermore, the limitations regarding the computing environment are identified separately as either (1) merely generic computing functionality applying the abstract idea or (2) merely reciting a particular technological environment or field of use, neither of which integrates the abstract idea into a practical application or amounts to significantly more than the abstract idea9. Moreover, holding that these specific claims are patent ineligible in no way suggests that “any software invention beyond the reach of Section 101 since all software is capable of representation at some level of generality as writing on paper”. The determination of patent ineligibility here is tied to the specific claim limitations, and as detailed below in the Claim Rejections – 35 USC 101 section, all claim limitations are either abstract, merely apply the abstract idea using generic computing functionality, or merely recite a particular technological environment or field of use. Examiner acknowledges that there are certainly methods of model checking that include steps that a person could not practically perform using only pen and paper, but Applicant has not claimed any details requiring such steps.
With respect to Step 2A Prong 2, Applicant argues that Examiner’s analysis “fails to address statements of material technological improvement that the specification links to the limitation in question”10 and “Here, the limitation quoted above represents a technological advance in the field of software code verification. In particular, prior software verification systems that did not employ an environmental model to limit a state space of the software component to be verified by way of predefinable boundary conditions presented technological disadvantages in terms of invalid sequences.”11 However, eligibility “cannot be furnished by the …abstract idea … itself”12 , “claims that amount to nothing more than an instruction to apply the abstract idea using a generic computer do not render an abstract idea eligible”,13 and “ limitations that amount to merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application.”14 As explained above and further in the Claim Rejections – 35 USC 101 section below, all of the instant claim limitations are either a mental process, merely apply the mental process using a generic computer, or merely indicate a field of use or technological environment in which to apply the mental process.
With respect to Step 2B, Applicant appears to argue that the analysis is deficient because it does not adequately support the determination that additional elements are well-understood, routine, and conventional15. However, Examiner has not asserted that any of the additional elements are well-understood, routine, and conventional. Furthermore, no such determination is required as the additional elements merely apply the abstract idea using generic computing functionality or merely indicate a field of use or technological environment in which to apply the abstract idea.
For the reasons set forth above, Applicant’s arguments are unpersuasive.
Claim Objections
Claims 4 and 7 are objected to because of the following informalities:
With respect to claim 4, “the basis” on line 5 lacks antecedent basis.
With respect to claim 7, the claim status is “Previously Presented” but there is an amendment on line “particular step”. This amendment was effective as of the previously amended claims dated July 25, 2025, and thus its inclusion here appears to be a typographical error. Also, “program code” recited on line 2 should recite “native program code”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 10-11 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
With respect to claim 10, line 1 has been amended to recite “A processor that includes a software component of an automated driving function….” The most relevant portion of the original disclosure is at lines 9-12 of p. 21, which recites “a computer-implemented system for implementing the automated driving function, which comprises at least one software component verified in accordance with the present invention”. However, there is no disclosure of a “processor that includes a software component of an automated driving function”. Nor is this inherent in Applicant’s original disclosure because “a software component of an automated driving function” may be in included memory rather than in a “processor”, as claimed. Accordingly, the claim is rejected under 35 USC 112(a).
With respect to claim 11, line 1 has been amended to recite “computer-implemented system for implementing an automated driving function, comprising: at least one processor that includes at least one software component….” The most relevant portion of the original disclosure is at lines 9-12 of p. 21, which recites “a computer-implemented system for implementing the automated driving function, which comprises at least one software component verified in accordance with the present invention”. However, there is no disclosure of a “processor that includes a software component of an automated driving function”. Nor is this inherent in Applicant’s original disclosure because “a software component of an automated driving function” could be included in memory rather than in a “processor”, as claimed. Accordingly, the claim is rejected under 35 USC 112(a).
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
With respect to claim 1, lines 9-10 recite “the environment model program”. It is unclear if this is the same as “an environment model”, as recited on line 3, or “a native environment model program code”, as recited on line 5. The scope of the claim is therefore indefinite. For purposes of compact prosecution only, Examiner has interpreted lines 9-10 as reciting “the native environment model program code”.
With respect to claims 2-9, each inherits the 35 USC 112(b) deficiency identified above with respect to claim 1.
With respect to claims 10-11, each recites limitations similar to claim 1 and is indefinite for the same reason and has been interpreted as indicated above (see the rejection of claim 1).
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-11 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, specifically an abstract idea, as it has not been integrated into a practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Step 1: Claims 1-9 are directed to computer-implemented methods and fall within the statutory category of processes; Claim 10 is directed to a processor that includes a software component of an automated driving function that could be software per se and thus does not fall within one of the four statutory categories; claim 11 is directed to a system that could be software per se and thus does not fall within one of the four statutory categories. Therefore, “Are the claims to a process, machine, manufacture or composition of matter?” Yes as to claims 1-9 and No as to claims 10-11 (see section 13 below).
In order to evaluate the Step 2A inquiry “Is the claim directed to a law of nature, a natural phenomenon or an abstract idea?” we must determine, at Step 2A Prong 1, whether the claim recites a law of nature, a natural phenomenon, or an abstract idea (see MPEP § 2106.04).
Step 2A Prong 1:
With respect to claims 1, 10, and 11, The limitations of “method for verifying at least one software component of an automated driving function, the method comprising the following steps: providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code, wherein the environment model limits the state space through a content relating to a physics as to what is physically possible for the automated driving function and to a behavior of other drivers in order to prevent a reporting of a false error; translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated; and verifying the model checker representation using a model checking method,” as claimed, is a process that, but for the recitation of generic computing components and under its broadest reasonable interpretation, covers performance of the limitation in the mind with no more than pen and paper. For example, a human software developer could, using no more than pen and paper, (1) draft human-readable16 source code of a model with boundary conditions for constraining the model-checking state space to physically possible state changes for AV software and other vehicles, e.g., prohibiting instant movement; (2) translate human-readable17 source code of an AV function; (3) translate the human-readable source code of the model for constraining model-checking; (4) translate human-readable source code of the AV function; (5) based on steps (1)-(4), generate a transition system specification with only physically possible properties being checked; (6) verify the AV function using the transition system specification.
Therefore, Yes, claims 1, 10, and 11 recite limitations that fall within the “Mental Processes” grouping of abstract ideas.
As the claims have been identified as reciting a judicial exception, Step 2A Prong 2 will evaluate whether the claim as a whole integrates the recited judicial exception into a practical application (see MPEP § 2106.04(d)).
Step 2A Prong 2:
With respect to claims 1, 10, and 11, The judicial exception is not integrated into a practical application. In particular, the claims recite the following additional element: “computer-implemented,”18 which merely recites instructions to implement an abstract idea on a generic computer, or merely uses a generic computer or computer components to perform the abstract idea, which does not integrate a judicial exception into a practical application (see MPEP § 2106.05(f), which also cites several court cases, e.g., Alice Corp. Pty. Ltd. V. CLS Bank Int’l, 573 U.S. 208, 223, 110 USPQ2d 1976, 1983 (2014); Apple, Inc. v. Ameranth, Inc., 842 F.3d 1229, 1243-44, 120 USPQ2d 1844, 1855-57 (Fed. Cir. 2016); FairWarning IP, LLC v. Iatric Sys., 839 F.3d 1089, 1095, 120 USPQ2d 1293, 1296 (Fed. Cir. 2016); Ultramercial, Inc. v. Hulu, LLC, 772 F.3d 709, 715, 112 USPQ2d 1750, 1754 (Fed. Cir. 2014); Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363, 1370-71, 115 USPQ2d 1636, 1642 (Fed. Cir. 2015)).
The claims further recite the following additional element(s): “A processor that includes a software component of an automated driving function which has been verified,”19 “A computer-implemented system for implementing an automated driving function, comprising: at least one processor that includes at least one software component,”20 which are merely indications of a field of use or technological environment in which to apply the judicial exception that do not integrate the judicial exception into a practical application (see MPEP § 2106.05(h), which also cites several pertinent court cases, e.g., Affinity Labs of Texas v. DirecTV, LLC, 838 F.3d 1253, 120 USPQ2d 1201 (Fed. Cir. 2016); FairWarning v. Iatric Sys., 839 F.3d 1089, 1094-95, 120 USPQ2d 1293, 1295 (Fed. Cir. 2016); Electric Power Group, LLC v. Alstom S.A., 830 F.3d 1350, 1354, 119 USPQ2d 1739, 1742 (Fed. Cir. 2016)).
Therefore, “Do the claims recite additional elements that integrate the judicial exception into a practical application? No, even when viewed in combination, these additional elements do not integrate the abstract idea into a practical application and they do not impose any meaningful limits on practicing the abstract idea.
After having evaluated the inquires set forth in Steps 2A Prong 1 and 2, it has been concluded that claims 1, 10, and 11 not only recite a judicial exception but are directed to the judicial exception as the judicial exception has not been integrated into a practical application. Accordingly, Step 2B will evaluate whether the claim as a whole amounts to significantly more than the recited exception, i.e., whether any additional element, or combination of additional elements, adds an inventive concept to the claim. See MPEP § 2106.05.
Step 2B:
With respect to claims 1, 10, and 11, The claims do not include additional elements, alone or in combination, that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to the integration of the abstract idea into a practical application, the additional elements amount to no more than generic computing components applying the abstract idea or a recitation of a field of use/technological environment.
Therefore, “Do the claims recite additional elements that amount to significantly more than the judicial exception?” No, these additional elements, alone or in combination, do not amount to significantly more than the judicial exception.
Having concluded the analysis within the provided framework, claims 1, 10, and 11 do not recite patent eligible subject matter under 35 U.S.C. § 101.
With respect to claim 2, the limitations recite “wherein the native program code of the software component to be verified and the environment model program code are limited to a set of operations of at least one programming language used that are defined as permissible”, which merely describes additional details for code that may be human-readable. Thus, under the broadest reasonable interpretation, the limitations could also be performed in the human mind with no more than pencil and paper. The claim is therefore directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 3, the limitations recite “wherein the environment model describes first boundary conditions for starting states of the software component to be verified and/or second boundary conditions for changes in a state of the software component to be verified”, which merely describes additional details for code that may be human-readable. Thus, under the broadest reasonable interpretation, the limitations could also be performed in the human mind with no more than pencil and paper. The claim is therefore directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 4, the limitations recite “wherein, during the translation, the native program code of the software component to be verified and the environment model program code are transferred into a structure of a common finite automaton, and wherein the model checker representation limited by the boundary conditions of the environment model and intended for the software component to be verified is generated on the basis of the common finite automaton”, which under the broadest reasonable interpretation could also be performed in the human mind with no more than pencil and paper. For example, a human developer using no more than pen and paper could create a finite state diagram during the translation and then use the finite state diagram to generate the transition system specification. Thus, the claim is directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 5, the limitations recite “wherein, at least in a first step, during the translation of the native program code of the software component to be verified and the environment model program code, at least one intermediate representation of the software component to be verified and/or of the environment model is generated which has a structure of a finite automaton (FA), in which at least part of the native program code is embedded”, which under the broadest reasonable interpretation could also be performed in the human mind with no more than pencil and paper. For example, a human developer could create a finite state diagram with some of the human-readable source code embedded during the translation. Thus, the claim is directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 6, the limitations recite “wherein, in at least one further step, during the translation of the native program code of the software component to be verified and the environment model program code, at least one code segment of the at least one intermediate representation is converted into FA segments”, which could also be performed in the human mind with no more than pencil and paper. For example, a human developer could convert the finite state diagram into finite state transition system. Thus, the claim is directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 7, the limitations recite “wherein, at least in a particular step, the program code of the software component to be verified and the environment model program code are each transferred, independently of one another, into a separate intermediate representation having a particular structure of the finite automaton, and wherein, in at least one further particular step, the intermediate representations are transferred into a common finite automaton, wherein the model checker representation is based on the common finite automaton”, which could also be performed in the human mind with no more than pencil and paper. For example, a developer could transfer the human-readable code of the AV function and the model into different diagrams, which are then transferred into a refined finite state diagram accounting for the constraints of the model, which is then used to generate the transition system specification. Thus, the claim is directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 8, the limitations recite “wherein the software component of the automated driving function forms an adaptive cruise control function for an automated vehicle”, which merely describes additional details for code that may be human-readable. Thus, under the broadest reasonable interpretation, the limitations could also be performed in the human mind with no more than pencil and paper. The claim is therefore directed to the judicial exception and does not have elements amounting to significantly more than the abstract idea itself. Accordingly, the claim does not recite patent eligible subject matter under 35 U.S.C. §101.
With respect to claim 9, the limitations recite “wherein the model checking method is performed using a NuSMV tool based on computation tree logic or linear temporal logic”, which merely describes using a particular software tool to perform the model checking. This amounts to no more than generally linking the use of a judicial exception to a particular technological environment/field of use (see MPEP §2106.05(h)). Thus, the claim is directed to the judicial exception and does not have elements amounting to significantly more that the abstract idea itself. Therefore, claim 9 does not recite patent eligible subject matter under 35 U.S.C. §101.
Claims 10-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter
With respect to claim 10, line 1 recites it “A processor that includes a software component of an automated driving function….” Since Applicant’s specification does not disclose a “processor”, the broadest reasonable interpretation (BRI) of a “processor” includes a processor made up entirely of software and/or data per se. Thus, the BRI of the subject matter of claim 10 is entirely software and/or data per se, which does not fall within one of the statutory categories identified in 35 U.S.C. §101.
With respect to claim 11, lines 1-3 recite “A computer-implemented system for implementing an automated driving function, comprising: at least one processor that includes at least one software component….” Since Applicant’s specification does not disclose a “processor”, the broadest reasonable interpretation (BRI) of a “processor” included a processor made up entirely of software and/or data per se. Thus, the BRI of the subject matter of claim 11 is entirely software and/or data per se, which does not fall within one of the statutory categories identified in 35 U.S.C. §101.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7 are rejected under 35 U.S.C. 103 as being unpatentable over Corbett et al. “Bandera: Extracting Finite-state Models from Java Source Code” (hereinafter Corbett) in view of Volker et al. “Verification of Cooperative Vehicle Behavior using Temporal Logic” (hereinafter Volker).
With respect to claim 1, Corbett discloses A computer-implemented method for verifying at least one software component (e.g., Fig. 1 and associated text, e.g., Abstract, we describe an integrated collection of program analysis and transformation components, called Bandera, that enables the automatic extraction of safe, compact finite-state models from program source code. Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools.), the method comprising the following steps:
providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code (e.g., Fig. 1, particularly Specification [](Heap.c1.queue>0 -><>Stage1.run:return [wherein the environment model is provided in a form of a native environment model program code] and associated text, e.g., p. 442, The user completes a specification by filling in the template's parameters with primitive propositions that describe the semantic features of the program that the user is interested in reasoning about [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions]. Currently, Bandera supports the definition of propositions that define a range of values for object fields that are defined as built-in types (e.g., c1.queue>0), and propositions that capture locations in the source code (e.g., Stage1.run:return| the return point of the run method of class Stage1). From these propositions, Bandera automatically derives a slicing criterion that can be used to slice away program components irrelevant to the property being checked [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code]; see also p. 443, slicing removes entire threads and dramatically reduces the state space.), ;
translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools [translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated]; p. 444, producing verifier-specific representations for targeted verifiers…. BIRC translates a subset of Jimple to BIR. Java locals and instance variables are mapped onto BIR state variables and record elds. The Jimple statement graph is traversed to construct a set of guarded commands for each thread. Each guarded command is marked as visible/invisible based on the kind of data accesses (e.g., operations on locals are invisible). BIRC also accepts a set of expressions used to define primitive propositions in the model (e.g., a thread is at a specific statement, a variable has a given value). BIRC embeds these proposition definitions into the BIR [translating the environment model program] …. The Spin translator accepts a BIR representation and produces a Promela model of the system, suitable for input to the Spin model checker [a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated].); and
verifying the model checker representation using a model checking method (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools; Bandera also maps verifier outputs back to the original source code.).
Corbett does not appear to disclose the following, which is taught in analogous art, Volker: of an automated driving function (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 1, 1st full para., cooperative solutions are an essential part of automated driving … formal methods may be used in order to verify the vehicle behavior; p. 5, left col., 3rd full para., All relevant actions and reactions of an automated vehicle, depending on the environment it is supposed to interact with, are encoded.) … wherein the environment model limits the state space through a content relating to a physics as to what is physically possible for the automated driving function and to a behavior of other drivers in order to prevent a reporting of a false error (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 2, § 3. Contribution, 1st para., A transition system T which encodes the possible state space; p. 2, § 3.1 Modeling Traffic Systems, 4th para. – 6th para., R can be understood as a graph. All paths though this graph represent possible but not necessarily legal behaviors … We allow illegal paths in the automaton in order to be able to model non-cooperative actors in the traffic system which might not always drive according to traffic rules … Only physically possible transitions respective to road boundaries and vehicle dynamics of a vehicle are included … The vehicle automata Ci = (Qi, Q2 ×G, q0i, δi) model the behaviors of a vehicle i; p. 4, right col., 2nd full para., R can be seen as a constraint on the automata Ci. Thus, we model a combination of R and Ci for each vehicle; p. 1, left cool., 2nd full para., reduce false positives.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Corbett with the invention of Volker, because “cooperative solutions are an essential part of automated driving” and the invention of Volker can “verify the safety of the behavior of cooperative vehicles”, as suggested by Volker (see p. 1, § Introduction, 1st para., and Abstract).
With respect to claim 2, Corbett also discloses wherein the native program code of the software component to be verified and the environment model program code are limited to a set of operations of at least one programming language used that are defined as permissible (e.g., Fig. 1 and associated text, e.g., p. 440, We also describe the application of the current implementation of Bandera (which handles a reasonably large subset of Java) [wherein the native program code of the software component to be verified and the environment model program code are limited to a set of operations of at least one programming language used that are defined as permissible] to a non-trivial program.).
With respect to claim 3, Volker further teaches wherein the environment model describes first boundary conditions for starting states of the software component to be verified and/or second boundary conditions for changes in a state of the software component to be verified (e.g., Figs. 1-8 and associated texted, e.g., p. 2, § 3.1 Modeling Traffic Systems, 2nd para., it splits up the road into a finite set of discrete states Q and state transitions ∆. Furthermore, there is a set of initial states Q0 at which vehicles can enter the traffic system; p. 2, right col., 2nd full para., Only physically possible transitions respective to road boundaries and vehicle dynamics of a vehicle are included; see also p. 2, right col., 3rd full para.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Corbett with the invention of Volker for the same reason set forth above.
With respect to claim 4, Corbett also discloses wherein, during the translation, the native program code of the software component to be verified and the environment model program code are transferred into a structure of a common finite automaton, and wherein the model checker representation limited by the boundary conditions of the environment model and intended for the software component to be verified is generated on the basis of the common finite automaton (e.g., Fig. 1 and associated text, e.g., p. 442, The Bandera front-end translates Java [program code of the software component to be verified] to a high-level intermediate language called Jimple [program code of the software component to be verified is transferred independently into a separate intermediate representation having a structure of a finite automaton]; p. 444, As shown in Figure 1, the back end has one fixed component called BIRC (Bandera Intermediate Representation Constructor) that accepts a restricted form of Jimple and produces BIR. For each supported verifier, there is also a translator component that accepts the program represented in BIR and generates input for that verifier [based on which the model checker representation for the software component to be verified is generated].… BIR [common FA] is a guarded command language for describing state transition systems …. BIRC translates a subset of Jimple to BIR…. The Jimple statement graph is traversed to construct a set of guarded commands for each thread …. BIRC also accepts a set of expressions used to define primitive propositions in the model (e.g., a thread is at a specific statement, a variable has a given value). BIRC embeds these proposition definitions into the BIR [wherein, during the translation, the native program code of the software component to be verified and the environment model program code are transferred into a structure of a common finite automaton, and wherein the model checker representation limited by the boundary conditions of the environment model and intended for the software component to be verified is generated on the basis of the common finite automaton]; see also p. 442, From these propositions, Bandera automatically derives a slicing criterion that can be used to slice away program components irrelevant to the property being checked [limited by the boundary conditions of the environment model].).
With respect to claim 5, Corbet also discloses wherein, at least in a first step, during the translation of the native program code of the software component to be verified and the environment model program code, at least one intermediate representation of the software component to be verified and/or of the environment model is generated which has a structure of a finite automaton (FA), in which at least part of the native program code is embedded (Fig. 1 and associated text, e.g., p. 444, The Bandera back end is like a code generator, taking the sliced and abstracted program and producing verifier-specific representations for targeted verifiers. The back-end components communicate through BIR, the Bandera Intermediate Representation, an intermediary between compiler-based representations and verifier-based representations. As shown in Figure 1, the back end has one fixed component called BIRC (Bandera Intermediate Representation Constructor) that accepts a restricted form of Jimple and produces BIR [at least one intermediate representation of the software component to be verified].… BIR is a guarded command language for describing state transition systems …. BIRC translates a subset of Jimple to BIR. Java locals and instance variables are mapped onto BIR state variables and record fields; p. 442, The Bandera front-end translates Java to a high-level intermediate language called Jimple; the Bandera back-end generates model-checker inputs from a low-level intermediate language of guarded commands called BIR (Bandera Intermediate Representation) [during the translation of the native program code of the software component to be verified and the environment model program code, at least one intermediate representation of the software component to be verified and/or of the environment model is generated which has a structure of a finite automaton (FA), in which at least part of the native program code is embedded]; see also Abstract, p. 440-442.).
With respect to claim 6, Corbett also discloses wherein, in at least one further step, during the translation of the native program code of the software component to be verified and the environment model program code, at least one code segment of the at least one intermediate representation is converted into FA segments (e.g., Fig. 1 and associated text, e.g., p. 444, producing verifier-specific representations for targeted verifiers….The Spin translator accepts a BIR representation and produces a Promela model of the system, suitable for input to the Spin model checker [at least one code segment of the at least one intermediate representation is converted into FA segments].).
With respect to claim 7, Corbet also discloses wherein, at least in a particular step, the program code of the software component to be verified and the environment model program code are each transferred, independently of one another, into a separate intermediate representation having a particular structure of the finite automaton, and wherein, in at least one further particular step, the intermediate representations are transferred into a common finite automaton, wherein the model checker representation is based on the common finite automaton (e.g., Fig. 1 and associated text, e.g., p. 442, The Bandera front-end translates Java [program code of the software component to be verified] to a high-level intermediate language called Jimple [program code of the software component to be verified is transferred independently into a separate intermediate representation having a structure of a finite automaton]; p. 444, As shown in Figure 1, the back end has one fixed component called BIRC (Bandera Intermediate Representation Constructor) that accepts a restricted form of Jimple and produces BIR [intermediate representations are transferred into a common finite automaton]. For each supported verifier, there is also a translator component that accepts the program represented in BIR and generates input for that verifier [based on which the model checker representation for the software component to be verified is generated].… BIR is a guarded command language for describing state transition systems [common FA] …. BIRC translates a subset of Jimple to BIR…. The Jimple statement graph is traversed to construct a set of guarded commands for each thread …. BIRC also accepts a set of expressions used to define primitive propositions in the model (e.g., a thread is at a specific statement, a variable has a given value). BIRC embeds these proposition definitions into the BIR [program code of the software component to be verified and the environment model program code are each transferred, independently of one another, into a separate intermediate representation having a particular structure of the finite automaton, and wherein, in at least one further particular step, the intermediate representations are transferred into a common finite automaton, wherein the model checker representation is based on the common finite automaton].).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Corbett in view of Volker, as applied to claim 1 above, and further in view of Ratiu et al. 20210342250 (hereinafter Ratiu).
With respect to claim 8, Corbett does not appear to disclose wherein the software component of the automated driving function forms an adaptive cruise control function for an automated vehicle. However, this is taught in analogous art, Ratiu (e.g., Figs. 1-4 and associated text, e.g., [0019], a method and apparatus are provided to verify a software system in an appropriate state based on a plurality of input values. Typically, the software system includes software components that are responsible for performing one or more functions associated with hardware system. The hardware system may be a vehicle with an adaptive cruise controller.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Corbett with the invention of Ratiu because reactive software systems require verification, as suggested by Ratiu (see [0003-4]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Corbet in view of Volker, as applied to claim 1 above, and further in view of Iosif et al. “Translating Java for Multiple Model Checkers: The Bandera Back-End” (hereinafter Iosif).
With respect to claim 9, Corbett also discloses wherein the model checking method is performed using a [NuSMV] tool based on computation tree logic or linear temporal logic (e.g., Fig. 1 and associated text, e.g., p. p. 441, The user formalizes a requirement as, for example, a temporal logic formula; 444, The Spin translator accepts a BIR representation and produces a Promela model of the system, suitable for input to the Spin model checker; p. 443, As an example, consider the LTL [linear temporal logic] response specification from Figure 1; see also p. 446.).
Although Corbett discloses using a model checker tool such as Spin (see above), it does not appear to disclose NuSMV. However, this is taught in analogous art, Iosif (p. 139, or each supported verifier, there is also a translator component that accepts the program represented in BIR and generates input for that verifier and a component that translates verifier counterexamples into a trace in the BIR transition system. Translators for … NuSMV have been built.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the Bandera invention of Corbett with the NuSMV tool of Iosif because it is a well-known model checker and Bandera is designed to work with NuSMV, as suggested by Iosif (see p. 139.).
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Corbett in view of Volker and Gulash (US 20170110022 A1, hereinafter Gulash).
With respect to claim 10, Corbett discloses a software component which has been verified, the software component being verified (e.g., Fig. 1 and associated text, e.g., Abstract, we describe an integrated collection of program analysis and transformation components, called Bandera, that enables the automatic extraction of safe, compact finite-state models from program source code. Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools.) by performing the following steps:
providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code (e.g., Fig. 1, particularly Specification [](Heap.c1.queue>0 -><>Stage1.run:return [wherein the environment model is provided in a form of a native environment model program code] and associated text, e.g., p. 442, The user completes a specification by filling in the template's parameters with primitive propositions that describe the semantic features of the program that the user is interested in reasoning about [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions]. Currently, Bandera supports the definition of propositions that define a range of values for object fields that are defined as built-in types (e.g., c1.queue>0), and propositions that capture locations in the source code (e.g., Stage1.run:return| the return point of the run method of class Stage1). From these propositions, Bandera automatically derives a slicing criterion that can be used to slice away program components irrelevant to the property being checked [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code]; see also p. 443, slicing removes entire threads and dramatically reduces the state space.), ;
translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools [translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated]; p. 444, producing verifier-specific representations for targeted verifiers…. BIRC translates a subset of Jimple to BIR. Java locals and instance variables are mapped onto BIR state variables and record elds. The Jimple statement graph is traversed to construct a set of guarded commands for each thread. Each guarded command is marked as visible/invisible based on the kind of data accesses (e.g., operations on locals are invisible). BIRC also accepts a set of expressions used to define primitive propositions in the model (e.g., a thread is at a specific statement, a variable has a given value). BIRC embeds these proposition definitions into the BIR [translating the environment model program] …. The Spin translator accepts a BIR representation and produces a Promela model of the system, suitable for input to the Spin model checker [a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated].); and
verifying the model checker representation using a model checking method (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools; Bandera also maps verifier outputs back to the original source code.).
Corbett does not appear to disclose the following, which is taught in analogous art, Volker: of an automated driving function (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 1, 1st full para., cooperative solutions are an essential part of automated driving … formal methods may be used in order to verify the vehicle behavior; p. 5, left col., 3rd full para., All relevant actions and reactions of an automated vehicle, depending on the environment it is supposed to interact with, are encoded.) … wherein the environment model limits the state space through a content relating to a physics as to what is physically possible for the automated driving function and to a behavior of other drivers in order to prevent a reporting of a false error (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 2, § 3. Contribution, 1st para., A transition system T which encodes the possible state space; p. 2, § 3.1 Modeling Traffic Systems, 4th para. – 6th para., R can be understood as a graph. All paths though this graph represent possible but not necessarily legal behaviors … We allow illegal paths in the automaton in order to be able to model non-cooperative actors in the traffic system which might not always drive according to traffic rules … Only physically possible transitions respective to road boundaries and vehicle dynamics of a vehicle are included … The vehicle automata Ci = (Qi, Q2 ×G, q0i, δi) model the behaviors of a vehicle i; p. 4, right col., 2nd full para., R can be seen as a constraint on the automata Ci. Thus, we model a combination of R and Ci for each vehicle; p. 1, left cool., 2nd full para., reduce false positives.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Corbett with the invention of Volker, because “cooperative solutions are an essential part of automated driving” and the invention of Volker can “verify the safety of the behavior of cooperative vehicles”, as suggested by Volker (see p. 1, § Introduction, 1st para., and Abstract).
Corbett does not appear to disclose the following, which is taught in analogous art, Gulash: A processor that includes (e.g., Fig. 1 and associated text, e.g., [0036], The autonomous driving module(s) 120 can be a component of the processor 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Corbett with the invention of Gulash because the processor could access it faster than if it were stored in external memory.
With respect to claim 11, Corbett discloses A computer-implemented system for implementing , comprising: at least one software component verified (e.g., Fig. 1 and associated text, e.g., Abstract, In this paper, we describe an integrated collection of program analysis and transformation components, called Bandera, that enables the automatic extraction of safe, compact finite-state models from program source code. Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools.) by performing the following steps:
providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code (e.g., Fig. 1, particularly Specification [](Heap.c1.queue>0 -><>Stage1.run:return [wherein the environment model is provided in a form of a native environment model program code] and associated text, e.g., p. 442, The user completes a specification by filling in the template's parameters with primitive propositions that describe the semantic features of the program that the user is interested in reasoning about [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions]. Currently, Bandera supports the definition of propositions that define a range of values for object fields that are defined as built-in types (e.g., c1.queue>0), and propositions that capture locations in the source code (e.g., Stage1.run:return| the return point of the run method of class Stage1). From these propositions, Bandera automatically derives a slicing criterion that can be used to slice away program components irrelevant to the property being checked [providing an environment model that limits a state space of the software component to be verified by way of predefinable boundary conditions, wherein the environment model is provided in a form of a native environment model program code]; see also p. 443, slicing removes entire threads and dramatically reduces the state space.), ;
translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools [translating native program code of the software component to be verified and the environment model program, wherein a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated]; p. 444, producing verifier-specific representations for targeted verifiers…. BIRC translates a subset of Jimple to BIR. Java locals and instance variables are mapped onto BIR state variables and record elds. The Jimple statement graph is traversed to construct a set of guarded commands for each thread. Each guarded command is marked as visible/invisible based on the kind of data accesses (e.g., operations on locals are invisible). BIRC also accepts a set of expressions used to define primitive propositions in the model (e.g., a thread is at a specific statement, a variable has a given value). BIRC embeds these proposition definitions into the BIR [translating the environment model program] …. The Spin translator accepts a BIR representation and produces a Promela model of the system, suitable for input to the Spin model checker [a model checker representation limited by the boundary conditions and intended for the software component to be verified is generated].); and
verifying the model checker representation using a model checking method (e.g., Fig. 1 and associated text, e.g., Abstract, Bandera takes as input Java source code and generates a program model in the input language of one of several existing verification tools; Bandera also maps verifier outputs back to the original source code.).
Corbett does not appear to disclose the following, which is taught in analogous art, Volker: an automated driving function (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 1, 1st full para., cooperative solutions are an essential part of automated driving … formal methods may be used in order to verify the vehicle behavior; p. 5, left col., 3rd full para., All relevant actions and reactions of an automated vehicle, depending on the environment it is supposed to interact with, are encoded.) … wherein the environment model limits the state space through a content relating to a physics as to what is physically possible for the automated driving function and to a behavior of other drivers in order to prevent a reporting of a false error (e.g., Figs. 1-8 and 12 along with associated text, e.g., p. 2, § 3. Contribution, 1st para., A transition system T which encodes the possible state space; p. 2, § 3.1 Modeling Traffic Systems, 4th para. – 6th para., R can be understood as a graph. All paths though this graph represent possible but not necessarily legal behaviors … We allow illegal paths in the automaton in order to be able to model non-cooperative actors in the traffic system which might not always drive according to traffic rules … Only physically possible transitions respective to road boundaries and vehicle dynamics of a vehicle are included … The vehicle automata Ci = (Qi, Q2 ×G, q0i, δi) model the behaviors of a vehicle i; p. 4, right col., 2nd full para., R can be seen as a constraint on the automata Ci. Thus, we model a combination of R and Ci for each vehicle; p. 1, left cool., 2nd full para., reduce false positives.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the invention of Corbett with the invention of Volker, because “cooperative solutions are an essential part of automated driving” and the invention of Volker can “verify the safety of the behavior of cooperative vehicles”, as suggested by Volker (see p. 1, § Introduction, 1st para., and Abstract).
Corbett does not appear to disclose the following, which is taught in analogous art, Gulash: at least one processor that includes (e.g., Fig. 1 and associated text, e.g., [0036], The autonomous driving module(s) 120 can be a component of the processor 110).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the invention of Corbett with the invention of Gulash because the processor could access it faster than if it were stored in external memory.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Specifically, Kloock et al. “Trajectory Verification for Networked and Autonomous Vehicles using Temporal Logic and Model Checking” teaches a verification method for the trajectory planning of networked and autonomous vehicles using temporal logic.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEPHEN DAVID BERMAN whose telephone number is (571) 272-7206. The examiner can normally be reached M-F, 9-6 Eastern.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Hyung S. Sough can be reached on 571-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEPHEN D BERMAN/ Examiner, Art Unit 2192
1 See Remarks at p. 6.
2 See Applicant’s specification at p. 13, lines 11-14, ““native environment model program code 110 (e.g., in the programming language C++, Python, etc. that is being used)”.
3 See Remarks at p. 7.
4 See Remarks at pp. 7-8
5 See Applicant’s specification at p. 13, lines 11-14, ““native environment model program code 110 (e.g., in the programming language C++, Python, etc. that is being used)”.
6 See Applicant’s specification at p. 16, lines 16-17, “native program code examples for the software component to be verified (“Example: C++,” 110, 210).”
7 See Applicant’s specification at p. 13, lines 11-14, ““native environment model program code 110 (e.g., in the programming language C++, Python, etc. that is being used)” and p. 16, lines 16-17, “native program code examples for the software component to be verified (“Example: C++,” 110, 210).”
8 See Remarks at p. 8.
9 See MPEP 2106.05(f) and 2106.05(h).
10 See Remarks at p. 9.
11 See Remarks at p. 10.
12 See MPEP § 2106.04(II)(2).
13 See MPEP § 2106.05(f)
14 See MPEP § 2106.05(h).
15 See Remarks at pp. 12-14.
16 See Applicant’s specification at lines 11-14, ““native environment model program code 110 (e.g., in the programming language C++, Python, etc. that is being used)”.
17 See Applicant’s specification at p. 16, lines 16-17, “native program code examples for the software component to be verified (“Example: C++,” 110, 210).”
18 See claim 1.
19 See claim 10.
20 See claim 11.
Prosecution Insights