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 .
DETAILED ACTION
This action is in response to the application filed on 08/07/26.
Claims 1-20 are pending.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to (an) abstract idea(s) without significantly more.
Claims 1, 8, and 15 recite:
Regarding claim 1, A method comprising:
Identifying, from a specification document of a software system, requirements of the software system related to vehicle safety functions;
Identifying one or more tests for safety related application programming interfaces
Determining, for each of the one or more tests, coverage of source code of the software system; and
Mapping, by a processing device, each of the one or more tests to requirements of the software system identified from the specification document in view of a comparison between source code corresponding to each requirement of the specification document the coverage of the source code of the software system for each of the one or more tests
Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 1 is a method
Claim 8 is a system
Claim 15 is a non-transitory medium
Step 2A, Prong I: does the claim recite an abstract idea, law of nature, or a natural phenomenon?
Yes: (an) abstract idea(s).
The “identifying” limitation in #1 above, as claimed an under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “identifying” in the context of the claim encompasses the person reading the specification document to learn requirements of the software system related to vehicle safety functions.
The “identifying” limitation in #2 above, as claimed an under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “identifying” in the context of the claim encompasses the person choosing tests for safety related APIs.
The “determining” limitation in #3 above, as claimed an under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “determining” in the context of the claim encompasses the person analyzing the source code or code portions and determining if those portions are covered in the one or more tests.
The “mapping” and “comparison” limitation in #4 above, as claimed an under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “mapping” in the context of the claim encompasses the person deciding that a test should be used for a requirement of the software system by reading/using the specification document.
The “generating” limitation in #5 above, as claimed an under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “generating” in the context of the claim encompasses the person, with aid of pen and paper, writing a report indicating the tests mapped to requirements with confidence level based on determination made of coverage of the requirements.
Step 2A, Prong II: Does the claim recite additional elements that integrate the judicial exception into a practical application?
No.
One or more of the claims recite the following additional elements:
Processing device (Claim 1, 8, 15)
Memory (Claim 8)
A non-transitory storage medium (Claim 15)
Step 2B: Does this claim recite additional elements that amount to significantly more than the judicial exception?
No.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of “processing device”, “memory”, and “non-transitory storage medium” amount to no more than mere instructions, or generic computer/computer components to carry out the exception. See MPEP 2106.05(f). The recitation of generic computer instruction and computer components to apply the judicial exception, and merely displaying data do not amount to significantly more, thus, cannot provide an inventive concept.
Claims 2, 9, and 16 recite:
Identifying source code corresponding to each requirement of the specification document
Comparing the source code corresponding to each requirement of the specification to the coverage of the source code for each of the one or more tests.
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 2 is a method
Claim 9 is a system
Claim 16 is a non-transitory medium
Step 2A, Prong I: does the claim recite an abstract idea, law of nature, or a natural phenomenon?
Yes: (an) abstract idea(s).
The “identifying” limitation in #6 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “identifying” in the context of this claim encompasses a person identifying source code matching the requirements of the specification document.
The “comparing” limitation in #7 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “comparing” in the context of this claim encompasses a person comparing the source code with each requirement of the specification document to how much the test covers the source code.
Claims 3, 10, and 17 merely further describe the claimed software system of Claims 1, 8, and 15, respectively.
Claims 4, 11, and 18 merely further describe the claimed safety related APIS of Claims 1, 8, and 15, respectively.
Claims 5, 12, and 19 recite:
Grouping the one or more tests for safety related APIs into a plurality of confidence levels
Iterating through the plurality of confidence levels to map the tests in each confidence level to requirements of the specification document
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 5 is a method
Claim 12 is a system
Claim 19 is a non-transitory medium
Step 2A, Prong I: does the claim recite an abstract idea, law of nature, or a natural phenomenon?
Yes: (an) abstract idea(s).
The “grouping” limitation in #8 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “grouping” in the context of this claim encompasses a person comparing tests with similar confidence levels and grouping them together.
The “iterating” limitation in #9 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “iterating” in the context of this claim encompasses a person picking a test based on confidence level and matching it to a requirement.
Claims 6, 13, and 20 recite:
Identifying requirements of the specification document not covered by the one or more tests; and
Providing a recommendation/indication of the requirements not covered
Step 1: Is the claim to a process, machine, manufacture, or composition of matter?
Yes.
Claim 6 is a method
Claim 13 is a system
Claim 20 is a non-transitory medium
Step 2A, Prong I: does the claim recite an abstract idea, law of nature, or a natural phenomenon?
Yes: (an) abstract idea(s).
The “identifying” limitation in #10 above, as claimed and under broadest reasonable interpretation (BRI), is a mental process that covers performance of the limitation in the mind. For example, “identifying” in the context of this claim encompasses a person looking at the requirements of the specification document and seeing what is not covered by the tests.
Step 2B: Does the claim recite additional elements that amount to significantly more than the judicial exception?
No.
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The “providing” limitation of #11 above, under broadest reasonable interpretation, these elements amount to mere outputting the result of a mental process (insignificant additional element and a post solution activity). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Claims 7 and 14 merely further describe the claimed coverage of source code of Claims 1, 8, and 15, respectively.
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(s) 1-4, 7-11, and 14-18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iacaruso et al. (US 20240329947 A1) hereinafter Iacaruso in view of Becker (US 20190378363 A1) in further view of Raju et al. (US 20230236802 A1) hereinafter Raju in further view of Ur et al. (US 6779135 B1) hereinafter Ur.
In regards to claim 1, Iacaruso discloses
A method comprising: identifying, from a specification document of a software system, requirements of the software system related to vehicle safety functions; (Iacaruso [0072] and [0074] discloses requirements/compliance with a functional safety-related specification, where the software product is verified to be compliant with the functional safety testing requirements. Further, [0003] discloses software product as an application, or operating system).
determining, for each of the one or more tests, coverage of source code of the software system; and (Iacaruso [0022]-[0025] discloses generating reports of code coverage and tested source code line to show how many source code lines have bene executed. This further involves validation test suite checks the invoked lines of source code and if the target is met for the compiler at 99% coverage).
mapping, by a processing device, each of the one or more tests to requirements of the software system identified from the specification document in view of the coverage of the source code of the software system for each of the one or more tests. (Iacaruso [0022] and [0086] discloses verification of functional safety testing requirements with compilation of software product by using the coverage data on a plurality of validation tests and coverage data for the complication of the software product on the lines of source code that are invoked during the compilation of the software product. Then, comparing the coverage data for compiler with the coverage data for the software and outputting the data to provide verification results of the functional safety testing requirements based on the comparison. Thus, this discloses how each of the tests are mapped/compared to the requirements for the software product, in view of the coverage data of source code).
Iacaruso lacks explicitly
identifying one or more tests for safety related application programming interfaces;
a comparison between source code corresponding to each requirement of the specification document and
Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system.
Becker teaches
identifying one or more tests for safety related application programming interfaces; (Becker [0106]-[0108] and [0018] discloses conducting a set of tests for submitted software modules (which utilize ROS API), and compute a functional safety compliance metric for each module by analyzing each software module using known tests and analytics).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified Iacaruso to incorporate the teachings of Becker to “identifying one or more tests for safety related application programming interfaces” in order to find tests related to the safety API which allows a proper test the API and ensure API effectiveness.
Iacaruso in view of Becker lacks explicitly
a comparison between source code corresponding to each requirement of the specification document and
Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system.
Raju teaches
a comparison between source code corresponding to each requirement of the specification document and (Raju [0049]-[0050] discloses using validation code that enables deliverables, such as source code, to be evaluated for compliance with one or more requirements of a compliance specification. The output generated is based on logs that identify each requirement, the compliance status of the deliverable with respect to each requirement, and portions of the deliverable that were evaluated for each requirement).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified Iacaruso in view of Becker to incorporate the teachings of Raju to “a comparison between source code corresponding to each requirement of the specification document and” in order to determine the compliance of the source code based on the requirements of the safety document and identify issues/missing requirements in an efficient way.
Iacaruso in view of Becker in further view of Raju lacks explicitly
Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system.
Ur teaches
Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system. (Ur column 1, lines 35-63 discloses coverage analysis of tests or a set of tests ensuring that all statements are executed, with each coverage requirement being achieved results in higher confidence levels in the “correctness” of the program. Thus, when a required overall level of coverage is achieved, it will be reasonable to assume the software under test is free of defects as it meets all the requirements. Further, in Iacaruso [0022] where a coverage report is generated based on code coverage and tested source code, it would be obvious to combine with the teachings Ur to further provide a confidence level based on the test’s coverage of the functional safety testing requirements presented in Iacaruo).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified Iacaruso in view of Becker in further view of Raju to incorporate the teachings of Ur to “Generating a coverage report indicating the one or more tests mapped to the requirements of the software system and a plurality of confidence levels corresponding to the one or more tests upon determining coverage of the requirements of the software system” in order to identify the tests that are the best for meeting the safety requirements, thus ensuring the safety standards for the vehicle is met.
In regards to claim 2, Iacaruso discloses
The method of claim 1, wherein mapping the one or more test to requirements of the specification document comprises: identifying the source code corresponding to each requirement of the specification document; and (Iacaruso [0036] and [0084] discloses the means for verifying functional safety testing requirements are based on a comparison of the first code coverage report for the compiler with the second code coverage report, where the second code coverage report is based on the lines of source code for the compiler that are invoked during the compilation of the software product)
comparing the source code corresponding to each requirement of the specification document to the coverage of the source code for each of the one or more tests. (Iacaruso [0031] and [0084]-[0086] discloses a comparison based on source code to generate a second code coverage report and a first code coverage report on a plurality of validation tests to verify functional safety testing requirements).
In regards to claim 3, Iacaruso discloses
The method of claim 1, wherein the software system comprises a vehicle integrated software system (Iacaruso [0011] and [0057] discloses the software products that comply with the FuSa standards may be integrated into autonomous vehicles, thus making it a vehicle integrated software system).
In regards to claim 4, Iacaruso discloses
The method of claim 1,
Iacaruso lacks explicitly
wherein the safety related APIs comprise automotive safety integrity level (ASIL) APIs associated with vehicle safety standards.
Becker teaches
wherein the safety related APIs comprise automotive safety integrity level (ASIL) APIs associated with vehicle safety standards (Becker [0108] discloses the functional safety compliance metric describing a number of mandatory and recommended measures to achieve different automotive safety integrity levels which is then used to analyze each software module).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified Iacaruso to incorporate the teachings of Becker to “wherein the safety related APIs comprise automotive safety integrity level (ASIL) APIs associated with vehicle safety standards” in order to see if the safety APIs are specifically used/compliant with vehicle safety standards, ensuring appropriate vehicle software safety analysis with relevant safety standards.
In regards to claim 7, Iacaruso discloses
The method of claim 1, wherein determining coverage of the source code from each of the one or more tests comprises executing a code coverage utility for each of the one or more tests identifying code paths of the source code executed during each of the one or more tests. (Iacaruso [0030] and [0036] discloses the toolchain safety application code coverage report shows which lines of source code of the compiler have been invoked (stimulated or used) during the build process. Code coverage is used to refer to the path or branch of the source code. As stated in the application [0031] code coverage utility tracks each line and branch of code performed during a test, therefore the code coverage report demonstrates the ability of the code coverage utility).
With regards to claim 8, it is a system having similar limitations cited in claim 1 above, thus claim 8 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 9, it is a system having similar limitations cited in claim 2 above, thus claim 9 is also rejected under the same rationale as cited in the rejection of claim 2 above.
With regards to claim 10, it is a system having similar limitations cited in claim 3 above, thus claim 10 is also rejected under the same rationale as cited in the rejection of claim 3 above.
With regards to claim 11, it is a system having similar limitations cited in claim 4 above, thus claim 11 is also rejected under the same rationale as cited in the rejection of claim 4 above.
With regards to claim 14, it is a system having similar limitations cited in claim 7 above, thus claim 14 is also rejected under the same rationale as cited in the rejection of claim 7 above.
With regards to claim 15, it is a non-transitory medium having similar limitations cited in claim 1 above, thus claim 15 is also rejected under the same rationale as cited in the rejection of claim 1 above.
With regards to claim 16, it is a non-transitory medium having similar limitations cited in claim 2 above, thus claim 16 is also rejected under the same rationale as cited in the rejection of claim 2 above.
With regards to claim 17, it is a non-transitory medium having similar limitations cited in claim 3 above, thus claim 17 is also rejected under the same rationale as cited in the rejection of claim 3 above.
With regards to claim 18, it is a non-transitory medium having similar limitations cited in claim 4 above, thus claim 18 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Claim(s) 5, 12, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iacaruso et al. (US 20240329947 A1) hereinafter Iacaruso in view of Becker (US 20190378363 A1) in further view of Raju et al. (US 20230236802 A1) hereinafter Raju in further view of Ur et al. (US 6779135 B1) hereinafter Ur in further view of Bhattacharjee et al. (US 20180349257 A1) hereinafter Bhattacharjee.
In regards to claim 5, Iacaruso in view of Becker in further view of Raju in further view of Ur discloses
The method of claim 1
The combination lacks explicitly
grouping the one or more tests for safety related APIs into the plurality of confidence levels; and iterating through the plurality of confidence levels to map the tests in each confidence level to requirements of the specification document.
Bhattacharjee teaches
grouping the one or more tests for safety related APIs into a plurality of confidence levels; and (Bhattacharjee [0069] discloses test consisting of confidence levels, where confidence level can refer to the likelihood that a test corresponds to the affected functions. The tests are grouped based on score and can be automatically determined to be used. The example provided is a group of tests from 100 tests with scores of 70 or over).
iterating through the plurality of confidence levels to map the tests in each confidence level to requirements of the specification document. (Bhattacharjee [0004], [0064] and [0066] discloses set of tests to verify compliance with a specific requirement, where this is done using a mapping table data store to communicate with the test prediction system to determine which tests should be executed based on a high degree of confidence).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified the combination to incorporate the teachings of Bhattacharjee to “grouping the one or more tests for safety related APIs into a plurality of confidence levels; and iterating through the plurality of confidence levels to map the tests in each confidence level to requirements of the specification document” in order to have the best tests with the most coverage of requirements be used, ensuring that the software is fully tested and safe for the user.
With regards to claim 12, it is a system having similar limitations cited in claim 5 above, thus claim 12 is also rejected under the same rationale as cited in the rejection of claim 5 above.
With regards to claim 19, it is a non-transitory medium having similar limitations cited in claim 5 above, thus claim 19 is also rejected under the same rationale as cited in the rejection of claim 5 above.
Claim(s) 6, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Iacaruso et al. (US 20240329947 A1) hereinafter Iacaruso in view of Becker (US 20190378363 A1) in further view of Raju et al. (US 20230236802 A1) hereinafter Raju in further view of Ur et al. (US 6779135 B1) hereinafter Ur in further view of Gueta et al. (US 12169449 B1) hereinafter Gueta.
In regards to claim 6, Iacaruso in view of Becker in further view of Raju in further view of Ur discloses
The method of claim 1
The combination lacks explicitly
Identifying requirements of the specification document not covered by the one or more tests; and providing a recommendation/indication of the requirements not covered.
Gueta teaches
Identifying requirements of the specification document not covered by the one or more tests; and providing a recommendation/indication of the requirements not covered. (Gueta column 4, lines 38-52 and column 2, lines 57-62 discloses analyzing a test coverage and missing a requirement, where the model then analyzes historic information and provides a recommendation of a severity and priority in order to create new test features to provide 100% test coverage).
It would have been obvious to one ordinary skill in the art before the effective filing date of claimed invention to have modified the combination to incorporate the teachings of Gueta to “Identifying requirements of the specification document not covered by the one or more tests; and providing a recommendation/indication of the requirements not covered” in order to make sure all requirements listed in the specification are tested and met ensuring safe vehicle software.
With regards to claim 13, it is a system having similar limitations cited in claim 6 above, thus claim 13 is also rejected under the same rationale as cited in the rejection of claim 6 above.
With regards to claim 20, it is a non-transitory medium having similar limitations cited in claim 6 above, thus claim 20 is also rejected under the same rationale as cited in the rejection of claim 6 above.
Response to Arguments
Response to 101 remarks:
Applicant's arguments filed 8/7/2026 have been fully considered but they are not persuasive. Regarding the limitation “Identifying, from a specification document of a software system…” examiner would treat this as an abstract idea, as though a manual and time-consuming process, can still be done mentally and has been used in conventional testing. Therefore, the claim as currently drafted, can merely encompass a person reading a specification document and determining what requirements are related to vehicle safety. Further “identify one or more tests for safety related application programming interface” to a person one of ordinary skill in the art and under BRI can also be done mentally and merely encompasses a person reading/observing the relevant safety API from a list and then choosing the test deemed necessary using personal opinion/objectives/requirements. Also, the “determining” limitation could encompass a person after deciding which tests to use can then determine how much of the source code would be covered/simulated during the testing. While the manual inspection of code is tedious, this type of testing observation can still be done mentally, thus rendering the limitation as abstract. Similarly, the “mapping” limitation under BRI encompasses a person to use the previously identified tests and match them to requirements identified from the specification document, where this process can be done mentally by reading the requirements and choosing the appropriate test. The “processing device” in this instance would be treated as merely using generic computer or computer components as a tool to perform/apply the abstract idea.
Further, the newly amended portion “comparison between source code corresponding to each requirement of the specification document” the examiner would treat as an abstract idea, mental process. For example, a person can read both the source code and the requirements in the specification document and have an opinion on whether each requirement is met or not. Additionally, the new amended portion “generating a coverage report…” the examiner would treat, under BRI, a mental process that can be done in the human mind or with aid of a pen and paper.
Response to 103 remarks:
Applicant’s arguments with respect to claim(s) 1,8, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied or has been combined with an additional reference in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 CHRISTOPHER J SALLEY whose telephone number is (571)272-6355. The examiner can normally be reached Mon-Fri, 7:30am-5pm.
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, Chat Do can be reached at (571) 272-3721. 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.
/CHRISTOPHER J SALLEY/Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights