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 .
Response to Amendment
This office action is in response to the applicant’s amendment filed on 09/16/2025. Claims 1-14 and 19-20 are canceled. Claims 37-39 are new. Claims 15-18 and 21-39 are pending. Claims 15, 21, 25-28, 30-31, and 35-36 are amended. Claims 15, 25, 26, 27, and 28 are independent.
Priority
Acknowledgement is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d) to application DE 102021207473.1 filed on 07/14/2021.
Response to Arguments
Rejections under 35 U.S.C. 112(a):
The rejections under 35 U.S.C. § 112(a) are withdrawn in view of applicant’s filed amendment.
Rejections under 35 U.S.C. 112(b):
The rejections under 35 U.S.C. § 112(b) are withdrawn in view of applicant’s filed amendment.
Rejections under 35 U.S.C. § 103:
Applicant’s arguments on pages 12-19 with respect to the rejection of the claims under 35 U.S.C. § 103 have been fully considered and are partially persuasive. Applicant argues the prior art of record Abo El-Fotouh et al. (EP Patent Application No. 3291119; hereinafter “Abo El-Fotouh ‘119”), in view of Loehr et al. (U.S. PGPub No. 2020/0195613; hereinafter “Loehr”) further in view of FILIPEK et al. (U.S. PGPub No. 2021/0026958; hereinafter “FILIPEK”) does not disclose all the limitations of the independent claims.
Applicant’s argument that the prior art of record does not teach the limitation (I) of the independent claims is not persuasive. Abo El-Fotouh ‘119 teaches an ECU with multiple software components (¶ 0058, Fig. 1). When a manipulation is detected specific virtual machines(s) can be de-loaded/de-activated (¶ 0058); the remaining software components within the ECU are still functioning, which reads on the limitation “the software for which the identification has been made performing a vehicle control function while in the communication restriction state.” The BRI of the limitation “software” can encompass the entirety of the software residing in a single ECU or a subset (e.g., software component) of the software within the ECU as disclosed by Abo El-Fotouh ‘119. Moreover, the limitation “communication restriction state” only requires “communications … is prevented” and does not require all communication to be prevented.
Applicant’s remaining arguments with respect to the amended limitations are persuasive. In view of applicant’s amendment, a new ground(s) of rejection under 35 U.S.C. § 103 is made over Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR (US PGPub No. 2021/0110622; hereinafter “McFarland JR”).
FILIPEK teaches responding to cybersecurity attacks with various actions based on the state and environment of the vehicle (¶ 0025, Fig. 3). The response may be rebooting a processor or ECU when the certain conditions are met such as vehicle speed (¶ 0025). Another response is degrading operation of the vehicle when it was not safe for a system reboot because of the environment such as the speed of the vehicle (¶ 0026, Fig. 3). This reads on determining whether to proceed with the first countermeasure option or the second countermeasure option where the first countermeasure option is immediately resetting the software and the second countermeasure option is continuing operation of the software.
McFarland JR teaches setting the performance of a reset to occur at a later point in time (¶ 0030).
Therefore, applicant’s arguments are persuasive, and in view of the amendments a new ground(s) of rejection is made over Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR.
Regarding applicant’s arguments with respect to the dependent claims, the amendments to the independent claims have necessitated a new ground(s) of rejection with respect to the independent claims from which the dependent claims depend, thereby requiring new grounds of rejection for the dependent claims.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 15, 18, and 22-33, 35-36, and 38 are rejected under 35 U.S.C. 103 as being unpatentable over Abo El-Fotouh et al. (EP Patent Application No. 3291119; hereinafter “Abo El-Fotouh ‘119) further in view of FILIPEK et al. (U.S. PGPub No. 2021/0026958; hereinafter “FILIPEK”) further in view of McFarland JR (US PGPub No. 2021/0110622; hereinafter “McFarland JR”).
As per claim 15: Abo El-Fotouh ‘119 discloses a computer-implemented method, comprising the following steps:
identifying a possibility of manipulation of software of a first component of a plurality of components of an on-board network of a vehicle in a central device for mitigating software manipulation, wherein the central device for mitigating manipulation is part of the on-board network and is configured to mitigate manipulation of software in each of the plurality of components of the on-board network (an automotive security system for performing dynamic actions in response to a manipulation and/or intrusion detection in a vehicle … a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1, vehicle]; the manipulation detection component can be located on a separate, central ECU in the same vehicle communicatively coupled to the secure ECU [¶ 0015]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]); and
initiating a countermeasure for mitigating manipulation of the software of the first component by the central device for mitigating manipulation (the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]; operable to actively de-activate at least the manipulated software component [¶ 0038]);
wherein the method includes either or both of the following two features (I)-(II):
(I) the countermeasure places the software for which the identification has been made in a communication restriction state in which communications by the software for which the identification has been made is prevented, with the software for which the identification has been made performing a vehicle control function while in the communication restriction state (ECUs provide vehicle functions/features … ECUs are increasingly involving features/functionalities with respect to critical tasks that are vulnerable to attack [Abo El-Fotouh ‘119 ¶ 002]; In particular, the hardware virtualization is realized using virtual machines (VMs) 220, 222, 224, 226. In exemplary secure ECU 210 a trusted execution environment (TEE), 226 is realized as VM, where the manipulation detection component 112 and the intrusion detection component 114 are running on. Further, a virtualized domain for each software component may be a separate virtual machine 220, 222, 224. Each virtual machine 220, 222, 224, 226 may act like a separate computer having its own operating system. Accordingly, when a manipulation/intrusion is detected, the respective virtual machine(s) can be de-loaded/de-activated (as explained in detail with reference to Figure 1 above). The VMs 220, 222, 224, 226 are managed by a virtual machine manager (VMM) 230 running on a suitable hardware 240. Further, in this example, a software component is running on each of the VMs 220, 222, 224 [Abo El-Fotouh ‘119 ¶ 0058, Examiner’s Note: de-loaded/de-activated of individual VM(s), while others are still running, all software in ECU interpreted as the software of the component]); and
(II) [a first countermeasure option and a second countermeasure option] are predefined (different response levels can be pre-defined [¶ 0014]), [and the method further comprises determining a current state of the vehicle, and, based on the current state, performing either of the following steps (a)-(b):]
determining at least one of (i) an intensity at which to implement a reset of, selectively, the software for which the identification has been made and (ii) an immediacy with which to reset, selectively, the software for which the identification has been made, according to which one of the first and second countermeasure options is implemented; and
[determining whether to proceed with the first countermeasure option or the second countermeasure option, wherein the initiating of the countermeasure implements whichever of the first and second countermeasures has been determined to be performed, the first countermeasure option is to immediately reset the software for which the identification has been made, and the second counter measure option is to (i) initially continue operation of the software for which the identification has been made with restrictions set due to the manipulation detection] and [(ii) set performance of a subsequent reset of the software to occur at a later point in time].
It's noted that only one of (I) and (II) is required to render the claim obvious and only one of (a) or (b) in the case that (II) is rendered obvious.
Abo El-Fotouh ‘119 discloses the claimed subject matter as discussed above but does not explicitly disclose a first countermeasure option and a second countermeasure option; and the method further comprises determining a current state of the vehicle, and, based on the current state, performing either of the following steps (a)-(b): (b) determining whether to proceed with the first countermeasure option or the second countermeasure option, wherein the initiating of the countermeasure implements whichever of the first and second countermeasures has been determined to be performed, the first countermeasure option is to immediately reset the software for which the identification has been made, and the second counter measure option is to (i) initially continue operation of the software for which the identification has been made with restrictions set due to the manipulation detection. However, FILIPEK teaches a first countermeasure option and a second countermeasure option (a security response database 205 may be a database that includes various options of how the system can respond during an attack … security protocols to activate in case of a cybersecurity attack [FILIPEK ¶ 0024]; analyze whether the vehicle is in a current driving situation that is safe to reboot … And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026-0027]); and the method further comprises determining a current state of the vehicle, and, based on the current state, performing either of the following steps (a)-(b): (b) determining whether to proceed with the first countermeasure option or the second countermeasure option, wherein the initiating of the countermeasure implements whichever of the first and second countermeasures has been determined to be performed, the first countermeasure option is to immediately reset the software for which the identification has been made, and the second counter measure option is to (i) initially continue operation of the software for which the identification has been made with restrictions set due to the manipulation detection (analyze whether the vehicle is in a current driving situation that is safe to reboot … The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment [FILIPEK ¶ 0025, ¶ 0025-0027, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026]; The system may have various use cases scenarios or thresholds to determine if the vehicle is in a safe driving environment to reboot the vehicle system in the scenario of a cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack [FILIPEK ¶ 0025, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 … the system may degrade operation of the vehicle by slowing down the vehicle speed if it is determined safe to do so [FILIPEK ¶ 0026-0027]). Abo El-Fotouh ‘119 and FILIPEK are analogous art because they are from the same field of endeavor of vehicle security. Therefore, based on Abo El-Fotouh ‘119 further in view of FILIPEK, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of FILIPEK to the system of Abo El-Fotouh ‘119 in order to protect a vehicle’s computer system from a cyber-attack under different environmental circumstances and situations (¶ 0002, ¶ 0024-0027). Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
Abo El-Fotouh ‘119 in view of FILIPEK discloses the claimed subject matter as discussed above but does not explicitly disclose (ii) set performance of a subsequent reset of the software to occur at a later point in time. However, McFarland JR teaches (ii) set performance of a subsequent reset of the software to occur at a later point in time (Returning back to the triggering module 290, the triggering module 290 may also include instructions that function to control the processor 110 to receive a second triggering signal at a second moment in time. The second moment in time may be after the first moment in time. The second triggering signal may be generated when the vehicle 100 is turned off, i.e. keyed off and/or one or more systems or subsystems of the vehicle 100 are either in the process of shutting down, shut down, or scheduled to be shut down at a later time. In addition, the second triggering signal may be generated when one or more systems or subsystems of the vehicle 100 detect the potential presence of malware and/or software defects on the vehicle 100. Further still, the second triggering signal may be a driver initiated signal, wherein the driver of the vehicle 100 interacts with the input system 130 after suspecting the potential of malware and/or software defects on the vehicle 100. For example, the input system 130 may be in the form of a button that the driver of the vehicle 100 presses when the driver of the vehicle 100 suspects the potential presence of malware and/or software defects on the vehicle 100. By pressing the button, the second triggering signal is generated, resulting in storing a portion of the volatile memory 115 on the secondary memory 175 or 275. Furthermore, the second triggering signal may be generated by being initiated remotely by a remote initiator. For example, the driver of the vehicle or a remote initiator may have a user interface that allows the manually generating of the first triggering signal. Further still, the vehicle or the remote initiator may automatically generate the second triggering signal either by a periodic schedule or may some potential detections of issues that may relate to malware and/or software defects [¶ 0030]). Abo El-Fotouh ‘119 in view of FILIPEK and McFarland JR are analogous art because they are from the same field of endeavor of vehicle security. Therefore, based on Abo El-Fotouh ‘119 in view of FILIPEK in view of McFarland JR, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of McFarland JR to the system of Abo El-Fotouh ‘119 in view of FILIPEK in order to respond to malware or a software defect with periodically scheduled measures. Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 18: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 discloses wherein the mitigation countermeasure is performed substantially without assistance of systems external to the vehicle (the manipulation detection component is able to actively and dynamically react towards a detected manipulation without the involvement of a third-party, e.g. the remote backend server [¶ 0013]; the intrusion detection component is also able to actively and dynamically react towards a detected intrusion without the involvement of a third-party [¶ 0019]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]).
As per claim 22: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 discloses wherein the countermeasure includes one or more of: [blocking communication of the first component via the on-board network]; blocking communication of a group of the components, which contains the first component, via the on-board network; modifying a functionality of the first component and/or displacing a functionality of the first component to one or more others of the plurality of the components (ECUs provide vehicle features/functionalities for appropriately reacting to situations/events [¶ 0002, Fig. 1]; the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]).
Abo El-Fotouh ‘119 discloses the claimed subject matter as discussed above but does not explicitly disclose blocking communication of the first component via the on-board network. However, Loehr teaches blocking communication of the first component via the on-board network (a countermeasure … setting at least one filtering, blocking or forwarding rule … at least one data stream to or from a terminal node being isolated … a controller area network [¶ 0006-0007]; blocking of the communication of particular terminal nodes [¶ 0008]; blocking the data traffic completely from and/or to the affected ECU [¶ 0055]). Abo El-Fotouh ‘119 and Loehr are analogous art because they are from the same field of endeavor of vehicle control unit and network protection. Therefore, based on Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR in view of Loehr, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Loehr to the system of Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR in order to provide a dynamic reaction as a countermeasure by blocking traffic to and from an effected ECU. This allows software update to be carried out at a later time, quality of service guarantees to be maintained, and fail-safe operations to still operate (blocking of the communication of particular terminal nodes … This means that software updates do not have to be carried out first… quality of service guarantees are kept … fail-safe operations are still possible in spite of denial of service attacks [¶ 0008]). Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 23: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 discloses further comprising: identifying manipulation of the software of the first component by a manipulation detection device of the central device for mitigating manipulation or a further component of the on-board network (a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]; if a manipulation is detected [¶ 0015]); and generating a signal which indicates manipulation of the software of the first component of the plurality of components of the on-board network (if a manipulation is detected, the manipulation detection component may send a secure signal to the secure ECU [¶ 0015, ¶ 0022-0023, ¶ 0043, ¶ 0049]); wherein the identifying of the possibility of manipulation proceeds based on the signal which indicates manipulation of the software of the first component of the plurality of components of the on-board network (wherein the secure signal causes the respective action to be performed (de-load, de-activate, notification to backend server as outlined above) [¶ 0015]).
As per claim 24: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 discloses wherein: the plurality of components of the on-board network includes one or more control units; and/or the first component is a control unit (at least one secure electronic control unit, ECU [¶ 0036, Fig. 1]; a plurality of Electronic Control Units (ECUs) [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1]; the manipulation detection component 114 is operable to detect a software manipulation on at least one software component [¶ 0038]).
As per claim 25: Abo El-Fotouh ‘119 discloses a central device for mitigating manipulation of software of a plurality of components of an on-board network of a vehicle, the central device configured to (the manipulation detection component… central ECU in the same vehicle [¶ 0015, ¶ 0020, ¶ 0043, ¶ 0049]):
identify a possibility of manipulation of software of a first component of the plurality of components of the on-board network of the vehicle in the central device for mitigating software manipulation, wherein the central device for mitigating manipulation is part of the on-board network and is configured to mitigate manipulation of software in each of the plurality of components of the on-board network (an automotive security system for performing dynamic actions in response to a manipulation and/or intrusion detection in a vehicle … a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1, vehicle]; the manipulation detection component can be located on a separate, central ECU in the same vehicle communicatively coupled to the secure ECU [¶ 0015]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]); and
initiate a countermeasure for mitigating manipulation of the software of the first component by the central device for mitigating manipulation (the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]; operable to actively de-activate at least the manipulated software component [¶ 0038]);
The remaining limitations of claim 25 are substantially similar to claim 15 above, and therefore are likewise rejected.
As per claim 26: Abo El-Fotouh ‘119 discloses an on-board network for a vehicle, comprising:
a plurality of components of the on-board network (a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1]); and
a central device for mitigating manipulation of software of the plurality of components, the central device configured to (the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020-0021, ¶ 0049, Fig. 1]):
identify a possibility of manipulation of software of a first component of the plurality of components of the on-board network of the vehicle in the central device for mitigating manipulation, wherein the central device for mitigating manipulation is part of the on-board network and is configured to mitigate manipulation of software in each of the plurality of components of the on-board network (an automotive security system for performing dynamic actions in response to a manipulation and/or intrusion detection in a vehicle … a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1, vehicle]; the manipulation detection component can be located on a separate, central ECU in the same vehicle communicatively coupled to the secure ECU [¶ 0015]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]),
and initiate a countermeasure for mitigating manipulation of the software of the first component by the central device for mitigating manipulation (the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]; operable to actively de-activate at least the manipulated software component [¶ 0038]);
The remaining limitations of claim 26 are substantially similar to claim 15 above, and therefore are likewise rejected.
As per claim 27: Abo El-Fotouh ‘119 discloses a vehicle, comprising:
an on-board network for a vehicle, including (a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1]; vehicle board network [¶ 0056]):
a plurality of components of the on-board network (a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1]);
and a central device for mitigating manipulation of software of the plurality of components, the central device configured to (the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020-0021, ¶ 0049, Fig. 1]):
identify a possibility of manipulation of software of a first component of the plurality of components of the on-board network of the vehicle in the central device for mitigating manipulation, wherein the central device for mitigating manipulation is part of the on-board network and is configured to mitigate manipulation of software in each of the plurality of components of the on-board network (an automotive security system for performing dynamic actions in response to a manipulation and/or intrusion detection in a vehicle … a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1, vehicle]; the manipulation detection component can be located on a separate, central ECU in the same vehicle communicatively coupled to the secure ECU [¶ 0015]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]),
and initiate a countermeasure for mitigating manipulation of the software of the first component by the central device for mitigating manipulation (the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]; operable to actively de-activate at least the manipulated software component [¶ 0038]);
The remaining limitations of claim 27 are substantially similar to claim 15 above, and therefore are likewise rejected.
As per claim 28: Abo El-Fotouh ‘119 discloses a non-transitory computer-readable medium on which is stored a computer program, the computer program, when executed by a computer, causing the computer to perform (a computer program product comprising instructions thereon … loaded and executed by at least one processor [¶ 0033]; the manipulation detection component and/or the intrusion detection component are running on a separate ECU or Backend server [¶ 0022, Examiner’s Note: a software component will necessarily be stored]):
identifying a possibility of manipulation of software of a first component of a plurality of components of an on-board network of a vehicle in a central device for mitigating software manipulation, wherein the central device for mitigating manipulation is part of the on-board network and is configured to mitigate manipulation of software in each of the plurality of components of the on-board network (an automotive security system for performing dynamic actions in response to a manipulation and/or intrusion detection in a vehicle … a manipulation detection component operable to detect a software manipulation on the software components [abstract, Page 1, ¶ 0032, ¶ 0038]; a plurality of Electronic Control Units (ECUs) … ECUs are more and more networked [¶ 0002, ¶ 0009, ¶ 0021, ¶ 0056, Fig. 1, vehicle]; the manipulation detection component can be located on a separate, central ECU in the same vehicle communicatively coupled to the secure ECU [¶ 0015]; the intrusion detection component can be located in the same vehicle on a separate ECU or together with the manipulation detection component -- on the central ECU communicatively coupled to the secure ECU [¶ 0020, ¶ 0049]; operable to detect a software manipulation on the software component during a boot process … operable to detect a software manipulation on the software component during a runtime of the secure ECU [¶ 0038]); and
initiating a countermeasure for mitigating manipulation of the software of the first component by the central device for mitigating manipulation (the manipulation detection component is operable to actively de-activate at least the manipulated software component … manipulation detection component and/or the intrusion detection component may be running on a separate ECU [abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]; operable to actively de-activate at least the manipulated software component [¶ 0038]);
The remaining limitations of claim 28 are substantially similar to claim 15 above, and therefore are likewise rejected.
As per claim 29: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 further discloses wherein the countermeasure (different response levels can be pre-defined [Abo El-Fotouh ‘119 ¶ 0014]) places the software for which the identification has been made (manipulation detection component and/or the intrusion detection component may be running on a separate ECU [Abo El-Fotouh ‘119, abstract, Page 1, ¶ 0009, ¶ 0012, ¶ 0016, ¶ 0017, ¶ 0032]) [in the communication restriction state in which the communications by the software for which the identification has been made is prevented], with the software for which the identification has been made performing the vehicle control function while in the communication restriction state (a manipulated software component can involve a danger to the driver and/or the passengers in the vehicle by e.g. sending ECU-resets during driving [Abo El-Fotouh ‘119 ¶ 0010, ¶ 0014, ECU components involved vehicle functions during driving]).
Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR discloses the claimed subject matter as discussed above but does not explicitly disclose in the communication restriction state in which the communications by the software for which the identification has been made is prevented. However, Loehr teaches in the communication restriction state in which the communications by the software for which the identification has been made is prevented (a countermeasure … setting at least one filtering, blocking or forwarding rule … at least one data stream to or from a terminal node being isolated … a controller area network [Loehr ¶ 0006-0007]; blocking of the communication of particular terminal nodes [Loehr ¶ 0008]; blocking the data traffic completely from and/or to the affected ECU [Loehr ¶ 0055]). Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR and Loehr are analogous art because they are from the same field of endeavor of vehicle security. Therefore, based on Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR in view of Loehr, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Loehr to the system of Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR in order to provide a dynamic reaction as a countermeasure by blocking traffic to and from an effected ECU. This allows software update to be carried out at a later time, quality of service guarantees to be maintained, and fail-safe operations to still operate (blocking of the communication of particular terminal nodes … This means that software updates do not have to be carried out first… quality of service guarantees are kept … fail-safe operations are still possible in spite of denial of service attacks [¶ 0008]). Hence, it would have been obvious to combine the references above to obtain the invention as specified in the instant claim.
As per claim 30: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119 and FILIPEK disclose wherein the first countermeasure option and the second countermeasure option are predefined (different response levels can be pre-defined [Abo El-Fotouh ‘119 ¶ 0014]; a security response database 205 may be a database that includes various options of how the system can respond during an attack … security protocols to activate in case of a cybersecurity attack [FILIPEK ¶ 0024]; analyze whether the vehicle is in a current driving situation that is safe to reboot … And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026-0027]), the first countermeasure is more extensive than the second countermeasure (The system may have various use cases scenarios or thresholds to determine if the vehicle is in a safe driving environment to reboot the vehicle system in the scenario of a cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack [FILIPEK ¶ 0025, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 … the system may degrade operation of the vehicle by slowing down the vehicle speed if it is determined safe to do so [FILIPEK ¶ 0026-0027]), and the method further comprises determining the current state of the vehicle, and, based on the determined current state, determining at least one of (i) the intensity at which to implement the reset of, selectively, the software for which the identification has been made and (ii) the immediacy with which to reset, selectively, the software for which the identification has been made, according to which the one of the first and second countermeasure options is implemented (analyze whether the vehicle is in a current driving situation that is safe to reboot … The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment [FILIPEK ¶ 0025, ¶ 0025-0027, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026]; The system may have various use cases scenarios or thresholds to determine if the vehicle is in a safe driving environment to reboot the vehicle system in the scenario of a cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack [FILIPEK ¶ 0025, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 … the system may degrade operation of the vehicle by slowing down the vehicle speed if it is determined safe to do so [FILIPEK ¶ 0026-0027]).
As per claim 31: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, FILIPEK discloses further comprising selecting, based on the determined current state, between resetting the software for which the identification has been made (analyze whether the vehicle is in a current driving situation that is safe to reboot … And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025, ¶ 0024, Fig. 3]) and restricting actions of the software for which the identification has been made without resetting the software for which the identification has been made (determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026-0027]; if the vehicle controller being attacked is taking control of the driving function in the vehicle, the system may either shutdown the commands for that controller/ECU (e.g. fail operation of that controller) or stop the vehicle … [FILIPEK ¶ 0026, Fig. 3, Examiner’s Note: shutting down the commands by failing the operations of the controller is interpreted as restricting actions without resetting the software for that controller]).
As per claim 32: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 30. Furthermore, FILIPEK discloses wherein the determining of the current state includes determining a current motion state of the vehicle (The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment … the system may have various use cases scenarios or thresholds to determine if the vehicle is in the scenario of cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack … if the system identifies that the vehicle is on a freeway or high speed road (e.g. threshold speed of 50 miles per hour (MPH) is exceeded), the system may recognize the situation where the vehicle is stopping for a traffic jam or at a traffic intersection. And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025]).
As per claim 33: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 30. Furthermore, FILIPEK discloses wherein the determining of the current state includes determining a current speed of the vehicle (The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment … the system may have various use cases scenarios or thresholds to determine if the vehicle is in the scenario of cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack … if the system identifies that the vehicle is on a freeway or high speed road (e.g. threshold speed of 50 miles per hour (MPH) is exceeded), the system may recognize the situation where the vehicle is stopping for a traffic jam or at a traffic intersection. And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025]), and the selecting is performed such that the first countermeasure is selected for lower speeds of the vehicle than for which the second countermeasure is selected (the system may recognize the situation where the vehicle is stopping for a traffic jam or at a traffic intersection (e.g. for red traffic signal). And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025, Examiner’s Note: Slow speeds such as in a traffic jam or stopped in at a red traffic signal allowing time for the system to reboot the respective processor or ECU]; the system may have determined that it is okay to conduct a system reboot for the vehicle … the system may analyze the vehicle environment and determine that rebooting, which may including shutting down and/or restarting the system, may be okay given the current vehicle environment … Such scenarios that may allow for a reboot … the vehicle is being driven at very low speeds [FILIPEK ¶ 0027]).
As per claim 35: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 30. Furthermore, FILIPEK discloses wherein the intensity at which to implement the reset of, selectively, the software for which the identification has been made is determined (analyze whether the vehicle is in a current driving situation that is safe to reboot … The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment [FILIPEK ¶ 0025, ¶ 0025-0027, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026]).
As per claim 36: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 30. Furthermore, FILIPEK discloses wherein the immediacy with which to reset, selectively, the software for which the identification has been made is determined (and if the expected reboot time (which may be stored in the database) is short enough, the system may reboot the processor or ECU. To determine if the reboot time is short enough, the expected restart time (e.g. timing when traffic light becomes green) could be provided by the DSA to predict the driving situation of a feature, or other features such as communication with a traffic signal or other infrastructures [FILIPEK ¶ 0024]).
As per claim 38: Abo El-Fotouh ‘119 in view of FILIPEK further in view of McFarland JR teaches all limitations of claim 15. Furthermore, Abo El-Fotouh ‘119, FILIPEK, and McFarland JR discloses wherein: the first countermeasure option and the second counter measure option are predefined (different response levels can be pre-defined [Abo El-Fotouh ‘119 ¶ 0014]; a security response database 205 may be a database that includes various options of how the system can respond during an attack … security protocols to activate in case of a cybersecurity attack [FILIPEK ¶ 0024]; analyze whether the vehicle is in a current driving situation that is safe to reboot … And if the expected reboot time is short enough, the system may reboot the processor or ECU [FILIPEK ¶ 0025, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026-0027]); the method further comprises: the determining of the current state of the vehicle (analyze whether the vehicle is in a current driving situation that is safe to reboot … The vehicle sensors collect data to determine various vehicle states or conditions of the vehicle’s environment [FILIPEK ¶ 0025, ¶ 0025-0027, ¶ 0024, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026]; The system may have various use cases scenarios or thresholds to determine if the vehicle is in a safe driving environment to reboot the vehicle system in the scenario of a cyber-attack. A reboot may allow the cyberattack to cease attacking, or mitigate damage of the attack [FILIPEK ¶ 0025, Fig. 3]; determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 … the system may degrade operation of the vehicle by slowing down the vehicle speed if it is determined safe to do so [FILIPEK ¶ 0026-0027]); and based on the determined current state, determining whether to proceed with the first countermeasure option or the second countermeasure option (determined that it was not safe for a system reboot … the system may determine at step 303 if the vehicle controller that is being attacked is controlling one or more driving functions of a car … the system may determine to degrade operation of the vehicle at step 313 [FILIPEK ¶ 0026]; The system may have various use cases scenarios or th