DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claims 1-3,5-10,12-17 and 19-23 are presented for examination.
Claims 1-3,5-10,12-17 and 19-23 are rejected.
Claim Objections
Claim 1 is objected to because of the following informalities: The amended claim recites “the inverse controller converts”. It seems that it was misspelled and should have been “the inversion controller”. Appropriate correction is required.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-3, 5-6, 8-10, 12-13, and 15-17, and 19-23 are have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant's arguments filed on 02/06/2026 have been fully considered but they are not persuasive.
Applicant remarks regarding the rejection of claims 21-23 under 35 U.S.C. § 103, Applicant states that “the Office does not list these claims as being rejected in the header” but “appears to allege that these claims are rejected.” (Remarks 8). Applicant continues that “ Applicant respectfully requests that the claims be allowed or a prima facie rejection be set forth” and “since these claims have not been rejected, Application does not believe the next action can be properly made final.” (Remarks 8). The examiner disagrees.
Applicant’s attention is directed to the Non-Final Rejection dated November 7, 2026 at pages 14-19. As can clearly be seen, a “prima facie rejection” for claims 21-23 were set forth. Thus, Applicant had sufficient notice of the rejection of these claims particularly in light of the statement at page 2 of the same action that indicates “Claims 1-3,5-10,12-16 and 19-23 are rejected.” In view of these facts, the examiner’s omission of claims 21-23 at page 4 is a clear typographical error that does not affect the finality of this action. Therefore, Applicant’s argument is unpersuasive.
Applicant’s arguments regarding claims 7 and 14 have been fully considered but are not persuasive. Applicant argues that the Office has not shown how Gupta cures the alleged defects of the primary reference and therefore a prima facie case has not been established. The Examiner disagrees.
As set forth in the Office Action, the feature relied upon from Gupta is narrow and specific, obtaining cruise control parameters from a lookup table. Gupta explicitly teaches implementing following-gap control using a table structure, i.e., a lookup table, Gupta [0076] discloses that “the vehicle 502 may be automatically controlled to follow vehicle 504 at a following gap determined according to an initial control strategy, such as that provided by a speed-gap table.” A “speed-gap table” is a lookup table that stores predetermined control parameter values (gap/headway) indexed by speed or operating state, and the controller obtains the cruise control parameter by retrieving it from the table. The primary reference (as applied in the Office Action) teaches an ACC/cruise control system that obtains and uses cruise-control-type parameters (e.g., speed/following behavior settings) to control vehicle following and acceleration. Gupta is not relied upon for the entire claim; Gupta is applied only for the missing implementation detail storing and retrieving such parameters via a lookup table. Thus, Gupta directly cures the deficiency identified in the Office Action. It would have been obvious to one of ordinary skill in the art to implement the primary reference’s cruise control parameters in the well-known lookup-table form taught by Gupta (e.g., speed–gap table), because table lookup is a routine and predictable design choice to reduce computation and to store control strategies efficiently, consistent with Gupta [0080] describing storage efficiency advantages of structured data. Accordingly, Gupta supplies the expressly recited “lookup table” limitation, and the combination establishes a proper prima facie case of obviousness for claims 7 and 14.
Therefore, the rejection is maintained.
Claim Rejections - 35 USC § 103
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-2, 5-6, 8-9, 12-13, and 15-16, and 19-23 are rejected under § 103 as being unpatentable over Niwa (US 20110066344 A1), in view of Sivaraman (US 9272711 B1).
Regarding Claim 1, Niwa discloses a method, comprising:
receiving, by an inversion controller of a vehicle, a desired acceleration [0041] “control requests inputted to the vehicle motion control platform 10, to obtain a single acceleration control request. This can express a requested value of acceleration” [0062] “The acceleration control request arbitration section 41 receives acceleration control requests and selects one. The requested acceleration value expressed by the selected acceleration control request is inputted to the acceleration control request conversion section 42.” Niwa teaches the intermediate controller receiving/handling a requested acceleration (i.e., “desired acceleration”) in the longitudinal control platform.,
wherein the inversion controller includes a model of operations of a cruise control module of the vehicle [0040] “Speed control requests are generated by a CC (Cruise Control) apparatus 54” [0075] “the functions of the vehicle motion control platform 10 are implemented by an ECU implemented as modules of a program” [0054]–[0060] Niwa discloses the conversion logic (FF/FB, reference model, limitation controller) that converts control requests into acceleration control requests. Accordingly, the inversion controller’s conversion sections implement an operational model of cruise control behavior (i.e., cruise control request processing and conversion).;
obtaining, by the inversion controller, cruise control parameters based on the desired acceleration by applying a mapping from acceleration commands to cruise control parameters, wherein the inverse controller converts the acceleration commands into the cruise control parameters; [0041] “Respective control requests outputted from the control request apparatuses 51 to 55 are inputted to the vehicle motion control platform 10, to obtain a single acceleration control request. This can express a positive or negative (i.e., deceleration) requested value of acceleration, and is converted to a torque control request by an acceleration control request conversion section 42 as described hereinafter. The torque control request expresses a requested value of torque (specifically, value of drive torque or braking torque that is to be applied to wheel axles of the vehicle), and is inputted to a drive control apparatus 61 which controls motive power for driving the vehicle and to a braking control apparatus 62 of the vehicle. The requested torque value expressed by a torque control request corresponds to a value of an acceleration control quantity, as recited in the appended claims.” See also [0016] “The control request apparatus derives from these a single acceleration request, which is converted to a motion control request, e.g., a torque control request expressing a requested value of wheel axle torque. This is supplied to an acceleration control apparatus of the vehicle (e.g., combination of drive control apparatus and braking control apparatus).” Further, “convert acceleration commands into cruise control parameters” is satisfied because the claimed “cruise control parameters” are speed/gap type parameters and the torque control values used by the cruise control systems. Niwa describes speed and allowable ranges as part of speed control requests and position control requests (ACC position control includes allowable speed range; speed control includes allowable acceleration range), i.e., “parameters” used by cruise control logic [0044] “Each speed control request expresses a requested value of speed and also expresses maximum and minimum allowable acceleration values” [0045] “Each position control request outputted from the ACC apparatus expresses a requested position and also maximum and minimum allowable vehicle speed values” Thus, Niwa teaches that the intermediate control platform converts between command dimensions and produces the parameterized control requests used by cruise control modules (speed requests, allowable ranges, and the torque control values).
and outputting, by the inversion controller and to the cruise control module, the cruise control parameter, wherein the cruise control module is configured to maintain the cruise control parameter for the vehicle [0041] “obtain a single acceleration control request converted to a torque control request supplied to drive control apparatus and braking control apparatus for controlling the vehicle” [0064] “converts to an axle drive torque request or axle braking torque request” Niwa teaches outputting the control quantities that are maintained/applied by the vehicle control system.
Niwa does not teach the full limitation regarding “communicating a congestion cruise control parameter from a congestion controller to the cruise control module regarding traffic congestion so that the cruise control module changes the cruise control parameter based upon the congestion cruise control parameter”
However, Sivaraman teaches equivalent teachings wherein communicating a congestion cruise control parameter from a congestion controller to the cruise control module regarding traffic congestion so that the cruise control module changes the cruise control parameter based upon the congestion cruise control parameter [Col.9, line 1-17] “Turning to FIG. 6, a process is shown for determining and activating a congestion status for triggering congestion-based ACC in an illustrative embodiment. The process begins at block 602 where processor 107 obtains and processes vehicle data, which includes vehicle use characteristics such as acceleration, speed, average speed, braking, braking frequency etc. Next in block 604, the navigation unit obtains and processes navigational system data, which includes any of the traffic data discussed above. Processor 107 then determines in block 606 if navigation data indicates congestion in an area traveled by vehicle 101. If, in determination block 606, it is determined that congestion exists (“YES”), the process moves to block 610, where congestion-based ACC is activated in vehicle 101. If, in determination block 606, it is determined that congestion is not detected (“NO”), the process moves to decision block 608, where it is determined if the vehicle data is consistent with the navigational system data.” [Col.9 line 31-36] “If one or more vehicle characteristics meet or exceed threshold congestion requirements and show an inconsistency with the navigational data (“NO”), this indicates potentially forming/formed congestion, and the process continues to block 610 where a congestion status is activated for the vehicle 101.” [Col.6 line 10-17] “In each of embodiments, 4A-4C, reference is made to a front vehicle 402, a rear vehicle 404 and a target vehicle 101 in which congestion mode ACC is affected. Front vehicle 402 is shown as traveling at a velocity (speed) of v.sub.f and having a distance d.sub.f from target vehicle 101. Rear vehicle 404 is shown as having a velocity of v.sub.r and having a distance d.sub.r from target vehicle 101. Target vehicle 101 is shown as traveling with a velocity of v.sub.tar.” [Col.9 line 66-Col.10 line6] “Once the speed and distance of a front and read vehicle are determined, vehicle 101 calculates an optimum congestive distance (discussed above, in connection with FIGS. 3 and 4A-4C) in block 708 between the vehicles. In block 710, vehicle processor 107 initiates one or more actions for vehicle modules (e.g., acceleration, deceleration, braking, etc.) to affect the optimum distance position for vehicle 101.” [Col.5 line 24-26] “Vehicle traffic sensor arrangement 300 is configured to operate as an ACC system by monitoring and regulating the distance of vehicle 101 to front and rear vehicles to make driving easier for drivers, particularly in congested (“stop-and-go”) traffic.” Sivaraman discloses a congestion-based ACC system wherein a processor 107 and navigation unit 501 determine when traffic congestion exists and activate a congestion status, (i.e., a congestion controller output) and in response, adjust the ACC behavior to maintain an optimized congestive distance (mid-point) between a front and a rear vehicle. This shows a congestion controller that communicates congestion-dependent parameters (e.g., congestion status and optimized distance/velocity) to the ACC logic so that the ACC changes its control behavior based on congestion.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Sivaraman’s congestion-based ACC configuration into Niwa’s motion control platform and cruise control request processing, so that Niwa’s cruise control parameters and control requests are adjusted/selected based on congestion status and congestion-dependent control objectives.
A person that is skilled in the art would have been motivated to combine Niwa and Sivaraman to improve traffic performance and safety in congested conditions [Col.1 line 6-11] “The present disclosure is directed to technologies and techniques for automatically controlling a vehicle. More specifically, the present disclosure is directed to positioning a vehicle between other vehicles and in turn distributing vehicle traffic and improving overall traffic performance and safety.”
Regarding Claim 2, The combination of Niwa with Sivaraman teaches the method of claim 1, Niwa discloses wherein obtaining the cruise control parameter is further based on a speed of the vehicle, …, and a distance between vehicle and the leading vehicle [0010] “ACC automatically controls the vehicle position, or distance from a preceding vehicle (control of position).” [0040] “position control requests are generated by an ACC apparatus 51” [0054]–[0055] “converts based on difference between requested position and actual vehicle position requested speed value” [0059] “converts based upon the difference between the requested speed and the actual current speed. A requested acceleration value is thereby obtained” [0133] “it will be understood that the vehicle position information may consist of relative position information, i.e., expressing a separation distance of the host vehicle from a preceding vehicle (i.e., a distance between vehicle and the leading vehicle).” Thus, Niwa teaches use of speed and distance/position in the conversion logic that produces acceleration commands. Additionally, Niwa’s architecture is explicitly an intermediate motion control platform converting requests between levels/dimensions.
and wherein the inversion controller is an intermediate control module that converts the acceleration commands from a high-level controller into the cruise control parameters for the cruise control module [0040] “Speed control requests are generated by a CC (Cruise Control) apparatus 54” and “position control requests are generated by an ACC 51” [0041] “Respective control requests are inputted to the vehicle motion control platform 10, to obtain a single acceleration control request and is converted to a torque control request supplied to drive control apparatus 61 and braking control apparatus 62” [0075] “the functions of the vehicle motion control platform 10 are implemented by an ECU the position control platform 20, the speed control platform 30 and the acceleration control platform 40 implemented as modules” Niwa teaches a vehicle motion control platform 10 (i.e., intermediate control module) by structure and function since it receives high-level control (i.e., a high-level controller “drive control apparatus 61”) requests and outputs requests used to control the vehicle. Thus, Niwa teaches that the intermediate control platform converts between command dimensions and produces the parameterized control requests used by cruise control modules (speed requests, allowable ranges, and the torque control values).
Niwa does not appear to teach the full claim limitation regarding the consideration of “a speed of a leading vehicle”
However, Sivaraman teaches equivalent teachings wherein consideration of a speed of a leading vehicle (Col. 6, ll. 8-67) “reference is made to a front vehicle 402, a rear vehicle 404 and a target vehicle 101 in which congestion mode ACC is affected. Front vehicle 402 is shown as traveling at a velocity (speed) of v.sub.f and having a distance d.sub.f from target vehicle 101. Rear vehicle 404 is shown as having a velocity of v.sub.r and having a distance d.sub.r from target vehicle 101. Target vehicle 101 is shown as traveling with a velocity of v.sub.tar.[] If a congestion mode is detected in vehicle 101 (discussed in greater detail below), target vehicle 101 begins adjusting its velocity using ACC to optimize target vehicle 101 position to be substantially at a mid-point between front vehicle 402 and rear vehicle 404.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Sivaraman’s congestion detection/configuration into Niwa while using vehicle speed and positional spacing (distance to a lead vehicle), as both references are directed to longitudinal control using speed/distance sensing and converting these objectives into acceleration/braking control.
A person that is skilled in the art would have been motivated to combine Niwa and Sivaraman to improve traffic performance and safety in congested conditions [Col.1 line 6-11] “The present disclosure is directed to technologies and techniques for automatically controlling a vehicle. More specifically, the present disclosure is directed to positioning a vehicle between other vehicles and in turn distributing vehicle traffic and improving overall traffic performance and safety.”
Regarding Claim 5, The combination of Niwa with Sivaraman teaches the method of claim 1, Niwa discloses wherein obtaining, by the inversion controller, the cruise control parameter based on the desired acceleration comprises:
obtaining respective computed vehicle acceleration commands for at least two cruise control parameters; and selecting, as the cruise control parameter, the one of the at least two cruise control parameters corresponding to minimum difference between the respective computed vehicle acceleration commands and the desired acceleration [0019] “position control request arbitration section selects one out of a plurality” [0021]–[0022] “speed control request arbitration section obtains a single speed control request from a plurality” [0030] “each of the position control request arbitration section, the speed control request arbitration section and the acceleration control request arbitration section is preferably configured to detect a condition whereby a difference between a currently requested control value (expressed by a currently selected control request) and a requested control value expressed by a precedingly derived selected control request exceeds a predetermined amount, and to initiate predetermined smoothing processing when the condition is detected.” [0062] “acceleration control request arbitration section derives a single acceleration control request from a plurality” [0049] describes selecting based on accomplishing objective rapidly; the platform chooses among competing requests. This arbitration/selection framework renders it obvious to evaluate multiple candidate parameterized control requests (e.g., speed/gap objectives expressed in control requests) that yield corresponding acceleration outcomes via the conversion sections, and select the one that best matches a desired acceleration objective (minimum deviation), as a matter of routine optimization in layered longitudinal control.
Regarding Claim 6, The combination of Niwa with Sivaraman teaches the method of claim 1, Niwa discloses wherein the cruise control module is an adaptive cruise control module that is configured to maintain a configured headway and a configured speed such that the configured speed is reduced to maintain the configured headway, wherein the cruise control parameter comprises a headway and a speed, and the method further comprising: configuring the cruise control module to use the headway and the speed [0010] “ACC controls distance from a preceding vehicle” [0040] “position control requests are generated by an ACC apparatus 51” [0040] “Speed control requests are generated by an ASL (Automatic Speed Limiting) apparatus 53 and a CC (Cruise Control) apparatus 54. Acceleration control requests are generated by a CA (Collision Avoidance) apparatus 55.” [0044] “Each speed control request outputted by the ASL apparatus 53 or the CC apparatus 54 expresses a requested value of speed at which the vehicle is to run, and also expresses maximum and minimum allowable acceleration values (allowable acceleration range information), where the acceleration values may be positive or negative (i.e., deceleration) values.” [0045] “Each position control request outputted from the ACC apparatus 51 or other position control request apparatus 52 expresses a requested position of the vehicle, and also maximum and minimum allowable vehicle speed values (allowable speed range information.” Niwa teaches ACC headway (distance) control and speed control parameters used in cruise control operation.
Regarding Claim 8, The claim discloses a vehicle and recites the parallel limitations in claim 1, respectively for the reasons discussed above. Therefore, claim 8 is rejected using the same rational reasoning.
Regarding Claim 9, The claim recites the parallel limitations in claim 2, respectively for the reasons discussed above. Therefore, claim 9 is rejected using the same rational reasoning.
Regarding Claim 12, The claim recites the parallel limitations in claim 5, respectively for the reasons discussed above. Therefore, claim 12 is rejected using the same rational reasoning.
Regarding Claim 13, The claim recites the parallel limitations in claim 6, respectively for the reasons discussed above. Therefore, claim 13 is rejected using the same rational reasoning.
Regarding Claim 15, The claim recites a non-transitory computer-readable medium storing instructions and recites the parallel limitations in claim 1, respectively for the reasons discussed above. Therefore, claim 15 is rejected using the same rational reasoning.
Regarding Claim 16, The claim recites a system of the parallel limitations in claim 2, respectively for the reasons discussed above. Therefore, claim 16 is rejected using the same rational reasoning.
Regarding Claim 19, The claim recites a system of the parallel limitations in claim 5, respectively for the reasons discussed above. Therefore, claim 19 is rejected using the same rational reasoning.
Regarding Claim 20, The claim recites a system of the parallel limitations in claim 6, respectively for the reasons discussed above. Therefore, claim 20 is rejected using the same rational reasoning.
Regarding Claim 21, The combination of Niwa with Sivaraman teaches the, Niwa does not teach “further comprising: predicting average velocities and the traffic congestion of a roadway based upon past velocities and past congestion of the roadway”
However, Sivaraman teaches equivalent teachings wherein further comprising: predicting average velocities and the traffic congestion of a roadway based upon past velocities and past congestion of the roadway [Col.4 line 55-60] “Preferably, device 201 registrations are stored at the vehicle (e.g., 108) according to a device ID or SIM ID, and may further include a device user profile associated with each ID that may include vehicle settings, vehicle function preferences, demographic data, and/or user device/vehicle history.” [Col.8 line 54-62] “Traffic data may be delivered using a plurality of data types that can be received about the road network. Two exemplary data types comprise incident data and traffic flow data. Incident data refers to information generally about a specific point/event on a road such as an accident or construction work (i.e., past congestion data). Flow data refers to the average speed vehicles (i.e., past average velocities) are currently traveling on a particular section of road. In one embodiment, navigation system 501 is configured to receive both types of data. This would be advantageous, for example, if a road only has incident coverage, and unexpected bad weather causes traffic to back up. As this scenario may not be detected by incident data (since there technically is not a particular accident-causing slower traffic), dual coverage that includes flow data would detect the back up more efficiently.” [Col.9, line 1-17] “Turning to FIG. 6, a process is shown for determining and activating a congestion status for triggering congestion-based ACC in an illustrative embodiment. The process begins at block 602 where processor 107 obtains and processes vehicle data, which includes vehicle use characteristics such as acceleration, speed, average speed, braking, braking frequency etc. Next in block 604, the navigation unit obtains and processes navigational system data, which includes any of the traffic data discussed above. Processor 107 then determines in block 606 if navigation data indicates congestion in an area traveled by vehicle 101. If, in determination block 606, it is determined that congestion exists (“YES”), the process moves to block 610, where congestion-based ACC is activated in vehicle 101. If, in determination block 606, it is determined that congestion is not detected (“NO”), the process moves to decision block 608, where it is determined if the vehicle data is consistent with the navigational system data.”
A person that is skilled in the art would understand that the system uses past velocities (traffic flow data over segments) and past congestion (incidents and prior ACC congestion activations) to determine that a given roadway segment is congested before or as the vehicle enters it. That shows “predicting average velocities and the traffic congestion of a roadway based upon past velocities and past congestion of the roadway.” A person of ordinary skill in the art would understand that Sivaraman’s traffic flow data (average speeds over road segments) corresponds to past velocities for roadway segments and that incident data corresponds to past congestion events, and that the navigation/processor determines congestion for road segments traveled by the vehicle based on such traffic data. This shows “predicting average velocities and the traffic congestion of a roadway based upon past velocities and past congestion of the roadway.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Sivaraman’s historical traffic flow and congestion model into Niwa’s vehicle motion control platform so that the system uses past velocities (traffic flow data) and past congestion events (incident data) to predict the average velocities and traffic congestion of a roadway before or as the vehicle travels along that roadway.
A person that is skilled in the art would have been motivated to combine Niwa and Sivaraman to improve traffic performance and safety in congested conditions [Col.1 line 6-11] “The present disclosure is directed to technologies and techniques for automatically controlling a vehicle. More specifically, the present disclosure is directed to positioning a vehicle between other vehicles and in turn distributing vehicle traffic and improving overall traffic performance and safety.”
Regarding Claim 22, The combination of Niwa with Sivaraman teaches the vehicle of claim 8, Niwa does not teach “further comprising: a long-term shared world model that comprises past velocities and past congestion of a roadway so that average velocities and the traffic congestion of the roadway is predicted as the vehicle travels along the roadway”
However, Sivaraman teaches equivalent teachings wherein further comprising: a long-term shared world model that comprises past velocities and past congestion of a roadway so that average velocities and the traffic congestion of the roadway is predicted as the vehicle travels along the roadway [Col.4 line 55-60] “Preferably, device 201 registrations are stored at the vehicle (e.g., 108) according to a device ID or SIM ID, and may further include a device user profile associated with each ID that may include vehicle settings, vehicle function preferences, demographic data, and/or user device/vehicle history.” [Col.8 line 54-62] “Traffic data may be delivered using a plurality of data types that can be received about the road network. Two exemplary data types comprise incident data and traffic flow data. Incident data refers to information generally about a specific point/event on a road such as an accident or construction work (i.e., past congestion data). Flow data refers to the average speed vehicles (i.e., past average velocities) are currently traveling on a particular section of road. In one embodiment, navigation system 501 is configured to receive both types of data. This would be advantageous, for example, if a road only has incident coverage, and unexpected bad weather causes traffic to back up. As this scenario may not be detected by incident data (since there technically is not a particular accident-causing slower traffic), dual coverage that includes flow data would detect the back up more efficiently.” [Col.9, line 1-17] “Turning to FIG. 6, a process is shown for determining and activating a congestion status for triggering congestion-based ACC in an illustrative embodiment. The process begins at block 602 where processor 107 obtains and processes vehicle data, which includes vehicle use characteristics such as acceleration, speed, average speed, braking, braking frequency etc. Next in block 604, the navigation unit obtains and processes navigational system data, which includes any of the traffic data discussed above. Processor 107 then determines in block 606 if navigation data indicates congestion in an area traveled by vehicle 101. If, in determination block 606, it is determined that congestion exists (“YES”), the process moves to block 610, where congestion-based ACC is activated in vehicle 101. If, in determination block 606, it is determined that congestion is not detected (“NO”), the process moves to decision block 608, where it is determined if the vehicle data is consistent with the navigational system data.”
A person of ordinary skill in the art would understand that Sivaraman’s navigation/traffic data stored and delivered for roadway segments (incident history and traffic flow/average speed history) constitutes a long-term shared traffic model (i.e., a shared dataset about roadway conditions over time) that comprises past congestion (incident data) and past velocities (traffic flow data), and that this model is used by the vehicle navigation/processor while the vehicle is traveling to determine and predict roadway congestion and expected traffic speeds along the roadway.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to integrate Sivaraman’s traffic/roadway model into Niwa’s vehicle motion control system as a “long-term shared world model” comprising past velocities (traffic flow history for segments) and past congestion (incident history), so that, as the vehicle travels along the roadway, the onboard system uses that shared model to predict average velocities and congestion status for roadway segments and adjust vehicle control accordingly.
A person that is skilled in the art would have been motivated to combine Niwa and Sivaraman to improve traffic performance and safety in congested conditions [Col.1 line 6-11] “The present disclosure is directed to technologies and techniques for automatically controlling a vehicle. More specifically, the present disclosure is directed to positioning a vehicle between other vehicles and in turn distributing vehicle traffic and improving overall traffic performance and safety.”
Regarding Claim 23, The claim recites a non-transitory computer-readable medium storing instructions and recites the parallel limitations in claim 21, respectively for the reasons discussed above. Therefore, claim 23 is rejected using the same rational reasoning.
Claims 7 and 14 are rejected under § 103 as being unpatentable over Niwa (US 20110066344 A1), in view of Sivaraman (US 9272711 B1), and further in view of Gupta (US 20240025404 A1).
Regarding Claim 7, The combination of Niwa with Sivaraman teaches the method of claim 1, wherein obtaining, by the inversion controller, the cruise control parameter comprises: obtaining the cruise control parameter Niwa teaches speed control requests and ACC distance control which rely on predefined control logic and allowable ranges; and conversion modules implemented as ECU program modules [0075] “the functions of the vehicle motion control platform 10 are implemented by an ECU (electronic control unit) which is based on a microcomputer (not shown in the drawings) installed in the vehicle, i.e., the position control platform 20, the speed control platform 30 and the acceleration control platform 40 are respectively implemented as modules of a program or programs executed by the microcomputer. However, the position control platform 20, speed control platform 30 and acceleration control platform 40 are not limited to any specific software or hardware configuration. For example, it would be possible to implement these through execution of a program by a single dedicated ECU, or through execution of programs by a plurality of ECUs.”, Niwa also discloses control policies and arbitration policies [0049], [0078]–[0087] consistent with table-based implementations.
Niwa does not teach wherein obtaining the cruise control parameter from a lookup table.
However, Gupta teaches equivalent teachings where in the system include a lookup table [0076] “the vehicle 502 may be automatically controlled to follow vehicle 504 at a following gap determined according to an initial control strategy, such as that provided by a speed-gap table.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement Niwa’s cruise control parameter selection (speed/distance related requests and allowable ranges) using Gupta’s table-based speed-gap representation to simplify runtime computation and improve storage efficiency.
A person that is skilled in the art would have been motivated to combine Niwa, Sivaraman, and Gupta teachings to simplify runtime computation, reduce reliance on raw trajectory data, and improve storage efficiency [0080] “The vehicle data 330 is significantly less noisy than raw trajectory data because it does not include data corresponding to periods of non-steady-state operation such as vehicle transition states and/or non-car following states. Further, because the vehicle data 330 excludes vehicle dynamics data corresponding to periods of non-steady-state operation, it is more storage efficient.”
Regarding Claim 14, The claim recites the parallel limitations in claims 2 and 7, respectively for the reasons discussed above. Therefore, claim 14 is rejected using the same rational reasoning.
Claim 3, 10, and 17 are rejected under § 103 as being unpatentable over Niwa (US 20110066344 A1), in view of Sivaraman (US 9272711 B1), and further in view of Wang (US 20230047354 A1).
Regarding Claim 3, The combination of Niwa with Sivaraman teaches the method of claim 1, The combination of Niwa with Sivaraman does not teach the full claim limitation regarding “wherein the model is trained using training data, wherein each training datum includes a training cruise control parameter and a training vehicle acceleration command that is obtained from the cruise control module and wherein the training cruise control parameter includes at least one of a training speed setting or a training gap setting”
However, Wang teaches equivalent teachings wherein the model is trained using training data, wherein each training datum includes a training cruise control parameter and a training vehicle acceleration command that is obtained from the cruise control module and wherein the training cruise control parameter includes at least one of a training speed setting or a training gap setting [0049] “ACC module 455 generally includes instructions that when executed by the one or more processors 110 cause the one or more processors 110 to generate an acceleration command 230 for the vehicle 100” [0049] “ACC module 455 produces the acceleration command 230 by processing real-time sensor data (e.g., ego- vehicle speed, lead-vehicle speed, and the measured space gap between the ego vehicle 100 and the lead vehicle 310) from sensor system 120 using the GP Regression model trained by training module 420.” [0047] “Training module 420 generally includes instructions that when executed by the one or more processors 405/110 cause the one or more processors 405/110 to train a GP Regression model using the collected vehicle-following-behavior data 210 to produce a set of ACC parameters 350 pertaining to the particular driver.”
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Niwa, Sivaraman, and Wang to make the system wherein the model is trained using training data, wherein each training datum includes a training cruise control parameter and a training vehicle acceleration command that is obtained from the cruise control module.
A person that is skilled in the art would have been motivated to combine Niwa, Sivaraman, and Wang to improve the training model accuracy Wang [0048] “In some embodiments, training module 420 includes instructions that, when executed by the one or more processors 405/110, cause the one or more processors 405/110 to employ nonlinear output-error (NOE) in the training process to improve training accuracy. GP-NOE is discussed in greater detail below.”
Regarding Claim 10, The claim recites the parallel limitations in claim 3, respectively for the reasons discussed above. Therefore, claim 10 is rejected using the same rational reasoning.
Regarding Claim 17, The claim recites a system of the parallel limitations in claim 3, respectively for the reasons discussed above. Therefore, claim 17 is rejected using the same rational reasoning.
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 HUSSAM ALZATEEMEH whose telephone number is (703)756-1013. The examiner can normally be reached 8:00-5:00 M-F.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Aniss Chad can be reached on (571) 270-3832. 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.
/HUSSAM ALDEEN ALZATEEMEH/Examiner, Art Unit 3662
/ANISS CHAD/Supervisory Patent Examiner, Art Unit 3662