DETAILED ACTION
1. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 02/11/2026 has been entered.
1a. This communication is in response to the request for continued examination filed on 02/11/2026. The present application is being examined under the AIA first to invent provisions.
1b. Status of the claims:
Claims 1 and 11 are amended.
Claims 2 and 12 are canceled.
Claims 1, 3-11, and 13-20 are pending.
Response to Arguments
2. Applicant's arguments filed 05/28/2025 have been fully considered but they are not persuasive.
A, Applicant argues that Fiedler does not disclose, teach or suggest “a controller comprising a communications interface to communicate with a set of sensors and a memory including a buffer to store buffered data, where the controller is configured to, among other features “partitio[n] the buffer into a raw buffer configured to store the buffered data for each sensor in the set, and a filtered buffer configured to store the buffered data for a subset of the sensors in the set,” (Remarks, page 1).
In response to A, The Examiner disagrees because the specification does not give a lot of details about the partition of the buffer. The partition of the buffer is only cited twice. The Examiner has interpreted the partition of the buffer broadly. The data of the vehicle that is put in a designated location of the buffer after being identified as part of the data collected for an accident is interpreted as the buffer data. The remaining of data that was not processed because not relevant for the accident is interpreted as raw data. Fiedler discloses in Fig. 2 and in column 3, lines 51-55 a computer device 200 (the computer device 200 is equated to the controller); Fiedler, discloses in, column 3, lines 51-55, a data interface coupled with sensors; further in column 5, lines 52-55, more details are giving about the sensors that interact with the interface when Fiedler discloses that sensor data that does not indicated a proximate event trigger is ignored ( the buffer section that contains the ignored sensor data that was not filtered is equated as raw buffer by the examiner); finally, Fiedler discloses in column 5, lines 25-29 that record data gathered regarding the driver of a vehicle are not ignored and is stored in the buffered ( sensors data about the grip of the driver on the steering wheel, and the heart fitness of the driver are also recorded (put in the filtered buffer)). As it is illustrated by the above analysis, Fiedler discloses raw data and filtered data; therefore, Fiedler discloses the claim limitations.
B, Applicant argues that “Merwe does not cure the deficiencies of Fiedler," (Remarks, page 2).
In response to B, The Examiner disagrees because Merwe does not have to cure the deficiencies of Fiedler. Fiedler discloses the claim limitations.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:A person shall be entitled to a patent unless -
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
3. Claims 1-8, 10-18, and 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Fiedler et al. (hereinafter “Fiedler”) (US 10,821,991 B1).
Regarding claim 1, Fiedler discloses a controller ( computer device 200 is disclosed (the computer device 200 is equated to the controller) (Fiedler, Fig. 2)) comprising:
a communications interface to communicate with a set of sensors ( a data interface coupled with sensors are disclosed (Fiedler, column 3, lines 51-55));
a memory including a buffer to store buffered data ( a buffer storing amount of buffered data (Fiedler, column 1, lines 55-59)); wherein the controller ( computer device 200 is disclosed (the computer device 200 is equated to the controller) (Fiedler, Fig. 1)) is configured to:
receive, from a server, a first data request ( fig 1 ... mobile devices 140, sensors 122 132 include but are not limited to ... server devices and software/firmware running on one or more of the same (servers) (Fiedler, fig 1 col 3, lines 32-56) ... data may be gathered via physical devices installed on or used in vehicle 121 131 via software and/or sensors natively present in car (see with fig 1 col 3, lines 32-56 - receiving from a server, a first data request), sensors that may be components of other devices (see with fig 1 col 3, lines 32-56 - receiving from a server, a first data request), or systems that are remote from vehicle system 120 130 or mobile device 140 (see with fig 1 col 3, lines 32-56 - receiving from a server, a first data request) (Fiedler, col 4, lines 34-53) ... fig 3 ... for example, at step 301, one or more sensors may continuously or periodically record data into a buffer that stores a certain amount of data (see with fig 1 col 3, lines 32-56 & col 4, lines 34-53 - receiving from a server, a first data request) (Fiedler: fig 3, col 5, lines 12-36);
in response to the first data request, send to the server the buffered data in the buffer (in response to the trigger ( breaking force exceeding a threshold), data sensor is communicating with a server (Fiedler, column 1, lines 45-55)), the buffered data including first sensor data from the sensors in the set ( data gathered from braking forces sensor is disclosed ( data gathered from braking forces is equated to the first sensor data) (Fiedler, column 4, lines 34-44));
obtain, from at least one given sensor in the set (data gathered from a spike rate of a driver heart is disclosed (data gathered from a spike rate of a driver heart is equated to the given sensor in a set of sensors) (Fiedler, column 5, lines 37-43 )), second sensor data detected at the at least one given sensor in the set ( sensor that detects the spike of heart of a person in the vehicle and among other sensor such as break threshold , loud noise.. (Fiedler, column 5, lines 39-50));
update the buffered data in the buffer to include the second sensor data for the at least one given sensor (new sensor data overwrite previous sensor data ( for example the buffer is updated by sensor data about the spike of heart of a person in the vehicle) (Fiedler, column 5, lines 52-63); a sensor about the heart rate of a person in the vehicle previously disclosed in column 5, lines 39-43);
receive, from the server, a second data request (record data after the accident being requested by a central server (Fiedler, column 7, lines 8-11)); and in response to the second data request, send to the server the buffered data in the buffer (record data after the accident being sent to a central server following a request for sensor data in the buffer (Fiedler, column 7, lines 8-11)), the buffered data including the second sensor data for the at least one given sensor in the set and the first sensor data for a remainder of the sensors in the set (sensor data about the heart of a person in the vehicle is part of the data collected after the accident was triggered (given sensor that contains data regarding the accident), and the first sensor data that collects data that is not part of the accident ( remainder such as immediate area, broader area, and weather sensors (Fiedler, column 5, lines 64 -Column 6 lines 1-54)).
wherein the controller partitions the buffer into a raw buffer configured to store the buffered data for each sensor in the set (the sensor data that does not indicated a proximate event trigger are ignored ( the buffer section that contains the ignored sensor data that was not filtered is equated as raw buffer by the examiner) (Fiedler, column 5, lines 52-55)), and a filtered buffer configured to store the buffered data for a subset of the sensors in the set (record data gathered regarding the driver of a vehicle are stored in the buffered ( sensors data about the grip of the driver on the steering wheel, and the heart fitness of the driver are recorded (put in the filtered buffer)) (Fiedler, column 5, lines 25-29)). The specification does not give a lot of details about the partition of the buffer. The partition of the buffer is only cited twice. The Examiner has interpreted the partition of the buffer broadly. The data of the vehicle that is put in a designated location of the buffer after being identified as part of the data collected for an accident is interpreted as the buffer data. The remaining of data that was not processed because not relevant for the accident is interpreted as raw data .
Regarding claim 3, Fiedler discloses the controller of claim 2, wherein the controller is further configured to: obtain buffer configuration data defining criteria for storing the buffered data of the subset of the sensors in the filtered buffer ( the defining criteria is sensor data that is the imagery that triggers the indication of collecting data about an accident in the buffer (Fiedler, column 5, lines 47-51)).
Regarding claim 4, Fiedler discloses the controller of claim 3, wherein, to update the buffered data with the second sensor data, the controller is further configured to: update the raw buffer with the second sensor data for the at least one given sensor in the set; and when the second sensor data meets the criteria defined in the buffer configuration data, update the filtered buffer with the second sensor data for the at least one given sensor in the set ( one or more sensors continuously and periodically record data, and data within five minutes is recorded ( for example data recorder after the event trigger by the accident) (Fiedler, column 7, lines 1-3)).
Regarding claim 5, Fiedler discloses the controller of claim 2, wherein, in response to the first data request and the second data request (record data after the accident being sent to a central server following a request for sensor data in the buffer (Fiedler, column 7, lines 8-11); (record data after the accident being requested by a central server (Fiedler, column 7, lines 8-11)) ), the controller is configured to send the buffered data stored in the filtered buffer to the server ( communicate to a central server from vehicle, sensor data collected after an accident (Fiedler, column 7, lines 1-3 and column 7, lines 15-19)).
Regarding claim 6, Fiedler discloses the controller of claim 1, wherein, in response to the first data request and the second data request, the controller is configured to send a subset of the buffered data stored in the buffer to the server ( communicate to a central server from a vehicle, sensor data before and after an accident (Fiedler, column 7, lines 1-3 and column 7, lines 15-19)) .
Regarding claim 7, Fiedler discloses the controller of claim 1, wherein the controller is further configured to: compare the second sensor data for the at least one given sensor in the set with the first sensor data stored in the buffer for the at least one given sensor to detect a trigger condition ( additional imagery data about rear ended of a vehicle collected from a vehicle is new imagery data (Fiedler, column 6, lines 36-45)); and when the trigger condition is detected, send a notification to a client device ( after the accident detected people with cellular phone are notified (Fiedler, column 6, lines 46-51 )).
Regarding claim 8, Fiedler discloses the controller of claim 1, wherein the controller is configured to iteratively (i) obtain further sensor data detected at further sensors in the set and update the buffered data in the buffer to include the further sensor data for the further sensors ( after the accident (that triggers requested data by the server) detected people with cellular phones are notified (Fiedler, column 6, lines 46-51 )) and (ii) receive subsequent data requests and send the buffered data in response to the subsequent data requests, the buffered data including the further sensor data ( after the accident detected people with cellular phones are notified (Fiedler, column 6, lines 46-51 )).
Regarding claim 10, Fiedler discloses the controller of claim 1, wherein the second sensor data comprises an updated measurement detected at the at least one given sensor ( data measurements are collected y sensors connected to the vehicle after the accident (Fiedler, column 6, lines 13-19).
Regarding claim 11, claim 11 is substantially similar to claim 1, thus the same rationale applies.
Regarding claim 13, claim 13 is substantially similar to claim 3, thus the same rationale applies.
Regarding claim 14, claim 14 is substantially similar to claim 4, thus the same rationale applies.
Regarding claim 15, claim 15 is substantially similar to claim 5, thus the same rationale applies.
Regarding claim 16, claim 16 is substantially similar to claim 6, thus the same rationale applies.
Regarding claim 17, claim 17 is substantially similar to claim 7, thus the same rationale applies.
Regarding claim 18, claim 18 is substantially similar to claim 8, thus the same rationale applies.
Regarding claim 20, claim 20 is substantially similar to claim 10, thus the same rationale applies.
Claim Rejections - 35 USC § 103
4. 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 of this title, 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.
4a. Claims 9 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Fiedler further in view of Merwe et al. (hereinafter “Merwe”) (US 2005/0251328 A1).
Regarding claim 9, Fiedler discloses the controller of claim 1.
Fiedler does not disclose wherein the controller is configured to: receive the first and second data requests from the server at a first rate; and further update the buffered data in the buffer at a second rate, the second rate being different than the first rate.
Merwe discloses wherein the controller is configured to: receive the first and second data requests from the server at a first rate; and further update the buffered data in the buffer at a second rate, the second rate being different than the first rate (updating a bank of sensors data with new data is available where the measurement of data is done at a different rate, Merwe, [0073] and [0074])) .
It would have been obvious to one having ordinary skill in the art before the effective date of the claimed invention to incorporate Merwe’s teachings with Fieldler’s teachings. One skilled in the art would be motivated to combine them in order to update sensor data current in a buffer by updating them as soon they become available.
Regarding claim 19, claim 19 is substantially similar to claim 9, thus the same rationale applies.
Conclusion
5. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARIEGEORGES A HENRY whose telephone number is (571)270-3226. The examiner can normally be reached on 11:00am -8:00pm East M-F.
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, Emmanuel Moise can be reached on 571 272-8365. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MARIEGEORGES A HENRY/Examiner, Art Unit 2455
/ZI YE/ Primary Examiner, Art Unit 2455