DETAILED ACTION
Remarks
Applicant presents a communication filed 8 May 2026 responsive to the 11 February 2026 non-final Office action (the “Previous Action”).
Claims 1 and 8 are amended, as well as paragraphs [0032], [0082-0083] and [0085-0086] of the specification.
Claims 1-20 are pending. Claims 1, 8 and 14 are the independent claims.
Any unpersuasive arguments are addressed in the “Response to Arguments” section below.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Response to Arguments
Applicant argues with respect to the objection to claim 15 that the claim has been amended to address the objection. (Remarks, p. 10 par. 3).
Examiner respectfully disagrees and points out that claim 15 has not been amended. The rejection is accordingly maintained.
Specification
The Previous Action’s specification objections are withdrawn in view of Applicant’s specification amendments.
Drawings
The Previous Action’s drawing objections are withdrawn in view of Applicant’s specification amendments.
Allowable Subject Matter
Claims 14-20 are allowed.
Claims 15-20 are allowable via dependence from claim 14.
Claim Objections
Claim 15 objected to because of the following informalities:
Claim 15 refers to “the primary objectives” at line 3, which appears to be a typographical error that should perhaps read -primary objectives- instead.
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, 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 and 6-7 are rejected under 35 U.S.C. 103 as being upatentable over Khakare et al. (US 2020/0278920) (art of record – hereinafter Khakare) in view of Allen et al. (US 2016/0132423) (art made of record – hereinafter Allen).
As to claim 1, Khakare discloses: a method comprising:
receiving a test suite; (e.g., Khakare, par. [269]: importing test cases from a repository [a test suite being a collection of test cases])
identifying, for each test case of the test suite, one or more parameter values; (e.g., Khakare, par. [0082]: gathering all the underlying blueprint components “(e.g., cloud provider resources and application packages)” [parameter values] that comprise each blueprint; par. [0036]: to generate IaC based on a blueprint; par. [0055]: a non-limiting example of IaC that is generate includes the following code that describes the creation of a server of the type “t2.micro” [see code, it includes variables such as “image_id” and “instance_type”]; par. [0073]: the IaC files can be deployed to build the defined infrastructure in the cloud; par. [0101]: running tests [test cases] on the newly instantiated cloud infrastructure)
obtaining, based on the one or more parameter values, a plurality of Infrastructure as Code (IaC) variables for a respective test case; (e.g., Khakare, par. [0082]: gathering all the underlying blueprint components “(e.g., cloud provider resources and application packages)” [parameter values] that comprise each blueprint; par. [0036]: to generate IaC based on a blueprint; par. [0055]: a non-limiting example of IaC that is generate includes the following code that describes the creation of a server of the type “t2.micro” [see code, it includes variables such as “image_id” and “instance_type”]; par. [0073]: the IaC files can be deployed to build the defined infrastructure in the cloud; par. [0101]: running tests [test cases] on the newly instantiated cloud infrastructure)
generating, for each IaC variable of the plurality of IaC variables, a corresponding IaC module; (e.g., Khakare,; par. [0055]: a non-limiting example of IaC that is generated includes the following code that describes the creation of a server of the type “t2.micro” [see code, it includes variables such as “image_id” and “instance_type”m the block of code being an IaC module]; par. [0011]: exporting IaC code generates a file that defines all the resources; par. [0099]: resources defined in the IaC files [i.e., a plurality of blocks of code (IaC modules), since resources are defined in the file by those blocks]) and
instantiating, based on each IaC module associated with a respective IaC variable, a corresponding testing environment to execute the respective test case (e.g., Khakare, par. [0073]: the IaC files can be deployed to build the defined infrastructure in the cloud; par. [0164-0173]: examples of different tests a user can execute from cloud test software include: 2. Manual test 5. Automated cross browser test; par. [0185]: manual test automatically creates the infrastructure needed to run the tests; par. [0210]: automated cross browser test covers automation testing for the application across a range of browsers. Cloud test software automates test infrastructure creation, importing test cases from a repository and executing test cases).
Khakare does not explicitly discloses one or more parameter values extracted from each test case of the test suite.
However, in an analogous art, Allen discloses:
one or more parameter values extracted from each test case of the test suite (e.g., Allen, par. [0034]: test cases may require different machines and/or resources to execute properly; par. [0002]: thousands of tests may be run [a test suite being a group of tests]. Analyzing the requirements for each test may be very time consuming; par. [0032]: test process 10 may inspect 100 contents of a test case. Contents of the test source code that test process may inspect include application server installables, server configuration files. Further contents may include operating system names mentioned in the test case. Test machine limitations may also be included within the test case source code, such as memory limitations “(e.g., ‘2 GB RAM’)”. Test process 10 may inspect for any information indicative of requirements for the test case to execute properly).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the identification of parameter values taught by Khakare such that the one or more parameter values extracted from each test case of the test suite, as taught by Allen, as Allen would provide the advantage of a less time-consuming means of identifying all requirements for the tests cases to execute correctly. (See Allen, pars. [0002-0003]).
As to claim 6, Khakare/Allen discloses the method of claim 1 (see rejection of claim 1 above), Khakare further discloses:
wherein instantiating the testing environment to execute the respective test case includes combining each IaC module associated with the respective IaC variable (e.g., Khakare par. [0055]: a non-limiting example of IaC that is generate includes the following code that describes the creation of a server of the type “t2.micro” [this code being a module and comprises the variables shown]; par. [0011]: exporting IAC generates a file that defines all the resources [i.e., the code for each resource being a module, so they are combined in the sense that they are in the same file]; , par. [0073]: the IaC files can be deployed to build the defined infrastructure [testing environment] in the cloud; par. [0101]: running tests [test cases] on the newly instantiated cloud infrastructure).
As to claim 7, Khakare/Allen discloses the method of claim 1 (see rejection of claim 1 above), Khakare further discloses
wherein generating, for each IaC variable of the plurality of IaC variables, the corresponding IaC module includes creating the IaC module and inserting the IaC variable into the created IaC module (e.g., Khakare,; par. [0055]: a non-limiting example of IaC that is generated includes the following code that describes the creation of a server of the type “t2.micro” [see code, as noted above, it is a module and as shown, it has variables inserted within it, such as “image_id” and “instance_type”]).
Claim 2-5 and 8-13 are rejected under 35 U.S.C. 103 as being unpatentable over Khakare (US 2020/0278920) in view of Allen (US 2018/0246804) in view of Bin-Nun et al. (US 2023/0356750) (art of record – hereinafter Bin-Nun).
As to claim 2, Khakare/Allen discloses the method of claim 1 (see rejection of claim 1 above), but does not explicitly disclose wherein the test suite is a collection of test cases used to test functional safety (FuSa) of an application being developed for an automotive vehicle.
However, in an analogous art, Bin-Nun discloses:
wherein the test suite is a collection of test cases used to test functional safety (FuSa) of an application being developed for an automotive vehicle (e.g., Bin-Nin, abstract: provided are methods for autonomous vehicle validation. The method includes extracting at least one safety critical scenario; par. [0071]: generally, the present techniques enable the validation of functional safety of an AV; par. [0069]: providing data representative of scenarios 510 as input into the AV compute of the vehicle. The response of the vehicle to the scenarios is compared to the known response. Through this comparison, vehicle systems are validated based on the response; par. [0058]: in some embodiments, any and/or all of the systems in the autonomous vehicle compute 400 are implemented in software).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the test suite of Khakare such that it includes a collection of test cases used to test functional safety (FuSa) of an application being developed for an automotive vehicle, as taught by Bin-Nin, as Bin-Nun would provide the advantage of a means of validating functional safety of an autonomous vehicle. (See Bin-Nun, par [0071]).
As to claim 3, Khakare/Allen discloses the method of claim 1 (see rejection of claim 1 above), Khakare further discloses further comprising:
deploying, in the instantiated testing environment, an application being developed; (e.g. Khakare, par. [0119]: application packages need to be provisioned on top of the infrastructure resource [and there is infrastructure generated for each of the different types of tests, see above]; par. [0135]: once the cloud deploy software installation is complete and an application VPC has been created and configured, cloud test software can be configured to run automatically to test the newly created cloud infrastructure and application [if the application is still undergoing testing, it is still being developed]).
Khakare does not explicitly disclose an application being developed for an automotive vehicle or inserting, in the instantiated testing environment, the respective test case to test the application.
However, in an analogous art, Bin-Nun discloses
an application being developed for an automotive vehicle (see immediately below) and
inserting, in the instantiated testing environment, the respective test case to test the application (e.g., Bin-Nun, par. [0080]: the scenarios [test cases] are characterized by sensor data provided as input [inserted] to a simulator [instantiated test environment] that replicates the AV compute. The response of the vehicle to the scenarios is compared to the known response. Through this comparison, vehicle systems are validated based on the response [i.e., the systems are being tested. And they are under development because they are still being tested]; par. [0058]: in some embodiments, any and/or all of the systems in the autonomous vehicle compute 400 are implemented in software [i.e., are applications]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the instantiated test environments and test cases for testing an application being developed taught by Khakare to include an application being developed for a vehicle, test cases for testing the vehicle application and inserting, in the instantiated testing environment, respective test cases to test an application, as taught by Bin-Nin, as Bin-Nun would provide the advantage of a means of validating functional safety of an autonomous vehicle. (See Bin-Nun, par [0071]).
As to claim 4, Khakare/Allen discloses the method of claim 1 (see rejection of claim 1 above), Khakare further discloses:
wherein each IaC variable of the plurality of IaC variables corresponds to one of: a testing parameter or a combination of testing parameters (e.g., Khakare, par. [0055]: a non-limiting example of IaC that is generate includes the following code that describes the creation of a server of the type “t2.micro” [see code, it includes variables such as “image_id” and “instance_type”]; par. [0073]: the IaC files can be deployed to build the defined infrastructure in the cloud; par. [0101]: running tests [test cases] on the newly instantiated cloud infrastructure)
Khakare does not explicitly disclose FuSa testing.
However, in an analogous art, Bin-Nun discloses:
FuSa testing (e.g., Bin-Nin, abstract: provided are methods for autonomous vehicle validation. The method includes extracting at least one safety critical scenario; par. [0071]: generally, the present techniques enable the validation of functional safety of an AV; par. [0069]: providing data representative of scenarios 510 as input into the AV compute of the vehicle. The response of the vehicle to the scenarios is compared to the known response. Through this comparison, vehicle systems are validated based on the response; par. [0058]: in some embodiments, any and/or all of the systems in the autonomous vehicle compute 400 are implemented in software).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the testing Khakare such that it includes functional safety (FuSa) testing, as taught by Bin-Nun, as Bin-Nun would provide the advantage of a means of validating functional safety of an autonomous vehicle. (See Bin-Nun, par [0071]).
As to claim 5, Khakare/Allen/Bin-Nun discloses the method of claim 4 (see rejection of claim 4 above), but Khakare does not explicitly disclose wherein the FuSa testing parameter is associated with one of: an automotive safety integrity level (ASIL) level, a failure mode, a fault injection, a safety mechanism, an internal condition, a safety requirement, a code coverage, a requirement coverage, a end-to-end test, an environmental condition, a timing and latency requirement, a stress test, a redundancy test, an error handling event, a data integrity requirement, or an interference.
However, in an analogous art, Bin-Nun discloses:
wherein the FuSa testing parameter is associated with one of: an automotive safety integrity level (ASIL) level, a failure mode, a fault injection, a safety mechanism, an internal condition, a safety requirement, a code coverage, a requirement coverage, a end-to-end test, an environmental condition, a timing and latency requirement, a stress test, a redundancy test, an error handling event, a data integrity requirement, or an interference (e.g., Bin-Nun, par. [0078]: a safety critical scenario is an event or sequence of events involving objects “(e.g., vehicles pedestrians, etc.)” acting outside control of the human driver [environmental conditions]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the IAC variables of Khakare such that they are correspond to parameters associated with an automotive safety integrity level (ASIL) level, a failure mode, a fault injection, a safety mechanism, an internal condition, a safety requirement, a code coverage, a requirement coverage, a end-to-end test, an environmental condition, a timing and latency requirement, a stress test, a redundancy test, an error handling event, a data integrity requirement, or an interference, as taught by Bin-Nun, as Bin-Nun would provide the advantage of a means of validating functional safety of an autonomous vehicle. (See Bin-Nun, par [0071]).
As to claim 8, it is a system claim whose limitations are substantially the same as those of claims 1 and 3. Accordingly, it is rejected for substantially the same reasons. Further limitations, disclosed by Khakare, include:
a memory; (e.g., Khakare, par. [0115]) and
a processor, operatively coupled with memory, to perform operations (e.g., Khakare, par. [0115]) comprising: (see rejection of claims 1 and 3 above).
As to claim 9, it is a system claim whose limitations are substantially the same as those of claim 2. Accordingly, it is rejected for substantially the same reasons.
As to claim 10, it is a system claim whose limitations are substantially the same as those of claim 4. Accordingly, it is rejected for substantially the same reasons.
As to claim 11, it is a system claim whose limitations are substantially the same as those of claim 5. Accordingly, it is rejected for substantially the same reasons.
As to claim 12, it is a system claim whose limitations are substantially the same as those of claim 6. Accordingly, it is rejected for substantially the same reasons.
As to claim 13, it is a system claim whose limitations are substantially the same as those of claim 7. Accordingly, it is rejected for substantially the same reasons.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TODD AGUILERA whose telephone number is (571)270-5186. The examiner can normally be reached M-F 11AM - 7:30PM EST.
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 at (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.
/TODD AGUILERA/Primary Examiner, Art Unit 2192
Prosecution Insights