Book a demo

Patent Drafting Analysis of NVIDIA Corporation’s Object Detection and Confidence Scoring for Autonomous Driving | US 2019/0258878 A1

Patent Drafting Analysis of NVIDIA Corporation’s Object Detection and Confidence Scoring for Autonomous Driving | US 2019/0258878 A1
IP Drafting Analysis · US 2019/0258878 A1

Patent Drafting Analysis of NVIDIA Corporation's Object Detection Confidence Scoring for Autonomous Driving | US 2019/0258878 A1

A structural and strategic analysis of NVIDIA's dual-neural-network object detection confidence system, examining claim architecture, drafting quality signals, critical gaps, and prosecution positioning across 21 method claims.

US 2019/0258878 A1Filed: Feb 15, 2019Published: Aug 22, 2019G06K 9/00G06K 9/46G06K 9/62
Spec Words
18,500
Across 6 sections
Draft now ↗
Total Claims
21
3 independent · 18 dependent
Draft now ↗
Figure Sheets
20
System architecture, detection flow, training methods
Draft now ↗
Published by PatSnap Insights Team · · 14 min read Verified by PatSnap Eureka Data
Overview

Structural Overview

The detailed description dominates at approximately 82% of total words (~15,200 of ~18,500), reflecting NVIDIA's strategy of embedding extensive technical disclosure around autonomous vehicle hardware and software pipelines, though much of this bulk covers the AV platform (FIGs. 15A–15D) rather than the claimed inventions. The claim set comprises 21 total claims across 3 independent method claims (Claims 1, 7, and 14), yielding a dependent-to-independent ratio of 6:1. The 20 figure sheets provide robust coverage of both the confidence score pipeline and the ground truth generation system, with FIGs. 10A–13 directly supporting the method claims.

Section Word Distribution

Detailed Desc. 15200 w Claims 1050 w Summary 740 w Background 530 w Brief Desc. 420 w Abstract 108 w ↗ Click bars to explore

Figure Inventory — 20 Sheets

FigureDescriptionRole
FIG. 1A
Block diagram of object detection system 100, showing communications manager 104, object detector 106, detected object clusterer 108, feature determiner 110, confidence score generator 112, object tracker 114, and detected object filter 116.Search in Eureka ↗
System architecture
FIG. 1B
Flow diagram illustrating the end-to-end process 118 from object detector 106 through clusterer 108, feature determiner 110, confidence score generator 112 (MLP with nodes 140, 142), and object tracker 114.Search in Eureka ↗
Flow diagram
FIG. 2A
Illustration of image 204 overlaid with grid 210 and detected object regions 250A–250D showing bounding boxes and positive detection region 240 corresponding to object 248A.Search in Eureka ↗
Claim support
FIG. 2B
Illustration of the same scene with clustered detection regions 260A–260D and labeled objects 248A–248D, demonstrating aggregated detected object output.Search in Eureka ↗
Claim support
FIG. 3
Diagram of object detector 306 neural network output layer 330 showing parallel output heads: coverage (Cov 312), depth (314), orientation (316/318), bounding box (Bbox 310), bottom visibility (320), and width visibility (322) with their activation functions.Search in Eureka ↗
Key embodiment
FIG. 4
Block diagram of object detection training system 400 including shape determiner 402, coverage value determiner 404, active object selector 406, visibility determiner 408, orientation determiner 410, ground truth generator 412, and model trainer 414.Search in Eureka ↗
System architecture
FIG. 5A
Illustration of elliptical shape 504 within object region 506 overlaid on spatial element regions 510 grid, showing cells 512 (boundary) and 514 (interior) used for coverage value assignment.Search in Eureka ↗
Claim support
FIG. 5B
Three-stage illustration showing downscaling from original training image 520 through intermediate resolution 522 to network output resolution 524, demonstrating anti-aliased soft coverage value generation.Search in Eureka ↗
Claim support
FIG. 6
Illustration of spatial element regions 600 showing how coverage values 602 (Car A in back), 604 (Car B in front), and composed values 606 are determined when two overlapping objects correspond to the same spatial element region.Search in Eureka ↗
Claim support
FIG. 7
Illustration of dead-zone area 710 determination showing non-active object shape 712 and active object shape 714 with radii rc, rd, rb, demonstrating how overlapping shapes are spatially separated in ground truth data.Search in Eureka ↗
Claim support
FIG. 8A
Training image 800 of an automobile showing ground truth labels 804 (front marker 812) and 806 (side marker 814) within object region 808 used for object orientation determination.Search in Eureka ↗
Claim support
FIG. 8B
Orientation coordinate diagram showing angle convention (0° right only, +90° front only, -90° back only, ±180° left only) with vehicle 1500 reference for orientation regression target.Search in Eureka ↗
Other
FIG. 9
Visibility state illustration showing occluder 904 with object 906 (width partially covered, bottom visible, value 0.0) and occluder 908 with object 910 (whole width visible 1.0, bottom not visible) demonstrating binary visibility flag taxonomy.Search in Eureka ↗
Claim support
FIG. 10A
Flow diagram of method 1000A with four steps: B1002 determine detected object data, B1004 generate cluster, B1006 determine features for neural network inputs, B1008 receive confidence score from neural network.Search in Eureka ↗
Flow diagram
FIG. 10B
Flow diagram of method 1000B with two steps: B1010 apply sensor data to neural network, B1012 receive detected object data, supporting the detected object data determination step of FIG. 10A.Search in Eureka ↗
Flow diagram
FIG. 11
Flow diagram of method 1100 with four steps: B1102 compute shape size, B1104 assign coverage value, B1106 populate ground truth data, B1108 train machine learning model — directly supporting independent Claim 14.Search in Eureka ↗
Claim support
FIG. 12
Flow diagram of method 1200 with two steps: B1202 render shape at higher spatial resolution than ground truth tensor, B1204 downscale to provide anti-aliased coverage value — supporting Claim 17.Search in Eureka ↗
Flow diagram
FIG. 13
Flow diagram of method 1300 with two steps: B1302 determine first and second coverage values for competing object regions, B1304 assign coverage value based on first value being greater — supporting Claims 19 and 20.Search in Eureka ↗
Flow diagram
FIG. 14
Operating environment 1400 diagram showing server devices 1460, network 1440, client devices 1420, sensors 1480, and data stores 1450 illustrating deployment context for the object detection system.Search in Eureka ↗
System architecture
FIG. 15A
Detailed diagram of autonomous vehicle 1502 showing all sensor placements including stereo camera 1568, wide-view camera 1570, infrared camera 1572, surround camera 1574, radar 1560, lidar 1564, ultrasonic 1562, and vehicle control systems.Search in Eureka ↗
Other
FIG. 15B
Top-down view of vehicle 1500 showing fields of view for all cameras including long-range 1598, stereo 1568, surround 1574, wide-view 1570, infrared 1572, and mid-range wing-mirror-mounted cameras.Search in Eureka ↗
Other
FIG. 15C
Complete system architecture block diagram of vehicle 1500 showing SoC 1504 with CPUs 1506, GPUs 1508, processors 1510, caches 1512, accelerators 1514, data stores 1516, ADAS system 1538, and all sensor/actuator interfaces.Search in Eureka ↗
System architecture
FIG. 15D
Cloud server system 1576 diagram showing servers 1578 with GPU clusters 1584(A-H) interconnected via PCIe switches 1582 and NVLink 1588, communicating with vehicle 1500 over networks 1590 for neural network 1592 and map data 1594 updates.Search in Eureka ↗
System architecture
FIG. 16
Generic computing device 1600 block diagram showing bus 1602 connecting memory 1604, CPU(s) 1606, GPU(s) 1608, communication interface 1610, I/O ports 1612, I/O components 1614, power supply 1616, and presentation components 1618.Search in Eureka ↗
Other
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims

Claim Architecture Analysis

The patent presents 3 independent method claims (Claims 1, 7, and 14) covering two distinct technical contributions: a dual-neural-network confidence scoring pipeline (Claims 1 and 7) and a shape-based ground truth generation method for training object detectors (Claim 14). The dependent-to-independent ratio of 6:1 is below the software/AI industry norm of approximately 8–10:1, leaving meaningful prosecution fallback relatively thin. Notably, all claims are method claims only — there are no system, apparatus, or computer-readable medium claims — creating significant design-around exposure.

Core inventive concept: The patent addresses the problem that conventional confidence values for aggregated object detections (max coverage value or unbounded sum) cannot be directly interpreted as a probability, leading to false detections. The claimed solution uses a second, separately trained neural network (a multi-layer perceptron per Claim 8) that takes cluster features as inputs and outputs a bounded scalar confidence score representative of the probability that the cluster corresponds to a real object — a directly interpretable probabilistic measure. Claim 14 independently addresses a training improvement by computing a geometric shape (e.g., an ellipse) sized to the object region's dimensions and assigning shape-based coverage values (including soft/anti-aliased values) to multiple spatial element regions rather than hard binary values assigned to a single midpoint cell.

Independent Claim Dissection

ClaimPreambleTransitionKey Body Elements
Claim 1A methodcomprising
applying sensor data to a first neural network; receiving detected object data from first NN; generating cluster based on locations; determining cluster features as inputs to second neural network; receiving confidence score from second NN representative of probability cluster corresponds to object in environmentSearch prior art ↗
Claim 7A methodcomprising
determining detected object data from sensor data; generating cluster based on locations; determining cluster features as inputs to a neural network; receiving confidence score representative of probability cluster corresponds to object at least partially in field of viewSearch prior art ↗
Claim 14A methodcomprising
computing size of a shape within object region based on dimension of object region; assigning coverage value to spatial element region based on shape; populating ground truth data elements with coverage value and object region value; training neural network using ground truth dataSearch prior art ↗

Claim Dependency Tree

1 Method: apply sensor data to first NN → receive detected objects → generate cluster → determine features → receive confidence score from second NNSearch Claim 1 prior art ↗
2 Adds: tracking same object across sequential frames; computing at least one value; using value as cluster featureSearch in Eureka ↗
3 Adds: features based on variance of detected object regions of the clusterSearch in Eureka ↗
4 Adds: features based on vehicle state data from additional sensor dataSearch in Eureka ↗
5 Adds: features based on statistic of input pixels or CNN layer features of first neural networkSearch in Eureka ↗
6 Adds: generating cluster by clustering detected objects based on coverage values indicating likelihood of object correspondenceSearch in Eureka ↗
7 Method: determine detected object data from sensor data → generate cluster → determine features → receive confidence score from neural networkSearch Claim 7 prior art ↗
8 Adds: neural network is a multi-layer perceptron neural networkSearch in Eureka ↗
9 Adds: locations represented by outputs of a convolutional neural network determining locations from sensor dataSearch in Eureka ↗
10 Adds: sensor is of a vehicle; feature based on distance data of vehicle from object from additional sensorsSearch in Eureka ↗
11 Adds: feature based on coverage values of detected objects, each indicating likelihood of object depictionSearch in Eureka ↗
12 Adds: feature based on height, width, central location of detected object region, or number of detected objects in clusterSearch in Eureka ↗
13 Adds: feature based on at least one estimated parameter of ground plane in field of viewSearch in Eureka ↗
14 Method: compute shape size from object region dimension → assign coverage value based on shape → populate ground truth data → train neural networkSearch Claim 14 prior art ↗
15 Adds: shape is at least one of ellipse, rectangle, circle, or super-ellipseSearch in Eureka ↗
16 Adds: determining soft coverage value where spatial element region corresponds to boundary of shapeSearch in Eureka ↗
17 Adds: rendering shape at higher resolution than ground truth tensor then downscaling to produce anti-aliased coverage valuesSearch in Eureka ↗
18 Adds: populating ground truth with dead-zone area coverage values to spatially separate coverage values of adjacent objectsSearch in Eureka ↗
19 Adds: assigning coverage value based on it being greater than a soft coverage value for additional object region (active object selection)Search in Eureka ↗
20 Adds: assigning coverage value based on first object being closer in training image than second object (depth-based active object selection)Search in Eureka ↗
21 Adds: ground truth data further populated with distance value, orientation value, and/or visibility value of the objectSearch in Eureka ↗
MetricThis ApplicationSoftware / AI Industry Norm
Total claims2120 – 30
Independent claim count33 – 5
Dependent : Independent ratio6.00 : 15 – 9 : 1
Method claims present?Yes — Claims 1, 7, 14Always
System / apparatus claims?NoCommon
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality

Drafting Quality Signals

The patent's principal drafting strength lies in its rich specification support for the ground truth generation embodiments (Claims 14–21), where FIGs. 5A, 5B, 6, 7, 11, 12, and 13 directly map to specific claim limitations with corresponding paragraphs [0151]–[0196]. The most significant weakness is the absence of any system, apparatus, or computer-readable medium claims — a serious enforcement gap for a commercially deployed AI pipeline — which exposes NVIDIA to design-arounds that implement the same logic in hardware or system form.

Antecedent Basis
The claims are generally clean with respect to antecedent basis. Claim 2 references "the first detected object" and "the second detected object" which are properly introduced in the same claim's body. Claim 17 uses "the shape" (introduced in Claim 14's preamble body), "the ground truth data" (introduced in Claim 14), and "the coverage value" (introduced in Claim 14) — all properly established. No floating "the" references were identified across the 21 claims that would create §112 indefiniteness risk.
Spec–Claim Consistency
The specification robustly supports the independent claims. FIG. 1B and paragraphs [0053], [0078]–[0079] directly support Claim 1's dual-neural-network architecture (first NN = object detector 106, second NN = confidence score generator 112). FIG. 11 and paragraph [0186]–[0190] map step-by-step to the four limitations of Claim 14 (B1102→computing shape size; B1104→assigning coverage value; B1106→populating ground truth; B1108→training). FIG. 5B and paragraphs [0159]–[0160] support the anti-aliased downscaling of Claim 17, naming both the higher-resolution rendering step and the downscaling ratio explicitly.
Transition Word Usage
All three independent claims use "comprising" as the transition word, which is the broadest possible open-ended transition, correctly preserving coverage against implementations that include additional steps. This is particularly important for Claims 1 and 7, which do not recite filtering or tracking steps as required steps — those are left to dependent claims (e.g., Claim 2 adds tracking), keeping the independent claims broad. No missed opportunity for "consisting essentially of" is identified as that narrower transition would not benefit these AI method claims.
⚠️
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in the claims, which avoids the classic §112(f) trap. However, Claim 14 uses functional language — "assigning a coverage value to a spatial element region... based at least in part on the spatial element region corresponding to a portion of the shape" — without structural recitation of how this assignment occurs. While this does not trigger §112(f), an examiner could challenge this as indefinite under §112(b) if "portion of the shape" is read as ambiguous for cases where a spatial element only marginally intersects a shape boundary. Paragraph [0158] and FIG. 5A provide supporting context but the claim language itself leaves the threshold ambiguous.
⚠️
§101 Eligibility Risk
Claims 1 and 7 face moderate Alice/Mayo exposure because at their core they recite abstract steps of data processing (generating a cluster, determining features, receiving a score). The §101 defense rests on Claims 1 and 7's tie to sensor data "representative of a field of view of at least one sensor of a vehicle in an environment" — but this environmental anchor is weak because it does not require any physical action on the environment. Claim 14's shape-based coverage value computation is more concrete, analogous to image rendering operations. A stronger filing would have included system claims anchored to processor hardware executing the steps, or recited specific physical hardware components as structural limitations.
⚠️
Dependent Claim Fallback Quality
The dependent claims under Claim 14 add meaningfully distinct fallback positions: Claim 16 (soft/boundary coverage values), Claim 17 (anti-aliased downscaling), Claim 18 (dead-zone area), Claims 19 and 20 (active object selection by coverage magnitude and depth respectively), and Claim 21 (distance/orientation/visibility ground truth). However, Claims 1 and 7 have a significant structural problem: many of their dependents (Claims 3, 11, 12) add essentially parallel feature-type limitations that a competitor could avoid by simply using different feature types, and Claims 1 and 7 themselves overlap substantially — Claim 7 is broader than Claim 1 (removes the dual-NN requirement) but the dependents under each are not differentiated accordingly.
⚠️
Abstract Quality
The abstract describes the confidence score mechanism and the ground truth training approach but does so using permissive hedging language: "may be determined," "may be generated," "may be received" — language that fails to convey which limitations are required. Critically, the abstract omits the key distinguishing mechanism of Claim 1 — the use of a separate second neural network (distinct from the object detector) to compute the bounded confidence score. An examiner reading only the abstract might classify this as a generic clustering-and-scoring patent, missing the dual-NN architecture that is the core inventive distinction over prior art.
Figure Support Quality
Figure support for the two claimed technical contributions is comprehensive. FIGs. 1A and 1B support the system architecture and process flow of Claims 1 and 7; FIGs. 2A/2B visually demonstrate the clustering step; FIG. 3 supports the first neural network (object detector) architecture; and FIGs. 10A/10B provide direct step-by-step flow diagram support for Claims 1 and 7. For Claim 14, FIGs. 4, 5A, 5B, 6, 7, 11, 12, and 13 collectively cover every limitation and all dependent claim fallbacks. The one gap is the absence of a figure specifically illustrating the confidence score generator as a standalone MLP network distinct from the object detector, though FIG. 1B partially addresses this with nodes 140 and 142.
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.5
Prosecution Defensibility
3
Spec–Claim Consistency
4.2
Dependent Claim Coverage
3.8
Claim Type Diversity
1.5
Figure Support Quality
4
Breadth Prosecution Consistency Dep. Coverage Claim Types Figures
Key observation: The strongest dimension is Spec–Claim Consistency (4.2/5): virtually every limitation in the independent and dependent claims maps directly to a named figure element and numbered paragraph, a reflection of NVIDIA's thorough technical documentation practice. The weakest dimension is Claim Type Diversity (1.5/5): all 21 claims are method claims, leaving the system/apparatus and computer-readable medium dimensions entirely unclaimed — a practitioner reading this patent should immediately file continuation applications covering system claims reciting the object detection system 100 as a hardware-configured apparatus and CRM claims, as competitors can currently implement this exact pipeline in a product without infringing any claim if they do not perform the steps themselves.
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 apparatus or CRM claims filed Trained model artifact not covered Confidence scorer training method unclaimed
Unlock Full Analysis — Free
Frequently asked questions

US 2019/0258878 A1 — key questions answered

Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
PatSnap Eureka

Ready to Draft Your Next Patent with AI?

PatSnap Eureka's AI drafting agent writes structured claims, flags coverage gaps, and positions your application for prosecution success.

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.
Powered by PatSnap Eureka
Link copied to clipboard

Help us improve this page

Found incorrect or outdated information? Let us know and we'll get it fixed.