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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
Road condition analysis part: The “road condition analysis part” is broadly construed as a hardware/software module that analyzes road conditions from image or sensor data when a driver’s pattern is outside the normal range. Specification support is found in [0008], [0037], and [0050], with constituent details in [0038]–[0043] and [0051]–[0058].
Safe driving index reflection part: The “safe driving index reflection part” is construed as a module that determines whether a driver’s actions were appropriate and transmits the result data to adjust the safe driving index. Defined in [0008], [0037], [0059], with details in [0044]–[0047] and [0060]–[0064].
Location information transmission part: The “location information transmission part” is construed as a component that transmits vehicle GPS/location data when no camera is installed. Specification support in [0011], [0042], and [0056].
Driving pattern analysis part: The “driving pattern analysis part” is interpreted as a module classifying driving behavior as abnormal by comparing sensor values to a preset threshold. Defined in [0009], [0038], and [0053].
Obstacle information transmission part: The “obstacle information transmission part” is broadly construed as a module transmitting obstacle information (size, location, lane, time). Defined in [0012], [0043], [0057]–[0058].
Data generation part: The “data generation part” is construed as a module generating structured result data for transmission to the management server. Defined in [0013], [0044]–[0045], [0060], [0062]–[0064].
Follow-up action reflection part: The “follow-up action reflection part” is construed as a component detecting hazard light flashing and transmitting this state to the data generation part. Defined in [0014], [0046]–[0047], [0061]–[0063].
Auxiliary analysis part: The “auxiliary analysis part” is construed as a module in a following vehicle analyzing road conditions at a preceding vehicle’s reported location using its own camera data. Defined in [0015], [0048], [0067].
Auxiliary index reflection part: The “auxiliary index reflection part” is construed as a module in a following vehicle determining the appropriateness of a preceding driver’s behavior and transmitting result data. Defined in [0015], [0048], [0068].
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 101
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.
Claims 1–3, 5, 8–12, and 14–17, 19 and 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (an abstract idea) and the claims do not recite additional elements that integrate the exception into a practical application; nor do they recite significantly more than the exception.
Step 1 – Statutory Category
The claims recite a vehicle (a machine) and methods (processes), and therefore fall within statutory categories.
Step 2A, Prong 1 – The Claims Are Directed to an Abstract Idea
The claims recite collecting, analyzing, and communicating driving/environment information to generate/adjust a driver safety score (safe driving index) and to communicate obstacle information for downstream action.
This is consistent with the application’s stated use and purpose: a driver’s driving pattern is used for automobile insurance and various applications, and the safe driving index may be adjusted upwards or downwards based on driving patterns.
More specifically, the claims recite, in substance:
analyzing road conditions shown in image data and using that analysis to determine whether a driving pattern is appropriate, then transmitting result data for score adjustment (safe driving index);
generating/transmitting result data so that the management server increases the safe driving index when the driving pattern is appropriate;
using hazard light information (flashing to inform following vehicles) as part of result data to support increasing the safe driving index;
transmitting obstacle-related information (size/location/lane/time), collecting it by timestamp, determining whether the obstacle is moving, and transmitting the obstacle-related information to a second vehicle.
These are information processing steps: (i) gathering data, (ii) analyzing/classifying data, and (iii) transmitting the analysis results (including score adjustments). Such claims are directed to an abstract idea.
Step 2A, Prong 2 – The Claims Are Not Integrated Into a Practical Application
Although the claims include vehicle-context elements (camera, sensors, server, inter-vehicle communication) and recite that a second vehicle “avoid[s] the obstacle,” the claim language and specification describe this at a results-oriented, functional level—i.e., what is achieved (avoidance) rather than how the vehicle-control mechanics are performed.
The “avoid obstacle” limitation does not add concrete vehicle-control mechanics
The specification explains the second-vehicle feature as server-mediated information delivery to other vehicles, stated in functional outcome terms:
“the management server … transmit[s] the obstacle-related information to another vehicle (e.g., the second vehicle …), thereby effectively avoiding the obstacle S.”
“Thus, an accident may be prevented.”
Critically, neither the claim nor these passages recite specific autonomous control operations (e.g., a defined steering/braking actuation algorithm, control laws, trajectory generation, closed-loop control, or actuator command outputs). Instead, the “avoid” language is satisfied by the second vehicle receiving obstacle-related information and then “avoid[ing]” based on that information—an end result that can be implemented as:
driver-assist (warning/display prompting a driver action), or
autonomous response, but without any claimed mechanism.
Accordingly, even accepting the broadest reasonable reading that “avoid” could encompass automatic avoidance, the claim remains results-oriented as to obstacle avoidance because it does not claim how the obstacle is avoided—only that obstacle information is communicated and the avoidance outcome occurs.
Field-of-use and generic implementation do not integrate the abstract idea
The claims apply the information-processing idea in a vehicle setting, but do so by:
using conventional data sources (camera/sensors),
transmitting data to a remote server,
generating “result data” to adjust a “safe driving index,” and
communicating obstacle-related information to other vehicles, culminating in the aspirational “avoid” outcome.
This is not an improvement to computer functionality or vehicle-control technology; it is the abstract idea applied in a vehicle environment.
Therefore, the judicial exception is not integrated into a practical application.
Step 2B – No Inventive Concept (Not “Significantly More”)
The claims do not include additional elements that amount to significantly more than the abstract idea because the additional elements recite generic components performing their expected functions to implement the scoring/communication scheme.
The specification itself frames the “safe driving index” concept as an indicator used to adjust a driver score upward/downward based on driving patterns, and motivates the invention as determining whether driving behavior was appropriate to road conditions so that the index can be adjusted.
Likewise, the “increase” logic is presented as straightforward score adjustment when appropriateness is found:
“generate the result data so that the management server increases the driver’s safe driving index, when the driver’s driving pattern is determined to be appropriate for the road condition.”
And the hazard-light-based score increase is presented as awarding score credit for a signaling behavior:
“information about whether hazard lights flash … to inform a following vehicle of the road condition … generate the result data including the information … so that the management server increases the driver’s safe driving index.”
The obstacle-sharing feature similarly recites collecting/classifying/transmitting obstacle-related information and then the second vehicle “avoiding” based on that information—again stated as a functional result, not a concrete control technique.
Taken individually and as an ordered combination, these elements amount to implementing the abstract idea using conventional data capture, analysis, scoring, and network communication, with a results-oriented “avoid obstacle” outcome. There is no additional element (or combination) that transforms the nature of the claim into a patent-eligible application.
101 Analysis Conclusion
Accordingly, Claims 1–3, 5, 8–12, 14–17, 19, and 20 are rejected under 35 U.S.C. 101 as being directed to an abstract idea (information collection/analysis/communication for driver scoring and hazard/obstacle reporting), not integrated into a practical application, and lacking additional elements that amount to significantly more, including because the “avoid obstacle” recitation is functional/results-oriented and does not claim specific vehicle-control mechanics.
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-3, 5, 8, 9, 11, 14, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Brinkmann, in view of Chen (WO 2021/121180 A1), in view of Nemat-Nasser (US 9344683 B1), and in view of Lin (US 20200174493 A1) .
Regarding Claim 1,
Disclosure by Brinkmann
Brinkmann discloses:
A vehicle
See at least: "The driving analysis system 200 shown in FIG. 2 includes a vehicle 210, such as an automobile, motorcycle, or other vehicle" (Column 5, lines 8-10)
Rationale: Brinkmann discloses a vehicle such as an automobile as shown in the system of Fig. 2.
comprising:
See at least: "The vehicle 210 may include vehicle operation sensors 212" (Column 5, lines 12)
Rationale: Brinkmann discloses a vehicle comprising or including various sensors and modules.
a road condition analysis part
See at least: "driving analysis module 221" (Column 7, line 36)
Rationale: Brinkmann discloses a road condition analysis part in the form of a driving analysis module.
configured to analyze a road condition
See at least: "driving analysis module 221 may use... additional image data... perform driving event analyses... to determine that the braking , swerving , or impact was caused by one or more of : an obstruction in the path in the vehicle 210 ; adverse road conditions " (Column 7, lines 44-48 and Column 12, lines 16-19)
Rationale: Brinkmann discloses that the module is configured to analyze a road condition to determine if it caused a driving event.
shown in image data
See at least: "The driving analysis server also may receive corresponding image data" (Abstract)
Rationale: Brinkmann discloses that environmental context and road conditions are shown in image data received by the server.
captured by a camera
See at least: "The vehicle 210 also may include one or more cameras... configured to transmit data" (Column 5, lines 38)
Rationale: Brinkmann discloses that image data is captured by a camera installed on the vehicle.
based on a driving pattern of a driver,
See at least: "identify an occurrence of a sudden swerving, sudden braking, or vehicle impact event by the vehicle 210... identify the driving event by analyzing only the vehicle operation data" (Column 15, lines 31-38…Column 9, lines 44-45)
Rationale: Brinkmann discloses analyzing a driving pattern of a driver (e.g., sudden braking or swerving) using operational data.
which is out of a normal range during driving,
See at least: "Based on the vehicle operational data, the driving analysis server may be configured to identify one or more potentially high - risk or unsafe driving events at a vehicle, for example, an occurrence of sudden braking or swerving, an impact to the vehicle, speeding, or a moving violation." (Column 2, line 6-11)
Rationale: Brinkmann discloses identifying events like sudden braking or high-risk maneuvers which is out of a normal range during driving.
and a safe driving index reflection part
See at least: "driver score calculation module 222" (Fig. 2)
Rationale: Brinkmann discloses a safe driving index reflection part in the form of a module that calculates and updates driver scores.
configured to determine whether the driving pattern of the driver is appropriate for the road condition
See at least: "an occurrence of sudden swerving or braking... image data... shows that a pedestrian... moved into the path of the vehicle... indicate that the driver of the vehicle 210 was paying proper attention and reacted appropriately to the situation." (Column 8, lines 40-49)
Rationale: Brinkmann discloses that the system is configured to determine whether the driving pattern of the driver is appropriate for the road condition (e.g., a sudden swerve in response to a pedestrian).
based on the analyzed road condition
See at least: "driving analysis module 221 may use... additional image data... perform driving event analyses... to determine that the braking , swerving , or impact was caused by one or more of : an obstruction in the path in the vehicle 210 ; adverse road conditions " (Column 7, lines 44-48 and Column 12, lines 16-19)
Rationale: Brinkmann discloses that the determination of appropriateness is based on the analyzed road condition identified in the image data.
and to transmit result data of the determination
See at least: "In certain examples, a driving analysis server 220 within the vehicle 210 may be configured to report the driving event to a vehicle operation system 225 or other external system (e.g., an insurance company computer system) only if a determined cause of the driving event was high-risk or unsafe driving, but not if the determined causes of the driving event were something other than high-risk or unsafe driving." (Column 15, lines 6-13)
Rationale: Brinkmann discloses that the vehicle is configured and to transmit result data of the determination regarding the event to an external system, which, from BRI, is a remote system.
to a management server remote from the vehicle
See at least: "In certain examples, a driving analysis server 220 within the vehicle 210 may be configured to report the driving event to a vehicle operation system 225 or other external system (e.g., an insurance company computer system) only if a determined cause of the driving event was high-risk or unsafe driving, but not if the determined causes of the driving event were something other than high-risk or unsafe driving." (Column 15, lines 6-13)
Rationale: Brinkmann discloses that the vehicle is configured and to transmit result data of the determination regarding the event to an external system, which, from BRI, is a remote system.
to reflect the result data in a safe driving index of the driver,
See at least: "A driver score... may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event." (Abstract)
Rationale: Brinkmann discloses using the event analysis to reflect the result data in a safe driving index of the driver (the driver score).
wherein the road condition analysis part further comprises a processor
See at least: "The device 101 may have a processor 103 for controlling overall operation" (Column 3, lines 27-28)
Rationale: Brinkmann discloses wherein the road condition analysis part further comprises a processor for executing the analysis logic.
configured to determine when the driving pattern of the driver is determined to be out of the normal range
See at least “In certain embodiments, the driving analysis server 220 may identify a potentially high-risk or unsafe driving event of the vehicle 210 in real-time or near real-time (in step 302), and may retrieve image, video, or object proximity data associated with the driving event or near the same time (in step 303)” (Column 10, lines 60-65)
Rationale: Brinkmann expressly discloses that the processor (driving analysis server) identifies when a driving event occurs—i.e., the moment a pattern of unsafe driving is detected—and performs subsequent actions at that time. The phrase “in real-time or near real-time” and “at or near the same time” confirms that the processor is configured to determine the temporal occurrence of the abnormal driving pattern.
and a location information transmission part
See at least: "To determine the vehicle's route, lane position, and other data, the telematics device 216 may include or may receive data from a mobile telephone, a Global Positioning System (GPS), locational sensors positioned inside a vehicle, or locational sensors or devices remote from the vehicle 210" (Column 6, line 42-47)
Rationale: Brinkmann discloses a location information transmission part in the form of a telematics device configured to send GPS and position data.
configured to transmit location information of the vehicle
See at least: "For example, telematics device 216 may be configured to receive and transmit data from operational sensors 212, while one or more cameras and proximity sensors 214 may be configured to directly transmit data to a vehicle operation computer system 225 or a driving analysis server 220 without using the telematics device 216." (Column 5, lines 60-65)
Rationale: Brinkmann discloses that the telematics device is configured to transmit location information of the vehicle.
and information about whether hazard lights flash,
See at least: "sensors 212 also may detect and store data received from the vehicle's 210 internal systems, such as... hazard lights usage…" (Column 5, lines 18-27)
Rationale: Brinkmann discloses collecting and information about whether hazard lights flash as part of the vehicle operation data.
wherein the road condition analysis part comprises an obstacle information transmission part
See at least: “the cameras and proximity sensors 214 … may be configured to transmit data … [to] … a driving analysis server 220” (Column 5, lines 54-65); “the driving analysis server 220 may be configured to specifically request and retrieve image, video, and object proximity data from the front-facing cameras and sensors 214”
Rationale: Brinkmann describes vehicle sensors/cameras/proximity sensors that transmit data (including camera/proximity data relevant to obstacles) to a driving analysis server 220 (i.e., a management server remote from the vehicle). That vehicle-side “transmit” functionality is a straightforward read on an “information transmission part.”. Also, Brinkmann teaches that the server may request and retrieve specific image/video/object-proximity data from the vehicle sensors (showing a defined comms path for obstacle-related data).
configured, based on the obstacle which is recognized in the road condition shown in the image data, to transmit obstacle-related information
See at least: ““image, video, and/or proximity data may show that a vehicle 210 swerved to avoid hitting an object that was in the vehicle’s path (e.g., a pedestrian, cyclist, animal, disabled vehicle, etc.)” (Column 12, lines 39 – 42): “the cameras and proximity sensors 214 … may be configured to transmit data … [to] … a driving analysis server 220” (Column 5, lines 54-65)
Rationale: Brinkmann explicitly uses image/video/object proximity data to identify that an object/obstruction has entered the vehicle path (pedestrian/cyclist/animal/disabled vehicle, etc.), and it describes the relevant data that the server transmits/retrieves from the vehicle-side cameras/sensors. Once Brinkmann is already transmitting the image/video/proximity dataset that shows the obstacle, packaging/transmitting an “obstacle-related information” subset (metadata derived from that dataset) is a predictable implementation choice (reduced bandwidth, faster server-side scoring/analysis, standard event reporting design).
including a size and a location of an obstacle,
See at least: “may use the location and time data associated with the driving event … [and] may access GPS system data, location and time data from telematics devices 216 …” (Column 11, lines 52-54); “analyze the image, video, and / or proximity data to determine the distance between the object and the vehicle …” (Column 12, lines 44-46)
Rationale: Brinkmann expressly uses and associates location data (GPS/telematics) and identifies time/location of the event and vicinity vehicles. Brinkmann already transmits image/video/proximity data sufficient to compute obstacle attributes; deriving obstacle size from image data (e.g., pixel extent/bounding box) and/or from object class + known dimensions is a routine computer-vision/ADAS implementation detail; and providing “size” alongside “distance/location” is a predictable design choice for obstacle characterization and downstream decisioning.
a lane, or a time
See at least: ““determine when and how often the vehicle 210 stays in a single lane or strays into other lanes … To determine … lane position …” (Column 6, lines 40-43); “corresponding to the time and location of the driving event …” (Column 12, lines 8-9)
Rationale: Brinkmann expressly discusses determining lane position / single lane vs straying lanes via telematics + sensors/cameras. Brinkmann repeatedly relies on time data tied to the driving event (including “time and location of the driving event”).
to the management server,
See at least: "transmit the data to... a driving analysis server 220" (Column 5, lines 51-53)
Rationale: Brinkmann discloses transmitting data to the management server.
wherein the management server is configured to collect the obstacle-related information
See at least: “A driving analysis server may be configured to receive vehicle operation data from vehicle sensors, and may use the data to identify a potentially high-risk or unsafe driving event by the vehicle. The driving analysis server also may receive corresponding image data, video, or object proximity data from the vehicle or one or more other data sources, and may use the image, video, or proximity data to analyze the potentially high-risk or unsafe driving event.” (Abstract)
Rationale: Brinkmann expressly states the server is configured to receive “object proximity data” (i.e., obstacle-related information) from the vehicle.
continuously reported based on timestamp
See at least: ““... may initiate communication with the vehicle’s telematics device 216, GPS servers, time servers, or other systems to determine the location and time that correspond to the received vehicle operation data. In certain embodiments, telematics devices 216, vehicle operation systems 225, and other data sources may transmit vehicle operation data for a vehicle 210 to the driving analysis server 220 in real-time (or near real-time). The driving analysis server 220 may be configured to receive the vehicle operation data, and then perform real-time (or near real-time) driving analyses and driver score calculations… In other embodiments… vehicle operation data… may be sent periodically (e.g., hourly, daily, weekly, etc.)… The driving analysis server 220 may be configured to receive the periodic transmissions...”
Rationale: Brinkmann explicitly has the server “configured to receive” vehicle operation data in real-time (or near real-time) and/or periodically, i.e., an ongoing stream rather than a one-off upload. Brinkmann also explicitly uses time servers to determine the time corresponding to received vehicle operation data, which is the functional equivalent of associating received reports with a timestamp
Claim limitations Not Explicitly Disclosed by Brinkmann
Brinkmann does not explicitly disclose:
image data captured by a camera a set period of time ago,
a processor configured to determine whether the camera is installed,
information about whether hazard lights flash during a time in which the driving pattern of the driver is out of the normal range, based on a determination by the processor that the camera is not installed,
and determine, based on the obstacle-related information, whether the obstacle is a moving object
by analyzing the location of the obstacle and lanes
and based on a determination that the obstacle is the moving object, transmit the obstacle-related information
to a second vehicle,
and wherein the second vehicle is configured to receive the obstacle-related information from the management server
and to avoid the obstacle based on the obstacle-related information.
Disclosure by Chen
Chen discloses:
a processor configured to determine whether the camera is installed,
See at least: “Wherein, the processor 610 is configured to detect the physical connection state between the camera module and the electronic device; according to the physical connection state, output first prompt information on the electronic device.” (Pg. 4); “Wherein, the first connection state is a state in which the camera module is installed in the electronic device, and the second connection state is a state in which the camera module is separated from the electronic device.” (Pg. 7) “In the embodiments of the present invention, electronic devices include, but are not limited to, mobile phones, tablet computers, notebook computers, palmtop computers, vehicle-mounted mobile terminals, wearable devices, and pedometers.” (Pg. 10)
Rationale: Chen discloses a processor configured to detect a physical connection state between a camera module and an electronic device, including whether the camera module is installed or separated, and explicitly states that the electronic device may be a “vehicle-mounted mobile terminal.” Therefore, Chen is analogous art at least because it is reasonably pertinent to the problem of verifying camera installation/availability before relying on camera-captured image data in a vehicle-mounted system.
Disclosure rendered obvious by the combination of Brinkmann and Chen:
The combination of Brinkmann and Chen renders obvious:
information about whether hazard lights flash during a time in which the driving pattern of the driver is out of the normal range, based on a determination by the processor that the camera is not installed
Rationale: Brinkmann already provides both (1) the substantive data (hazard light usage) and (2) the contextual trigger (time/location of an unsafe event). Chen provides the explicit conditional (missing camera). A PHOSITA would simply apply Chen’s missing-component detection to condition the transmission of Brinkmann’s existing event-linked telemetry. This is a predictable combination of known elements according to their known functions.
Motivation to Combine Brinkmann and Chen
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann and Chen before them, to configure Brinkmann’s vehicle-side processing to, upon identification of an out-of-normal-range driving pattern (i.e., a potentially high-risk/unsafe driving event), use Chen’s processor-based determination of whether the camera module is installed vs. separated (not installed) to control which event-related data are transmitted, and, responsive to a determination that the camera is not installed, to transmit to the remote system an alternate event payload comprising non-camera vehicle telemetry that is available during the event interval, including information indicating whether the hazard lights were in use (i.e., whether hazard lights flash) during the time in which the driving pattern is out of the normal range. Brinkmann already teaches (i) detecting unsafe driving events tied to abnormal driving patterns, (ii) associating received/transmitted vehicle operation data with the time of the driving event and transmitting such data to an external system, and (iii) collecting hazard lights usage as part of vehicle operation data, such that hazard-light status is a readily available safety-indicator datum contemporaneous with the abnormal driving period. Chen teaches an implementation-ready technique for determining whether a camera module is installed or not installed (separated), enabling the system to avoid attempting camera-based image analysis/transmission when the camera is absent. A PHOSITA would have been motivated to combine these teachings as a predictable robustness enhancement—when the camera is not installed, the system predictably relies on alternate, already-collected vehicle operation data (including hazard-light usage) over the relevant event window to preserve continuity of event reporting and hazard characterization to the remote server, yielding the expected result of maintaining safety-event reporting functionality even when camera hardware is unavailable.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann and Chen
After combining the teachings of Brinkmann and Chen, the following are not explicitly disclosed:
image data captured by a camera a set period of time ago,
and determine, based on the obstacle-related information, whether the obstacle is a moving object by analyzing the location of the obstacle and lanes
and based on a determination that the obstacle is the moving object, transmit the obstacle-related information to a second vehicle,
and wherein the second vehicle is configured to receive the obstacle-related information from the management server and to avoid the obstacle based on the obstacle-related information.
Disclosure by Nemat-Nasser
Nemat-Nasser discloses:
image data captured by a camera a set period of time ago,
See at least Col. 7, ll. 18-22: Excerpt: “images are captured to a raw image buffer… in the event a trigger is received, the raw image is…transferred for processing…”;
Rationale: Buffered image frames enable access to images from moments before the trigger, satisfying analysis of images captured a period previously).
Motivation to Combine Brinkmann, Chen, and Nemat-Nasser
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, and Nemat-Nasser before them, to incorporate Nemat-Nasser’s event-triggered pre-event camera buffering and selective upload window into Brinkmann’s driving-event/road-condition analysis and reporting system (as already enhanced with Chen’s camera-installation determination), because Brinkmann expressly analyzes unsafe/out-of-range driving events using camera-derived image/video data and reports event results to a remote system, and a PHOSITA would have recognized that accurately diagnosing the road condition that precipitated an abnormal driving maneuver predictably benefits from preserving and transmitting camera image/video data captured for a defined time period immediately preceding the event. Nemat-Nasser teaches a well-known, implementation-ready technique of storing and uploading a bounded clip (e.g., seconds before and after the detected safety event), thereby providing the “set period of time ago” image data needed to analyze conditions leading up to the event, while Chen’s installed-vs-separated determination ensures that the system only attempts Nemat-Nasser’s camera-data buffering/upload path when the camera is installed and otherwise predictably relies on non-camera event payloads already available in Brinkmann (e.g., vehicle operation data such as location and hazard-light usage) to maintain continuity of event reporting.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann, Chen, and Nemat-Nasser
After combining the teachings of Brinkmann, Chen, and Nemat-Nasser, the following are not explicitly disclosed:
information about whether hazard lights flash during a time in which the driving pattern of the driver is out of the normal range, based on a determination by the processor that the camera is not installed,
and determine, based on the obstacle-related information, whether the obstacle is a moving object by analyzing the location of the obstacle and lanes
and based on a determination that the obstacle is the moving object, transmit the obstacle-related information to a second vehicle,
and wherein the second vehicle is configured to receive the obstacle-related information from the management server and to avoid the obstacle based on the obstacle-related information.
Disclosure by Lin
Lin discloses:
and determine, based on the obstacle-related information, whether the obstacle is a moving object by analyzing the location of the obstacle and lanes
See at least: "The tracking module 320 may include functionality to receive sensor information to determine and/or distinguish between static objects and dynamic objects. In some instances, the determination of static objects or dynamic objects may be included as shared vehicle data." ([0056]); “the tracking module 320 may determine a velocity of a dynamic object and/or may determine and store a trajectory of the dynamic object over time”; ([0056]); "alter a position in a lane of the road 102" [0022]) (contextual tie to positional analysis for obstacles)
Rationale: Lin explicitly teaches determining "dynamic objects" (moving, e.g., cars/pedestrians) vs. static based on obstacle-related sensor data (e.g., velocity/trajectory over time, which analyzes location changes). Lanes are implicitly analyzed as part of trajectory/position (e.g., altering lane position to avoid dynamic obstacles).
and based on a determination that the obstacle is the moving object, transmit the obstacle-related information to a second vehicle,
"dynamic information (e.g., representing moving cars, bicycles, pedestrians, traffic lights, traffic, etc.) may be transmitted directly to other vehicles." (0014]); "the first vehicle 202 can transmit a transmission 210 to a second vehicle (V2) 212, and/or may transmit a transmission 214 to one or more central server(s) 216." ([0025]); "the transmission 210 may include any information associated with the obstacle 204, such as a location of the obstacle 204, a speed/heading of the obstacle 204, a timestamp associated with capturing data associated with the obstacle 204, predicted movement of the obstacle 204, segmentation information (e.g., a two-dimensional or three-dimensional bounding box associated with the obstacle 204, classification information (e.g., identifying the obstacle)), etc." ([0029])
Rationale: Lin explicitly teaches transmitting obstacle-related info (e.g., location, speed, trajectory) to a second vehicle when the obstacle is determined dynamic/moving (e.g., cars/bicycles/pedestrians as "dynamic information").
and wherein the second vehicle is configured to receive the obstacle-related information from the management server and to avoid the obstacle based on the obstacle-related information.
See at least: "the first vehicle 102 may capture data associated with the bicycle 108 and may transmit data 116 to the second vehicle 110, so that the second vehicle 110 may be aware of the bicycle 108 despite the bicycle 108 not being within a field of view of the second sensor area 112." ([0020]); "As the second vehicle 110 receives the data 116 from the first vehicle 102, the second vehicle 110 can modify a trajectory of the second vehicle 110 based on the expectation that the bicycle 108 may be present on the road 102... For example, the second vehicle 110 may reduce velocity, alter a position in a lane of the road 102, etc., based on the data 116 provided to the second vehicle 110." ([0022]); "Thus, the second vehicle 110, upon receiving the data 116, can control motion of the second vehicle 110 based on the obstacle."; "the data ingestion module 326 can receive transmissions and determine a confidence level associated with the data corresponding to the relevancy or validity of the data contained therein." ([0059]) (server/central processing context).
Rationale: Lin explicitly teaches the second vehicle configured to receive obstacle-related info (from first vehicle or via central server rebroadcast, [0025]/[0031]) and avoid by modifying trajectory/position (e.g., reduce velocity, alter lane). The management server (central server(s) 216) facilitates rebroadcast ([0031]: "the third vehicle 218 may transmit some or all of the data... to the fourth vehicle 220").
Motivation to Combine Brinkmann, Chen, Nemat-Nasser , and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to incorporate Lin’s distributed obstacle management into the integrated safety system. Brinkmann and Nemat-Nasser establish the edge-triggered analysis of road conditions and driver appropriateness for scoring. Lin extends this by teaching that once an obstacle (the "road condition") is recognized, its specific attributes (size, location, lane, time) should be shared via a server to extend the safety horizon of other vehicles. PHOSITA would combine these to create a comprehensive safety ecosystem where the server not only adjusts a "safe driving index" for the first driver but also classifies the cause of the event as a "moving object" to proactively assist a "second vehicle" in avoidance maneuvers. This represents a predictable application of V2X (Vehicle-to-Everything) communication to enhance fleet safety and driver scoring accuracy.
Regarding Claim 2,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of Claim 1, which is the basis for Claim 2.
Disclosure by Brinkmann
Brinkmann discloses
wherein the road condition analysis part comprises a sensor
See at least: "The vehicle 210 may include vehicle operation sensors 212 capable of detecting and recording various conditions at the vehicle and operational parameters of the vehicle." (Column 5, lines 12-15)
Rationale: Brinkmann discloses wherein the road condition analysis part comprises a sensor as the driving analysis module uses vehicle operation sensors to analyze road conditions based on driving patterns.
configured to detect a sudden acceleration, a sudden deceleration, a sudden stop, or a sudden lane-change during driving.
See at least: "For example, sensors 212 may detect and store data corresponding to the vehicle's speed, distances driven, rates of acceleration or braking, and specific instances of sudden acceleration, braking, and swerving." (Column 5, lines 16-21)
Rationale: Brinkmann discloses configured to detect a sudden acceleration, a sudden deceleration, a sudden stop, or a sudden lane-change during driving as sensors detect specific instances of sudden acceleration, braking (deceleration or stop), and swerving (lane-change) as operational parameters during vehicle driving.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to incorporate Chen's camera installation detection, Nemat-Nasser's pre-event image buffering, and Lin's obstacle sharing and analysis into Brinkmann's vehicle-based driving analysis system, because Brinkmann provides a foundational framework for detecting and analyzing driving events using sensors and image data to adjust driver scores, Chen enhances system robustness by checking for camera presence to enable fallback data transmission, Nemat-Nasser improves event context capture through time-specific image retrieval, and Lin extends safety by enabling server-mediated sharing of moving obstacle information, resulting in a predictable comprehensive system that ensures reliable road condition analysis and inter-vehicle safety even in dependent configurations involving sensor-detected sudden maneuvers.
Regarding Claim 3,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of Claim 2, which is the basis for Claim 3.
Disclosure by Brinkmann
Brinkmann discloses:
wherein the road condition analysis part further comprises a driving pattern analysis part
See at least: "driving analysis module 221" (Column 7, line 36)
Rationale: Brinkmann discloses wherein the road condition analysis part further comprises a driving pattern analysis part as the driving analysis module analyzes driving patterns for road conditions.
configured to determine that the driving pattern of the driver is out of the normal range
See at least: "identify one or more potentially high - risk or unsafe driving events at a vehicle, for example, an occurrence of sudden braking or swerving, an impact to the vehicle, speeding, or a moving violation." (Column 2, lines 6-11)
Rationale: Brinkmann discloses configured to determine that the driving pattern of the driver is out of the normal range as the module identifies high-risk events like sudden braking or swerving which are out of normal driving patterns.
when a value detected by the sensor exceeds a preset range.
See at least: "For example, sensors 212 may detect and store data corresponding to the vehicle's speed, distances driven, rates of acceleration or braking, and specific instances of sudden acceleration, braking, and swerving." (Column 5, lines 16-21)
Rationale: Brinkmann discloses when a value detected by the sensor exceeds a preset range as sensors detect sudden instances implying values like acceleration or braking rates exceed preset normal thresholds.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to incorporate Chen's camera installation detection, Nemat-Nasser's pre-event image buffering, and Lin's obstacle sharing and analysis into Brinkmann's vehicle-based driving analysis system, because Brinkmann provides a foundational framework for detecting and analyzing driving events using sensors and image data to adjust driver scores, Chen enhances system robustness by checking for camera presence to enable fallback data transmission, Nemat-Nasser improves event context capture through time-specific image retrieval, and Lin extends safety by enabling server-mediated sharing of moving obstacle information, resulting in a predictable comprehensive system that ensures reliable road condition analysis and inter-vehicle safety even in dependent configurations involving driving pattern determinations based on sensor values exceeding presets.
Regarding Claim 5,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of Claim 1, which is the basis for Claim 5.
Disclosure by Brinkmann
Brinkmann discloses:
the road condition analysis part is configured to receive the image data
See at least: "driving analysis module 221 may use... additional image data... perform driving event analyses..." (Column 7, lines 44-46)
Rationale: Brinkmann discloses the road condition analysis part is configured to receive the image data as the driving analysis module receives additional image data for analyses.
captured by the camera
See at least: "The vehicle 210 also may include one or more cameras... configured to transmit data" (Column 5, line 38)
Rationale: Brinkmann discloses captured by the camera as cameras capture and transmit image data. ·
and analyze the road condition shown in the image data.
See at least: "to determine that the braking , swerving , or impact was caused by one or more of : an obstruction in the path in the vehicle 210 ; adverse road conditions " (Column 12, lines 16-19)
Rationale: Brinkmann analyzes the road condition shown in the image data as the module analyzes image data to determine road conditions like obstructions or adverse conditions.
Claim limitations Not Explicitly Disclosed by Brinkmann
Brinkmann does not explicitly disclose:
wherein, in response to a determination by the processor that the camera is installed,
the set period of time ago
Disclosure by Chen
Chen discloses:
wherein, in response to a determination by the processor
“Wherein, the processor 610 is configured to detect the physical connection state between the camera module and the electronic device; according to the physical connection state, output first prompt information on the electronic device.” (Pg. 4)
Rationale: Chen expressly describes the processor detecting the connection state and performing an action according to that detected state, which reads on wherein, in response to a determination by the processor.
that the camera is installed,
“Wherein, the first connection state is a state in which the camera module is installed in the electronic device, and the second connection state is a state in which the camera module is separated from the electronic device.” (Pg. 7)
Rationale: Chen expressly defines a connection state corresponding to the camera module being installed, which satisfies that the camera is installed.
Disclosure rendered obvious by the combination of Brinkmann and Chen
The combination of Brinkmann and Chen renders obvious:
wherein, in response to a determination by the processor that the camera is installed, the road condition analysis part is configured to receive the image data captured by the camera
Rationale: Brinkmann already relies on vehicle cameras and receives image data captured by the camera for road-condition/driving-event analysis. Chen teaches a processor determination that the camera module is installed (first connection state) and performing actions “according to” that state. A PHOSITA would therefore have used Chen’s installed-state check as a simple gate on Brinkmann’s camera-data input—i.e., in response to a determination by the processor that the camera is installed, enable Brinkmann’s existing camera reception path so the road condition analysis part receives the image data captured by the camera—a predictable reliability enhancement with the expected result of only using camera data when the camera is present.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann and Chen
After combining the teachings of Brinkmann and Chen, the following are not explicitly disclosed:
image data captured by a camera a set period of time ago
Disclosure by Nemat-Nasser
Nemat-Nasser discloses:
image data captured by a camera a set period of time ago,
See at least Col. 7, ll. 18-22: Excerpt: “images are captured to a raw image buffer… in the event a trigger is received, the raw image is…transferred for processing…”;
Rationale: Buffered image frames enable access to images from moments before the trigger, satisfying analysis of images captured a period previously).
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to incorporate Nemat-Nasser’s raw image buffering (which stores images captured before a trigger) into Brinkmann’s camera-based road-condition analysis system as already conditioned by Chen’s determination that the camera is installed, because Brinkmann relies on camera-captured image data to analyze road conditions and driving events, Chen provides an implementation-ready technique for enabling that camera-data path only when the camera is installed, and Nemat-Nasser teaches storing camera images in a buffer and, upon a trigger, transferring buffered images for processing—thereby predictably providing the image data captured by the camera the set period of time ago for Brinkmann’s road-condition analysis (with Lin merely reflecting the predictable connected-vehicle context in which such event/obstacle data can be shared).
Regarding Claim 8,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of Claim 1, which is the basis for Claim 8.
Disclosure by Brinkmann
Brinkmann discloses:
wherein the safe driving index reflection part
See at least Col. 7, ll. 49-51: “The driver score calculation module 222 may use the results of the driving event analysis…”;
Rationale: The Driver score calculation module is the safe-driving-index reflection part, tasked with calculating or adjusting the driver's score based on the analyses performed)
comprises a data generation part
See at least Col. 7, ll. 49-52: “The driver score calculation module 222 may use the results of the driving event analysis…to calculate or adjust a driver score…”;
Rationale: Calculating/adjusting the score is “generating result data,” i.e., a data-generation function within the reflection part)
configured to generate the result data
See at least Col. 8, ll. 25-28: “adjusting driver score based on a driving event identified… using image data, video data, and/or object proximity data associated with the driving event.”;
Rationale: The module outputs the adjusted score (result data) after analysis)
to increase the safe driving index of the driver,
See at least Col. 16, ll. 23-24: Excerpt: then the driver’s score may be positively adjusted in step 406.”;
Rationale: “Positively adjusted” = increased safe-driving index)
in response to a determination that the driving pattern of the driver is appropriate for the road condition
See at least Fig. 4, Step 405-406: “…retrieve and analyze additional data… determine… was driving in a competent and safe manner… (405: Safe) … then the driver’s score may be positively adjusted in step 406.”
Rationale: Brinkmann increases the score because analysis concludes the driver’s behavior was appropriate given road conditions (external cause/safe behavior)).
Motivation to Combine Brinkmann, Chen, Nemat-Nasser , and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to integrate Chen’s camera-installed determination and Nemat-Nasser’s pre-event image buffering into Brinkmann’s camera-based road-condition/driver-appropriateness evaluation, and to operate that evaluation within Lin’s vehicle-safety data ecosystem, because Brinkmann already teaches determining driver appropriateness for a road condition and adjusting a driver score (safe driving index) based on that determination, while Chen and Nemat-Nasser provide predictable robustness improvements to ensure the image data used for the appropriateness determination is available (camera installed) and includes a defined prior interval (buffer), and Lin shows the predictable use of such safety determinations/data in a connected-vehicle context—yielding the expected result that, in response to a determination that the driving pattern of the driver is appropriate for the road condition, the system generates the result data to increase the safe driving index of the driver.
Regarding Claim 9,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of claim 8, which is the basis for Claim 9.
Disclosure by Brinkmann
Brinkmann discloses:
wherein the safe driving index reflection part further comprises: a follow-up action reflection part
See at least: “For example, telematics device 216 may be configured to receive and transmit data from operational sensors 212…” (Column 5, lines 60–65)
Rationale: The telematics/sensor data-path in Brinkmann functions as a follow-up action reflection part by acquiring and carrying post-event/driver-action operational signals for downstream scoring/analysis components.
configured to transmit, to the data generation part, information about whether the hazard lights flash,
See at least: “sensors 212 also may detect and store data received from the vehicle’s 210 internal systems, such as… hazard lights usage…” (Column 5, lines 18–27)
Rationale: Brinkmann’s sensors detect/store information about whether the hazard lights flash (hazard-lights usage), and Brinkmann’s telematics path transmits sensor-derived operational data for scoring/event processing, meeting configured to transmit, to the data generation part.
when the driver turns on the hazard lights to inform the following vehicle of the road condition,
See at least: “sensors 212 also may detect and store data received from the vehicle’s 210 internal systems, such as… hazard lights usage…” (Col. 5, ll. 18–27)
Rationale: Brinkmann expressly discloses “hazard lights usage,” which inherently occurs when the driver turns on hazard lights. Further, the functional purpose “to inform the following vehicle of the road condition” is the conventional, well-understood use of hazard lights as a visible warning signal to other traffic (including following vehicles) regarding a hazard/unsafe condition; thus, the recited “when” clause would have been obvious to a PHOSITA in view of Brinkmann’s disclosed hazard-light usage being captured during driving events/conditions.
and the data generation part is configured to generate the result data
See at least: “A driver score… may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event.” (Abstract)
Rationale: Brinkmann’s score calculation/adjustment based on analyzed driving-event data reads on a data generation part that generates the result data for safe-driving-index reflection.
including the information about whether the hazard lights flash
See at least: “sensors 212 also may detect and store data received from the vehicle’s 210 internal systems, such as… hazard lights usage…” (Column 5, lines 18–27)
Rationale: Since Brinkmann expressly collects hazard-lights usage as part of the event/operational dataset, a PHOSITA would include that collected item within the generated event/score payload, satisfying including the information about whether the hazard lights flash.
to increase the safe driving index of the driver,
See at least: “…indicate that the driver of the vehicle 210 was paying proper attention and reacted appropriately to the situation.” (Column 8, lines 40–49)
Rationale: Brinkmann ties “reacted appropriately” determinations to driver-score adjustment; as a predictable scoring implementation, appropriate reactions correspond to upward adjustment/reward, meeting to increase the safe driving index of the driver.
the information about whether the hazard lights flash being received from the follow-up action reflection part.
See at least: “For example, telematics device 216 may be configured to receive and transmit data from operational sensors 212…” (Col. 5, ll. 60–65)
Rationale: Brinkmann expressly teaches sensor data being received by the telematics path and transmitted onward, satisfying the information about whether the hazard lights flash being received from the follow-up action reflection part.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to implement Claim 9’s hazard-light follow-up-action signaling and inclusion in the generated result data within the already-established safe-driving-index framework, because Brinkmann already captures “hazard lights usage” as vehicle operation data and generates driver-score result data from received vehicle operation data, while the already-combined teachings (Chen/Nemat-Nasser/Lin) maintain robustness and event-context handling in the overall system; incorporating hazard-light usage during the relevant condition/event window as a follow-up-action input to the result-data generation is a predictable, conventional integration with the expected result of improving road-condition/event characterization for safe driving index reflection.
Regarding Claim 14,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the method of Claim 11, which is the basis for Claim 14.
Disclosure by Brinkmann
Brinkmann teaches:
further comprising adjusting,
See at least: “A driver score... may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event.” (Abstract)
Rationale: Brinkmann expressly teaches that the driver score “may be… adjusted,” which reads on the claimed adjusting.
by the management server,
See at least: “The driving analysis server 220 may be configured to receive the vehicle operation data, and then perform real-time (or near real-time) driving analyses and driver score calculations…” (Col. 9, ll. 21–24)
Rationale: Brinkmann expressly teaches that the “driving analysis server 220” performs “driver score calculations,” which reads on adjusting being performed by the management server.
the safe driving index of the driver
See at least: “A driver score... may be calculated or adjusted…” (Abstract)
Rationale: Brinkmann expressly teaches a “driver score,” which corresponds to the safe driving index of the driver.
based on the result data.
See at least: “A driver score... may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event.” (Abstract)
Rationale: Brinkmann expressly teaches adjusting the driver score “based on” the “analysis of the data” and the “determination” outputs, which correspond to the result data.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to integrate Chen’s camera-installation state determination into Brinkmann’s vehicle driving-event analysis so that Brinkmann’s image-data-based road-condition analysis is selectively enabled when a camera is installed, to further incorporate Nemat-Nasser’s triggered raw-image buffering to supply image data captured a set period of time before the driving event for improved event-cause analysis, and to further incorporate Lin’s obstacle-related information sharing and dynamic-object determination to extend Brinkmann’s server-side safety assessment beyond scoring to server-mediated communication of obstacle-related information to other vehicles for avoidance, because each reference addresses complementary aspects of the same vehicle safety and event-reporting field and the combination yields the predictable result of more robust detection, reporting, and response to abnormal driving events.
Regarding Claim 15,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the method of Claim 14, which is the basis for Claim 15.
Disclosure by Brinkmann
Brinkmann teaches:
wherein adjusting the safe driving index of the driver comprises increasing the safe driving index of the driver in response to the result data indicating that the driving pattern of the driver is appropriate for the road condition.
See at least: “See at least: "If the driving analysis module 221 determines that the driver of the vehicle 210 was driving in a competent and safe manner during the driving event (405: Safe), then the driver's score may be positively adjusted in step 406." (Fig. 4, Column 16, lines 20-24)
Rationale: Brinkmann teaches wherein adjusting the safe driving index of the driver comprises increasing the safe driving index of the driver in response to the result data indicating that the driving pattern of the driver is appropriate for the road condition by positively adjusting the score when the determination is safe manner.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to maintain the integrated system from Claim 14 for Claim 15's specific score adjustment, because Brinkmann's core analysis and adjustment logic complements Chen's camera conditioning, Nemat-Nasser's buffering for retrospective context, and Lin's obstacle sharing for enhanced determination accuracy, yielding the predictable result of rewarding appropriate driving with score increases in a robust, multi-data-source safety framework.
Claims 10, 12, 16, 17, 19, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Brinkmann, in view of Chen, in view of Nemat-Nasser, in view of Lin, and in view of Slusar (US 20250304078 A1)
Regarding Claim 10,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the vehicle of Claim 1, which is the basis for Claim 10.
Disclosure by Brinkmann
Brinkmann discloses:
further comprising: an auxiliary analysis part
See at least: “a driving analysis module 221” (Column 7, line 36)
Rationale: Brinkmann discloses an auxiliary analysis part in the form of a driving analysis module, which is configured to perform analysis functions related to driving data.
configured to analyze the road condition shown in the image data
See at least: “driving analysis module 221 may use... additional image data... perform driving event analyses... “ (Column 7, lines 44-49); “to determine that the braking , swerving , or impact was caused by one or more of : an obstruction in the path in the vehicle 210 ; adverse road conditions” (Column 12, lines 16-18)
Rationale: Brinkmann discloses that the module is configured to analyze the road condition shown in the image data to determine if it caused a driving event.
captured by the camera,
See at least: “The vehicle 210 also may include one or more cameras...”(Column 5, line 38); “…the cameras and proximity sensors…configured to transmit data…” (Column 5, line 54-55)
Rationale: Brinkmann discloses that image data is captured by the camera installed on the vehicle.
and an auxiliary index reflection part
See at least: “driver score calculation module 222” (FIG. 2 and Column 7, lines 49-51)
Rationale: Brinkmann discloses an auxiliary index reflection part in the form of a driver score calculation module that is configured to calculate and update driver scores.
configured to determine whether the driving pattern of a driver
“…identify one or more potentially high - risk or unsafe driving events at a vehicle, for example, an occurrence of sudden braking or swerving, an impact to the vehicle, speeding, or a moving violation.” (Column 2, lines 8-11)
Rationale: Brinkmann discloses that the system is configured to determine whether the driving pattern of a driver is high-risk or unsafe, which is a determination about a driver's driving behavior/pattern.
based on the analyzed road condition
See at least: "driving analysis module 221 may use... additional image data... perform driving event analyses... to determine that the braking , swerving , or impact was caused by one or more of : an obstruction in the path in the vehicle 210 ; adverse road conditions " (Column 7, lines 44-48 and Column 12, lines 16-19)
Rationale: Brinkmann discloses that the determination of appropriateness is based on the analyzed road condition identified in the image data.
and to transmit the result data of the determination
See at least: "In certain examples, a driving analysis server 220 within the vehicle 210 may be configured to report the driving event to a vehicle operation system 225 or other external system (e.g., an insurance company computer system) only if a determined cause of the driving event was high-risk or unsafe driving, but not if the determined causes of the driving event were something other than high-risk or unsafe driving." (Column 15, lines 6-13)
Rationale: Brinkmann discloses that the vehicle is configured and to transmit result data of the determination regarding the event to an external system, which, from BRI, is a remote system.
to reflect the result data in a safe driving index of the driver.
See at least: "A driver score... may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event." (Abstract)
Rationale: Brinkmann discloses using the event analysis to reflect the result data in a safe driving index of the driver (the driver score).
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann and Chen
After combining the teachings of Brinkmann and Chen, the following are not explicitly disclosed:
image data captured by the camera the set period of time ago,
from a point in time that the vehicle reaches a location
corresponding to location information of a preceding vehicle,
when the location information of the preceding vehicle is received,
determine whether the driving pattern of a driver of the preceding vehicle is appropriate for the road condition based on the analyzed road condition and to transmit the result data of the determination to reflect the result data in a safe driving index of the driver of the preceding vehicle.
Disclosure by Nemat-Nasser
image data captured by the camera the set period of time ago,
See at least Col. 7, ll. 18-22: Excerpt: “images are captured to a raw image buffer… in the event a trigger is received, the raw image is…transferred for processing…”;
Rationale: Buffered image frames enable access to images from moments before the trigger, satisfying analysis of images captured a period previously).
Motivation to Combine Brinkmann, Chen, and Nemat-Nasser
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, and Nemat-Nasser before them, to incorporate Nemat-Nasser's event-triggered pre-event camera buffering into Brinkmann's driving-event analysis system (as already enhanced with Chen's camera-installation determination). Brinkmann expressly analyzes unsafe driving events using camera-derived image data, and a PHOSITA would recognize that accurately diagnosing the road condition that precipitated an abnormal driving maneuver benefits from preserving and analyzing camera image data captured for a defined time period immediately preceding the event. Nemat-Nasser teaches a well-known, implementation-ready technique of storing and uploading a bounded clip of images captured before a trigger, thereby providing the set period of time ago image data needed to analyze conditions leading up to the event.
Claim Limitations Not Explicitly Disclosed by the Combination of Brinkmann, Chen, and Nemat-Nasser
After combining the teachings of Brinkmann, Chen, and Nemat-Nasser, the following are not explicitly disclosed:
from a point in time that the vehicle reaches a location
corresponding to location information of a preceding vehicle,
when the location information of the preceding vehicle is received,
determine whether the driving pattern of a driver of the preceding vehicle is appropriate for the road condition based on the analyzed road condition and to transmit the result data of the determination to reflect the result data in a safe driving index of the driver of the preceding vehicle.
Disclosure by Lin
Lin renders obvious:
from a point in time that the vehicle reaches a location
“receive transmissions ... and may assign a weight ... based on a distance of the receiving vehicle from a location associated with the source ... and a time elapsed between the transmission time ... and a time associated with reception...” ([0059])
Rationale: Lin explicitly ties (i) vehicle “distance ... from a location” and (ii) “transmission time” / “time ... associated with reception,” which provides a point-in-time framework keyed to vehicle location; when the receiving vehicle reaches the location (distance minimized), the corresponding “time associated with reception” provides the claimed from a point in time that the vehicle reaches a location for selecting/processing data. The concepts of "reaching a location" and "a point in time" are inherent mathematical consequences of the distance and time calculations Lin explicitly teaches a PHOSITA to perform. A PHOSITA implementing Lin's validity system would necessarily be able to determine the exact moment the vehicle arrives at the source location, making the specific limitation an obvious implementation detail.
corresponding to location information of a preceding vehicle,
“the first vehicle 202 can transmit a transmission 210 to a second vehicle (V2) 212, and/or may transmit a transmission 214 to one or more central server(s) 216.” ([0025]); “the transmission 210 may include any information associated with the obstacle 204, such as a location of the obstacle 204, a speed/heading of the obstacle 204, a timestamp” ([0029])
Rationale: Lin discloses a first vehicle transmitting information including location to a second vehicle, which is location information of a preceding vehicle being transmitted.
when the location information of the preceding vehicle is received,
“the data ingestion module 326 can receive transmissions” ([0059])
Rationale: Lin discloses a module that “can receive transmissions,” which teaches the condition when the location information of the preceding vehicle is received.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, and Lin before them, to incorporate Lin's location/time-referenced receipt processing into the combined Brinkmann + Chen + Nemat-Nasser system. The references are in compatible vehicle telematics and driver-analysis fields and provide complementary components. Brinkmann establishes camera-based road-condition analysis and driver scoring. Chen enables camera availability verification. Nemat-Nasser provides time-buffered image data. Lin teaches that when location information is received from a preceding vehicle, the receiving vehicle can perform operations based on its distance from that location and the elapsed time. A PHOSITA would combine these to create a system where, upon receiving location information from a preceding vehicle (Lin), the vehicle reaching that location triggers retrieval and analysis of buffered camera data (Nemat-Nasser) to analyze road conditions (Brinkmann) for determining the preceding vehicle's driving behavior. This integration yields the predictable result of enabling retrospective analysis of a preceding vehicle's driving context when the current vehicle arrives at the relevant location.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann, Chen, Nemat-Nasser, and Lin
After combining the teachings of Brinkmann, Chen, Nemat-Nasser, and Lin, the following are not explicitly disclosed:
determine whether the driving pattern of a driver of the preceding vehicle is appropriate for the road condition based on the analyzed road condition and to transmit the result data of the determination to reflect the result data in a safe driving index of the driver of the preceding vehicle.
Disclosure by Slusar
Slusar renders obvious:
determine whether the driving pattern of a driver of the preceding vehicle is appropriate for the road condition based on the analyzed road condition
See at least:
[0040]: "the driving analysis server 250 may receive additional data relevant to driving behavior determinations and driver score calculations from other non-vehicle data sources, such as external traffic databases containing traffic data (e.g., amounts of traffic, average driving speed, traffic speed distribution, and numbers and types of accidents, etc.) at various times and locations, external weather databases containing weather data (e.g., rain, snow, sleet, and hail amounts, temperatures, wind, road conditions, visibility, etc.) at various times and locations"; [0048]: "the driving analysis module 214 in a first vehicle 210 may compare the driving data (e.g., location, speed, direction) from its own vehicle sensors 211 with the corresponding driving data (e.g., location, speed, direction) from a nearby vehicle 220. Based on the relative locations, speeds, and directions of travel of vehicles 210 and 220, the driving analysis module 214 may determine a driving behavior involving the two vehicles"; [0050]: "determinations of defensive avoidance by driving analysis modules 214 also may take into account traffic density. For example, when a current traffic density is greater than a predetermined density threshold, the amount of time that vehicle 520 is given to change lanes in order to count as a defensive avoidance driving behavior may be increased"
Rationale: Slusar teaches receiving external data including "weather data" (rain, snow, road conditions, visibility) and "traffic data" (amounts of traffic, average speed) from external databases [0040], which constitutes analyzed road condition data. Slusar further teaches analyzing driving patterns of nearby (preceding) vehicles by comparing their speed, location, and direction to determine driving behaviors [0048]-[0053]. Slusar explicitly teaches determining whether a driving pattern is "appropriate" based on conditions, such as adjusting behavior thresholds based on "traffic density" [0050], which directly maps to determining appropriateness for the road condition.
and to transmit the result data of the determination to reflect the result data in a safe driving index of the driver of the preceding vehicle.
See at least:
[0007]: "driver scores may be calculated or adjusted based on the determined driving behaviors attributed to vehicle drivers. For example, vehicles/drivers engaging in positive driving behaviors indicative of safe driving may receive higher driver scores, while vehicles/drivers engaging in negative driving behaviors indicative of high-risk driving may receive lower driver scores"; [0055]: "If a driving analysis module 214 determines a 'negative' driving behavior for a driver of vehicle 210 in step 303, then the driving analysis module 214 may negatively adjust the driver's driver score in step 304. Similarly, if the driving analysis module 214 determines a 'positive' or safe driving behavior in step 303, then the driving analysis module 214 may positively adjust the driver score in step 304"; [0057]: "indications of these behaviors may be transmitted to the server 250 so that the driving analysis module 251 can perform the driver score calculations and updates based on the driving behaviors"
Rationale: Slusar explicitly teaches that driver scores (safe driving indices) are "calculated or adjusted based on the determined driving behaviors attributed to vehicle drivers" [0007], including both positive and negative adjustments based on behavior determinations [0055]. Slusar further teaches that "indications of these behaviors may be transmitted to the server 250" specifically "so that the driving analysis module 251 can perform the driver score calculations and updates based on the driving behaviors" [0057]. This directly maps to transmitting result data of the determination to reflect in a safe driving index of the driver.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar before them, to incorporate Slusar's V2V-based social interaction analysis and other-vehicle driver-score computation into the combined system. The references are in the same field of vehicle telematics and driver behavior analysis and provide complementary components. Brinkmann establishes camera-based road-condition analysis and driver scoring. Chen enables camera availability verification. Nemat-Nasser provides time-buffered image data. Lin teaches location-based triggering of operations upon receiving preceding vehicle location information. Slusar teaches that vehicle-to-vehicle communication enables determination of whether a preceding vehicle's driving behavior (tailgating, yielding, etc.) is appropriate for the situation and that driver scores can be calculated for other nearby vehicles. A PHOSITA would combine these teachings to create a comprehensive system where: upon receiving location information from a preceding vehicle (Lin), the following vehicle upon reaching that location retrieves and analyzes buffered camera data (Nemat-Nasser) to determine road conditions (Brinkmann), uses that analysis to evaluate whether the preceding vehicle's driving behavior was appropriate (tailgating vs. yielding) (Slusar), and then transmits that determination to reflect in the preceding vehicle's safe driving index (Slusar). This combination yields the predictable result of enabling fair, context-aware driver scoring even for vehicles lacking their own cameras.
Regarding Claim 12,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the method of Claim 11, which is the basis for Claim 12.
Disclosure by Brinkmann
Brinkmann teaches:
transmitting the location information of the vehicle
See at least: "To determine the vehicle's route, lane position, and other data, the telematics device 216 may include or may receive data from a mobile telephone, a Global Positioning System (GPS), locational sensors positioned inside a vehicle, or locational sensors or devices remote from the vehicle 210" (Column 6, lines 42-47); "telematics device 216 may be configured to receive and transmit data from operational sensors 212" (Column 5, lines 60-65)
Rationale: Brinkmann teaches transmitting location information of the vehicle via telematics/GPS systems, which reads on "transmitting the location information of the vehicle."
at a point in time that the driving pattern of the driver is out of the normal range,
See at least: "identify a potentially high-risk or unsafe driving event… in real-time or near real-time… and may retrieve image, video, or object proximity data associated with the driving event or near the same time…" (Column 10, lines 60-65)
Rationale: Brinkmann teaches that data retrieval and transmission are tied to the event time window—i.e., the point in time that the driving pattern is out of the normal range—as data is handled "associated with" that time.
so that the management server can adjust the safe driving index of the driver
See at least: "A driver score… may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event." (Abstract); "an insurance company server 101 may periodically calculate driver scores for one or more of the insurance company's customers, and may use the driver scores to perform insurance analyses and determinations" (Column 4, lines 1-5)
Rationale: Brinkmann teaches that the management server (e.g., "driving analysis server" or "insurance company server") adjusts the safe driving index based on analysis and determination results.
based on the result data
See at least: "A driver score… may be calculated or adjusted based on the analysis of the data and the determination of one or more causes of the driving event." (Abstract)
Rationale: Brinkmann teaches that adjustment is based on the analysis data and determination, which reads on "based on the result data."
Claim limitations Not Explicitly Taught by Brinkmann
Brinkmann does not explicitly teach:
wherein, in response to a determination that the camera is not installed in the vehicle, the method further comprises: transmitting the location information of the vehicle,
the location information of the vehicle being transmitted to the following vehicle of the vehicle;
and receiving result data
indicating whether the driving pattern of the driver is appropriate for the road condition
from the following vehicle
received from the following vehicle.
Disclosure by Chen
Chen teaches:
wherein, in response to a determination that the camera is not installed, the method further comprises: transmitting information
See at least: "In the embodiment of the present invention, the physical connection state between the camera module and the electronic device is detected; and the first prompt information is output on the electronic device according to the physical connection state. In this way, the user can process the camera module based on the prompt information output on the electronic device, thereby eliminating the connection failure of the camera module." (Pg. 6); "In a case where the physical connection state is the second connection state, the icon that controls the camera module is displayed as a second icon, and the second icon is used to prompt that the camera module is not installed (Pg. 7; Wherein, the first connection state is a state in which the camera module is installed in the electronic device, and the second connection state is a state in which the camera module is separated from the electronic device." (Pg. 4)
Rationale: Chen teaches detecting a physical connection state (determining whether the camera is installed). Chen further teaches that in response to detecting the second connection state (i.e., the camera is not installed), the method comprises outputting first prompt information. One of ordinary skill in the art would recognize that outputting information to a user interface (e.g., a display or speaker) necessarily requires transmitting information from a processor to the relevant output component. Therefore, Chen teaches "in response to a determination that the camera is not installed, the method further comprises: transmitting information."
Disclosure rendered obvious by the combination of Brinkmann and Chen:
The combination of Brinkmann and Chen renders obvious:
wherein, in response to a determination that the camera is not installed in the vehicle, the method further comprises: transmitting the location information of the vehicle,
Rationale: Chen teaches detecting a physical connection state and, in response to determining the camera is not installed (second connection state), transmitting information (outputting first prompt information). Brinkmann teaches transmitting location information of the vehicle via telematics/GPS systems during an out-of-normal-range driving event. A PHOSITA would have been motivated to combine these teachings such that, when Chen's determination indicates the camera is not installed, the system transmits Brinkmann's location information as the alternative payload. This predictable combination maintains event reporting functionality when camera data is unavailable, applying Chen's conditional transmission framework to Brinkmann's existing location-data transmission capabilities.
Motivation to Combine Brinkmann and Chen
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann and Chen before them, to incorporate Chen's camera installation determination and responsive information transmission into Brinkmann's vehicle-based driving analysis method. Brinkmann already teaches transmitting location information and adjusting driver scores based on driving events. Chen provides the missing conditional logic for when the camera is not installed, teaching that information should be transmitted in response to that determination. A PHOSITA would combine these teachings to create a robust system that maintains reporting functionality even when camera hardware is unavailable.
Claim limitations Not Explicitly Taught by the Combination of Brinkmann, Chen, Nemat-Nasser, and Lin
After combining the teachings of Brinkmann, Chen, Nemat-Nasser, and Lin, the following are not explicitly taught:
the location information of the vehicle being transmitted to the following vehicle of the vehicle;
and receiving result data
indicating whether the driving pattern of the driver is appropriate for the road condition
from the following vehicle
received from the following vehicle.
Disclosure by Slusar
Slusar teaches:
the location information of the vehicle being transmitted to the following vehicle of the vehicle;
See at least: "vehicles 210 and 220 may periodically broadcast corresponding sets of similar vehicle driving data, such as the location (which may include an absolute location in GPS coordinates or other coordinate systems, and/or a relative location with respect to another vehicle or a fixed point), speed, and direction of travel." ([0033]); "the first vehicle 202 can transmit a transmission 210 to a second vehicle (V2) 212, and/or may transmit a transmission 214 to one or more central server(s) 216." ([0025])
Rationale: Slusar explicitly teaches transmitting location information of a vehicle to another vehicle (e.g., "second vehicle (V2) 212"), which reads on "the location information of the vehicle being transmitted to the following vehicle of the vehicle."
and receiving result data
See at least: "indications of these behaviors may be transmitted to the server 250 so that the driving analysis module 251 can perform the driver score calculations and updates based on the driving behaviors" ([0057]); "the data ingestion module 326 can receive transmissions" ([0059])
Rationale: Slusar teaches a bidirectional communication framework where vehicles transmit data and can receive information. A PHOSITA would understand that in a V2V system, receiving result data is a predictable counterpart to transmitting information, enabling closed-loop feedback between vehicles.
indicating whether the driving pattern of the driver is appropriate for the road condition
See at least: "driver scores may be calculated or adjusted based on the determined driving behaviors attributed to vehicle drivers. For example, vehicles/drivers engaging in positive driving behaviors indicative of safe driving may receive higher driver scores, while vehicles/drivers engaging in negative driving behaviors indicative of high-risk driving may receive lower driver scores" ([0007]); "If a driving analysis module 214 determines a 'negative' driving behavior for a driver of vehicle 210 in step 303, then the driving analysis module 214 may negatively adjust the driver's driver score in step 304. Similarly, if the driving analysis module 214 determines a 'positive' or safe driving behavior in step 303, then the driving analysis module 214 may positively adjust the driver score in step 304" ([0055])
Rationale: Slusar teaches that driving behaviors are evaluated (indicating whether the driving pattern is appropriate) and that these determinations are reflected in driver scores. Result data indicating such appropriateness determinations would be the type of information shared between vehicles in a V2V system.
from the following vehicle
See at least: "the first vehicle 102 may capture data associated with the bicycle 108 and may transmit data 116 to the second vehicle 110" ([0020]); "the data ingestion module 326 can receive transmissions" ([0059])
Rationale: Slusar establishes that vehicles are configured to both transmit and receive data from other vehicles. A PHOSITA would find it obvious that, in a V2V system where a vehicle transmits location information to a following vehicle, the same vehicle would also be configured to receive result data from that following vehicle as part of normal inter-vehicle communication.
received from the following vehicle.
See at least: "the first vehicle 102 may capture data associated with the bicycle 108 and may transmit data 116 to the second vehicle 110" ([0020]); "the data ingestion module 326 can receive transmissions" ([0059])
Rationale: The same teachings support this limitation. Slusar's framework of bidirectional V2V communication inherently includes receiving data from the following vehicle as the reciprocal operation to transmitting data to it.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar before them, to incorporate Slusar's bidirectional V2V communication framework into the combined system established for Claim 11. The Claim 11 combination already integrates camera installation detection (Chen), event-triggered buffered imaging (Nemat-Nasser), moving object determination (Lin), and server-based driver scoring (Brinkmann). Slusar explicitly teaches that vehicles transmit location information to following vehicles and can receive data from other vehicles as part of normal V2V communication. A PHOSITA would recognize that, when the camera is not installed (as determined by Chen) and location information is transmitted (as taught by Brinkmann), it is a predictable design choice to transmit that location information directly to a following vehicle (as taught by Slusar) to provide immediate situational awareness. Furthermore, Slusar's framework of bidirectional communication would naturally include receiving result data from that following vehicle indicating whether the driving pattern was appropriate, creating a closed-loop feedback system that enhances driver scoring accuracy. This combination yields the predictable result of a comprehensive V2X safety ecosystem where vehicles collaborate to validate driving behaviors and adjust safe driving indices based on third-party observations.
Regarding Claim 16,
The combination of Brinkmann, Chen, Nemat-Nasser, and Lin establishes the method of Claim 15, which is the basis for Claim 16.
Disclosure by Brinkmann
Brinkmann teaches
further comprising:
See at least: "If the driving analysis server 220 determines , based on the previous driving behavior and driver profile , that the vehicle was being driven safely prior to and during the swerving , braking , or impact to the vehicle ( 405 : Safe ) , then the driv er's score may be positively adjusted in step 406." (Column 16, lines 20-24)
Rationale: Brinkmann teaches further comprising additional steps like positive score adjustment based on determinations.
when the driver turns on the hazard lights to inform the following vehicle of the road condition,
See at least: “sensors 212 also may detect and store data received from the vehicle’s 210 internal systems, such as… hazard lights usage…” (Col. 5, ll. 18–27)
Rationale: Brinkmann expressly discloses “hazard lights usage,” which inherently occurs when the driver turns on hazard lights. Further, the functional purpose “to inform the following vehicle of the road condition” is the conventional, well-understood use of hazard lights as a visible warning signal to other traffic (including following vehicles) regarding a hazard/unsafe condition; thus, the recited “when” clause would have been obvious to a PHOSITA in view of Brinkmann’s disclosed hazard-light usage being captured during driving events/conditions.
and increasing the safe driving index of the driver.
See at least: "If the driving analysis module 221 determines that the driver of the vehicle 210 was driving in a competent and safe manner during the driving event (405: Safe), then the driver's score may be positively adjusted in step 406." (Column 16, lines 20-24)
Rationale: Brinkmann teaches and increasing the safe driving index of the driver by positively adjusting the driver's score.
Claim limitations Not Explicitly Taught by Brinkmann
Brinkmann does not explicitly teach:
receiving information indicating the hazard lights flashed;
Disclosure by Slusar
Slusar teaches:
receiving information indicating the hazard lights flashed;
See at least: "the state or usage of the vehicle's 210 controls and instruments may also be transmitted, for example, whether the vehicle is accelerating, braking, turning, and by how much, and/or which of the vehicle's instruments are currently activated by the driver (e.g., head lights, turn signals, hazard lights, cruise control, 4-wheel drive, traction control, etc.)." ([0033])
Rationale: Slusar teaches receiving information indicating the hazard lights flashed by transmitting/receiving usage of hazard lights as activated instruments.
Motivation to Combine Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Nemat-Nasser, Lin, and Slusar before them, to incorporate Slusar’s hazard-light broadcast warning technique into the already-combined Brinkmann-based driver-event reporting and scoring framework (with camera-availability handling and obstacle sharing), because Brinkmann already collects and reports “hazard lights usage” as vehicle operation data used for driver scoring/event characterization, while Slusar teaches broadcasting “hazard lights” information to other vehicles to warn them of hazardous conditions; integrating these teachings predictably yields the expected result that the same hazard-light activation both (i) informs a following vehicle and (ii) is received and used within the driver-scoring pipeline, improving safety communication and scoring robustness without changing the fundamental operation of either system.
Regarding Claim 17,
Disclosure by Brinkmann
Brinkmann teaches:
A method
See at least: “FIG. 3 is a flow diagram illustrating an example method of performing a driving event analysis and adjusting driver score based on a driving event identified for a vehicle, using image data, video data, and/or object proximity data associated with the driving event.” (Col. 8, ll. 24–28; FIG. 3)
Rationale: Brinkmann expressly uses the term “example method,” which teaches the claimed “A method.”
comprising:
See at least: “FIG. 3 is a flow diagram illustrating an example method of performing a driving event analysis and adjusting driver score…” ( Col. 8, ll. 24–28, FIG. 3)
Rationale: Brinkmann’s “example method” language establishes the open-ended “comprising” format of the claimed method.
receiving result data relating to whether a driving pattern of a driver of a vehicle is appropriate
See at least: “In step 301, a driving analysis server 220 may receive vehicle operation data (or driving data) for a vehicle 210.” (Fig. 3)
Rationale: Brinkmann expressly teaches “receive vehicle operation data (or driving data),” which constitutes the claimed “result data” used to evaluate driving behavior and whether the driving pattern is appropriate.
based on a determination that the driving pattern of the driver is out of a normal range while the vehicle is driving;
See at least: “The steps in the example method of FIG. 3 describe performing an analysis to determine whether or not to adjust a driver score in response to a potentially high-risk or unsafe driving event (e.g., an occurrence of sudden braking or swerving…)” (Fig. 3)
Rationale: Brinkmann expressly teaches identifying “potentially high-risk or unsafe driving event,” which corresponds to the driving pattern being “out of a normal range while the vehicle is driving.”
and adjusting a safe driving index of the driver based on the received result data,
See at least: “The driver score calculation module 222 may use the results of the driving event analysis performed by module 221 to calculate or adjust a driver score for a driver of a vehicle 210…” ( Fig. 3)
Rationale: Brinkmann explicitly “calculate or adjust a driver score,” which corresponds to adjusting the claimed “safe driving index” based on the received driving data/results.
wherein, when a camera, which is able to capture image data related to a road condition
See at least: “camera data (e.g., image, audio, and/or video)… (Col. 7, ll. 1-5); “External cameras and proximity sensors 214 may detect… road conditions…” (Col. 5, ll. 44-48)
Rationale: Brinkmann expressly discloses “camera data (e.g., image… video)” and that “External cameras… may detect… road conditions,” matching the claimed camera capturing image data related to road condition.
and which is installed in the vehicle,
See at least: “The vehicle 210 also may include one or more cameras and proximity sensors 214…” ( Col. 5, ll. 38–40)
Rationale: Brinkmann explicitly states the vehicle “may include” cameras, i.e., installed in the vehicle.
the result data is received from the vehicle
See at least: “the telematics device 216 may receive vehicle operation and driving data from vehicle sensors 212, and proximity sensors and cameras 214, and may transmit the data to… a driving analysis server 220…” ( Col. 6, ll. 7–15)
Rationale: Brinkmann explicitly teaches that vehicle-collected data is transmitted to the server, i.e., “received from the vehicle.”
and is based on the driving pattern of the driver
See at least: “sensors 212 may detect and store data corresponding to the vehicle’s speed… rates of acceleration or braking… sudden acceleration, braking, and swerving.” ( Col. 5, ll. ~12–18)
Rationale: Brinkmann expressly teaches receiving driving behavior metrics (speed, acceleration/braking, swerving), which are the driver’s driving pattern.
and the road condition shown in the image data captured by the camera,
See at least: “…using image data, video data, and/or object proximity data… “ (Col. 8, ll. 24-32); “road conditions…” (Col. 5, ll. 44-48)
Rationale: Brinkmann expressly ties “image data, video data” with “road conditions,” indicating road conditions are shown/derived from captured camera image/video data.
about whether hazard lights flash
See at least: “…hazard lights usage…” (Col. 5, ll. ~20–25)
Rationale: Brinkmann expressly recites “hazard lights usage,” which is information about whether hazard lights flash.
Claim limitations Not Explicitly Disclosed by Brinkmann
Brinkmann does not explicitly teach:
wherein, when the camera is not installed in the vehicle,
the method further comprises transmitting location information
to a following vehicle of the vehicle,
and receiving the result data from the following vehicle,
and wherein the method further comprises:
receiving obstacle-related information
including a size and a location of the obstacle,
a lane, or a time
when an obstacle is recognized in the road condition
shown in the image data,
collecting the obstacle-related information
continuously reported based on timestamps,
determining,
based on analyzing the location of the obstacle and lanes
and based on the obstacle-related information,
whether the obstacle is a moving object,
and transmitting,
based on a determination that the obstacle is the moving object,
the obstacle-related information
to a second vehicle,
which is configured to receive the obstacle-related information
and avoid the obstacle-related information.
Disclosure by Chen
Chen teaches:
wherein, when the camera is not installed in the vehicle,
See at least: “When the camera module is not installed in the electronic device…”; (Pg. 3); “the second icon is used to prompt that the camera is not installed Module…” (Pg. 4); “the second connection state is a state in which the camera module is separated from the electronic device.” (Pg. 7)
Rationale: Chen expressly teaches the conditionally trigger of the camera “is not installed” and is “separated,” providing the missing “camera is not installed” condition.
Disclosure rendered obvious by the combination of Brinkmann and Chen
The combination of Brinkmann and Chen renders obvious:
when the camera is not installed in the vehicle, the method further comprises transmitting location information about whether hazard lights flash the method further comprises transmitting location information about whether hazard lights flash
Rationale: Brinkmann already teaches the collection of location information and whether hazard lights flash (hazard lights usage) as part of the vehicle's telemetry. Chen teaches the conditional logic to perform an alternative action when a camera is not detected. It would have been obvious to a PHOSITA to transmit these available safety indicators as a fallback when the primary camera-based analysis is impossible due to the camera not being installed.
Motivation to Combine Brinkmann and Chen
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann and Chen before them, to modify Brinkmann by incorporating Chen’s camera-installation status detection (camera installed vs. camera not installed) in order to allow Brinkmann’s camera-dependent driving/road-condition analysis framework to robustly handle situations when a vehicle camera is absent or disconnected, yielding predictable improved reliability in driver-event evaluation without changing Brinkmann’s core scoring logic. A PHOSITA having Brinkmann and Chen would find it obvious configure Brinkmann’s vehicle-side processing to, upon identification of an out-of-normal-range driving pattern, use Chen’s processor-based determination of whether the camera module is installed to control data transmission. In modern vehicle safety design, robustness is achieved through redundant reporting paths. If a camera is absent, the system cannot provide visual evidence of a road hazard; however, hazard lights and precise GPS coordinates are high-value telemetry that can signal an emergency to the network. Combining Chen's hardware detection with Brinkmann's safety telemetry provides a predictable enhancement to system reliability, ensuring that even vehicles without functional cameras can contribute to a safety database and maintain score integrity through non-visual cues.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann and Chen
After combining Brinkmann and Chen, the following are not explicitly taught:
transmitting location information to a following vehicle of the vehicle,
and receiving the result data from the following vehicle,
and wherein the method further comprises:
receiving obstacle-related information
including a size and a location of the obstacle,
a lane, or a time
when an obstacle is recognized in the road condition
shown in the image data,
collecting the obstacle-related information
continuously reported based on timestamps,
determining,
based on analyzing the location of the obstacle and lanes
and based on the obstacle-related information,
whether the obstacle is a moving object,
and transmitting,
based on a determination that the obstacle is the moving object,
the obstacle-related information
to a second vehicle,
which is configured to receive the obstacle-related information
and avoid the obstacle-related information.
Disclosure by Lin
Lin teachings:
and wherein the method further comprises:
See at least: “This disclosure describes methods… for sharing vehicle obstacle data…” ([0010])
Rationale: Lin expressly teaches additional method steps for obstacle-data sharing, satisfying the “method further comprises” transition.
receiving obstacle-related information
See at least: “FIG. 5 depicts an example process 500 for receiving obstacle data at a vehicle…” ([0072])
Rationale: Lin explicitly teaches “receiving obstacle data,” which is obstacle-related information.
including a size and a location of the obstacle,
See at least: “…may determine two-dimensional or three-dimensional bounding boxes associated with objects…” ([0051])
Rationale: Lin’s “two-dimensional or three-dimensional bounding boxes” inherently include object size and location.
a lane, or a time
See at least: “…determining a location, time… lane position…” ([0069])
Rationale: Lin explicitly lists “lane position” and “time” as metadata, meeting “a lane, or a time.”
when an obstacle is recognized in the road condition
See at least: “…a timestamp associated with capturing data associated with the obstacle 204…” ([0029])
Rationale: Lin explicitly discloses a timestamp tied to capturing obstacle data, corresponding to when the obstacle is recognized.
shown in the image data,
See at least:“…for a camera sensor capturing video data…” ([0012])
Rationale: Lin expressly teaches camera/video data capturing obstacles, satisfying obstacle recognition shown in image data.
collecting the obstacle-related information
See at least: “At operation 502, the process can include capturing sensor data.” ([0073])
Rationale: Lin’s “capturing sensor data” teaches collecting obstacle-related information.
continuously reported based on timestamps,
See at least:“…a timestamp associated with the transmission 210… As time progresses…” ([0032])
Rationale: Lin expressly teaches timestamped transmissions and time-based progression, supporting continuous timestamp-based reporting.
determining,
See at least: “…perform classification on data to determine an occurrence of an event…” ([0052])
Rationale: Lin explicitly teaches “determine,” meeting the determining step.
based on analyzing the location of the obstacle and lanes
See at least: “…move the autonomous vehicle in a lane away from an expected location of the disabled vehicle…” ([0016])
Rationale: Lin expressly teaches lane-based motion planning relative to obstacle location, corresponding to analyzing obstacle location and lanes.
and based on the obstacle-related information,
See at least:“…the transmission 210 may include any data related… related to the obstacle 204.” ([0028])
Rationale: Lin expressly identifies transmissions including data related to the obstacle, i.e., obstacle-related information.
whether the obstacle is a moving object,
See at least: “dynamic information (e.g., representing moving cars, bicycles, pedestrians…)” ([0014])
Rationale: Lin expressly distinguishes “dynamic information” representing moving objects, matching moving object determination.
and transmitting,
See at least: “…dynamic information… may be transmitted directly to other vehicles.” ([0014])
Rationale: Lin explicitly teaches transmitting dynamic obstacle information.
based on a determination that the obstacle is the moving object,
See at least: “…distinguish between static objects and dynamic objects… determine a velocity of a dynamic object…” ([0056])
Rationale: Lin expressly teaches determining an object is dynamic (moving), which is the basis for transmitting moving-object info.
the obstacle-related information
See at least: “…determine data to be transmitted regarding the obstacle…” ([0057])
Rationale: Lin explicitly recites “data… regarding the obstacle,” i.e., obstacle-related information.
to a second vehicle,
See at least: “…may transmit the transmission 210 to the second vehicle 212.” ([0028])
Rationale: Lin expressly discloses transmitting to a “second vehicle.”
which is configured to receive the obstacle-related information
See at least: “…transmit and/or receive data to and from various vehicles…” ([0058])
Rationale: Lin expressly teaches a communication module configured to receive shared vehicle/obstacle transmissions.
and avoid the obstacle-related information.
See at least: “At operation 510… operating the vehicle based at least in part on the data… generating commands… braking… steering… to navigate…” ([0077])
Rationale: Lin explicitly teaches operating a vehicle using the received data by braking/steering to navigate, which corresponds to avoidance behavior based on the obstacle-related information.
Motivation to Combine Brinkmann, Chen, and Lin
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, and Lin before them, to incorporate Lin’s obstacle-data capture, classification (static vs. dynamic), timestamped reporting, and inter-vehicle transmission techniques into Brinkmann’s driving-event analysis and driver-score adjustment framework (as conditionally controlled by Chen’s camera-installed versus camera-not-installed status), because Brinkmann already relies on vehicle-collected sensing/telematics (including camera data when available) to evaluate driving events and adjust driver score, Chen provides a predictable hardware-state trigger identifying when camera-based evidence is unavailable, and Lin provides a compatible and known solution for generating and sharing obstacle-related data (including bounding boxes, time, and lane-related context) that improves roadway hazard awareness and driving-event context. A PHOSITA would have been motivated to combine these teachings to achieve a predictable enhancement in robustness and safety-context fidelity—namely, enabling Brinkmann’s event analysis/score adjustment to be supported by Lin’s obstacle information generation/sharing pipeline under the same telematics/communications environment, particularly in scenarios where Chen indicates the camera is absent or disconnected, thereby improving reliability of safety determinations without changing the fundamental scoring architecture taught by Brinkmann.
Claim limitations Not Explicitly Disclosed by the Combination of Brinkmann, Chen, and Lin
After combining Brinkmann, Chen, and Lin, the following are not explicitly disclosed:
the method further comprises transmitting location information to a following vehicle of the vehicle,
and receiving the result data from the following vehicle,
Disclosure by Slusar
Slusar teaches:
the method further comprises transmitting location information
See at least: “vehicles 210 and 220 may periodically broadcast… vehicle driving data, such as the location…” ([0033])
Rationale: Slusar expressly teaches transmitting/broadcasting “the location,” satisfying transmitting location information.
to a following vehicle of the vehicle,
See at least:“…configured to transmit vehicle operational data to other nearby vehicles…” ([0030])
Rationale: Slusar explicitly teaches transmitting to “other nearby vehicles,” which includes a following vehicle as a predictable recipient in V2V communications.
and receiving the result data from the following vehicle,
See at least: “…configured… to receive vehicle operational data from other nearby vehicles.” ([0030])
Rationale: Slusar expressly discloses receiving vehicle operational/result data from another vehicle via V2V, corresponding to receiving result data from a following vehicle.
Motivation to Combine Brinkmann, Chen, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Lin, and Slusar before them, to further modify the combined Brinkmann/Chen/Lin system by incorporating Slusar’s V2V broadcast/receive mechanism for transmitting vehicle operational data such as location (and related safety-indicator status) to other nearby vehicles and receiving corresponding vehicle operational data from other nearby vehicles, because Slusar expressly teaches a directly compatible vehicle-to-vehicle communication layer for exchanging such information, Lin already teaches transmitting obstacle-related data between vehicles, and Brinkmann already teaches telematics transmission of vehicle driving data to a remote analysis server for safety scoring. A PHOSITA would have been motivated to add Slusar’s V2V exchange to provide a predictable redundant communication path enabling cooperative sensing and data sharing between vehicles in the same roadway environment—particularly to support the camera-absent condition identified via Chen—so that location/safety signaling can be delivered to nearby (including following) vehicles and data can be received back from those vehicles, yielding predictable improvements in system robustness, timeliness of hazard awareness, and completeness of the data used for driving-event evaluation and score adjustment as taught by Brinkmann..
Regarding Claim 19,
The combination of Brinkmann, Chen, Lin, and Slusar establishes the method of Claim 17, which is the basis for Claim 19.
Disclosure by Brinkmann
Brinkmann teaches:
wherein adjusting the safe driving index of the driver comprises increasing the safe driving index of the driver in response to the result data indicating that the driving pattern of the driver is appropriate for the road condition.
See at least Fig. 4.
FIG. 4 shows retrieving image/video/proximity data (403) to determine cause/conditions (404) and evaluate driving behavior as safe (405); when results indicate safe under conditions, driver score is positively adjusted (406).
Motivation to Combine Brinkmann, Chen, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Lin, and Slusar before them, to combine (i) Brinkmann’s driving-event analysis and driver-score adjustment framework using vehicle operation data and camera/proximity data, with (ii) Chen’s camera-installed versus camera-not-installed detection logic to conditionally control fallback behavior when camera-derived road-condition image data is unavailable, further with (iii) Lin’s obstacle-related information generation/receipt/classification (static vs. dynamic), timestamped reporting, and inter-vehicle transmission of obstacle data to support cooperative hazard awareness, and further with (iv) Slusar’s vehicle-to-vehicle broadcasting and receiving of vehicle operational data such as location (and safety-indicator status such as hazard lights) to nearby vehicles including a following vehicle, because each reference is in the same vehicle safety/telematics and inter-vehicle communication field, the teachings are technically compatible and complementary (camera-status gating; hazard/location fallback; obstacle-data sharing; scoring/event analysis), and the combination yields predictable results of improved robustness and completeness of the data used for safety determination and score adjustment—namely, enabling the vehicle to provide camera-based road-condition analysis when available, to instead share location and hazard status when the camera is absent, and to receive and distribute obstacle-related information among vehicles for avoidance and safety scoring without altering Brinkmann’s fundamental score-adjustment architecture.
Regarding Claim 20,
The combination of Brinkmann, Chen, Lin, and Slusar establishes the method of Claim 19, which is the basis for Claim 20.
Disclosure by Brinkmann
Brinkmann teaches:
further comprising:
See at least: “RECEIVE VEHICLE DRIVING DATA” (FIG. 4, Step 401)Rationale: further comprising: is taught because Brinkmann’s FIG. 4 expressly sets out additional method operations, including Step 401, consistent with an open-ended “further comprising” recitation.
receiving hazard-light related information
See at least: “RECEIVE VEHICLE DRIVING DATA” (FIG. 4, Step 401); “… data corresponding to … hazard lights usage …” (Col. 5, ll. 20–25)
Rationale: receiving hazard-light related information is taught because Brinkmann expressly receives “VEHICLE DRIVING DATA” (Step 401) and expressly identifies “hazard lights usage” as included within the vehicle data, which is hazard-light related information that is received.
and increasing the safe driving index of the driver
See at least: “POSITIVELY ADJUST DRIVER SCORE” (FIG. 4, Step 406)
Rationale: and increasing the safe driving index of the driver is taught because Brinkmann expressly performs “POSITIVELY ADJUST DRIVER SCORE” (Step 406), which corresponds to increasing a safe driving index / driver score.
Claim limitations Not Explicitly Disclosed by Brinkmann
Brinkmann does not explicitly teach:
indicating the hazard lights of the vehicle are being flashed
to inform the following vehicle of the road conditions
in response to the received hazard-light related information.
Disclosure by Slusar
Slusar teaches:
indicating the hazard lights of the vehicle are being flashed
See at least: “…may periodically broadcast … which … instruments … are activated (e.g., hazard lights) …” ([0033])
Rationale: indicating the hazard lights of the vehicle are being flashed is taught because Slusar expressly describes broadcasting an indication that “hazard lights” are activated, which conveys hazard-light status to other vehicles.
to inform the following vehicle of the road conditions
See at least: “…configured to transmit vehicle operational data to other nearby vehicles …” ([0030]); “…may periodically broadcast … which … instruments … are activated (e.g., hazard lights) …” ([0033])
Rationale: to inform the following vehicle of the road conditions is taught because Slusar expressly teaches transmitting hazard-light activation status to “other nearby vehicles,” which predictably includes a following vehicle, and hazard-light activation is a roadway signal used to inform nearby/following vehicles of hazardous road conditions.
Disclosure rendered obvious by the combination of Brinkmann and Slusar
The combination of Brinkmann and Slusar renders obvious:
increasing the safe driving index of the driver in response to the received hazard-light related information.
See at least: “… data corresponding to … hazard lights usage …” (Brinkmann, Col. 5, ll. 20–25); “POSITIVELY ADJUST DRIVER SCORE” (Brinkmann, FIG. 4, Step 406); “…may periodically broadcast … which … instruments … are activated (e.g., hazard lights) …” (Slusar, [0033])
Rationale: This is rendered obvious because Brinkmann expressly receives vehicle driving data that includes “hazard lights usage” and expressly performs “POSITIVELY ADJUST DRIVER SCORE,” and Slusar expressly treats hazard-light activation as broadcast safety/roadway-condition signaling to other vehicles; thus, it would have been obvious to a PHOSITA to configure Brinkmann’s score-adjustment logic to increase the safe driving index when the received hazard-light related information indicates the driver used hazard lights appropriately to signal hazardous road conditions, yielding a predictable safety-scoring enhancement consistent with both references.
Motivation to Combine Brinkmann, Chen, Lin, and Slusar
Therefore, given the teachings as a whole, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, having Brinkmann, Chen, Lin, and Slusar before them, to implement the Claim 20 method as a dependent refinement of the already-combined Claim 19/17 method by (i) using Brinkmann’s receipt of vehicle driving data and driver-score adjustment logic (including “hazard lights usage” as part of received driving data and “POSITIVELY ADJUST DRIVER SCORE”), (ii) using Chen’s camera-installed versus camera-not-installed status detection to control alternative communication/reporting paths when camera-derived road-condition evidence is unavailable, (iii) using Lin’s inter-vehicle hazard/obstacle data exchange techniques to support cooperative awareness in the same connected-vehicle environment, and (iv) using Slusar’s V2V broadcasting to other nearby vehicles of operational data including activation of instruments such as hazard lights, because these teachings are in the same vehicle safety/telematics and inter-vehicle communication field, are technically compatible and complementary (driver scoring based on received driving data; conditional fallback based on camera presence; cooperative data sharing; V2V broadcast of hazard-light status), and the combination yields predictable results of improved robustness and safety signaling—namely, that hazard-light related information can be received and used as part of the driving data for positive safe-driving-index adjustment while also being transmitted to a following vehicle to inform it of road conditions, without altering Brinkmann’s underlying scoring architecture.
Response to Arguments
Applicant’s arguments filed 12/03/2025 have been fully considered.
112 REJECTIONS — WITHDRAWN
The prior rejections under 35 U.S.C. 112(a) and 112(b) are withdrawn.
101 REJECTION — MAINTAINED (CLAIMS 1–3, 5, 8–12, 14–17)
Claims 1–3, 5, 8–12, and 14–17, 19 and 20 remain rejected under 35 U.S.C. 101 as outlined in the 101 rejection section.
RESPONSE TO PRIOR-ART TRAVERSAL — FINAL REJECTION OVERCOMES THE NON-FINAL ARGUMENTS
Claim 17 and related claims
A. Applicant’s assertion: “The references of record do not teach or suggest such a method.”
Applicant’s conclusion is not persuasive because the final rejection applies additional, directly-on-point teachings, in light of the amendments to the claims, to supply the features Applicant alleges are missing, specifically:
Chen supplies the camera-installed vs. camera-not-installed condition logic (camera module separated/not installed).
Lin supplies the server-mediated obstacle-data architecture, including obstacle-data content (e.g., bounding boxes), time/timestamp association, static/dynamic (moving) classification, and downstream dissemination for vehicle avoidance behavior. (Lin [0003], [0010], [0029], [0060], [0077])
Slusar supplies V2V dissemination to nearby vehicles (including a following vehicle as an obvious subset of nearby vehicles) and periodic broadcast of location and operational data using vehicular wireless communication. (Slusar [0030], [0033], [0034])
Brinkmann supplies the driver-score/safe-driving-index adjustment framework based on received driving/telemetry and contextual data, which the final rejection augments with Lin/Slusar/Chen for robustness and cooperative safety reporting.
Accordingly, Applicant’s “not taught/suggested” position does not address the final applied combination’s express teachings.
B. Applicant’s Brinkmann argument: “Brinkmann focuses on evaluating the score of the first vehicle’s driver” and “does not teach a server-mediated warning system…”
This argument is not persuasive for two reasons:
Claim 17 does not require Brinkmann alone to be a server-mediated warning system. Brinkmann is relied upon in the final rejection for the safe-driving-index/driver-score adjustment pipeline and the receipt/use of vehicle-derived result/telemetry in a remote processing context. The final rejection then adds (i) Chen for camera-not-installed conditionality and (ii) Lin/Slusar for obstacle dissemination and inter-vehicle sharing.
The server-mediated obstacle architecture Applicant says is missing is taught by Lin, not Brinkmann. Lin explicitly describes obstacle-data sharing via central server(s) and dissemination to other vehicles. (Lin [0010], [0029], [0034])
So, Applicant’s criticism of Brinkmann does not defeat obviousness because the final rejection does not rely on Brinkmann for the allegedly missing server-mediated obstacle-sharing features.
C. Applicant’s “timestamp-based continuous collection + moving object determination + server dissemination” argument
Applicant argues the art fails to teach:
continuous collection “based on timestamps,”
server-side analysis to determine a “moving object,” and
server transmission of the processed obstacle information to another vehicle for avoidance.
This is not persuasive because Lin teaches these exact functional blocks in the same vehicle-safety/cooperative-driving context:
Obstacle-related information content (size/location): Lin describes determining 2D/3D bounding boxes for objects (size/location information inherent in bounding boxes). (Lin [0003])
Time/timestamp association and repeated reporting: Lin describes obstacle data including a timestamp associated with capturing obstacle data and transmission fields including time/location/speed/heading—supporting the claimed timestamped reporting/collection concept. (Lin [0029])
Moving object determination (static vs dynamic): Lin explicitly distinguishes static objects and dynamic objects and determines velocity for a dynamic object—this is the claimed moving-object determination. (Lin [0060])
Dissemination to other vehicles and “avoid” functionality: Lin describes operating the vehicle based on received obstacle data, including generating commands for braking/steering to navigate—i.e., avoidance based on obstacle-related information. (Lin [0077])
Applicant’s argument frames “avoidance” as requiring some special “actual avoidance maneuvers” linkage not derivable from the record. However, Lin explicitly provides that operational linkage (commands for braking/steering) and therefore directly rebuts Applicant’s contention. (Lin [0077])
D. Applicant’s Slusar argument: “primarily direct V2V… does not teach a central management server that performs specific data processing…”
Applicant’s characterization is incomplete and, in any event, does not overcome the final rejection.
Slusar is applied for the communication topology and dissemination (broadcast/transmit to nearby vehicles, including a following vehicle as an obvious subset), not for Lin’s specific moving-object classification logic. Slusar teaches vehicle communication modules configured to transmit operational data to other nearby vehicles and receive from other nearby vehicles, supporting the “to a following vehicle” transmission/receipt framework in Claim 17’s camera-not-installed branch. (Slusar [0030])
Slusar also teaches periodic broadcast including location as a type of vehicle driving data. (Slusar [0033], [0034])
To the extent Applicant asserts Slusar lacks server-side moving-object determination, that feature is supplied by Lin, which is exactly why Lin is applied in the final rejection. (Lin [0060])
Therefore, Applicant’s Slusar critique does not address what Slusar is actually used for in the final rejection, nor does it rebut Lin’s server-mediated obstacle processing and dissemination teachings.
E. Applicant’s Goto argument
Applicant’s discussion of Goto is not persuasive because, under the final applies combination, the asserted missing limitations are met via Lin (server-mediated obstacle processing and dissemination) and Slusar (inter-vehicle dissemination and location broadcast), with Chen providing camera-not-installed conditionality.
Thus, Applicant’s Goto-based critique does not undermine the final rejection’s mapping and rationale.
F. Applicant’s “Nemat-Nasser and Selig do not really relate” argument
Applicant’s contention is not persuasive because the final rejection’s core disputed features (server-mediated obstacle collection/analysis, timestamp association, moving-object classification, dissemination for avoidance, and camera-not-installed fallback handling) are addressed by Lin + Slusar + Chen, in combination with Brinkmann’s scoring framework. (Lin [0010], [0029], [0060], [0077]; Slusar [0030], [0033], [0034]; Chen.
Accordingly, even if Applicant alleges certain prior art in the earlier record is “not really” directed to server configurations, the final rejection applies additional art that is directly directed to those server-mediated and cooperative-driving functions.
G. Applicant’s “even if combined, not obvious to construct server-mediated safety system… connected to avoidance maneuvers” argument
This argument is not persuasive because:
The final applied references are field-compatible (vehicle telemetry / cooperative safety / obstacle data sharing / remote processing) and provide complementary teachings:
Brinkmann: driver scoring/safe-driving-index adjustment based on analyzed driving event/conditions;
Chen: robust detection of camera installed/not installed (fallback branching);
Lin: server-mediated obstacle-data ingestion, timestamp/time association, static/dynamic determination, dissemination to other vehicles, and vehicle operation (braking/steering) based on the data;
Slusar: dissemination to nearby/following vehicles and periodic broadcast including location.
The combination yields predictable results a PHOSITA would reasonably pursue: improved robustness and cooperative safety reporting when camera data is unavailable, and enhanced hazard dissemination to other vehicles while maintaining/augmenting the scoring framework.
Applicant’s “avoidance maneuvers” premise is overly narrow. Claim 17 recites the second vehicle is “configured to… avoid… based on” the obstacle-related information; Lin explicitly teaches vehicle operation (including braking/steering commands) based on received obstacle data, which is avoidance behavior based on that information. (Lin [0077])
H. Applicant’s “Claims 1 and 11 are allowable for similar reasons” argument
This is not persuasive because the premise (Claim 17 is allowable) is not established. The same deficiencies alleged by Applicant for Claim 17 are addressed by the final rejection’s use of Chen/Lin/Slusar in combination with Brinkmann, and therefore the “similar reasons” argument fails for Claims 1 and 11 as well.
I. Applicant’s dependent-claims argument: “Dependent claims are allowable because they depend from an allowable claim… not necessary to separately address”
This argument is not persuasive. Dependent claims are not automatically allowable merely because Applicant asserts an independent claim is allowable. Since the independent claims remain unpatentable for the reasons above, the dependent-claim allowability argument necessarily fails. Further, Applicant’s decision not to substantively address the dependent limitations does not overcome the specific mappings and rationales set forth in the rejections.
103 Conclusion
For the reasons above, Applicant’s arguments do not overcome the final 103 rejections. The applied combination Brinkmann + Chen + Lin + Slusar renders obvious the server-mediated obstacle collection/analysis and dissemination (including timestamp association, dynamic/moving-object determination, and avoidance based on received obstacle information), as well as the camera-not-installed fallback communications and location broadcast to a following vehicle.
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 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 OLUWABUSAYO ADEBANJO AWORUNSE whose telephone number is (571)272-4311. The examiner can normally be reached M - F (8:30AM - 5PM).
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, Jelani Smith can be reached at (571) 270-3969. 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.
/OLUWABUSAYO ADEBANJO AWORUNSE/Examiner, Art Unit 3662
/JELANI A SMITH/Supervisory Patent Examiner, Art Unit 3662