DETAILED ACTION
This Action is a response to the RCE filed 17 December 2025. Claims 1, 5 and 13 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 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 13-14 and 16-18 are rejected under 35 U.S.C. § 103 as being unpatentable over Gomes, Joao Manuel Ferreira, U.S. 2019/0205115 A1 (“Gomes”) in view of Claiborne, Andrew E., U.S. 2004/0088698 A1 (“Claiborne”).
Regarding claim 13, Gomes 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 (Gomes, e.g., ¶221, “a non-transitory machine-readable medium having stored thereon a plurality of code sections … cause the one or more processors to perform the actions of a method of operating an on-board unit of a vehicle … to, among other things, receive and manage application of information updates …”) implement:
receiving, from a vehicle software deployment management system: a deployment plan for implementing a vehicle software application at a vehicle (Gomes, e.g., ¶195, “an example data structure of an information update 900, including details of an example update metadata portion 901 and an example data portion 902 …” See also, e.g., ¶196, “metadata 901 also comprises an affected vehicle application(s)/system(s) element 906, which may be used to identify one or more software application(s) … and/or vehicle systems … that are affected by the update … comprise an order policy element 908 that may define an order in which information updates … are to be applied, and a conditions required for update element 910 that may define the operating state in which the software application and/or vehicle system must be for an information update to be applied …”); and …
a set of application packages to be used to implement the vehicle software application at the vehicle (Gomes, e.g., ¶195, “an example data structure of an information update, including … an example data portion 902 …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … update may be for one or more software application(s) …” and ¶205, “vehicle components and/or systems to be updated, or the OBU itself may apply the respective parts of the information update to the software, firmware …”) …;
obtaining, via a vehicle application deployment planner, vehicle metadata from the vehicle based on the received deployment plan (Gomes, e.g., ¶201, “method may direct the OBU to verify that the update version and the order policy of the information update … are consistent with the current version and update order policy of the vehicle configuration … to be updated …” and ¶202, “method may determine whether vehicle operating conditions required for application of the update … are currently met …. state of the vehicle (e.g., an AV) may comprise, for example … charging its batteries … traveling … the states of various vehicle components and/or systems that are able to be updates …” See also, e.g., ¶196, “conditions required for update element 910 may indicate that … certain types or amounts of local storage must be available; and/or that a particular software application or vehicle system may not be present (e.g., due to competing processing load/use of storage/peripheral or sensor access demands”);
generating, via [[a]]the vehicle application deployment planner, an execution plan for implementing the vehicle software application at the vehicle based on the received deployment plan and vehicle metadata obtained from the vehicle (Gomes, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …”);
… carrying out the execution plan to implement the vehicle software application at the vehicle in accordance with the deployment plan (Gomes, e.g., ¶205, “vehicle components and/or systems to be updated, or the OBU itself may apply the respective parts of the information update to the software, firmware … OBU may act as a manager and communication conduit for those systems other than the OBU …”).
Gomes does not more particularly teach receiving and reconstructing at the vehicle data chunks representing application packages to implement the vehicle software application, and upon full reconstruction, carrying out the update. However, Claiborne does teach: [receiving] data chunks representing [a set of application packages to be used to implement the vehicle software application at the vehicle], wherein the data chunks are configured to be used at the vehicle to reconstruct the set of application packages (Claiborne, e.g., ¶24, “software distributor so it is stored … on the control server 2 in a serialized format, creating a serialized software distributor 4 … part of the serialized software distributor is a software grouping 6 … an interactive control script 10 …” See also, e.g., ¶26, “user interface then copies the serialized software distributor 4 and the wrapper script 8 to the software source server 16 …”); …
reconstructing, at the vehicle, using the data chunks, the application packages for the vehicle software application; and upon determination of full reconstruction of the application packages for the vehicle software application, [carry out the update] (Claiborne, e.g., ¶26, “serialized software distributor 4 is de-serialized by the user interface … software source server 16 is now able to access the sub-parts of the deserialized software distributor 18, namely the software grouping 6 and the interactive control script 10 … executes the wrapper script 8 … customizes the software grouping 6 for installation on the workstations …”) for the purpose of permitting the customization of a software application once to be installed on a plurality of target computing devices (Claiborne, e.g., ¶¶21-26).
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 OTA updates to vehicle ECUs as taught by Gomes to provide for receiving and reconstructing at the vehicle data chunks representing application packages to implement the vehicle software application, and upon full reconstruction, carrying out the update because the disclosure of Claiborne shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for updating software in a distributed system to provide for receiving and reconstructing at the vehicle data chunks representing application packages to implement the vehicle software application, and upon full reconstruction, carrying out the update for the purpose of permitting the customization of a software application once to be installed on a plurality of target computing devices (Claiborne, Id.).
Regarding claim 14, the rejection of claim 13 is incorporated, and Gomes further teaches: wherein said carrying out the execution plan comprises: determining, based on the deployment plan, respective electronic control units (ECUs) of a plurality of ECUs of the vehicle that are to be used to execute code included in the respective application packages of the set of application packages; and transmitting the respective application packages to the corresponding respective ECUs (Gomes, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …”).
Regarding claim 16, the rejection of claim 14 is incorporated, and Gomes further teaches: wherein said transmitting the respective application packages to the corresponding respective ECUs comprises sequentially transmitting the respective application packages to the respective ECUs according to a deployment sequence as defined in the deployment plan (Gomes, e.g., ¶195, “an example data structure of an information update 900, including details of an example update metadata portion 901 and an example data portion 902 …” See also, e.g., ¶196, “metadata 901 also comprises an affected vehicle application(s)/system(s) element 906, which may be used to identify one or more software application(s) … and/or vehicle systems … that are affected by the update … comprise an order policy element 908 that may define an order in which information updates … are to be applied, and a conditions required for update element 910 that may define the operating state in which the software application and/or vehicle system must be for an information update to be applied …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …”).
Regarding claim 17, the rejection of claim 13 is incorporated, and Gomes further teaches: wherein the program instructions that when executed cause the one or more processors to further implement: generating, by the vehicle application deployment planner, for respective ones of the ECUs, a respective localized ECU execution plan for deploying respective ones of the application packages at the respective ones of the ECUs, wherein the localized ECU execution plans are generated based, at least in part, on metadata describing respective execution environments of the respective ones of the ECUs; and sending the respective localized ECU execution plans to the respective ones of the ECUs (Gomes, e.g., ¶201, “method may direct the OBU to verify that the update version and the order policy of the information update … are consistent with the current version and update order policy of the vehicle configuration … to be updated …” and ¶202, “method may determine whether vehicle operating conditions required for application of the update … are currently met …. state of the vehicle (e.g., an AV) may comprise, for example … charging its batteries … traveling … the states of various vehicle components and/or systems that are able to be updates …” See also, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” and ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …”).
Regarding claim 18, the rejection of claim 13 is incorporated, and Kushwaha further teaches: wherein the deployment plan comprises conditional rules for the deployment of the set of application packages, wherein the conditional rules comprise one or more of: a conditional rule comprising a contingent deployment location to be used for a given one of the application packages in response to a failure of deployment of the given application package or another application package in an electronic control units (ECUs) of a plurality of ECUs of the vehicle; a conditional rule comprising a contingent deployment location for a given application package in response to a successful deployment of another one of the application packages in the ECU of the plurality of ECUs; or a conditional rule for selecting a deployment location for a given application package based on respective states, characteristics, and/or configurations of respective ones of the ECUs of the vehicle (Gomes, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …” See also, e.g., ¶196, “conditions required for update element 910 may indicate that … certain types or amounts of local storage must be available; and/or that a particular software application or vehicle system may not be present (e.g., due to competing processing load/use of storage/peripheral or sensor access demands.” Examiner’s note: the conditional rule determines whether a particular update is to be installed on a particular ECU, or to be deferred to a future time at which the conditions may be met, the conditions including states, characteristics or configurations of the ECUs (see in particular ¶196)).
Claim 15 is rejected under 35 U.S.C. § 103 as being unpatentable over Gomes in view of Claiborne, and in further view of Barrett et al., U.S. 2015/0073697 A1 (“Barrett”).
Regarding claim 15, the rejection of claim 14 is incorporated, but Kushwaha in view of Claiborne does not more particularly teach that the application packages are transmitted to corresponding ECUs via a plurality of different in-vehicle communication protocols including at least CAN and OBD. However, Barrett does teach: wherein the respective application packages are transmitted to the corresponding respective ECUs via a plurality of different in-vehicle communication protocols comprising two or more of: a controller area network (CAN) protocol; a remote procedure call (RPC) protocol; a controller area network flexible data-rate (CAN FD) protocol; a low-speed CAN protocol; a high-speed CAN protocol; a Society of Automotive Engineers (SAE) J1939 protocol; a CANopen protocol; or an on-board diagnostics (OBD) protocol (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 enabling a user to communicate with and alter the state of one or more vehicle components over a plurality of communication protocols (Barrett, e.g., ¶¶11-13)
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne to provide that the application packages are transmitted to corresponding ECUs via a plurality of different in-vehicle communication protocols including at least CAN and OBD 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 communicating disparate vehicle sensor and component data to provide that the application packages are transmitted to corresponding ECUs via a plurality of different in-vehicle communication protocols including at least CAN and OBD for the purpose of enabling a user to communicate with and alter the state of one or more vehicle components over a plurality of communication protocols (Barrett, Id.).
Claims 19-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Gomes in view of Claiborne, and in further view of Westrick, Jr. et al., U.S. 2017/0364046 A1 (“Westrick”).
Regarding claim 19, the rejection of claim 13 is incorporated, but Gomes in view of Claiborne does not more particularly teach that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols. However, Westrick does teach: wherein the received deployment plan and the received data chunks are transmitted to the vehicle application deployment planner using a protocol agnostic chunked transmission, wherein the protocol agnostic chunked transmission is compatible with a plurality of different server to vehicle transmission protocols (Westrick, e.g., ¶27, “applications in the layer 135 of the stack 121 interact through an application framework 137 …includes a … (MQTT) broker 141 and a MQTT client 143 for execution via the application framework …” See also, e.g., ¶28, “MQTT is a lightweight client/server messaging model …” and ¶30, “MQTT broker and associated clients provide data transfer that is relatively agnostic with respect to differences in protocols used for or by different applications …”) for the purpose of facilitating communication of data across heterogeneous devices without requiring protocol aggregation or conversion (Westrick, e.g., ¶¶27-31).
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne to provide that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols because the disclosure of Westrick shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for communicating disparate sensor and component data to provide that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols for the purpose of facilitating communication of data across heterogeneous devices without requiring protocol aggregation or conversion (Westrick, Id.).
Regarding claim 20, the rejection of claim 19 is incorporated, and Westrick further teaches: wherein the plurality of different transmission protocols with which the protocol agnostic format is compatible comprises, at least: a Message Queue Telemetry Transport (MQTT) protocol (Westrick, e.g., ¶27, “applications in the layer 135 of the stack 121 interact through an application framework 137 …includes a … (MQTT) broker 141 and a MQTT client 143 for execution via the application framework …” See also, e.g., ¶28, “MQTT is a lightweight client/server messaging model …” and ¶30, “MQTT broker and associated clients provide data transfer that is relatively agnostic with respect to differences in protocols used for or by different applications …”).
Claims 1, 3, 5 and 9 are rejected under 35 U.S.C. § 103 as being unpatentable over Gomes in view of Claiborne and McLennan et al., U.S. 8,595,187 B1 (“McLennan”).
Regarding claim 1, Gomes teaches: A system, comprising: one or more computing devices configured to implement a vehicle software deployment management system configured (Gomes, e.g., ¶221, “a non-transitory machine-readable medium having stored thereon a plurality of code sections … cause the one or more processors to perform the actions of a method of operating an on-board unit of a vehicle … to, among other things, receive and manage application of information updates …”) to:
generate a deployment plan for a set of application packages for use in implementing a distributed vehicle software application; … send the deployment plan … to the vehicle (Gomes, e.g., ¶195, “an example data structure of an information update 900, including details of an example update metadata portion 901 and an example data portion 902 …” See also, e.g., ¶196, “metadata 901 also comprises an affected vehicle application(s)/system(s) element 906, which may be used to identify one or more software application(s) … and/or vehicle systems … that are affected by the update … comprise an order policy element 908 that may define an order in which information updates … are to be applied, and a conditions required for update element 910 that may define the operating state in which the software application and/or vehicle system must be for an information update to be applied …”), wherein the deployment plan comprises instructions that, when executed, cause the vehicle application deployment planner to:
obtain metadata from the vehicle (Gomes, e.g., ¶201, “method may direct the OBU to verify that the update version and the order policy of the information update … are consistent with the current version and update order policy of the vehicle configuration … to be updated …” and ¶202, “method may determine whether vehicle operating conditions required for application of the update … are currently met …. state of the vehicle (e.g., an AV) may comprise, for example … charging its batteries … traveling … the states of various vehicle components and/or systems that are able to be updates …” See also, e.g., ¶196, “conditions required for update element 910 may indicate that … certain types or amounts of local storage must be available; and/or that a particular software application or vehicle system may not be present (e.g., due to competing processing load/use of storage/peripheral or sensor access demands”);
generate an execution plan for implementing the distributed vehicle software application at the vehicle based on the deployment plan and the vehicle metadata obtained from the vehicle (Gomes, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …”)[[,]]; and
… carry out the execution plan to implement the distributed vehicle software application at the vehicle in accordance with the deployment plan (Gomes, e.g., ¶205, “vehicle components and/or systems to be updated, or the OBU itself may apply the respective parts of the information update to the software, firmware … OBU may act as a manager and communication conduit for those systems other than the OBU …”).
Gomes does not more particularly teach generating and sending serialized data chunks for the application packages configured to be used by the vehicle to reconstruct the packages, and upon full reconstruction of the packages, carrying out the update. However, Claiborne does teach: generate … serialized data chunks for the set of application packages, wherein the … serialized data chunks are configured to be used by a vehicle application deployment planner of a vehicle to reconstruct the set of application packages (Claiborne, e.g., ¶24, “software distributor so it is stored … on the control server 2 in a serialized format, creating a serialized software distributor 4 … part of the serialized software distributor is a software grouping 6 … an interactive control script 10 …”); and
[send …] the [signed] serialized data chunks [to the vehicle] (Claiborne, e.g., ¶26, “user interface then copies the serialized software distributor 4 and the wrapper script 8 to the software source server 16 …”) …
upon determination of full reconstruction of the application packages, [carry out the update] (Claiborne, e.g., ¶26, “serialized software distributor 4 is de-serialized by the user interface … software source server 16 is now able to access the sub-parts of the deserialized software distributor 18, namely the software grouping 6 and the interactive control script 10 … executes the wrapper script 8 … customizes the software grouping 6 for installation on the workstations …”) for the purpose of permitting the customization of a software application once to be installed on a plurality of target computing devices (Claiborne, e.g., ¶¶21-26).
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 OTA updates to vehicle ECUs as taught by Gomes to provide for receiving and reconstructing at the vehicle data chunks representing application packages to implement the vehicle software application, and upon full reconstruction, carrying out the update because the disclosure of Claiborne shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for updating software in a distributed system to provide for receiving and reconstructing at the vehicle data chunks representing application packages to implement the vehicle software application, and upon full reconstruction, carrying out the update for the purpose of permitting the customization of a software application once to be installed on a plurality of target computing devices (Claiborne, Id.).
Gomes in view of Claiborne does not more particularly teach that the data chunks are also signed. However, McLennan does teach: [generate] signed [data chunks for the package] … [send the] signed [data chunks] … (McLennan, e.g., FIG. 8, wherein for each block in a patch for updating one or more files, a signature is generated for the sub-block based on the size of the sub-block; see also, e.g., 9:4-21, “modified image could be serialized into a file which includes multiple instances of the information … between the <deltainfo> tags, one for each variation on the base document … when it was time to replicate the modified image to a particular remote site …”) for the purpose of serializing data for replicating and patching files at remote devices, including signing information for verifying completeness and accuracy of a generated patch (McLennan, e.g., 10:39-12:42).
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne to provide that the data chunks are also signed because the disclosure of McLennan shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for updating software in a distributed system to provide that the data chunks are also signed for the purpose of serializing data for replicating and patching files at remote devices, including signing information for verifying completeness and accuracy of a generated patch (McLennan, Id.).
Claim 5 is rejected for the reasons given in the rejection of claim 1 above. Examiner notes that with respect to claim 5, Gomes further teaches: A method (Gomes, e.g., ¶221, “a non-transitory machine-readable medium having stored thereon a plurality of code sections … cause the one or more processors to perform the actions of a method of operating an on-board unit of a vehicle … to, among other things, receive and manage application of information updates …”), comprising: [[[the operations performed by the system of claim 1]]].
Regarding claim 3, the rejection of claim 1 is incorporated, and Gomes further teaches: wherein the deployment plan for the distributed vehicle software application comprises, for use in implementing the distributed vehicle software application at the vehicle: one or more indications of deployment dependencies between respective ones of the set of the application packages; or conditional rules for deployment of respective ones of the set of application packages (Gomes, e.g., ¶203, “if … method determined that the vehicle conditions for application of the information update had not been met … method may direct the OBU to save the update information for later application to the identified components and/or systems of the vehicle, if or when vehicle operating conditions are later met …” See also, e.g., ¶204, “method may direct the OBU to distribute the information update to the vehicle components and/or systems to be updated … OBU may distribute the respective parts of the information update to each system exterior to the OBU … use a vehicle network such as a [CAN] communication interface …” See also, e.g., ¶196, “conditions required for update element 910 may indicate that … certain types or amounts of local storage must be available; and/or that a particular software application or vehicle system may not be present (e.g., due to competing processing load/use of storage/peripheral or sensor access demands.” Examiner’s note: the conditional rule determines whether a particular update is to be installed on a particular ECU, or to be deferred to a future time at which the conditions may be met, the conditions including states, characteristics or configurations of the ECUs (see in particular ¶196)).
Claim 9 is rejected for the additional reasons given in the rejection of claim 3 above.
Claims 2 and 6-8 are rejected over Gomes in view of Claiborne and McLennan, and in further view of Kushwaha et al., U.S. 2020/0218531 A1 (“Kushwaha”).
Regarding claim 2, the rejection of claim 1 is incorporated, but Gomes in view of Claiborne and McLennan does not more particularly teach that the vehicle software deployment system receives from a client instructions indicating one or more application packages to be included in the set of application packages, and retrieving the application packages from one or more registries. However, Kushwaha does teach: wherein the vehicle software deployment management system is further configured to: receive, from a client, prior to the generating the deployment plan for the set of application packages, deployment instructions comprising one or more indications of application packages to be included in the set of application packages (Kushwaha, e.g., ¶42, “update engine 406 identifies the software state of the ECUs 210 in the vehicle 120 …” See also, e.g., ¶43, “update engine 406 selects a set … of update software components 410-415 for installation in the vehicle 120 … generates an update plan … based on the software state of the vehicle 120 and the authorized software configuration 422 for the vehicle …” See also, e.g., ¶35, “authorized software configurations 422 for vehicles that are tested and/or verified by the vehicle manufacturer(s) … OEM tests or validates which versions of the software components are interoperable in the network architecture of a vehicle, and approves the versions for release …”); and
retrieve, from one or more application package registries accessible by the vehicle software deployment management system, the set of application packages indicated to the vehicle deployment software management system by the client (Kushwaha, e.g., ¶44, “OTA interface 408 may also download the set of updated software components 410-415 to the vehicle … may download each of the updated software components separately …” See also, e.g., ¶35, “Storage controller 403 may provide a user interface 426 or portal that allows OEMs, part suppliers or venders … to upload software components and other software-related data …”) for the purpose of facilitating operable vehicle software updates by vehicle / component OEM selection of application package combinations and a determination of one or more combinations appropriate for a particular vehicle (Kushwaha, e.g., ¶¶35, 40-45).
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne and McLennan to provide that the vehicle software deployment system receives from a client instructions indicating one or more application packages to be included in the set of application packages, and retrieving the application packages from one or more registries because the disclosure of Kushwaha shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for application file storage and management to provide that the vehicle software deployment system receives from a client instructions indicating one or more application packages to be included in the set of application packages, and retrieving the application packages from one or more registries for the purpose of facilitating operable vehicle software updates by vehicle / component OEM selection of application package combinations and a determination of one or more combinations appropriate for a particular vehicle (Kushwaha, Id.).
Claims 6-7 are rejected for the additional reasons given in the rejection of claim 2 above.
Regarding claim 8, the rejection of claim 7 is incorporated, and Kushwaha further teaches: receiving, from a client of the vehicle software management system, one or more client-provided custom application packages; and storing in the one or more container storage locations the one or more client-provided custom application packages (Kushwaha, e.g., ¶35, “Storage controller 403 may provide a user interface 426 or portal that allows OEMs, part suppliers or vendors, or other authorized entities to upload software components and other software-related data … to data storage 402.” Examiner’s note: at least some software components provided by OEMs or other authorized entities are “custom” under the broadest reasonable interpretation of that term),
wherein at least a portion of the set of application packages retrieved for deployment include the one or more client-provided custom application packages (Kushwaha, e.g., ¶36, “update engine 406 selects updated software components 410-415 for installation in a vehicle or fleet of vehicles …” Examiner’s note: as the selection occurs from the software included in the data storage, at least one of the application packages selected may include the above-referenced custom software components) for the purpose of facilitating operable vehicle software updates by vehicle / component OEM selection of application package combinations and a determination of one or more combinations appropriate for a particular vehicle (Kushwaha, e.g., ¶¶35, 40-45).
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne and McLennan to provide for receiving from a client a provided custom application package, storing the package in a storage location, and retrieving the package as at least a portion of the set of application packages retrieved for deployment because the disclosure of Kushwaha shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for application file storage and management to provide for receiving from a client a provided custom application package, storing the package in a storage location, and retrieving the package as at least a portion of the set of application packages retrieved for deployment for the purpose of facilitating operable vehicle software updates by vehicle / component OEM selection of application package combinations and a determination of one or more combinations appropriate for a particular vehicle (Kushwaha, Id.).
Claims 4 and 10 are rejected under 35 U.S.C. § 103 as being unpatentable over Kushwaha in view of Claiborne and McLennan, and in further view of Scrivano, Giuseppe, U.S. 2023/0214290 A1 (“Scrivano”).
Regarding claim 4, the rejection of claim 1 is incorporated, but Gomes in view of Claiborne and McLennan does not more particularly teach that the application packages are formatted according to an OCI format. However, Scrivano does teach: wherein respective ones of the application packages of the set of application packages are formatted according to an Open Container Initiative (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 …”) for the purpose of providing a distributed containerized application service and maintaining data consistency and deduplication (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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne and McLennan to provide that the application packages are formatted according to an OCI format 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 application file storage and management to provide that the application packages are formatted according to an OCI format for the purpose of providing a distributed containerized application service and maintaining data consistency and deduplication (Scrivano, Id.).
Claim 10 is rejected for the additional reasons given in the rejection of claim 4 above.
Claims 11-12 are rejected under 35 U.S.C. § 103 as being unpatentable over Gomes in view of Claiborne and McLennan, and in further view of Westrick.
Regarding claim 11, the rejection of claim 5 is incorporated, but Gomes in view of Claiborne and McLennan does not more particularly teach that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols. However, Westrick does teach: wherein the deployment plan and the data chunks sent to the vehicle are sent using a protocol agnostic transmission format that is compatible with a plurality of different transmission protocols used for communications between a given remote server and a given vehicle (Westrick, e.g., ¶27, “applications in the layer 135 of the stack 121 interact through an application framework 137 …includes a … (MQTT) broker 141 and a MQTT client 143 for execution via the application framework …” See also, e.g., ¶28, “MQTT is a lightweight client/server messaging model …” and ¶30, “MQTT broker and associated clients provide data transfer that is relatively agnostic with respect to differences in protocols used for or by different applications …”) for the purpose of facilitating communication of data across heterogeneous devices without requiring protocol aggregation or conversion (Westrick, e.g., ¶¶27-31).
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 OTA updates to vehicle ECUs as taught by Gomes in view of Claiborne and McLennan to provide that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols because the disclosure of Westrick shows that it was known to those of ordinary skill in the pertinent art to improve a system and method for communicating disparate sensor and component data to provide that the received deployment plan and data chunks are transmitted to the vehicle using a protocol agnostic chunked transmission compatible with a plurality of different server to vehicle transmission protocols for the purpose of facilitating communication of data across heterogeneous devices without requiring protocol aggregation or conversion (Westrick, Id.).
Regarding claim 12, the rejection of claim 11 is incorporated, and Westrick further teaches: wherein the plurality of different transmission protocols with which the protocol agnostic format is compatible comprises, at least: a Message Queue Telemetry Transport (MQTT) protocol (Westrick, e.g., ¶27, “applications in the layer 135 of the stack 121 interact through an application framework 137 …includes a … (MQTT) broker 141 and a MQTT client 143 for execution via the application framework …” See also, e.g., ¶28, “MQTT is a lightweight client/server messaging model …” and ¶30, “MQTT broker and associated clients provide data transfer that is relatively agnostic with respect to differences in protocols used for or by different applications …”).
Response to Arguments
In the Remarks, Applicant Argues: In view of the amendments, the independent claims distinguish at least over the teachings of Kushwaha, and the claims are in condition for allowance (Resp. at 9-14).
Examiner’s Response: In view of the amendments, Examiner newly cites to Gomes, 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