Prosecution Insights
Last updated: October 02, 2026
Application No. 18/609,975

METHODS AND SYSTEMS FOR CLIENT-LESS VEHICLE SOFTWARE UPDATES

Final Rejection §103
Filed
Mar 19, 2024
Examiner
NIGATU, BEZA DIRESSA
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
Red Bend Ltd.
OA Round
2 (Final)
Grant Probability
Favorable
3-4
OA Rounds

Examiner Intelligence

Grants only 0% of cases
0%
Career Allowance Rate
0 granted / 0 resolved
-55.0% vs TC avg
Minimal +0% lift
Without
With
+0.0%
Interview Lift
resolved cases with interview
Typical timeline
Avg Prosecution
13 currently pending
Career history
14
Total Applications
across all art units
This examiner has no resolved cases yet (career too new); statute-level performance unavailable. The Grant Probability card shows Tech Center averages instead.

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is filed in response to the Applicant’s Arguments and Remarks amendment dated 08/04/2026. Claims 1-3, 6, 8-9, 13, 16, and 18-19 are currently amended. Claims 1-20 are pending. In view of Applicant’s Amendments and Remarks, the objections are withdrawn from Claim 6 and the disclosure. Applicant’s arguments with respect to the prior art rejections have been considered by the examiner but are moot in view of the present claim language, as detailed below in the “Response to Arguments” section. Examiner’s Notes Examiner cites columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. Claim Objections Claims 16-20 are objected to because of the following informalities: Claim 16, line 9, the first occurrence of acronym (“OEM”) should be spelled out, i.e., --an original equipment manufacturer (OEM)--. Claims 17-20 depend on the objected claim and inherit the same issue. Appropriate correction is required. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1-15 are rejected under 35 U.S.C. 103 as being unpatentable over Nordbruch (U.S. Publication No. 2018/0029489 A1, hereinafter Nordbruch) in view of Babayan et al. (U.S. Publication No. 2024/0394036 A1, hereinafter Babayan), Veselov et al. (U.S. Publication No. U.S. Patent No. 10706155 B1), and David et al. (U.S. Publication No. 2020/0174778 A1, hereinafter David). Regarding Claim 1: Nordbruch discloses, A method for an over-the-air (OTA) integrated charging station, comprising (In paragraph [0087], “FIG. 1 shows a flow chart of a method for operating a charging station”. In paragraph [0077], “a wireless communication link is thus enabled between the e-vehicle and the charging station”.); establishing communication between a computing system of the OTA integrated charging station and a vehicle computing system of an electric vehicle (Paragraphs [0099]- [0100] describe how communication is established between the charging station and electric vehicle, “Charging station 201 furthermore includes: a communication interface 203 for establishing a communication link between the charging station and an electric vehicle”. In paragraph [0101], the reference specifies a computing system of the electric vehicle as, “a processing unit of the electric vehicle”. In paragraph [0103], the computing system of the charging station is specified as a processor, “charging station 201 includes a processor”, where paragraph [0082] teaches the mapping of the charging station processor to a higher-level computing system of the communication interface, “a processor of the charging station is designed to carry out the technical method steps … in such a way that it appropriately controls the communication interface”.); determining one or more vehicle specifics of the electric vehicle from the vehicle computing system (In paragraph [0101], “is possible to check, via the communication link, whether a software stored on a processing unit of the electric vehicle has to be updated”.); establishing communication between the computing system and an original equipment manufacturer (OEM) system (Paragraph [0045] specifies that a server may be used by the original equipment manufacturer (OEM) to establish communication, “for example online, i.e., via the communication links”, where “the server is a server of an OEM”. Further, paragraph [0043] describes how communication is established with the charging station by, “a further communication link is established between the charging station and a server via a communication network”. The data communicated from the OEM may then be communicated to the vehicle indirectly, by forwarding the data via the charging station, “the charging station receiving the update data from the server via the further communication link in order to transmit the update data via the communication link to the e- vehicle”. Note that communication is established with the OEM to include both the charging station computing system and vehicle computing system, indirectly or directly.); [] a software update from the OEM system based on the one or more vehicle specifics; and installing the software update to the vehicle computing system via a software installer thereof (In paragraph [0045], “In particular, the server is a server of an OEM inspection provider. Such a provider carries out an inspection of the e- vehicle, i.e., in particular of vehicle systems of the e-vehicle”. Paragraph [0048] further specifies, “The server may thus access the e-vehicle remotely … via the communication link … for example, to install update data”. Moreover, paragraph [0117] recites how the installing of the software update is carried, “the installation of possibly necessary software updates are, in particular, provided via a WLAN communication link”.). determining whether installation of the software update at the vehicle computing system is verified (In paragraphs [0051]-[0052], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station: transmitting a message to a keeper and/or to a driver of the electric vehicle to inform them”.); and responsive to the installation being verified [] to the OEM system (In paragraph [0045], “the server is a server of an OEM”. In paragraph [0048], “The server may thus access the e-vehicle remotely … to carry out a defect analysis of the processing unit and/or, for example, to install update data”. In paragraph [0050], “the check includes … whether an update of the software suffices to eliminate the malfunction”.). Nordbruch does not disclose however Babayan discloses, the one or more vehicle specifics comprising a make, a model, and a year of the electric vehicle (In paragraph [0056], “the remote computing platform 110 may be associated with an OEM that is responsible for the make and model of the vehicle 105”. In paragraph [0112], “updating certain software versions on a group of vehicles (e.g., certain vehicle models of year X)”. In paragraph [0064], “the vehicle 105 may be a fully electric vehicle (EV)”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Nordbruch as modified does not disclose however Veselov explicitly discloses, retrieving [a software update from the OEM system]. (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the system disclosed by Nordbruch in view of Babayan. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either system of obtaining data for an update, in order to process data according to the best available configurations. Nordbruch as modified does not disclose however David discloses, responsive to the installation not being verified, re-attempting installation of the software update to the vehicle computing system up to a preset number of retries (In paragraph [0063], “an indication 432 that the update was unsuccessful … the automatic retry may be performed for a predetermined number of attempts before requiring confirmation for further retries from the user”.); send a report of the software update (In paragraph [0061], “If the result indicates that the software update was successful, then the result of decision block 341 is YES, and the method 300 proceeds to block 342, where the update processing module 206 presents a success notification. In addition, the server computing system 104 may update the appropriate vehicle record in the vehicle data store 212 to indicate that the software update was successfully installed”.); the report comprising the one or more vehicle specifics and a software update identifier (In paragraph [0043], “the identifier is some other unique identifier, such as a license plate number, or a unique identifier other than the VIN that is generated for the vehicle 106 to associate the vehicle 106 with a record in the vehicle data store 104”. In paragraph [0068], “To register the vehicle 106, the user processing module 208 creates a record within the vehicle data store 212 that associates the vehicle 106 with the user. The record may also store other information about the vehicle 106, such as the status of software updates as described above”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Nordbruch by adapting the teaching in David, to address “drawbacks of using a specialized device to update the vehicle software” (David [0004]) such as the drawback of “the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device … where such updates can be installed may not always be closely available to the vehicle” (David [0003]), by providing an easier delivery of software updates for vehicles with the use of over-the-air (OTA) updates. Regarding Claim 2: Nordbruch discloses, The method of claim 1, further comprising determining availability of the software update within the OEM system based on the one or more vehicle specifics (In paragraph [0116] where there is, “a regular inspection analysis, including a possibly necessary import of software updates (software actualizations) in electric vehicles”. Furthermore, the inspection is specified in paragraph [0119], “this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”. The determination of software update availability is explained in paragraphs [0120]-[0122], “the charging station is connected to all and/or different and/or multiple OEMs. In this way, it is in particular ensured that the latest inspection analyses and software updates, i.e., software actualizations, are always available. If defects and/or necessary software updates are detected during an analysis, it is preferably provided that the update data are transmitted to the e-vehicle”.). Nordbruch does not disclose however Babayan discloses, wherein the OEM system stores a plurality of operating system software configurations for a plurality of vehicles (In paragraph [0076], “The hardware layer 205 may be configured to include a connectivity module 225 … The connectivity module 225 may allow the vehicle computing system 200 to communicate with … remote computing platform 110 (e.g., an OEM cloud platform)”. In paragraph [0056], “the OEM to operate a cloud-based server system that provides computing services to the vehicle 105”. Where the OEM system contain servers to store in paragraph [0106], “The servers may include physical or virtual machines that … store data … in the cloud”. In paragraph [0072], “The hardware and software layers 205, 210 may include sub-layers … the software layer 210 can be standardized base layers of the vehicle's operating system”. Where there may be multiple vehicles in paragraph [0103], “distribution of software updates 460 (e.g., OTA updates) to vehicles, the computing platform 110 (e.g., the vehicle software system 455) may include a remote update controller system”. In paragraph [0101], “a vehicle software system 455 that is configured to provide the vehicle 105 with one or more software updates”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Regarding Claim 3: Nordbruch discloses, The method of claim 1, further comprising sending a notification of availability of the software update to the electric vehicle (Paragraph [0130] identifies the notification of a software update in the form of a request to the driver for permission to carry out the software update, where “If the software updates suffice … at least the keeper/driver is informed”.); the determining whether installation is verified (In paragraphs [0051]-[0052], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station: transmitting a message to a keeper and/or to a driver of the electric vehicle to inform them”.). Nordbruch as modified does not disclose however David discloses, is based at least in part on a notification from the vehicle computing system (In paragraph [0037], “(OTA) updater device 108 of a vehicle 106”. In paragraph [0039], “the OTA updater device 108 optionally transmits a notification … the notification informs the server computing system 104 that the software update has been completely downloaded to allow a list of registered vehicles that includes indications of vehicles that have received a software update to be generated”.); Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Nordbruch by adapting the teaching in David, to address “drawbacks of using a specialized device to update the vehicle software” (David [0004]) such as the drawback of “the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device … where such updates can be installed may not always be closely available to the vehicle” (David [0003]), by providing an easier delivery of software updates for vehicles with the use of over-the-air (OTA) updates. Regarding Claim 4: Nordbruch discloses, The method of claim 3, wherein installing the software update is performed in response to receiving an installation request from the vehicle (Paragraph [0064] teaches that, “… a driver of the e-vehicle with the aid of the charging station to inform them/him, her of this and/or to request from them/him, her a confirmation for carrying out the update …”. In other words, a software update is performed as a result of an affirmative request to update the vehicle.). Regarding Claim 5: Nordbruch discloses, The method of claim 1, wherein establishing communication between the vehicle computing system and the computing system of the OTA integrated charging station comprises one of connecting a charging cable of the OTA integrated charging station to the electric vehicle, the charging cable embedded with a data channel and connecting a dedicated data cable of the charging station to the electric vehicle (Paragraph [0079] specifies, “a wired communication link between the charging station and the electric vehicle”, with said wired communication link including a patch cable that integrates “a cable conduit including a charging cable”. The electric vehicle includes a communication interface, “designed for a wireless and/or wired communication link, for the wired communication link the communication interface including a patch cable for forming the wired communication link between the charging station and the electric vehicle”. Additionally, paragraph [0078] further specifies, “the charging station is able to receive the update data from the server via the further communication link”, thus allowing the charging cable from the wired communication link to transmit data to the electric vehicle.). Regarding Claim 6: Nordbruch discloses, The method of claim 1, wherein establishing communication between the vehicle computing system and the computing system of the OTA integrated charging station is in response to the electric vehicle having attempted to [] the software update from the OEM system via OTA programming (Paragraph [0130] teaches that a driver of the electric vehicle is informed of the software update, “If the software updates suffice … at least the keeper/driver is informed”, where permission is obtained in advance, “in particular prior to a transmission of the update data”. Therefore, if permission is denied, then transmission of the update is denied. The driver is informed of the software update through the communication interface linking the electric vehicle and the charging station, as outlined in paragraphs [0105]-[0109], “Electric vehicle 301 includes: a processing unit 303 on which software 305 is stored; a communication interface 307 for establishing a communication link between the electric vehicle and a charging station, so that it is possible to check ,via the communication link, whether the software 305 stored on the processing unit of the electric vehicle has to be updated, the communication interface 307 being designed to receive, as a function of the check, update data for updating the software 305 via the communication link from the charging station so that the software may be updated based on the update data.”. Paragraph [0117]-[0119] specifies that the charging station assumes functionality of the OEM to carry out the check and transmission of update data, if it is necessary, “the check and the transmission of the update data, if necessary, take place during charging … the charging station assumes the functionality of an OEM inspection provider … this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”, where the OTA programming to carry out a check on whether to update the software is from, “The analysis and the installation of possibly necessary software updates are, in particular, provided via a WLAN communication link”. Further, in light of the examined case specifications in the Detailed Description at paragraph [0058], “the user rejecting the software update” is cited as a factor in why the vehicle may be unable to install the software request. In paragraph [0081] of the examined case, “being unable [to] retrieve the software update from the OEM system via OTA programming”, includes the example that is “in response to receiving an installation request from the vehicle” when establishing communication between the computing systems of the OTA integrated charging station and vehicle. Therefore, it is further supported that Nordbruch teaches claim 6, as it also describes a request that takes place prior to installation of the software update. Moreover, Figure 7 of the examined case establishes communication between the OTA integrated charging system and vehicle computing system at step 702; and in response to retrieving a software update at step 712, communication occurs between the charging station and vehicle in the following step 14, where the OEM (connected to the charging station) may communicate a request to the vehicle on whether the software update should be installed through an interface; given as an example in paragraph [0064], [0083] where an installation request is displayed on a vehicle, “a message is transmitted to a keeper and/or to a driver of the e-vehicle with the aid of the charging station to inform them/him, her of this and/or to request from them/him, her a confirmation for carrying out the update”, where “the communication interface of the charging station is accordingly designed to receive a confirmation”. Thus, indicating that communication has occurred between the charging station and the vehicle in response to the request. The answer to the request is transmitted from the vehicle, back to the OEM via the charging station. In the case that the request is denied, then that answer is submitted where the OEM will not continue to transmit the software update to the vehicle. Nordbruch also discloses a request from the vehicle where the denial of transmission is communicated to the OEM so the software update will not continue as a response, as discussed above.). and having been unable to [] the OTA software update due to unavailability of a reliable or cellular data connection (In paragraph [0028], “Even if the charging station is situated in an underground parking garage, a software update may still be carried out, even though conventional mobile communication networks may not be present in an underground parking garage”. In paragraph [0005], “Software updates are increasingly imported via a mobile communication link to the vehicle … coverage of the mobile communication network has dead zones or, for example, when the vehicle enters an underground parking garage. An update of a software on the vehicle may thus fail”.). Nordbruch as modified does not disclose but Veselov explicitly discloses, retrieve [a software update from the OEM system]. (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the method disclosed by Nordbruch. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either method of obtaining data for an update, in order to process data according to the best available configurations. Regarding Claim 7: Nordbruch discloses, The method of claim 1, wherein establishing communication between the vehicle computing system and the computing system of the OTA integrated charging station comprises establishing an OTA connection therebetween (Paragraph [0077] teaches that the OTA connection is established wirelessly told as, “a wireless communication link is thus enabled between the e-vehicle and the charging station”. A communication interface aids in establishing the wireless communication link involving the computing systems of the vehicle and OTA integrated charging station, as supported in paragraphs [0018], “a processing unit on which software is stored”; [0077], “a wireless communication link is thus enabled between the e-vehicle and the charging station.”: and [0079], “that the communication interface is designed for a wireless and/or wired communication link”. As mentioned previously in claim 1, paragraph [0101] of the reference specifies a computing system of the electric vehicle as, “a processing unit of the electric vehicle”. In paragraph [0103], the computing system of the charging station is specified as a processor, “charging station 201 includes a processor”; where paragraph [0082] teaches the mapping of the charging station processor to a higher- level computing system of the communication interface, “a processor of the charging station is designed to carry out the technical method steps … in such a way that it appropriately controls the communication interface”, where the communication interface is designed for wireless communication, as stated above.). Regarding Claim 8: Nordbruch discloses, The method of claim 1, wherein establishing communication between the computing system of the OTA integrated charging station and the OEM system comprises establishing an OTA connection therebetween (Paragraphs [0043] teaches that, “a further communication link is established between the charging station and a server via a communication network”, where paragraph [0070] specifies, “the communication link includes a wireless communication link”. Additionally, paragraph [0045] includes that, “the server is a server of an OEM … In particular, the server is a server of an OEM inspection provider”. Therefore, the reference teaches that a charging station may be connected over the air, via wirelessly, to communicate with the OEM.). the method further comprising receiving, from the vehicle computing system, a message indicating that the electric vehicle [] with the OEM system and has been unable to install the OTA software update (In paragraph [0051]-[0052], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station: transmitting a message to a keeper and/or to a driver of the electric vehicle to inform them”. In paragraph [0083], “the processor is designed to ascertain or generate the above-mentioned messages, the communication interface then, in particular, being designed to transmit these messages, or one of the messages, via the communication network”. In paragraph [0048], “The server may thus access the e-vehicle remotely … to carry out a defect analysis”. In paragraph [0045], “the server is a server of an OEM”. Note that the term “malfunction” in paragraph [0051] is used similarly to the term “defects”, as shown in paragraph [0123], “which the software updates are not sufficient to eliminate the discovered defects”.). Nordbruch as modified does not disclose however David discloses, has attempted an OTA software update (In paragraph [0062], “the failure notification may include a status message that indicates what portion of the software update failed and why … the failure notification may indicate to the operator that a retry of the software update will be automatically attempted one or more times”. In paragraph [0032], “the vehicle 106 includes an over-the-air (OTA) updater device”, where paragraph [0033] specifies, “the OTA updater device 108 obtains software updates”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Nordbruch by adapting the teaching in David, to address “drawbacks of using a specialized device to update the vehicle software” (David [0004]) such as the drawback of “the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device … where such updates can be installed may not always be closely available to the vehicle” (David [0003]), by providing an easier delivery of software updates for vehicles with the use of over-the-air (OTA) updates. Regarding Claim 9: Nordbruch discloses, A vehicle software update system, comprising: an electric vehicle comprising a vehicle computing system controlled by software (Paragraph [0105]-[0109] describes a system where the electric vehicle updates software stored on the vehicle processing unit as follows, “Electric vehicle 301 includes: a processing unit 303 on which software 305 is stored; a communication interface 307 for establishing a communication link between the electric vehicle and a charging station, so that it is possible to check, via the communication link, whether the software 305 stored on the processing unit of the electric vehicle has to be updated, the communication interface 307 being designed to receive, as a function of the check, update data for updating the software 305 via the communication link from the charging station so that the software may be updated based on the update data”.); an over-the-air (OTA) integrated charging station configured to communicate with the vehicle computing system (Paragraph [0107] teaches communication occurs between the charging station and electric vehicle, “a communication interface 307 for establishing a communication link between the electric vehicle and a charging station”. Paragraph [0070] further specifies that the communication may occur over-the-air via wirelessly, “… it is provided that the communication link includes a wireless communication link”.); and an original equipment manufacturer (OEM) system configured to communicate with the OTA integrated charging station (Paragraph [0045] specifies that a server may be used by the original equipment manufacturer (OEM) to establish communication, “for example online, i.e., via the communication links”, where “the server is a server of an OEM”. Further, paragraph [0043] describes how communication is established with the charging station by, “a further communication link is established between the charging station and a server via a communication network”.); wherein the OTA integrated charging station is configured to [] a software update for the vehicle from the OEM system (In paragraph [0045], “In particular, the server is a server of an OEM inspection provider. Such a provider carries out an inspection of the e-vehicle, i.e., in particular of vehicle systems of the e-vehicle”. Moreover, paragraph [0117] recites how the installing of the software update is carried, “the installation of possibly necessary software updates are, in particular, provided via a WLAN communication link”.); and install the software update to the vehicle computing system (Paragraph [0048] specifies, “The server may thus access the e-vehicle remotely … via the communication link … for example, to install update data”.); determine whether installation of the software update at the vehicle computing system is verified (In paragraphs [0051]-[0052], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station: transmitting a message to a keeper and/or to a driver of the electric vehicle to inform them”.); and responsive to the installation being verified [] to the OEM system (In paragraph [0045], “the server is a server of an OEM”. In paragraph [0048], “The server may thus access the e-vehicle remotely … to carry out a defect analysis of the processing unit and/or, for example, to install update data”. In paragraph [0050], “the check includes … whether an update of the software suffices to eliminate the malfunction”.). Nordbruch does not disclose however Babayan discloses, based on one or more vehicle specifics of the electric vehicle, the one or more vehicle specifics comprising a make, a model, and a year of the electric vehicle (In paragraph [0056], “the remote computing platform 110 may be associated with an OEM that is responsible for the make and model of the vehicle 105”. In paragraph [0112], “updating certain software versions on a group of vehicles (e.g., certain vehicle models of year X)”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Nordbruch as modified does not disclose however Veselov discloses, retrieve (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the system disclosed by Nordbruch in view of Babayan. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either system of obtaining data for an update, in order to process data according to the best available configurations. Nordbruch as modified does not disclose however David discloses, based at least in part on a notification from the vehicle computing system (In paragraph [0037], “(OTA) updater device 108 of a vehicle 106”. In paragraph [0039], “the OTA updater device 108 optionally transmits a notification … the notification informs the server computing system 104 that the software update has been completely downloaded to allow a list of registered vehicles that includes indications of vehicles that have received a software update to be generated”.); responsive to the installation not being verified re-attempt installation of the software update to the vehicle computing system up to a preset number of retries (In paragraph [0063], “an indication 432 that the update was unsuccessful … the automatic retry may be performed for a predetermined number of attempts before requiring confirmation for further retries from the user”.); send a report of the software update (In paragraph [0061], “If the result indicates that the software update was successful, then the result of decision block 341 is YES, and the method 300 proceeds to block 342, where the update processing module 206 presents a success notification. In addition, the server computing system 104 may update the appropriate vehicle record in the vehicle data store 212 to indicate that the software update was successfully installed”.); the report comprising the one or more vehicle specifics and a software update identifier (In paragraph [0043], “the identifier is some other unique identifier, such as a license plate number, or a unique identifier other than the VIN that is generated for the vehicle 106 to associate the vehicle 106 with a record in the vehicle data store 104”. In paragraph [0068], “To register the vehicle 106, the user processing module 208 creates a record within the vehicle data store 212 that associates the vehicle 106 with the user. The record may also store other information about the vehicle 106, such as the status of software updates as described above”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Nordbruch by adapting the teaching in David, to address “drawbacks of using a specialized device to update the vehicle software” (David [0004]) such as the drawback of “the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device … where such updates can be installed may not always be closely available to the vehicle” (David [0003]), by providing an easier delivery of software updates for vehicles with the use of over-the-air (OTA) updates. Regarding Claim 10: Nordbruch discloses, The vehicle software update system of claim 9, wherein the OTA integrated charging station is configured to [] the software update from the OEM system via OTA programming (Paragraph [0117]-[0119] specifies that the charging station assumes functionality of the OEM to carry out the check and transmission of update data, if it is necessary, “the check and the transmission of the update data, if necessary, take place during charging … the charging station assumes the functionality of an OEM inspection provider … this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”, where the OTA programming to carry out a check on whether to update the software is from, “The analysis and the installation of possibly necessary software updates are, in particular, provided via a WLAN communication link”. Paragraph [0105]-[0109] teaches that the software update is able to be obtained through the communication interface linking the electric vehicle and the charging station, “a communication interface 307 for establishing a communication link between the electric vehicle and a charging station, so that it is possible to check, via the communication link, whether the software 305 stored on the processing unit of the electric vehicle has to be updated … so that the software may be updated based on the update data”. Functions of the charging station may be carried out with programming as stated in paragraph [0025], “a computer program is provided, which includes program code for carrying out the method for operating a charging station and/or the method for operating an electric vehicle if the computer program is executed on a computer”. In paragraph [0077]-[0078], the charging station may further be integrated to connect wirelessly through a server connected to a communication network to receive the update, “the charging station is able to receive the update data from the server via the further communication link … the communication interface is designed for a wireless and/or wired communication link”.). Nordbruch as modified does not but Veselov explicitly discloses, retrieve [the software update from the OEM system]. (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the system disclosed by Nordbruch. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either system of obtaining data for an update, in order to process data according to the best available configurations. Regarding Claim 11: Nordbruch discloses, The vehicle software update system of claim 9, wherein the OTA integrated charging station is configured to communicate with the vehicle computing system via one or more of OTA programming, a data channel embedded in a charging cable coupled to the vehicle, and a dedicated data cable coupled to the vehicle (Paragraph [0079] specifies, “a wired communication link between the charging station and the electric vehicle”, with said wired communication link including a patch cable that integrates “a cable conduit including a charging cable”. The electric vehicle includes a communication interface, “designed for a wireless and/or wired communication link, for the wired communication link the communication interface including a patch cable for forming the wired communication link between the charging station and the electric vehicle”. Additionally, paragraph [0078] states, “… the communication interface is designed to establish a further communication link … the charging station is able to receive the update data from the server via the further communication link”; paragraph [0079] further specifies, “it is provided that the communication interface is designed for a wireless and/or wired communication link”. Thus, allowing data to be transmitted wirelessly from the communication link, or through the charging cable from the wired communication link to transmit data to the electric vehicle.). Regarding Claim 12: Nordbruch discloses, The vehicle software update system of claim 9, wherein the OTA integrated charging station comprises a computing system including a vehicle communication subsystem and an OEM communication subsystem (Paragraphs [0082]; [0012]-[0013], teach how the charging station comprises a vehicle communication subsystem as a part of the charging station’s communication interface which may be processed with the charging station’s processor, “a processor of the charging station is designed to carry out the technical method steps according to the method in such a way that it appropriately controls the communication interface”; “the charging station furthermore including: a communication interface for establishing a communication link between the charging station and an electric vehicle”. In paragraph [0043]; [0045], the charging station comprises an OEM communication subsystem by establishing access to a server, “a further communication link is established between the charging station and a server via a communication network”, in which “the server is a server of an OEM”.). Regarding Claim 13: Nordbruch discloses, The vehicle software update system of claim 12, wherein the vehicle communication subsystem [], cause the computing system to determine the one or more vehicle specifics of the electric vehicle and install the software update on the vehicle computing system (Paragraphs [0099]-[0103] specifies that once the charging station establishes communication with the vehicle communication subsystem through the communication interface, “Charging station 201 furthermore includes: a communication interface 203 for establishing a communication link between the charging station and an electric vehicle”; the computing system of the charging station (being a processor), may carry out a check on the vehicle specifics, “it is possible to check, via the communication link, whether a software stored on a processing unit of the electric vehicle has to be updated … the communication interface being designed to transmit, as a function of the check, update data for updating the software”. One of the vehicle specifics determined when carrying out the check is the current operating software, “whether a software stored on a processing unit of the electric vehicle has to be updated”, as stated in paragraph [0101]. The software update specific to the vehicle may be installed from data transmitted by the communication interface, once permission is given by the driver to install the software update, “when the update of the software suffices, a message is transmitted to a keeper and/or to a driver of the e-vehicle with the aid of the charging station to inform them/him … and/or to request … a confirmation for carrying out the update … it is then provided that the software is updated … only in response to a confirmation on the part of the keeper and/or on the part of the driver” (paragraph [0064]).). Nordbruch does not disclose however Babayan explicitly discloses, comprises instructions stored in memory that, when executed by a processor of the computing system (Babayan specifies hardware components of the claim that Nordbruch does not explicitly state. In paragraph [0171], “The non- transitory computer-readable medium 6020 may also store computer-readable instructions 6030 that may be executed by the control circuit 6015”. Paragraph [0168] specifies the mapping of elements, “the control circuit 6015 may include one or more processors”, and, “a non-transitory computer-readable medium 6020, also referred to herein as memory”. Thus, Babayan discloses instructions stored on memory that may be executed by the processor. Further, the invention disclosed by Babayan is aimed to solve a similar goal as stated in the Abstract, “The computing system generates a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Regarding Claim 14: Nordbruch discloses, The vehicle software update system of claim 13, wherein the OEM communication subsystem [comprises instructions stored in memory that, when executed by the processor], cause the computing system to [retrieve] the software update for the electric vehicle from the OEM system based on the one or more vehicle specifics. (In paragraph [0043]; [0045], the charging station comprises an OEM communication subsystem by establishing access to a server, “a further communication link is established between the charging station and a server via a communication network”, in which “the server is a server of an OEM”. Paragraph [0043] additionally specifies that the OEM subsystem obtains the software update for the vehicle via update data, “… the charging station receiving the update data from the server via the further communication link in order to transmit the update data via the communication link to the e-vehicle”. One of the vehicle specifics determined when carrying out the check is checking the current operating software on the vehicle, as stated in paragraph, “whether a software stored on a processing unit of the electric vehicle has to be updated”, where paragraph [0085] further specifies, “the software is updated based on the update data”, and in paragraph [0114], “receiving 405 with the aid of the electric vehicle, as a function of the check 403, update data for updating the software”.). Nordbruch does not disclose however Babayan explicitly discloses, comprises instructions stored in memory that, when executed by the processor (Babayan specifies hardware components of the claim that Nordbruch does not explicitly state. In paragraph [0171], “The non-transitory computer- readable medium 6020 may also store computer-readable instructions 6030 that may be executed by the control circuit 6015”. Paragraph [0168] specifies the mapping of elements, “the control circuit 6015 may include one or more processors”, and, “a non-transitory computer-readable medium 6020, also referred to herein as memory”. Thus, Babayan discloses instructions stored on memory that may be executed by the processor. Further, the invention disclosed by Babayan is aimed to solve a similar goal as stated in the Abstract, “The computing system generates a task package including the OTA software update and indicating the action to be taken for implementing the OTA software update”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Nordbruch as modified does not disclose however Veselov explicitly discloses, retrieve [the software update for the electric vehicle from the OEM system]. (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the system disclosed by Nordbruch in view of Babayan. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either system of obtaining data for an update, in order to process data according to the best available configurations. Regarding Claim 15: Nordbruch discloses, The vehicle software update system of claim 9, wherein the vehicle computing system comprises a software installer configured to receive the software update from the OTA integrated charging station (Paragraph [0119] cites that the charging station connects to the OEM inspection provider to identify the particular software update needed to be transmitted via a check, “the charging station carries out both the check and the transmission of update data … so that it is then able to forward the received update data to the e-vehicle”. Paragraph [0010]-[0011] specifies that the check determines whether an electric vehicle needs to have a software update based on whether the current software stored on the vehicle processing unit should be updated, “checking … whether a software stored on a processing unit of the electric vehicle has to be updated; and transmitting … update data for updating the software via the communication link to the electric vehicle with the aid of the charging station so that the software may be updated based on the update data”. The check is then transmitted as update data to instruct the installation and updating of the software on the electric vehicle with the aid of the charging station. Installation of the software update to the vehicle is further supported in paragraph [0122], “it is preferably provided that the update data are transmitted to the e-vehicle. This means that the software updates are preferably installed”.). Claims 16-18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Nordbruch in view of Babayan and David. Regarding Claim 16: Nordbruch discloses, A method of a vehicle computing system, comprising: establishing communication with a computing system of an over-the-air (OTA) integrated charging station (Paragraph [0111]-[0112] teaches a method for establishing communication between the electric vehicle and charging station, “The method includes the following steps: establishing 401 a communication link between the electric vehicle and a charging station”. The charging station may be over-the-air via wireless integration as states in paragraph [0039], “The charging station may, for example, be designed as a wireless charging station”.); transmitting one or more vehicle specifics to the computing system of the OTA integrated charging station (Paragraph [0119] cites, “… this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”.); transmitting, to the computing system of the OTA integrated charging station, a message indicating that the vehicle computing system [] with an OEM system and has been unable to install the OTA software update (In paragraph [0051]-[0052], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station: transmitting a message to a keeper and/or to a driver of the electric vehicle to inform them”. In paragraph [0083], “the processor is designed to ascertain or generate the above-mentioned messages, the communication interface then, in particular, being designed to transmit these messages, or one of the messages, via the communication network”. In paragraph [0082], “a processor of the charging station is designed to carry out the technical method steps according to the method in such a way that it appropriately controls the communication interface”. In paragraph [0048], “The server may thus access the e-vehicle remotely … to carry out a defect analysis”. In paragraph [0045], “the server is a server of an OEM”. Note that the term “malfunction” in paragraph [0051] is used similarly to the term “defects”, as shown in paragraph [0123], “which the software updates are not sufficient to eliminate the discovered defects”.); receiving a software update from the computing system of the OTA integrated charging station based on the one or more vehicle specifics (Paragraph [0119] cites that the OEM inspection provider, “… this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”, identifies the particular software update needed to be transmitted via a check. Paragraph [0010]-[0011] specifies that the check determines whether an electric vehicle needs to have a software update by checking vehicle specific information, stored on the vehicle processing unit, on whether the current software stored on the processing unit may need to be updated. The check is then transmitted to the vehicle processing unit as update data for updating the software to the electric vehicle, with the aid of the charging station.); installing the software update at the vehicle computing system (In paragraph [0048], “The server may thus access the e-vehicle remotely … via the communication link … for example, to install update data”.); determining whether installation of the software update is verified (In paragraph [0050], “the check includes whether the processing unit has a malfunction … if so, whether an update of the software suffices to eliminate the malfunction”.); responsive to the installation not being verified, [] of the OTA integrated charging station [] (In paragraph [0051], “it is provided that, when the update of the software is not sufficient to eliminate the malfunction, at least one of the following actions is carried out with the aid of the charging station”.); and responsive to the installation being verified, notifying the computing system of the OTA integrated charging station [] (In paragraph [0064], “when the update of the software suffices , a message is transmitted to a keeper and/or to a driver of the e-vehicle with the aid of the charging station to inform them”. In paragraph [0043], “the charging station receiving the update data from the server via the further communication link in order to transmit the update data”. In paragraph [0021], “receiving with the aid of the electric vehicle, as a function of the check, update data”. In paragraph [0050], “the check includes whether the processing unit has a malfunction … whether an update of the software suffices to eliminate the malfunction”.). Nordbruch does not disclose however Babayan discloses, the one or more vehicle specifics comprising a make, a model, and a year of a vehicle comprising the vehicle computing system (In paragraph [0056], “the remote computing platform 110 may be associated with an OEM that is responsible for the make and model of the vehicle 105”. In paragraph [0112], “updating certain software versions on a group of vehicles (e.g., certain vehicle models of year X)”.); that the installation is successful (In paragraph [0114], “the consumer systems 520 may be configured to automatically create a rule 522 once an OTA update 515 is validated, deployed, posted, or otherwise made available for distribution. Additionally, or alternatively, the consumer systems 520 may include a display device that is configured to present a user interface for a user of the consumer systems 520”.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to modify Nordbruch by adapting the teaching in Babayan, to obtain an easier delivery of software updates for vehicles from manufactures with the use of over-the- air (OTA) updates. Nordbruch as modified does not disclose however David discloses, has attempted an OTA software update (In paragraph [0062], “the failure notification may include a status message that indicates what portion of the software update failed and why … the failure notification may indicate to the operator that a retry of the software update will be automatically attempted one or more times”. In paragraph [0032], “the vehicle 106 includes an over-the-air (OTA) updater device”, where paragraph [0033] specifies, “the OTA updater device 108 obtains software updates”.); receiving the software update from the computing system [] in one or more retries (In paragraph [0063], “the interface displays an indication 432 that the update was unsuccessful and that the vehicle 106 will automatically retry the software update”. In paragraph [0064], “the method 300 returns to block 334 to attempt to retry the update”. In paragraph [0058], “At block 334 … an interface element for initiating the software update … at block 336 … detects actuation of the interface element and transmits a command to the server computing system 104 to initiate the software update”.). (Examiner’s Note: The claimed “OTA integrated charging station” is disclosed by the primary prior art reference, Nordbruch.). Therefore, it would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to further modify Nordbruch by adapting the teaching in David, to address “drawbacks of using a specialized device to update the vehicle software” (David [0004]) such as the drawback of “the vehicle must be taken to a dealership, service center, or other location that offers software update services using the specialized device … where such updates can be installed may not always be closely available to the vehicle” (David [0003]), by providing an easier delivery of software updates for vehicles with the use of over-the-air (OTA) updates. Regarding Claim 17: Nordbruch discloses, The method of claim 16, further comprising receiving a notification of availability of the software update from the computing system of the OTA integrated charging station (Paragraph [0130] identifies the notification of a software update in the form of a request to the driver for permission to carry out the software update, where “If the software updates suffice … at least the keeper/driver is informed … a permission/request for this service is obtained from the driver/keeper in advance (i.e., prior to an update, in particular prior to a transmission of the update data)”. Paragraph [0130] further specifies the vehicle receives the update data from the charging station during charging, “the check and the transmission of the update data, if necessary, take place during charging”.). Regarding Claim 18: Nordbruch discloses, The method of claim 17, wherein the software update is received in response to an installation request, wherein the installation request is transmitted to the computing system of the OTA integrated charging station based on one of user input and predetermined instructions stored in memory (Paragraph [0130] teaches that a user of the electric vehicle is informed of the software update, where permission is obtained as input in advance, “in particular prior to a transmission of the update data”. Therefore, if permission is given as an approval, then transmission of the update is sent. The driver is informed of the software update through the communication interface linking the electric vehicle and the charging station, as outlined in paragraphs [0105]-[0109]. Paragraph [0118]-[0119] specifies that the charging station assumes functionality of the OEM to carry out the check and transmission of update data, if it is necessary. Paragraph [0113]-[0116] specifies that update data stores the preference of a software update that may be imported in advance, so that the vehicle can receive the instruction on whether to install an update if it is necessary, prior to installation.). Regarding Claim 20: Nordbruch discloses, The method of claim 16, wherein the software update is received by a software installer of the vehicle computing system (Paragraph [0119] cites that the OEM inspection provider identifies the particular software update needed to be transmitted to the vehicle via a check, “this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”. Paragraph [0010]- [0011] specifies that the check determines whether an electric vehicle needs to have a software update, based on the current software stored on the vehicle processing unit. The check is then transmitted as update data to instruct the installation of the software update to the electric vehicle, as outlined in paragraph [0122].). Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Nordbruch in view of Babayan and David as applied to claim 16 above, and further in view of Veselov. Regarding Claim 19: Nordbruch discloses, The method of claim 16, wherein establishing communication with the computing system of the OTA integrated charging station is performed in response to the vehicle having attempted to [] an OTA software update from the OEM system ((Paragraph [0130] teaches that a driver of the electric vehicle is informed of the software update, “If the software updates suffice … at least the keeper/driver is informed”, where permission is obtained in advance, “in particular prior to a transmission of the update data”. Therefore, if permission is denied, then transmission of the update is denied. The driver is informed of the software update through the communication interface linking the electric vehicle and the charging station, as outlined in paragraphs [0105]-[0109], “Electric vehicle 301 includes … a communication interface 307 for establishing a communication link between the electric vehicle and a charging station, so that it is possible to check, via the communication link, whether the software 305 stored on the processing unit of the electric vehicle has to be updated, the communication interface 307 being designed to receive, as a function of the check, update data for updating the software 305 via the communication link from the charging station so that the software may be updated based on the update data”. Paragraph [0117]-[0119] specifies that the charging station assumes functionality of the OEM to carry out the check and transmission of update data, if it is necessary, “the check and the transmission of the update data, if necessary, take place during charging … the charging station assumes the functionality of an OEM inspection provider … this OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”. A request from the vehicle where the denial of transmission is communicated back to the OEM so the software update will not continue as a response of the request answer.); and having been unable to [] the OTA software update due to unavailability of a reliable or cellular data connection (In paragraph [0028], “Even if the charging station is situated in an underground parking garage, a software update may still be carried out, even though conventional mobile communication networks may not be present in an underground parking garage”. In paragraph [0005], “Software updates are increasingly imported via a mobile communication link to the vehicle … coverage of the mobile communication network has dead zones or, for example, when the vehicle enters an underground parking garage. An update of a software on the vehicle may thus fail”.). Nordbruch as modified does not disclose however Veselov discloses, retrieve (See Col. 6, lines 51-56, “A data preparation service or a software program within the computing resource service provider's systems may anonymize and/or encrypt the user data and either send the user data to the scanning service or enable the scanning service to retrieve the user data from a limited-access storage location”.). Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to try and incorporate the teaching of Veselov into the system disclosed by Nordbruch in view of Babayan. The modification would be obvious to try because there is a finite number of predictable solutions. Assuming all other preconditions are working as expected, the update may only be obtained in two ways; if it is given (i.e., sent), or if taken (i.e., retrieved). It is merely a design choice that results in the same outcome of how the vehicle obtains the software update from the OEM system. One of ordinary skill in the art would be motivated to try either system of obtaining data for an update, in order to process data according to the best available configurations. Response to Arguments Applicant’s arguments filed on 08/04/2026 were considered but not persuasive. Regarding the arguments on claim 16, The Applicant states the amended claim limitations added to claim 16 are not disclosed by Nordbruch. The new limitations are disclosed above in the 35 U.S.C. 103 section of this rejection, based on the previous references of Nordbruch and Babayan, and a new additional reference of David. As a result of the references’ obviousness to combine with Nordbruch, the amended claim limitations are disclosed by prior art filed before the application’s effective filing data. Regarding the arguments on claims 1 and 9, Similar to the reasons stated in the above reply to the arguments on claim 16, the amended claim limitations added to claims 1 and 9 are disclosed by existing prior art as described above in the 35 U.S.C. 103 section, despite Veselov not disclosing the amended claim limitations. Because Veselov is not used to not disclose any of the new limitations (i.e., verification, retry, and reporting limitations), however other references are newly used to disclose, the argument does not directly apply and is moot. Further regarding the remark on Veselov’s obviousness rationale being in a “binary solution space”: Nordbruch had supported that the update was “obtained” from the OEM in Nordbruch’s paragraph [0119], “OEM inspection provider carrying out the check and transmitting the update data to the charging station, so that it is then able to forward the received update data to the e-vehicle”. The distinction of “retrieval” was originally combined with an additional reference because of the implication that the update had to be actively taken from the OEM, such as a fetch request. To “obtain” includes the broader case where the update may be given, such as transmission, which Nordbruch did explicitly disclose. The argument was not persuasive because the two ways stated to obtain an update does not necessarily reduce the solution spaces-- the emphasis of finite solutions either being sent or retrieved is based on the direction in which the update is obtained which may still include multiple possible solution spaces; as the update may also either be sent or retrieved through a single or multiple sources, sent or retrieved in a single or multiple sessions, or sent or retrieved as executable or non-executable code. Although the examples listed here are to reflect the Applicant’s, the list is not limited to these solution spaces. In reference to the remark that the rejection was in part relied upon the Applicant’s own disclosure. It is noted that the paragraph from the instant application is to clarify the interpretation of the reference in light of the specification rather than relying on “Applicant’s own disclosure”. Regarding the arguments on claims 6 and 19, Nordbruch does disclose, as supported in the above 103 section, that the software update is transmitted from the OEM system through the charging station in response to an inability to connect to a reliable cellular data connection when the vehicle is underground. Additionally, Nordbruch describes update data reaching the electric vehicle by way of the charging station, where the update data is transmitted to the charging station from the OEM. Therefore, and in addition to the claim language not limiting the OEM to direct communication, Nordbruch discloses that the electric vehicle indirectly communicates with the OEM through the charging station, because update data is given to the charging station from the OEM and is then forwarded to the vehicle. Regarding the arguments on claims 2 and 8, A new additional reference is given for the recited amended claim limitation based on new grounds of rejection, which does not apply to the arguments given based on the previous grounds of rejection, therefore causing the argument to become moot. Regarding the arguments on claims 13 and 14, Although Babayan on its own does not recite the amended limitations from claim 9 by way of claim 12, additional references are used based on the new grounds of rejection, therefore causing this argument to become moot. Conclusion Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any 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 Beza D Nigatu whose telephone number is (571)272-9643. The examiner can normally be reached Monday - Friday 7:30am-3:30pm. 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, Hyung Sough can be reached at (571) 272-6799. 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. /BEZA D NIGATU/Examiner, Art Unit 2192 /S. Sough/SPE, Art Unit 2192
Read full office action

Prosecution Timeline

Mar 19, 2024
Application Filed
May 05, 2026
Non-Final Rejection mailed — §103
Aug 04, 2026
Response Filed
Sep 17, 2026
Final Rejection mailed — §103 (current)

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

3-4
Expected OA Rounds
Grant Probability
Moderate
PTA Risk
Based on 0 resolved cases by this examiner. Grant probability derived from career allowance 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