Patent Drafting Analysis of NVIDIA Corporation’s Real-Time Lane Detection by Autonomous Vehicles | US 10,997,433 B2
Patent Drafting Analysis of NVIDIA Corporation's Real-Time Lane and Boundary Detection Patent | US 10,997,433 B2
A structural and strategic analysis of NVIDIA's granted autonomous vehicle lane detection patent, examining claim architecture, drafting quality, dependency structure, prosecution positioning, and critical coverage gaps across 22 claims.
Spec Words
18,400
Across 6 sections
Draft now ↗
Total Claims
22
3 independent · 19 dependent
Draft now ↗
Figure Sheets
22
System architecture, neural network models, training flows, annotation methods, autonomous vehicle hardware
Draft now ↗
Published by PatSnap Insights Team · · 13 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 79% of total words (~14,500 of ~18,400), reflecting NVIDIA's thorough technical disclosure strategy with extensive autonomous vehicle system context. The claim set comprises 22 claims — 3 independent method claims and 19 dependent claims — providing a method-only claim architecture that leaves apparatus and system claim types unprotected. The 22 drawing sheets provide comprehensive coverage spanning neural network architectures (FIGS. 1B–1C), training pipelines (FIGS. 3A–3D, 4A–4D), annotation methods (FIGS. 5A–6E), performance evaluation (FIGS. 7A–7C), and vehicle system context (FIGS. 8A–9).
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 22 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1A | Data flow diagram illustrating the end-to-end lane and road boundary detection process including sensor data pre-processor (104), machine learning models (108), segmentation mask (110), resampling (112), DCC (114), dynamic programming (116), lane assignment (118), curve fitting (120), and planning layer (124).Search in Eureka ↗ | System architecture |
| FIG. 1B | Illustration of an example machine learning model (108A) showing convolutional streams (132) with layers 134A–134C and deconvolutional layers (136A–136B) producing segmentation masks (110).Search in Eureka ↗ | Key embodiment |
| FIG. 1C | Detailed illustration of the convolutional neural network (108B) showing layer-by-layer spatial resolution down-sampling from 480×252 input through layers 134A–134M and final deconvolutional output layer (135A, 140) at 240×128.Search in Eureka ↗ | Key embodiment |
| FIG. 2 | Flow diagram of method 200 for detecting lanes and road boundaries, showing steps B202 (receive sensor data) through B212 (send data to vehicle component for navigation).Search in Eureka ↗ | Flow diagram |
| FIG. 3A | Data flow diagram of process 300 for training machine learning model(s) showing input images (302), labels (308), down-sampling (304), cropping (306), data mini-batch (314), online data augmentation (316), and loss function (318).Search in Eureka ↗ | System architecture |
| FIG. 3B | Data flow diagram (process 320) illustrating generation of training images through down-sampling stages (324A, 326A) and ROI cropping (324B, 326B) to form mini-batch halves 328A and 328B.Search in Eureka ↗ | Claim support |
| FIG. 3C | Data flow diagram showing machine learning model (108) trained simultaneously with multi-class mask head (332, 332A–332C) and binary mask head (334) outputs from input image (322).Search in Eureka ↗ | Key embodiment |
| FIG. 3D | Flow diagram of method 340 for training a neural network using transformed images and transformed labels as ground truth data, covering steps B342 through B350.Search in Eureka ↗ | Flow diagram |
| FIG. 4A | Illustration of process 400 for generating ground truth data showing full-resolution images (410A, 410B) with polygon (470), down-sampled polygon (472) producing binary masked image (414), and cropped ROI image (416) with binary mask (418).Search in Eureka ↗ | Claim support |
| FIG. 4B | Illustration of process 420 showing online data augmentation of ground truth masks, with zoom-out transformation producing transformed polygon (476), augmented ground truth mask (424), and padded image (426).Search in Eureka ↗ | Claim support |
| FIG. 4C | Flow diagram of method 440 for training a neural network using down-sampled images, covering steps B442 through B452 including first/second image resolution transformations and vertex data transformations for polygon generation.Search in Eureka ↗ | Flow diagram |
| FIG. 4D | Flow diagram of method 460 for training using cropped images, covering steps B462 through B468 including determining crop portion, masking polygon and crop portions to generate masked image, and training neural network.Search in Eureka ↗ | Flow diagram |
| FIG. 5A | Illustration of process 500 for annotating road boundaries showing first vertices (502A–502D), first polylines (516A–516C), second vertices (504A–504D), second polylines (522A–522C), third polylines (524A–524C), and resulting polygons (520A–520C) with right angle indicator (518).Search in Eureka ↗ | Claim support |
| FIG. 5B | Illustration of an example road boundary annotation (510) showing lines 512 and 514 as ground truth polygon annotations on a road scene with a vehicle.Search in Eureka ↗ | Claim support |
| FIG. 5C | Flow diagram of method 540 for annotating road boundaries for ground truth generation, covering steps B542 through B544E including polygon generation sub-steps for first/second vertices and polyline generation.Search in Eureka ↗ | Flow diagram |
| FIG. 6A | Illustration of crosswalk and intersection annotation (600) showing crosswalk solid polygon lines (602A–602E) and intersection dotted polygon lines (604A–604D) as separate class annotations.Search in Eureka ↗ | Claim support |
| FIG. 6B | Diagram illustrating lane merge annotation (622) showing merge point 622C where lane markings 622A and 622B converge, labeled as Attribute: Merge.Search in Eureka ↗ | Claim support |
| FIG. 6C | Diagram illustrating a second lane merge annotation example (624) with merge point 624B where lane marking 624A ends, labeled as Attribute: Merge.Search in Eureka ↗ | Claim support |
| FIG. 6D | Diagram illustrating lane split annotation (626) showing split point 626C where lane markings 626A and 626B diverge, labeled as Attribute: Split.Search in Eureka ↗ | Claim support |
| FIG. 6E | Diagram illustrating a second lane split annotation example (628) with split point 628C where lane marking 628A ends, labeled as Attribute: Split.Search in Eureka ↗ | Claim support |
| FIG. 7A | Illustration of performance calculation regions (700) showing vehicle with three evaluation zones: close view area (702, 702A), mid view area (704, 704A), and far view area (706) with lane lines (708).Search in Eureka ↗ | Other |
| FIG. 7B | Illustration (720) of 2D KPI measurement showing precision computation and recall computation with ground truth polylines (722A–722D), detection polylines (724A–724D), and true positive (TP) and false positive (FP)/false negative (FN) areas.Search in Eureka ↗ | Other |
| FIG. 7C | Data flow diagram (730) of 3D KPI measurement pipeline showing detection pipeline with machine learning model (108) and ground truth pipeline, both feeding Lane KPI Calculation (748) to produce MMD (750A), success rate (750B), and miss rate (750C) outputs.Search in Eureka ↗ | Other |
| FIG. 8A | Illustration of autonomous vehicle (800) showing the external placement of sensors including stereo camera (868), wide view camera (870), infrared camera (872), surround cameras (874), ultrasonic sensors (862), radar sensors (860), lidar sensors (864), and various other sensors and actuators.Search in Eureka ↗ | System architecture |
| FIG. 8B | Top-down illustration showing camera locations and fields of view for autonomous vehicle (800), including stereo cameras (868), wide view camera (870), infrared camera (872), surround cameras (874), and long/mid-range cameras (898) coverage zones.Search in Eureka ↗ | System architecture |
| FIG. 8C | Block diagram of system architecture for autonomous vehicle (800) showing SoC 804(A) with CPU(s) (806), GPU(s) (808), processors (810), cache(s) (812), accelerators (814), data stores (816), connected to sensors, controllers (836), ADAS system (838), and vehicle actuation systems.Search in Eureka ↗ | System architecture |
| FIG. 8D | System diagram (876) for cloud-based server(s) (878) communication with autonomous vehicle (800), showing server GPU clusters (884A–884H) connected via PCIe switches (882) and CPUs (880), networked to vehicle with map data (894) and neural networks (892).Search in Eureka ↗ | System architecture |
| FIG. 9 | Block diagram of example computing device (900) suitable for implementing the disclosed methods, showing bus (902) connecting memory (904), CPU(s) (906), GPU(s) (908), communication interface (910), I/O ports (912), I/O components (914), power supply (916), and presentation components (918).Search in Eureka ↗ | System architecture |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Claims
Claim Architecture Analysis
The patent contains 3 independent claims — all method claims (Claims 1, 15, and 20) — with no apparatus, system, or computer-readable medium claims filed, creating significant enforcement gaps. The dependent-to-independent ratio of 6.33:1 is above the software/AI norm for this IPC class, indicating reasonably layered fallback positions. The exclusive reliance on method claim types represents a deliberate but potentially limiting strategy, as a competitor practicing the same invention via a system or non-transitory computer-readable medium would not be directly captured by the issued claims.
Core inventive concept: Claim 1 solves the problem of computationally expensive and inaccurate real-time lane detection by applying sensor data to a neural network that computes a multi-class segmentation mask representing both a first and second lane marking type simultaneously, then determining lane edges from that mask, performing curve fitting to generate final lane edges, assigning lane types relative to vehicle position, and using the result to perform vehicle operations — all in real time. Claim 15 addresses ground truth annotation efficiency by generating variable-width polygons from vertex geometry that narrows with distance from image bottom, while Claim 20 covers the training augmentation method of applying corresponding spatial/color transformations to both images and annotations.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method comprising | comprising | receiving sensor data from at least one vehicle sensor; applying to a neural network; computing multi-class segmentation mask for at least first and second lane marking types; determining lane edges from the mask; performing curve fitting to generate final lane edges; identifying lane type for each final lane edge based on relative location to vehicle; performing vehicle operations based on final lane edges and lane typesSearch prior art ↗ |
| Claim 15 | A method comprising | comprising | receiving image data of an environment; generating a polygon by identifying first vertices corresponding to a boundary, generating first polylines between adjacent first vertices, generating second vertices adjacent to first vertices spaced perpendicular to first polylines, generating second polyline between second vertices, generating third polylines between corresponding first and second vertices; training a neural network using image data and the polylines as ground truth dataSearch prior art ↗ |
| Claim 20 | A method comprising | comprising | receiving image data of a driving surface; receiving annotations for lane markings or boundaries; applying one or more first transformations to generate transformed image; applying corresponding second transformations to annotations to generate transformed annotations; using image, annotations, transformed image, and transformed annotations as ground truth to train neural network to identify pixels corresponding to lane markings or boundariesSearch prior art ↗ |
Claim Dependency Tree
1 Method: receive sensor data, apply to neural network, compute multi-class segmentation mask, determine lane edges, curve fit, assign lane types, perform vehicle operationsSearch Claim 1 prior art ↗
2 Adds: batching first and second versions of image before applying to neural networkSearch in Eureka ↗
3 Adds: portions of image are pixels, mask further represents each pixel corresponding to first or second lane marking typeSearch in Eureka ↗
4 Adds: lane marking types include dashed line, solid line, yellow line, white line, intersection line, crosswalk line, or lane split lineSearch in Eureka ↗
5 Adds: determining lane edges by analyzing points unilaterally, determining if adjacent point is same lane marking type, grouping same lane marking type pointsSearch in Eureka ↗
6 Adds: determining lane edges by analyzing points unilaterally based on same lane appearance (not marking type) and grouping same lane appearance pointsSearch in Eureka ↗
7 Adds: determining lane edges via dynamic programming — significant points with confidence values, connectivity scores between pairs, candidate edges, clustering algorithmsSearch in Eureka ↗
8 Adds: curve fitting comprises at least one of polyline fitting, polynomial fitting, or clothoid fittingSearch in Eureka ↗
9 Adds: neural network includes plurality of convolutional layers and at least one deconvolutional output layerSearch in Eureka ↗
10 Adds: sensor data further representative of additional image that is a cropped version of the imageSearch in Eureka ↗
11 Adds: image is down-sampled version of original image, and sensor data further includes cropped version of original imageSearch in Eureka ↗
12 Adds: multi-class segmentation mask further representative of confidence scores corresponding to probability of each portion corresponding to first or second lane marking typeSearch in Eureka ↗
13 Adds: neural network is trained using a region based weighted loss functionSearch in Eureka ↗
14 Further: region based weighted loss function results in back-propagation of more error at further distances from bottom of image (depends on Claim 13)Search in Eureka ↗
15 Method: receive image data of environment, generate polygon from boundary vertices using perpendicular-spaced second vertices, train neural network using polylines as ground truthSearch Claim 15 prior art ↗
16 Adds: spacing between second and first vertices based on distance of first vertices from bottom of imageSearch in Eureka ↗
17 Adds: second vertices spaced closer to first vertices as distance of first vertices from bottom of image increasesSearch in Eureka ↗
18 Adds: each second vertex is generated based on slope of a previous first polylineSearch in Eureka ↗
19 Adds: further comprising generating a line segment from each polygon, masking out to generate masked out line segment, using masked out line segment as ground truthSearch in Eureka ↗
20 Method: receive image data of driving surface, receive annotations, apply first transformations, apply corresponding second transformations to annotations, use all as ground truth to train neural networkSearch Claim 20 prior art ↗
21 Adds: first transformations include one or more of a spatial transformation or a color transformationSearch in Eureka ↗
22 Adds: at least one first transformation and at least one second transformation are a same transformationSearch in Eureka ↗
| Metric | This Application | Software / AI / Autonomous Driving Norm |
|---|---|---|
| Total claims | 22 | 20 – 30 |
| Independent claim count | 3 | 3 – 5 |
| Dependent : Independent ratio | 6.33 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claims 1, 15, 20 | Always |
| System / apparatus claims? | No | Common |
Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent
Drafting Quality
Drafting Quality Signals
The claim set demonstrates strong technical specificity — Claim 1's multi-class segmentation mask limitation with explicit first and second lane marking types provides a well-defined inventive hook, and the region-based weighted loss function limitations in Claims 13–14 add meaningful prosecution fallback. The principal weakness is the complete absence of apparatus, system, and computer-readable medium claims, leaving the entire claim set vulnerable to design-around via hardware implementations or non-method embodiments not explicitly covered.
✅
Antecedent Basis
The claim set is clean on antecedent basis. In Claim 1, "the sensor data," "the neural network," "the multi-class segmentation mask," and "the lane edges" all have proper antecedents introduced earlier in the claim. Claims 2–14, which depend on Claim 1, consistently use "the" references (e.g., "the sensor data," "the neural network") that trace back correctly. Claims 15–19 and 20–22 similarly maintain clean antecedent basis chains within their respective dependency groups. No §112(b) indefiniteness risks from missing antecedents were identified.
✅
Spec–Claim Consistency
Strong mapping exists between the independent claims and specific figures and paragraphs. FIG. 1A and the detailed description directly support the core pipeline of Claim 1 (sensor data → neural network → segmentation mask → lane edges → curve fitting → lane assignment → vehicle operations). FIG. 3C and paragraphs describing multi-class mask head (332) and binary mask head (334) directly support the multi-class segmentation mask limitation. FIG. 5A and accompanying paragraphs support Claim 15's polygon generation with perpendicular-spaced second vertices. FIGS. 3D and 4A–4B support Claim 20's augmentation methodology. No claim limitations were identified without corresponding specification support.
✅
Transition Word Usage
All 22 claims use "comprising" as the transition, which is the correct open-ended choice for method claims in the autonomous driving/AI space where downstream steps may be added without negating infringement. The use of "comprising" throughout is strategically appropriate and consistent. No use of "consisting of" or "consisting essentially of" was found, and no narrowing transition words were misapplied. One missed opportunity is that Claim 1's preamble "A method comprising" is maximally broad but could benefit from a corresponding system claim using "comprising" to capture apparatus implementations.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language is used anywhere in the 22 claims, avoiding §112(f) invocation entirely. Claim 7 uses functional language ("determining significant points," "determining a connectivity score") but these are method steps reciting specific technical actions rather than means-plus-function elements. Claim 9's "at least one output layer including a deconvolutional layer" provides structural identification, further reducing any §112(f) exposure. The prosecution-safe avoidance of means-plus-function language throughout is a positive drafting choice for this technology space.
⚠️
§101 Eligibility Risk
Claims 1, 15, and 20 all recite methods that involve mathematical operations (curve fitting, connectivity scores, weighted loss functions) and data manipulation steps that could face Alice/Mayo scrutiny as abstract ideas. The key §101 defense for Claim 1 is the physical integration requirement — "receiving, from at least one sensor of a vehicle" and "performing one or more operations by the vehicle" — which ties the claim to a real-world autonomous vehicle system. Claims 15 and 20, however, are framed as purely computational training methods without an explicit hardware anchor, making them more vulnerable to a §101 rejection if asserted in covered business method proceedings or challenged by a sophisticated examiner. A stronger filing would have added explicit processor or non-transitory medium claims to provide a hardware tie-in fallback.
✅
Dependent Claim Fallback Quality
The dependent claims add genuinely distinct and technically meaningful fallback positions. Claim 7 (dynamic programming with connectivity scores and clustering) adds substantial technical specificity over Claim 1's base limitation. Claims 13 and 14 introduce the region-based weighted loss function and its distance-penalizing behavior — a commercially distinct training technique. Claim 2's batching limitation and Claims 10–11's multi-resolution image handling each carve out specific deployment scenarios. However, Claims 5 and 6 are somewhat redundant — both add DCC-style directional analysis but differ only in whether grouping is by "lane marking type" (Claim 5) versus "lane appearance" (Claim 6), a distinction that may be difficult to enforce in practice.
⚠️
Abstract Quality
The abstract fails to identify the specific novel contribution of the patent — it describes the general process of applying sensor data to a machine learning model to compute a segmentation mask and perform curve fitting, but omits the distinctive multi-class segmentation mask with lane marking type classification that distinguishes the invention from prior art. An examiner reading only the abstract may characterize this as conventional image processing with a neural network, missing the key advancement of the region-based weighted loss function (Claims 13–14) and the variable-width polygon annotation method (Claim 15). A stronger abstract would have explicitly named the multi-class segmentation mask's role in real-time lane type identification.
✅
Figure Support Quality
Figure support is comprehensive across all claim limitations. FIG. 1A supports the complete pipeline of Claim 1, and FIG. 1C specifically supports Claim 9's convolutional layers and deconvolutional output layer architecture. FIG. 3C directly illustrates the multi-class mask head (332) and binary mask head (334) supporting the multi-class segmentation mask limitation. FIG. 5A with its labeled second vertices (504A–504D) perpendicular to first polylines (516) directly maps to Claim 15's core limitations. FIGS. 4A–4B support Claims 10 and 11's down-sampled and cropped image limitations. The 22 drawing sheets provide unusually thorough coverage for a software/AI patent, with no identified claim limitations lacking figure support.
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.8
Spec–Claim Consistency
4.8
Dependent Claim Coverage
4
Claim Type Diversity
1.5
Figure Support Quality
4.8
Key observation: This patent scores highest on Spec–Claim Consistency (4.8/5) and Figure Support Quality (4.8/5) — every claim limitation in Claims 1, 15, and 20 maps to a named figure and specific paragraph, reflecting NVIDIA's thorough technical disclosure culture. The critical weakness is Claim Type Diversity (1.5/5): all 22 claims are method claims, leaving apparatus, system, and computer-readable medium claim types completely unprotected — a competitor deploying this invention via an NVIDIA-chip-based system in an autonomous vehicle is not directly captured by any issued claim. Practitioners analyzing FTO for competitors should note that the method-only filing creates substantial white space for non-infringing system-level implementations.
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 system claims filed Training claims lack §101 hardware anchor No real-time performance temporal limitations
Unlock Full Analysis — Free Frequently asked questions
US 10,997,433 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