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 .
Summary
The Amendment filed on 4 May 2026 has been acknowledged.
Claims 1 – 10 have been amended.
Claims 11 – 21 are cancelled.
Claim 22 – 31 are is newly presented
Currently, claims 1 – 10 and 22 – 31 are pending and considered as set forth.
Response to Arguments
Applicant’s arguments, see Remarks/Argument, filed on 4 May 2026, with respect to the rejections of claims 1 – 2, 6 – 11, 13 – 14, 16 – 17 and 19 – 21 under Tiwari et al., Packer et al., and Google have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new grounds of rejection is made in view of Tiwari and Google based on the claim amendments the Applicant made.
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 – 2, 4 – 10, 22 – 23 and 25 – 31 are rejected under 35 U.S.C. 103 as being unpatentable over Tiwari et al. (Hereinafter Tiwari) (US 2018/0154899) in view of Google Cloud Blog (Hereinafter Google) (https://cloud.google.com/blog/products/ai-machine-learning/an-in-depth-look-at-googles-first-tensor-processing-unit-tpu).
As per claim 1, Tiwari teaches limitations of:
an autonomous or semi-autonomous machine (See at least paragraph 14; The system is operable between several operating modes, including a manual operation mode, an autonomous operation mode (e.g., level four autonomy, level five autonomy, etc.), a semi-autonomous operation mode (e.g., level three autonomy, level two autonomy, etc.)) comprising:
a plurality of sensors including at least one or more geolocation sensors and one or more perception sensors (See at least paragraph 31 and 33; The perception module 110 can function to directly perceive the environment (e.g., to sample imaging sensors, rangefinding sensors, etc.) as well as to perform analysis related to perception (e.g., object detection, object classification, image feature detection, image feature tracking, traffic data extraction, etc.). The perception module 110 includes a sensor subsystem in, and can include a lane detection block 112, a lane tracking block 113, an object detection block 114, an object tracking block 115, a state estimation block 116, and a cost mapping block 117. … The localization of the vehicle 1101 preferably includes the absolute geographic location of the vehicle (e.g., a geographic location, GPS coordinates), but can additionally or alternatively include relative distance(s) between the vehicle and objects proximal the vehicle (e.g., roadway edges, lane edges, nearest-neighbor vehicles, traffic signage, etc.), and/or any other suitable location or positional information.) ; and
at least one processing system including one or more memory devices and one or more hardware-based accelerators (See at least paragraph 69; The local planning module 140 includes a plurality of task blocks 141, and can include a degenerate block 142. The local planning module 140 is preferably located entirely at the vehicle, and is preferably implemented at least in part at a local computing subsystem (e.g., an application-specific integrated circuit, a GPU, a CPU, a microcontroller, a mobile device residing at the vehicle, etc.)), the at least one processing system to:
produce one or more occupancy representations based at least on sensor inputs obtained using the plurality of sensors (See at least paragraph 37 and 43; sensors and/or data sources on-board the vehicle include: an inertial measurement unit (IMU), ultrasonic sensors, a data port (e.g., on-board diagnostic module port/OBD port), GPS sensor(s) and modules, cameras (e.g., stereoscopic cameras, single lens cameras, etc.), navigation sensors (e.g., LiDAR, radar, ToF, etc.) … The object detection block 114 of the perception module 110 functions to detect objects proximal the vehicle based on the sensor data gathered by the sensor subsystem. Such objects can include neighboring vehicles (e.g., vehicles within one vehicle-length of the vehicle, vehicles within sensor range of the sensor subsystem, etc.), static objects (e.g., road signs, sound-suppression walls, center dividers, etc.), and any other physical objects nearby the vehicle. The object detection block 114 can detect (e.g., identify the existence of) the objects, classify (e.g., determine the type of) the objects, and perform any other suitable analysis related to the objects.);
plan machine paths based at least on the one or more occupancy representations in view of a current location of the machine (See at least paragraph 55 – 56; The behavior planning module 130 preferably receives the cost map 1102 and the traffic data 1103 from the perception module 110 and the route plan 1201 from the mission planning module 120 and generates planner primitives 1301 based on the cost map 1102, traffic data 1103, and route plan 1201. In an alternative variation, the behavior planning module 130 receives the cost map 1102 and traffic data 1103 from the perception module 110, and a directive from a remote operator (e.g., received at the decision-making block 135) and generates planner primitives 1301 based on the cost map 1102, traffic data 1103, and the directive. In another variation, the behavior planning module generates the planner primitives based on output of the prediction block, which includes estimated future positions of nearby traffic objects. However, the behavior planning module can additionally or alternatively receive any suitable inputs from any other modules of the system 100, and generate any suitable outputs in any suitable manner. The planner primitives 1301 are preferably high-level instructions that semantically describe the desired vehicle behavior. For example, the planner primitives 1301 can include instructions to stay within the current lane on the roadway (e.g., a lane keeping primitive), instructions to hold the present speed (e.g., a maintain-state primitive), instructions to change lanes (e.g., a lane-change primitive), and any other suitable high-level instructions. The planner primitives 1301 are preferably generated by the decision-making block 135 and can incorporate inputs from other block(s) of the behavior planning module 130 and/or can be based at least in part on the cost map 11-2. traffic data 1103, and route plan 1201, either directly or indirectly. However, the planner primitives 1301 can additionally or alternatively include low-level instructions (e.g., analog signals suitable for operating actuators, detailed instructions for operation that include specific distances, angles, and time periods, etc.) and/or any other suitable output(s) of the behavior planning module 130.);
arbitrate between machine paths to select a path (See at least paragraph 60 – 61; The decision-making block can generate various outputs for use by other system components and/or related entities. The decision-making block preferably determines a task block to execute based on received inputs (e.g., inputs such as those described above), but can otherwise suitably generate and/or determine outputs. Outputs of the decision-making block can include, for example: direct vehicle control instructions (e.g., voltages and/or currents to supply to the actuation subsystem), a selected task block (e.g., wherein the task block codifies a set of instructions to change from the current lane to a lane to the left of the vehicle), a set of selected task blocks (e.g., wherein the task blocks codify a set of instructions to change lanes to the right and to engine brake), input parameters for a task block or set of task blocks (e.g., a target speed in miles-per-hour, the last-known position of objects in the immediate vicinity of the vehicle, etc.), any suitable combination of the aforementioned outputs, or any other suitable outputs. In a first variation, determination of a task block by the decision-making block includes selecting one of a set of task blocks (e.g., a set including an acceleration module, a deceleration module, a speed-maintenance module, etc.). In a second variation, determining a task block includes selecting a combination of task blocks (e.g., a lane-change and an acceleration module, a lane-keeping and a speed-maintenance module, an emergency braking module and hazard-light-activation module, etc.). In a third variation, determining a task block includes generating and/or modifying a task block (e.g., automatically generating a list of executable instructions to accomplish a vehicle operation task)); and
cause the autonomous or semi-autonomous machine to perform one or more control operations based at least on the selected path (See at least paragraph 101; generating a planner primitive, which functions to provide a high-level description (e.g., a semantic description) of the specific actions to be taken in navigating the vehicle according to the directive. Block S230 can include generating the planner primitive based on a directive. For example, the directive can include a directive to change lanes, and Block S230 can include generating a planner primitive to enter a lane-change task block and a set of criteria that should be met before initiating the lane change (e.g., an integrated cost threshold based on the cost map, a timeout limit, etc.). Block S230 can include automatically generating the planner primitive. For example, Block S230 can include automatically generating a planner primitive at a behavior planning module of the vehicle based on the received sensor data (e.g., operating substantially and/or completely autonomously)).
While Tiwari teaches at least one hardware-based accelerator (See the rejection above), Tiwari is silent regarding the limitation of:
the one or more hardware-based accelerators including at least one matrix multiplication unit (MMU).
Google teaches limitations of:
the one or more hardware-based accelerators including at least one matrix multiplication unit (MMU) (See at least page 1 paragraph 1 – 2 and 4 - 5; There’s a common thread that connects Google services such as Google Search, Street View, Google Photos and Google Translate: they all use Google’s Tensor Processing Unit, or TPU, to accelerate their neural network computations behind the scenes. We announced the TPU last year and recently followed up with a detailed study of its performance and architecture. In short, we found that the TPU delivered 15–30X higher performance and 30–80X higher performance-per-watt than contemporary CPUs and GPUs. These advantages help many of Google’s services run state-of-the-art neural networks at scale and at an affordable cost. In this post, we’ll take an in-depth look at the technology inside the Google TPU and discuss how it delivers such outstanding performance. Usually, ASIC development takes several years. In the case of the TPU, however, we designed, verified, built and deployed the processor to our data centers in just 15 months. Norm Jouppi, the tech lead for the TPU project (also one of the principal architects of the MIPS processor) described the sprint this way. … The TPU ASIC is built on a 28nm process, runs at 700MHz and consumes 40W when running. Because we needed to deploy the TPU to Google's existing servers as fast as possible, we chose to package the processor as an external accelerator card that fits into an SATA hard disk slot for drop-in installation. The Examiner construes that tensor core can perform matrix multiplication.).
It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention was made to modify using vehicle controller to control vehicle based on planning the behavior and lane management on the road via neural network process of Tiwari, to include at least one tensor core that can perform matrix multiplication as taught by Google in order to perform process data faster than CPU or GPU (Google, page 1).
As per claim 2, Tiwari discloses wherein machine paths are planned using a planner including a basic behavior planner and at least one advanced behavior planner (See at least paragraph 18 and 64; performing vehicle operation tasks and/or actions (e.g., lane changing, gear shifting, braking, etc.) according to deterministic models (e.g., hard-coded models, explicitly programmed sets of rules, a set of static computer-implemented rules, etc.) … The trajectory generator 132 preferably generates one or more trajectories as output(s), and provides the one or more trajectories to the decision-making block 135. The generated trajectories can be two-dimensional trajectories plotted from the current position of the vehicle to a desired future position of the vehicle, wherein the distance between the current position and the future position is determined based on the speed of the vehicle and the rate (e.g., frequency) at which the system module(s) and/or block(s) are executed. For example, a generated trajectory can correspond to the path designated for the vehicle to follow over the next 5 seconds, 15 seconds, 60 seconds, and any other suitable time period. Proximal in time (e.g., coincident with, contemporaneously with, within 1 second of, etc.) the end of the time period corresponding to the completion of travel via the generated trajectory, a new trajectory can be generated by the trajectory generator 132. However, the trajectory generator 132 can additionally or alternatively generate one or more trajectories in any suitable manner.) The Examiner notes that Tiwari can perform basic behavior planning such as basic brake, acceleration and lane change if possible, and advanced behavior planning such as comparing set of trajectories to find a best choice based on the objects around the vehicles.
As per claim 4, The combination of Tiwari and Google discloses wherein the at least one processing system is capable of achieving an ASIL “D” rating under ISO 26262-9:2011 for Level 3 – 5 autonomous driving (Tiwari, see at least paragraph 14).
As per claim 5, The combination of Tiwari and Google discloses wherein the machine path correspond to staying in a current lane, following a fork in a lane graph, or changing lane (Tiwari, see at least paragraph 56 and 60 - 61).
As per claim 6, The combination of Tiwari and Google discloses wherein the machine paths are planned in view of wait conditions and in-path objects (Tiwari, see at least paragraph 41 and 44 – 45).
As per claim 7, The combination of Tiwari and Google discloses wherein the at least one hardware-based accelerator is deep learning accelerator, start from edges of a tracked lane graph after a lane change to provide plural paths through the tracked lane graph and to determine a path favored by a match to an output of the lane planner (Tiwari, see at least paragraph 41 – 42, 56 and 113).
As per claim 8, The combination of Tiwari and Google discloses wherein the machine paths are planned by independently processing longitudinal control and longitudinal constraints relevant to the respective path (Tawari, see at least paragraph 46 and 56).
As per claim 9, The combination of Tiwari and Google discloses wherein at least one processing system is capable of massively parallel processing (Tawari, see at least paragraph 28).
As per claim 10, The combination of Tiwari and Google discloses wherein the occupancy representation includes an occupancy grid, and the occupancy grid is used to check the machine paths for at least one of safety or comfort (Tawari, see at least paragraph 35 and 64).
Regarding claims 22 – 23 and 25 - 31:
Claims 22 – 23 and 25 – 31 are rejected using the same rationale, mutatis mutandis, applied to claims 1 – 2 and 4 – 10 above, respectively.
Claims 3 and 24 are rejected under 35 U.S.C. 103 as being unpatentable over Tiwari and Google and in further view of Redding et al. (Hereinafter Redding) (US 2018/0089563).
As per claim 3, the combination of Tiwari, Packer and Google teaches all the element of the claimed invention but does not explicitly teach element of: wherein the machine paths individually include associated scores based on feasibility of different behaviors.
Redding teaches element of: wherein the machine paths individually include associated scores based on feasibility of different behaviors (See at least paragraph 6)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include wherein the machine paths individually include associated scores based on feasibility of different behaviors as taught by Redding in the system of the combination of Tiwari and Google, since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 24:
Claim 24 is rejected using the same rationale, mutatis mutandis, applied to claim 3 above, respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to IG T AN whose telephone number is (571)270-5110. The examiner can normally be reached M - F: 10:00AM- 4:00PM.
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 at (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.
IG T AN
Primary Examiner
Art Unit 3662
/IG T AN/Primary Examiner, Art Unit 3662
Prosecution Insights