Patent Drafting Analysis of NVIDIA Corporation’s Autonomous Vehicle SoC Architecture | US 11,644,834 B2
Patent Drafting Analysis of NVIDIA Corporation's Autonomous Vehicle SoC Architecture | US 11,644,834 B2
A structural and strategic analysis of NVIDIA's granted autonomous vehicle SoC patent, examining claim architecture, drafting quality, functional safety integration, and prosecution positioning across 60 claims.
Spec Words
52,000
Across 9 sections
Draft now ↗
Total Claims
60
6 independent · 54 dependent
Draft now ↗
Figure Sheets
62
SoC architecture, safety systems, AV platforms, perception
Draft now ↗
Published by PatSnap Insights Team · · 14 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 63% of total estimated words (~43,000 of ~68,000), reflecting the extraordinarily broad scope of autonomous vehicle technology covered across perception, planning, control, and functional safety subsystems. The claim set comprises 60 claims total — 6 independent and 54 dependent — all directed to apparatus (system-on-a-chip) claim types with no method or CRM claims, a notable strategic limitation given the breadth of the disclosed software stack. The 62 drawing sheets provide comprehensive figure support spanning SAE automation levels, ASIL risk tables, SoC block diagrams, software system diagrams, sensor configurations, and multiple vehicle platform embodiments.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 62 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Table illustrating SAE/NHTSA automation levels from driver-only (Level 0) to full automation (Level 5) with driver loop requirements and examples.Search in Eureka ↗ | Other |
| FIG. 2 | Table presenting controllability, severity, and exposure factors for determining ASIL risk levels C0–C3, S0–S3, E0–E4.Search in Eureka ↗ | Other |
| FIG. 3 | Neural network training data flow diagram showing input layer (6010), hidden layers (6020), and output layer (6030) for traffic sign recognition using forward and backward propagation.Search in Eureka ↗ | Claim support |
| FIG. 4 | Top-view diagram of an example autonomous self-driving vehicle (50) showing placement of cameras, LIDAR (70), RADAR (68), ultrasonic sensors (66), IMU (82), GPS (76), and controllers (100).Search in Eureka ↗ | Key embodiment |
| FIG. 5 | Bird's-eye view showing example camera types and field-of-view coverage zones including surround cameras (72), stereo cameras (74), wide-view camera (73), infrared camera (75), and long-range cameras (76).Search in Eureka ↗ | Key embodiment |
| FIG. 6 | Cloud-based datacenter architecture (5000) with GPU servers (5001–500N) communicating via NVLink/PCIe with autonomous vehicle (50) showing wireless uplink (1101) and downlink (1102).Search in Eureka ↗ | System architecture |
| FIG. 7 | High-level block diagram of the Advanced Platform (100) showing CPU (200), GPU (300), Accelerator cluster (400), Storage (500), and Bus (160) with I/O (170).Search in Eureka ↗ | Claim support |
| FIG. 8 | Detailed block diagram of the Advanced SoC (100) showing CPU Complex (200) with cores (201) and L2 caches (202), GPU Complex (300) with SMs (301), ACCEL Complex (400) with TPUs (401) and VAs (402), and memory (500/600/700).Search in Eureka ↗ | Claim support |
| FIG. 9 | Detailed component diagram of the Advanced SoC showing system fabric (714), CPU cluster (200), GPU (300), accelerators, safety cluster engine (704), real-time camera management (705), APB (710), and memory controller.Search in Eureka ↗ | Claim support |
| FIG. 10 | Block diagram of the Programmable Vision Accelerator (PVA 402) showing RISC core (4010), DMA engines (4020), vector processors (4030), and memory (4040).Search in Eureka ↗ | Claim support |
| FIG. 11 | Hardware Acceleration Cluster memory architecture (400/600) showing DLAs (401), PVAs (402), AXI bus connections (407), cluster memory (600), FCM blocks (601), and MUX (603).Search in Eureka ↗ | Claim support |
| FIG. 12 | Multiple neural networks (7040, 7050, 7060) running on DLA interpreting a caution traffic sign with flashing lights and icy conditions through parallel classification tasks.Search in Eureka ↗ | Claim support |
| FIG. 13 | Advanced SoC controlling an autonomous vehicle, showing sensor inputs (cameras, LIDAR, RADAR, GPS), controller (100), steering (62A), propulsion (64A), and brake (63A) subsystems.Search in Eureka ↗ | System architecture |
| FIG. 14 | Table showing ASIL decomposition methods per ISO 26262 Part 9, mapping ASIL D/C/B/A requirements to decomposed component pairs.Search in Eureka ↗ | Other |
| FIG. 15 | Functional safety block diagram showing ASIL B(D) pipeline stages — pre-processing (150), DL processing (162), post-processing (164) — across DLA (401), PVA (402), and iGPU (300).Search in Eureka ↗ | Claim support |
| FIG. 16 | Platform with three SoCs including ASIL C Advanced SoC (100), PARKER SoC ASIL B (200), and ASIL D MCU (316) with NVLINK connections and PMIC power management.Search in Eureka ↗ | System architecture |
| FIG. 17 | First exemplary L3-L5 platform architecture (800) with two Advanced SoCs (100) connected via NVLINK (805) to two discrete GPUs (802) with DeSer units and MCU (803).Search in Eureka ↗ | Key embodiment |
| FIG. 18 | Second exemplary L3-L5 platform architecture (900) adding an X86 CPU (901) connected via PCIe x8 Gen3 (902) to the dual Advanced SoC configuration.Search in Eureka ↗ | Key embodiment |
| FIG. 19 | Third exemplary L3-L5 platform architecture (900) with PCIe Switch (804) connecting X86 CPU to dual Advanced SoC and dual GPU configuration.Search in Eureka ↗ | Key embodiment |
| FIG. 20 | Communications architecture (2000) showing dual SOC (2002(1), 2002(2)) with associated GPUs (2006), memory systems (2004), deserializers (2024), PCIe switch (2012), and MCU units (2003).Search in Eureka ↗ | System architecture |
| FIG. 21 | Multiple Advanced SoCs controlling an autonomous vehicle showing dual dGPU (802), dual SoC (100), X86 CPU (941), sensor inputs, and fault-tolerant steering/propulsion/brake actuators.Search in Eureka ↗ | System architecture |
| FIG. 22 | Exemplary architecture with eight Advanced SoCs (100) and eight dGPUs (802) interconnected via NV Switch (1001) using NVLINK connections (805).Search in Eureka ↗ | Key embodiment |
| FIG. 23 | Architecture with one Advanced SoC (100) and four dGPUs (802) connected via NVLINK (805) and NV Switch (1001).Search in Eureka ↗ | Key embodiment |
| FIG. 24 | High-level system architecture with allocated ASILs showing primary computer (100, ASIL C), secondary computer (200, ASIL B), supervisory control unit (600, ASIL D), and sensor subsystems.Search in Eureka ↗ | Claim support |
| FIG. 25 | Arbitration modules diagram showing braking module (700) with arbitration between independent control signals (702) and window/conflict logic for resolving commands from primary and secondary computers.Search in Eureka ↗ | Flow diagram |
| FIG. 26 | System architecture with allocated ASILs showing primary computer (100), secondary computer (200), supervisory MCU (600, ASIL D), sensor groups (700–707), and perception/driving modules.Search in Eureka ↗ | System architecture |
| FIG. 27 | Advanced ADAS systems as secondary computer (200) including Mobileye ADAS systems (AEB, LDW, FCW, LKA, ASIL B) feeding into perception and dynamic driving task modules.Search in Eureka ↗ | System architecture |
| FIG. 28 | Virtual machine configuration (4000) showing hypervisor priority scheduler (4008) managing VCPUs (4004) assigned to hardware CPU cores (4006) across multiple virtual machines.Search in Eureka ↗ | System architecture |
| FIG. 29 | Application allocation on virtual machines showing GPU channel assignment (4012) across virtual machines (4002(0)–4002(2)) with memory management unit and memory controller.Search in Eureka ↗ | System architecture |
| FIG. 30 | Workflow for compute instructions with preemption showing command pushbuffer (6102), dispatch (6104), work groups (6106), threads (6108), and compute instructions (6110).Search in Eureka ↗ | Flow diagram |
| FIG. 31 | Partitioning services for functional safety showing communication partition (4002(L)), security partition (4002(M)) with neutral net and audit/log, and drive partition (4002(P)).Search in Eureka ↗ | System architecture |
| FIG. 32 | Communication and security system architecture showing communication partition (4002(L)) with virtual router (4032), security partition (4002(M)) with virtual bridge (4034), and guest OS partition (4002(P)).Search in Eureka ↗ | System architecture |
| FIG. 33 | Software stack showing processor SOC (5054) with CCPLEX, SCE, and safety MCU (5020) layers, including L1SS (5014(1)), L2SS (5014(2)), L3SS (5014(3)) safety supervisors and watchdogs.Search in Eureka ↗ | System architecture |
| FIG. 34 | Functional safety configuration showing safety MCU (5020) with safety monitor control (mission), L1SS/L2SS/L3SS layers, and processor SOC (5054) with AV apps, middleware, and device drivers.Search in Eureka ↗ | System architecture |
| FIG. 35 | Interaction topology for virtual machine applications showing L1SS (5014(1)), L2SS (5014(2)), L3SS safety MCU (5014(3)), hypervisor (CCPLEX), and NvIVC channels per guest VM.Search in Eureka ↗ | System architecture |
| FIG. 36 | Flowchart for monitoring errors in a Guest OS showing integrity check by watchdog (5010), error detection (5104), notification through L1SS→L2SS→L3SS chain, and corrective action.Search in Eureka ↗ | Flow diagram |
| FIG. 37 | Error reporting procedure showing BPMP (5060) and iGPU inputs, L1 CCPLEX (5014(1)), L2 SCE (5014(2)), and L3 external MCU (5014(3)) supervisory hierarchy.Search in Eureka ↗ | Flow diagram |
| FIG. 38 | Hardware error detection flow showing SOC hardware IP (5090), HW checkers (5092), HW Error Collator (5094), Hardware Security Module (5096), and L1SS/L2SS/L3SS notification chain.Search in Eureka ↗ | Flow diagram |
| FIG. 39 | Software error detection flow showing application fault (step 1) propagating through L1SS (5014(1)), L2SS SOC SCE (5014(2)), and L3SS Safety MCU (5014(3)) with SPI bus and error signal pin.Search in Eureka ↗ | Flow diagram |
| FIG. 40 | Partition configuration for peripheral sensor inputs showing event partition (4053) with async processing, time-triggered partition (4054) with time-triggered graph executor, and watchdog (4060).Search in Eureka ↗ | System architecture |
| FIG. 41 | Software system diagram for autonomous driving platform (3000) showing world model (3002), perception modules (3010–3016), planning (3004), control (3006), actuation (3008), and cloud mapping (3022).Search in Eureka ↗ | System architecture |
| FIG. 42 | Detailed software system diagram expanding FIG. 41 with tracked lane graphs (3100), dynamic occupancy grid (3102), obstacle perception (3010), trajectory estimation (3030), self-calibration (3028), and HD map components.Search in Eureka ↗ | System architecture |
| FIG. 43 | Example tracked lane graph (3100b) showing contention area, wait condition, in-path object, lane boundary, fork, merge, and dynamic occupancy grid elements.Search in Eureka ↗ | Claim support |
| FIG. 44 | Example annotation of valid path showing L-shaped boundary markers used as training input for neural network lane detection.Search in Eureka ↗ | Other |
| FIG. 45 | Example output from detecting virtual landmarks showing vertical line segments identified by neural network for sensor roll and pitch calibration.Search in Eureka ↗ | Other |
| FIG. 46 | Point detector output showing tracked feature points on multiple object trajectories across consecutive image frames.Search in Eureka ↗ | Other |
| FIG. 47 | Output from iterative closest point (ICP) alignment between LIDAR frames showing spatial separation of point clouds for trajectory estimation.Search in Eureka ↗ | Other |
| FIG. 48 | Self-calibrator (3028) block diagram showing pitch/roll/yaw estimation chains for cameras, LIDAR, and RADAR using lane detection, vertical landmarks, and vehicle odometry inputs.Search in Eureka ↗ | Claim support |
| FIG. 49 | Trajectory estimation (3030a) block diagram showing image feature tracking, triangulation, depth maps, windowed bundle adjustment, and world placement modules.Search in Eureka ↗ | Claim support |
| FIG. 50 | Example pixel-wise class output images showing bounding boxes at multiple scales for object detection using deep learning on camera frames.Search in Eureka ↗ | Other |
| FIG. 51 | Object tracking output showing bounding box progression across frames to bridge detection gaps and enable temporal association.Search in Eureka ↗ | Other |
| FIG. 52 | Example output from temporal baseline determination showing relative motion analysis between successive frames for time-of-arrival estimation.Search in Eureka ↗ | Other |
| FIG. 53 | Example output from heuristic ground plane redefinition showing vehicle approaching a curved road with projected image plane.Search in Eureka ↗ | Other |
| FIG. 54 | Example output from RADAR and vision track mapping showing frustum projection of vision track onto RADAR coordinate space for sensor fusion.Search in Eureka ↗ | Other |
| FIG. 55 | Example dynamic occupancy grid (3102) showing three-lane highway scenario with ego vehicle, lead vehicle, and predicted occupancy paths.Search in Eureka ↗ | Claim support |
| FIG. 56 | Example path perception scenario showing lane graph with fork/merge topology and drivable edge splines.Search in Eureka ↗ | Claim support |
| FIG. 57 | In-path determination scenario showing bounding box projected onto lane path pixel map for object-to-path encroachment detection.Search in Eureka ↗ | Other |
| FIG. 58 | Wait condition scenario showing intersection with stop sign, traffic signal, and merge junction representing a multi-way stop scenario.Search in Eureka ↗ | Other |
| FIG. 59 | Map perception scenario showing visual elements detected: road boundaries, perpendicular lines, dashes/dots, vertical landmarks, traffic lights, signs, and road images.Search in Eureka ↗ | Other |
| FIG. 60 | Directed graph with points and tangents at each node showing lane graph topology with spline edges for path representation.Search in Eureka ↗ | Claim support |
| FIG. 61 | Directed graph with wait conditions showing stop line markers overlaid on lane graph for intersection negotiation planning.Search in Eureka ↗ | Other |
| FIG. 62 | Representational view of a schematic for displaying additional definitional information showing shaded corridors on lane graph edges.Search in Eureka ↗ | Other |
| FIG. 63 | Planning hierarchy diagram showing route planner (3004e), lane planner (3004c), advanced behavior planner (3004b), and basic behavior planner (3004a) as nested layers.Search in Eureka ↗ | Claim support |
| FIG. 64 | Example output from controller (3006) showing planned trajectory (dashed) vs. executed trajectory (solid) for a curved road segment.Search in Eureka ↗ | Claim support |
| FIG. 65 | Example self-driving long-haul truck (50/55) showing sensor placement including surround cameras, LIDAR, RADAR, GPS, inertial sensors, gust sensors, and weight/balance sensors.Search in Eureka ↗ | Key embodiment |
| FIG. 66 | Example self-driving two-level bus (56) showing sensor configuration including surround cameras, interior cameras, LIDAR, RADAR, weight/balance sensors, and controller placement.Search in Eureka ↗ | Key embodiment |
| FIG. 67 | Example self-driving articulated bus (57) showing sensor layout across multiple articulated sections with surround cameras, interior cameras, LIDAR, RADAR, and inertial sensors.Search in Eureka ↗ | Key embodiment |
| FIG. 68 | Example self-driving tiller truck (58) showing dual-controller configuration (100(1), 100(2)) for independent front/rear axle control with cameras, LIDAR, RADAR, and weight/balance sensors.Search in Eureka ↗ | Key embodiment |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent presents 6 independent claims, all directed to apparatus (system-on-a-chip) form — Claims 1, 4, 26, 29, 52, 55, 59, and 60 are independent (the patent states 60 claims with the last independent claims at 59 and 60) — with 54 dependent claims producing a dependent-to-independent ratio of 9.0:1, well above the automotive/semiconductor norm. A significant strategic observation is that all claims are system-on-a-chip apparatus claims with zero method or CRM claims filed, leaving the operational software stack and training pipeline entirely unprotected by direct claim coverage. Claims 1, 4, 26, and 29 progressively add features like L3 cache, real-time ray tracing GPU, and specific memory specifications, while Claims 52, 55, 59, and 60 add PVA-specific architectural details.
Core inventive concept: The claims protect a purpose-built autonomous vehicle System-on-a-Chip integrating a CPU cluster supporting virtualization, a massively parallel GPU, at least one deep learning accelerator (DLA) configured to execute neural networks, and a programmable vision accelerator (PVA), where these four compute elements 'interoperate to process at least the received camera sensor data and the LIDAR sensor data to perform lane detection' — solving the problem of achieving ASIL D functional safety through redundant, diverse hardware processing paths on a single chip.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU cluster supporting virtualization with multiple CPU cores and L2 caches and simplified power state entry sequences; at least one GPU providing massively parallel processing; embedded hardware accelerator cluster comprising at least one DLA configured to execute neural networks and a programmable vision accelerator; at least one memory device interface; instructions configured to operate as autonomous vehicle controller receiving camera and LIDAR sensor data; interoperation to perform lane detectionSearch prior art ↗ |
| Claim 4 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing with tensor instruction set including at least eight streaming processors each with L1 cache and sharing L2 cache, mixed-precision cores in multiple processing blocks with independent thread scheduling; at least one programmable vision accelerator; at least one DLA configured to execute neural networks; at least one memory device interface; instructions for autonomous vehicle controller receiving LIDAR sensor data; interoperation providing object perceptor that perceives object affordancesSearch prior art ↗ |
| Claim 26 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing; a Level 3 cache available to both CPU and GPU; embedded hardware accelerator cluster comprising DLA and programmable vision accelerator; at least one memory device interface; instructions for autonomous vehicle controller receiving camera and LIDAR sensor data; interoperation to perform lane detectionSearch prior art ↗ |
| Claim 29 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing wherein the GPU includes real time ray tracing hardware-based acceleration to determine positions and extents of objects; embedded hardware accelerator cluster comprising DLA and programmable vision accelerator; at least one memory device interface; instructions for autonomous vehicle controller receiving camera and LIDAR sensor data; interoperation to perform lane detectionSearch prior art ↗ |
| Claim 52 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing; a Level 3 cache available to both CPU and GPU; at least one programmable vision accelerator; at least one DLA; at least one memory device interface; instructions for autonomous vehicle controller receiving LIDAR sensor data; interoperation for object perceptor that perceives object affordancesSearch prior art ↗ |
| Claim 55 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing including real time ray tracing hardware-based acceleration; at least one programmable vision accelerator; at least one DLA; at least one memory device interface; instructions for autonomous vehicle controller receiving LIDAR sensor data; interoperation for object perceptor that perceives object affordancesSearch prior art ↗ |
| Claim 59 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing; at least one programmable vision accelerator comprising RISC core, DMA circuit configured to support at least six dimensions of addressing, and vector processor; at least one DLA; at least one memory device interface; instructions for autonomous vehicle controller receiving LIDAR sensor data; interoperation for object perceptor perceiving object affordancesSearch prior art ↗ |
| Claim 60 | A system-on-a-chip for an autonomous vehicle | including | at least one CPU supporting virtualization; at least one GPU providing massively parallel processing; at least one programmable vision accelerator with vector processor configured to perform semi-dense or dense regular computation; at least one DLA; at least one memory device interface; instructions for autonomous vehicle controller receiving LIDAR sensor data; interoperation for object perceptor perceiving object affordancesSearch prior art ↗ |
Claim Dependency Tree
1 SoC for AV: CPU cluster with virtualization + GPU + DLA + PVA + memory interface; interoperate to perform lane detectionSearch Claim 1 prior art ↗
2 Adds: structured for Level 5 full autonomous driving compliance per SAE J3016Search in Eureka ↗
3 Adds: ASIL D compliance per ISO Standard 26262Search in Eureka ↗
7 Adds: CPU cluster includes at least eight CPU cores in coherent multi-processor configurationSearch in Eureka ↗
8 Further: CPU cluster supports simultaneous cluster operation with any combination of clusters activeSearch in Eureka ↗
9 Further: CPU cores organized as four dual-core clusters each with dedicated L2 unified cacheSearch in Eureka ↗
10 Further: high-speed coherency fabric connecting CPU cluster allowing heterogeneous multi-processingSearch in Eureka ↗
11 Adds: individual hardware blocks clock-gated automatically when idle; plural core clocks gated for WFI/WFESearch in Eureka ↗
12 Adds: each core is independently power-gatedSearch in Eureka ↗
13 Adds: each core cluster independently clock-gated and all cores clock-gated or power-gatedSearch in Eureka ↗
14 Adds: each core cluster independently power-gated and all cores power-gatedSearch in Eureka ↗
15 Adds: CPU cluster configured to manage power states with specified allowed power states and wakeup timesSearch in Eureka ↗
16 Adds: CPU cluster processing cores support simplified power state entry sequences with work offloaded to microcodeSearch in Eureka ↗
17 Adds: GPU is programmable and DLA comprises tensor processing unit for neural networks based on tensor instruction setSearch in Eureka ↗
18 Further: GPU includes at least eight streaming multiprocessors each with L1 cache and sharing L2 cacheSearch in Eureka ↗
19 Further: GPU power-optimized for performance in automotive embedded use applicationsSearch in Eureka ↗
20 Further: GPU fabricated on FinFET high-performance manufacturing processSearch in Eureka ↗
21 Further: each streaming multiprocessor incorporates mixed-precision processing cores partitioned into multiple processing blocksSearch in Eureka ↗
22 Further: processing blocks comprise FP32, FP64, INT32 Cores, Tensor Cores, instruction cache, warp scheduler, dispatch unit, Register FileSearch in Eureka ↗
23 Further: processing blocks include independent parallel integer and floating-point data pathsSearch in Eureka ↗
24 Further: each streaming processor includes independent thread scheduling capabilitySearch in Eureka ↗
25 Further: each streaming processor includes combined L1 data cache and shared memory unitSearch in Eureka ↗
30 Adds: DLA includes one or more tensor processing unitsSearch in Eureka ↗
31 Further: tensor processing units configured for single-instance convolution supporting INT8/INT16/FP16 data typesSearch in Eureka ↗
32 Adds: PVA configured to accelerate computer vision algorithms comprising RISC core, DMA circuit, and vector processorSearch in Eureka ↗
33 Further: DMA circuit supports at least six dimensions of addressingSearch in Eureka ↗
34 Further: vector processor configured to perform semi-dense or dense regular computationSearch in Eureka ↗
4 SoC for AV: CPU + GPU with tensor instruction set (≥8 SMs, L1/L2) + PVA + DLA + memory; interoperate for object affordance perceptionSearch Claim 4 prior art ↗
5 Adds: CPU, GPU, PVA, and DLA structured for ASIL D Level 5 autonomous driving complianceSearch in Eureka ↗
6 Further: configured to provide navigator with route planner, control planner, and actuator interfaceSearch in Eureka ↗
35 Adds: CPU supporting virtualization comprises CPU cluster or CPU complexSearch in Eureka ↗
36 Further: CPU cluster performs serial work and includes multiple CPU cores and associated L2 cachesSearch in Eureka ↗
37 Further: CPU cluster includes at least eight CPU cores in coherent multi-processor configurationSearch in Eureka ↗
38 Further: simultaneous cluster operation with any combination of clusters activeSearch in Eureka ↗
39 Further: CPU cores organized as four dual-core clusters with dedicated L2 unified cacheSearch in Eureka ↗
40 Further: high-speed coherency fabric allowing heterogeneous multi-processing with all CPU coresSearch in Eureka ↗
41 Further: individual hardware blocks clock-gated automatically when idle with WFI/WFE core clock gatingSearch in Eureka ↗
42 Further: each core independently power-gatedSearch in Eureka ↗
43 Further: each core cluster independently clock-gated and all cores clock or power-gatedSearch in Eureka ↗
44 Further: each core cluster independently power-gated and all cores power-gatedSearch in Eureka ↗
45 Further: CPU cluster manages power states with specified allowed power states and hardware/microcode determining power statesSearch in Eureka ↗
46 Further: CPU cluster processing cores support simplified power state entry sequences with work offloaded to microcodeSearch in Eureka ↗
47 Adds: GPU power-optimized for automotive embedded use applicationsSearch in Eureka ↗
48 Further: GPU fabricated on FinFET high-performance manufacturing processSearch in Eureka ↗
49 Adds: processing blocks comprise FP32, FP64, INT32, Tensor Cores, instruction cache, warp scheduler, dispatch unit, Register FileSearch in Eureka ↗
50 Adds: processing blocks include independent parallel integer and floating-point data pathsSearch in Eureka ↗
51 Adds: each streaming processor includes combined L1 data cache and shared memory unitSearch in Eureka ↗
56 Adds: DLA includes one or more tensor processing unitsSearch in Eureka ↗
57 Further: tensor processing units configured for single-instance convolution supporting INT8/INT16/FP16 data typesSearch in Eureka ↗
58 Adds: PVA configured to accelerate computer vision algorithms comprising RISC core, DMA circuit, and vector processorSearch in Eureka ↗
26 SoC for AV: CPU + GPU + Level 3 cache shared by CPU and GPU + DLA + PVA + memory; interoperate to perform lane detectionSearch Claim 26 prior art ↗
27 Adds: L3 cache comprises write-back cache keeping track of cache lines in MEI statesSearch in Eureka ↗
28 Further: L3 cache comprises at least 4 MBSearch in Eureka ↗
29 SoC for AV: CPU + GPU with real-time ray tracing hardware acceleration + DLA + PVA + memory; interoperate to perform lane detectionSearch Claim 29 prior art ↗
52 SoC for AV: CPU + GPU + L3 cache + PVA + DLA + memory; interoperate for object perceptor perceiving object affordancesSearch Claim 52 prior art ↗
53 Adds: L3 cache comprises write-back cache keeping track of cache lines in MEI statesSearch in Eureka ↗
54 Further: L3 cache comprises at least 4 MBSearch in Eureka ↗
55 SoC for AV: CPU + GPU with ray tracing hardware acceleration + PVA + DLA + memory; interoperate for object perceptor perceiving object affordancesSearch Claim 55 prior art ↗
56 Adds: DLA includes one or more tensor processing unitsSearch in Eureka ↗
59 SoC for AV: CPU + GPU + PVA with RISC core, 6-dimension DMA, vector processor + DLA + memory; interoperate for object perceptorSearch Claim 59 prior art ↗
60 SoC for AV: CPU + GPU + PVA with vector processor for semi-dense or dense regular computation + DLA + memory; interoperate for object perceptorSearch Claim 60 prior art ↗
| Metric | This Application | Automotive / Semiconductor Norm |
|---|---|---|
| Total claims | 60 | 20 – 40 |
| Independent claim count | 8 | 2 – 5 |
| Dependent : Independent ratio | 6.50 : 1 | 4 – 8 : 1 |
| Method claims present? | No | Common |
| System / apparatus claims? | Yes — Claim 1 | Always |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The claims demonstrate exceptional specification depth — 62 figures and ~52,000 words of detailed description provide robust support for every hardware limitation — but the strategy of filing exclusively apparatus (SoC) claims creates a significant enforcement gap for the extensive software stack, virtualization architecture, and training pipeline described in the specification. Claims 1 and 4 are admirably broad in their preamble but introduce subtle scope limitations through the interoperation limitation requiring 'lane detection,' which a designer could argue excludes SoCs used only for object detection or path planning.
✅
Antecedent Basis
No antecedent basis issues were identified across the 60 claims. The independent claims introduce 'at least one CPU cluster,' 'at least one GPU,' 'at least one deep learning hardware-based accelerator,' and 'a programmable vision accelerator' with clean first-mention articles. Dependent claims consistently refer back to 'the at least one CPU cluster or CPU complex,' 'the at least one GPU,' and 'the at least one deep learning accelerator' — all correctly using definite articles after proper introduction. The use of 'at least one' throughout avoids singular/plural antecedent mismatches that commonly arise in hardware claims.
✅
Spec–Claim Consistency
Every structural limitation in the independent claims maps to specific figures and paragraphs. FIG. 8 and FIG. 9 directly support the CPU Complex (200), GPU Complex (300), and Acceleration Cluster (400) recited in Claim 1. FIG. 10 provides PVA block-diagram support for the 'programmable vision accelerator' limitation. FIG. 11 supports the hardware acceleration cluster memory architecture. The 'lane detection' and 'LIDAR sensor data' limitations of Claim 1's final clause are supported by FIG. 13 (AV control system) and the detailed description at column 22. No claim limitation appears unsupported by specific written description.
✅
Transition Word Usage
All independent and dependent claims use 'comprising' or 'including,' providing open-ended scope appropriate for a hardware platform patent where additional components (modems, GPS units, additional SoCs) will always be present in real-world implementations. The use of 'including' in Claim 1's preamble ('a system-on-a-chip for an autonomous vehicle including') is equivalent to 'comprising' in US practice. No closed 'consisting of' transitions are used, which is strategically correct given the expansive hardware ecosystem described in the specification. No missed opportunities for broader open-ended language are apparent.
✅
§112(f) Means-Plus-Function Risk
No 'means for' or 'step for' language appears in any of the 60 claims. The claims use functional result language ('configured to execute neural networks,' 'configured to process') attached to structural terms (DLA, PVA, GPU), which under post-Williamson v. Citrix analysis does not invoke §112(f) because the structural terms — Deep Learning Accelerator, Programmable Vision Accelerator — are defined in the specification with sufficient structural disclosure in FIGS. 8–11 to remove any §112(f) ambiguity. The term 'object perceptor' in Claims 4 and 52 could attract scrutiny, but it is tied to the SoC's hardware structure rather than presented as a standalone means element.
✅
§101 Eligibility Risk
The patent presents minimal §101 risk because all independent claims are directed to a physical, integrated system-on-a-chip — a concrete machine with specific structural components (CPU, GPU, DLA, PVA, memory interface). The claims do not recite abstract methods or mathematical relationships in isolation; the 'interoperate to process... camera sensor data and LIDAR sensor data to perform lane detection' limitation anchors the claims to a specific real-world application on specific hardware. Under Alice Step 1, the claims are directed to a machine, not an abstract idea. Under Step 2A, even if considered, the integration of DLA and PVA on a single chip to achieve ASIL-level functional safety is a specific technical improvement over prior art systems. No §101 rejections appear to have been issued during prosecution.
⚠️
Dependent Claim Fallback Quality
A redundancy problem reduces the practical value of the 52 dependent claims: Claims 7–16 (depending from Claim 1) are essentially mirrored by Claims 37–46 (depending from Claim 4 via Claim 35/36), covering identical CPU power management features (clock gating, power gating, wakeup time management) without adding genuinely distinct technical limitations. Similarly, Claims 27–28 (L3 cache specifics under Claim 26) are repeated as Claims 53–54 under Claim 52. This structural mirroring means that if Claim 1 is invalidated, Claims 7–16 fall with it, providing no additional protection that Claim 4's dependent chain doesn't already cover through a different structural path — a missed opportunity for claims addressing the virtualization architecture, safety supervisor layers (L1SS/L2SS/L3SS), or multi-SoC configurations independently.
⚠️
Abstract Quality
An examiner reading only the abstract may identify the hardware platform but miss the key novel contribution — the specific combination of CPU virtualization, GPU, DLA, and PVA on a single chip achieving ASIL D functional safety through redundant diverse processing paths. The abstract states the technology 'provides a platform for autonomous driving Levels 3, 4, and/or 5' and mentions 'System-on-a-Chip' but does not articulate the inventive mechanism of hardware-diverse redundancy (ASIL decomposition) or the interoperability of the four compute element types for lane detection. A competitor reading only the abstract would underestimate the scope and novelty of Claims 1 and 4.
⚠️
Figure Support Quality
Figure support for hardware structural limitations is exemplary — FIGs. 7–11 provide complete block-diagram support for every SoC component recited in Claims 1–60. However, the 'lane detection' interoperation limitation in Claims 1, 26, and 29 is supported only implicitly through the software system diagrams (FIGs. 41–42) and the AV control diagram (FIG. 13), with no dedicated figure showing the data flow from camera/LIDAR inputs through the DLA/PVA pipeline specifically resulting in lane detection output. A challenger could argue the lane detection limitation is not adequately shown as an integrated hardware function. The extensive software figures (FIGs. 41–64) have no corresponding hardware-level claim coverage, representing a missed alignment opportunity.
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Scorecard
Strategic Intent Scorecard
Multi-dimensional assessment of this application's patent strategy quality, based on claim structure, specification depth, and prosecution positioning.
Claim Breadth
3.8
Prosecution Defensibility
4
Spec–Claim Consistency
4.5
Dependent Claim Coverage
3
Claim Type Diversity
2
Figure Support Quality
4.2
Key observation: This patent scores highest on Spec-Claim Consistency (4.5/5.0) because the 62 drawing sheets provide exhaustive hardware block-diagram support for every component limitation in the 60 claims — an unusual level of drafting rigor for a complex SoC patent. The lowest score is Claim Type Diversity (2.0/5.0) because all 60 claims are apparatus (SoC) claims, leaving the entire autonomous driving software stack, hypervisor architecture, neural network training pipeline, and multi-vehicle operational methods without any direct method or computer-readable medium claim coverage — a significant design-around opportunity for competitors who implement the same functional architecture without directly manufacturing the described SoC. Practitioners should note that the specification contains substantial enablement for continuation method claims covering the L1SS/L2SS/L3SS safety supervision architecture, virtual machine partitioning, and the planning/perception/control software pipeline.
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
No method claims on software stack Lane detection limits Claim 1 scope Multi-SoC system apparatus unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 11,644,834 B2 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard