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 .
Status of Claims
Claims 1, 3-9, 11, 13-19, and 21-24 are pending in this application.
Claims 2, 10, 12, and 20 are cancelled.
Claims 1, 3-4, 6-9, 11, and 13-19 are amended.
Claims 21-24 are newly added.
Claims 1, 3-9, 11, 13-19, and 21-24 are presented for examination.
Claim Interpretation
The examiner is interpreting the term “long distance” found in claims 8 and 18 as an area or a region within a threshold distance with time enough to identify a risk and send an alert to the user before the vehicle reaches the location of the risk as supported by the applicant’s specification (Para. 5, 25).
Response to Arguments
Claim Objections
Claim 1 is objected to because of the following informalities:.
Claim 1’s “vehicle operational data data” should be – vehicle operation data --.
Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The 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 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, 3-8, 11-18, and 21-24 are rejected under 35 U.S.C. 103 as being unpatentable over Nayak et al. (US Publication 2020/0167575 A1) in view of Dronen et al. (US Publication 2022/0203973 A1).
Regarding claim 1, Nayak teaches a vehicle-related event recognization and alert system, the vehicle-related event recognization and alert system comprising: a plurality of control systems of a plurality of original equipment manufacturer (OEM) vehicles, respectively, each OEM vehicle being associated with an OEM and each control system (Nayak: Para. 7; plurality of in-vehicle sensors installed in multiple vehicles traveling the road or from an original equipment manufacturer (OEM) cloud of the multiple vehicles) being configured to: detect a vehicle-related event in which an encounter between the OEM vehicle and one or more other objects occurred (Nayak: Para. 7; vehicular sensor data related to a number of positive observations of the physical divider by unique vehicles), verify that the vehicle-related event is a valid vehicle-related event for training of a long range vehicle-related event recognization model (Nayak: Para. 7; one or more aggregated values generated from the categorical vehicular sensor data includes selected categorical values, using a voting algorithm, for each of the physical divider measurement event type, the physical divider flag), and in response to verifying that the vehicle-related event is valid, transmitting vehicle operational data relating to the vehicle-related event via a network (Nayak: Para. 7; one or more aggregated values are collected over an extended period of time for use in training of the machine learning model for prediction of presence of the physical divider), and a computing server associated with the OEM and configured to: (Nayak: Para. 36, 81; OEM cloud for the vehicles; processing needed by the machine learning model is provided on the server side) ……… , and train the long range vehicle-related event recognization model based on the received vehicle operational data (Nayak: Para. 1, 36; using the trained machine learning model for predicting presence of one or more physical dividers on at least one segment of a road; train a machine learning model to predict physical dividers on a road segment of interest, based on map data associated with the segment of interest, vehicular sensor data collected from vehicles, an OEM cloud for the vehicles), wherein the trained long range vehicle- related event recognization model is configured to (i) recognize a plurality of different types of vehicle-related events at least at a long distance relative to a particular OEM vehicle of the plurality of OEM vehicles (Nayak: Para. 64-65; model or predict shape, distance from vehicle to the physical divider, and/or other attributes of the physical divider; predict a road characteristic related to the physical divider; probability of oncoming traffic, a presence of vulnerable road users).
Nayak doesn’t explicitly teach receive, from the plurality of OEM vehicles and via the network, vehicle operational data data relating to a plurality of vehicle-related events ………. (ii) to be executed based on a set of input data to generate a model output indicative of one or more recognized vehicle-related events at least at the long distance relative to the particular OEM vehicle (Dronen: Para. 11, 62; a high risk of mishappening to other vehicles in its vicinity, such as in the form of high collision possibility, vehicle swerving, vehicle breakdown, erratic driving); wherein a control system of the particular OEM vehicle is further configured to obtain the model output and selectively generate an alert for the one or more recognized vehicle-related events (Dronen: Para. 47, 89; sensor data from the vehicle detector, and the vehicle communication data from the V2V unit may then be fed to a local map generating unit; a single platform to provide a suite of mapping and navigation related applications for OEM devices).
However Dronen, in the same field of endeavor, teaches receive, from the plurality of OEM vehicles and via the network, vehicle operational data data relating to a plurality of vehicle-related events (Dronen: Para. 45; the data collected from the vehicles is transmitted to the OEM cloud) ………. (ii) to be executed based on a set of input data to generate a model output indicative of one or more recognized vehicle-related events at least at the long distance relative to the particular OEM vehicle; wherein a control system of the particular OEM vehicle is further configured to obtain the model output and selectively generate an alert for the one or more recognized vehicle-related events.
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 3, Nayak doesn’t explicitly teach wherein the control system for the particular OEM vehicle is further configured to determine a set of vehicle information indicative of a state of the particular OEM vehicle, wherein the set of vehicle information is the set of input data for the trained vehicle-related event recognization model.
However Dronen, in the same field of endeavor, teaches wherein the control system for the particular OEM vehicle is further configured to determine a set of vehicle information indicative of a state of the particular OEM vehicle, wherein the set of vehicle information is the set of input data for the trained vehicle-related event recognization model (Dronen: Para. 13, 40; characterizing, based on the processing of the local map by the second machine learning model, each of the one or more vehicles to output a navigation information for the ego vehicle; vehicles may be characterized into different risk categories, such as a high risk category, a medium risk category or a low risk category based on a risk factor associated with each vehicle; risk factor may be determined based on machine learning algorithms run on real-time vehicle data).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 4, Nayak doesn’t explicitly teach wherein the set of vehicle information includes at least one of (i) information captured by a set of perception sensors of the particular OEM vehicle and (ii) vehicle-to-anything (V2X) information obtained by the particular OEM vehicle.
However Dronen, in the same field of endeavor, teaches wherein the set of vehicle information includes at least one of (i) information captured by a set of perception sensors of the particular OEM vehicle and (ii) vehicle-to-anything (V2X) information obtained by the particular OEM vehicle (Dronen: Para. 89; sensor data from the vehicle detector, and the vehicle communication data from the V2V unit may then be fed to a local map generating unit).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 5, Nayak doesn’t explicitly teach wherein the plurality of vehicle-related events includes at least one of (i) accidents, (ii) police chases, (iii) public threats, (iv) careless driving, (v) roadside events, (vi) fire incidents, and (vii) natural disasters.
However Dronen, in the same field of endeavor, teaches wherein the plurality of vehicle-related events includes at least one of (i) accidents, (ii) police chases, (iii) public threats, (iv) careless driving, (v) roadside events, (vi) fire incidents, and (vii) natural disasters (Dronen: Para. 39; the probe data may also be captured from a fleet of vehicles including connected-car sensors, smartphones, personal navigation devices, fixed road sensors, smart-enabled commercial vehicles, and expert monitors observing accidents and construction).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 6, Nayak doesn’t explicitly teach wherein the computing server is further configured to provide the model output to a user device logged into an account or an application associated with the OEM.
However Dronen, in the same field of endeavor, teaches wherein the computing server is further configured to provide the model output to a user device logged into an account or an application associated with the OEM (Dronen: Para. 46; user equipment may be configured to execute and run mobile applications such as a messaging application, a browser application, a navigation application; user equipment may be coupled to the system via the OEM cloud 105 and the network).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 7, Nayak doesn’t explicitly teach wherein the model output includes a probability score indicative of a likelihood that a particular recognized vehicle-related event will be encountered by the particular OEM vehicle in the future, and wherein the control system for the particular OEM vehicle is further configured to generate the alert for the particular recognized vehicle-related event when its probability score satisfies a probability score threshold.
However Dronen, in the same field of endeavor, teaches wherein the model output includes a probability score indicative of a likelihood that a particular recognized vehicle-related event will be encountered by the particular OEM vehicle in the future (Dronen: Para. 62; vehicle is characterized with indicates a level of risk that the vehicle poses to other vehicles in its vicinity; a high risk category vehicle poses a high risk of mishappening to other vehicles in its vicinity, such as in the form of high collision possibility, vehicle swerving, vehicle breakdown, erratic driving), and wherein the control system for the particular OEM vehicle is further configured to generate the alert for the particular recognized vehicle-related event when its probability score satisfies a probability score threshold (Dronen: Para. 62, 83, 99; system may process the data in risk layer and may generate an awareness notification of this kind of dangerous situation; high risk category vehicle poses a high risk of mishappening to other vehicles in its vicinity; high or low degree may be determined based on probabilistic measures).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 8, Nayak teaches the vehicle-related event recognization and alert system of claim 1, wherein the long distance is a physical distance from the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Regarding claim 11, Nayak teaches a vehicle-related event recognization and alert method, the vehicle-related event recognization and alert method comprising: detecting, by each control system of a plurality of control systems of a plurality of original equipment manufacturer (OEM) vehicles, respectively, each OEM vehicle being associated with an OEM, a vehicle-related event in which an encounter between the OEM vehicle and one or more other objects occurred (Nayak: Para. 7; plurality of in-vehicle sensors installed in multiple vehicles traveling the road or from an original equipment manufacturer (OEM) cloud of the multiple vehicles; vehicular sensor data related to a number of positive observations of the physical divider by unique vehicles); verifying, by each control system, that the vehicle-related event is a valid vehicle- related event for training of a long range vehicle-related event recognization model (Nayak: Para. 7; one or more aggregated values generated from the categorical vehicular sensor data includes selected categorical values, using a voting algorithm, for each of the physical divider measurement event type, the physical divider flag); in response to verifying that the vehicle-related event is valid, transmitting, from each control system via a network, vehicle operational data relating to the vehicle-related event (Nayak: Para. 7; one or more aggregated values are collected over an extended period of time for use in training of the machine learning model for prediction of presence of the physical divider); receiving, by a computing server associated with the OEM and via the network (Nayak: Para. 36, 81; OEM cloud for the vehicles; processing needed by the machine learning model is provided on the server side) ……… ; training, by the computing server, the long range vehicle-related event recognization model based on the received vehicle operational data (Nayak: Para. 1, 36; using the trained machine learning model for predicting presence of one or more physical dividers on at least one segment of a road; train a machine learning model to predict physical dividers on a road segment of interest, based on map data associated with the segment of interest, vehicular sensor data collected from vehicles, an OEM cloud for the vehicles), wherein the trained long range vehicle-related event recognization model is configured to (i) recognize a plurality of different types of vehicle-related events at least at a long distance relative to a particular OEM vehicle of the plurality of OEM vehicles (Nayak: Para. 64-65; model or predict shape, distance from vehicle to the physical divider, and/or other attributes of the physical divider; predict a road characteristic related to the physical divider; probability of oncoming traffic, a presence of vulnerable road users).
Nayak doesn’t explicitly teach vehicle operational data relating to a plurality of vehicle-related events ……… (ii) to be executed based on a set of input data to generate a model output indicative of one or more recognized vehicle-related events at least at the long distance relative to the particular OEM vehicle; and obtaining, by a control system associated with the particular OEM vehicle, the model output and selectively generating, by the control system of the particular OEM vehicle, an alert for the one or more recognized vehicle-related events.
However Dronen, in the same field of endeavor, teaches vehicle operational data relating to a plurality of vehicle-related events (Dronen: Para. 45; the data collected from the vehicles is transmitted to the OEM cloud) ……… (ii) to be executed based on a set of input data to generate a model output indicative of one or more recognized vehicle-related events at least at the long distance relative to the particular OEM vehicle (Dronen: Para. 11, 62; a high risk of mishappening to other vehicles in its vicinity, such as in the form of high collision possibility, vehicle swerving, vehicle breakdown, erratic driving); and obtaining, by a control system associated with the particular OEM vehicle, the model output and selectively generating, by the control system of the particular OEM vehicle, an alert for the one or more recognized vehicle-related events (Dronen: Para. 47, 89; sensor data from the vehicle detector, and the vehicle communication data from the V2V unit may then be fed to a local map generating unit; a single platform to provide a suite of mapping and navigation related applications for OEM devices).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 13, Nayak doesn’t explicitly teach further comprising determining, by the control system for the particular OEM vehicle, a set of vehicle information indicative of a state of the for the particular OEM vehicle, wherein the set of vehicle information is the set of input data for the trained vehicle-related event recognization model.
However Dronen, in the same field of endeavor, teaches further comprising determining, by the control system for the particular OEM vehicle, a set of vehicle information indicative of a state of the for the particular OEM vehicle, wherein the set of vehicle information is the set of input data for the trained vehicle-related event recognization model (Dronen: Para. 13, 40; characterizing, based on the processing of the local map by the second machine learning model, each of the one or more vehicles to output a navigation information for the ego vehicle; vehicles may be characterized into different risk categories, such as a high risk category, a medium risk category or a low risk category based on a risk factor associated with each vehicle; risk factor may be determined based on machine learning algorithms run on real-time vehicle data).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 14, Nayak doesn’t explicitly teach wherein the set of vehicle information includes at least one of (i) information captured by a set of perception sensors of the particular OEM vehicle and (ii) vehicle-to-anything (V2X) information obtained by the particular OEM vehicle.
However Dronen, in the same field of endeavor, teaches wherein the set of vehicle information includes at least one of (i) information captured by a set of perception sensors of the particular OEM vehicle and (ii) vehicle-to-anything (V2X) information obtained by the particular OEM vehicle (Dronen: Para. 89; sensor data from the vehicle detector, and the vehicle communication data from the V2V unit may then be fed to a local map generating unit).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 15 Nayak doesn’t explicitly teach wherein the plurality of vehicle-related events includes at least one of (i) accidents, (ii) police chases, (iii) public threats, (iv) careless driving, (v) roadside events, (vi) fire incidents, and (vii) natural disasters.
However Dronen, in the same field of endeavor, teaches wherein the plurality of vehicle-related events includes at least one of (i) accidents, (ii) police chases, (iii) public threats, (iv) careless driving, (v) roadside events, (vi) fire incidents, and (vii) natural disasters (Dronen: Para. 39; the probe data may also be captured from a fleet of vehicles including connected-car sensors, smartphones, personal navigation devices, fixed road sensors, smart-enabled commercial vehicles, and expert monitors observing accidents and construction).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 16, Nayak doesn’t explicitly teach further comprising providing, by the computing server, the model output to a user device logged into an account or an application associated with the OEM.
However Dronen, in the same field of endeavor, teaches further comprising providing, by the computing server, the model output to a user device logged into an account or an application associated with the OEM (Dronen: Para. 46; user equipment may be configured to execute and run mobile applications such as a messaging application, a browser application, a navigation application; user equipment may be coupled to the system via the OEM cloud and the network).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 17, Nayak doesn’t explicitly teach wherein the model output includes a probability score indicative of a likelihood that a particular recognized vehicle-related event will be encountered by the particular OEM vehicle in the future, and wherein the generating of the alert for the particular recognized vehicle-related event is performed when its probability score satisfies a probability score threshold.
However Dronen, in the same field of endeavor, teaches wherein the model output includes a probability score indicative of a likelihood that a particular recognized vehicle-related event will be encountered by the particular OEM vehicle in the future (Dronen: Para. 62; vehicle is characterized with indicates a level of risk that the vehicle poses to other vehicles in its vicinity; a high risk category vehicle poses a high risk of mishappening to other vehicles in its vicinity, such as in the form of high collision possibility, vehicle swerving, vehicle breakdown, erratic driving), and wherein the generating of the alert for the particular recognized vehicle-related event is performed when its probability score satisfies a probability score threshold (Dronen: Para. 62, 83, 99; system may process the data in risk layer and may generate an awareness notification of this kind of dangerous situation; high risk category vehicle poses a high risk of mishappening to other vehicles in its vicinity; high or low degree may be determined based on probabilistic measures).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Regarding claim 18, Nayak teaches the vehicle-related event recognization and alert method of claim 17, wherein the long distance is a physical distance from the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Regarding claim 21, Nayak teaches the vehicle-related event recognization and alert system of claim 7, wherein the long distance is a time period in advance of the future encounter with the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Regarding claim 22, Nayak teaches the vehicle-related event recognization and alert system of claim 21, wherein the long distance is a combination of (i) the time period in advance of the future encounter with the particular OEM vehicle and (ii) a physical distance from the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Regarding claim 23, Nayak teaches the vehicle-related event recognization and alert method of claim 17, wherein the long distance is a time period in advance of the future encounter with the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Regarding claim 24, Nayak teaches the vehicle-related event recognization and alert method of claim 23, wherein the long distance is a combination of (i) the time period in advance of the future encounter with the particular OEM vehicle and (ii) a physical distance from the particular OEM vehicle (Nayak: Para. 73; present a notification to the driver; notification can alert the driver that a change in the autonomous mode will occur shortly (e.g., within a specified period of time)).
Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Nayak et al. (US Publication 2020/0167575 A1) in view of Dronen et al. (US Publication 2022/0203973 A1) and in further view of Kim et al. (US Publication 2024/0375642 A1).
Regarding claim 9, Nayak teaches the vehicle-related event recognization and alert system of claim 7, wherein the alert includes at least one of a visual alert, an audio alert, and a haptic alert wherein the alert includes at least one of a visual alert, an audio alert, and a haptic alert (Nayak: Para. 73; present a notification to the driver or occupant of the vehicle).
Nayak doesn’t explicitly teach wherein the control system for the particular OEM vehicle is further configured to generate and output different alerts for different recognized vehicle-related events.
However Dronen, in the same field of endeavor, teaches wherein the control system for the particular OEM vehicle is further configured to generate and output different alerts for different recognized vehicle-related events (Dronen: Para. 62, 83; navigation information as output data that may be provided to the user of the vehicle 503 based on the risk factor associated with the plurality of vehicles 505a-505d around the vehicle 501, and surrounding environment of the vehicle; a vehicle is characterized with indicates a level of risk that the vehicle poses to other vehicles in its vicinity; high collision possibility, vehicle swerving, vehicle breakdown, erratic driving).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Nayak and Dronen don’t explicitly teach wherein more intense alerts are provided for more severe recognized vehicle-related events.
However Kim, in the same field of endeavor, teaches wherein more intense alerts are provided for more severe recognized vehicle-related events (Kim: Para. 139; as the warning level increases, auditory alerts may have a louder sound level).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) and the with louder sound level with increased warning level (Kim: Para. 139) with a reasonable expectation of success because providing escalating auditory or haptic warnings to the user attempts to gain the user’s attention as the warning level escalates (Kim: Para. 108).
Regarding claim 19, Nayak teaches the vehicle-related event recognization and alert method of claim 17, wherein the alert includes at least one of a visual alert, an audio alert, and a haptic alert (Nayak: Para. 73; present a notification to the driver or occupant of the vehicle).
Nayak doesn’t explicitly teach further comprising generating and outputting, by the control system of the particular OEM, different alerts for different recognized vehicle-related events.
However Dronen, in the same field of endeavor, teaches further comprising generating and outputting, by the control system of the particular OEM, different alerts for different recognized vehicle-related events (Dronen: Para. 62, 83; navigation information as output data that may be provided to the user of the vehicle 503 based on the risk factor associated with the plurality of vehicles 505a-505d around the vehicle 501, and surrounding environment of the vehicle; a vehicle is characterized with indicates a level of risk that the vehicle poses to other vehicles in its vicinity; high collision possibility, vehicle swerving, vehicle breakdown, erratic driving).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) with a reasonable expectation of success because machine learning algorithms with real-time V2V data determines vehicle characterization data and associated risk data to identify risks posed by various vehicles within that region of road and alert the driver of an upcoming dangerous situation (Dronen: Para. 35, 40).
Nayak and Dronen don’t explicitly teach wherein more intense alerts are provided for more severe recognized vehicle-related events.
However Kim, in the same field of endeavor, teaches wherein more intense alerts are provided for more severe recognized vehicle-related events (Kim: Para. 139; as the warning level increases, auditory alerts may have a louder sound level).
It would have been obvious to one having ordinary skill in the art to modify the OEM cloud machine learning model (Nayak: Para. 7) with the OEM cloud mapping and navigation platform for OEM devices (Dronen: Para. 47) and the with louder sound level with increased warning level (Kim: Para. 139) with a reasonable expectation of success because providing escalating auditory or haptic warnings to the user attempts to gain the user’s attention as the warning level escalates (Kim: Para. 108).
Response to Arguments
Applicant’s arguments, filed 3 April 2026, with respect to the rejection of claims 1-9 and 11-19 under 35 U.S.C. 102 have been fully considered. The rejection has been withdrawn. Claims 1, 3-9, 11, 13-19, 21-24 are currently rejected under 35 U.S.C. 103.
The applicant argues that Dronen fails to teach “verify[ing] that the vehicle-related event is a valid vehicle-related event for training a long range vehicle-related event recognization model” or “the trained long range vehicle-related event recognization model is configured to ……. recognize a plurality of different types of vehicle-related events at least at a long distance relative to a particular OEM vehicle”.
In response to the applicant’s argument above, the limitations argued above are moot because they do not apply to the prior art used in this rejection.
Applicant next argues that the remainder of the claims depend from one of the independent claims, all of the pending claims should be in condition for allowance for at least similar reasons.,
In response to the applicant’s argument above, the independent claims are rejected. All dependent claims are rejected at least based on their dependencies.
Applicant next argues that claims 21-24 define features that are neither disclose or suggested by the art of record for at least similar reasons as those presented in detail above.
In response to the applicant’s argument above, applicant only presented mere allegations without substantive support. The examiner has provided a rejection explaining the rejection of the claims 21-24. Mere allegations without substantive support/reasoning do not require any significant response from the examiner. The reasons presented in detail above were addressed above by the examiner.
The applicant’s arguments have failed to point out the distinguishing characteristics of the amended claim language over the prior art. For the above reasons, Nayak’s OEM vehicle server based machine learning in view of Dronen’s reads on applicant’s steering kickback. The rejection is maintained.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAURA E LINHARDT whose telephone number is (571)272-8325. The examiner can normally be reached on M-TR, M-F: 8am-4pm.
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, Angela Ortiz can be reached on (571) 272-1206. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/L.E.L./Examiner, Art Unit 3663
/ANGELA Y ORTIZ/Supervisory Patent Examiner, Art Unit 3663
Prosecution Insights