DETAILED ACTION
This office action is in response to communication filed on 25 November 2024.
Claims 1 – 20 are presented for examination.
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.
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 – 4 and 6 – 20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to the judicial exception of abstract ideas without significantly more. The independent claims recite capturing driving behavior data while a vehicle is operated by a driver to traverse a route, determining a safe driving threshold based on: dynamic contextual attributes of the route, and historical driving behaviors exhibited, while traversing the route, by a second driver distinct from the first driver, the historical driving behaviors represented by sensor data, determining that a parameter represented in the driving behavior data meets or exceeds the safe driving threshold, based on determining that the parameter meets or exceeds the safe driving threshold, generating an executable instruction; and transmitting the executable instruction to an infrastructure component, the executable instruction causing modification of an operational behavior of the infrastructure component. This judicial exception is not integrated into a practical application. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The eligibility analysis in support of these findings is provided below, in accordance section 2106 of the MPEP (hereinafter, MPEP 2106).
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is noted that the systems, the method, and the non-transitory computer-readable storage medium are directed to an eligible categories of subject matter. Step 1 is satisfied.
With respect to Step 2A prong 1 of MPEP 2106, it is next noted that the claims recite an abstract idea by reciting concepts of transmitting metrics is managing interactions between people, which falls into the “certain methods of organizing human activity” group within the enumerated groupings of abstract ideas set forth in the MPEP 2106. The claimed invention also recites an abstract idea that falls within the mental processes grouping, as independent claims recite determining of thresholds. The limitations reciting the abstract idea in independent claims are capturing driving behavior data while a vehicle is operated by a driver to traverse a route, determining a safe driving threshold based on: dynamic contextual attributes of the route, and historical driving behaviors exhibited, while traversing the route, by a second driver distinct from the first driver, the historical driving behaviors represented by sensor data, determining that a parameter represented in the driving behavior data meets or exceeds the safe driving threshold, based on determining that the parameter meets or exceeds the safe driving threshold, generating an executable instruction; and transmitting the executable instruction to an infrastructure component, the executable instruction causing modification of an operational behavior of the infrastructure component.
With respect to Step 2A Prong Two of the MPEP 2106, the judicial exception is not integrated into a practical application. The additional elements in all claims are directed to processors, memory, sensors, mobile electronic device, computer-implementation, and non-transitory computer-readable storage medium, to implement the abstract idea. However, these elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment. Furthermore, these elements have been fully considered, however they are directed to the use of generic computing elements to perform the abstract idea, which is not sufficient to amount to a practical application (as noted in the MPEP 2106) and is tantamount to simply saying “apply it” using a general purpose computer, which merely serves to tie the abstract idea to a particular technological environment by using the computer as a tool to perform the abstract idea, which is not sufficient to amount to particular application.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. The additional limitations are directed to: processors, memory, sensors, mobile electronic device, computer-implementation, and non-transitory computer-readable storage medium. These elements have been considered, but merely serve to tie the invention to a particular operating environment, though at a very high level of generality and without imposing meaningful limitation on the scope of the claim. This does not amount to significantly more than the abstract idea, and it is not enough to transform an abstract idea into eligible subject matter. Such generic, high-level, and nominal involvement of a computer or computer-based elements for carrying out the invention merely serves to tie the abstract idea to a particular technological environment, which is not enough to render the claims patent-eligible, as noted at pg. 74624 of Federal Register/Vol. 79, No. 241, citing Alice, which in turn cites Mayo.
In addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrates the abstract idea into a practical application. Their collective functions merely provide conventional computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that the ordered combination amounts to significantly more than the abstract idea itself.
The dependent claims have been fully considered as well, however, similar to the finding for claims above, these claims are similarly directed to the abstract idea of concepts of defining infrastructure components, defining sensor locations, and determining a predetermined driving threshold, by way of examples, without integrating it into a practical application and with, at most, a general purpose computer that serves to tie the idea to a particular technological environment, which does not add significantly more to the claims. The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to significantly more than the abstract idea.
This rejection could be withdrawn by incorporating the limitation of claim 5 along with any intervening claim language in claim 1 into all independent claims.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1 – 4 and 6 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. P.G. Pub. 2014/0162219 (hereinafter, Stankoulov) in view of U.S. P.G. Pub. 2017/0313332 (hereinafter, Paget).
Regarding claim 1, Stankoulov teaches a computing system for determining driver performance, the computing system comprising:
a processor; and memory in communication with the processor, the memory storing instructions that, when executed by the processor, cause the processor to perform operations comprising (¶ 168, “The processor 2110 may, in order to execute the processes of some embodiments, retrieve instructions to execute and data to process from components such as system memory 2115, ROM 2120, and permanent storage device 2140. Such instructions and data may be passed over bus 2105.”):
causing a sensor to capture driving behavior data while a vehicle is operated by a first driver to traverse a route (¶ 8, “receiving a set of measured parameters from a set of sensors associated with the vehicle”) (¶ 38, “The set of vehicle sensors 120 may include GNSS sensors (such as global positioning system (GPS), global navigation satellite systems (GLONASS), Galileo, etc.), inertial sensors (i.e., gyroscopes, accelerometers, etc.), wheel speed sensors, differential speed sensors, radar sensors, outside temperature sensors, laser sensors, camera sensors, and/or any other appropriate sensors. The sensors may provide information related to the vehicle, such as speed, odometer readings, revolutions per minute (RPMs), pedal position (e.g., gas, brake, clutch, etc.), turn signal indications, fuel level, battery charge level, gear position, etc. The sensors may be adapted to communicate with the driver behavior engine 130 in various appropriate ways (e.g., using a serial bus such as a controller area network (CAN) bus, using wireless communication links, etc.).”) (Examiner note: GPS data demonstrates vehicle is traversing a route);
determining a safe driving threshold based on: dynamic contextual attributes of the route, and historical driving behaviors exhibited, while traversing the route, by a second driver distinct from the first driver, the historical driving behaviors represented by sensor data (¶ 52, “The positioning engine 225 may be adapted to receive information from the vehicle sensors 120 and the map data access module 220. The positioning engine 225 may process the received information to determine a position of the vehicle. The positioning engine 225 may be adapted to send such determined position information to the driver behavior engine 205, and/or the path prediction engine 230. The positioning engine 225 may include various software modules that are responsible for receiving vehicle positioning sensor information such as GPS, inertial sensors, etc. and matching the received information to a position on a road segment from the map database 215. The positioning engine 225 may return a set of map segments, each with an associated probability. The positioning engine may be used to identify map segments associated with the vehicle travel path and construct a vehicle map path based at least partly on the identified map segments.”) (¶ 84, “FIG. 5 illustrates an x-y plot 500 with example performance evaluation curves according to some embodiments of the invention. Specifically, this figure shows a set of reference curves that may be used to evaluate performance of a driver related to a specific sensed parameter. Such reference curves may be based on various factors such as posted, derived, average, or recommended speed attributes retrieved from a map database, vehicle characteristics, road curvature, intersections, traffic lights, and stop signs, weather conditions, slope, position of the accelerator control, and/or other appropriate factors.”) (¶ 150, “The actual acceleration curve 1710 may be determined using various appropriate vehicle sensors. The optimal static acceleration curve 1720 and safe static acceleration curve 1730 may be determined based on vehicle characteristics (e.g., vehicle weight, size, etc.), weather conditions (which may be determined by temperature sensors, a barometric pressure sensor, windshield wiper data, head-light data, etc.), and/or position of the accelerator pedal (which may be determined by OBD-II, for example). The optimal static acceleration curve 1720 and safe static acceleration curve 1730 may also be determined based on known points of acceleration/deceleration, and predicted future possible points.”);
determining that a parameter represented in the driving behavior data meets or exceeds the safe driving threshold (¶¶ 75-77, “Each driver profile data element 410 may include, for example, a driver profile ID, driver scores, trip attributes, and/or other sub-elements. Driver scores (or drive style factors) may include, for instance, various scores for different observable driving characteristics. For example, a driver may have different scores for braking, acceleration, safe turning, fuel efficient driving, etc. Trip attributes may include, for instance, such information as load weight, type of load (e.g., passengers, cargo, hazardous materials, etc.), and/or vehicle configuration (e.g., number/size of wheels, whether trailers are present, etc.). Each rule data element 420 may include a rule ID, rule attributes, and/or other sub-elements, as appropriate. A rule may include various specific elements depending on the type of rule being implemented and any attributes that may be associated with the rule. A rule may be used to identify one or more driving events (and/or other appropriate performance criteria). For instance, in some embodiments a rule may include a threshold (which may be defined as a curve) and the rule may identify an event whenever sensed data (e.g., driving speed) exceeds the threshold. As another example, in some embodiments a rule may include multiple thresholds. Such a rule may include a first threshold (which may be defined as a curve) and a second threshold (which may be defined as an area or a length of time). When the first threshold is exceeded, the rule may identify a potential event, where the potential event may not be classified as an event until the second threshold is exceeded (e.g., when an amount of time exceeding the threshold has passed, when an area defined between a set of curves exceeds a threshold value, etc.). Each map data element 430 may include link (or "segment") data (i.e., a stretch of road between two intersections where the link attributes remain the same), and/or node data (i.e., a connection point between road links). Link data may include, for instance, a link ID, link attributes (e.g., functional class, road type, posted speed limit, speed category, link length, etc.), link travel direction, link shape, from-node ID (i.e., identifier of a node at the beginning of the link), to-node ID (i.e., identifier of the node at the end of the link), driving restriction data (e.g., physical, logical, time restricted, etc.), and/or other sub-elements. Node data may include, for instance, a node ID, a set of connect-link IDs, and/or other sub-elements. Using this structure, node and link entities may be used to define a connected graph of a road network.”);
based on determining that the parameter meets or exceeds the safe driving threshold, generating an executable instruction (¶¶ 148-151, “FIG. 17 illustrates an x-y plot 1700 with example static acceleration curves according to some embodiments of the invention. Specifically, this figure shows a set of curves that may be used to evaluate performance of a driver related to sensed static acceleration. As shown, the x-y plot may include an actual acceleration curve 1710, an optimal static acceleration curve 1720, a safe static acceleration curve 1730, and a sudden static acceleration violation zone 1740. In real-time driving systems, the exact location of acceleration/deceleration may be difficult to ascertain, and therefore, respective behavior curves may be difficult to generate. Instead, static acceleration curves may be used to provide real-time warnings and/or driving guidance. The actual acceleration curve 1710 may be determined using various appropriate vehicle sensors. The optimal static acceleration curve 1720 and safe static acceleration curve 1730 may be determined based on vehicle characteristics (e.g., vehicle weight, size, etc.), weather conditions (which may be determined by temperature sensors, a barometric pressure sensor, windshield wiper data, head-light data, etc.), and/or position of the accelerator pedal (which may be determined by OBD-II, for example). The optimal static acceleration curve 1720 and safe static acceleration curve 1730 may also be determined based on known points of acceleration/deceleration, and predicted future possible points. The sudden static acceleration violation zone 1740 may indicate a region of unsafe static acceleration. A sudden static acceleration violation 1740 occurs when actual static acceleration (as represented by curve 1710) exceeds the safe static acceleration (as represented by curve 1730)”).
Stankoulov does not disclose modifying operational behavior of the infrastructure component, but in the analogous art of vehicle operation sensing, Paget teaches transmitting the executable instruction to an additional processor associated with an infrastructure component, the executable instruction causing the additional processor to modify an operational behavior of the infrastructure component (¶ 284, “This control signal can help in preventing the vehicle heading toward the hazard from reaching the hazard, such as by changing a color or other state of a signal (e.g., changing from a green light to a red light), by lowering a gate (e.g., to prevent passage of the vehicle on a route toward the hazard), by changing which routes are connected by a switch (e.g., to cause the vehicle to move onto another route that does not include the hazard), etc.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine vehicle performance operation of Stankoulov with altering operations of infrastructure that interacts with a vehicle of Paget. This combination would have yielded a predictable result because both use sensors to monitor and send instructions for altering behavior. Paget changes the location of the sensors with similar end result of changed user behavior.
Regarding claim 2, Stankoulov and Paget teach the computing system of claim 1. Paget teaches wherein the infrastructure component comprises one or more of a traffic signal, a street sign, a notification sign, a roadside display, or a billboard display (¶ 284, “This control signal can help in preventing the vehicle heading toward the hazard from reaching the hazard, such as by changing a color or other state of a signal (e.g., changing from a green light to a red light), by lowering a gate (e.g., to prevent passage of the vehicle on a route toward the hazard), by changing which routes are connected by a switch (e.g., to cause the vehicle to move onto another route that does not include the hazard), etc.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine vehicle performance operation of Stankoulov with altering operations of infrastructure that interacts with a vehicle of Paget. This combination would have yielded a predictable result because both use sensors to monitor and send instructions for altering behavior. Paget changes the location of the sensors with similar end result of changed user behavior.
Regarding claim 3, Stankoulov and Paget teach the computing system of claim 1. Stankoulov teaches wherein the sensor is fixedly attached to the vehicle, or comprises a component of a mobile electronic device disposed in the vehicle (¶ 38, “The set of vehicle sensors 120 may include GNSS sensors (such as global positioning system (GPS), global navigation satellite systems (GLONASS), Galileo, etc.), inertial sensors (i.e., gyroscopes, accelerometers, etc.), wheel speed sensors, differential speed sensors, radar sensors, outside temperature sensors, laser sensors, camera sensors, and/or any other appropriate sensors. The sensors may provide information related to the vehicle, such as speed, odometer readings, revolutions per minute (RPMs), pedal position (e.g., gas, brake, clutch, etc.), turn signal indications, fuel level, battery charge level, gear position, etc.”).
Regarding claim 4, Stankoulov and Paget teach the computing system of claim 1. Stankoulov teaches wherein the operations further comprise:
determining that the safe driving threshold differs from a predetermined driving threshold, the predetermined driving threshold corresponding to the route (¶¶ 86-88, “The optimum curve 510 may represent an optimum level for various sensed parameters (e.g., speed, acceleration, braking, yaw rate, fuel efficiency, etc.). For instance, such an optimal curve may represent the speed at which fuel efficiency is maximized. The speed limit curve 520 may represent the actual speed limit for a driving path. The warning level curve 530 may represent a warning level for various sensed parameters. For instance, the warning level curve may indicate various unsafe levels of speed, acceleration, braking, yaw rate, etc. The warning level curve may indicate a bottom level of various unsafe driving behaviors. The critical warning level curve 540 may represent a critical warning level for various sensed driving parameters. The critical warning level curve may indicate an upper level of various unsafe driving behaviors. For instance, the critical warning level curve may indicate a level of various sensed driving parameters at which a driver may lose control of a vehicle, fail to keep a vehicle in its current lane, fail to maintain a safe stopping distance between other vehicles, fail to maintain a safe turning speed, etc. During operation, an actual behavior (driving) curve (not shown) may be generated (e.g., based on a measured parameter of the vehicle) and compared to one or more of the evaluation curves 510-540. Such comparison may result in identification and quantifications of various differences among the curves.”); and
generating the executable instruction is further based on determining that the safe driving threshold differs from the predetermined driving threshold (¶ 45, “The driver behavior engine 130 may continuously retrieve information related to the measured and/or predicted path(s) of the vehicle. Such information may be passed directly to the storage 140 and/or analyzed in various ways (e.g., by comparing such measured information to various thresholds to determine whether a warning should be issued). Such warnings and/or other feedback may be provided to an optional user interface 150. ”) (¶ 54, “The warning module 235 may be adapted to receive information from the driver behavior engine 205 and/or communicate with the user interface module 240. The warning module 235 may provide real-time warnings and/or guidance to drivers. The warning module may, for example, display information on a vehicle display, head-unit, instrument cluster, dashboard, and/or any other appropriate location. The warning module may be adapted to emit sounds and/or voice commands/warnings. The warning module may be adapted to provide other warning methods such as seat and/or steering wheel vibration, colored and/or flashing lights, written messages, and/or any other appropriate warning method. Such warnings may be based on various appropriate factors.”).
Regarding claim 6, Stankoulov and Paget teach the computing system of claim 1. Paget teaches wherein the sensor is fixedly disposed in an environment along the route (¶ 14, “For both in-vehicle and wayside sensor package systems, the sensor package systems may be fixed in place, to capture video data only of a designated field of view, e.g., to the front or rear of a vehicle, or a designated segment of road.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine vehicle performance operation of Stankoulov with altering operations of infrastructure that interacts with a vehicle of Paget. This combination would have yielded a predictable result because both use sensors to monitor and send instructions for altering behavior. Paget changes the location of the sensors with similar end result of changed user behavior.
Regarding claim 7, Stankoulov and Paget teach the computing system of claim 1. Paget teaches wherein the vehicle comprises a first vehicle, and the operations further comprise supplementing the driving behavior data based on data captured by a second vehicle sensor disposed at a second vehicle in an environment along the route (¶ 181, “If the vehicle system is one of a plurality of like vehicle systems, and the mobile route inspection unit includes an inspection system mounted on another, second vehicle system of the plurality of vehicle systems operating over the segment of the route prior to the first vehicle system then the system can use data for a route segment even if it was inspected by a different vehicle system's equipment.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine vehicle performance operation of Stankoulov with altering operations of infrastructure that interacts with a vehicle of Paget. This combination would have yielded a predictable result because both use sensors to monitor and send instructions for altering behavior. Paget changes the location of the sensors with similar end result of changed user behavior.
Regarding claims 8, 14, and 20, the claims recite substantially similar limitations to claim 1. Therefore, claims 8, 14, and 20 are similarly rejected for the reasons set forth above with respect to claim 1.
Regarding claim 9, Stankoulov and Paget teach computer-implemented method of claim 8. Stankoulov teaches wherein the sensor is configured at the vehicle and comprises at least one of a camera, an optical sensor, a speed sensor, a weight sensor, a noise sensor, a heat sensor, an accelerometer, a force sensor, a location tracking sensor, a proximity sensor, a seat belt sensor, or a sensor to detect an operation of an instrument included in the vehicle (¶ 38, “The set of vehicle sensors 120 may include GNSS sensors (such as global positioning system (GPS), global navigation satellite systems (GLONASS), Galileo, etc.), inertial sensors (i.e., gyroscopes, accelerometers, etc.), wheel speed sensors, differential speed sensors, radar sensors, outside temperature sensors, laser sensors, camera sensors, and/or any other appropriate sensors. The sensors may provide information related to the vehicle, such as speed, odometer readings, revolutions per minute (RPMs), pedal position (e.g., gas, brake, clutch, etc.), turn signal indications, fuel level, battery charge level, gear position, etc. The sensors may be adapted to communicate with the driver behavior engine 130 in various appropriate ways (e.g., using a serial bus such as a controller area network (CAN) bus, using wireless communication links, etc.). Although the sensors 120 are represented as physical elements with direct communication pathways to the driver behavior engine 130, one of ordinary skill in the art will recognize that systems of some embodiments may receive data associated with one or more sensors over an existing bus or other communication interface (and/or through one or more processing modules) without communicating directly with any, some, or all of the sensors.”).
Regarding claim 10, the claim recites substantially similar limitations to claim 6. Therefore, claim 10 is similarly rejected for the reasons set forth above with respect to claim 6.
Regarding claims 11 and 16 – 18, the claims recite substantially similar limitations to claim 4. Therefore, claims 11 and 16 – 18 are similarly rejected for the reasons set forth above with respect to claim 4.
Regarding claims 12 and 19, the claims recite substantially similar limitations to claim 2. Therefore, claims 12 and 19 are similarly rejected for the reasons set forth above with respect to claim 2.
Regarding claim 13, Stankoulov and Paget teaches the computer-implemented method of claim 8. Paget teaches wherein the infrastructure component comprises one or more of a gate, a switch, or a crossing (¶ 18, “The one or more processors also can generate another control signal (or use the same control signal) and communicate the control signal to a component of the transportation network, such as a signal, gate, switch, etc. This control signal can help in preventing the vehicle heading toward the hazard from reaching the hazard, such as by changing a color or other state of a signal (e.g., changing from a green light to a red light), by lowering a gate (e.g., to prevent passage of the vehicle on a route toward the hazard), by changing which routes are connected by a switch (e.g., to cause the vehicle to move onto another route that does not include the hazard), etc.”)
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine vehicle performance operation of Stankoulov with altering operations of infrastructure that interacts with a vehicle of Paget. This combination would have yielded a predictable result because both use sensors to monitor and send instructions for altering behavior. Paget changes the location of the sensors with similar end result of changed user behavior.
Regarding claim 15, the claim recites substantially similar limitations to claim 7. Therefore, claim 15 is similarly rejected for the reasons set forth above with respect to claim 7.
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Stankoulov in view of Paget in view of U.S. P.G. Pub. 2017/0008521 (hereinafter, Braunstein).
Regarding claim 5, Stankoulov and Paget teach the computing system of claim 1. Neither teaches controlling the vehicle. However, in the analogous art of autonomous vehicle control, Braunstein teaches wherein the operations further comprise: generating an autonomous control instruction based on determining that the parameter meets or exceeds the safe driving threshold; and controlling the vehicle based on the autonomous control instruction (¶¶ 333-335, “FIG. 5A is a flowchart showing an exemplary process 500A for causing one or more navigational responses based on monocular image analysis, consistent with disclosed embodiments. At step 510, processing unit 110 may receive a plurality of images via data interface 128 between processing unit 110 and image acquisition unit 120. For instance, a camera included in image acquisition unit 120 (such as image capture device 122 having field of view 202) may capture a plurality of images of an area forward of vehicle 200 (or to the sides or rear of a vehicle, for example) and transmit them over a data connection (e.g., digital, wired, USB, wireless, Bluetooth, etc.) to processing unit 110. Processing unit 110 may execute monocular image analysis module 402 to analyze the plurality of images at step 520, as described in further detail in connection with FIGS. 5B-5D below. By performing the analysis, processing unit 110 may detect a set of features within the set of images, such as lane markings, vehicles, pedestrians, road signs, highway exit ramps, traffic lights, and the like. Processing unit 110 may also execute monocular image analysis module 402 to detect various road hazards at step 520, such as, for example, parts of a truck tire, fallen road signs, loose cargo, small animals, and the like. Road hazards may vary in structure, shape, size, and color, which may make detection of such hazards more challenging. In some embodiments, processing unit 110 may execute monocular image analysis module 402 to perform multi-frame analysis on the plurality of images to detect road hazards. For example, processing unit 110 may estimate camera motion between consecutive image frames and calculate the disparities in pixels between the frames to construct a 3D-map of the road. Processing unit 110 may then use the 3D-map to detect the road surface, as well as hazards existing above the road surface. At step 530, processing unit 110 may execute navigational response module 408 to cause one or more navigational responses in vehicle 200 based on the analysis performed at step 520 and the techniques as described above in connection with FIG. 4. Navigational responses may include, for example, a turn, a lane shift, a change in acceleration, and the like. In some embodiments, processing unit 110 may use data derived from execution of velocity and acceleration module 406 to cause the one or more navigational responses. Additionally, multiple navigational responses may occur simultaneously, in sequence, or any combination thereof. For instance, processing unit 110 may cause vehicle 200 to shift one lane over and then accelerate by, for example, sequentially transmitting control signals to steering system 240 and throttling system 220 of vehicle 200. Alternatively, processing unit 110 may cause vehicle 200 to brake while at the same time shifting lanes by, for example, simultaneously transmitting control signals to braking system 230 and steering system 240 of vehicle 200.”) (¶ 967, “The server side may analyze the received information (e.g., using automated image analysis processes) to determine whether any updates to sparse data model 800 are warranted based on whether or not the adjustment was due to a transient condition. Where the adjustment was not due to the existence of a transient condition, the road model may be updated. For example, where an experienced condition is determined to be one likely to persist beyond a predetermined time threshold (e.g., a few hours, a day, or a week or more) updates may be made to the model. In some embodiments, the threshold for determining a transient condition may be dependent on a geographic region in which the condition is determined to occur, on an average number of vehicles that travel the road segment in which the condition was encountered, or any other suitable criteria.”) (¶ 970 , “For example, the server may be trained to recognized in an image or image stream the presence of a concrete barrier (possibly indicating the presence of a non-transient construction or lane separation condition), a pothole in the surface of the road (a possible transient or non-transient condition depending on the size, depth, etc.), a road edge intersecting with an expected path of travel (potentially indicating a non-transient lane shift or new traffic pattern), a parked car (a potentially transient condition), an animal shape in the road (a potentially transient condition), or any other relevant shapes, objects, or road features.”) (¶ 972, “The server-based system may also be configured to take into account other information when determining whether an experienced road condition is transient. For example, the server may determine an average number of vehicles that travel a road segment over a particular amount of time. Such information may be helpful in determining the number of vehicles a temporary condition is likely to affect over an amount of time that the condition is expected to persist. Higher numbers of vehicles impacted by the condition may suggest a determination that the sparse data model 800 should be updated.”).
It would have been obvious to one having ordinary skill in the art prior to the effective filing date to combine the determination of a level of driving performance of Stankoulov with the ability to use driver behavior to intervene and control a vehicle while a driver is otherwise in control of a vehicle of Braunstein. One of ordinary skill in the art would have been motivated to combine these teachings for the benefit of utilizing technology to react more quickly than a human’s reaction time to safely navigate an operate certain vehicle controls. It would prevent collisions by utilizing the information of what the driver is doing to assist the driver in a manner that could help save people and property from damage.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANDA GURSKI whose telephone number is (571)270-5961. The examiner can normally be reached Monday to Thursday 7am to 5pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Brian Epstein can be reached at 571-270-5389. 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.
/AMANDA GURSKI/Primary Examiner, Art Unit 3625