DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Notice on Prior Art Rejections
2. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Status of Claims
3. This Office Action is in response to the applicant's arguments/remarks filed November 19, 2025. Claims 1, 10, and 19 have been amended. Claims 1-20 are presently pending and are presented for examination.
Response to Arguments/Remarks
4. 35 USC § 101 rejection: Applicant's arguments/remarks filed November 19, 2025 regarding the 35 USC § 101 rejection have been fully considered. Applicant's arguments are not persuasive. Accordingly, the 35 USC § 101 rejection is maintained.
Applicant argues that “Such actions cannot be "performed in the human mind, or by a human using a pen and paper," as considered by the courts to be a mental process. CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1372, 99 USPQ2d 1690, 1695 (Fed. Cir. 2011). This is especially true considering the computations take place in real time in order to timely generate the verification strategy according to presently determined data. In addition, "generating a verification strategy according to the obstruction and the vehicle movement pattern; selecting a subset of vehicles to verify the obstruction; [and] sending the verification strategy to the subset of vehicles causing the subset of vehicles to collect verification data on the obstruction" are additional elements that integrate any alleged abstract idea into a practical application. Here, a practical application is generating a verification strategy for an ego vehicle to implement according to real-time data to allow the ego vehicle to be routed to encounter, navigate around, and collect verification data on an obstruction.”
Pursuant to MPEP 2106.05(g) Insignificant Extra-Solution Activity [R-10.2019], “The term “extra-solution activity” can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim. Extra-solution activity includes both pre-solution and post-solution activity. An example of pre-solution activity is a step of gathering data for use in a claimed process, e.g., a step of obtaining information about credit card transactions, which is recited as part of a claimed process of analyzing and manipulating the gathered information by a series of steps in order to detect whether the transactions were fraudulent… (3) Whether the limitation amounts to necessary data gathering and outputting, (i.e., all uses of the recited judicial exception require such data gathering or data output). See Mayo, 566 U.S. at 79, 101 USPQ2d at 1968; OIP Techs., Inc. v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1092-93 (Fed. Cir. 2015) (presenting offers and gathering statistics amounted to mere data gathering). This is considered in Step 2A Prong Two and Step 2B. Below are examples of activities that the courts have found to be insignificant extra-solution activity: • Mere Data Gathering”
However, the examiner respectfully disagrees. The limitation steps of Claim 1 that are attributed to a machine learning algorithms are an insignificant extra-solution activity and mere data gathering that is not considered an inventive concept. The examiner considers the data gathering of claim 1 to be insignificant extra-solution activity (Step 2A), and therefore find that the judicial exception is not integrated into a practical application. Accordingly, the 35 USC § 101 rejection is maintained.
5. 35 USC § 103 rejection. Applicant's arguments/remarks filed November 19, 2025 regarding the 35 USC § 103 rejection have been fully considered. Applicant's arguments/amendments are not persuasive. Accordingly, the 35 USC § 103 rejection is maintained.
The applicant argues that “Xu is silent regarding the generation and implementation of a verification strategy by one or more vehicles, where the verification strategy includes instructions for a vehicle(s) to implement to verify a detected obstruction. Xu does not disclose, teach or suggest "generating a verification strategy according to the obstruction and the vehicle movement pattern" and "sending the verification strategy to the subset of vehicles causing the subset of vehicles to operate in accordance with the verification strategy to collect verification data on the obstruction." Accordingly, Shields and Xu, whether considered alone or in combination, do not disclose, teach or suggest the limitations of recited claim 1”
Pursuant to MPEP 2144 Supporting a Rejection Under 35 U.S.C. 103, I. RATIONALE MAY BE IN A REFERENCE, OR REASONED FROM COMMON KNOWLEDGE IN THE ART, SCIENTIFIC PRINCIPLES, ART-RECOGNIZED EQUIVALENTS, OR LEGAL PRECEDENT, “The rationale to modify or combine the prior art does not have to be expressly stated in the prior art; the rationale may be expressly or impliedly contained in the prior art or it may be reasoned from knowledge generally available to one of ordinary skill in the art, established scientific principles, or legal precedent established by prior case law. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988); In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992)”
However, the examiner respectfully disagrees. The new added limitation is expressly or impliedly contained in the prior art. For example, Xu teaches the generation and implementation of a verification strategy by one or more vehicles, where the verification strategy includes instructions for a vehicle(s) to implement to verify a detected obstruction (See at least fig 1-6, ¶ 42, 43, 51, 30, “the blockchain system 300 may include multiple nodes. The nodes may be operated by various users/entities, including, e.g., drivers, passengers, pedestrians, traffic controllers, emergency services providers, autonomous vehicles, and the like”). Xu teaches that the generation and implementation of the verification strategy can be performed by not only vehicles but also by pedestrians, drivers, traffic controllers and the like. In other words, each node that participates in the verification strategy can collect and transmit verification data on the obstruction.
Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Accordingly, the limitations argued by the applicant are expressly or impliedly contained in the prior art as shown. Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Therefore, for the above reasons, the examiner maintains rejection over claims 1-20.
Judicial Exception Claim Rejections - 35 USC § 101
6. 35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
7. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. Claim 1 recites “receiving, from a vehicle, road conditions data; detecting, from the road conditions data, an obstruction; determining a vehicle movement pattern according to the obstruction; generating, using machine learning algorithms, a verification strategy according to the obstruction and the vehicle movement pattern; selecting a subset of vehicles to verify the obstruction; sending the verification strategy to the subset of vehicles causing the subset of vehicles to collect verification data on the obstruction; receiving the verification data on the obstruction from the subset of vehicles; and verifying the obstruction based on the verification data.”.
The limitations of claim 1 presented above, as drafted, are processes that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “a vehicle” nothing in the claims elements precludes the steps from practically being performed as part of human activities. For example, “receiving, from a vehicle, road conditions data”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind where a person is mentally able to observe road conditions. Further, “detecting, from the road conditions data, an obstruction”, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind where a person is mentally able to observe if there is an obstruction on a road. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. For example, “verifying the obstruction based on the verification data” is not a practical application because it is a mere instruction to apply the judicial exception using generic elements. In particular, the claim does not recite any additional elements that integrate the abstract idea into a practical application. Accordingly, the claim lack of additional elements that integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
The claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, there are no additional elements that integrate the abstract idea into a practical application. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept. The claim is not patent eligible. The independent claims 2-9 are also rejected for their dependency upon claim 1. Further, claims 10-20 are also rejected because they amount no more than the same mere instructions of the method of claim 1 in a system which does not impose any meaningful limits on practicing the abstract idea.
Claim Rejections - 35 USC § 103
8. 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.
9. Claims 1-20 are rejected under 35 U.S.C 103 as being unpatentable over Shields et al, US 11,530,925, in view of Xu et al. US 2021/0281980, hereinafter referred to as Shields and Xu, respectively.
Regarding claim 1, Shields discloses a computer implemented method for detecting and verifying obstructions on a road, the method comprising:
receiving, from a vehicle, road conditions data (See at least col 11, lines 30-40, “The vehicle 230a also may include one or more cameras and proximity sensors 233 capable of recording additional conditions inside or outside of the vehicle 230a. Internal cameras 230 may detect conditions such as the number of the passengers in the vehicle 230a, and potential sources of driver distraction within the vehicle ( e.g., pets, phone usage, unsecured objects in the vehicle). External cameras and proximity sensors 233 may detect other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving event data analysis”);
detecting, from the road conditions data, an obstruction (See at least col 6, lines 40-65, “the hazard detection module 112a may receive data from various internal and external sources (e.g., vehicle data, mobile device data, other sensor data, environmental data, historical data, and the like) and may analyze the data to determine whether a hazard or obstruction exists.”);
determining a vehicle movement pattern according to the obstruction (See at least col 3, lines 1-20, “In some arrangements, the data may be analyzed to identify the hazard or obstruction by evaluating data related to driving behaviors (e.g., telematics data, other sensor data, and the like), to identify instances of swerving, hard braking, bumping due to pot holes (e.g., based on accelerometer data), lane deviations, sudden speed changes, stopped vehicles, road smoothness, and the like. In some arrangements, machine learning may be used to analyze the data”);
generating, using machine learning algorithms, a verification strategy according to the obstruction and the vehicle movement pattern (See at least col 8, lines 7-35, “the machine learning engine 112f may analyze data to identify patterns of activity, sequences of activity, and the like, to generate one or more machine learning datasets”), (See at least col 16, lines 50-67, “the received sensor data and response data may be analyzed to detect, identify and/or corroborate identification of a hazard detected within the sensor data. For instance, in some examples, the sensor data may be aggregated with the response data and, in some examples, machine learning datasets may be used to determine that a hazard was detected, identify a type of hazard”);
selecting a subset of vehicles to verify the obstruction (See at least col 20, lines 39-67, “the sensor data may be aggregated with data from a plurality of other sources and that data may be analyzed to detect or determine that a hazard exists, identify a type of hazard, and the like. In some examples, the additional data may include data from other vehicles near the vehicle or mobile device capturing the sensor data”);
sending the verification strategy to the subset of vehicles causing the subset of vehicles to collect verification data on the obstruction (See at least col 20, lines 39-67, “data transmitted from other vehicles may be transmitted using a messaging protocol configured for sharing real-time telematics or other data. For instance, the messaging protocol may enable making information accessible to others in an application-to-application communication scenario in real-time. In some examples, an application executing on a mobile device (e.g., application 252) or a computing device within a vehicle (e.g., application 232) may facilitate communication of data between devices”);
receiving the verification data on the obstruction from the subset of vehicles (See at least col 15, lines 20-50, “In some examples, the city-based intelligence data, as well as other external and internal data, may be used to determine that a hazard exists, identify the hazard, and/or corroborate detection or identification of a hazard based on sensor data”); and
verifying the obstruction based on the verification data (See at least col 8, lines 28-50, “The machine learning datasets 112g may be updated and/or validated based on later-received data. For instance, as additional data collected from subsequent hazard evaluation or detection incidents may be used to validate and/or update the machine learning datasets 112g based on the newly received information. Accordingly, the system may continuously refine determinations, outputs, and the like”).
Shields fails to explicitly discloses a verification strategy.
However, Xu discloses a verification strategy (See at least fig 1-6, ¶ 30, 34, 35, 36, 37, 38, 40, 44, 45, 46, 47, 50, 52, 32, “Node A may submit the verification request using various communication technologies, including, e.g., vehicle-to-everything (V2X) communication technologies as well as other wired or wireless communication technologies. In some embodiments, Node A may submit the verification request automatically when the event is detected.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Shields and include a verification strategy as taught by Xu because it would allow the methods and devices to operate with improved accuracy and it may support verification of the occurrence of the event prior to broadcasting the event (Xu ¶ 15).
Regarding claim 2, Shields discloses the method of claim 1, wherein the road conditions data is obtained from a sensor of the vehicle (See at least col 11, lines 30-40, “The vehicle 230a also may include one or more cameras and proximity sensors 233 capable of recording additional conditions inside or outside of the vehicle 230a. Internal cameras 230 may detect conditions such as the number of the passengers in the vehicle 230a, and potential sources of driver distraction within the vehicle ( e.g., pets, phone usage, unsecured objects in the vehicle). External cameras and proximity sensors 233 may detect other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving event data analysis”).
Regarding claim 3, Shields discloses the method of claim 2, wherein the sensor comprises at least one of a camera, image sensor, radar sensor, light detection and ranging (LiDAR) sensor, position sensor, audio sensor, infrared sensor, microwave sensor, optical sensor, haptic sensor, magnetometer, communication system and global positioning system (GPS) (See at least col 10, lines 57-67, “data from sensors 233 (e.g., I-axis, 2-axis, or 3-axis accelerometers, compasses, speedometers, vibration sensors, pressure sensors, gyroscopic sensors, etc.) and/or GPS receivers or other location-based services (LBS) 234, may be used by, for example, application 232 (or other device or module, e.g., hazard detection and broadcast control server 210) to determine movement of the vehicle”).
Regarding claim 4, Shields discloses the method of claim 1, wherein the obstruction comprises at least one of a pothole, crack, tire marking, faded road marking, debris, objects, occlusion, road reflection, flooding, ice, oil leak, uneven pavement, erosion and raveling (See at least col 3, lines 1-21, “the data may be analyzed to identify a pothole in a particular location along a road. In another example, the data may be analyzed to identify traffic congestion or an accident. In yet another example, the data may be analyzed to identify debris at a particular location in or along a road that may, for example, cause drivers to swerve or brake hard.”).
Regarding claim 5, Shields discloses the method of claim 1, wherein the selecting the subset of vehicles comprises: determining a first vehicle within a distance threshold to the obstruction; and determining the first vehicle comprises a sensor capable of collecting the verification data on the obstruction (See at least col 17, lines 14-39, “group may include a single user or individual. Further, a group maybe identified in real-time based on proximity of one or more vehicles to a vehicle detecting a hazard (e.g., all vehicles within 100 feet, 1000 meters, 1 mile, or the like may be identified, in real-time, as a group). At step 322, one or more groups associated with the identified hazard may be identified. For instance, a group of users or vehicles within a predefined proximity of the detecting vehicle may be identified in real-time”).
Regarding claim 6, Shields discloses the method of claim 1, wherein the selecting the subset of vehicles comprises: determining a first vehicle enroute to the obstruction; and determining the first vehicle comprises a sensor capable of collecting the verification data on the obstruction (See at least col 16, lines 55-65, “Additionally or alternatively, data from other vehicles ( e.g., within a predefined proximity of a first vehicle) may be evaluated to determine stopped vehicles, slowed traffic, or the like. Further, data related to bumps in a road (e.g., based on accelerometer data) may be evaluated to identify potholes, debris, or the like. Data related to road smoothness (e.g., based on a smooth ride factor determined from data related to other hazards and debris, vehicle noise levels on a road or road segment, and the like) may also be used to identify a hazard or obstruction”).
Regarding claim 7, Shields discloses the method of claim 1, wherein the vehicle movement pattern is updated according to driving data of vehicles encountering the obstruction (See at least col 7, lines 15-30, “Driving behavior evaluation module 112c may store instructions and/or data that may cause or enable the hazard detection and broadcast computing platform 110 to receiving driving data ( e.g., on board vehicle diagnostic data, telematics data, sensor data from a vehicle or mobile device, or the like) and analyze the data to identify behaviors or patterns in the data. These driving behaviors may be used to identify and generate groups, identify users 25 to receiving a notification, and the like”).
Regarding claim 8, Shields discloses the method of claim 1, wherein the verification strategy comprises: routing each of the subset of vehicles to encounter the obstruction; navigating each of the subset of vehicles around the obstruction according to the vehicle movement pattern; and collecting the verification data on the obstruction from each of the subset of vehicles according to the navigation, wherein the verification data is collected by a sensor of each of the subset of vehicles (See at least col 20, lines 10-25, “the notification may include identification of an alternate route. The notifications may provide information about the identified hazard (e.g.,
type of hazard, location, and the like). In some examples, the notifications may include various selectable options to reroute a user, generate a different alternate route, provide
driving behavior recommendations (e.g., as shown in FIG. 6B), and the like”).
Regarding claim 9, Shields discloses the method of claim 1, further comprising updating the obstruction based on the verification of the obstruction (See at least col 8, lines 28-50, “The machine learning datasets 112g may be updated and/or validated based on later-received data. For instance, as additional data collected from subsequent hazard evaluation or detection incidents may be used to validate and/or update the machine learning datasets 112g based on the newly received information. Accordingly, the system may continuously refine determinations, outputs, and the like”).
Regarding claim 10, Shields discloses a computing system for detecting and verifying obstructions on a road comprising: one or more processors; and memory coupled to the one or more processors to store instructions, which when executed by the one or more processors, cause the one or more processors to perform operations, the operations comprising:
receiving, from a vehicle, road conditions data (See at least col 11, lines 30-40, “The vehicle 230a also may include one or more cameras and proximity sensors 233 capable of recording additional conditions inside or outside of the vehicle 230a. Internal cameras 230 may detect conditions such as the number of the passengers in the vehicle 230a, and potential sources of driver distraction within the vehicle ( e.g., pets, phone usage, unsecured objects in the vehicle). External cameras and proximity sensors 233 may detect other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving event data analysis”);
detecting, from the road conditions data, an obstruction (See at least col 6, lines 40-65, “the hazard detection module 112a may receive data from various internal and external sources (e.g., vehicle data, mobile device data, other sensor data, environmental data, historical data, and the like) and may analyze the data to determine whether a hazard or obstruction exists.”);
determining a vehicle movement pattern according to the obstruction (See at least col 3, lines 1-20, “In some arrangements, the data may be analyzed to identify the hazard or obstruction by evaluating data related to driving behaviors (e.g., telematics data, other sensor data, and the like), to identify instances of swerving, hard braking, bumping due to pot holes (e.g., based on accelerometer data), lane deviations, sudden speed changes, stopped vehicles, road smoothness, and the like. In some arrangements, machine learning may be used to analyze the data”);
generating, using machine learning algorithms, a verification strategy according to the obstruction and the vehicle movement pattern (See at least col 8, lines 7-35, “the machine learning engine 112f may analyze data to identify patterns of activity, sequences of activity, and the like, to generate one or more machine learning datasets”), (See at least col 16, lines 50-67, “the received sensor data and response data may be analyzed to detect, identify and/or corroborate identification of a hazard detected within the sensor data. For instance, in some examples, the sensor data may be aggregated with the response data and, in some examples, machine learning datasets may be used to determine that a hazard was detected, identify a type of hazard”);
selecting a subset of vehicles to verify the obstruction (See at least col 20, lines 39-67, “the sensor data may be aggregated with data from a plurality of other sources and that data may be analyzed to detect or determine that a hazard exists, identify a type of hazard, and the like. In some examples, the additional data may include data from other vehicles near the vehicle or mobile device capturing the sensor data”);
sending the verification strategy to the subset of vehicles causing the subset of vehicles to collect verification data on the obstruction (See at least col 20, lines 39-67, “data transmitted from other vehicles may be transmitted using a messaging protocol configured for sharing real-time telematics or other data. For instance, the messaging protocol may enable making information accessible to others in an application-to-application communication scenario in real-time. In some examples, an application executing on a mobile device (e.g., application 252) or a computing device within a vehicle (e.g., application 232) may facilitate communication of data between devices”);
receiving the verification data on the obstruction from the subset of vehicles (See at least col 15, lines 20-50, “In some examples, the city-based intelligence data, as well as other external and internal data, may be used to determine that a hazard exists, identify the hazard, and/or corroborate detection or identification of a hazard based on sensor data”); and
verifying the obstruction based on the verification data (See at least col 8, lines 28-50, “The machine learning datasets 112g may be updated and/or validated based on later-received data. For instance, as additional data collected from subsequent hazard evaluation or detection incidents may be used to validate and/or update the machine learning datasets 112g based on the newly received information. Accordingly, the system may continuously refine determinations, outputs, and the like”).
Shields fails to explicitly discloses a verification strategy.
However, Xu discloses a verification strategy (See at least fig 1-6, ¶ 30, 34, 35, 36, 37, 38, 40, 44, 45, 46, 47, 50, 52, 32, “Node A may submit the verification request using various communication technologies, including, e.g., vehicle-to-everything (V2X) communication technologies as well as other wired or wireless communication technologies. In some embodiments, Node A may submit the verification request automatically when the event is detected.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shields and include a verification strategy as taught by Xu because it would allow the methods and devices to operate with improved accuracy and it may support verification of the occurrence of the event prior to broadcasting the event (Xu ¶ 15).
Regarding claim 11, Shields discloses the computing system of claim 10, wherein the road conditions data is obtained from a sensor of the vehicle (See at least col 11, lines 30-40, “The vehicle 230a also may include one or more cameras and proximity sensors 233 capable of recording additional conditions inside or outside of the vehicle 230a. Internal cameras 230 may detect conditions such as the number of the passengers in the vehicle 230a, and potential sources of driver distraction within the vehicle ( e.g., pets, phone usage, unsecured objects in the vehicle). External cameras and proximity sensors 233 may detect other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving event data analysis”).
Regarding claim 12, Shields discloses the computing system of claim 11, wherein the sensor comprises at least one of a camera, image sensor, radar sensor, light detection and ranging (LiDAR) sensor, position sensor, audio sensor, infrared sensor, microwave sensor, optical sensor, haptic sensor, magnetometer, communication system and global positioning system (GPS) (See at least col 10, lines 57-67, “data from sensors 233 (e.g., I-axis, 2-axis, or 3-axis accelerometers, compasses, speedometers, vibration sensors, pressure sensors, gyroscopic sensors, etc.) and/or GPS receivers or other location-based services (LBS) 234, may be used by, for example, application 232 (or other device or module, e.g., hazard detection and broadcast control server 210) to determine movement of the vehicle”).
Regarding claim 13, Shields discloses the computing system of claim 10, wherein the obstruction comprises at least one of a pothole, crack, tire marking, faded road marking, debris, objects, occlusion, road reflection, flooding, ice, oil leak, uneven pavement, erosion and raveling (See at least col 3, lines 1-21, “the data may be analyzed to identify a pothole in a particular location along a road. In another example, the data may be analyzed to identify traffic congestion or an accident. In yet another example, the data may be analyzed to identify debris at a particular location in or along a road that may, for example, cause drivers to swerve or brake hard.”).
Regarding claim 14, Shields discloses the computing system of claim 10, wherein the selecting the subset of vehicles comprises: determining a first vehicle within a distance threshold to the obstruction; and determining the first vehicle comprises a sensor capable of collecting the verification data on the obstruction (See at least col 17, lines 14-39, “group may include a single user or individual. Further, a group maybe identified in real-time based on proximity of one or more vehicles to a vehicle detecting a hazard (e.g., all vehicles within 100 feet, 1000 meters, 1 mile, or the like may be identified, in real-time, as a group). At step 322, one or more groups associated with the identified hazard may be identified. For instance, a group of users or vehicles within a predefined proximity of the detecting vehicle may be identified in real-time”).
Regarding claim 15, Shields discloses the computing system of claim 10, wherein the selecting the subset of vehicles comprises: determining a first vehicle enroute to the obstruction; and determining the first vehicle comprises a sensor capable of collecting the verification data on the obstruction (See at least col 16, lines 55-65, “Additionally or alternatively, data from other vehicles ( e.g., within a predefined proximity of a first vehicle) may be evaluated to determine stopped vehicles, slowed traffic, or the like. Further, data related to bumps in a road (e.g., based on accelerometer data) may be evaluated to identify potholes, debris, or the like. Data related to road smoothness (e.g., based on a smooth ride factor determined from data related to other hazards and debris, vehicle noise levels on a road or road segment, and the like) may also be used to identify a hazard or obstruction”).
Regarding claim 16, Shields discloses the computing system of claim 10, wherein the vehicle movement pattern is updated according to driving data of vehicles encountering the obstruction (See at least col 7, lines 15-30, “Driving behavior evaluation module 112c may store instructions and/or data that may cause or enable the hazard detection and broadcast computing platform 110 to receiving driving data ( e.g., on board vehicle diagnostic data, telematics data, sensor data from a vehicle or mobile device, or the like) and analyze the data to identify behaviors or patterns in the data. These driving behaviors may be used to identify and generate groups, identify users 25 to receiving a notification, and the like”).
Regarding claim 17, Shields discloses the computing system of claim 10, wherein the verification strategy comprises: routing each of the subset of vehicles to encounter the obstruction; navigating each of the subset of vehicles around the obstruction according to the vehicle movement pattern; and collecting the verification data on the obstruction from each of the subset of vehicles according to the navigation, wherein the verification data is collected by a sensor of each of the subset of vehicles (See at least col 20, lines 10-25, “the notification may include identification of an alternate route. The notifications may provide information about the identified hazard (e.g., type of hazard, location, and the like). In some examples, the notifications may include various selectable options to reroute a user, generate a different alternate route, provide driving behavior recommendations (e.g., as shown in FIG. 6B), and the like”).
Regarding claim 18, Shields discloses the computing system of claim 10, further comprising updating the obstruction based on the verification of the obstruction (See at least col 8, lines 28-50, “The machine learning datasets 112g may be updated and/or validated based on later-received data. For instance, as additional data collected from subsequent hazard evaluation or detection incidents may be used to validate and/or update the machine learning datasets 112g based on the newly received information. Accordingly, the system may continuously refine determinations, outputs, and the like”).
Regarding claim 19, Shields discloses a non-transitory machine-readable medium having instructions stored therein, which when executed by a processor, cause the processor to perform operations, the operations comprising:
receiving road conditions data from a vehicle (See at least col 11, lines 30-40, “The vehicle 230a also may include one or more cameras and proximity sensors 233 capable of recording additional conditions inside or outside of the vehicle 230a. Internal cameras 230 may detect conditions such as the number of the passengers in the vehicle 230a, and potential sources of driver distraction within the vehicle ( e.g., pets, phone usage, unsecured objects in the vehicle). External cameras and proximity sensors 233 may detect other nearby vehicles, traffic levels, road conditions, traffic obstructions, animals, cyclists, pedestrians, and other conditions that may factor into a driving event data analysis”);
detecting an obstruction based on the road conditions data (See at least col 6, lines 40-65, “the hazard detection module 112a may receive data from various internal and external sources (e.g., vehicle data, mobile device data, other sensor data, environmental data, historical data, and the like) and may analyze the data to determine whether a hazard or obstruction exists.”);
determining a vehicle movement pattern according to the obstruction (See at least col 3, lines 1-20, “In some arrangements, the data may be analyzed to identify the hazard or obstruction by evaluating data related to driving behaviors (e.g., telematics data, other sensor data, and the like), to identify instances of swerving, hard braking, bumping due to pot holes (e.g., based on accelerometer data), lane deviations, sudden speed changes, stopped vehicles, road smoothness, and the like. In some arrangements, machine learning may be used to analyze the data”);
generating, using machine learning algorithms, a verification strategy according to the obstruction and the vehicle movement pattern (See at least col 8, lines 7-35, “the machine learning engine 112f may analyze data to identify patterns of activity, sequences of activity, and the like, to generate one or more machine learning datasets”), (See at least col 16, lines 50-67, “the received sensor data and response data may be analyzed to detect, identify and/or corroborate identification of a hazard detected within the sensor data. For instance, in some examples, the sensor data may be aggregated with the response data and, in some examples, machine learning datasets may be used to determine that a hazard was detected, identify a type of hazard”);
selecting a subset of vehicles to verify the obstruction (See at least col 20, lines 39-67, “the sensor data may be aggregated with data from a plurality of other sources and that data may be analyzed to detect or determine that a hazard exists, identify a type of hazard, and the like. In some examples, the additional data may include data from other vehicles near the vehicle or mobile device capturing the sensor data”);
sending the verification strategy to the subset of vehicles causing the subset of vehicles to collect verification data on the obstruction (See at least col 20, lines 39-67, “data transmitted from other vehicles may be transmitted using a messaging protocol configured for sharing real-time telematics or other data. For instance, the messaging protocol may enable making information accessible to others in an application-to-application communication scenario in real-time. In some examples, an application executing on a mobile device (e.g., application 252) or a computing device within a vehicle (e.g., application 232) may facilitate communication of data between devices”);
receiving the verification data on the obstruction from the subset of vehicles (See at least col 15, lines 20-50, “In some examples, the city-based intelligence data, as well as other external and internal data, may be used to determine that a hazard exists, identify the hazard, and/or corroborate detection or identification of a hazard based on sensor data”); and
verifying the obstruction based on the verification data (See at least col 8, lines 28-50, “The machine learning datasets 112g may be updated and/or validated based on later-received data. For instance, as additional data collected from subsequent hazard evaluation or detection incidents may be used to validate and/or update the machine learning datasets 112g based on the newly received information. Accordingly, the system may continuously refine determinations, outputs, and the like”).
Shields fails to explicitly discloses a verification strategy.
However, Xu discloses a verification strategy (See at least fig 1-6, ¶ 30, 34, 35, 36, 37, 38, 40, 44, 45, 46, 47, 50, 52, 32, “Node A may submit the verification request using various communication technologies, including, e.g., vehicle-to-everything (V2X) communication technologies as well as other wired or wireless communication technologies. In some embodiments, Node A may submit the verification request automatically when the event is detected.”).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Shields and include a verification strategy as taught by Xu because it would allow the methods and devices to operate with improved accuracy and it may support verification of the occurrence of the event prior to broadcasting the event (Xu ¶ 15).
Regarding claim 20, Shields discloses the non-transitory machine-readable medium of claim 19, wherein the verification strategy comprises: routing each of the subset of vehicles to encounter the obstruction; navigating each of the subset of vehicles around the obstruction according to the vehicle movement pattern; and collecting the verification data on the obstruction from each of the subset of vehicles according to the navigation, wherein the verification data is collected by a sensor of each of the subset of vehicles (See at least col 20, lines 10-25, “the notification may include identification of an alternate route. The notifications may provide information about the identified hazard (e.g., type of hazard, location, and the like). In some examples, the notifications may include various selectable options to reroute a user, generate a different alternate route, provide driving behavior recommendations (e.g., as shown in FIG. 6B), and the like”).
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LUIS MARTINEZ whose email is luis.martinezborrero@uspto.gov and telephone number is (571)272-4577. The examiner can normally be reached on Monday-Friday 8:30AM-5:00PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, HUNTER LONSBERRY can be reached on (571)272-7298. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/LUIS A MARTINEZ BORRERO/Primary Examiner, Art Unit 3665