DETAILED ACTION
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 Arguments
The amendment filed May 20, 2026 has been entered. Claims 1, 9, and 18-20 have been amended. The remaining claim, claim 19, is in previously presented form. Therefore, claims 1-20 are pending in the application. Claims 1, 9, and 18 are the independent claims.
The applicant’s Remarks, filed May 20, 2026, has been fully considered. The applicant argues, under the heading “Rejections Under 35 U.S.C. §§ 102 and 103” that present claim 1 is not taught by the prior art of record, and in particular by Konrardy (US2021/0116256). Konrardy was used to reject the independent claims in the last detailed action, which was the Non-Final Rejection dated February 20, 2026. Present claim 1 recites the following:
An apparatus comprising:
a plurality of vehicle controllers configured to control a vehicle;
a hacking monitoring system configured to determine whether a hacking activity associated with the vehicle is detected; and
a vehicle control device configured to:
detect, via the hacking monitoring system, hacking activity associated with the vehicle;
identify at least one first vehicle controller, of the plurality of vehicle controllers, corresponding to the hacking activity;
determine, based on the hacking activity, a risk level based on a type of the at least one first vehicle controller;
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone (in the present published disclosure, Kim (US2024/0202327), paragraph 0073 teaches that “If a hacking activity is sensed/detected in the vehicle, the vehicle control device 230 may detect a safety zone in front of the vehicle, set an entry path for entering the safety zone, and adjust the performance of the vehicle controller 210 depending on the entry state to the entry path.” ); and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers; and
an advanced driver assistance system (ADAS) configured to:
control, based on the hacking activity,
The applicant argues that Konrardy does not teach this. The applicant argues on page 10 of the Remarks that paragraph 0118 is simply a “generic safety response to anticipated incidents, which are distinct from the alleged hacking activity of Konrardy described in other paragraphs of Konrardy.” It is hard to consider the hacking activity in Konrardy as “alleged.” It is better characterized as clearly and definitely taught. Fig. 5, block 508, for example, recites “has an incident, including a cyber-attack occurred[?]”. Paragraph 0138 recites “software malfunctions (e.g., hacking attempts, cyber-attacks…etc.)”. Then in block 510 the method determines a response to the hacking. Paragraph 0143 teaches that there can be damage from “malicious code, such as when the component is the target of a cyber-attack.”
The teaching of pulling the vehicle to a shoulder, as found in paragraph 0118, is also found in other places in Konrardy, including places teaching that such an action is a direct response to hacking. Paragraph 0147 teaches that the vehicle may determine a response based on the damage from the hacking mentioned in paragraphs 0138 and 0143. This response, according to paragraph 0147, is “including moving the vehicle 108 out of a traffic lane to a nearby location, such as a roadway shoulder, a parking lane, or a parking lot.” Paragraph 0151 teaches that a remote computer may also be given control of the vehicle to move it to a “parking location out of the flow of traffic (e.g., along a shoulder of a road).” Thus, even if paragraph 0118 refers to pulling to the shoulder in response to predicted incidents, such as running out of gas, the teaching of moving a vehicle to a safe location, such as a shoulder, is also taught as a response to a hacking incident.
Some of the rejections in the last detailed action, such as the rejection of claim 11, cited paragraph 0147 “for on-board computer 114 detecting situations and moving a host vehicle out of a lane and to a shoulder. See paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” The rejection of claim 3 including the statement “see Konrardy paragraph 0147 for on-board computer 114 detecting situations and moving a host vehicle out of a lane and to a shoulder.”
What do the amended limitations mean in a broad reasonable interpretation, and do they have written description. To determine that the examiner copies the limitations below, and comments on them in bold.
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone (in the present published disclosure, Kim (US2024/0202327), paragraph 0073 in its entirety reads: “If a hacking activity is sensed/detected in the vehicle, the vehicle control device 230 may detect a safety zone in front of the vehicle, set an entry path for entering the safety zone, and adjust the performance of the vehicle controller 210 depending on the entry state to the entry path.” This seems to the examiner a long form way of stating that if there is hacking activity, the vehicle will safety pull over to the shoulder or perform some other safety maneuver. Paragraphs 0081-0085 also mention a “safety zone” but in about the same amount of detail as paragraph 0073. As far as the examiner can tell, the term “entry path” is only used twice in the disclosure, both times in paragraph 0073.); and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers (in the present published disclosure, as far as the examiner can tell, the term “entry state” is used only once, which is in paragraph 0073. It is not clear what “an entry state” to the entry path is. Is it the state of one of the controllers or components of the vehicle as it enters the entry path? For examination purposes, that is how the phrase will be interpreted.
In broad reasonable interpretation, based on paragraph 0073, this limitation seems to mean: the system can “adjust” a vehicle controller based on the risk level, the hacking activity, and “an entry state” of the vehicle (which might be the degree to which, or the way in which, the vehicle is disabled from hacking).
In what way is does the system “adjust” the “second vehicle controller” based on these factors? Keep in mind that earlier in the claim it taught that the “first vehicle controller” was the one “corresponding to the hacking activity.” The second vehicle controller is reasonably the one that still works. In a broad reasonable interpretation, if a first vehicle controller is hacked the system may “adjust” the second vehicle controller to perform the safety maneuver. In one broad reasonable scenario, if a vehicle’s steering controller is hacked, but the vehicle’s braking controller is still operating correctly, the system may “adjust” the braking controller (i.e., the second vehicle controller) based on recognizing that the “risk level” of the hack to the first vehicle controller is high, that the vehicle needs to pull to a shoulder, and that the “entry state” of this maneuver is going to be one in which the steering controller does not operate but the braking controller does. The system may therefore identify a “safety zone,” such as a shoulder in front of the vehicle, and use differential braking to both slow down and direct the vehicle along a path to reach the safety zone. This change from the normal path of the vehicle to one in which the braking controllers needs to execute some new commands reasonably meets this limitation).
In the examiner’s view, Konrardy teaches at least strongly teaches towards these limitations, if not teaches them. Konrardy teaches pulling over to a shoulder, as in paragraphs 0147, does that mean that the system identifies a “safety zone” in which to pull over? That certainly seems to be what paragraph 0147 means by reciting “moving the vehicle 108 out of a traffic lane to a nearby location, such as a roadway shoulder, a parking lane, or a parking lot.” This “nearby location” is a “safety zone.”
Konrardy also teaches adjusting controllers based on hacks. See paragraph 0217 for a component malfunction leading to “placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.”
Does Konrardy also teach that the system will “set an entry path for entering the safety zone.” It is doubtful that Konrardy intends to imply that the vehicle will simply perform a maneuver regardless of whether it is safe, such as if other vehicles are around. In the same way that lane-change art doesn’t simply execute lane changes even when requested if there is a vehicle blocking the space in the neighboring lane, Konrardy cannot be reasonably construed to teach that the system will simply perform a lane change to the shoulder in disregard of nearby vehicles. This interpretation is supported by paragraph 0150 on Konrardy which teaches that the system can also drive a vehicle occupant all the way to the hospital in fully autonomous mode if needed.
Since Konrardy teaches a system that will autonomously pull the vehicle over to the shoulder when necessary it seems inherent to the examiner that the autonomous system sets an “entry path” to do this. Yet the examiner has found art that teaches this even more explicitly.
In particular, Ho et al. (US2017/0090480) teaches the amended limitations of present claim 1.
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone (see Ho paragraph 0167 for the AVS 1600 planning for various failures of malfunctions for which a failsafe action is “triggered”. See Fig. 16 for the “AVS” being an autonomous vehicle system. See paragraph 0167 for the failure or malfunction being related to a “bug or hardware malfunctions or failures”. These can “trigger” a “failsafe action”. See paragraph 0167 for the event or condition being “a cataclysmic failure or malfunction”. In that case, in at least one embodiment the vehicle will “pull the vehicle to a safe roadside location before stopping, turning off, or calling for assistance.” See paragraph 0171 for determining “multiple failsafe trajectories 1653 at one time”. See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors. See paragraph 0176 for “in variations, the route planning component 1650 may also determine a more sophisticated failsafe trajectory 1653, requiring for example, a sharp turn or a sequence of driving actions.”); and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers (see Fig. 16 and paragraph 0177 for a “redundant or alternative controller 1648 can receive the failsafe trajectory 1653” and implement it when needed. Trajectories can be “triggered by different types of failures (e.g., brake failure for a brake failure trajectory, steering failure for a steering failure trajectory, etc.).” See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors.).
The motivation to combine Ho with Konrardy would be to allow the vehicle to implement a “failsafe action in which the vehicle drives to safety and stops” when there is a “malfunction, such as the vehicle’s software malfunctioning,” as recognized by Ho, paragraphs 0169 and 0167.
Due to the applicant’s amendments the grounds for rejection have changed. Please see the rejections below.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 20 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claims contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for pre-AIA the inventor(s), at the time the application was filed, had possession of the claimed invention.
Claim 20 lacks written description and is new matter. It might be that Table 2 gestures toward something somewhat related to claim 20, but it does not do so at the level of abstraction of the claim. The Remarks provide no guidance as to where support might be found for the claim in the original disclosure. For examination purposes, the claim will be interpreted as written.
Claim 20 recites:
The apparatus of claim 18,wherein
a first group of vehicle controllers of the plurality of vehicle controllers corresponds to a first type of vehicle controllers,
wherein a second group of vehicle controllers of the plurality of vehicle controllers corresponds to a second type of vehicle controllers, and
wherein different types of vehicle controllers respectively correspond to different risk levels
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 for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
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 1, 9-16, and 18 rejected under 35 U.S.C. 103 as being unpatentable over Konrardy (US2021/0116256) in view of Ho et al. (US2017/0090480).
Regarding claim 1, Konrardy teaches:
An apparatus comprising (see Fig. 1A):
a plurality of vehicle controllers configured to control a vehicle (see Konrardy paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s current software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component. That is based on paragraph 0211 which recites that “extent of use of the component in the autonomous vehicle,” implying that some components are used more than others, and there are a plurality of them. See also paragraph 0208 for “components” (plural) related to “distinct autonomous operation features” and “hardware components associated therefore (e.g….controllers)”.);
a hacking monitoring system configured to determine whether a hacking activity associated with the vehicle is detected (see paragraph 0138 for an on-board computer detecting “hacking attempts, [and] cyber attacks”.); and
a vehicle control device configured to (see paragraph 0138 for an on-board computer):
detect, via the hacking monitoring system, hacking activity associated with the vehicle (see paragraph 0138 for an on-board computer detecting “hacking attempts, [and] cyber attacks”.);
identify at least one first vehicle controller, of the plurality of vehicle controllers, corresponding to the hacking activity (see paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. This makes sense because a component without a controller cannot incur a cyberattack. A components that merely include gearboxes, for example, cannot be hacked.);
determine, based on the hacking activity, a risk level based on a type of the at least one first vehicle controller (see paragraph 0213 for detecting a software hack and then evaluated the “severity,” which can be, “low, mid, high, critical, etc.” The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level.); and
an advanced driver assistance system (ADAS) configured to (see paragraph 0215 for determining that the result of a hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.”):
control, based on the hacking activity,see paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Yet Konrardy does not explicitly further teach:
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone; and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers.
However, Ho teaches:
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone (see Ho paragraph 0167 for the AVS 1600 planning for various failures of malfunctions for which a failsafe action is “triggered”. See Fig. 16 for the “AVS” being an autonomous vehicle system. See paragraph 0167 for the failure or malfunction being related to a “bug or hardware malfunctions or failures”. These can “trigger” a “failsafe action”. See paragraph 0167 for the event or condition being “a cataclysmic failure or malfunction”. In that case, in at least one embodiment the vehicle will “pull the vehicle to a safe roadside location before stopping, turning off, or calling for assistance.” See paragraph 0171 for determining “multiple failsafe trajectories 1653 at one time”. See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors. See paragraph 0176 for “in variations, the route planning component 1650 may also determine a more sophisticated failsafe trajectory 1653, requiring for example, a sharp turn or a sequence of driving actions.”); and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers (see Fig. 16 and paragraph 0177 for a “redundant or alternative controller 1648 can receive the failsafe trajectory 1653” and implement it when needed. Trajectories can be “triggered by different types of failures (e.g., brake failure for a brake failure trajectory, steering failure for a steering failure trajectory, etc.).” See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Konrardy, to add the additional features indicated, as taught by Ho. The motivation for doing so would be to allow the vehicle to implement a “failsafe action in which the vehicle drives to safety and stops” when there is a “malfunction, such as the vehicle’s software malfunctioning,” as recognized by Ho (see paragraphs 0169 and 0167).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 9, Konrardy teaches:
A method comprising:
determining, by a computing device, a hacking activity associated with a vehicle (see paragraph 0138 for an on-board computer detecting “hacking attempts, [and] cyber attacks”.);
identifying at least one first vehicle controller, of a plurality of vehicle controllers configured to control the vehicle, corresponding to the hacking activity (see paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. This makes sense because a component without a controller cannot incur a cyberattack. A components that merely include gearboxes, for example, cannot be hacked.);
determine, based on the hacking activity, a risk level based on a type of the at least one first vehicle controller (see paragraph 0213 for detecting a software hack and then evaluated the “severity,” which can be, “low, mid, high, critical, etc.” The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level.);
controlling, based on the hacking activity, at least one advanced driver assistance system (ADAS) operation associated with the at least one second vehicle controller (see paragraph 0215 for determining that the result of a hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” See paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Yet Konrardy does not explicitly further teach:
detecting a safety zone in front of the vehicle and setting an entry path for entering the safety zone;
adjusting, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the vehicle.
However, Ho teaches:
detecting a safety zone in front of the vehicle and setting an entry path for entering the safety zone (see Ho paragraph 0167 for the AVS 1600 planning for various failures of malfunctions for which a failsafe action is “triggered”. See Fig. 16 for the “AVS” being an autonomous vehicle system. See paragraph 0167 for the failure or malfunction being related to a “bug or hardware malfunctions or failures”. These can “trigger” a “failsafe action”. See paragraph 0167 for the event or condition being “a cataclysmic failure or malfunction”. In that case, in at least one embodiment the vehicle will “pull the vehicle to a safe roadside location before stopping, turning off, or calling for assistance.” See paragraph 0171 for determining “multiple failsafe trajectories 1653 at one time”. See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors. See paragraph 0176 for “in variations, the route planning component 1650 may also determine a more sophisticated failsafe trajectory 1653, requiring for example, a sharp turn or a sequence of driving actions.”); and
adjusting, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the vehicle (see Fig. 16 and paragraph 0177 for a “redundant or alternative controller 1648 can receive the failsafe trajectory 1653” and implement it when needed. Trajectories can be “triggered by different types of failures (e.g., brake failure for a brake failure trajectory, steering failure for a steering failure trajectory, etc.).” See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Konrardy, to add the additional features indicated, as taught by Ho. The motivation for doing so would be to allow the vehicle to implement a “failsafe action in which the vehicle drives to safety and stops” when there is a “malfunction, such as the vehicle’s software malfunctioning,” as recognized by Ho (see paragraphs 0169 and 0167).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 10, Konrardy and Ho teach the method of claim 9.
Konrardy further teaches:
The method of claim 9, wherein an ADAS of the vehicle comprises:
a plurality of function applications to perform see paragraph 0213 for the “an inability to operate in a fully autonomous or semi-autonomous mode.” See paragraph 0093 for the autonomous vehicle having adaptive cruise control and automatic lane centering.), and
wherein the plurality of function applications comprises at least one of:Forward Collision-Avoidance Assist (FCA) to assist forward collision-avoidance,Lane Keeping Assist (LKA) to assist lane keeping, Blind-Spot Collision-Avoidance Assist (BCA) to assist rearward collision-avoidance, Intelligent Speed Limit Assist (ISLA) to assist intelligent speed limit, Smart Cruise Control (SCC) to perform smart cruise control, Navigation-based Smart Cruise Control (NSCC) to perform navigation-based smart cruise control, Lane Following Assist (LFA) to assist lane following, or Highway Driving Assist (HDA) to assist highway driving (see paragraph 0093).
Regarding claim 11, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises: a power train controller to control longitudinally accelerating (see paragraph 0093. A fully autonomous vehicle uses a controller to control acceleration.), and
wherein the controlling of see Konrardy paragraph 0147 for on-board computer 114 detecting situations and moving a host vehicle out of a lane and to a shoulder. see paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 12, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises:a brake controller to control longitudinally decelerating (see paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.), and
wherein the controlling of see paragraph 0124 for enabling or disabling autonomous features, including adaptive cruise control. See paragraph 0093. See paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level. Paragraph 0217 goes on to teach that once there are “identified occurrences of component [with processor] malfunctioning” the system can seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.).
Regarding claim 13, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises: a steering controller to control lateral driving (see paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident), and
wherein the controlling of see paragraph 0124 for enabling or disabling autonomous features, including adaptive cruise control. See paragraph 0093. See paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level. Paragraph 0217 goes on to teach that once there are “identified occurrences of component [with processor] malfunctioning” the system can seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.).
Regarding claim 14, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises: a gateway for vehicle networking (see Fig. 4B and paragraph 0120 for a controller and server a network 130 connecting them. See paragraph 0114 for control gates), and
wherein the controlling of see paragraph 0055. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 15, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises: a vehicle to everything (V2X) controller for communication with an external device (see paragraph 0285 for using V2V), and
wherein the controlling of see paragraph 0213 for detecting a software hack and then evaluated the “severity,” which can be, “low, mid, high, critical, etc.” See paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 16, Konrardy and Ho teach the method of claim 10.
Konrardy further teaches:
The method of claim 10, wherein
the at least one first vehicle controller comprises: an audio, video, and navigation (AVN) controller to control a user interface (see paragraph 0063 for a vehicle telephone, entertainment, navigation, or information system of the vehicle.), and
wherein the controlling of see paragraph 0055 for a navigation application 144. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 18, Konrardy teaches:
An apparatus for a vehicle, the apparatus comprising:
a plurality of vehicle controllers each configured to control at least one operation of the vehicle (see Konrardy paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s current software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component. That is based on paragraph 0211 which recites that “extent of use of the component in the autonomous vehicle,” implying that some components are used more than others, and there are a plurality of them. See also paragraph 0208 for “components” (plural) related to “distinct autonomous operation features” and “hardware components associated therefore (e.g….controllers)”.);
at least one processor (see Fig. 1B, item 181.1); and
a memory storing instructions that, when executed by the at least one processor, are configured to cause the apparatus to (see paragraph 0053):
control at least one of an autonomous driving operation or an advanced driver assistance system (ADAS) operation (see paragraph 0213 for fully autonomous or semi-autonomous mode.” See paragraph 0093 for the autonomous vehicle having adaptive cruise control and automatic lane centering);
detect hacking activity associated with the vehicle (see paragraph 0138 for an on-board computer detecting “hacking attempts, [and] cyber attacks”.);
identify at least one first vehicle controller, of the plurality of vehicle controllers, corresponding to the hacking activity (see paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. This makes sense because a component without a controller cannot incur a cyberattack. A components that merely include gearboxes, for example, cannot be hacked.);
determine, based on the hacking activity, a risk level based on a type of the at least one first vehicle controller (see paragraph 0213 for detecting a software hack and then evaluated the “severity,” which can be, “low, mid, high, critical, etc.” The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level.);
control, based on the hacking activity, at least one of an autonomous driving operation associated with the at least one second vehicle controller or an ADAS operation associated with the at least one second vehicle controller (see paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Yet Konrardy does not explicitly further teach:
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone; and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers.
However, Ho teaches:
detect a safety zone in front of the vehicle and set an entry path for entering the safety zone (see Ho paragraph 0167 for the AVS 1600 planning for various failures of malfunctions for which a failsafe action is “triggered”. See Fig. 16 for the “AVS” being an autonomous vehicle system. See paragraph 0167 for the failure or malfunction being related to a “bug or hardware malfunctions or failures”. These can “trigger” a “failsafe action”. See paragraph 0167 for the event or condition being “a cataclysmic failure or malfunction”. In that case, in at least one embodiment the vehicle will “pull the vehicle to a safe roadside location before stopping, turning off, or calling for assistance.” See paragraph 0171 for determining “multiple failsafe trajectories 1653 at one time”. See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors. See paragraph 0176 for “in variations, the route planning component 1650 may also determine a more sophisticated failsafe trajectory 1653, requiring for example, a sharp turn or a sequence of driving actions.”); and
adjust, based on the risk level and based on the hacking activity and an entry state to the entry path, performance of at least one second vehicle controller of the plurality of vehicle controllers (see Fig. 16 and paragraph 0177 for a “redundant or alternative controller 1648 can receive the failsafe trajectory 1653” and implement it when needed. Trajectories can be “triggered by different types of failures (e.g., brake failure for a brake failure trajectory, steering failure for a steering failure trajectory, etc.).” See paragraph 0176 for “the route planning component 1650” that “can calculate at least one failsafe trajectory 1653 which identifies a safe (or most safe) route to move the vehicle to a selected length of the shoulder on the road.” See paragraph 0176 for the system calculating “multiple stopping location” and then selecting the “most safe” one based on the “closest stopping location” or one that is not the closest but “more optimal for safety”. The selection may be based on the length of the shoulder, the location of the shoulder (left or right side) or other factors.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Konrardy, to add the additional features indicated, as taught by Ho. The motivation for doing so would be to allow the vehicle to implement a “failsafe action in which the vehicle drives to safety and stops” when there is a “malfunction, such as the vehicle’s software malfunctioning,” as recognized by Ho (see paragraphs 0169 and 0167).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Claims 2-8 and 17 rejected under 35 U.S.C. 103 as being unpatentable over Konrardy in view of Ho in further view of Cha (US2021/0114534 A1).
Regarding claim 2, Konrardy and Ho teach the apparatus of claim 1.
Konrardy further discloses:
An apparatus wherein the ADAS comprises:
a plurality of function applications to perform see paragraph 0213 for the “an inability to operate in a fully autonomous or semi-autonomous mode.” See paragraph 0093 for the autonomous vehicle having adaptive cruise control and automatic lane centering.); and
an ADAS control device to control see paragraph 0147 for on-board computer 114 detecting situations and moving a host vehicle out of a lane. See paragraph 0093 for the autonomous vehicle having adaptive cruise control and automatic lane centering.).
Yet Konrardy and Ho not explicitly further teach:
a sensor fusion configured to receive an external sensing signal.
However Cha teaches:
a sensor fusion configured to receive an external sensing signal (the examiner submits that a sensor fusion system is inherent in an ADAS system that performs lane keeping, automatic braking, etc. But the examiner cites Cha here because Cha explicitly teaches this. See Cha Fig. 1 for item 117 and paragraph 0018 for “a sensor fusion detection controller 117”. Note that Cha is directed toward the same general idea as Konrardy. See Cha paragraph 0016 for a “hacker” that tries to hack the host vehicle 102. See paragraph 0028 for the system being able to “determine whether an attack has occurred or not.” See Fig. 3, step 308 and paragraph 0044 for flagging and discarding values that come from a hacker and not the vehicle system.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the system, as taught by Konrardy and Ho, to add the additional features of a sensor fusion configured to receive an external sensing signal, as taught by Cha. The motivation for doing so would be to navigate autonomously with a secure system, as recognized by Cha (see paragraph 0006).
This conclusion of obviousness corresponds to KSR rationale “A”: it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined prior art elements according to known methods to yield predictable results. See MPEP § 2141, subsection III.
Regarding claim 3, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
An apparatus wherein the plurality of function applications comprises at least one of:
Forward Collision-Avoidance Assist (FCA) to assist forward collision-avoidance, Lane Keeping Assist (LKA) to assist lane keeping, Blind-Spot Collision-Avoidance Assist (BCA) to assist rearward collision-avoidance, Intelligent Speed Limit Assist (ISLA) to assist intelligent speed limit, Smart Cruise Control (SCC) to perform smart cruise control, Navigation-based Smart Cruise Control (NSCC) to perform navigation-based smart cruise control, Lane Following Assist (LFA) to assist lane following, or Highway Driving Assist (HDA) to assist highway driving (see paragraph 0093),
wherein the at least one vehicle controller comprises a power train controller to control longitudinally accelerating (see paragraph 0093. A fully autonomous vehicle uses a controller to control accleration.), and
wherein the ADAS control device is configured to stop, based on a in a broad reasonable interpretation, HAD includes ACC and automatic lane-keeping or lane-keeping assist. With that in mind, see Konrardy paragraph 0147 for on-board computer 114 detecting situations and moving a host vehicle out of a lane and to a shoulder. see paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 4, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
The apparatus of claim 2, wherein the at least one first vehicle controller comprises:
a brake controller to control longitudinally decelerating (See paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.), and
wherein the ADAS control device is configured to stop, based on a see paragraph 0124 for enabling or disabling autonomous features, including adaptive cruise control. See paragraph 0093. See paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level. Paragraph 0217 goes on to teach that once there are “identified occurrences of component [with processor] malfunctioning” the system can seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.).
Regarding claim 5, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
The apparatus of claim 2, wherein the at least one first vehicle controller comprises:
a steering controller to control lateral driving (see paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.), and
wherein the ADAS control device is configured to stop, based on Spot Collision-Avoidance Assist(BCA), Lane Following Assist (LFA), Highway Driving Assist (HDA) (see paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident. See paragraph 0124 for enabling or disabling autonomous features, including adaptive cruise control. See paragraph 0093. See paragraph 0094 for autonomous braking for collision avoidance. See paragraph 0213 for a system that can determining the “vulnerabilities” in an autonomous vehicle’s software that is “executing on the component,” as stated in paragraph 0214. This “the component” can reasonably be interpreted as a specific component of the plurality of components mentioned in at least paragraph 0208. See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” See paragraph 0215 for determining an “identified occurrence of the component malfunctioning.” This reasonably means that “the component” of the vehicle has been hacked, including the component’s controller. The “impact” of this software hack may be “an inability to operate in a fully autonomous or semi-autonomous mode.” According to paragraph 0216 and 0217, the response to the hack depends on the determined “risk” level. Paragraph 0217 goes on to teach that once there are “identified occurrences of component [with processor] malfunctioning” the system can seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0279 for “different hardware features for automatic braking, different computer instructions for automatic steering”. See paragraph 0049.).
Regarding claim 6, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
The apparatus of claim 2, wherein the at least one first vehicle controller comprises:
a gateway for vehicle networking (see Fig. 4B and paragraph 0120 for a controller and server a network 130 connecting them. See paragraph 0114 for control gates), and
wherein the ADAS control device is configured to stop, based on a-thesee paragraph 0055. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 7, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
The apparatus of claim 2, wherein
the at least one first vehicle controller comprises:
a vehicle to everything (V2X) controller for communication with an external device (see paragraph 0285 for using V2V), and
wherein the ADAS control device is configured to maintain, based on a-thesee paragraph 0213 for detecting a software hack and then evaluated the “severity,” which can be, “low, mid, high, critical, etc.” See paragraph 0217 which teaches that once there are “identified occurrences of component [with processor] malfunctioning” (due to a hack) the system will seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.” See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 8, Konrardy, Ho, and Cha teach the apparatus of claim 2.
Konrardy further teaches:
The apparatus of claim 2, wherein the at least one first vehicle controller comprises:
an audio, video, and navigation (AVN) controller to control a user interface (see paragraph 0063 for a vehicle telephone, entertainment, navigation, or information system of the vehicle.), and
wherein the ADAS control device is configured to stop, based on a-thesee paragraph 0055 for a navigation application 144. See paragraph 0118, among others, for pulling the vehicle to the shoulder to minimize the negative effects of an incident.).
Regarding claim 17, Konrardy, Ho, and Cha teach the apparatus of claim 3,
Konrardy further teaches:
The apparatus of claim 3, wherein
the ADAS control device is configured to: while maintaining at least one autonomous driving function active, stop, based on thesee paragraph 0217 for the teaching that when there are “identified occurrences of component [with processor] malfunctioning” the system can seek “mitigation”. This mitigation may including “making adjustments to the operation of one or more autonomous operation features associated with the malfunctioning component, placing restrictions or limits on the use of the one or more autonomous operation features, or engaging additional components to compensate for the malfunction.”).
Potentially Allowable Subject Matter
Claim 19 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
Claim 19 is not taught by the prior art of record, alone or in combination. The claim recites:
The apparatus of claim 18, further comprising
an autonomous driving system configured to perform the at least one of the autonomous driving operation or the ADAS operation, wherein the instructions, when executed by the at least one processor, are configured to cause the apparatus to:
stop a function of the at least one first vehicle controller corresponding to the hacking activity;
normally operate performance of remaining vehicle controllers of the plurality of vehicle controllers until the vehicle enters the safety zone; and
after the vehicle enters the safety zone, decrease the performance of the remaining vehicle controllers into a preset range.
In the present disclosure, paragraph 0084 teaches this limitation.
One close prior art is Konrardy (US2021/0116256). Konrardy teaches that “components” can fail. These can be considered steering and braking components, including their controllers. Yet Konrardy does not further teach, as present claim 19 does, at least: after the vehicle enters the safety zone, decrease the performance of the remaining vehicle controllers into a preset range.
Another close prior art is Ho et al. (US2017/0090480). Ho teaches a primary and a redundant controller. But Ho does not further teach, as present claim 19 does, at least: after the vehicle enters the safety zone, decrease the performance of the remaining vehicle controllers into a preset range.
Additional Art
The prior art made of record here, though not relied upon, is considered pertinent to the present disclosure.
Batts et al. (US2020/0339151). See Batts paragraph 0070 for lane markings. See paragraph 0067 for sensors including the hardware and processing components. See Batts paragraph 0059 for the teaching that if right hand sensors fail the vehicle may still be able to turn left. See paragraph 0080 for lidar and radar. See paragraph 0177 for a safe stop maneuver and paragraph 0018 for a “ ‘limp home’ mode”. See Batts paragraph 0152 for sensors 1310 “or a subset of sensors 1310” failing or being “determined to have a level of confidence that is less than a confidence level threshold in the AV 1304.” If all the right hand side sensors fail the vehicle will only make left turns. “The planning module 1338 adjusts the vehicle operation profile 1384 based on the failed subset of sensors”. In some cases, the vehicle may enter “a ‘limp home mode.’” But “if all sensors fail,” the vehicle will “come to a stop as soon as possible…hereinafter ‘Safe Stop’, according to paragraph 0153. See also Fig. 14, step 1425 (Yes out of step 1420) and paragraph 0174. If the right hand side subset of sensors have failed the system will “adjust” the driving on the vehicle. Yet in Fig. 14, step 1430 (No out of step 1420), and paragraph 0175, based on a different threshold, the vehicle will execute “emergency maneuvers to navigate the vehicle to a safe location.” Therefore, in Batts there is the lowest level of degradation, which is Fig. 14, step 1430. And this is “from a predetermined number of levels”, as recited in the present claim, which are Batts, Fig. 14, step 1425, and normal full working operation.
Kagerer et al. (US2021/0269039), a BMW disclosure. Kagerer teaches that if an emergency stop is triggered, but no passenger is in the vehicle compartment, then the system may determine that the vehicle can simply stop in a lane. But if there is a passenger in the vehicle compartment, as determined by a seat sensor for example, the system may determine that “The lane change is…less risky than stopping on the current traffic lane,” as recited in paragraph 0060. This is one broad reasonable interpretation of what it means for a risk assessment for the automated lane change to be based on a vehicle passenger compartment characteristic.
Oshida et al. (US2016/0071418). Oshida teaches in paragraph 0067 that if a vehicle occupant is experiencing a life threatening emergency the vehicle may “perform an emergency stop or pull over maneuver”. Paragraph 0068 goes on to teach pulling over to a shoulder of a roadway.
Oba et al. (US2017/0364070) teaches in at least Fig. 3 and 10 that in the event of a sensor failure in an autonomous vehicle, the vehicle should pull over. But if it is safer for the vehicle to keep driving it can do that. In other words, when there is a sensor failure, take the safest action possible. Oba teaches that in the event of a sensor failure in an autonomous vehicle, the vehicle should pull over. But if it is safer for the vehicle to keep driving it can do that. In other words, when there is a sensor failure, take the safest action possible.
See paragraph 0072 for “the determination processing unit 26 can control the driving processing unit 32 to cause the vehicle to evacuate into an evacuation lane and suddenly slows down within a safe range for a vehicle driving behind in accordance with automatic driving.”
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 DANIEL M. ROBERT whose telephone number is (571)270-5841. The examiner can normally be reached M-F 7:30-4:30 EST.
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, Hunter Lonsberry can be reached at 571-272-7298. 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.
/DANIEL M. ROBERT/Primary Examiner, Art Unit 3665
Prosecution Insights