DETAILED ACTION
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 .
Response to Amendment
The amendment filed on 01/28/2026 has been entered. Claims 1-5, 7-13 and 15-16 are pending in this application. Claims 6 and 14 have been canceled. Applicant’s amendments to the Claims have overcome the 112 rejection set forth in the previous Non-Final Office Action mailed 10/28/2025.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-5, 7-13, and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kislovskiy et al. (US 20180341571 A1) in view of Rodriguez et al. (US 20200073651 A1) and Morley et al. (US 20210004313 A1)
Regarding claim 1, Kislovskiy teaches an electronic apparatus comprising:
a memory configured to store computer-executable instructions ([0042]);
and at least one processor configured to access the memory and execute the instructions ([0042]), wherein the at least one processor is configured to:
identify, from a third-party autonomous driving module, at least one of a software version of the third-party autonomous driving module or identification information of the third-party autonomous driving module, or any combination thereof ([0053], where software versions, i.e. autonomous driving modules, are stored in software version logs where they are identified as verified, new, or in-progress software versions);
output a test scenario related to autonomous driving ([0059] and [0136-0137], where driving software is developed by being outputted testing scenarios to ensure safety validation; [0067] and [0137], where driving software is verified by vehicles performing test scenarios in the form of specific travel routes) …;
and perform transmitting of the third-party autonomous driving module to a vehicle based on the test scenario and a control signal of the third-party autonomous driving module corresponding to the test scenario ([0053] and [0059], where vehicles are certified via their results of test scenarios and distributed to vehicles throughout the region to be subsequently verified),
wherein the at least one processor is further configured to:
perform the transmitting of the third-party autonomous driving module and the vehicle based on result data from a tested scenario ([0053] and [0067-0068], where software is tested and verified if software achieves “the predetermined confidence threshold”).
Kislovskiy teaches verifying a driving software by analyzing its performance in test scenarios related to autonomous driving, and distributing this software of a third-party autonomous driving module to vehicles based on the verification. However, Kislovskiy does not include an authentication step to ensure the software being tested and transmitted is not tampered with, nor is it explicit in how it transmits the software to the vehicle. It does not teach that the testing of the software is based on a certificate of the third-party autonomous driving module being verified as at least one of the software version or the identification information, or any combination thereof is transmitted to a certificate management server, nor that the transmitting of software is done by performing a routing of a gateway.
In the same field of endeavor, Rodriguez teaches a method of validating the downloading of new software, wherein driving software is verified based on a certificate of the third-party autonomous driving module being verified as at least one of the software version or the identification information, or any combination thereof is transmitted to a certificate management server ([0023-0024], [0046], and [0076], where a certificate for a validation request in the form of a ledger entry is sent for validation to a software distribution program, which checks the ledger entry against a maintained blockchain for validation; [0016] and [0022], where said ledger entry includes a hash value of the software package, i.e. identification information, and “version information for the available software”, i.e. software version). Note that the network that performs the operations of Rodriguez is taught to be a gateway computer ([0081]).
A skilled artisan would have been able to modify the operations performed by the processor of Kislovskiy to include this authenticating step and details for performing it as taught by Rodriguez. This step would advantageously be performed whenever software versions are being transmitted between components of the AV Software Management System of Kislovskiy as shown in Fig. 2. This modification ensures that the software is verified for authenticity before it is tested to determine verification of accuracy and safety. Additionally, as the network for these operations is taught by Rodriguez to be performed via gateway computers, it would have been obvious to the skilled artisan that the transmission of software and any other data over this network is done by the routing of a gateway as performed as part of the well-known operations of gateway computers.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to modify Kislovskiy to include an authentication step based on a reasonable expectation of success and motivation ensure that the software to be tested is properly installed and has not been tampered with in order to ensure the correct software is tested during the verification of its accuracy. This also enhances the security of the system by ensuring that testing and accuracy verification operations are only performed on verified versions of software.
Neither Kislovskiy nor Rodriguez of the prior combination teach that the at least one processor is further configured to: generate a correct answer signal for the test scenario; and obtain result data via comparison between the correct answer signal and the control signal based on the control signal being received from the third-party autonomous driving module. Kislovskiy instead teaches that result data is produced by the assessment of the performance of vehicle driving software, which directly compares the actions taken by a new software during a scenario to the actions of an average human driver ([0137]), and determines if the performance of the vehicle while controlled by the software is “safe enough to initiate the verification process”, which is defined as being preferable to an average human driver in said scenarios ([0059] and [0067]). This comparison is directly against actions performed by an average human driver, with no intermediary step of checking correctness against a correct answer signal as claimed.
In the same field of endeavor, Morley teaches a software validation system for autonomous vehicles, wherein the at least one processor of said system is configured to:
generate a correct answer signal for the test scenario ([0058-0059], where each scenario generates an expected outcome that determines whether the autonomous control software “passes” or “fails” said scenario);
and obtain result data via comparison between the correct answer signal and the control signal based on the control signal being received from the third-party autonomous driving module ([0058-0059], where the signals produced by the vehicle controlled by the autonomous control software, i.e. third-party autonomous driving module, during the scenario are compared to the expected outcome signals of the scenario, and result data in a variety of forms, including a simple “passed” or “failed” if the vehicle collides with another object, is obtained).
Note that the autonomous control software of Morley is validated based on a result of this analysis ([0068-0069] and [0073], where the autonomous control software is validated if the comparison of its result data, i.e. the number of scenarios “passed” by the control software, to the result data of a validation model, i.e. the number of scenarios “passed” by the validation model, is higher than a certain predetermined threshold).
A skilled artisan would have been able to modify the scenario analysis of the prior combination by including an intermediary determination of a “passing” or “failing” of the tested scenarios as taught by Morley. This would result in the certification of new vehicle software that is performed by Kislovskiy now including an intermediary step of being compared to a correct action signal for a scenario before said actions are compared to an average human driver. The result data produced by the new driving software would be given a “pass” or “fail” over tested scenarios and would then be compared to whether an average human driver would “pass” or “fail” those same scenarios, where any subsequent routing of the gateway would be performed if the number of scenarios “passed” by the new driving software are determined to be safer than an average human driver above a certain degree of threshold confidence, with said threshold confidence being taught by Kislovskiy ([0067-0068]).
It would have been obvious to one of ordinary skill in the art at the effective date of filing to modify the scenario analysis of the prior combination based on a reasonable expectation of success and motivation to enhance the testing of autonomous control software by standardizing the analysis of said testing. As taught by Morley, this provides a benchmark for which to evaluate the response of autonomous control software to determine effectiveness rather than simply observing and “guessing” ([0020]) as the prior combination does by comparing to an average human driver. Additionally, an average human driver may make mistakes in a driving scenario, so a correct signal is needed to determine whether the actions taken by the new driving software, the average human driver, or some combination thereof, are correct, especially when the actions taken during the testing scenarios differ between the two.
Regarding claim 2, the prior art remains as applied in claim 1. Kislovskiy teaches wherein the at least one processor is further configured to:
identify at least one of the software version or the identification information, or any combination thereof from the third-party autonomous driving module based on the vehicle and the third-party autonomous driving module being connected to each other ([0053] and [0158-0159], where software versions, i.e. autonomous driving modules, are stored in software version logs where they are identified as verified, new, or in-progress software versions, and where the AV software management system can identify a downloaded software as a new software release and sets risk thresholds correspondingly).
Kislovskiy does not teach that the processor is further configured to disconnect the vehicle and the third-party autonomous driving module from each other based on at least one of the software version or the identification information, or any combination thereof not being identified.
Rodriguez teaches determining whether at least one of the software version or the identification information, or any combination thereof of a verification is request is not being identified ([0010] and [0026]). This determination is done so the vehicle can download the package again ([0026]).
A skilled artisan would have been able to modify Kislovskiy to include this determination when software is being distributed to the vehicles. As the determination of failure to verify the authenticity of the software is the result of tampering or otherwise harmful malfunctions that could jeopardize the operation of the vehicle if the software were ran, it would have been obvious to the skilled artisan to disconnect the vehicle and the third-party autonomous driving module from each other when such a determination of failure is confirmed in order to assure that the software is not ran on the vehicle.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to include a determination of failure to identify an autonomous driving module into the operations of Kislovskiy based on a reasonable expectation of success and motivation, as taught by Rodriguez, to ensure software integrity in case said software has been tampered with ([0010]). It also advantageously allows the vehicle to redownload and reverify the authenticity of software in case it is downloaded improperly.
Regarding claim 3, the prior art remains as applied in claim 1. Kislovskiy does not teach the limitations of the claim.
Rodriguez teaches wherein the at least one processor is configured to transmit a message related to a certificate issuance request to the vehicle based on the verification of the certificate being failed ([0010], [0026], and [0078], where a notice of failure is sent to the vehicle).
A person having ordinary skill in the art would have been able to include this message of an error of verification in the operations performed by Kislovskiy. Rodriguez teaches that this notice of failure is sent so the vehicle can redownload the vehicle software ([0026]). As the failure to verify the authenticity of the software is caused by tampering or otherwise harmful malfunctions that could jeopardize the operation of the vehicle if the software were ran, it would have been obvious to the skilled artisan to also send a message to the third-party autonomous driving module so that the unverified software can uninstall from the vehicle. The unverified software will be replaced by the redownloaded software, so it serves no purpose remaining installed in the vehicle.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to include a sending of a notice of failure to verify the authenticity of an autonomous driving module into the operations of Kislovskiy based on a reasonable expectation of success and motivation, as taught by Rodriguez, to ensure software integrity in case said software has been tampered with ([0010]). It also advantageously allows the vehicle to redownload and reverify the authenticity of software in case it is downloaded improperly.
Regarding claim 4, the prior art remains as applied in claim 1. Rodriguez teaches wherein the at least one processor is further configured to:
obtain a transaction record corresponding to the certificate from a blockchain stored in the certificate management server ([0015-0016] and [0024], where the ledger entry, i.e. certificate, of the requesting vehicle is compared to the corresponding transactions of said ledger entry that are memorialized in the blockchain ledger);
and verify the certificate based on at least one of the transaction record, the identification information, or a model information of the vehicle, or any combination thereof ([0023-0024], where the ledger entry is verified if the data values of the ledger entry produce a favorable comparison to the corresponding information of the transaction record; [0016] and [0022], where the data of said ledger entry includes a hash value of the software package, i.e. identification information, and “version information for the available software”, i.e. software version).
Regarding claim 5, the prior art remains as applied in claim 1. Kislovskiy teaches wherein the at least one processor is further configured to:
identify driving information related to an image-based advanced driver assistance system (ADAS) and road information of a predetermined road section ([0047] and [0066], where the vehicles record log data comprising image data, camera data, and telemetry data to be stored in the software management system and used to generate test scenarios);
identify a traffic scenario related to the autonomous driving of the vehicle based on the driving information and the road information ([0057-0060], where test scenarios generated for certifying software are generated based on identifying risk and event quantifiers associated with traffic scenarios; [0063-67], where transport instructions for a vehicle are generated so that a vehicle software to be verified runs for specific segments classified by risk values associated with traffic scenarios; [0057] and [0067], where said traffic scenarios are accessed based on traffic, i.e. driving information, and road conditions, i.e. road information);
generate the test scenario based on the driving information, the road information, and the traffic scenario ([0057-0060], where test scenarios generated for certifying software are generated based on identifying risk and event quantifiers associated with traffic scenarios; [0057], where the scenario takes into account the traffic, i.e. driving information, the road conditions, i.e. the road information, and the risk and harmful event values, i.e. the traffic scenario);
and output the test scenario to the third-party autonomous driving module ([0059] and [0136-0137], where the AV software management system executes a full forward simulation using this real-world log data that is replayed by the simulation engine).
Regarding claim 7, the prior art remains as applied in claim 6. Kislovskiy teaches wherein the at least one processor is further configured to stop the transmitting of the third-party autonomous driving module and the vehicle based on the result data being smaller than the predetermined threshold value ([0138] and see Fig. 9, where if a software module fails its certification or is otherwise not certified at step 935, it is sent back to debugging and simulation testing at step 940 rather than being transmitted to vehicles via distribution at step 960; [0059] and [0067], where the certification fails if the result data is less than a threshold confidence level safer than an average human driver). This transmitting of the vehicle software is performed via the routing of the gateway as is taught by Rodriguez of the prior combination ([0081]).
Regarding claim 8, the prior art remains as applied in claim 1. Kislovskiy teaches
wherein the software version includes a version of software running the third-party autonomous driving module ([0053], where the software in the software version logs includes verified, new, or in-progress software versions),
wherein the identification information includes information allowing the vehicle to identify the third-party autonomous driving module ([0053], wherein the software is identified as verified, new, or in-progress software; [0061] and [0067-0068], where the vehicle can selectively trigger different software and send log data indicative of the identified software to the management system for analysis).
Rodriguez teaches wherein the certificate includes information on authorization for the third-party autonomous driving module to control the vehicle by the certificate management server ([0023]).
Regarding claim 9, Kislovskiy teaches a control method comprising:
identifying by at least one processor ([0042]), from a third-party autonomous driving module, at least one of a software version of the third-party autonomous driving module or identification information of the third-party autonomous driving module, or any combination thereof ([0053], where software versions, i.e. autonomous driving modules, are stored in software version logs where they are identified as verified, new, or in-progress software versions);
outputting, by the at least one processor ([0042]), a test scenario related to autonomous driving ([0059] and [0136-0137], where driving software is developed by being outputted testing scenarios to ensure safety validation; [0067] and [0137], where driving software is verified by vehicles performing test scenarios in the form of specific travel routes);
and performing, by the at least one processor, transmitting of the third-party autonomous driving module to the vehicle based on the test scenario and a control signal of the third-party autonomous driving module corresponding to the test scenario ([0053] and [0059], where vehicles are certified via their results of test scenarios and distributed to vehicles throughout the region to be subsequently verified),
wherein the performing of the transmitting of the third-party autonomous driving module and the vehicle includes:
performing the transmitting of the third-party autonomous driving module and the vehicle based on result data from a tested scenario ([0053] and [0067-0068], where software is tested and verified if software achieves “the predetermined confidence threshold”).
Kislovskiy teaches verifying a driving software by analyzing its performance in test scenarios related to autonomous driving, and distributing this software of a third-party autonomous driving module to vehicles based on the verification. However, Kislovskiy does not include an authentication step to ensure the software being tested and transmitted is not tampered with, nor is it explicit in how it transmits the software to the vehicle. It does not teach that the testing of the software is based on a certificate of the third-party autonomous driving module being verified as at least one of the software version or the identification information, or any combination thereof is transmitted to a certificate management server, nor that the transmitting of software is done by performing a routing of a gateway.
In the same field of endeavor, Rodriguez teaches a method of validating the downloading of new software, wherein driving software is verified based on a certificate of the third-party autonomous driving module being verified as at least one of the software version or the identification information, or any combination thereof is transmitted to a certificate management server ([0023-0024], [0046], and [0076], where a certificate for a validation request in the form of a ledger entry is sent for validation to a software distribution program, which checks the ledger entry against a maintained blockchain for validation; [0016] and [0022], where said ledger entry includes a hash value of the software package, i.e. identification information, and “version information for the available software”, i.e. software version). Note that the network that performs the operations of Rodriguez is taught to be a gateway computer ([0081]).
A skilled artisan would have been able to modify the operations performed by the processor of Kislovskiy to include this authenticating step and details for performing it as taught by Rodriguez. This step would advantageously be performed whenever software versions are being transmitted between components of the AV Software Management System of Kislovskiy as shown in Fig. 2. This modification ensures that the software is verified for authenticity before it is tested to determine verification of accuracy and safety. Additionally, as the network for these operations is taught by Rodriguez to be performed via gateway computers, it would have been obvious to the skilled artisan that the transmission of software and any other data over this network is done by the routing of a gateway as performed as part of the well-known operations of gateway computers.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to modify Kislovskiy to include an authentication step based on a reasonable expectation of success and motivation ensure that the software to be tested is properly installed and has not been tampered with in order to ensure the correct software is tested during the verification of its accuracy. This also enhances the security of the system by ensuring that testing and accuracy verification operations are only performed on verified versions of software.
Neither Kislovskiy nor Rodriguez of the prior combination teach that the method includes generating a correct answer signal for the test scenario; and obtaining result data via comparison between the correct answer signal and the control signal based on the control signal being received from the third-party autonomous driving module. Kislovskiy instead teaches that result data is produced by the assessment of the performance of vehicle driving software, which directly compares the actions taken by a new software during a scenario to the actions of an average human driver ([0137]), and determines if the performance of the vehicle while controlled by the software is “safe enough to initiate the verification process”, which is defined as being preferable to an average human driver in said scenarios ([0059] and [0067]). This comparison is directly against actions performed by an average human driver, with no intermediary step of checking correctness against a correct answer signal as claimed.
In the same field of endeavor, Morley teaches a software validation system for autonomous vehicles, wherein the at least one processor of said system is configured to:
generate a correct answer signal for the test scenario ([0058-0059], where each scenario generates an expected outcome that determines whether the autonomous control software “passes” or “fails” said scenario);
and obtain result data via comparison between the correct answer signal and the control signal based on the control signal being received from the third-party autonomous driving module ([0058-0059], where the signals produced by the vehicle controlled by the autonomous control software, i.e. third-party autonomous driving module, during the scenario are compared to the expected outcome signals of the scenario, and result data in a variety of forms, including a simple “passed” or “failed” if the vehicle collides with another object, is obtained).
Note that the autonomous control software of Morley is validated based on a result of this analysis ([0068-0069] and [0073], where the autonomous control software is validated if the comparison of its result data, i.e. the number of scenarios “passed” by the control software, to the result data of a validation model, i.e. the number of scenarios “passed” by the validation model, is higher than a certain predetermined threshold).
A skilled artisan would have been able to modify the scenario analysis of the prior combination by including an intermediary determination of a “passing” or “failing” of the tested scenarios as taught by Morley. This would result in the certification of new vehicle software that is performed by Kislovskiy now including an intermediary step of being compared to a correct action signal for a scenario before said actions are compared to an average human driver. The result data produced by the new driving software would be given a “pass” or “fail” over tested scenarios and would then be compared to whether an average human driver would “pass” or “fail” those same scenarios, where any subsequent routing of the gateway would be performed if the number of scenarios “passed” by the new driving software are determined to be safer than an average human driver above a certain degree of threshold confidence, with said threshold confidence being taught by Kislovskiy ([0067-0068]).
It would have been obvious to one of ordinary skill in the art at the effective date of filing to modify the scenario analysis of the prior combination based on a reasonable expectation of success and motivation to enhance the testing of autonomous control software by standardizing the analysis of said testing. As taught by Morley, this provides a benchmark for which to evaluate the response of autonomous control software to determine effectiveness rather than simply observing and “guessing” ([0020]) as the prior combination does by comparing to an average human driver. Additionally, an average human driver may make mistakes in a driving scenario, so a correct signal is needed to determine whether the actions taken by the new driving software, the average human driver, or some combination thereof, are correct, especially when the actions taken during the testing scenarios differ between the two.
Regarding claim 10, the prior art remains as applied in claim 9. Kislovskiy teaches wherein the identifying of the at least one of the software version or the identification information, or any combination thereof includes:
identifying at least one of the software version or the identification information, or any combination thereof from the third-party autonomous driving module based on the vehicle and the third-party autonomous driving module being connected to each other ([0053] and [0158-0159], where software versions, i.e. autonomous driving modules, are stored in software version logs where they are identified as verified, new, or in-progress software versions, and where the AV software management system can identify a downloaded software as a new software release and sets risk thresholds correspondingly).
Kislovskiy does not teach that operations include a step of disconnecting the vehicle and the third-party autonomous driving module from each other based on at least one of the software version or the identification information, or any combination thereof not being identified.
Rodriguez teaches determining whether at least one of the software version or the identification information, or any combination thereof of a verification is request is not being identified ([0010] and [0026]). This determination is done so the vehicle can download the package again ([0026]).
A skilled artisan would have been able to modify Kislovskiy to include this determination when software is being distributed to the vehicles. As the determination of failure to verify the authenticity of the software is the result of tampering or otherwise harmful malfunctions that could jeopardize the operation of the vehicle if the software were ran, it would have been obvious to the skilled artisan to disconnect the vehicle and the third-party autonomous driving module from each other when such a determination of failure is confirmed in order to assure that the software is not ran on the vehicle.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to include a determination of failure to identify an autonomous driving module into the operations of Kislovskiy based on a reasonable expectation of success and motivation, as taught by Rodriguez, to ensure software integrity in case said software has been tampered with ([0010]). It also advantageously allows the vehicle to redownload and reverify the authenticity of software in case it is downloaded improperly.
Regarding claim 11, the prior art remains as applied in claim 9. Kislovskiy does not teach the limitations of the claim.
Rodriguez teaches wherein the outputting of the test scenario related to the autonomous driving includes: transmitting a message related to a certificate issuance request to the vehicle based on the verification of the certificate being failed ([0010], [0026], and [0078], where a notice of failure is sent to the vehicle).
A person having ordinary skill in the art would have been able to include this message of an error of verification in the operations performed by Kislovskiy. Rodriguez teaches that this notice of failure is sent so the vehicle can redownload the vehicle software ([0026]). As the failure to verify the authenticity of the software is caused by tampering or otherwise harmful malfunctions that could jeopardize the operation of the vehicle if the software were ran, it would have been obvious to the skilled artisan to also send a message to the third-party autonomous driving module so that the unverified software can uninstall from the vehicle. The unverified software will be replaced by the redownloaded software, so it serves no purpose remaining installed in the vehicle.
It would have been obvious to one of ordinary skill in the art at the effective date of filing to include a sending of a notice of failure to verify the authenticity of an autonomous driving module into the operations of Kislovskiy based on a reasonable expectation of success and motivation, as taught by Rodriguez, to ensure software integrity in case said software has been tampered with ([0010]). It also advantageously allows the vehicle to redownload and reverify the authenticity of software in case it is downloaded improperly.
Regarding claim 12, the prior art remains as applied in claim 9. Rodriguez teaches wherein the outputting of the test scenario related to the autonomous driving includes:
obtaining a transaction record corresponding to the certificate from a blockchain stored in the certificate management server ([0015-0016] and [0024], where the ledger entry, i.e. certificate, of the requesting vehicle is compared to the corresponding transactions of said ledger entry that are memorialized in the blockchain ledger);
and verifying the certificate based on at least one of the transaction record, the identification information, or a model information of the vehicle, or any combination thereof ([0023-0024], where the ledger entry is verified if the data values of the ledger entry produce a favorable comparison to the corresponding information of the transaction record; [0016] and [0022], where the data of said ledger entry includes a hash value of the software package, i.e. identification information, and “version information for the available software”, i.e. software version).
Regarding claim 13, the prior art remains as applied in claim 9. Kislovskiy teaches wherein the outputting of the test scenario related to the autonomous driving includes:
identifying driving information related to an image-based advanced driver assistance system (ADAS) and road information of a predetermined road section ([0047] and [0066], where the vehicles record log data comprising image data, camera data, and telemetry data to be stored in the software management system and used to generate test scenarios);
identify a traffic scenario related to the autonomous driving of the vehicle based on the driving information and the road information ([0057-0060], where test scenarios generated for certifying software are generated based on identifying risk and event quantifiers associated with traffic scenarios; [0063-67], where transport instructions for a vehicle are generated so that a vehicle software to be verified runs for specific segments classified by risk values associated with traffic scenarios; [0057] and [0067], where said traffic scenarios are accessed based on traffic, i.e. driving information, and road conditions, i.e. road information);
generate the test scenario based on the driving information, the road information, and the traffic scenario ([0057-0060], where test scenarios generated for certifying software are generated based on identifying risk and event quantifiers associated with traffic scenarios; [0057], where the scenario takes into account the traffic, i.e. driving information, the road conditions, i.e. the road information, and the risk and harmful event values, i.e. the traffic scenario);
and output the test scenario to the third-party autonomous driving module ([0059] and [0136-0137], where the AV software management system executes a full forward simulation using this real-world log data that is replayed by the simulation engine).
Regarding claim 15, the prior art remains as applied in claim 9. Kislovskiy teaches wherein the at least one processor is further configured to stop the transmitting of the third-party autonomous driving module and the vehicle based on the result data being smaller than the predetermined threshold value ([0138] and see Fig. 9, where if a software module fails its certification or is otherwise not certified at step 935, it is sent back to debugging and simulation testing at step 940 rather than being transmitted to vehicles via distribution at step 960; [0059] and [0067], where the certification fails if the result data is less than a threshold confidence level safer than an average human driver). This transmitting of the vehicle software is performed via the routing of the gateway as is taught by Rodriguez of the prior combination ([0081]).
Regarding claim 16, the prior art remains as applied in claim 9. Kislovskiy teaches
wherein the software version includes a version of software running the third-party autonomous driving module ([0053], where the software in the software version logs includes verified, new, or in-progress software versions),
wherein the identification information includes information allowing the vehicle to identify the third-party autonomous driving module ([0053], wherein the software is identified as verified, new, or in-progress software; [0061] and [0067-0068], where the vehicle can selectively trigger different software and send log data indicative of the identified software to the management system for analysis).
Rodriguez teaches wherein the certificate includes information on authorization for the third-party autonomous driving module to control the vehicle by the certificate management server ([0023]).
Response to Arguments
Applicant's arguments filed 01/28/2026 have been fully considered.
Regarding the rejection under 35 U.S.C 103, applicant argues “Kislovskiy, Rodriguez, Morley, taken individually or combined, fail to teach or suggest inventive features of the presently claimed invention”, specifically contending that “Morley merely discloses determining whether a given scenario has been passed or failed based on results of a simulation” and thus does not teach the limitations amended to be included in the independent claims. This argument is unpersuasive.
As stated in the rejection above, the prior combination of Kislovskiy and Rodriguez teaches performing the routing of the third-party autonomous driving module and the vehicle. Morley is relied upon to teach the rest of the limitations added to the independent claims via the filed amendment. To that end, Morley teaches the generating of a correct answer signal for a test scenario in the form of an “expected outcome” of a given test scenario ([0058]). Morley then compares characteristics of the outcome of a given scenario as simulated by the autonomous control software, i.e. the control signal being received from the third-party autonomous driving module, to characteristics of the expected outcome of the scenario, i.e. the correct answer signal, to determine if the autonomous control software “passed” or “failed” a scenario ([0059-0060]). The resulting data of these comparisons for a number of scenarios is then obtained and analyzed to see if the autonomous control software, i.e. the third-party autonomous driving module, meets requirements for validation ([0071]). One such requirement is based on the result data and a predetermined threshold value as the results of comparing the output of the autonomous control software to the expected outcome, i.e. the result data, is checked to see if a number of “passed” scenarios matches a predetermined threshold number of scenarios as “passed” by a validation model ([0068]).
Conclusion
The following prior art made of record and not relied upon by the examiner is considered pertinent to applicant’s disclosure:
Wilmes et al. (US 20240184686 A1)
Kim et al. (US 20250291977 A1)
Rossetti et al. (US 20240430238 A1)
Smith et al. (US 20200374700 A1)
Goldberg (US 20190129831 A1)
THIS ACTION IS MADE FINAL. 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 JACK R BREWER whose telephone number is (571)272-4455. The examiner can normally be reached 10AM-6PM.
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, Angela Ortiz can be reached at 571-272-1206. 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.
/JACK ROBERT BREWER/Examiner, Art Unit 3663
/ADAM D TISSOT/Primary Examiner, Art Unit 3663
Prosecution Insights