Prosecution Insights
Last updated: April 19, 2026
Application No. 17/489,448

Over-The-Air (OTA) Update for Firmware of a Vehicle Component

Final Rejection §103§DP
Filed
Sep 29, 2021
Examiner
SOLTANZADEH, AMIR
Art Unit
2191
Tech Center
2100 — Computer Architecture & Software
Assignee
Lodestar Licensing Group LLC
OA Round
9 (Final)
81%
Grant Probability
Favorable
10-11
OA Rounds
2y 6m
To Grant
98%
With Interview

Examiner Intelligence

Grants 81% — above average
81%
Career Allow Rate
340 granted / 421 resolved
+25.8% vs TC avg
Strong +17% interview lift
Without
With
+16.9%
Interview Lift
resolved cases with interview
Typical timeline
2y 6m
Avg Prosecution
35 currently pending
Career history
456
Total Applications
across all art units

Statute-Specific Performance

§101
17.7%
-22.3% vs TC avg
§103
60.4%
+20.4% vs TC avg
§102
3.4%
-36.6% vs TC avg
§112
10.1%
-29.9% vs TC avg
Black line = Tech Center average estimate • Based on career data from 421 resolved cases

Office Action

§103 §DP
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 . Claims 1-2, 5-14, and 16-23 are presented for examination. Double Patenting The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969). A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b). The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp. Claims 1, 5-14, 16-23 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-16 of U.S. Patent No. 11144301. Although the claims at issue are not identical, they are not patentably distinct from each other because the referenced patent and the instant application are claiming common subject matter. For illustration purpose, Claim 1 rejection is provided as follow: Current Application U.S. Patent No. 11144301 1. An apparatus comprising: a communication interface; at least one controller; and memory containing instructions configured to instruct the at least one controller to: send at least one communication, via the communication interface, to a computing device to request a first update, the at least one communication including at least one desired characteristic, [based on an output from a computer model] receive the first update from the computing device [the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller]; in response to confirming authenticity of the first update, train, the computer model using the first update 1. A method comprising: collecting data from at least one sensor of a first vehicle; providing the data from the sensor of the first vehicle as an input to a computer model stored in memory of the first vehicle; determining, based on an output from the computer model, at least one desired characteristic; detecting a malfunction on a first computing device of the first vehicle; in response to detecting the malfunction, requesting a first update from a second computing device, wherein the requesting includes the first computing device sending the desired characteristic to the second computing device, and the second computing device collects and stores data from sensors of vehicles other than the first vehicle; receiving, by the first computing device, the first update from the second computing device, wherein the first update is selected by the second computing device based on the desired characteristic, and the first update includes the data from sensors of vehicles other than the first vehicle; determining authenticity of the first update by calculating a digest using a message authentication code, wherein the first update and a secret key are inputs to the message authentication code, and wherein the secret key is stored in memory of the first computing device; in response to determining authenticity of the first update, training, using the first update, the computer model; and updating firmware using the received first update, wherein updating the firmware modifies at least one action performed during execution of the firmware. Claim 1 of U.S. Patent No. 11144301 did not disclose “An apparatus comprising: a communication interface; at least one controller; and memory containing instructions configured to instruct the at least one controller to”. However, Caushi (US20180024826A1) discloses “A computing platform 104 may include one or more processors 106 connected with both a memory 108 and a computer-readable storage medium 112 and configured to perform instructions, commands” (See [0015]), which the computing platform 104 is interpreted to the claimed apparatus. Therefore, it would have been obvious to a person ordinary skill in the art to provide the computing platform as taught in Caushi in order to execute instructions of Vehicle applications to provide features to operate the vehicle (Caushi [0015]). Claim 1 of U.S. Patent No. 11144301 did not disclose “based on an output from a computer model”. However, Appel (US 20190036948 A1) teaches “based on an output from a computer model” (Para 0018, The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof … The analysis may include machine learning of normal vehicle behavior data. A root cause of the anomaly may be determined. One or more mitigation actions for mitigating the anomaly are taken). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to identify the desired characteristic based on the output of a computer model, as taught by Appel, in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). Claim 1 of U.S. Patent No. 11144301 did not disclose “the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller.” However, Rennie (US 8,583,333 B2) teaches the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller (Col 1, lines 4- Col 2, line 10: " a data collection and transmission method is provided that includes the steps: a sensor or equivalent hardware collecting information regarding road and/or weather conditions; establishing a connection to a remote server through a means such as a wireless network connection or the equivalent; transmitting the collected information through the established connection to the remote server; and storing the data on the server, which can be readily available to other processes or applications in the compilation and/or aggregation of information, such as extrapolation of data to model current and future weather characteristics, to be transmitted to other specified designations." ). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to “the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller” in order to disseminate real-time road condition and maintenance data collected from sensors on other vehicles, enhancing safety and efficiency for recipient vehicles by providing timely updates on road status by updating recipient vehicles including data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update including sensor data from another vehicle. Claim 2 of current application was not disclosed in U.S. Patent No. 11144301. However, Appel teaches wherein the instructions are further configured to instruct the at least one controller to: provide data from at least one sensor as an input to the computer model (Para 0018, The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof. The normal behavior model may be created by analyzing sources of data such as, but not limited to, telematics data (e.g., from multiple sensors inside a car)). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to provide data from at least one sensor as an input to the computer model, as taught by Appel, in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). However, Caushi (US20180024826A1) discloses “wherein the controller is further configured to: determine whether to accept the first update” (Caushi [Para 0044, In an example, a user of the vehicle 102 may opt into download of the software updates 220 via a prompt immediately prior to update download]). Therefore, it would have been obvious to a person ordinary skill in the art to provide the computing platform as taught in Caushi in order to execute instructions of Vehicle applications to provide features to operate the vehicle (Caushi [0015]). Further, Risbood (US 9063818 B1) discloses “Wherein the computer model is trained in response to determining to accept the first update” (Col 2, ln 20-35, logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning). Therefore, It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to train using the first update the computer model, as taught by Risbood’s in order to enable allowing a predictor to use the trained mathematical model to predict whether a software update is automatically installed on a given client and commanding the client to install based on the prediction, thus performing improved decision tree learning, association rule learning, clustering and reinforcement learning processes (Risbood [Summary). Claims 1, 5-14, 16-23 are rejected on the ground of non-statutory double patenting as being unpatentable over claims 1-19 of U.S. Patent No. 10409585. Although the claims at issue are not identical, they are not patentably distinct from each other because the referenced patent and the instant application are claiming common subject matter. For illustration purpose, Claim 1 rejection is provided as follow: Current Application U.S. Patent No. 10409585 1. An apparatus comprising: a communication interface; at least one controller; and memory containing instructions configured to instruct the at least one controller to: send at least one communication, via the communication interface, to a computing device to request a first update, the at least one communication including at least one desired characteristic determined [based on an output from a computer model] receive the first update from the computing device [the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller]; in response to confirming authenticity of the first update, train, the computer model using the first update 3. detecting a malfunction for an application executed by the application controller, wherein the update is requested by the application controller in response to detecting the malfunction, and wherein the update reconfigures at least one function of the application Claim 1 of U.S. Patent No. 10409585 did not disclose “An apparatus comprising: a communication interface; at least one controller; and memory containing instructions configured to instruct the at least one controller to … receive the first update from the computing device, wherein the first update corresponds to the desired characteristic … and in response to receiving, update a configuration of the controller using the first update, … update a configuration of the controller using the first update, wherein updating the configuration comprises modifying at least one action performed by the controller”. However, Caushi (US20180024826A1) discloses “A computing platform 104 may include one or more processors 106 connected with both a memory 108 and a computer-readable storage medium 112 and configured to perform instructions, commands” (See [0015]), which the computing platform 104 is interpreted to the claimed apparatus. Caushi further discloses “receive the first update from the computing device, wherein the first update corresponds to the desired characteristic” (Para 0052, The computing platform 104 may accordingly download the software updates 220 as shown at time index (G). As one example, the instructions 216 may specify the network locations as URLs served by a web server 218 of the IVSU 202, and the computing platform 104 may download the software update 220 from the URLs specified by the instructions 216); “and in response to receiving the first update, update a configuration of the controller using the first update, wherein updating the configuration comprises modifying at least one action performed by the controller” (Para 0053, At time index (H), the computing platform 104 installs the downloaded software updates 220). Therefore, it would have been obvious to a person ordinary skill in the art to provide the computing platform as taught in Caushi in order to execute instructions of Vehicle applications to provide features to operate the vehicle (Caushi [0015]). Claim 1 of U.S. Patent No. 10409585 did not disclose “based on an output from a computer model”. However, Appel (US 20190036948 A1) teaches “based on an output from a computer model” (Para 0018, The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof … The analysis may include machine learning of normal vehicle behavior data. A root cause of the anomaly may be determined. One or more mitigation actions for mitigating the anomaly are taken). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to identify the desired characteristic based on the output of a computer model, as taught by Appel, in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). Claim 1 of U.S. Patent No. 10409585 did not disclose “and in response to confirming authenticity of the first update.” However, Hunt (US 20180275982 A1) teaches “in response to confirming authenticity of the first update” (Para 0062, the software update analyzer is further to verify an integrity of the software update with a manifest that includes one or more signatures for one or more components of the software update). Therefore, It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to confirm authenticity of the first update as taught by Hunt, in order to distribute software update, by having a update manager determining several target mesh nodes of several mesh nodes for software update and verify the integrity of the contents of the components of the software update as a function of the one or more signatures included in the manifest (Hunt [Summary], [0039]). Claim 1 of U.S. Patent No. 10409585 did not disclose “train, the computer model using the first update”. However, Risbood (US 9063818 B1) teaches “train, using the first update, the computer model” (Col 2, ln 20-35, logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning). Therefore, It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to train using the first update the computer model, as taught by Risbood’s in order to enable allowing a predictor to use the trained mathematical model to predict whether a software update is automatically installed on a given client and commanding the client to install based on the prediction, thus performing improved decision tree learning, association rule learning, clustering and reinforcement learning processes (Risbood [Summary). Claim 1 of U.S. Patent No. 10409585 did not disclose “the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller.” However, Rennie (US 8,583,333 B2) teaches the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller (Col 1, lines 4- Col 2, line 10: " a data collection and transmission method is provided that includes the steps: a sensor or equivalent hardware collecting information regarding road and/or weather conditions; establishing a connection to a remote server through a means such as a wireless network connection or the equivalent; transmitting the collected information through the established connection to the remote server; and storing the data on the server, which can be readily available to other processes or applications in the compilation and/or aggregation of information, such as extrapolation of data to model current and future weather characteristics, to be transmitted to other specified designations." ). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to “the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller” in order to disseminate real-time road condition and maintenance data collected from sensors on other vehicles, enhancing safety and efficiency for recipient vehicles by providing timely updates on road status by updating recipient vehicles including data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update including sensor data from another vehicle. Claim 2 of current application was not disclosed in U.S. Patent No. 10409585. However, Appel teaches wherein the instructions are further configured to instruct the at least one controller to: provide data from at least one sensor as an input to the computer model (Para 0018, The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof. The normal behavior model may be created by analyzing sources of data such as, but not limited to, telematics data (e.g., from multiple sensors inside a car)). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to provide data from at least one sensor as an input to the computer model, as taught by Appel, in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). Claim 13 of current application was not fully disclosed in U.S. Patent No. 10409585. However, Caushi (US20180024826A1) discloses “wherein the controller is further configured to: determine whether to accept the first update” (Caushi [Para 0044, In an example, a user of the vehicle 102 may opt into download of the software updates 220 via a prompt immediately prior to update download]). Therefore, it would have been obvious to a person ordinary skill in the art to provide the computing platform as taught in Caushi in order to execute instructions of Vehicle applications to provide features to operate the vehicle (Caushi [0015]). Further, Risbood (US 9063818 B1) discloses “Wherein the computer model is trained in response to determining to accept the first update” (Col 2, ln 20-35, logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning). Therefore, It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to train using the first update the computer model, as taught by Risbood’s in order to enable allowing a predictor to use the trained mathematical model to predict whether a software update is automatically installed on a given client and commanding the client to install based on the prediction, thus performing improved decision tree learning, association rule learning, clustering and reinforcement learning processes (Risbood [Summary). Claim Interpretation The following is a quotation of 35 U.S.C. 112(f): (f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph: An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof. The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph: (A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function; (B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and (C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function. Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function. Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “a controller configured to …” in claim 12, “wherein the controller is further configured to …” in Claim 13-16. Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows: 1. Determining the scope and contents of the prior art. 2. Ascertaining the differences between the prior art and the claims at issue. 3. Resolving the level of ordinary skill in the pertinent art. 4. Considering objective evidence present in the application indicating obviousness or nonobviousness. Claim(s) 1, 7, 9, 11, 19 and 23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) and Rennie (US 8,583,333 B2). Regarding Claim 1, Caushi (US 2018/0024826 A1) teaches An apparatus comprising: a communication interface; at least one controller; and memory containing instructions configured to instruct the at least one controller to: send at least one communication, via the communication interface, to a computing device to request a first update, the at least one communication including at least one desired characteristic (Para [0051]: "Based on the instructions 216, at time index (F) the computing platform 104 requests the software updates 220 (e.g., configuration files, binaries, etc.) from the link locations specified by the instructions 216. In one example, the computing platform 104 may request the updates from region-specific network locations for the regional software delivery network 204 intended to serve the region 210. In another example, the computing platform 104 may request the region-specific update files from the link locations specified by the instructions 216."; Para 0002, In one example, the updates may include changes to the software or settings of the vehicle to address an issue or to provide improved functionality to current software or settings) Examiner Comments: The request communication includes specified link locations as the desired characteristic for the update type, determined from the instructions which represent the output of the update management model; receive the first update from the computing device (Para [0052]: "At time index (G) the regional software delivery network 204 provides the requested software updates 220 to the vehicle 102.") Examiner Comments: The vehicle receives the software update from the network computing device, directly mapping to receiving the first update. Caushi did not specifically teach the desired characteristic determined based on an output from a computer model; in response to confirming authenticity of the first update and a source of the first update, train the computer model using the first update the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller. However, Forest (US 9,280,653 B2) teaches in response to confirming authenticity of the first update and a source of the first update (Col 2, lines 30-50: "The service tool that wants to gain access to the ECU for software reprogramming or service requests the ECU identification value and a challenge from the ECU and sends them to the secure server, which then identifies the security key value associated with that ECU identification value and the response for the challenge. The secure server then sends the response to the service tool, which provides it to the ECU to unlock it for programming.") Examiner Comments: The challenge-response mechanism confirms the authenticity of the reprogramming update and verifies the source through the secure server key association, ensuring only authorized sources can initiate the update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi’s teaching into Forest’s in order to provide a cost-effective security method resistant to unauthorized access attacks on vehicle ECUs, by verifying the authenticity of the update and its source to prevent unauthorized reprogramming of vehicle ECUs. Therefore, there is a need in the art for a security access method for automotive electronic control units that is cost effective, does not require high levels of memory and processing power in the ECU, and is resistant to attacks (Forest, [background/summary]). Caushi and Forest did not specifically teach the desired characteristic determined based on an output from a computer model; train the computer model using the first update the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller. However, Risbood (US 9,063,818 B1) teaches the desired characteristic determined based on an output from a computer model (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The mathematical model's output probability determines the desired patch characteristic for installation, directly mapping to determining the desired update based on model output; train the computer model using the first update (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The logging of the software update installation serves as training data to train the mathematical model, mapping to training the computer model using the first update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi and Forest’s teaching into Risbood’s in order to predict and automatically handle software updates, reducing the risk of uninstalled patches causing problems, so as to use a computer model to determine desired updates and train the model using the update to predict and automatically handle software installations, reducing administrative burden (Risbood [Summary]). Caushi, Forest and Risbood did not specifically teach the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller. However, Rennie (US 8,583,333 B2) teaches the first update including at least some data from at least one sensor of a vehicle other than a first vehicle that includes the at least one controller (Col 1, lines 4- Col 2, line 10: " a data collection and transmission method is provided that includes the steps: a sensor or equivalent hardware collecting information regarding road and/or weather conditions; establishing a connection to a remote server through a means such as a wireless network connection or the equivalent; transmitting the collected information through the established connection to the remote server; and storing the data on the server, which can be readily available to other processes or applications in the compilation and/or aggregation of information, such as extrapolation of data to model current and future weather characteristics, to be transmitted to other specified designations." ) Examiner Comments: The update disseminated to recipient vehicles includes data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update, including sensor data from another vehicle. The server generates and sends updates based on sensor data from maintenance vehicles to other recipient vehicles, directly teaching the update, including data from sensors of other vehicles. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi, Forest and Risbood’s teaching with Rennie’s in order to disseminate real-time road condition and maintenance data collected from sensors on other vehicles, enhancing safety and efficiency for recipient vehicles by providing timely updates on road status by updating recipient vehicles including data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update including sensor data from another vehicle. Regarding Claim 7, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi further teaches wherein the at least one controller is an application controller for a vehicle, and receiving the first update comprises receiving an over-the-air update of the first update (Fig.1 , Computing platform 104; Para [0002]: "One or more software and/or hardware components of a vehicle may require periodic or occasional electronic updates. In one example, the updates may include changes to the software or settings of the vehicle to address an issue or to provide improved functionality to current software or settings. In another example, the updates may include updated configuration settings for one or more vehicle controllers and/or updated versions of software or firmware to be installed on the one or more vehicle controllers.") Examiner Comments: The updates are for vehicle controllers over the air, mapping to the application controller receiving OTA updates. Regarding Claim 9, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi further teaches wherein the received first update is stored in system memory of the at least one controller (Para [0053]: "At time index (H) the computing platform 104 installs the software updates 220.") Examiner Comments: The updates are installed into the vehicle's computing platform memory, mapping to storage in system memory. Regarding Claim 11, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi further teaches wherein the at least one controller is an application controller (Para [0015]: " the computing platform 104 may be configured to execute instructions of vehicle applications 110 to provide features such as navigation, accident reporting, satellite radio decoding, and hands-free calling.") Examiner Comments: The computing platform is the application controller for vehicle functions. Regarding Claim 19, Caushi teach A system comprising: at least one controller of a first vehicle; and memory containing instructions configured to instruct the at least one controller to: send at least one desired characteristic to a first server (Para [0051]: "Based on the instructions 216, at time index (F) the computing platform 104 requests the software updates 220 (e.g., configuration files, binaries, etc.) from the link locations specified by the instructions 216.") Examiner Comments: The request sends the desired update characteristics to the network server; request a first update from the first server, (Para [0051]: "In one example, the computing platform 104 may request the updates from region-specific network locations for the regional software delivery network 204 intended to serve the region 210.") Examiner Comments: The server stores and provides updates collected for multiple vehicles; wherein the first server collects and stores data from sensors of vehicles other than the first vehicle (Para [0030], “The IVSU 202 may receive these communications from the vehicles 102, and may maintain a data store of the hardware configurations and software (e.g., firmware, etc.) versions linked to identifiers of the vehicles 102, e.g., linked to VIN of the vehicle 102”) Examiner Comments: The IVSU receives information from multiple vehicles 102; receive, via wireless transmission, the first update from the first server, wherein the first update corresponds to the at least one desired characteristic (Para [0052]: "The computing platform 104 may accordingly download the software updates 220 as shown at time index (G). As one example, the instructions 216 may specify the network locations as URLs served by a web server 218 of the IVSU 202, and the computing platform 104 may download the software update 220 from the URLs specified by the instructions 216.") Examiner Comments: Wireless OTA receipt of the update matching the requested characteristic; Caushi did not specifically teach in response to confirming authenticity of the first update and a source of the first update, train the computer model using the first update and includes at least some data of the data from at least one sensors the sensors of the vehicles other than the first vehicle. However, Forest (US 9,280,653 B2) teaches in response to confirming authenticity of the first update and a source of the first update (Col 2, lines 30-50: "The service tool that wants to gain access to the ECU for software reprogramming or service requests the ECU identification value and a challenge from the ECU and sends them to the secure server, which then identifies the security key value associated with that ECU identification value and the response for the challenge. The secure server then sends the response to the service tool, which provides it to the ECU to unlock it for programming.") Examiner Comments: The challenge-response mechanism confirms the authenticity of the reprogramming update and verifies the source through the secure server key association, ensuring only authorized sources can initiate the update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi’s teaching into Forest’s in order to provide a cost-effective security method resistant to unauthorized access attacks on vehicle ECUs, by verifying the authenticity of the update and its source to prevent unauthorized reprogramming of vehicle ECUs. Therefore, there is a need in the art for a security access method for automotive electronic control units that is cost effective, does not require high levels of memory and processing power in the ECU, and is resistant to attacks (Forest, [background/summary]). Caushi and Forest did not specifically teach train the computer model using the first update and includes at least some data of the data from at least one sensors the sensors of the vehicles other than the first vehicle. However, Risbood (US 9,063,818 B1) teaches the desired characteristic determined based on an output from a computer model (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The mathematical model's output probability determines the desired patch characteristic for installation, directly mapping to determining the desired update based on model output; train the computer model using the first update (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The logging of the software update installation serves as training data to train the mathematical model, mapping to training the computer model using the first update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi and Forest’s teaching into Risbood’s in order to predict and automatically handle software updates, reducing the risk of uninstalled patches causing problems, so as to use a computer model to determine desired updates and train the model using the update to predict and automatically handle software installations, reducing administrative burden (Risbood [Summary]). Caushi, Forest and Risbood did not specifically teach and includes at least some data of the data from at least one sensors the sensors of the vehicles other than the first vehicle. However, Rennie (US 8,583,333 B2) teaches and includes at least some data of the data from at least one sensors the sensors of the vehicles other than the first vehicle (Col 1, lines 4- Col 2, line 10: " a data collection and transmission method is provided that includes the steps: a sensor or equivalent hardware collecting information regarding road and/or weather conditions; establishing a connection to a remote server through a means such as a wireless network connection or the equivalent; transmitting the collected information through the established connection to the remote server; and storing the data on the server, which can be readily available to other processes or applications in the compilation and/or aggregation of information, such as extrapolation of data to model current and future weather characteristics, to be transmitted to other specified designations." ) Examiner Comments: The update disseminated to recipient vehicles includes data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update, including sensor data from another vehicle. The server generates and sends updates based on sensor data from maintenance vehicles to other recipient vehicles, directly teaching the update, including data from sensors of other vehicles. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi, Forest and Risbood’s teaching with Rennie’s in order to disseminate real-time road condition and maintenance data collected from sensors on other vehicles, enhancing safety and efficiency for recipient vehicles by providing timely updates on road status by updating recipient vehicles including data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update including sensor data from another vehicle. Regarding Claim 23, Caushi, Forest, Risbood and Rennie teach The system of Claim 19. Caushi further teaches wherein a computer program corresponding to the first update is stored in system memory, and wherein the instructions are further configured to instruct the at least one controller to, in response to determining to accept the first update, execute the computer program (Para [0053]: "At time index (H) the computing platform 104 installs the software updates 220.") Examiner Comments: Installation stores and executes the update program in memory upon acceptance. Claim(s) 2, 12-13, 16 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) further in view of Appel (US 2019/0036948 A1). Regarding Claim 2, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi, Forest, Risbood and Rennie did not specifically teach wherein the instructions are further configured to instruct the at least one controller to: provide data from the at least one sensor as an input to the computer model. However, Appel (US 2019/0036948 A1) teaches wherein the instructions are further configured to instruct the at least one controller to: provide data from at least one sensor as an input to the computer model (Para [0018]: " The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof. The normal behavior model may be created by analyzing sources of data such as, but not limited to, telematics data (e.g., from multiple sensors inside a car)." Para [0020], “ For example, based on data collected by sensors inside a car, telematics data correlated among thousands of cars, or a combination of multiple types of data, malware running on a specific set of the cars may be detected before it spreads to the other cars”) Examiner Comments: The training data includes sensor-like threat data inputs to train the model for malware detection in updates. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest and Risbood’s teaching to Appel’s in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). Regarding Claim 12, Caushi teaches An apparatus comprising: a sensor (Para [0020]: " a climate control management controller configured to provide control and monitoring of heating and cooling system components (e.g., compressor clutch and blower fan control, temperature sensor information, etc.).") Examiner Comments: Vehicle sensors provide data; a memory; and a controller configured to: request a first update from at least one server (Para [0051], “Based on the instructions 216, at time index (F) the computing platform 104 requests the software updates 220 (e.g., configuration files, binaries, etc.) from the link locations specified by the instructions 216.”; Para [0038], “The instructions 216 may be a file or other data structure configured to identify binaries or other software updates 220 that should be installed to the vehicle 102”) receive, by a wireless transmission from the at least one server, the first update, wherein the first update corresponds to the at least one desired characteristic (Para [0052]: "At time index (G) the regional software delivery network 204 provides the requested software updates 220 to the vehicle 102.") Examiner Comments: The vehicle receives the software update from the network computing device, directly mapping to receiving the first update. Caushi did not specifically teach provide data from the sensor as an input to a computer model stored in the memory; determine, based on an output from the computer model, at least one desired characteristic and in response to confirming authenticity of the first update and a source of the first update using a cryptographic measurement, train the computer model using the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the sensor. However, Forest (US 9,280,653 B2) teaches and in response to confirming authenticity of the first update and a source of the first update using a cryptographic measurement (Col 2, lines 30-50: "The service tool that wants to gain access to the ECU for software reprogramming or service requests the ECU identification value and a challenge from the ECU and sends them to the secure server, which then identifies the security key value associated with that ECU identification value and the response for the challenge. The secure server then sends the response to the service tool, which provides it to the ECU to unlock it for programming." Col 3: ln 8-25, This security key is used with a cryptographic authentication algorithm) Examiner Comments: The challenge-response mechanism confirms the authenticity of the reprogramming update and verifies the source through the secure server key association, ensuring only authorized sources can initiate the update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi’s teaching into Forest’s in order to provide a cost-effective security method resistant to unauthorized access attacks on vehicle ECUs, by verifying the authenticity of the update and its source to prevent unauthorized reprogramming of vehicle ECUs. Therefore, there is a need in the art for a security access method for automotive electronic control units that is cost effective, does not require high levels of memory and processing power in the ECU, and is resistant to attacks (Forest, [background/summary]). Caushi and Forest did not specifically teach provide data from the sensor as an input to a computer model stored in the memory; determine, based on an output from the computer model, at least one desired characteristic train the computer model using the first update includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the sensor. However, Risbood (US 9,063,818 B1) teaches determine, based on an output from the computer model, at least one desired characteristic (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The mathematical model's output probability determines the desired patch characteristic for installation, directly mapping to determining the desired update based on model output; train the computer model using the first update (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") Examiner Comments: The logging of the software update installation serves as training data to train the mathematical model, mapping to training the computer model using the first update. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi and Forest’s teaching into Risbood’s in order to predict and automatically handle software updates, reducing the risk of uninstalled patches causing problems, so as to use a computer model to determine desired updates and train the model using the update to predict and automatically handle software installations, reducing administrative burden (Risbood [Summary]). Caushi, Forest and Risbood did not specifically teach provide data from the sensor as an input to a computer model stored in the memory includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the sensor. However, Appel (US 2019/0036948 A1) teaches wherein the instructions are further configured to instruct the at least one controller to: provide data from at least one sensor as an input to the computer model (Para [0018]: " The detection is further based on a normal behavior model created based on individual vehicle behavior, fleet behavior, sub-fleet behavior, service behavior, or a combination thereof. The normal behavior model may be created by analyzing sources of data such as, but not limited to, telematics data (e.g., from multiple sensors inside a car)." Para [0020], “ For example, based on data collected by sensors inside a car, telematics data correlated among thousands of cars, or a combination of multiple types of data, malware running on a specific set of the cars may be detected before it spreads to the other cars”) Examiner Comments: The training data includes sensor-like threat data inputs to train the model for malware detection in updates. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest and Risbood’s teaching to Appel’s in order to provide security for connected vehicles by detecting anomaly based on normal behavior model and set of data, determining mitigation action based on detected anomaly, and causing implementation of mitigation action (Appel [Summary]). Caushi, Forest, Risbood and Appel did not specifically teach includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the sensor. However, Rennie (US 8,583,333 B2) teaches includes at least some data from at least one sensor of a vehicle other than a first vehicle that includes the sensor (Col 1, lines 4- Col 2, line 10: " a data collection and transmission method is provided that includes the steps: a sensor or equivalent hardware collecting information regarding road and/or weather conditions; establishing a connection to a remote server through a means such as a wireless network connection or the equivalent; transmitting the collected information through the established connection to the remote server; and storing the data on the server, which can be readily available to other processes or applications in the compilation and/or aggregation of information, such as extrapolation of data to model current and future weather characteristics, to be transmitted to other specified designations." ) Examiner Comments: The update disseminated to recipient vehicles includes data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update, including sensor data from another vehicle. The server generates and sends updates based on sensor data from maintenance vehicles to other recipient vehicles, directly teaching the update, including data from sensors of other vehicles. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi, Forest, Risbood And Appel’s teaching with Rennie’s in order to disseminate real-time road condition and maintenance data collected from sensors on other vehicles, enhancing safety and efficiency for recipient vehicles by providing timely updates on road status by updating recipient vehicles including data collected from sensors on road maintenance vehicles (other vehicles), such as location and operational status from sensors, mapping to the first update including sensor data from another vehicle. Regarding Claim 13, Caushi, Forest, Risbood, Appel and Rennie teach The apparatus of Claim 12. Caushi further teaches wherein the controller is further configured to: determine whether to accept the first update (Para [0053]: "At time index (H) the computing platform 104 installs the software updates 220.") Examiner Comments: Installation implies acceptance determination. Caushi and Forest did not specifically teach wherein the computer model is trained in response to determining to accept the first update. However, Risbood teaches wherein the computer model is trained in response to determining to accept the first update (Col 2, lines 20-35: "Various implementations include a framework for (i) logging actions around software installation and usage in a network of computers; (ii) logging system administrator behavior when sent a notification for a software update; (iii) logging the installation of a software update/patch and ensuring system is functioning as before; (iv) taking into account all of these signals as training data, to create a mathematical model using machine learning; and (v) using the mathematical model to predict the probability of a software patch actually being installed by the administrator and using the prediction to decide whether or not to automatically install the software on the computer network.") It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Caushi and Forest’s teaching into Risbood’s in order to predict and automatically handle software updates, reducing the risk of uninstalled patches causing problems. Regarding Claim 16, Caushi, Forest, Risbood, Appel and Rennie teach The apparatus of Claim 12. Caushi further teaches wherein the controller is further configured to, in response to determining to accept the first update, copy the first update to system memory of the controller (Para [0053]: "At time index (H) the computing platform 104 installs the software updates 220.") Examiner Comments: Installation copies to memory. Regarding Claim 18, Caushi, Forest, Risbood, Appel and Rennie teach The apparatus of Claim 12. Caushi further teaches wherein the first update includes a software update, and wherein the controller is further configured to, in response to determining to accept the first update, discard a previously-received software update (Para [0053]: "At time index (H) the computing platform 104 installs the software updates 220.") Examiner Comments: New installation implies discarding old versions. Claim(s) 5 and 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) and Rennie (US 8,583,333 B2) further in view of Maletsky (US 2015/0339213 A1). Regarding Claim 5, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi, Forest, Risbood and Rennie did not specifically teach wherein the instructions are further configured to instruct the at least one controller to determine the authenticity of the first update by calculating a digest using a message authentication code. However, Maletsky (US 2015/0339213 A1) teaches wherein the instructions are further configured to instruct the at least one controller to determine the authenticity of the first update by calculating a digest using a message authentication code (Para [0112]: " where the response includes a MAC of a digest of the code generated by the client device based on the digest generated by the client device and a shared secret key stored within the client device, and the verifying correctness of the response includes: calculating a MAC of a digest of the authorized code based on the authorized code stored in a secure storage and the shared secret key stored in the secure storage; and validating the MAC of the digest of the code in the response based on the calculated MAC of the digest of the authorized code.") It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Maletsky’s in order for the security of the host and client network is improved by the security of the host device by using trusted or secured host device to perform controlled secure code authentication on the client device (Maletsky [Summary]). Regarding Claim 6, Caushi, Forest, Risbood, Rennie and Maletsky teach The apparatus of Claim 5. Caushi, Forest, Risbood and Rennie did not specifically teach wherein the first update and a secret key are inputs to the message authentication code, and wherein the secret key is stored in the at least one controller. However, Maletsky further teaches wherein the first update and a secret key are inputs to the message authentication code, and wherein the secret key is stored in the at least one controller (Para [0112]: " where the response includes a MAC of a digest of the code generated by the client device based on the digest generated by the client device and a shared secret key stored within the client device.") It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest and Risbood’s teaching to Maletsky’s in order for the security of the host and client network is improved by the security of the host device by using trusted or secured host device to perform controlled secure code authentication on the client device (Maletsky [Summary]). Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) and Rennie (US 8,583,333 B2) further in view of Pirakash (US20110131447 A1). Regarding Claim 8, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi, Forest, Risbood and Rennie did not specifically teach further comprising a boot device, wherein the first update is firmware, and the received first update is stored on the boot device. However, Pirakash (US20110131447 A1) teaches further comprising a boot device, wherein the first update is firmware, and the received first update is stored on the boot device (Para [0059]: "As the console devices are established and access to boot devices is established, additional firmware volumes may be discovered.") It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Pirakash in order for the updates can be enabled to be performed for specific BIOS/platform firmware code module or an application by receiving an updated boot firmware code module in secure partition of system, the updated boot firmware code is provided to replace one original boot firmware code module of several boot firmware code modules for the system (Pirakash [Summary]). Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) and Rennie (US 8,583,333 B2) further in view of Jang (US 20140325500). Regarding Claim 10, Caushi, Forest, Risbood and Rennie teach The apparatus of Claim 1. Caushi further teaches wherein the instructions are further configured to instruct the at least one controller to: control at least one function of the vehicle (Para [0015]: " A computing platform 104 may include one or more processors 106 connected with both a memory 108 and a computer-readable storage medium 112 and configured to perform instructions, commands, and other routines in support of the processes described herein. For instance, the computing platform 104 may be configured to execute instructions of vehicle applications 110 to provide features such as navigation, accident reporting, satellite radio decoding, and hands-free calling.") Caushi, Forest, Risbood and Rennie did not specifically teach and prior to receiving the first update from the computing device, authenticate a user of the vehicle; wherein the first update is received from the computing device in response to authenticating. However, Jang teaches and prior to receiving the first update from the computing device, authenticate a user of the vehicle; wherein the first update is received from the computing device in response to authenticating (Para [0011]: " there is provided a method for transmitting a software update for a vehicle with an electronic control unit, including steps of: storing a software update of an electronic control unit of a vehicle by an update server; making the update server wirelessly connected to the vehicle, if a user requests an update for the electronic control unit and the user is authenticated; and allowing the update server to transmit the software update to the vehicle at the request of the user.") It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Jang’s in order to allows user to download software update conveniently by allowing an update device of vehicle to wirelessly connect to update server at a request of user terminal, allowing the update device to download software update from the update server, and allowing the update device to update the electronic control unit using the software update (Jang [Summary]). Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) further in view of Appel (US 2019/0036948 A1) and Rennie (US 8,583,333 B2) further in view of Kotani (US 20150113520). Regarding Claim 14, Caushi, Forest, Risbood, Appel and Rennie teach The apparatus of Claim 12. Caushi, Forest, Risbood, Appel and Rennie did not specifically teach wherein the controller is further configured to: determine, based on the cryptographic measurement, whether to accept or reject the first update; wherein firmware is updated in response to determining to accept the first update. However, Kotani (US 20150113520) teaches wherein the controller is further configured to: determine, based on the cryptographic measurement, whether to accept or reject the first update (Para [0101]: " the server authentication unit 202 calculates the hash value of the transmission target data by using the hash function that is stored in the authentication information storage unit 201. Then, the server authentication unit 202 compares the calculated hash value with the hash value acquired by decrypting the digital signature, and decides that the update server 22 is authentic and that the transmission target data received from the update server 22 is not falsified, when the comparison results are matched”) wherein firmware is updated in response to determining to accept the first update (Para [0025], the update software application unit 204 transmits the update instruction together with the update software to each ECU 24 in which the update target software is operating (S504)). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood, Appel and Rennie’s teaching to Kotani’s in order to confirm update program to control unit mounted on motor vehicle, by determining whether application process of update program with respect to control unit is successful or failed (Kotani [Summary]). Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) further in view of Appel (US 2019/0036948 A1) and Rennie (US 8,583,333 B2) further in view of Kotani (US 20150113520) and Pirakash (US 20110131447). Regarding Claim 17, Caushi, Forest, Risbood, Appel and Rennie teach The apparatus of claim 12. Caushi, Forest, Risbood, Appel and Rennie did not teach wherein the cryptographic measurement is determined by a cryptographic engine of the controller, and wherein the controller is further configured to: prior to determining the cryptographic measurement, receive a data value from [a boot device], and store the data value in the memory. However, Kotani (US 20150113520) teaches wherein the cryptographic measurement is determined by a cryptographic engine of the controller, and wherein the controller is further configured to: prior to determining the cryptographic measurement, receive a data value from [a boot device], and store the data value in the memory (Paragraph 0101, When receiving from the update server 22 the transmission target data and digital signature that have been encrypted, the server authentication unit 202 decrypts the received information by using the private key of the in-vehicle equipment 23. Next, the server authentication unit 202 decrypts the digital signature by using the public key of the server 22 and acquires the hash value; Paragraph 0148, The program according to the present embodiment may be provided to the update server 22 in the following forms. (1) Installed in the storage 403 beforehand. (2) Provided by the removable storage medium 450]) Examiner Comments: The authentication process and acquiring the hash value can be interpreted to the claimed cryptographic measurement. It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood, Appel and Rennie’s teaching to Kotani’s in order to confirm update program to control unit mounted on motor vehicle, by determining whether application process of update program with respect to control unit is successful or failed (Kotani [Summary]). Caushi, Forest, Risbood, Appel, Rennie and Kotani did not teach a boot device. However, Pirakash (US 20110131447) teaches a boot device (Paragraph 0059, As the console devices are established and access to boot devices is established, additional firmware volumes may be discovered). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood, Appel and Rennie and Kotani’s teaching to Pirakash in order for the updates can be enabled to be performed for specific BIOS/platform firmware code module or an application by receiving an updated boot firmware code module in secure partition of system, the updated boot firmware code is provided to replace one original boot firmware code module of several boot firmware code modules for the system (Pirakash [Summary]). Claim(s) 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US 2018/0024826 A1) in view of Forest (US 9,280,653 B2) further in view of Risbood (US 9,063,818 B1) and Rennie (US 8,583,333 B2) further in view of further in view of Kotani (US 20150113520) and Pirakash (US 20110131447). Regarding Claim 20, Caushi, Forest, Risbood and Rennie teach The system of claim 19. Caushi, Forest, Risbood and Rennie did not teach wherein: the instructions are further configured to instruct the at least one controller to determine a cryptographic measurement of the first update and determine, based on the cryptographic measurement, whether to accept or reject the first update the cryptographic measurement is determined by a cryptographic engine; and the instructions are further configured to instruct the controller to, prior to determining the cryptographic measurement, receive a data value from a boot device, and store the data value in memory. However, Kotani (US 20150113520) teaches wherein: the instructions are further configured to instruct the at least one controller to determine a cryptographic measurement of the first update (Paragraph 0101, When receiving from the update server 22 the transmission target data and digital signature that have been encrypted, the server authentication unit 202 decrypts the received information by using the private key of the in-vehicle equipment 23. Next, the server authentication unit 202 decrypts the digital signature by using the public key of the server 22 and acquires the hash value) Examiner Comments: The authentication process and acquiring the hash value can be interpreted to the claimed cryptographic measurement, and determine, based on the cryptographic measurement, whether to accept or reject the first update (Paragraph 0101, the server authentication unit 202 calculates the hash value of the transmission target data by using the hash function that is stored in the authentication information storage unit 201. Then, the server authentication unit 202 compares the calculated hash value with the hash value acquired by decrypting the digital signature, and decides that the update server 22 is authentic and that the transmission target data received from the update server 22 is not falsified, when the comparison results are matched); the cryptographic measurement is determined by a cryptographic engine; and the instructions are further configured to instruct the controller to, prior to determining the cryptographic measurement, receive a data value from a boot device, and store the data value in memory (Paragraph 0101, When receiving from the update server 22 the transmission target data and digital signature that have been encrypted, the server authentication unit 202 decrypts the received information by using the private key of the in-vehicle equipment 23. Next, the server authentication unit 202 decrypts the digital signature by using the public key of the server 22 and acquires the hash value; Paragraph 0148, The program according to the present embodiment may be provided to the update server 22 in the following forms. (1) Installed in the storage 403 beforehand. (2) Provided by the removable storage medium 450]). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Kotani’s in order to confirm update program to control unit mounted on motor vehicle, by determining whether application process of update program with respect to control unit is successful or failed (Kotani [Summary]). Caushi, Forest, Risbood, Rennie and Kotani did not teach a boot device. However, Pirakash (US 20110131447) teaches a boot device (Paragraph 0059, As the console devices are established and access to boot devices is established, additional firmware volumes may be discovered). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood, Rennie and Kotani’s teaching to Pirakash in order for the updates can be enabled to be performed for specific BIOS/platform firmware code module or an application by receiving an updated boot firmware code module in secure partition of system, the updated boot firmware code is provided to replace one original boot firmware code module of several boot firmware code modules for the system (Pirakash [Summary]). Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US20180024826A1) in view of Forest (US 9,280,653 B2), and Risbood (US 9063818 B1) and Rennie (US 8,583,333 B2) further in view of Sinha (US8452465). Regarding Claim 21, Caushi, Forest, Risbood and Rennie teach The system of claim 19. Caushi, Forest, Risbood and Rennie did not teach wherein the instructions are further configured to instruct the at least one controller to detect a malfunction, wherein the first update is requested in response to detecting the malfunction. However, Sinha (US8452465) teaches wherein the instructions are further configured to instruct the at least one controller to detect a malfunction, wherein the first update is requested in response to detecting the malfunction (4:29-36, The on-board unit 112 is configured to detect ECU 104 failure and individual task failure, generate and execute a robust on-board reconfiguration strategy, bring the vehicle 100 to a safe state, send health data to the remote unit 114, and execute an optimized reconfiguration strategy that is generated by and received from the remote unit 114; 3:42-47, the reconfiguration system 110 is configured to handle failures in sensors, actuators, wiring harnesses, communication busses, software bugs, combinations thereof, and the like). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Sinha’s in order to reconfigure task initially assigned to electronic control unit (ecu) of e.g. car, by receiving reconfiguration strategy generated as function of health data, fault model, and system model from remote unit (Sinha [Summary]). Claim(s) 22 is/are rejected under 35 U.S.C. 103 as being unpatentable over Caushi (US20180024826A1) in view of Forest (US 9,280,653 B2), Risbood (US 9063818 B1) and Rennie (US 8,583,333 B2) further in view of Schmidt (US20110010543). Regarding Claim 22, Caushi, Forest, Risbood and Rennie teach The system of claim 19. Caushi, Forest, Risbood and Rennie did not teach wherein the instructions are further configured to instruct the at least one controller to, in response to determining to reject a second update, update at least a portion of software stored in system memory. However, Schmidt (US20110010543) teaches wherein the instructions are further configured to instruct the at least one controller to, in response to determining to reject a second update, update at least a portion of software stored in system memory (Paragraph 0203, This function ensures that a compromised device may at least be sent into a rescue mode in the case of a failed software or component update. A fallback code base (FBC) may be used for device reversion by the DMS in case of failure. This allows the device to revert to a pristine state from which the main code may be updated via DMS management methods). It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have combined Caushi, Forest, Risbood and Rennie’s teaching to Schmidt’s in order to provide platform validation and management performing for e.g. wireless transmit/receive unit, by sending failure report to management system to initiate remediation and revalidation, and sending modified token with validation result (Schmidt [Summary]). Response to Arguments Applicant’s arguments with respect to claims 1-2, 5-14, and 16-23 have been considered but are moot because the arguments do not apply to the previous cited sections of the references used in the previous office action. The current office action is now citing additional references to address the newly added claimed limitations. Conclusion THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMIR SOLTANZADEH whose telephone number is (571)272-3451. The examiner can normally be reached M-F, 9am - 5pm ET. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Wei Mui can be reached at (571) 272-3708. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /AMIR SOLTANZADEH/Examiner, Art Unit 2191 /WEI Y MUI/Supervisory Patent Examiner, Art Unit 2191
Read full office action

Prosecution Timeline

Sep 29, 2021
Application Filed
Oct 31, 2022
Non-Final Rejection — §103, §DP
Feb 07, 2023
Response Filed
Mar 08, 2023
Final Rejection — §103, §DP
Jun 15, 2023
Request for Continued Examination
Jun 23, 2023
Response after Non-Final Action
Jun 27, 2023
Non-Final Rejection — §103, §DP
Sep 27, 2023
Response Filed
Oct 02, 2023
Interview Requested
Oct 10, 2023
Applicant Interview (Telephonic)
Oct 10, 2023
Examiner Interview Summary
Nov 16, 2023
Final Rejection — §103, §DP
Jan 24, 2024
Response after Non-Final Action
Jan 24, 2024
Interview Requested
Feb 08, 2024
Examiner Interview Summary
Feb 08, 2024
Applicant Interview (Telephonic)
Feb 26, 2024
Request for Continued Examination
Feb 29, 2024
Response after Non-Final Action
Mar 11, 2024
Applicant Interview (Telephonic)
Mar 12, 2024
Examiner Interview Summary
Mar 22, 2024
Non-Final Rejection — §103, §DP
Jun 28, 2024
Response Filed
Sep 30, 2024
Non-Final Rejection — §103, §DP
Dec 30, 2024
Response Filed
Feb 03, 2025
Final Rejection — §103, §DP
Apr 14, 2025
Response after Non-Final Action
May 13, 2025
Request for Continued Examination
May 20, 2025
Response after Non-Final Action
May 20, 2025
Response after Non-Final Action
Dec 12, 2025
Non-Final Rejection — §103, §DP
Feb 16, 2026
Response Filed
Mar 16, 2026
Final Rejection — §103, §DP (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12602225
IDENTIFYING THE TRANLATABILITY OF HARD-CODED STRINGS IN SOURCE CODE VIA POS TAGGING
2y 5m to grant Granted Apr 14, 2026
Patent 12591414
CENTRALIZED INTAKE AND CAPACITY ASSESSMENT PLATFORM FOR PROJECT PROCESSES, SUCH AS WITH PRODUCT DEVELOPMENT IN TELECOMMUNICATIONS
2y 5m to grant Granted Mar 31, 2026
Patent 12561134
Function Code Extraction
2y 5m to grant Granted Feb 24, 2026
Patent 12561136
METHOD, APPARATUS, AND SYSTEM FOR OUTPUTTING SOFTWARE DEVELOPMENT INSIGHT COMPONENTS IN A MULTI-RESOURCE SOFTWARE DEVELOPMENT ENVIRONMENT
2y 5m to grant Granted Feb 24, 2026
Patent 12561118
SYSTEM AND METHOD FOR AUTOMATED TECHNOLOGY MIGRATION
2y 5m to grant Granted Feb 24, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

10-11
Expected OA Rounds
81%
Grant Probability
98%
With Interview (+16.9%)
2y 6m
Median Time to Grant
High
PTA Risk
Based on 421 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month