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
This office action is in response to application number 18/948,046 filed on 5/18/2026, in which
Claims 1-20 are presented for examination. Applicant amends Claims 1-2, 5, 7, 11-12, 16-17, and 19-20.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 11/14/2024 has been received and considered by the examiner.
Response to Arguments
Applicant’s arguments, see pgs. 4 and 11, filed 5/18/2026, with respect to the objections to the drawings have been fully considered and are persuasive. The objections to the drawings set forth in the office action of 2/25/2026 have been withdrawn.
Applicant’s arguments, see pgs. , filed 5/18/2026, with respect to the objections to the have been fully considered and are persuasive. The objections to the of 2/25/2026 have been withdrawn.
Applicant’s arguments, see pgs. , filed 5/18/2026, with respect to the objections to the have been fully considered but are not fully persuasive. The objections to the of 2/25/2026 have been withdrawn. In light of the amendments, the objection to Claim 7 is updated and new objections to Claims 2 and 12 are introduced. Further details are provided below.
Applicant’s arguments, see pgs. , filed 5/18/2026, with respect to the have been fully considered and are persuasive. The rejection of Claims of 2/25/2026 have been withdrawn. However, in light of the amendments, new rejections under 35 U.S.C. 112(b) are introduced. Further details are provided below.
Applicant’s arguments, see pgs. , filed 5/18/2026, with respect to the have been fully considered and are persuasive. The rejections of Claims 1-10 and Claims 1-20 under 35 U.S.C. 101 set forth in the office action of 2/25/2026 has been withdrawn.
Applicant argues that the claim is not directed towards an abstract idea because it is “rooted in technology and directed to tangible, technical operations, for increasing the accuracy of the reporting machine learning model and in detection and reporting of road events by the event reporting system,” as amended in Claim 1. Applicant further argues that if Claim 1 is directed towards an abstract idea, it is directed towards an inventive concept and integrates any abstract idea into a practical application. Applicant explains that the invention addresses improvements in the time and expense of detecting, logging, and reporting road events using autonomous vehicles by using separate computing systems to reduce the demand on the autonomous vehicle, where a separate, event reporting server is used to analyze and report the events, which improves the “accuracy in analyzing and reporting events […] by using feedback from an external party as ground truth information for training the reporting machine learning model,” as also reflected in the amendments to Claim 1. Finally, Applicant notes that the recited ordered combination of “unconventional steps” amounts to significantly more than mere mathematical concepts as cited in the office action and instead provide meaningful limitations beyond merely organizing and manipulating information and provides a technical solution to a technical problem in the field of autonomous vehicles. Applicant states that the same arguments apply to the limitations of amended Claim 11 and dependent Claims 2-10 and 12-20, by their dependency on the independent claims, Claim 1 and 11.
Examiner agrees. Applicant’s amendments, to Claims 1 and Claim 11, further define the processing step to include “predicting […] measurements of road conditions associated with the event.” Applicant’s amendments add steps for labeling feedback as “ground truth of the event, the feedback including at least one of flagging incorrect events or correcting events” and training a machine learning model “using the event and the ground truth” to increase accuracy of the machine learning model in detection and reporting of road events. These amendments go beyond a mental process, where processing data to predict measurements of road conditions and labeling feedback in the recited way is not reasonably done in the human mind. Additionally, using and training the machine learning model is recited in a way that goes beyond implementing an abstract idea using a computer because the model is processing specific data and being trained on specific data, where the datasets are not generally recited, as defined by the limitations of the claim. Therefore, this goes beyond just “apply it,” or generally using a computer, for performing an abstract idea. Finally, Applicant’s amendments recite a specific improvement by using the specified datasets, that include ground truth data with flags indicating incorrect or corrected events, to increase accuracy in detection and reporting.
Applicant’s arguments, see pgs. , filed 5/18/2026, with respect to the have been fully considered and are persuasive, however, they are directed towards the amendments of Claims 1, 5 and 11, and are therefore moot. The rejection of Claims of 2/25/2026 is maintained and, in light of the amendments, the rejection of Claims 1-20 under 35 U.S.C. 103 is updated. Further details are provided below.
Claim Objections
Claims 2, 7, and 12 are objected to because of the following informalities:
Claim 2 (line 3) and Claim 12 (line 3): “the sensor data” should be “the logged sensor data,” based on the amendments made to Claim 1 (lines 15-16) and Claim 11 (lines 7-9). Additional instances of “the sensor data” and “the logged sensor” data that should be interpreted as either “the sensor data” or “the logged sensor data,” according to Claim 1 and Claim 11, should be reviewed and addressed as needed.
Claim 7 (line 3): "based on detection one" should be "based on detection of one"
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 4 and 14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 4 (line 2) and Claim 14 (line 2) recite the limitation "feedback." “Feedback” is already defined in Claim 1 (lines 22-23) and Claim 11 (lines 15-16). For clarity, Claim 4 (line 2) and Claim 14 (line 2) should recite “the feedback.”
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 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.
Claims 1, 5, 7-8, 11, 15, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lavie et al., PG Pub US-2017/0169625-A1 (herein “Lavie”) in view of Cheng et al., PG Pub US-2022/0036098-A1 (herein “Cheng”) and Averbuch, PG Pub US-2022/0319336-A1 (herein "Averbuch").
Regarding Claim 1, Lavie discloses: (Currently Amended) An event reporting system, comprising: at least one […] vehicle comprising: an autonomy computing system, comprising at least one processor in communication with at least one non-transitory memory device. See [Lavie, pg. 6, para 0109], which explains that a processor of a client, including a vehicle, receives data from sensors, “Communications between various sensors and a processor in a client can happen via the system bus in the client or via short range wireless or via fiber optics or wired connections. If the client device is an add-on product or consists of software running on a mobile device within a vehicle, then communication with the integral vehicle sensor may be by using an interface that can read on-board diagnostic (OBD II) codes by interfacing with a vehicle portal designed for external communications.” See also [Lavie, pg. 8, paras 0193-0194], which explains that the system is implemented on a computer containing a processor and a memory for storing the instructions, “[0193] The present invention may be conveniently implemented using one or more conventional general purpose or specialized digital computers or microprocessors programmed according to the teachings of the present disclosure, or a portable device […], equipped with including one or more sensors […] or where the portable device are connected to the data collection devices that are remote to the portable device, or that are connected via wired or wireless means. […]. [0194] In some embodiments, the present invention includes a computer program product which is a non-transitory storage medium (media) having instructions stored thereon/in which can be used to program a computer to perform any of the processes of the present invention.”
Lavie further discloses: and the at least one processor programmed to: receive sensor data from one or more sensors of the at least one […] vehicle while traveling through an environment; determine an event is present by evaluating the sensor data; and log sensor data related to the event […]. See [Lavie, pg. 1, paras 0011-0012], which explains that the system includes a database, distributed on a central server and clients, and includes sensor data stored by the vehicle. Further, it explains that the sensor data includes raw data, patterns, or indicators relating changes in data over time, “[0011] The database is distributed among one or more central servers and clients: satellite servers, individual vehicles, and hand-held units. Each server and clients houses a database of information that is pertinent to one of: one or more vehicles or to an individual driver who drives the one or more vehicles. For example, a vehicle will store raw sensor data from sensors embedded in the vehicle and/or that reside in-vehicle and also information acquired from external feeds—for example traffic (in the vicinity of the vehicle or along a route the vehicle will travel) and weather information. […]. [0012] In addition to raw sensor data being stored, patterns or indicators that relate changes in one or more sensor readings over time and changes in environmental data overtime to events that are also stored.” See also [Lavie, pg. 2, para 0015], which further explains that the sensors include accelerometers and gyroscopes to measure vehicle data and external sensors, such as LIDAR, for measuring traffic, weather, or road conditions, “Sensors: measurement devices which measure parameters that are directly or indirectly related to the amount and extent of maintenance and/or repair needed to keep a vehicle in peak operating condition. Sensors could be in-vehicle—either part of the vehicle or an after-market attachment to the vehicle such as a fleet management system or as part of a mobile device within the vehicle such as the sensors in a mobile phone—like accelerometers or gyroscopes. Sensors may also be outside the vehicle such as roadside traffic counters in the vicinity of the vehicle, weather stations, and satellite or airborne based sensor such as LIDAR. External sensors that can provide information about the condition of pavement, weather, freeze thaw conditions or the like are included.” See also [Lavie, pg. 2, para 0021], which explains the external observations a sensor can make, “External Observations: See the definition of sensors above for examples of observations that can come from outside the vehicle. Source for this information can also be from web services, for example weather data, or traffic information that is a feed coming in from a FM sideband via an FM receiver.” See also [Lavie, pgs. 2-3, paras 0029-0038], which further explains the patterns of driving events, analyzed using multiple datasets over time, and include, for example, hazardous driving, road conditions, or traffic density, “[0029] Patterns: Time series or frequency distribution of sequential sensor data of one or more sensors or feeds for a given time period and locale that can be used to identify Driving Events. Patterns are created by analyzing many datasets with known events happening. […]. [0030] […]. [0031] Patterns may be based on the output of 1 or more sensor and/or 1 or more observations. The pattern could be based on exceeding (or falling below) a threshold value, or exceeding (or falling below) an average value over time. Patterns may be analyzed in the frequency domain (after a fast Fourier transform is applied to time series data). [0032] Examples of patterns based on time series or frequency analysis of sensor traces: [0033] […]; [0034] Hazardous driving [0035] Dangerous Roads Segments or Intersections [0036] […] [0037] Excessive Speed [0038] Patterns based on location and/or time: [0039] Road locations [0040] Traffic density [0041] Speed of Travel.” See also [Lavie, pg. 3, paras 0042-0044], which further explains the indicators and assessment used to identify driving events or ongoing driving events, “[0042] Indicators: Readings from one or more sensors for a given time period and locale that exceed or fall below a specified threshold value indicative or an Event, or Situation. An example of an indicator is exceeding the speed limit. [0043] Assessment: Given a variety of patterns and indicators as input, predictions are made for the resulting cost or extent of an event associated with the patterns and indicators. [0044] Driving Events: Something of interest that happens related to a vehicle, location, or time period which is identifiable by monitoring patterns or indicators. Events generally are categorized by something that is out of the ordinary. Examples of an event are a vehicle accident, a vehicle exceeding the speed limit, a vehicle being driven in an unsafe manner. An Ongoing Driving Event is a subset of an Event where the event occurs over a period of time. For example, an accident may be a momentary event, but may cause an Ongoing Event such as a slowing of traffic on the road where the accident occurs.” Finally see [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients, “[0078] In FIG. 3, a client 302 continuously monitors sensors and external feeds 304 and compares to patterns and indicators to detect an event. If an event is detected 306, pre-programmed activities are initiated that are associated with the event 308. One of these activities may be to inform the central server/s of the event and to upload information pertaining to the event. The client 302 establishes two way communications with the central server/s and then uploads the information and data associated with the event. The central server/s 310 in turn receives the information 312 and determines the type of follow-up information that is needed 314. An example would be, an accident is detected; it is reported to the central server along with particulars about speed, location, severity of impact. The central server may be programmed to determine if the accident caused a traffic slow down; therefore, it would broadcast a bulletin that it is interested in knowing the speed of vehicles that are in the vicinity of the accident so it can determine what, if any, roads were affected by the accident 318. In response other clients 320 that meet the selection criteria would communicate with the central server and upload their speed 322.
Lavie further discloses: an event reporting server computing system, comprising at least one processor in communication with at least one non-transitory memory device, the at least one processor programmed to; receive the logged sensor data related to the event from the at least one […] vehicle; process the logged sensor data related to the event […]. See again [Lavie, FIG. 3] and [Lavie, pg. 7, paras 0147-0153], which explains that the central server contains a computer with a memory and processor, “[0147] The following components are parts of embodiments of the system described in this application: [0148] One or more central servers that contain: [0149] Computer memory loaded with: [0150] a comprehensive database and patterns and indicators that correlate to events and situations [0151] One or more processors containing: [0152] Instructions for when and how to transmit requests for information and/or bulletins [0153] Instructions for receiving and analyzing information from remote devices.”
Lavie further discloses: report the event by: […]; and sending the event to an external party […]. See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients and [Lavie, pg. 7, paras 0163-0169], which describes radio receiver of the central server for communicating externally and receiving information to update stored data, such as patterns and indicators, “[0163] Radio Receiver for information from central servers via the one-way transmitter and/or other vehicles or systems including: [0164] Query for information [0165] Updates of patterns and indicators [0166] Updates on codes that are used to identify fields in a query [0167] Updates on sensor information and/or external feeds that are available on the network [0168] Updates on parts inventory that are part of each car [0169] Radio Transceiver configured to establish two-way communications with one or more central servers and further used to upload and download information […].”
Lavie does not explicitly disclose: […] autonomous [vehicle…]; [process the logged sensor data …] by predicting, by a reporting machine learning model, measurements of road conditions associated with the event; [[and]] […]: comparing the event with a database of existing events, […], wherein the measurements of the road conditions are accessible to the external party; label feedback about the event received from a feedback module as ground truth of the event, the feedback including at least one of flagging incorrect events or correcting events; and train the reporting machine learning model, using the event and the ground truth, to increase accuracy of the reporting machine learning model and in detection and reporting of road events by the event reporting system. However, [Lavie, pg. 1, para 0007], does discuss that autonomous driving systems are used for crowdsourcing road information, “Typical vehicle diagnostic systems and assisted or autonomous driving systems rely on crowdsourced information that was compiled from collecting data stored in on-board vehicle systems and from external feeds such as traffic and weather. All this information is compiled and sifted through in an effort to, for example, provide a prediction of some type of hazardous conditions or need of repair. Tremendous amounts of data need to be wirelessly transmitted, typically on mobile networks, where two-way communications are established between every vehicle or external feed and the central server or servers,” where [Lavie, pg., para 0015], sensors provide measurements, including external sensors for providing the road information, “Sensors may also be outside the vehicle such as roadside traffic counters in the vicinity of the vehicle, weather stations, and satellite or airborne based sensor such as LIDAR. External sensors that can provide information about the condition of pavement, weather, freeze thaw conditions or the like are included.” Additionally, [Lavie, pg. 6, para 0115], does discuss a historical vehicle maintenance database, ”In embodiments of this invention, vehicle maintenance and service requirements are predicted by comparing the observed conditions that occur during vehicle operation over time with similar observed conditions for similarly classed vehicle used in similar conditions stored in a historical vehicle maintenance database. Algorithms are developed to classify each maintenance or service event as succinctly as possible, given the available data, such that when the conditions requiring maintenance or service for a vehicle in use match a classification, this can be used with a degree of certainty, to predict resulting maintenance required and the parts and services necessary to effect the maintenance,” and [Lavie, pg. 7, para 0146 and 0150], discusses a database of data for correlating events and situations,”[0146] For information from disparate sources to be compared, the information must be normalized, i.e. converted to the same units of measure and be relative to the same reference frame. In addition, the quality and precision of the data must also be evaluated and represented within the database in a normalized fashion. In other words, if for example, one speed is known to be accurate within +/− 10 mph, then all speeds in the database should have an error of estimate in mph (as opposed to kph for example). […]. [0150] a comprehensive database and patterns and indicators that correlate to events and situations.”
However, Cheng teaches: […] autonomous [vehicle…]. See [Cheng, pg. 3, para 0024], which explains that the ego vehicle and other vehicles of the system can be autonomous, “The ego vehicle 200 and/or the other vehicle(s) 140 may be operated manually by a human driver, semi-autonomously by a mix of manual inputs from a human driver and autonomous inputs by one or more vehicle computers, fully autonomously by one or more vehicle computers, or any combination thereof.” See also [Cheng, pg. 6, para 0047], which further explains, in more detail, the autonomous capability of the ego vehicle, “The ego vehicle 200 will now be described in greater detail. Referring to FIG. 2, an example of the ego vehicle 200 is shown. In some instances, the ego vehicle 200 can be an autonomous vehicle. As used herein, “autonomous vehicle” means a vehicle that configured to operate in an autonomous operational mode. “Autonomous operational mode” means that one or more computing systems are used to navigate and/or maneuver the vehicle along a travel route with minimal or no input from a human driver. In one or more arrangements, the ego vehicle 200 can be manual, semi-autonomous, highly autonomous, or fully automated.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to specify the vehicle as autonomous. Doing so uses the existing features available on an autonomous vehicle, such as perception and wireless transfer capabilities, to better understand the external environment of the vehicle, improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
However, Cheng teaches: [process the logged sensor data …] by predicting, by a reporting machine learning model, measurements of road conditions associated with the event; [[and]] […]: comparing the event with a database of existing events, […], wherein the measurements of the road conditions are accessible to the external party. See [Cheng, pg. 5, paras 0039], which explains that the modules can classify objects using environmental data collected by sensors, “The SSDS module(s) 132 can, in one or more arrangements, attempt to classify the type, nature, and/or identity of the object(s) detected in the first environment data. The SSDS module(s) 132 can further determine information about the sensor(s) that detected the objects in the first environment data such as the type of sensor(s), the field of view of the sensor(s), and the distance between the detected object(s) and the sensor(s),” where [Cheng, pgs. 5-6, paras 0041-0043], the modules receive the sensor data, analyze the captured data to classify objects using a machine learning model, and compare a the measurements of the detected object against an image of an object database, which includes comparing identifying features, or measurements, such as shape and size. Finally the modules output classification data and transmit this data as a data summary, “[0041] The SSDS module(s) 132 can analyze first environment data captured by the sensor(s) to classify objects detected therein. The SSDS module(s) 132 can use any suitable technique, including, for example, template matching and other kinds of computer vision and/or image processing techniques and/or other artificial or computational intelligence algorithms or machine learning methods. […]. The SSDS module(s) 132 can query the object image database for possible matches. For instance, images in the first environment data can be compared to images in the object image database for possible matches. Alternatively or in addition, measurements or other aspects of the image can be compared to measurements or other aspects of any images in the object image database. The SSDS module(s) 132 can classify the detected object as a particular type of object if there is a match between the captured image and an image in the object database. “Match” or “matches” means that an image or other information in the first environment data and one or more of the images in the object image database are substantially identical. For instance, an image or other information collected by the sensor(s) and one or more of the images in the object image database can match within a predetermined probability (e.g., at least about 85%, at least about 90%, at least about 95% or greater) or confidence level. In one or more arrangements, the detected object can be compared to identifying features of an object, such as color measured visually, shape, size, movement, sounds, etc.]. [0042] The SSDS module(s) 132 can output classification data for the detected objects for inclusion in the data summary 162. […]. As an example, in the data summary 162, the classification data for a detected object can include the type and/or category of the object, the color of the object, the size of the object, a bounding box around the object, the position of the object relative to the ego vehicle 200, a timestamp, and/or information on the sensor(s) that detected the object as described above. [0043] […].The SSDS module(s) 132 can transmit the data summary 162 to the other vehicle(s) 140 or another entity using the transceiver(s) and the communication network(s) 150.” See also [Cheng, pgs. 6-7, paras 0050 and 0053-0054], which further describes the ego vehicle that includes the sensors used for determining, assessing, and measuring the environment in real-time, including information about obstacles such as stationary or dynamic objects, “[0050] The ego vehicle 200 can include one or more sensors 240. “Sensor” means any device, component and/or system that can detect, determine, assess, monitor, measure, quantify, acquire, and/or sense something. The one or more sensors can detect, determine, assess, monitor, measure, quantify, acquire, and/or sense in real-time. […]. […]. [0053] […]. The vehicle sensor(s) 241 can detect, determine, assess, monitor, measure, quantify and/or sense information about the ego vehicle 200 itself (e.g., position, orientation, speed, etc.). The sensor(s) 240 can include one or more environment sensors 242 configured to detect, determine, assess, monitor, measure, quantify, acquire, and/or sense data or information about the external environment in which a vehicle is located or one or more portions thereof. For example, the environment sensor(s) 242 can detect, determine, assess, monitor, measure, quantify, acquire, and/or sense obstacles in at least a portion of the external environment of the ego vehicle 200 and/or information/data about such obstacles. Such obstacles may be stationary objects and/or dynamic objects. […]. [0054] […]. For instance, one or more of the environment sensors 242 can be used to detect, determine, assess, monitor, measure, quantify, acquire, and/or sense, directly or indirectly, the presence of one or more objects in the external environment of the ego vehicle 200, the position or location of each detected object relative to the ego vehicle 200, the distance between each detected object and the ego vehicle 200 in one or more directions (e.g. in a longitudinal direction, a lateral direction, and/or other direction(s)), the elevation of a detected object, the speed of a detected object, the acceleration of a detected object, the heading angle of a detected object, and/or the movement of each detected obstacle.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include using sensor data for predicting road condition measurements and detecting and comparing objects with a database. Doing so allows for object, or event, classification and confirmation, with a high degree of confidence, [Cheng, pg. 5, paras 0041], that can be incorporated into a data summary for sharing, which contributes streamlined sharing of sensor data, by minimizing redundancy [Cheng, pg. 2, paras 0014-0015] and overall, contributes to improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
However, Averbuch teaches: label feedback about the event received from a feedback module as ground truth of the event, the feedback including at least one of flagging incorrect events or correcting events; and train the reporting machine learning model, using the event and the ground truth, to increase accuracy of the reporting machine learning model and in detection and reporting of road events by the event reporting system. See [Averbuch, pgs. 2-3, para 0031], which discusses estimating false positive reports for road events, including road conditions such as slippery road events, using groups of vehicles, such as vehicle fleets, to categorize true and false positive slippery road events, “[…], a system 100 of FIG. 1 introduces the capability of estimating false positive reports of detectable road events using two groups of vehicles. FIG. 1 is a diagram of a system 100 capable of estimating false positive reports of detectable road events using two groups of vehicles, according to one or more example embodiments. […]. In one embodiment, the system 100 can acquire slippery road event sensor data/signals from a first fleet/group of vehicles 201 and a second fleet/group of vehicles 203, perform a statistic processing 205 on the sensor data/signals to distinguish false positive slippery road event signals/reports 207b from true slippery road event signals/reports 207a, and then map-match the event signals/reports 207a, 207b into a slippery road event map 209. By way of example, the true slippery road event signals/reports 207a are marked as black dots while the false positive slippery road event signals/reports 207b are marked as white dots with outlines in the slippery road event map 209.” See also [Averbuch, pgs. 4-5, paras 0052-0054], which further explains that the system, including various modules such as a data processing, mapping, or fleet management module and a machine learning system or cloud based service for integrating these modules, collects real-time sensor data and contextual information to be used as “ground true” data, “[0052] In one embodiment, the system 100 may also collect real-time sensor data, and/or road event information from one or more other sources […], etc. as ground true data to verify false positive road event reporting rates. [0053] In another embodiment, the sensor information can be supplemented with additional information from network-based services such as those provided by the services platform 119 and the services 121. By way of example, the services 121 can include mapping service, navigation services, and/or other data services that provide data for estimating false positive reports of detectable road events using two groups of vehicles. In one embodiment, the services platform 119 and/or the services 121 can provide contextual information such as weather, traffic, etc. as well as facilitate communications […] among vehicles to share road event information. In one embodiment, the services platform 119 and/or the services 121 interact with content providers 123 who provide content data (e.g., map data, imaging data, road event data, etc.) to the services platform 119 and/or the services 121. In one embodiment, the UE 109 executes an application 119 that acts as client to the mapping platform 105, the services platform 119, the services 121, and/or the content providers 123. In one embodiment, the sensor data, contextual information, and/or configuration information can be stored in a database (e.g., the geographic database 115) for use by the mapping platform 105. […]. [0054] FIG. 3 is a diagram of the components of the mapping platform 105, […]. […]. In one embodiment, the mapping platform 105 includes a data processing module 301, an estimating module 303, a reporting module 305, a mapping module 307, a fleet management module 309, an output module 311, and the machine learning system 113 has connectivity to the geographic database 115 and/or the road event database 117. The above presented modules and components of the mapping platform 105 can be implemented in hardware, firmware, software, or a combination thereof. Though depicted as a separate entity in FIG. 1, it is contemplated that the mapping platform 105 may be implemented as a module of any other component of the system 100. In another embodiment, the mapping platform 105, the machine learning system 113, and/or the modules 301-311 may be implemented as a cloud-based service, local service, native application, or combination thereof,” and [Averbuch, pgs. 8-9, para 0089], can further include sensor data associated with the user response that can be used to confirm the road event, and support confirmation of “ground truth data,” “As other examples, the sensors can be any type of sensor that can detect a user's gaze, heartrate, sweat rate or perspiration level, eye movement, body movement, or combination thereof, in order to determine a user response to confirm road events. As such, the system 100 can enable a user to confirm road events (e.g., to provide the system 100 as ground truth data).” Finally see [Averbuch, pg. 9, para 0098], which explains that machine learning model uses the driving condition information and the false report data as training data, “In one embodiment, a false positive cause machine learning model can be built by the machine learning system 113 based on the sensor data, false positive road event report data, ground truth data, etc. as training data. By way of example, the machine learning system 113 can use parameters/factors such as characteristics of the vehicle […], […], driving context and conditions (e.g., road geometry/conditions, traffic, weather, etc.), map data, etc. that describe a distribution or a set of distributions of the false positive road event reports, thereby calculating cause(s) of the false positive road event reports (with a respective road event type, a respective map object type, etc.) […]., where [Averbuch, pg. 13, para 0132], the sensor data, report event data, false positive report data, training data, etc. is stored in a database with corresponding metadata for use by the system, “In one embodiment, the geographic database 115 can also include road event data records 909 for storing sensor data, road event report data, cause and false positive road event reports association data, training data, prediction models, annotated observations, computed featured distributions, sampling probabilities, and/or any other data generated or used by the system 100 according to the various embodiments described herein. By way of example, the road event data records 909 can be associated with one or more of the node records 903, road segment records 905, and/or POI data records 907 to support localization or visual odometry based on the features stored therein and the corresponding estimated quality of the features. In this way, the road event data records 909 can also be associated with or used to classify the characteristics or metadata of the corresponding records 903, 905, and/or 907.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Averbuch to include feedback labeled as ground truth and flagged as incorrect or correct and using the ground truth and sensor data to train the machine learning model. Doing so provides up-to-date data on road events, which supports identifying false positive report data [Averbuch, pg. 1, para 001], by improving map data and delivery of dynamic road event content to users through navigation and mapping services [Averbuch, pgs. 2-3, paras 0030-0031]. Additionally, the feedback and training can provide continuous improvement and help prevent future false positive road event reports [Averbuch, pg. 10, para 0100].
Regarding Claim 5, Lavie as modified discloses the limitations of Claim 1.
Lavie further discloses: (Currently Amended) […] wherein the at least one […] vehicle comprises a fleet of at least two different […] vehicles […], and wherein the event reporting server computing system processor is further programmed the logged sensor data related to the event from the at least two different […] vehicles and compare the event from the at least two different […] vehicles. See [Lavie, FIG. 1 and pg. 4, paras 0073 and 0076], which explains that the central server receives information from multiple clients, or vehicles, to create models, form patterns, and identify indicators for comparing and identifying an event, where datasets include vehicle fleets and vehicles, “[0073] Patterns are created by analyzing many datasets with known events happening and developing a predictive model of the event based on the available data. Patterns are updated by a central server in communication with client systems through the process of querying the client system (such as a vehicle fleet) and having clients (vehicles) that match the requirements for the pattern, respond with relaying data for the event in question. […]. [0076] The central server/s 202 then uses a form of statistical analysis to establish a relationship between the uploaded information from numerous clients 204 and creates predictive models 220 in the form of patterns and indicators. A broadcast, using the transmitter, is made to the clients 204 to let them know the derived patterns, and indicators are available for usage 222. Clients 204 that have need of the patterns and indicators 224, then download the information 226, then monitor sensors and other incoming information to determine if patterns or indicators occur that are indicate an event has happened 228.”
Lavie does not explicitly disclose: […] autonomous [vehicle] comprises a fleet of at least two different autonomous vehicles, the fleet traveling along a same route, […]. However, [Lavie, pg. 1, para 0007], does discuss that autonomous driving systems are used for crowdsourcing road information.
However, Cheng teaches: […] autonomous [vehicle…]. See again [Cheng, pg. 3, para 0024], which explains that the ego vehicle and other vehicles of the system can be autonomous and [Cheng, pg. 6, para 0047], which further explains, in more detail, the autonomous capability of the ego vehicle.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to specify the vehicle as autonomous. Doing so uses the existing features available on an autonomous vehicle, such as perception and wireless transfer capabilities, to better understand the external environment of the vehicle, improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
However, Averbuch teaches: […] comprises a fleet of at least two different autonomous vehicles, the fleet traveling along a same route, […]. See [Averbuch, pg. 3, para 0033], which explains that the road event reports are compared between the vehicles in the fleet over time, “The bigger the difference between the two numbers of the road event reports (a dry day vs. a slipper day), the more reliable (i.e., a higher level of confidence) the percentage of defective vehicles in the fleet. In other words, the more extreme the first and second environmental conditions of the two days (dry vs. wet), the more reliable the percentage of defective vehicles in the fleet. Such environmental conditions are independent from the fleet. The system 100 can set thresholds for sufficient slippery or dry. Rather than two days, the system 100 can use any two time periods (e.g., three hours of the same day, three hours of the same time of two different days, two different weeks, etc.) with sufficiently different environmental conditions to provide reliable results,” where [Averbuch, pg. 3, para 0039], the data is collected over time for the same area, “Therefore, having two days in the same area and approximately the same sizes of fleets with very different number of slippery road events reported, the system 100 can observe very different impact of the false positive cases caused by defect vehicles of the OEM at issue, and calculate actual impact of the defective vehicles on the false positive cases,” that [Averbuch, pg. 4, paras 0042-0043 and 0048], is bucketed by road segments for comparison, “[0042] In one embodiment, the system 100 can compare two similar time periods, for instance, two days (day 1, day 2) with two sets of actual slippery road segments S.sub.act1 and S.sub.act2 having a substantial difference. Assuming that the actual number of road segments in the area is Seg.sub.tot, the numbers of non-slippery road segments in the area can be expressed as N.sub.act1=Seg.sub.tot−S.sub.act1 and N.sub.act2=Seg.sub.tot−S.sub.act2 respectively. In one scenario, vehicles of another OEM fleet produces X.sub.other slippery road event reports for each road segment being slippery, and do not produce any slippery road event reports for each non-slippery road segment. […]. [0043] The system 100 can assume that the OEM fleet at issue produces X.sub.tp slippery road event reports for each segment being slippery (i.e., true positive) and X.sub.fp slippery road event reports for each non-slippery road segment (i.e., false positive due to, such as defects). […]. [0048] Therefore, the system 100 cam estimate the impact of false positive slippery road event signals/reports in the absence of the explicit information (e.g., the sizes of the fleets, the numbers of defective vehicles, etc.) from the road event report data sources (e.g., the OEMs).”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Averbuch to include a fleet of at least two vehicles traveling along the same route. Doing so allows for generating a more reliable, or higher confidence, in the detection of false reports and identification of defective vehicles in a fleet [Averbuch, pg. 3, para 0033]. Additionally, it promotes a mutually beneficially relationship between fleet management systems and service providers or OEMs, where service providers and OEMs can improve a driving experience using the collected sensor data [Averbuch, pg. 2, para 0029], but it also provides an option to the fleet management systems to manage a relationship with an OEM, by informing OEMs that the fleet, or a specific vehicle of the fleet, may be defective and requires improvement to minimize false event reporting before continuing the payments, for example [Averbuch, pg. 6, paras 0067-0068].
Regarding Claim 7, Lavie as modified discloses the limitations of Claim 1.
Lavie further discloses: (Currently Amended) […] wherein the autonomy computing system processor is programmed to: detect the event based on detection the road conditions based on the one or more continuous events. See again [Lavie , pgs. 2-3, paras 0029-0038], which further explains the patterns of driving events, analyzed using multiple datasets over time, and include, for example, hazardous driving, road conditions, or traffic density and [Lavie, pg. 3, paras 0042-0044], which further explains the indicators and assessment used to identify driving events or ongoing driving event, where an ongoing even uses road conditions, for example slowing traffic, “[0044] An Ongoing Driving Event is a subset of an Event where the event occurs over a period of time. For example, an accident may be a momentary event, but may cause an Ongoing Event such as a slowing of traffic on the road where the accident occurs.” Also see again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients.
Regarding Claim 8, Lavie as modified discloses the limitations of Claim 1.
Lavie further discloses: (Original) […] wherein the autonomy computing system processor is programmed to: detect, using a detection machine learning model, the event is present based on the sensor data. See [0042-0047], which discusses monitoring and assessing patterns and indicators to detect driving events or situations where multi-variate analysis is used to identify or maintain patterns, examples of which include artificial neural networks and machine learning, “[0042] Indicators: Readings from one or more sensors for a given time period and locale that exceed or fall below a specified threshold value indicative or an Event, or Situation. […]. [0043] Assessment: Given a variety of patterns and indicators as input, predictions are made for the resulting cost or extent of an event associated with the patterns and indicators. [0044] Driving Events: Something of interest that happens related to a vehicle, location, or time period which is identifiable by monitoring patterns or indicators. Events generally are categorized by something that is out of the ordinary. […]. An Ongoing Driving Event is a subset of an Event where the event occurs over a period of time. […]. [0045] External Data Feeds: Servers or services that available via a web interface or that are broadcast over radio frequency that provide information on conditions such as weather and traffic. [0046] Situation: Something that is associated with the likelihood that an event will happen for a particular place, time and/or conditions. […]. [0047] Mutli-variate analysis: A statistical technique to identify or maintain patterns. Examples are artificial neural networks and machine learning.” See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients.
Regarding Claim 11, Lavie discloses: (Currently Amended) A computer-implemented method of event reporting for managing infrastructure and event information, the method comprising: receiving sensor data from one or more sensors of at least one […] vehicle; detecting an event is present by: evaluating the sensor data; logging sensor data related to the event. See again [Lavie, pg. 6, para 0109 ], which explains that a processor of a client, including a vehicle, receives data from sensors and [Lavie, pg. 8, paras 0193-0194 ], which explains that the system is implemented on a computer containing a processor and a memory for storing the instructions. Also see again [Lavie, pg. 1, paras 0011-0012 ], which explains that the system includes a database, distributed on a central server and clients, and includes sensor data stored by the vehicle. Further, it explains that the sensor data includes raw data, patterns, or indicators relating changes in data over time and [Lavie, pg. 2, para 0015], which further explains that the sensors include accelerometers and gyroscopes to measure vehicle data and external sensors, such as LIDAR, for measuring traffic, weather, or road conditions. Also see again [Lavie , pgs. 2-3, paras 0029-0038], which further explains the patterns of driving events, analyzed using multiple datasets over time, and include, for example, hazardous driving, road conditions, or traffic density and [Lavie, pg. 3, paras 0042-0044], which further explains the indicators and assessment used to identify driving events or ongoing driving event. Finally see again[Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients.
Lavie further disclose: processing the logged sensor data related to the event […]; and reporting the event by: […]; and sending the event to an external party based on the comparison. See again [Lavie, FIG. 3] and [Lavie, pg. 7, paras 0147-0153], which explains that the central server contains a computer with a memory and processor. See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients and [Lavie, pg. 7, paras 0163-0169 ], which describes radio receiver of the central server for communicating externally and receiving information to update stored data, such as patterns and indicators.
Lavie does not explicitly disclose: […] autonomous [vehicle…]; [processing the logged sensor data …] by predicting, by a reporting machine learning model, measurements of road conditions associated with the event; [[and]] […]: comparing the event with a database of existing events, […], wherein the measurements of the road conditions are accessible to the external party; label feedback about the event received from a feedback module as ground truth of the event, the feedback including at least one of flagging incorrect events or correcting events; and train the reporting machine learning model, using the event and the ground truth, to increase accuracy of the reporting machine learning model and in detection and reporting of road events by the event reporting system. However, [Lavie, pg. 1, para 0007], does discuss that autonomous driving systems are used for crowdsourcing road information, where [Lavie, pg., para 0015], sensors provide measurements, including external sensors for providing the road information. Additionally, [Lavie, pg. 6, para 0115], does discuss a historical vehicle maintenance database, and [Lavie, pg. 7, para 0146 and 0150], discusses a database of data for correlating events and situations.
However, Cheng teaches: […] autonomous [vehicle…]. See again [Cheng, pg. 3, para 0024], which explains that the ego vehicle and other vehicles of the system can be autonomous and [Cheng, pg. 6, para 0047], which further explains, in more detail, the autonomous capability of the ego vehicle.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to specify the vehicle as autonomous. Doing so uses the existing features available on an autonomous vehicle, such as perception and wireless transfer capabilities, to better understand the external environment of the vehicle, improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
However, Cheng teaches: [processing the logged sensor data …] by predicting, by a reporting machine learning model, measurements of road conditions associated with the event; [[and]] […]: comparing the event with a database of existing events, […], wherein the measurements of the road conditions are accessible to the external party. See again [Cheng, pg. 5, paras 0039], which explains that the modules can classify objects using environmental data collected by sensors, where [Cheng, pgs. 5-6, paras 0041-0043], the modules receive the sensor data, analyze the captured data to classify objects using a machine learning model, and compare a the measurements of the detected object against an image of an object database, which includes comparing identifying features, or measurements, such as shape and size. Finally the modules output classification data and transmit this data as a data summary. Also see again [Cheng, pgs. 6-7, paras 0050 and 0053-0054], which further describes the ego vehicle that includes the sensors used for determining, assessing, and measuring the environment in real-time, including information about obstacles such as stationary or dynamic objects.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include using sensor data for predicting road condition measurements and detecting and comparing objects with a database. Doing so allows for object, or event, classification and confirmation, with a high degree of confidence, [Cheng, pg. 5, paras 0041], that can be incorporated into a data summary for sharing, which contributes streamlined sharing of sensor data, by minimizing redundancy [Cheng, pg. 2, paras 0014-0015] and overall, contributes to improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
However, Averbuch teaches: label feedback about the event received from a feedback module as ground truth of the event, the feedback including at least one of flagging incorrect events or correcting events; and train the reporting machine learning model, using the event and the ground truth, to increase accuracy of the reporting machine learning model and in detection and reporting of road events by the event reporting system. See again [Averbuch, pgs. 2-3, para 0031], which discusses estimating false positive reports for road events, including road conditions such as slippery road events, using groups of vehicles, such as vehicle fleets, to categorize true and false positive slippery road events. Also see again [Averbuch, pgs. 4-5, paras 0052-0054], which further explains that the system, including various modules such as a data processing, mapping, or fleet management module and a machine learning system or cloud based service for integrating these modules, collects real-time sensor data and contextual information to be used as “ground true” data, and [Averbuch, pgs. 8-9, para 0089], can further include sensor data associated with the user response that can be used to confirm the road event, and support confirmation of “ground truth data.” Finally see again [Averbuch, pg. 9, para 0098], which explains that machine learning model uses the driving condition information and the false report data as training data, where [Averbuch, pg. 13, para 0132], the sensor data, report event data, false positive report data, training data, etc. is stored in a database with corresponding metadata for use by the system.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Averbuch to include feedback labeled as ground truth and flagged as incorrect or correct and using the ground truth and sensor data to train the machine learning model. Doing so provides up-to-date data on road events, which supports identifying false positive report data [Averbuch, pg. 1, para 001], by improving map data and delivery of dynamic road event content to users through navigation and mapping services [Averbuch, pgs. 2-3, paras 0030-0031]. Additionally, the feedback and training can provide continuous improvement and help prevent future false positive road event reports [Averbuch, pg. 10, para 0100].
Regarding Claim 15, Lavie as modified discloses the limitations of Claim 11.
Lavie further discloses: (Original) […] wherein the at least one […] vehicle comprises at least two different […] vehicles, and wherein the reporting the event further comprises: comparing events detected from the at least two different […] vehicles. See again [Lavie, FIG. 1 and pg. 4, para 0076], which explains that the central server receives information from multiple clients, or vehicles, to create models, form patterns, and identify indicators for comparing and identifying an event.
Lavie does not explicitly disclose: […] autonomous [vehicle]. However, [Lavie, pg. 1, para 0007], does discuss that autonomous driving systems are used for crowdsourcing road information.
However, Cheng teaches: […] autonomous [vehicle…]. See again [Cheng, pg. 3, para 0024], which explains that the ego vehicle and other vehicles of the system can be autonomous and [Cheng, pg. 6, para 0047], which further explains, in more detail, the autonomous capability of the ego vehicle.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to specify the vehicle as autonomous. Doing so
uses the existing features available on an autonomous vehicle, such as perception and wireless transfer capabilities, to better understand the external environment of the vehicle, improving safety, mobility, and sustainability [Cheng, pg. 9, para 0080].
Regarding Claim 17, Lavie as modified discloses the limitations of Claim 11.
Lavie further discloses: (Currently Amended) […] the detecting the event further comprises: detecting one or more continuous events; and the reporting the the road conditions based on the one or more continuous events. See again [Lavie , pgs. 2-3, paras 0029-0038], which further explains the patterns of driving events, analyzed using multiple datasets over time, and include, for example, hazardous driving, road conditions, or traffic density and [Lavie, pg. 3, paras 0042-0044], which further explains the indicators and assessment used to identify driving events or ongoing driving event, where an ongoing even uses road conditions, for example slowing traffic from an accident. Also see again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients.
Regarding Claim 18, Lavie as modified discloses the limitations of Claim 11.
Lavie further discloses: (Original) […] wherein the detecting the event further comprises: detecting, using a detection machine learning model, the event is present based on the sensor data. See again [0042-0047], which discusses monitoring and assessing patterns and indicators to detect driving events or situations where multi-variate analysis is used to identify or maintain patterns, examples of which include artificial neural networks and machine learning. See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients.
Claims 2-4, 9-10, 12-14, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Lavie in view of Cheng and further in view of Kale et al., PG Pub US-2024/0185067-A1 (herein “Kale”).
Regarding Claim 2, Lavie as modified discloses the limitations of Claim 1.
Lavie does not disclose: (Currently Amended) […] wherein the event reporting server computing system processor is programmed to process, using [[a]] the reporting machine learning model, the event and the sensor data related to the event.
However, Kale teaches: (Currently Amended) […] wherein the event reporting server computing system processor is programmed to process, using [[a]] the reporting machine learning model, the event and the sensor data related to the event. See [Kale, pg. 1, para 0012], which explains that a vehicle uses sensor data and deep learning to provide a report by collecting and storing sensor data, generating a model, using deep learning, to identify events, and provide feedback or a report, “In some implementations, a vehicle may use sensor data and a deep learning device to provide a report to a driver of the vehicle. For example, the vehicle may collect data from vehicle sensors and store a set of inputs received from the sensors in a volatile memory device. One or more processing units coupled with the memory system of the vehicle system may generate a model associated with the environment of the vehicle using the stored sensory inputs. The vehicle may identify events (e.g., a sharp turn, a stop sign, a collision, etc.) using the model, the sensory inputs or both. In some examples, the vehicle may employ a deep learning device to generate an event report using a machine learning model and the set of inputs. The deep learning may be integrated with a memory system of the vehicle. In some examples, the vehicle may transmit the event report to an output device and store the event report in a non-volatile memory device of the memory system. In some examples, the deep learning device may provide feedback or suggestions during the trip (e.g., while the driver is driving), for example using a head up display (HUD). The driver or other interested party may use the generated report to improve driving safety and accountability.” See also [Kale, pg. 9, para 0068], which further explains than an event identification component is used for identifying the events in the sensor data and the event report generation component uses a deep learning device, which uses machine learning to generate a report, and finally the transmission component can transmit the report or a storage component can store the report, “The sensor reception component 525 may be configured as or otherwise support a means for receiving, at a memory system of a vehicle, a set of inputs from one or more sensors of the vehicle. The storage component 530 may be configured as or otherwise support a means for storing the set of inputs in a volatile memory device of the memory system based at least in part on receiving the set of inputs. The event identification component 535 may be configured as or otherwise support a means for identifying, by one or more processing units of the vehicle, an event associated with the vehicle based at least in part on the set of inputs. The event report generation component 540 may be configured as or otherwise support a means for generating, by a deep learning device directly coupled with the memory system of the vehicle, an event report associated with the event, the deep learning device for performing one or more operations using a machine learning model and the set of inputs. The transmission component 545 may be configured as or otherwise support a means for transmitting the event report to an output device associated with the vehicle. In some examples, the storage component 530 may be configured as or otherwise support a means for storing the event report in a non-volatile memory device of the memory system.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Kale to include using a machine learning model to process the data. Doing so allows for sharing more useful and analyzed data to a driver, insurer, law enforcement, etc., especially regarding driver and trip information [Kale, pg.1, paras 0011-0012]. Being able to identify and share more information using the machine learning model also allows for generating a more user-friendly report, such as an interactive report model for the user to examine [Kale, pg. 8, para 0063], or specific feedback that a driver can use for understanding driving behavior or performance or for law enforcement to document a collision [Kale, pg. 1, para 0011].
Regarding Claim 3, Lavie as modified discloses the limitations of Claim 2.
Lavie does not explicitly disclose: (Original) […] wherein the event reporting server computing system processor is programmed to send the event to an external party when a confidence level of the reporting machine learning model is at or above a predefined threshold. However, [Lavie, pg. 2, para 0026], does discuss a confidence interval, however, it is used for identify the probability of an outcome not for transmitting decisions, “Confidence Interval: One method of expressing the probability that an outcome will be observed to happen within a specific range for a given set of circumstances. For example, the probability that the water pump will have to be replaced for shortly after 100,000 miles of driving is 95 percent for a Ford Focus and 92 percent for a BMW 928i.”
However, Cheng teaches: (Original) […] wherein the event reporting server computing system processor is programmed to send the event to an external party when a confidence level of the reporting machine learning model is at or above a predefined threshold. See again [Cheng, pgs. 5-6, paras 0041-0043], which explains that the modules, which receive sensor data from a sensor of vehicle, analyze the captured data to classify objects using a machine learning model and comparing a detected object against an image of an object database, output classification data, and transmit this data as a data summary. And further explains that a predetermined probability or confidence level is used to determine object classification for determination of what data is included and transmitted, “The SSDS module(s) 132 can analyze first environment data captured by the sensor(s) to classify objects detected therein. The SSDS module(s) 132 can use any suitable technique, including, for example, template matching and other kinds of computer vision and/or image processing techniques and/or other artificial or computational intelligence algorithms or machine learning methods. […]. The SSDS module(s) 132 can query the object image database for possible matches. For instance, images in the first environment data can be compared to images in the object image database for possible matches. Alternatively or in addition, measurements or other aspects of the image can be compared to measurements or other aspects of any images in the object image database. The SSDS module(s) 132 can classify the detected object as a particular type of object if there is a match between the captured image and an image in the object database. “Match” or “matches” means that an image or other information in the first environment data and one or more of the images in the object image database are substantially identical. For instance, an image or other information collected by the sensor(s) and one or more of the images in the object image database can match within a predetermined probability (e.g., at least about 85%, at least about 90%, at least about 95% or greater) or confidence level. In one or more arrangements, the detected object can be compared to identifying features of an object, such as color measured visually, shape, size, movement, sounds, etc.]. [0042] The SSDS module(s) 132 can output classification data for the detected objects for inclusion in the data summary 162. […]. As an example, in the data summary 162, the classification data for a detected object can include the type and/or category of the object, the color of the object, the size of the object, a bounding box around the object, the position of the object relative to the ego vehicle 200, a timestamp, and/or information on the sensor(s) that detected the object as described above. [0043] […].The SSDS module(s) 132 can transmit the data summary 162 to the other vehicle(s) 140 or another entity using the transceiver(s) and the communication network(s) 150.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include a confidence level for defining what data is transmitted. Doing so allows for object, or event, classification and confirmation [Cheng, pg. 5, paras 0041] for incorporation into a data summary for sharing, which promotes streamlined sharing of sensor data [Cheng, pg. 2, paras 0014-0015] reducing transferring redundant data [Cheng, pg. 2, para 0016].
Regarding Claim 4, Lavie as modified discloses the limitations of Claim 3.
Lavie discloses: (Original) […] wherein the event reporting server computing system processor is further programmed to receive feedback from an external party. See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients. Also see [Lavie, FIG. 4 and pg. 4, para 0080], which further explains that the client server requests feedback from clients for updated data and clients, containing pertinent information, establish a link with the client server for uploading data, “FIG. 4 describes periodic update of the patterns and indicators stored in the system. Patterns and indicators need to be updated by central server/s. This happens by determining when certain patterns are either too old or new information is available that needs to be incorporated. For example, a new sensor reading may have been determined to be useful in prediction of certain types of events and has previously not been included in the patterns for that event. The central server/s 402 would send out a query for additional information to be used for this update including the type of sensor reading that are needed and other pertinent information 406. Potential clients of interest receive the query and determines if they are a client 404 of interest (have pertinent information) 414. Clients 404 of interest establish a link 416 with the server/s 402 and then upload pertinent information 418. The server/s 402 receives the information 408, and retires older information 410 and re-compute updated patterns and indicators 412.”
Regarding Claim 9, Lavie as modified discloses the limitations of Claim 1.
Lavie does not disclose: (Original) […] wherein the event reporting server computing system processor is further programmed to pull metadata associated with the event.
However, Kale teaches: (Original) […] wherein the event reporting server computing system processor is further programmed to pull metadata associated with the event. See [Kale, pg. 8, para 0062], which explains that the system can identify an extract data associated with the event, “At 430, the memory system may identify and extract metadata associated with the event. For example, the memory system may identify: a speed of the vehicle; speeds of other nearby vehicles; forces experienced by the vehicle (e.g., using and IMU); environmental conditions (e.g., weather conditions, road conditions); or a combination thereof. In some examples, the memory system may generate a report that may include the extracted metadata.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Kale to include pulling the metadata. Doing so allows the data associated with the event to be documented and stored [Kale, pg. 8, para 0062] which allows for generating a more user-friendly report, such as an interactive report model for the user to examine [Kale, pg. 8, para 0063], or specific feedback that a driver can use for understanding driving behavior or performance or for law enforcement to document a collision [Kale, pg. 1, para 0011].
Regarding Claim 10, Lavie as modified discloses the limitations of Claim 9.
Lavie does not disclose: (Original) […] wherein the event reporting server computing system processor is further programmed to at least one of down sample or compress the sensor data and/or the metadata.
However, Cheng teaches: (Original) […] wherein the event reporting server computing system processor is further programmed to at least one of down sample or compress the sensor data and/or the metadata. See [Cheng, pg. 2, para 0016], which explains that the vehicle or server can downsample or compress the sensor data, “The ego vehicle and/or the server can receive the data summary based on the external environment of the other vehicle. The ego vehicle and/or the server can determine whether there is a common region between the external environment of the ego vehicle and the data summary received from the other vehicle. In the case that there is a common region, the ego vehicle and/or the server can downsample and/or compress the sensor data in the common region so as to reduce redundant sensor data being transferred from the ego vehicle to the other vehicle. The ego vehicle and/or the server can transmit the downsampled and/or compressed sensor data along with the remaining sensor data to the other vehicle. The other vehicle can receive the downsampled and/or compressed sensor data and the remaining sensor data from the ego vehicle. The other vehicle can fuse the received sensor data with second environment data to broaden the other vehicle's field of view.”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include compressing and downsampling the sensor data. Doing so allows for streamlined sharing of sensor data [Cheng, pg. 2, paras 0014-0015] and reducing transferring redundant data [Cheng, pg. 2, para 0016], which prepares the data for transfer to, for example, another vehicle [Cheng, pg.8, paras 0066-0067].
Regarding Claim 12, Lavie as modified discloses the limitations of Claim 11.
Lavie does not disclose: (Currently Amended) […] wherein the processing the event further comprises: processing, using [[a]] the reporting machine learning model, the event and the sensor data related to the event.
However, Kale teaches: (Currently Amended) […] wherein the processing the event further comprises: processing, using [[a]] the reporting machine learning model, the event and the sensor data related to the event. See again [Kale, pg. 1, para 0012], which explains that a vehicle uses sensor data and deep learning to provide a report by collecting and storing sensor data, generating a model, using deep learning, to identify events, and provide feedback or a report. Also see again [Kale, pg. 9, para 0068], which further explains than an event identification component is used for identifying the events in the sensor data and the event report generation component uses a deep learning device, which uses machine learning to generate a report, and finally the transmission component can transmit the report or a storage component can store the report.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Kale to include using a machine learning model to process the data. Doing so allows for sharing more useful and analyzed data to a driver, insurer, law enforcement, etc., especially regarding driver and trip information [Kale, pg.1, paras 0011-0012]. Being able to identify and share more information using the machine learning model also allows for generating a more user-friendly report, such as an interactive report model for the user to examine [Kale, pg. 8, para 0063], or specific feedback that a driver can use for understanding driving behavior or performance or for law enforcement to document a collision [Kale, pg. 1, para 0011].
Regarding Claim 13, Lavie as modified discloses the limitations of Claim 12.
Lavie does not explicitly disclose: (Original) […] wherein the reporting the event further comprises: sending the event to an external party when a confidence level of the reporting machine learning model is at or above a predefined threshold. However, [Lavie, pg. 2, para 0026], does discuss a confidence interval, however, it is used for identify the probability of an outcome not for transmitting decisions.
However, Cheng teaches: (Original) […] wherein the reporting the event further comprises: sending the event to an external party when a confidence level of the reporting machine learning model is at or above a predefined threshold. See again [Cheng, pgs. 5-6, paras 0041-0043], which explains that the modules, which receive sensor data from a sensor of vehicle, analyze the captured data to classify objects using a machine learning model and comparing a detected object against an image of an object database, output classification data, and transmit this data as a data summary. And further explains that a predetermined probability or confidence level is used to determine object classification for determination of what data is included and transmitted.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include a confidence level for defining what data is transmitted. Doing so allows for object, or event, classification and confirmation [Cheng, pg. 5, paras 0041] for incorporation into a data summary for sharing, which promotes streamlined sharing of sensor data [Cheng, pg. 2, paras 0014-0015] reducing transferring redundant data [Cheng, pg. 2, para 0016].
Regarding Claim 14, Lavie as modified discloses the limitations of Claim 13.
Lavie further discloses: (Original) […] receiving feedback from an external party. See again [Lavie, FIG. 3 and pg. 4, para 0078], which explains that the client, or vehicle, continuously monitors sensors, detects an event, shares the event data with the central server, where the central server analyzes the received data, and broadcast the information, and possibly request and receive feedback from other clients. Also see [Lavie, FIG. 4 and pg. 4, para 0080], which further explains that the client server requests feedback from clients for updated data and clients, containing pertinent information, establish a link with the client server for uploading data.
Regarding Claim 19, Lavie as modified discloses the limitations of Claim 11.
Lavie does not disclose: (Currently Amended) […] wherein processing the logged sensor data [[event]] further comprises: pulling metadata associated with the event.
However, Kale teaches: (Currently Amended) […] wherein processing the logged sensor data [[event]] further comprises: pulling metadata associated with the event. See [Kale, pg. 8, para 0062], which explains that the system can identify an extract data associated with the event.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Kale to include pulling the metadata. Doing so allows the data associated with the event to be documented and stored [Kale, pg. 8, para 0062] which allows for generating a more user-friendly report, such as an interactive report model for the user to examine [Kale, pg. 8, para 0063], or specific feedback that a driver can use for understanding driving behavior or performance or for law enforcement to document a collision [Kale, pg. 1, para 0011].
Regarding Claim 20, Lavie as modified discloses the limitations of Claim 19.
Lavie does not disclose: (Currently Amended) […] wherein processing the logged sensor data [[event]]further comprises: at least one of down sampling or compressing the sensor data and/or the metadata.
However, Cheng teaches: (Currently Amended) […] wherein processing the logged sensor data [[event]]further comprises: at least one of down sampling or compressing the sensor data and/or the metadata. See [Cheng, pg. 2, para 0016], which explains that the vehicle or server can downsample or compress the sensor data.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Cheng to include compressing and downsampling the sensor data. Doing so allows for streamlined sharing of sensor data [Cheng, pg. 2, paras 0014-0015] and reducing transferring redundant data [Cheng, pg. 2, para 0016], which prepares the data for transfer to, for example, another vehicle [Cheng, pg.8, paras 0066-0067].
Claims 6 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Lavie in view of Cheng and further in view of Moon et al., PG Pub US-2020/0043316-A1 (herein “Moon”).
Regarding Claim 6, Lavie as modified discloses the limitations of Claim 1.
Lavie does not explicitly disclose: (Original) […] wherein the event reporting server computing system processor is programmed to send the event to an external party when a number of occurrences of the event is at or above a predefined threshold. However, [Lavie, pg. 3, para 0042] does discuss that the number of occurrences of an event is tracked against a threshold, “Indicators: Readings from one or more sensors for a given time period and locale that exceed or fall below a specified threshold value indicative or an Event, or Situation. An example of an indicator is exceeding the speed limit.”
However, Moon teaches: (Original) […] wherein the event reporting server computing system processor is programmed to send the event to an external party when a number of occurrences of the event is at or above a predefined threshold. See [Moon, pgs. 4-5, paras 0037-0038], which explains that vehicle mounted sensor data is received at a computing device, which processes the data using a machine learning model or object recognition, to determine if an event threshold has been exceeded and transmit a corrective action or response, such as to a mobile device of a user, “[0037] In addition to the foregoing, once the home-mounted sensor data, vehicle-mounted sensor data, mobile device sensor data, and/or other data (such as weather forecast or weather data) is received at the external computing device 10 via one or more radio links and the communication network 16, the external computing device 10 may apply one or more machine learning, object recognition, or optical character recognition techniques on the data to determine (1) that the sensor or other event data indicates that an event threshold has been exceeded or that an event exists; (2) a geographic boundary for an area impacted by the event (which may be based upon GPS (Global Positioning System) data or coordinates); and/or (3) a corrective action or response to the event, or the estimated or actual extent of the event. [0038] […]. After which, newly received home, mobile device, or vehicle sensor data may be input by the computing device 10 into the trained machine learning program to determine (1) that an event threshold has been exceeded or that an event exists; (2) a geographic boundary for an area impacted by the event; and/or (3) a corrective action or response to the event (such as generate and transmit notifications to user mobile devices (i) recommending that they seek shelter, move out of the way of the event (for a moving whether event); or take alternate routes avoiding the area impacted by the event if traveling by vehicle; and/or (ii) determine an estimated amount of damage to insured assets within the area impacted by the event and prepared a proposed insurance claim for the insured's review and approval via their mobile device).”
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Moon to explicitly track the number of occurrences against a threshold before transmitting. Doing so allows for improving detecting and tracking of events, including the clarity of communications and response efficiency and accuracy, especially in catastrophic events [Moon, pg. 1, paras 0004-0005].
Regarding Claim 16, Lavie as modified discloses the limitations of Claim 11.
Lavie does not explicitly disclose: (Currently Amended) […] wherein the reporting . However, [Lavie, pg. 3, para 0042] does discuss that the number of occurrences of an event is tracked against a threshold.
However, Moon teaches: (Currently Amended) […] wherein the reporting . See again [Moon, pgs. 4-5, paras 0037-0038], which explains that vehicle mounted sensor data is received at a computing device, which processes the data using a machine learning model or object recognition, to determine if an event threshold has been exceeded and transmit a corrective action or response, such as to a mobile device of a user.
It would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to modify Lavie with Moon to explicitly track the number of occurrences against a threshold before transmitting. Doing so allows for improving detecting and tracking of events, including the clarity of communications and response efficiency and accuracy, especially in catastrophic events [Moon, pg. 1, paras 0004-0005].
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 ERIN MARIE HARTMANN whose telephone number is (571)272-5309. The examiner can normally be reached M-F 7-5.
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, Kito Robinson can be reached at (571) 270-3921. 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.
/E.M.H./Examiner, Art Unit 3664
/SHARDUL D PATEL/Primary Examiner, Art Unit 3664
Prosecution Insights