DETAILED ACTION
Remarks
The present application was filed on 28 November 2023
Claims 1-20 are pending.
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.
Specification
The specification is objected to because:
it uses at least the trademarks TERRAFORM, ANSIBLE, PUPPET and CHEF in paragraph [0032] without capitalizing every letter of the mark(s). See M.P.E.P. § 608.01(v); and
it is inconsistent with the drawings insofar as it uses reference character 708 in paragraph [0083] to refer to a bus instead of 730 as in Figure 7 and uses reference character 722 in paragraph [0085] to refer to the network interface device instead of 722 as in Figure 7.
Drawings
The drawings are objected to as failing to comply with 37 CFR 1.84(p)(5) because they include the following reference character(s) not mentioned in the description: 718, 720 and 730 (see Fig. 7).
Corrected drawing sheets in compliance with 37 CFR 1.121(d), or amendment to the specification to add the reference character(s) in the description in compliance with 37 CFR 1.121(b) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
Allowable Subject Matter
Claims 14-20 are allowed.
The following is a statement of reasons for the indication of allowable subject matter: the “ identifying a subset of the test cases of the test suite as base test cases; instantiating, for each base test case of the test suite, a base testing environment to execute a respective base test case, wherein a plurality of base testing environments are instantiated for the base test cases of the test suite; deploying, in each base testing environment of the plurality of base testing environments, an application being developed for an automotive vehicle; and inserting, in each base testing environment of the plurality of base testing environments, a base test case used to instantiate a respective base testing environment to test the application” features of claim 14, in combination with the other elements recited, is not taught by the prior art and would not have been obvious.
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 § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 and 6-7 are rejected are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Khakare et al. (US 2020/0278920) (art made of record – hereinafter Khakare).
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).
As to claim 6, Khakare 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 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 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.
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 Bin-Nun et al. (US 2023/0356750) (art made of record – hereinafter Bin-Nun).
As to claim 2, Khakare 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 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 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/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
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