DETAILED ACTION
This Action is a response to the RCE filed 17 December 2025. Claims 1, 6 and 17 are amended; no claims are canceled or newly added. Claims 1-20 remain pending for examination.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 17 December 2025 has been entered.
Claim Objections
Claim 17 objected to because of the following informalities: at line 3, “a dynamic vehicle software deployment planner” should be amended to recite “a cloud-based vehicle software deployment planner” for consistency with claim 18. Appropriate correction is required.
Claim Rejections - 35 USC § 103
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 (i.e., changing from AIA to pre-AIA ) 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.
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, 3, 6, 8, 11-13, 15-17 and 20 are rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha et al., U.S. 2020/0218531 A1 (“Kushwaha”) in view of Nagamitsu, Shoichi, U.S. 2022/0317995 A1 (“Nagamitsu”).
Regarding claim 1, Kushwaha teaches: A system, comprising: one or more computing devices configured to implement a dynamic vehicle software deployment planner configured (Kushwaha, e.g., ¶30, “system 100 for OTA updates … includes an OTA update manager 110, which comprises a system … configured to orchestrate OTA updates for vehicles …”) to:
receive, from a vehicle of a fleet of vehicles, a stream of vehicle data comprising updates indicating an electronic control unit (ECU) configuration of the vehicle and diagnostic data for the vehicle or systems of the vehicle (Kushwaha, e.g., ¶35, “Data storage 402 may also be configured to store network architectures 424 for one or more types of vehicles … indicates the ECUs 210 installed in a vehicle, the software component(s) 310 in the ECUs 210, etc. …” See also, e.g., ¶40, “software-related data bay be indexed based on metadata for the vehicles 120, such as make, model, model year … data storage 402 is supplied with current software-related data for vehicles …” See also, e.g., ¶42, “After or responsive to the vehicle 120 connecting with OTA interface 408, update engine 406 identifies the software state of the ECUs 210 in the vehicle … may indicate part numbers for the software components presently installed … versions of the software … architecture of the vehicle …” Examiner’s note: “various diagnostic data for the vehicle 142, including … an ECU configuration of the vehicle …” (see Spec. ¶30). That is, a network architecture comprising installed ECUs and the software components installed thereon is consistent with an embodiment of the claimed diagnostic data. Examiner further notes that the claim has been amended to provide additional specificity with respect to the diagnostic data, the subject matter of which is recited in Nagamitsu, cited below);
generate, a deployment plan for deploying a distributed vehicle software application on the vehicle, wherein the deployment plan is generated based, at least in part, on the ECU configuration of the vehicle and the diagnostic data for the vehicle indicated in the stream (Kushwaha, e.g., ¶36, “Update engine 406 … configured to generate an update plan for updating software in a vehicle or a fleet of vehicles … selects updated software components 410-415 for installation …”); and
send, based on a request received by the dynamic vehicle software deployment planner, the deployment plan (Kushwaha, e.g., ¶44, “OTA interface 408 downloads the update plan to the vehicle …”),
wherein the generated deployment plan comprises instructions that, when executed, cause an in-vehicle application deployment planner of the vehicle to: relay localized execution plans for deploying components of the distributed vehicle software application based on the deployment plan (Kushwaha, e.g., ¶43, “update plan comprises instructions or commands for installing the set of updated software components … indicates an order or sequence for installing the set of updated software components … instructions for removing prior software components, when to download the updated software components …” See also, e.g., ¶44, “update controller 224 processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …”); and
implement the localized execution plans to deploy, on the vehicle, the components of the distributed vehicle software application (Kushwaha, e.g., ¶60, “Central gateway 220 then processes the update plan to update the software components in the vehicle …”).
Kushwaha does not more particularly teach that the diagnostic data comprises information indicating available capacity or performance of one or more ECUs. However, Nagamitsu does teach: wherein the diagnostic data comprises information indicating available capacity or performance of one or more electronic control units (ECUs) (Nagamitsu, e.g., ¶90, “control unit 17 determines which of the update processing using the total data or the update processing using the difference data has a shorter predicted time until the completion of the update of the update target software … predicted based on, for example, a degree of congestion of a communication band, the current version of the software, and a processing capacity of the ECU …” See also, e.g., ¶93, wherein an example is provided of determining a deployment plan based on diagnostic data including ECU processing capacity used to predict an update time for a plurality of possible deployment plans, wherein an improved deployment plan is identified based on the predicted time determined based on the diagnostic data) for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, e.g., ¶¶102-106).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs because the disclosure of Nagamitsu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for vehicle ECU software update planning to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, Id.).
Regarding claim 3, the rejection of claim 1 is incorporated, and Kushwaha further teaches: wherein the dynamic vehicle software deployment planner is further configured to: dynamically generate, based on the stream of vehicle data, an updated deployment plan for the distributed vehicle software application; and send the dynamically generated updated deployment plan to the vehicle, wherein the dynamically generated deployment plan comprises instructions that, when executed, cause the in-vehicle application deployment planner of the vehicle to: deploy components of the distributed vehicle software application to one or more ECUs of the vehicle in a configuration indicated in the deployment plan that was generated taking into account a current ECU configuration and current diagnostic data for the vehicle indicated in the stream (Kushwaha, e.g., ¶43, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 …” See also, e.g., ¶60, “Central gateway 220 then processes the update plan to update the software components in the vehicle …”).
Regarding claim 6, Kushwaha teaches: A method (Kushwaha, e.g., ¶39, “method 500 of performing OTA updates …”), comprising: receiving, via a vehicle software deployment planner, a stream of vehicle data comprising updates indicating an electronic control unit (ECU) configuration for a vehicle and diagnostic data of the vehicle (Kushwaha, e.g., ¶35, “Data storage 402 may also be configured to store network architectures 424 for one or more types of vehicles … indicates the ECUs 210 installed in a vehicle, the software component(s) 310 in the ECUs 210, etc. …” See also, e.g., ¶40, “software-related data bay be indexed based on metadata for the vehicles 120, such as make, model, model year … data storage 402 is supplied with current software-related data for vehicles …” See also, e.g., ¶42, “After or responsive to the vehicle 120 connecting with OTA interface 408, update engine 406 identifies the software state of the ECUs 210 in the vehicle … may indicate part numbers for the software components presently installed … versions of the software … architecture of the vehicle …” Examiner’s note: “various diagnostic data for the vehicle 142, including … an ECU configuration of the vehicle …” (see Spec. ¶30). That is, a network architecture comprising installed ECUs and the software components installed thereon is consistent with an embodiment of the claimed diagnostic data. Examiner further notes that the claim has been amended to provide additional specificity with respect to the diagnostic data, the subject matter of which is recited in Nagamitsu, cited below); and
sending, based on a request to deploy to the vehicle a vehicle software application, a deployment plan for the vehicle software application (Kushwaha, e.g., ¶44, “OTA interface 408 downloads the update plan to the vehicle …”), wherein the deployment plan is generated based on the ECU configuration and the diagnostic data indicated in the stream (Kushwaha, e.g., ¶36, “Update engine 406 … configured to generate an update plan for updating software in a vehicle or a fleet of vehicles … selects updated software components 410-415 for installation …”),
wherein the deployment plan comprises instructions that, when executed, cause an in-vehicle application deployment planner of the vehicle to: implement, based on the deployment plan, localized execution plans for deploying the vehicle software application at the vehicle (Kushwaha, e.g., ¶43, “update plan comprises instructions or commands for installing the set of updated software components … indicates an order or sequence for installing the set of updated software components … instructions for removing prior software components, when to download the updated software components …” See also, e.g., ¶44, “update controller 224 processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …” See also, e.g., ¶60, “Central gateway 220 then processes the update plan to update the software components in the vehicle …”).
Kushwaha does not more particularly teach that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs. However, Nagamitsu does teach: wherein the diagnostic data comprises information indicating available capacity or performance of one or more electronic control units (ECUs) (Nagamitsu, e.g., ¶90, “control unit 17 determines which of the update processing using the total data or the update processing using the difference data has a shorter predicted time until the completion of the update of the update target software … predicted based on, for example, a degree of congestion of a communication band, the current version of the software, and a processing capacity of the ECU …” See also, e.g., ¶93, wherein an example is provided of determining a deployment plan based on diagnostic data including ECU processing capacity used to predict an update time for a plurality of possible deployment plans, wherein an improved deployment plan is identified based on the predicted time determined based on the diagnostic data) for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, e.g., ¶¶102-106).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs because the disclosure of Nagamitsu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for vehicle ECU software update planning to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, Id.).
Regarding claim 8, the rejection of claim 6 is incorporated, and Kushwaha further teaches: dynamically generating, based on the ECU configuration and/or the diagnostic data indicated in the stream, the deployment plan for the vehicle software application (Kushwaha, e.g., ¶44, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 …”); and
sending the dynamically generated deployment plan to the vehicle (Kushwaha, e.g., ¶44, “OTA interface 408 downloads the update plan to the vehicle …”),
wherein the dynamically generated deployment plan comprises instructions that, when executed, cause the in-vehicle application deployment planner of the vehicle to: remove another vehicle software application previously deployed to the vehicle; and deploy the vehicle software application to one or more ECUs of the vehicle in accordance with the dynamically generated deployment plan (Kushwaha, e.g., ¶43, “update plan comprises instructions or commands for installing the set of updated software components … indicates an order or sequence for installing the set of updated software components … instructions for removing prior software components, when to download the updated software components …” See also, e.g., ¶44, “update controller 224 processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …” See also, e.g., ¶60, “Central gateway 220 then processes the update plan to update the software components in the vehicle …”).
Regarding claim 11, the rejection of claim 6 is incorporated, and Kushwaha further teaches: wherein said dynamically generating the deployment plan is performed by a cloud-based dynamic vehicle software deployment planner (Kushwaha, e.g., ¶30, “system 100 for OTA updates … includes an OTA update manager 110, which comprises a system … configured to orchestrate OTA updates for vehicles …” See also, e.g., ¶35, “OTA update manager 110 includes … data storage 402 … may represent cloud storage …”), the method further comprising:
training one or more machine learning (ML) models used by the dynamic vehicle software deployment planner based on the received stream, wherein the deployment plan for the vehicle software application is dynamically generated based, at least in part, on ML inferences generated from the one or more ML models (Kushwaha, e.g., ¶36, “update engine 406 may utilize machine learning or artificial intelligence (AI) techniques to generate the update plans, such as with machine learning system 407. Machine learning system 407 may be trained … with the prior software updates on vehicles … to develop a model”).
Regarding claim 12, the rejection of claim 6 is incorporated, and Kushwaha further teaches: wherein said training the one or more ML models comprises: training the one or more ML models based on current and historical updates to the ECU configuration of the vehicle and current and historical diagnostic data of the vehicle, wherein the deployment plan for the vehicle software application is generated based, at least in part, on ML inferences generated from the current and historical updates and the current and historical diagnostic data (Kushwaha, e.g., ¶36, “update engine 406 may utilize machine learning or artificial intelligence (AI) techniques to generate the update plans, such as with machine learning system 407. Machine learning system 407 may be trained … with the prior software updates on vehicles, and/or with other contextual information … Based on this training, machine learning system 407 is able to generate an update plan for a vehicle or fleet.” See also, e.g., ¶44, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 …” Examiner’s note: as discussed above, the ECU architecture is consistent with diagnostic data (see Spec. ¶30), and that the ML model is trained based on and used to generate deployment plans, said deployment plans being based on vehicle state, which includes the ECU architecture, suggests that the ML model incorporates current and historical diagnostic data (i.e., as the current and historical deployment plans are generated based thereon)).
Regarding claim 13, the rejection of claim 6 is incorporated, and Kushwaha further teaches: wherein said training the one or more ML models comprises: training the one or more ML models based on ECU configurations indicated in the stream for a plurality of vehicles in a fleet and diagnostic data of the plurality of vehicles, wherein the deployment plan for the vehicle software application is generated based, at least in part, on ML inferences generated taking into account the ECU configurations and the diagnostic data from the plurality of vehicles of the fleet (Kushwaha, e.g., ¶36, “update engine 406 may utilize machine learning or artificial intelligence (AI) techniques to generate the update plans, such as with machine learning system 407. Machine learning system 407 may be trained … with the prior software updates on vehicles, and/or with other contextual information … Based on this training, machine learning system 407 is able to generate an update plan for a vehicle or fleet.” See also, e.g., ¶43, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 …” Examiner’s note: as discussed above, the ECU architecture is consistent with diagnostic data (see Spec. ¶30), and that the ML model is trained based on and used to generate deployment plans, said deployment plans being based on vehicle state, which includes the ECU architecture, suggests that the ML model incorporates current and historical diagnostic data (i.e., as the current and historical deployment plans are generated based thereon)).
Regarding claim 15, the rejection of claim 6 is incorporated, and Kushwaha further teaches: determining, based on the ECU configuration and diagnostic data of the stream, for a plurality of vehicle software applications in a vehicle applications store, one or more feasible vehicle software applications that are able to be deployed in the vehicle (Kushwaha, e.g., ¶35, “Data storage 402 is also configured to store authorized software configurations 422 for vehicles that are tested and/or verified … OEM tests or validates which versions of the software components are interoperable in the network architecture of a vehicle, and approves the versions for the release …”), wherein the vehicle software application to be deployed is chosen to be deployed from the one or more feasible vehicle software applications (Kushwaha, e.g., ¶43, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 and the authorized software configuration 422 for the vehicle …”).
Regarding claim 16, the rejection of claim 6 is incorporated, and Kushwaha further teaches: determining based on the ECU configuration and diagnostic data of the stream, one or more feasible deployment options for the vehicle software applications, wherein the one or more feasible deployment options comprise options to change one or more of: an arrangement of vehicle software deployed in the vehicle, a collection of vehicle software deployed in the vehicle, or a specification of a vehicle hardware component (Kushwaha, e.g., ¶35, “Data storage 402 is also configured to store authorized software configurations 422 for vehicles that are tested and/or verified … OEM tests or validates which versions of the software components are interoperable in the network architecture of a vehicle, and approves the versions for the release …” See also, e.g., ¶43, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 and the authorized software configuration 422 for the vehicle …”).
Regarding claim 17, Kushwaha teaches: One or more non-transitory, computer-readable storage media, storing program instructions that when executed on or across one or more processors cause the one or more processors to implement a dynamic vehicle software deployment planner (Kushwaha, e.g., ¶30, “system 100 for OTA updates … includes an OTA update manager 110, which comprises a system … configured to orchestrate OTA updates for vehicles …” See also, e.g., ¶62, “embodiment may be implemented as instructions executable by a processor or a computer to perform the functions of the element … instructions may be stored on storage devices that are readable by the processor …”) that implements:
sending, from a vehicle of a fleet of vehicles to the dynamic vehicle software deployment planner, a stream of vehicle data indicating an electronic control unit (ECU) configuration of the vehicle of the fleet and indicating diagnostic data of the vehicle of the fleet (Kushwaha, e.g., ¶35, “Data storage 402 may also be configured to store network architectures 424 for one or more types of vehicles … indicates the ECUs 210 installed in a vehicle, the software component(s) 310 in the ECUs 210, etc. …” See also, e.g., ¶40, “software-related data bay be indexed based on metadata for the vehicles 120, such as make, model, model year … data storage 402 is supplied with current software-related data for vehicles …” See also, e.g., ¶42, “After or responsive to the vehicle 120 connecting with OTA interface 408, update engine 406 identifies the software state of the ECUs 210 in the vehicle … may indicate part numbers for the software components presently installed … versions of the software … architecture of the vehicle …” Examiner’s note: “various diagnostic data for the vehicle 142, including … an ECU configuration of the vehicle …” (see Spec. ¶30). That is, a network architecture comprising installed ECUs and the software components installed thereon is consistent with an embodiment of the claimed diagnostic data. Examiner further notes that the claim has been amended to provide additional specificity with respect to the diagnostic data, the subject matter of which is recited in Nagamitsu, cited below);
receiving a deployment plan for a distributed vehicle software application (Kushwaha, e.g., ¶44, “OTA interface 408 downloads the update plan to the vehicle …”) that has been dynamically generated, based on the indications of the stream, by a cloud-based dynamic vehicle software deployment planner (Kushwaha, e.g., ¶43, “update engine 406 selects a set … of updated software components 410-415 for installation in the vehicle 120 (step 512), and generates an update plan for installing the set of updated software components … based on the software state of the vehicle 120 and the authorized software configuration 422 for the vehicle …”);
implementing, via an in-vehicle application deployment planner of the vehicle, localized execution plans, based on the deployment plan, to install the distributed vehicle software application on the vehicle (Kushwaha, e.g., ¶43, “update plan comprises instructions or commands for installing the set of updated software components … indicates an order or sequence for installing the set of updated software components … instructions for removing prior software components, when to download the updated software components …” See also, e.g., ¶44, “update controller 224 processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …” See also, e.g., ¶60, “Central gateway 220 then processes the update plan to update the software components in the vehicle …”).
Kushwaha does not more particularly teach that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle components. However, Nagamitsu does teach: wherein the diagnostic data comprises information indicating available capacity or performance of one or more electronic control units (ECUs) (Nagamitsu, e.g., ¶90, “control unit 17 determines which of the update processing using the total data or the update processing using the difference data has a shorter predicted time until the completion of the update of the update target software … predicted based on, for example, a degree of congestion of a communication band, the current version of the software, and a processing capacity of the ECU …” See also, e.g., ¶93, wherein an example is provided of determining a deployment plan based on diagnostic data including ECU processing capacity used to predict an update time for a plurality of possible deployment plans, wherein an improved deployment plan is identified based on the predicted time determined based on the diagnostic data) for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, e.g., ¶¶102-106).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs because the disclosure of Nagamitsu shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for vehicle ECU software update planning to provide that the diagnostic data comprises information indicating available capacity or performance of one or more vehicle ECUs for the purpose of utilizing a variety of data about vehicle ECU configurations and parameters as well as software availability to identify a particular deployment plan for performing a vehicle ECU update (Nagamitsu, Id.).
Regarding claim 20, the rejection of claim 17 is incorporated, and Kushwaha further teaches: wherein the program instructions that when executed cause the one or more processors to further implement: receiving a different deployment plan, wherein the different deployment plan comprises instructions to deploy another distributed vehicle software application in a different deployment configuration; removing the vehicle software application previously deployed; and deploying the other vehicle software application to one or more ECUs of the vehicle based on the different deployment plan (Kushwaha, e.g., ¶43, “update plan comprises instructions or commands for installing the set of updated software components … indicates an order or sequence for installing the set of updated software components … instructions for removing prior software components, when to download the updated software components …” See also, e.g., ¶44, “update controller 224 processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …” Examiner’s note: this deployment plan is for a subsequent deployment plan from a previous deployment plan, as indicated by the removal and subsequent installation of a different software component. See also, e.g., ¶36, “update engine 406 may utilize machine learning or artificial intelligence (AI) techniques to generate the update plans, such as with machine learning system 407. Machine learning system 407 may be trained … with the prior software updates on vehicles, and/or with other contextual information …” which indicates the knowledge of and use of a previous deployment plan and other information (vehicle software state including ECU architecture) to generate a subsequent plan).
Claims 2 and 7 are rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu, and in further view of Ogino et al., U.S. 2023/0168882 A1 (“Ogino”).
Regarding claim 2, the rejection of claim 1 is incorporated, but Kushwaha in view of Nagamitsu does not more particularly teach that the generated deployment plan comprises executable instructions to cause the in-vehicle deployment planner to redeploy another deployed component of another distributed vehicle software application from an initial ECU to another ECU of a plurality of ECUs of the vehicle. However, Ogino does teach: wherein the generated deployment plan comprises instructions that, when executed further cause the in-vehicle application deployment planner to: redeploy, based on the generated deployment plan, another deployed component of another distributed vehicle software application from an initial ECU of a plurality of ECUs of the vehicle to another ECU of the plurality of ECUs of the vehicle (Ogino, e.g., Abs., “first control unit configured to execute first control program for controlling a vehicle. A second control unit … configured to execute a second control program … first communication line connects the first and second control units. A program update unit transmits program update information to the first control unit … second communication line branches from the first communication line … second control unit acquires the update information for the second control program from among communication contents between the update unit and the first control unit acquired through the second communication line …” Examiner’s note: compare Ogino FIG. 5 to Applicant’s FIG. 6B) for the purpose of updating a plurality of control units via the initial sending of a combined update information package to a first control unit, and obtaining by a second control unit pertinent update information from communications to the first control unit (Ogino, e.g., ¶¶45-51).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide that the generated deployment plan comprises executable instructions to cause the in-vehicle deployment planner to redeploy another deployed component of another distributed vehicle software application from an initial ECU to another ECU of a plurality of ECUs of the vehicle because the disclosure of Ogino shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for vehicle program rewriting to provide that the generated deployment plan comprises executable instructions to cause the in-vehicle deployment planner to redeploy another deployed component of another distributed vehicle software application from an initial ECU to another ECU of a plurality of ECUs of the vehicle for the purpose of updating a plurality of control units via the initial sending of a combined update information package to a first control unit, and obtaining by a second control unit pertinent update information from communications to the first control unit (Ogino, Id.).
Claim 7 is rejected for the additional reasons given in the rejection of claim 2 above.
Claim 4 is rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu, and in further view of Kroselberg, Dirk, U.S. 10,698,676 B2 (“Kroselberg”).
Regarding claim 4, the rejection of claim 3 is incorporated, but Kushwaha in view of Nagamitsu does not more particularly teach that based on the vehicle ECU configuration and diagnostic data, the deployment planner determines whether one or more deployment-related condition of the distributed vehicle software has changed by more than a threshold amount, and if so, generate and send the deployment plan, but if not, refrain from generating and sending the deployment plan. However, Kroselberg does teach: wherein the dynamic vehicle software deployment planner is further configured to: determine, based on the ECU configuration of the vehicle and the diagnostic data for the vehicle indicated in the stream, whether one or more conditions of the vehicle related to the deployment of the distributed vehicle software have changed by more than a threshold amount (Kroselberg, e.g., claim 1, “receiving a reliability information of the patch … automatically applying the patch to correct the software if a specifiable reliability status indicated by means of the reliability information associated with the patch exceeds a threshold value of a reliability status …”);
in response to the one or more conditions having changed by more than the threshold amount: perform the dynamic generation of the updated deployment plan and the sending of the updated deployment plan; and in response to the one or more conditions not having changed by more than the threshold amount: refrain from performing the dynamic generation of the updated deployment plan and the sending of the updated deployment plan (Kroselberg, e.g., claim 1, “receiving a reliability information of the patch … automatically applying the patch to correct the software if a specifiable reliability status indicated by means of the reliability information associated with the patch exceeds a threshold value of a reliability status …” Examiner’s note: whether a threshold of reliability (condition) improvement (change) is achieved via a patch is determined based on information about the patch and the existing software, and the software is only installed when the threshold is exceeded (changed by more than a threshold amount); therefore the update is refrained from being performed otherwise. See Spec. ¶50 describing that a threshold improvement in application reliability is a consideration for generating and executing a deployment plan (performing one or more patches)) for the purpose of utilizing collected information regarding patch reliability for patches installed on other devices to evaluate whether one or more of said patches increase the reliability of a particular device, and to perform an update upon determining that the reliability increase exceeds the threshold (Kroselberg, e.g., 1:51-2:37).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide that based on the vehicle ECU configuration and diagnostic data, the deployment planner determines whether one or more deployment-related condition of the distributed vehicle software has changed by more than a threshold amount, and if so, generate and send the deployment plan, but if not, refrain from generating and sending the deployment plan because the disclosure of Kroselberg shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for software reliability enhancement through distributed update application to provide that based on the vehicle ECU configuration and diagnostic data, the deployment planner determines whether one or more deployment-related condition of the distributed vehicle software has changed by more than a threshold amount, and if so, generate and send the deployment plan, but if not, refrain from generating and sending the deployment plan for the purpose of utilizing collected information regarding patch reliability for patches installed on other devices to evaluate whether one or more of said patches increase the reliability of a particular device, and to perform an update upon determining that the reliability increase exceeds the threshold (Kroselberg, Id.).
Claims 5, 9 and 19 are rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu, and in further view of Barrett et al., U.S. 2015/0073697 A1 (“Barrett”).
Regarding claim 5, the rejection of claim 1 is incorporated, and Kushwaha further teaches: wherein the deployment plan is configured to interface with an in-vehicle orchestrator of the vehicle (Kushwaha, e.g., ¶44, “central gateway 220 in the vehicle 120 receives the update plan … Update controller 224 then processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …”).
Kushwaha in view of Nagamitsu does not more particularly teach that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs. However, Barrett does teach: wherein the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of ECUs of the vehicle (Barrett, e.g., ¶12, “data signals, which are communicated from the ECUs to the CAN bus, are abstracted ... The abstraction device connects directly to the On Board Diagnostics (OBD) connector that enables access to the CAN bus …” See also, e.g., ¶13, “a user of the mobile device and/or a network resource can send a write or control signal from the mobile device and/or network resource through the abstraction device to the CAN bus … enables the user … to alter the state of one or more components included in the vehicle …”) for the purpose of facilitating activation of procedures and/or services between one or more devices and vehicle ECUs, to include the sharing of ECU state data and other information and the writing and transmitting of applications to one or more of the ECUs (Barrett, e.g., ¶¶11-14).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs because the disclosure of Barrett shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for providing write and communication signals among a plurality of ECUs through one or more CAN buses to provide that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs for the purpose of facilitating activation of procedures and/or services between one or more devices and vehicle ECUs, to include the sharing of ECU state data and other information and the writing and transmitting of applications to one or more of the ECUs (Barrett, Id.).
Claim 19 is rejected for the additional reasons given in the rejection of claim 5 above.
Regarding claim 9, the rejection of claim 6 is incorporated, and Kushwaha further teaches: wherein the vehicle further comprises a plurality of ECUs and wherein the said generating the deployment plan comprises: determining different runtime architectures of the plurality of ECUs (Kushwaha, e.g., ¶35, “Data storage 402 may also be configured to store network architectures 424 for one or more types of vehicles … indicates the ECUs 210 installed in a vehicle, the software component(s) 310 in the ECUs 210, etc. …”), …
wherein the deployment plan is configured to enable an in-vehicle orchestrator of the vehicle to employ a deployment adapter framework (Kushwaha, e.g., ¶44, “central gateway 220 in the vehicle 120 receives the update plan … Update controller 224 then processes the update plan to determine an order for removing an old version of a software component, and replacing it with an updated software component …”).
Kushwaha in view of Nagamitsu does not more particularly teach that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs. However, Barrett does teach: [wherein the in-vehicle orchestrator is to employ an adapter framework] to interface with different runtime architectures of the plurality of ECUs (Barrett, e.g., ¶12, “data signals, which are communicated from the ECUs to the CAN bus, are abstracted ... The abstraction device connects directly to the On Board Diagnostics (OBD) connector that enables access to the CAN bus …” See also, e.g., ¶13, “a user of the mobile device and/or a network resource can send a write or control signal from the mobile device and/or network resource through the abstraction device to the CAN bus … enables the user … to alter the state of one or more components included in the vehicle …”) for the purpose of facilitating activation of procedures and/or services between one or more devices and vehicle ECUs, to include the sharing of ECU state data and other information and the writing and transmitting of applications to one or more of the ECUs (Barrett, e.g., ¶¶11-14).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs because the disclosure of Barrett shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for providing write and communication signals among a plurality of ECUs through one or more CAN buses to provide that the in-vehicle orchestrator employs a deployment adapter framework configured to interface with a plurality of different runtime architectures of a plurality of vehicle ECUs for the purpose of facilitating activation of procedures and/or services between one or more devices and vehicle ECUs, to include the sharing of ECU state data and other information and the writing and transmitting of applications to one or more of the ECUs (Barrett, Id.).
Claim 10 is rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu and Barrett, and in further view of Scrivano, Giuseppe, U.S. 2023/0214290 A1 (“Scrivano”).
Regarding claim 10, the rejection of claim 9 is incorporated, but Kushwaha in view of Nagamitsu and Barrett does not more particularly teach that at least one of the different ECU runtime architectures is an OCI framework architecture, and the vehicle software application comprises one or more OCI format container images. However, Scrivano does teach: wherein at least one of the different runtime architectures of the plurality of ECUs is an Open Container Initiative (OCI) framework architecture, wherein the vehicle software application comprises one or more container images formatted according to an OCI format (Scrivano, e.g., ¶11, “package may be a container image usable to deploy a container (e.g., an Open Container Initiatives container) in a computing environment …” Examiner’s note: the ECU is the computing environment) for the purpose of reliably transmitting, writing and utilizing software packages obtained from a remote device to a target device (Scrivano, e.g., ¶¶7-11).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu and Barrett to provide that at least one of the different ECU runtime architectures is an OCI framework architecture, and the vehicle software application comprises one or more OCI format container images because the disclosure of Scrivano shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for distributed software application download and installation to provide for that at least one of the different ECU runtime architectures is an OCI framework architecture, and the vehicle software application comprises one or more OCI format container images for the purpose of reliably transmitting, writing and utilizing software packages obtained from a remote device to a target device (Scrivano, Id.).
Claim 14 is rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu, and in further view of Yamamoto et al., U.S. 2023/0082123 A1 (“Yamamoto”).
Regarding claim 14, the rejection of claim 6 is incorporated, but Kushwaha in view of Nagamitsu does not more particularly teach generating a virtual replica of the vehicle based on the ECU configuration and diagnostic data of the stream and testing, using the replica, the deployment of the vehicle software application based on the deployment plan. However, Yamamoto does teach: generating a virtual replica of the vehicle based on the ECU configuration and diagnostic data of the stream (Yamamoto, e.g., ¶112, “vehicle virtual model generating unit 303 generates and updates a virtual model based on the vehicle data … aging variation … operating conditions … change in elements … change in hardware … change in software … generate a digital twin which is the virtual vehicle model …”); and
testing, using the virtual replica, the deployment of the vehicle software application based on the deployment plan (Yamamoto, e.g., ¶117, “effect predicting unit 306 may predict the effect of software update, for example, by causing the simulator unit 305 to perform virtual simulation on the vehicle 10 using the virtual vehicle model of the vehicle 10 …”) for the purpose of utilizing a robust virtual model of a vehicle on which to simulate and predict the effects of software updates on the corresponding vehicle (Yamamoto, e.g., ¶¶110-117).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide for generating a virtual replica of the vehicle based on the ECU configuration and diagnostic data of the stream and testing, using the replica, the deployment of the vehicle software application based on the deployment plan because the disclosure of Yamamoto shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for performing distributed vehicle software updates to provide for generating a virtual replica of the vehicle based on the ECU configuration and diagnostic data of the stream and testing, using the replica, the deployment of the vehicle software application based on the deployment plan for the purpose of utilizing a robust virtual model of a vehicle on which to simulate and predict the effects of software updates on the corresponding vehicle (Yamamoto, Id.).
Claim 18 is rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Nagamitsu, and in further view of Lee, Soojin, U.S. 9,176,561 B2 (“Lee”).
Regarding claim 18, the rejection of claim 17 is incorporated, but Kushwaha in view of Nagamitsu does not more particularly teach that upon determining that a connection to the vehicle software deployment planner is unavailable, generating an alternative localized execution plan that prioritizes availability of safety critical applications over non-safety critical applications. However, Lee does teach: upon determining that a connection to the cloud-based dynamic vehicle software deployment planner is unavailable, generating an alternative localized execution plan that prioritizes availability of safety critical applications over non-safety critical applications (Lee, e.g., claim 9, “first storage medium records and stores the updated data transmitted from the data communication unit, wherein upon errors being generated in product data and program data of the microprocessor, the microprocessor resets the charge/discharge control unit and applies the updated data of the predetermined program … while operating the charge/discharge control unit in a safety model to safely operate the external set device while and until the charge/discharge control unit is updated with the received updated data of the predetermined program.” Examiner’s note: an unavailable connection to the cloud deployment planner (i.e., the update source) may result in errors in transmitting or storing the update data. In the case of Lee, upon determining there is an error in the update data, the control unit is operated in a safety mode to ensure that the control unit may safely operate the external device (i.e., prioritizing availability of a safety critical application over other potential updates)) for the purpose of permitting software update to continue with respect to one or more updates, when an error is discovered in one or more software program data, by executing a safety mode such that the battery device may be safely operated while an update continues (Lee, e.g., 4:54-5:6).
Therefore, 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 system and method for performing over-the-air vehicle ECU software updates as taught by Kushwaha in view of Nagamitsu to provide that upon determining that a connection to the vehicle software deployment planner is unavailable, generating an alternative localized execution plan that prioritizes availability of safety critical applications over non-safety critical applications because the disclosure of Lee shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for battery pack control unit program update to provide that upon determining that a connection to the vehicle software deployment planner is unavailable, generating an alternative localized execution plan that prioritizes availability of safety critical applications over non-safety critical applications for the purpose of permitting software update to continue with respect to one or more updates, when an error is discovered in one or more software program data, by executing a safety mode such that the battery device may be safely operated while an update continues (Lee, Id.).
Response to Arguments
In the Remarks, Applicant Argues: Amendments to the independent claims distinguish over the teachings of Arai, and the claims are therefore in condition for allowance (Resp. at 9-13).
Examiner’s Response: In view of the amendments, Examiner newly cites to Nagamitsu, and maintains the rejections under the new grounds set forth in full above.
Conclusion
Examiner has identified particular references contained in the prior art of record within the body of this action for the convenience of Applicant. Although the citations made are representative of the teachings in the art and are applied to the specific limitations within the enumerated claims, the teaching of the cited art as a whole is not limited to the cited passages. Other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art and/or disclosed by Examiner.
Examiner respectfully requests that, in response to this Office Action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
Examiner interviews are available via telephone and video conferencing using a USPTO-supplied web-based collaboration tool. Applicant is encouraged to submit an Automated Interview Request (AIR) which may be done via https://www.uspto.gov/patent/uspto-automated-interview-request-air-form, or may contact Examiner directly via the methods below.
Any inquiry concerning this communication or earlier communication from Examiner should be directed to Andrew M. Lyons, whose telephone number is (571) 270-3529, and whose fax number is (571) 270-4529. The examiner can normally be reached Monday to Friday from 10:00 AM to 6:00 PM ET. If attempts to reach Examiner by telephone are unsuccessful, Examiner’s supervisor, Wei Mui, can be reached at (571) 272-3708. Information regarding the status of an application may be obtained from the Patent Center system. For more information about the Patent Center system, see https://www.uspto.gov/patents/apply/patent-center. If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call (800) 786-9199 (in USA or Canada) or (571) 272-1000.
/Andrew M. Lyons/Primary Examiner, Art Unit 2191