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-20 filed on 01/22/2024 have been examined.
This Office Action is in response to the Applicant’s amendments and remarks filed on 02/18/2026. Claims 1, 10, and 19 have been amended. Claims 1-20 are currently pending and addressed below.
Response to Remarks/Arguments
Applicant’s accompanying amendments and arguments, on pages 9-12 of the Applicant Arguments/Remarks (hereinafter referred to as the “Remarks”), filed 02/18/2026, with respect to the rejection of claims independent claims 1, 10, and 19 and their corresponding dependent claims under 35 U.S.C. 101 stating “… the Examiner asserts that claims 1, 10, and 19 recite the abstract idea metal processes. Applicant respectfully disagrees…Even if the claims were considered to recite an abstract idea, they are integrated into a practical application because they improve a specific technological process, namely efficient identification, storage, and retrieval of vehicle event data. As described in the Specification, the claimed systems and methods can carefully collect[] and analyz[e] data generated during vehicle operation. Specification, [0023]. In conventional approaches [a]s the volume of data collected grows, it can become increasingly difficult to quickly and effectively isolate portions of the data that are relevant for certain development tasks and portions of the data are unnecessarily duplicated and, in turn, consume computing resources unnecessarily. Specification, [0004]. The Specification further states the claimed systems and methods can interact with one another to quickly and efficiently request and provide data associated with the operation of at least one vehicle. Specification, [0004]… This is not merely linking of the alleged abstract idea to a technological field and instead the claims improve the collection and analyzation of vehicle event data to more accurately identify relevant events. Like USPTO Example 48, claim 2, which is identified as eligible because the alleged mathematical and potential mental process steps were integrated into a practical application, the present claims are likewise eligible. Specifically, both claim 2 and the present claims (1) acquire real-world data from specific sensors attached to a particular machine, (2) execute a specialized trained model to transform that data into precise, structured information, and (3) apply that information to produce an improved output in a defined technical field. For example, in Example 48, the output was a cleaned speech signal for improved audio source separation. Here, the claims recite the output as a user interface including only precise, synchronized data representing relevant vehicle events, solving known latency and storage problems in vehicle data analysis. Therefore, the claims are integrated into a practical application under Step 2A, Two… For these reasons, Applicant respectfully requests reconsideration and withdrawal of the rejection of claims 1-20 under 35 U.S.C. § 101…” have been considered and are persuasive. The Examiner further notes, in addition to the arguments presented by the applicant above, that the claimed invention is analogous to Example 48, claim 2, because the claimed invention generates event data by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index, thus excluding undesired time segments of data that are not of interest for the set of events to output only precise, synchronized data representing relevant vehicle events to solve known latency and storage problems in vehicle data analysis. Moreover, the claimed invention reflects the improvement described in the disclosure and integrates the abstract idea into a practical application under Step 2A, Prong Two so the claim is eligible. Therefore, the Examiner has withdrawn the rejection of the claims under 35 U.S.C. 101.
Applicant’s accompanying amendments and arguments, on pages 12-14 of the Applicant Remarks, filed 02/18/2026, with respect to the rejection of claims independent claims 1, 10, and 19 and their corresponding dependent claims under 35 U.S.C. 103 stating “… Claim 1 is amended to recite, in pertinent part: structure the data into a metadata index comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle; …generate event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index; … Srinivasan does not teach or suggest structure the data into a metadata index comprising a plurality of time-synchronized arrays corresponding to the data associated with operation of the at least one vehicle as recited in independent claim 1… Further, Srinvasan does not teach or suggest generate event data ...by retrieving...only those time segments corresponding to the set of events identified using the metadata index as recited in independent claim 1… Srinivasan neither teaches nor a suggests using a metadata index or any rule for retrieving only those time segments corresponding to the set of events identified using the metadata index… As such, claim 1 is patentable over the references of record… Claims 10 and 19 are amended in a manner similar to claim 1. As such, Applicant respectfully submits that claims 10 and 19 are patentable over the references of record for at least the same reasons as those set forth with respect to amended independent claim 1. Accordingly, Applicant requests reconsideration and withdrawal of the rejection of claims 1-20 under 35 U.S.C. § 103 in view of Srinivasan and Calmer…” have been considered but are moot due to the amendments and added limitations provided above. Upon further consideration, a new ground(s) of rejection is made in view of Lagorce US 20220101640 A1 (“Lagorce”).
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Srinivasan et al. US 11352013 B1 in view of Lagorce US 20220101640 A1 (“Lagorce”) and Calmer et al. US 11643102 B1 (“Calmer”).
For claim 1, Srinivasan discloses a system for identifying subsets of data in a dataset (See at least Col. 11 lines 49-64 of Srinivasan – “…the vehicle device and/or the event analysis system may implement certain machine learning techniques that are configured to identify features within sensor data, such as in images from one or more of the outward-facing or inward-facing cameras of the vehicle device, audio detected by one or more microphones of the vehicle device, metadata from other sensors, and the like…”), the system comprising:
at least one processor (See at least Col. 11 lines 49-64 of Srinivasan – “…The feature detection may be performed by a feature detection module (e.g., part of the vehicle device and/or the event detection system), which may include program code executable by one or more processors…”) programmed to:
receive, from a set of sensors (See at least the Abstract of Srinivasan – “… A vehicle device may execute one or more neural networks … based on input from one or more of the cameras and/or other sensors … to intelligently detect safety events in real-time…”), data associated with operation of at least one vehicle in an environment, the operation of the at least one vehicle occurring during at least one period of time (See at least Col. 23 lines 23-37 of Srinivasan – “… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period… may indicate that asset data is requested only for the first 5 occurrence of harsh turning events.. Thus, the event analysis system receives additional asset data for some of the harsh turning events and preserves bandwidth and reduces costs by not requesting asset data for all of the harsh turning events, due to the limited value of analyzing the additional asset data associated with a recurring triggered safety event…”);
scan the metadata index to determine a plurality of events that occurred during the at least one period of time based on the operation of the at least one vehicle in the environment, each event of the plurality of events having an event type (See at least Col. 15 lines 54-67 through Col. 16 lines 1-11 of Srinivasan – “…sensor data (e.g., video data) is stored for processing by one or more event models… video data and metadata from one or more sensors may be stored for a particular time period … one or more event models are executed on the sensor data, which may be accessible via the sensor data store 206. In some embodiments, the event models executed at block 210 are configured to identify harsh events indicative of a sudden, extreme, and/or unexpected movement of the vehicle… In addition, or as an alternative, to detection of harsh events, the vehicle device 114 advantageously executes one or more event models (e.g., neural networks) on sensor data, such as video data, to detect safety events, such as a tailgating, forward collision risk, and/or distracted driver event …”);
receive, from a computing device, data associated with a request, the request specifying one or more event types (See at least Col. 22 lines 43-67 through Col. 23 lines 1-17 of Srinivasan – “… the event analysis system receives the event data 219, which may initially be only metadata associated with a detected event… event data associated with a tailgating event may be analyzed using a tailgating model in the event analysis system that is more sophisticated than the tailgating model used in the vehicle device… the event models applied in the event analysis system may require additional event data beyond the initial event data received upon triggering of the safety event at the vehicle device… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type …the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 … This process may be repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
determine a set of events from among the plurality of events based on the one or more event types specified by the request, each event from the set of events occurring at points in time associated with the at least one period of time (See at least Col. 21 line 19 through Col. 23 line 22 of Srinivasan – “…The rules may further indicate that occurrence of the same safety event within a subsequent time period (e.g., 1 minute, 30 minutes, 60 minutes, etc.) causes event data 219 regarding both of the detected events to be transmitted to the event analysis system. Similarly, rules may be established to transmit event data 219 only upon occurrence of other quantities of safety events (e.g., three, four, five, etc.) during other time periods … the video data (and/or other types of asset data) may be compiled into a single video file that includes all of the detected events throughout the roll up time period… the event analysis system may receive a single video file that is a hyper-lapse showing frames from all of the safety events… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time in accordance with rules for transmitting additional data… specific asset data is requested by the event analysis system, such as a particular time period of requested video or audio data… the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
generate event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events (See at least Col. 23 lines 7-37 of Srinivasan – “… At block 230, additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time … requested by the event analysis system, such as a particular time period of requested video or audio data… Upon receipt of the additional event data 219 at the event analysis system, the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided... the event analysis system applies default and/or user configurable rules to determine which asset data is requested from the vehicle device… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period…”); and
transmit the event data to the computing device associated with the request (See at least Col. 24 line 56 through Col. 25 line 10 of Srinivasan – “…The backend server may transmit the probability (e.g., the probability of the occurrence of the particular feature and/or the probability of the event) determined by the backend server to the vehicle device… the backend server may provide an indication of the comparison of the two probabilities to the vehicle device…”).
Srinivasan fails to specifically disclose structure the data into a metadata index comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle;
generate event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index.
However, Lagorce, in the same field of endeavor teaches structure the data into a metadata index (See at least [0066] of Lagorce – “… The data structure may contain one or more of the following items forming the event data for a pixel having an address expressed as an index i, and coordinates (x.sub.i, y.sub.i) in the array…”) comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…” and [0102] of Lagorce – “… the event-based sensor 10 and the processor(s) 12 is used in an automobile to detect and track objects on the roads, such as traffic light, moving objects, etc., so as to provide these dynamic information to autonomous driving system…”);
generate event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Lagorce teaches a system for an autonomous vehicle that processes event based information structured in an index with time-stamped arrays and disregards data not belonging to a time requirement for identifying an event.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of structuring the data into a metadata index comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle as taught by Lagorce, with a reasonable expectation of success, in order to disregard data not meeting a timing requirement for identifying events as specified in at least [0076] of Lagorce.
Furthermore, Srinivasan also fails to specifically disclose the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle.
However, Calmer, in the same field of endeavor teaches the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle (See at least Col. 12 lines 41-57 of Calmer – “…FIG. 4 is an example user interface that may be provided to the user as part of the safety dashboard, such as via a web enabled interface that is viewed on a desktop, portable, or mobile device. This example user interface illustrates asset data associated with a tailgating alert…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Calmer teaches a safety even detection system for a vehicle that provides a user interface to alert a driver or safety manager of a safety risk identified.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle as taught by Calmer, with a reasonable expectation of success, in order to provide an alert to a user where an action may be prudent as specified in at least Col. 12 lines 41-57 of Calmer.
For claim 2, Srinivasan discloses wherein the request specifies at least one event type corresponding to a change in a state of the at least one vehicle (See at least Col. 19 lines 13-39 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events…”), and
wherein, when determining the plurality of events, the at least one processor is programmed to:
determine the change in the state of the at least one vehicle during the at least one period of time (See at least Col. 19 lines 13-53 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events… the displayed data is synchronized, such that each of the outward-facing video 520, inward-facing video 522, map view 518, and time series graph 516 each depict information associated with a same point in time (e.g., a particular time during the ten seconds of event data associated with a detected safety event…”).
For claim 3, Srinivasan discloses wherein, when determining the plurality of events, the at least one processor is programmed to:
determine a presence of one or more scenarios, agents, or objects in the environment at points in time during the at least one period of time (See at least Col. 20 lines 53 through Col. 21 line 18 of Srinivasan – “… the event data 219 that is transmitted to the event analysis system upon detection of a driver assistance alert… metadata that is transmitted to the event analysis system may include location of the object that triggered the event, such as the lead vehicle in the case of a forward collision warning or tailgating, or the head of the driver in the case of a distracted driver event… The rules may further indicate that occurrence of the same safety event within a subsequent time period (e.g., 1 minute, 30 minutes, 60 minutes, etc.) causes event data 219 regarding both of the detected events to be transmitted to the event analysis system. Similarly, rules may be established to transmit event data 219 only upon occurrence of other quantities of safety events (e.g., three, four, five, etc.) during other time periods…”).
For claim 4, Srinivasan discloses wherein, when generating the event data associated with the operation of the at least one vehicle in the environment, the at least one processor is programmed to:
generate the event data based on the set of events and the data generated during the operation of the at least one vehicle at the points in time corresponding to an occurrence of each event in the set of events (See at least Col. 23 lines 7-37 of Srinivasan – “… At block 230, additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time … requested by the event analysis system, such as a particular time period of requested video or audio data… Upon receipt of the additional event data 219 at the event analysis system, the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided... the event analysis system applies default and/or user configurable rules to determine which asset data is requested from the vehicle device… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period…”).
For claim 5, Srinivasan discloses wherein the at least one processor is further programmed to:
determine a trigger based on the request (See at least Col. 22 line 43 through Col. 23 line 6 of Srinivasan – “…at block 210 high-fidelity event detection models, such as higher precision neural networks than are executed on the vehicle device, may be executed to determine whether the triggered event was accurately detected… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type. Thus, the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device...”), the trigger configured to cause a computing device installed in the at least one vehicle to store the data associated with the operation of the at least one vehicle in the environment (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event …”); and
provide data associated with the trigger to the at least one vehicle, the data associated with the trigger configured to cause the trigger to be implemented by the computing device installed in the at least one vehicle (See at least Col. 23 lines 38-56 of Srinivasan – “… the event analysis system evaluates asset data that was not considered by the vehicle device in triggering the initial safety event. The event analysis system may provide suggestions and/or may automatically update event models that are restricted to analysis of certain event data (e.g., event metadata and/or certain types of asset data) based on analysis of asset data that is not analyzed by the updated event model. For example, analysis of video data associated with a safety event may identify correlations between features in the video data and acceleration data that may be used to update criteria or thresholds for triggering the particular safety event by the vehicle device. Advantageously, the event analysis system may consider event data across massive quantities of vehicles in determining updates to the event models that are executed on the vehicle device…”).
For claim 6, Srinivasan discloses wherein the at least one processor is further programmed to:
receive the data associated with the operation of the at least one vehicle in the environment based on providing the data associated with the trigger to the at least one vehicle (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event… the asset data may be later transmitted when the communication link supports transmission of the asset data, such as when the vehicle is within a geographic area with a high cellular data speed…”).
For claim 7, Srinivasan discloses wherein the at least one processor is further programmed to:
determine a trigger based on the request (See at least Col. 22 line 43 through Col. 23 line 6 of Srinivasan – “…at block 210 high-fidelity event detection models, such as higher precision neural networks than are executed on the vehicle device, may be executed to determine whether the triggered event was accurately detected… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type. Thus, the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device...”), the trigger configured to cause a computing device installed in the at least one vehicle to store the data associated with the operation of the at least one vehicle in the environment (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event …”); and
determine whether the trigger satisfies a probability threshold based on applying the trigger to the data associated with the operation of the at least one vehicle in the environment (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may determine if a safety event is triggered based on the probability of the event output by the one or more machine learning models. For example, the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number… may determine if a safety event has been triggered based on a probability output by the one or more machine learning models...”).
For claim 8, Srinivasan discloses wherein the at least one processor is further programmed to:
provide data associated with the trigger to the at least one vehicle, the data associated with the trigger configured to cause the trigger to be implemented by the computing device installed in the at least one vehicle based on determining that the trigger satisfies the probability threshold (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may determine if a safety event is triggered based on the probability of the event output by the one or more machine learning models. For example, the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number. If the vehicle device determines the probability satisfies the prediction number, the vehicle device may determine an event has occurred and if the vehicle device determines the probability does not satisfy the prediction number, the vehicle device may determine an event has not occurred. Therefore, the vehicle device may determine if a safety event has been triggered based on a probability output by the one or more machine learning models…”).
For claim 9, Srinivasan discloses wherein the at least one processor is further programmed to:
update the trigger based on determining that the trigger does not satisfy the probability threshold (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number… if the vehicle device determines the probability does not satisfy the prediction number, the vehicle device may determine an event has not occurred …”); and
provide the data associated with the trigger to the at least one vehicle based on updating the trigger, the data associated with the trigger configured to cause the trigger to be implemented by the computing device installed in the at least one vehicle (See at least Col. 27 lines 38-60 of Srinivasan – “… If the vehicle device determines a safety event has been triggered, at block 214, the vehicle device may generate and/or provide an in-vehicle alert within the vehicle. Further, at block 216, based on identifying the occurrence of a safety event, the vehicle device may send metadata and limited asset data to the event analysis system… the vehicle device may send metadata and limited asset data to the event analysis system based on identifying the non-occurrence of a safety event. For example, the vehicle device may periodically or aperiodically send metadata and limited asset data to the event analysis system regardless of whether an event has been identified in order to confirm that the vehicle device is correctly identifying events and correctly identifying non-events (e.g., the non-occurrence of events). Therefore, the vehicle device can send metadata and limited asset data to the event analysis system if an event has been triggered or if an event has not been triggered …”).
For claim 10, Srinivasan discloses a computer-implemented method (See at least Col. 11 lines 49-64 of Srinivasan – “…the vehicle device and/or the event analysis system may implement certain machine learning techniques that are configured to identify features within sensor data, such as in images from one or more of the outward-facing or inward-facing cameras of the vehicle device, audio detected by one or more microphones of the vehicle device, metadata from other sensors, and the like…”), comprising:
receiving, by at least one processor from a set of sensors (See at least the Abstract of Srinivasan – “… A vehicle device may execute one or more neural networks … based on input from one or more of the cameras and/or other sensors … to intelligently detect safety events in real-time…”), data associated with operation of at least one vehicle in an environment, the operation of the at least one vehicle occurring during at least one period of time (See at least Col. 23 lines 23-37 of Srinivasan – “… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period… may indicate that asset data is requested only for the first 5 occurrence of harsh turning events.. Thus, the event analysis system receives additional asset data for some of the harsh turning events and preserves bandwidth and reduces costs by not requesting asset data for all of the harsh turning events, due to the limited value of analyzing the additional asset data associated with a recurring triggered safety event…”);
scanning, by the at least one processor, the metadata index to determining, by the at least one processor, a plurality of events that occurred during the at least one period of time based on the operation of the at least one vehicle in the environment, each event of the plurality of events having an event type (See at least Col. 15 lines 54-67 through Col. 16 lines 1-11 of Srinivasan – “…sensor data (e.g., video data) is stored for processing by one or more event models… video data and metadata from one or more sensors may be stored for a particular time period … one or more event models are executed on the sensor data, which may be accessible via the sensor data store 206. In some embodiments, the event models executed at block 210 are configured to identify harsh events indicative of a sudden, extreme, and/or unexpected movement of the vehicle… In addition, or as an alternative, to detection of harsh events, the vehicle device 114 advantageously executes one or more event models (e.g., neural networks) on sensor data, such as video data, to detect safety events, such as a tailgating, forward collision risk, and/or distracted driver event …”);
receiving, by the at least one processor and from a computing device, data associated with a request, the request specifying one or more event types (See at least Col. 22 lines 43-67 through Col. 23 lines 1-17 of Srinivasan – “… the event analysis system receives the event data 219, which may initially be only metadata associated with a detected event… event data associated with a tailgating event may be analyzed using a tailgating model in the event analysis system that is more sophisticated than the tailgating model used in the vehicle device… the event models applied in the event analysis system may require additional event data beyond the initial event data received upon triggering of the safety event at the vehicle device… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type …the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 … This process may be repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
determining, by the at least one processor, a set of events from among the plurality of events based on the one or more event types specified by the request, each event from the set of events occurring at points in time associated with the at least one period of time (See at least Col. 21 line 19 through Col. 23 line 22 of Srinivasan – “…The rules may further indicate that occurrence of the same safety event within a subsequent time period (e.g., 1 minute, 30 minutes, 60 minutes, etc.) causes event data 219 regarding both of the detected events to be transmitted to the event analysis system. Similarly, rules may be established to transmit event data 219 only upon occurrence of other quantities of safety events (e.g., three, four, five, etc.) during other time periods … the video data (and/or other types of asset data) may be compiled into a single video file that includes all of the detected events throughout the roll up time period… the event analysis system may receive a single video file that is a hyper-lapse showing frames from all of the safety events… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time in accordance with rules for transmitting additional data… specific asset data is requested by the event analysis system, such as a particular time period of requested video or audio data… the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
generating, by the at least one processor, event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events (See at least Col. 23 lines 7-37 of Srinivasan – “… At block 230, additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time … requested by the event analysis system, such as a particular time period of requested video or audio data… Upon receipt of the additional event data 219 at the event analysis system, the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided... the event analysis system applies default and/or user configurable rules to determine which asset data is requested from the vehicle device… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period…”); and
transmitting the event data to the computing device associated with the request (See at least Col. 24 line 56 through Col. 25 line 10 of Srinivasan – “…The backend server may transmit the probability (e.g., the probability of the occurrence of the particular feature and/or the probability of the event) determined by the backend server to the vehicle device… the backend server may provide an indication of the comparison of the two probabilities to the vehicle device…”).
Srinivasan fails to specifically disclose structuring, by the at least one processor, the data into a metadata index comprising a plurality of time-synchronized arrays corresponding to the data associated with operation of the at least one vehicle;
generating, by the at least one processor, event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index.
However, Lagorce, in the same field of endeavor teaches structuring, by the at least one processor, the data into a metadata index (See at least [0066] of Lagorce – “… The data structure may contain one or more of the following items forming the event data for a pixel having an address expressed as an index i, and coordinates (x.sub.i, y.sub.i) in the array…”) comprising a plurality of time-synchronized arrays corresponding to the data associated with operation of the at least one vehicle (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…” and [0102] of Lagorce – “… the event-based sensor 10 and the processor(s) 12 is used in an automobile to detect and track objects on the roads, such as traffic light, moving objects, etc., so as to provide these dynamic information to autonomous driving system…”);
generating, by the at least one processor, event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Lagorce teaches a system for an autonomous vehicle that processes event based information structured in an index with time-stamped arrays and disregards data not belonging to a time requirement for identifying an event.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of structuring the data into a metadata index comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle as taught by Lagorce, with a reasonable expectation of success, in order to disregard data not meeting a timing requirement for identifying events as specified in at least [0076] of Lagorce.
Furthermore, Srinivasan also fails to specifically disclose the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle.
However, Calmer, in the same field of endeavor teaches the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle (See at least Col. 12 lines 41-57 of Calmer – “…FIG. 4 is an example user interface that may be provided to the user as part of the safety dashboard, such as via a web enabled interface that is viewed on a desktop, portable, or mobile device. This example user interface illustrates asset data associated with a tailgating alert…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Calmer teaches a safety even detection system for a vehicle that provides a user interface to alert a driver or safety manager of a safety risk identified.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle as taught by Calmer, with a reasonable expectation of success, in order to provide an alert to a user where an action may be prudent as specified in at least Col. 12 lines 41-57 of Calmer.
For claim 11, Srinivasan discloses wherein, the request specifies at least one event type corresponding to a change in a state of the at least one vehicle (See at least Col. 19 lines 13-39 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events…”), and
wherein determining the plurality of events comprises:
determining the change in the state of the at least one vehicle during the at least one period of time (See at least Col. 19 lines 13-53 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events… the displayed data is synchronized, such that each of the outward-facing video 520, inward-facing video 522, map view 518, and time series graph 516 each depict information associated with a same point in time (e.g., a particular time during the ten seconds of event data associated with a detected safety event…”).
For claim 12, Srinivasan discloses wherein determining the plurality of events comprises:
determining a presence of one or more scenarios, agents, or objects in the environment at points in time during the at least one period of time (See at least Col. 20 lines 53 through Col. 21 line 18 of Srinivasan – “… the event data 219 that is transmitted to the event analysis system upon detection of a driver assistance alert… metadata that is transmitted to the event analysis system may include location of the object that triggered the event, such as the lead vehicle in the case of a forward collision warning or tailgating, or the head of the driver in the case of a distracted driver event… The rules may further indicate that occurrence of the same safety event within a subsequent time period (e.g., 1 minute, 30 minutes, 60 minutes, etc.) causes event data 219 regarding both of the detected events to be transmitted to the event analysis system. Similarly, rules may be established to transmit event data 219 only upon occurrence of other quantities of safety events (e.g., three, four, five, etc.) during other time periods…”).
For claim 13, Srinivasan discloses wherein generating the event data associated with the operation of the at least one vehicle in the environment comprises:
generating the event data based on the set of events and the data generated during the operation of the at least one vehicle at the points in time corresponding to an occurrence of each event in the set of events (See at least Col. 23 lines 7-37 of Srinivasan – “… At block 230, additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time … requested by the event analysis system, such as a particular time period of requested video or audio data… Upon receipt of the additional event data 219 at the event analysis system, the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided... the event analysis system applies default and/or user configurable rules to determine which asset data is requested from the vehicle device… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period…”).
For claim 14, Srinivasan discloses further comprising:
determining, by the at least one processor, a trigger based on the request (See at least Col. 22 line 43 through Col. 23 line 6 of Srinivasan – “…at block 210 high-fidelity event detection models, such as higher precision neural networks than are executed on the vehicle device, may be executed to determine whether the triggered event was accurately detected… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type. Thus, the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device...”), the trigger configured to cause a computing device installed in the at least one vehicle to store the data associated with the operation of the at least one vehicle in the environment (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event …”); and
providing, by the at least one processor, data associated with the trigger to the at least one vehicle to cause the trigger to be implemented by the computing device installed in the at least one vehicle (See at least Col. 23 lines 38-56 of Srinivasan – “… the event analysis system evaluates asset data that was not considered by the vehicle device in triggering the initial safety event. The event analysis system may provide suggestions and/or may automatically update event models that are restricted to analysis of certain event data (e.g., event metadata and/or certain types of asset data) based on analysis of asset data that is not analyzed by the updated event model. For example, analysis of video data associated with a safety event may identify correlations between features in the video data and acceleration data that may be used to update criteria or thresholds for triggering the particular safety event by the vehicle device. Advantageously, the event analysis system may consider event data across massive quantities of vehicles in determining updates to the event models that are executed on the vehicle device…”).
For claim 15, Srinivasan discloses further comprising:
receiving, by the at least one processor, the data associated with the operation of the at least one vehicle in the environment based on providing the data associated with the trigger to the at least one vehicle (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event… the asset data may be later transmitted when the communication link supports transmission of the asset data, such as when the vehicle is within a geographic area with a high cellular data speed…”).
For claim 16, Srinivasan discloses further comprising:
determining, by the at least one processor, a trigger based on the request See at least Col. 22 line 43 through Col. 23 line 6 of Srinivasan – “…at block 210 high-fidelity event detection models, such as higher precision neural networks than are executed on the vehicle device, may be executed to determine whether the triggered event was accurately detected… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type. Thus, the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device...”), the trigger configured to cause a computing device installed in the at least one vehicle to store the data associated with the operation of the at least one vehicle in the environment (See at least Col. 22 lines 10-17 of Srinivasan – “… asset data, such as video and audio data, are recorded in the sensor data store 206, even though such asset data may not be transmitted to the event analysis system initially upon triggering of a safety event …”); and
determining, by the at least one processor, whether the trigger satisfies a probability threshold based on applying the trigger to the data associated with the operation of the at least one vehicle in the environment (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may determine if a safety event is triggered based on the probability of the event output by the one or more machine learning models. For example, the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number… may determine if a safety event has been triggered based on a probability output by the one or more machine learning models...”).
For claim 17, Srinivasan discloses further comprising:
providing, by the at least one processor, data associated with the trigger to the at least one vehicle to cause the trigger to be implemented by the computing device installed in the at least one vehicle based on determining that the trigger satisfies the probability threshold (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may determine if a safety event is triggered based on the probability of the event output by the one or more machine learning models. For example, the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number. If the vehicle device determines the probability satisfies the prediction number, the vehicle device may determine an event has occurred and if the vehicle device determines the probability does not satisfy the prediction number, the vehicle device may determine an event has not occurred. Therefore, the vehicle device may determine if a safety event has been triggered based on a probability output by the one or more machine learning models…”).
For claim 18, Srinivasan discloses further comprising:
updating, by the at least one processor, the trigger based on determining that the trigger does not satisfy the probability threshold (See at least Col. 27 lines 23-37 of Srinivasan – “… the vehicle device may compare the probability output by the one or more machine learning models to a prediction number to determine whether the probability satisfies the prediction number… if the vehicle device determines the probability does not satisfy the prediction number, the vehicle device may determine an event has not occurred …”); and
providing, by the at least one processor, data associated with the trigger to the at least one vehicle to cause the trigger to be implemented by the computing device installed in the at least one vehicle based on updating the trigger (See at least Col. 27 lines 38-60 of Srinivasan – “… If the vehicle device determines a safety event has been triggered, at block 214, the vehicle device may generate and/or provide an in-vehicle alert within the vehicle. Further, at block 216, based on identifying the occurrence of a safety event, the vehicle device may send metadata and limited asset data to the event analysis system… the vehicle device may send metadata and limited asset data to the event analysis system based on identifying the non-occurrence of a safety event. For example, the vehicle device may periodically or aperiodically send metadata and limited asset data to the event analysis system regardless of whether an event has been identified in order to confirm that the vehicle device is correctly identifying events and correctly identifying non-events (e.g., the non-occurrence of events). Therefore, the vehicle device can send metadata and limited asset data to the event analysis system if an event has been triggered or if an event has not been triggered …”).
For claim 19, Srinivasan discloses a non-transitory machine-readable medium having computer-executable instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations (See at least Col. 37 lines 6-12 of Srinivasan – “… the functionality described herein may be performed as software instructions are executed by, and/or in response to software instructions being executed by, one or more hardware processors and/or any other suitable computing devices. The software instructions and/or other executable code may be read from a computer readable storage medium …”) comprising:
receiving, from a set of sensors (See at least the Abstract of Srinivasan – “… A vehicle device may execute one or more neural networks … based on input from one or more of the cameras and/or other sensors … to intelligently detect safety events in real-time…”), data associated with operation of at least one vehicle in an environment, the operation of the at least one vehicle occurring during at least one period of time (See at least Col. 23 lines 23-37 of Srinivasan – “… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period… may indicate that asset data is requested only for the first 5 occurrence of harsh turning events.. Thus, the event analysis system receives additional asset data for some of the harsh turning events and preserves bandwidth and reduces costs by not requesting asset data for all of the harsh turning events, due to the limited value of analyzing the additional asset data associated with a recurring triggered safety event…”);
scanning the metadata index to determining a plurality of events that occurred during the at least one period of time based on the operation of the at least one vehicle in the environment, each event of the plurality of events having an event type (See at least Col. 15 lines 54-67 through Col. 16 lines 1-11 of Srinivasan – “…sensor data (e.g., video data) is stored for processing by one or more event models… video data and metadata from one or more sensors may be stored for a particular time period … one or more event models are executed on the sensor data, which may be accessible via the sensor data store 206. In some embodiments, the event models executed at block 210 are configured to identify harsh events indicative of a sudden, extreme, and/or unexpected movement of the vehicle… In addition, or as an alternative, to detection of harsh events, the vehicle device 114 advantageously executes one or more event models (e.g., neural networks) on sensor data, such as video data, to detect safety events, such as a tailgating, forward collision risk, and/or distracted driver event …”);
receiving, from a computing device, data associated with a request, the request specifying one or more event types (See at least Col. 22 lines 43-67 through Col. 23 lines 1-17 of Srinivasan – “… the event analysis system receives the event data 219, which may initially be only metadata associated with a detected event… event data associated with a tailgating event may be analyzed using a tailgating model in the event analysis system that is more sophisticated than the tailgating model used in the vehicle device… the event models applied in the event analysis system may require additional event data beyond the initial event data received upon triggering of the safety event at the vehicle device… audio data that was not part of the initial event data transmitted to the event analysis system may be indicated as required for a particular detected event type …the event analysis system may determine that a particular time segment of audio data should be requested from the vehicle device… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 … This process may be repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
determining a set of events from among the plurality of events based on the one or more event types specified by the request, each event from the set of events occurring at points in time associated with the at least one period of time (See at least Col. 21 line 19 through Col. 23 line 22 of Srinivasan – “…The rules may further indicate that occurrence of the same safety event within a subsequent time period (e.g., 1 minute, 30 minutes, 60 minutes, etc.) causes event data 219 regarding both of the detected events to be transmitted to the event analysis system. Similarly, rules may be established to transmit event data 219 only upon occurrence of other quantities of safety events (e.g., three, four, five, etc.) during other time periods … the video data (and/or other types of asset data) may be compiled into a single video file that includes all of the detected events throughout the roll up time period… the event analysis system may receive a single video file that is a hyper-lapse showing frames from all of the safety events… additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time in accordance with rules for transmitting additional data… specific asset data is requested by the event analysis system, such as a particular time period of requested video or audio data… the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided…”);
generating event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events (See at least Col. 23 lines 7-37 of Srinivasan – “… At block 230, additional event data is requested from the vehicle device, which may fulfill the request by transmitting additional event data 219 immediately and/or at some later time … requested by the event analysis system, such as a particular time period of requested video or audio data… Upon receipt of the additional event data 219 at the event analysis system, the high-fidelity event models 210 may be further executed … repeated multiple times until the event data needed to evaluate the event analysis system models and/or meet the minimum requirements for a safety dashboard is provided... the event analysis system applies default and/or user configurable rules to determine which asset data is requested from the vehicle device… a rule may be established that excludes requests for additional asset data when asset data for the same type of safety event has already been received during a particular time period…”); and
transmitting the event data to the computing device associated with the request (See at least Col. 24 line 56 through Col. 25 line 10 of Srinivasan – “…The backend server may transmit the probability (e.g., the probability of the occurrence of the particular feature and/or the probability of the event) determined by the backend server to the vehicle device… the backend server may provide an indication of the comparison of the two probabilities to the vehicle device…”).
Srinivasan fails to specifically disclose structuring the data into a metadata index comprising a plurality of time synchronized arrays corresponding to the data associated with operation of the at least one vehicle;
generating event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index.
However, Lagorce, in the same field of endeavor teaches structuring the data into a metadata index (See at least [0066] of Lagorce – “… The data structure may contain one or more of the following items forming the event data for a pixel having an address expressed as an index i, and coordinates (x.sub.i, y.sub.i) in the array…”) comprising a plurality of time synchronized arrays corresponding to the data associated with operation of the at least one vehicle (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…” and [0102] of Lagorce – “… the event-based sensor 10 and the processor(s) 12 is used in an automobile to detect and track objects on the roads, such as traffic light, moving objects, etc., so as to provide these dynamic information to autonomous driving system…”);
generating event data associated with the operation of the at least one vehicle in the environment during the points in time corresponding to each event of the set of events by retrieving, from the data associated with operation of at least one vehicle, only those time segments corresponding to the set of events identified using the metadata index (See at least [0076] of Lagorce – “… It will also be appreciated that, in a practical implementation, the data structure, stored and maintained as events are received, can have the information (i.e. part or all of the items listed above) for all the pixels of the array… whose most recent event has a timestamp t.sub.j earlier than t.sub.i−T (i.e. a pixel that does not belong to the “set” at time t.sub.i), will be disregarded in the processing performed upon receipt of an event at time t.sub.i…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Lagorce teaches a system for an autonomous vehicle that processes event based information structured in an index with time-stamped arrays and disregards data not belonging to a time requirement for identifying an event.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of structuring the data into a metadata index comprising a plurality of time- synchronized arrays corresponding to the data associated with operation of the at least one vehicle as taught by Lagorce, with a reasonable expectation of success, in order to disregard data not meeting a timing requirement for identifying events as specified in at least [0076] of Lagorce.
Furthermore, Srinivasan also fails to specifically disclose the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle.
However, Calmer, in the same field of endeavor teaches the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle (See at least Col. 12 lines 41-57 of Calmer – “…FIG. 4 is an example user interface that may be provided to the user as part of the safety dashboard, such as via a web enabled interface that is viewed on a desktop, portable, or mobile device. This example user interface illustrates asset data associated with a tailgating alert…”). Thus, Srinivasan discloses an event detection system for a vehicle that analyzes sensor data to identify safety events during operation of a vehicle, while Calmer teaches a safety even detection system for a vehicle that provides a user interface to alert a driver or safety manager of a safety risk identified.
Therefore, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to modify the system, computer-implemented method, and non-transitory machine-readable medium as disclosed in Srinivasan to include the feature of the event data configured to cause a display associated with the computing device to generate a user interface representing the operation of the at least one vehicle as taught by Calmer, with a reasonable expectation of success, in order to provide an alert to a user where an action may be prudent as specified in at least Col. 12 lines 41-57 of Calmer.
For claim 20, Srinivasan discloses wherein the request specifies at least one event type corresponding to a change in a state of the at least one vehicle (See at least Col. 19 lines 13-39 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events…”), and
wherein the computer-executable instructions that cause the one or more processors to determine the plurality of events, cause the one or more processors to:
determine the change in the state of the at least one vehicle during the at least one period of time (See at least Col. 19 lines 13-53 of Srinivasan – “… FIG. 5 is an example user interface that provides information regarding a detected safety event, in this case a harsh braking and a distracted driver event… the event type 510 is indicated as both a harsh braking and a distracted driver safety event. Additionally, the dashboard provides the maximum G force 512 detected during the event, as well as the default vehicle type setting used in detecting the events… the displayed data is synchronized, such that each of the outward-facing video 520, inward-facing video 522, map view 518, and time series graph 516 each depict information associated with a same point in time (e.g., a particular time during the ten seconds of event data associated with a detected safety event…”).
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 MICHAEL J HERRERA whose telephone number is (571)270-5271. The examiner can normally be reached M-F 10:00 AM to 6:00 PM 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, FADEY JABR can be reached at (571)272-1516. 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.
/M.J.H./Examiner, Art Unit 3668
/Fadey S. Jabr/Supervisory Patent Examiner, Art Unit 3668
Prosecution Insights