DETAILED ACTION
This Action addresses the communication received on 15 Sep 2025. Applicant has amended Claims 1, 2, and 5; added Claims 7-9; and cancelled Claim 3. The Office rejects pending Claims 1-2 and 4-9 as detailed below.
Response to Amendments
Double Patenting
Based on Applicant’s amendment to the claims, the Office withdraws the non-statutory double patenting rejection to Claim 1 and the corresponding dependent claims.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2 and 4-9 are rejected under 35 U.S.C. 103 as being unpatentable over
David et al. (U.S. Pub. 2020/0174778 [IDS entry]) in view of Nakahara et al. (U.S. Pub. 20210173634).
As for Claim 1, David teaches to receive, from a server, prerequisite condition information including one or more prerequisite conditions to be satisfied by a vehicle when executing a software update of an electronic control unit installed in the vehicle; determine, before performing an installation of the software and after performing a download of the software, whether the prerequisite conditions included in the prerequisite condition information acquired by the one or more processors are satisfied; update the software of the electronic control unit when determining that all of the prerequisite conditions are satisfied (¶17|8: “One or more prerequisites, including but not limited to whether an initiation device has been actuated, whether an engine of the vehicle is off, whether an ignition key of the vehicle is on, whether a battery of the mobile computing device and/or the vehicle has a sufficient level of charge, and whether a parking brake is set, are checked by the server computing system, the vehicle, and/or the mobile computing device before allowing the update to be initiated.”); [...] after first determining that not all of the prerequisite conditions are satisfied; re-determine whether the prerequisite conditions are satisfied in response to determining that not all of the prerequisite conditions are satisfied[...] since the one or more processors first determine that not all of the prerequisite conditions are satisfied (¶57|12: “If the vehicle state conditions do not indicate that the vehicle 106 is ready for an update, then the result of decision block 332 is NO, and the method 300 returns to terminal B to recheck the vehicle state conditions.”); and transmit error information to the server in response to re-determining that not all of the prerequisite conditions are satisfied [...] since the one or more processors first determine that not all of the prerequisite conditions are satisfied (¶53|1: “Returning to decision block 326, if the HMI device has been actuated for at least the threshold amount of time, then the result of decision block 326 is YES, and the method 300 proceeds to a continuation terminal [i.e., determining if the prerequisite conditions are met after a predetermined time period] ("terminal C").” Further, (¶56|1) “Although this example displays checkmarks and "X" indicators as illustrating the success state and the failure state [of prerequisite conditions], respectively, it is understood that in some embodiments other techniques may be used to indicate success and failure, including but not limited to different colors, different shapes, or organization of indicators into different areas or groups.”) David does not explicitly teach an update timeout.
But Nakahara teaches determine whether a predetermined amount of time has lapsed (¶71|8: “Thereafter, when the timeout of the limit time of the software update is notified during the processing of storing the difference data transmitted from the gateway 12 (S1402), the vehicle control device 11 transmits a forced interruption response M1401 to the gateway 12 and forcibly terminates the software update processing.”)
It 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 to combine David and Nakahara because enforcing an overall update timeout ensures that the process does not continue indefinitely.
As for Claim 2, which depends on Claim 1, David teaches determine, after performing the installation, whether the prerequisite conditions are satisfied; continue the software update when determining that all of the prerequisite conditions are satisfied (¶60|1: “At block 340, the communication relay module 210 transmits the result to the mobile computing device 102. In some embodiments, the result may indicate a success of the software update or a failure of the software update, and may include separate results for separate software updates and/or updatable components 110. In some embodiments, intermediate results, such as a predicted amount of time before the software update is completed, or a percentage of the software update that has currently been completed, may be transmitted by the OTA updater device 108 and relayed to the mobile computing device 102 by the communication relay module 210 in order to present a progress indication to the operator during application of the software update.”); and cancel the software update when determining that not all of the prerequisite conditions are satisfied, regardless of whether the predetermined amount of time has been elapsed since the one or more processors firstly determine that not all of the prerequisite conditions are satisfied (¶62|1: “Returning to decision block 341 of FIG. 3C, if the result indicated that the software update was not successful, then the result of decision block 341 is NO, and the method 300 proceeds to block 344, where the update processing module 206 presents a failure notification. In some embodiments, the failure notification may include a status message that indicates what portion of the software update failed and why. In some embodiments, the failure notification may indicate to the operator that a retry of the software update will be automatically attempted one or more times.”)
As for Claim 4, which depends on Claim 1, David teaches wherein the one or more processors are configured to: determine, before the software update is complete, whether the prerequisite conditions are satisfied; and continue the software update when determining that all of the prerequisite conditions are satisfied (¶17|8: “One or more prerequisites, including but not limited to whether an initiation device has been actuated, whether an engine of the vehicle is off, whether an ignition key of the vehicle is on, whether a battery of the mobile computing device and/or the vehicle has a sufficient level of charge, and whether a parking brake is set, are checked by the server computing system, the vehicle, and/or the mobile computing device before allowing the update to be initiated.”)
As for Claim 5, which depends on Claim 1, David teaches wherein the one or more processors are configured to: determine, before the software update is complete, whether the prerequisite conditions are satisfied; and cancel the software update when determining that not all of the prerequisite condition are satisfied, regardless of whether the predetermined amount of time has been elapsed since the one or more processors firstly determine that not all of the prerequisite conditions are satisfied (¶57|8: “Alternatively, in some embodiments, the determination at decision block 332 is made by the user processing module 208 or the communication relay module 210, and a result of the determination is transmitted to the update processing module 206. If the vehicle state conditions do not indicate that the vehicle 106 is ready for an update, then the result of decision block 332 is NO, and the method 300 returns to terminal B to recheck the vehicle state conditions. Otherwise, if all of the vehicle state conditions indicate that the vehicle 106 is ready for an update, then the result of decision block 332 is YES, and the method 300 proceeds to block 334. In some embodiments, all of the vehicle state conditions presented by the mobile computing device 102 must be met in order to indicate that the vehicle 106 is ready for an update.”)
As for Claim 6, which depends on Claim 1, David teaches wherein the one or more processors are configured to, after performing the download and before performing the installation, determine whether the prerequisite conditions are satisfied when determining that the predetermined amount of time has not elapsed since the one or more processors first determine that not all of the prerequisite conditions are satisfied (¶17|8: “One or more prerequisites, including but not limited to whether an initiation device has been actuated, whether an engine of the vehicle is off, whether an ignition key of the vehicle is on, whether a battery of the mobile computing device and/or the vehicle has a sufficient level of charge, and whether a parking brake is set, are checked by the server computing system, the vehicle, and/or the mobile computing device before allowing the update to be initiated.”); and determine, after performing the installation, whether the prerequisite conditions are satisfied; continue the software update when determining that all of the prerequisite conditions are satisfied (¶53|1: “Returning to decision block 326, if the HMI device has been actuated for at least the threshold amount of time, then the result of decision block 326 is YES, and the method 300 proceeds to a continuation terminal ("terminal C").” Further, (¶56|1) “Although this example displays checkmarks and "X" indicators as illustrating the success state and the failure state [of prerequisite conditions], respectively, it is understood that in some embodiments other techniques may be used to indicate success and failure, including but not limited to different colors, different shapes, or organization of indicators into different areas or groups.”); and cancel the software update when determining that not all of the prerequisite condition are satisfied, regardless of whether the predetermined amount of time has been elapsed since the one or more processor firstly determine that not all of the prerequisite conditions are satisfied (See Fig. 4D, showing “cancel” option along with list of prerequisites and whether or not each has been met, allowing the user to cancel the update immediately, without waiting for a timeout to elapse.)
As for Claim 7, which depends on Claim 1, David teaches wherein the one or more prerequisite conditions include at least one of: (i) state of charge of a battery, wherein the state of charge the battery is a condition requesting that electric power necessary for software updating processing is secured, and a value of the state of charge the battery is capable of supplying the electric power necessary for the software updating processing and electric power necessary to maintain other functions of the vehicle (¶50|13:”Some non-limiting examples of vehicle state conditions that may be determined based on an instantaneous value include …whether a battery voltage of the vehicle 106 meets a battery voltage threshold…and any combination thereof.”), (ii) installation state of particular sensors or accessories, wherein the installation state of particular sensors or accessories is a condition requesting that sensors and accessories necessary for the electronic control unit to operate are installed in the vehicle; or (iii) shift range, vehicle speed, and Global Positioning System (OPS) coordinates, wherein the shift range, the vehicle speed, and the OPS coordinates are conditions for the vehicle to be in a safe state at a time of execution of the software updating processing.
As for Claim 8, which depends on Claim 1, David teaches wherein the one or more prerequisite conditions include at least one of: (i) operating state of a DC-to-DC converter, wherein the operating state of the DC-to-DC converter is a condition requesting that the DC-to-DC converter that supplies electric power from a traction battery to an accessory battery is running; (ii) state of error occurring at the electronic control unit, wherein the state of error occurring at an electronic control unit is a condition requesting that an error that would impede execution of software updating processing at the electronic control unit is not occurring (¶50|13: “Some non-limiting examples of vehicle state conditions that may be determined based on an instantaneous value include …whether the OTA updater device 108 can communicate with one or more updatable components 110 to be updated by the software update and/or the computer-readable media associated therewith, and any combination thereof.”); or (iii) availability of functions of an electronic control unit, wherein the availability of functions of the electronic control unit is a condition requesting that settings are made by a user to use the functions of the electronic control unit.
As for Claim 9, which depends on Claim 1, David teaches wherein at least one of the one or more prerequisite conditions is set based on a model of the vehicle (¶50|13:”Some non-limiting examples of vehicle state conditions that may be determined based on an instantaneous value include …whether a battery voltage of the vehicle 106 meets a battery voltage threshold…and any combination thereof.” The battery voltage would differ based on the type/model of vehicle including, for example, gas, electric, passenger, or semi.)
Response to Arguments
Applicant's arguments filed 15 Sep 2025 relate to newly amended claims and are not addressed in this section; the rejections above, however, address the latest version of the claims in detail.
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 extension fee 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 date of this final action.
Applicants should direct any inquiry concerning this or earlier communications to CLINT THATCHER at phone 571.270.3588. Examiner is normally available Mon-Fri, 9am to 5:30pm ET and generally keeps a daily 2:30pm timeslot open for interviews.
If attempts to reach the examiner by telephone are unsuccessful, Examiner’s supervisor, Yuqing Xiao, can be reached at (571) 270-3603.
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.
/Clint Thatcher/
Examiner, Art Unit 3645
/YUQING XIAO/Supervisory Patent Examiner, Art Unit 3645