Patent Drafting Analysis of Tesla’s 3D Feature Prediction for Autonomous Driving | US 2020/0249685 A1
Patent Drafting Analysis of Tesla's 3D Trajectory Prediction for Autonomous Driving | US 2020/0249685 A1
A structural and strategic analysis of Tesla's machine-learning-based 3D feature prediction patent, covering claim architecture, drafting quality signals, critical gaps, and prosecution positioning across all 20 claims.
Spec Words
6,200
Across 5 sections
Draft now ↗
Total Claims
20
3 independent · 17 dependent
Draft now ↗
Figure Sheets
6
System block diagram, flow diagrams, real-world lane imagery
Draft now ↗
Published by PatSnap Insights Team · · 11 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 62% of total specification words (~4,800 words), with the claims section contributing a significant ~25% at roughly 1,900 words — a ratio indicating reasonable claim elaboration relative to specification depth. The claim architecture comprises 20 claims total: 3 independent claims (Claims 1, 19, and 20) covering system, CRM, and method formats respectively, supported by 17 dependent claims that cascade predominantly from Claim 1. The 6 figure sheets provide a mix of system block diagram (FIG. 1), process flow diagrams (FIGS. 2–4), and real-world road imagery (FIGS. 5–6), though coverage of the neural network architecture itself is notably absent.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 6 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram of deep learning system 100 showing sensors 101, image pre-processor 103, deep learning network 105, AI processor 107, vehicle control module 109, and network interface 111 communicatively connected.Search in Eureka ↗ | System architecture |
| FIG. 2 | Flow diagram of the end-to-end process for training and applying a machine learning model for autonomous driving, covering steps 201–211 from data preparation through vehicle control.Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Flow diagram of the training data creation process using a time series of sensor elements, covering steps 301–307 from receiving time series elements through packaging training data with ground truth.Search in Eureka ↗ | Flow diagram |
| FIG. 4 | Flow diagram illustrating the inference and data transmission process steps 401–411, including sensor data receipt, pre-processing, deep learning analysis, vehicle control, and transmitting sensor and related data for training.Search in Eureka ↗ | Flow diagram |
| FIG. 5 | Real road image 500 showing lane lines 501 and 511 with labeled portions 503/513, 505/515, 507/517 corresponding to time series locations A, B, and C, illustrating the ground truth determination process.Search in Eureka ↗ | Claim support |
| FIG. 6 | Real road image 600 showing the output of the trained model: predicted three-dimensional trajectories of lane lines 601 and 611 overlaid as curves, including distant portions 621, demonstrating the 3D prediction result.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 application presents 3 independent claims: Claim 1 is a system/apparatus claim, Claim 19 is a computer program product (CRM) claim, and Claim 20 is a method claim — providing tripartite structural coverage. The dependent:independent ratio of 5.67:1 is below the typical 7–10:1 norm for autonomous driving software patents in the G05D/G06K class, and the 17 dependent claims cascade almost entirely from Claim 1, leaving Claims 19 and 20 without any dependent narrowing. The claim strategy appropriately mirrors the core functionality across system, CRM, and method types, but the absence of dependent claims on Claims 19 and 20 creates prosecution vulnerability if Claim 1 is narrowed.
Core inventive concept: The independent claims address the problem of inaccurate lane detection from single 2D camera images by employing a trained machine learning model that predicts a "three-dimensional trajectory of a machine learning feature" (Claim 1) or specifically "a vehicle lane" (Claims 19 and 20) from image data, then using that 3D trajectory to automatically control the vehicle — solving the occlusion and elevation-loss problem inherent in 2D segmentation approaches.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A system | comprising | a processor configured to: receive image data from vehicle camera, use image data as input to trained ML model to predict 3D trajectory of a machine learning feature, provide 3D trajectory for automatic vehicle control; a memory coupled to processor providing instructionsSearch prior art ↗ |
| Claim 19 | A computer program product, the computer program product being embodied in a non-transitory computer readable storage medium | comprising | computer instructions for: receiving image data from vehicle camera, using image data as input to trained ML model to predict 3D trajectory of a vehicle lane, providing 3D trajectory of vehicle lane for automatic vehicle controlSearch prior art ↗ |
| Claim 20 | A method | comprising | receiving image data from vehicle camera, using image data as input to trained ML model to predict 3D trajectory of vehicle lane, providing 3D trajectory of vehicle lane for automatic vehicle controlSearch prior art ↗ |
Claim Dependency Tree
1 System: processor receives camera image data, applies trained ML model to predict 3D trajectory of machine learning feature, controls vehicleSearch Claim 1 prior art ↗
2 Adds: machine learning feature is associated with a vehicle lane lineSearch in Eureka ↗
3 Adds: portions of 3D trajectory of vehicle lane line are occluded in the image dataSearch in Eureka ↗
4 Adds: processor further configured to use vehicle lane line to identify vehicle lane occupied by the vehicleSearch in Eureka ↗
5 Further: (depends on Claim 4) vehicle lane is used to identify a drivable spaceSearch in Eureka ↗
6 Further: (depends on Claim 5) identified drivable space is used to maintain vehicle in the vehicle laneSearch in Eureka ↗
7 Adds: camera includes at least one of: front-facing, side-facing, or rear-facing cameraSearch in Eureka ↗
8 Adds: predicted 3D trajectory is one of a plurality of identified potential trajectoriesSearch in Eureka ↗
9 Adds: (depends on Claim 8) predicted trajectory has highest probability of occurring among pluralitySearch in Eureka ↗
10 Adds: training data includes a selected time series element in a group of time series elementsSearch in Eureka ↗
11 Adds: (depends on Claim 10) training data further includes related set of odometry data associated with group of time series elementsSearch in Eureka ↗
12 Adds: (depends on Claim 11) at least a portion of training data is automatically labeled a corresponding ground truthSearch in Eureka ↗
13 Adds: controlling vehicle includes adjusting speed and steeringSearch in Eureka ↗
14 Adds: 3D trajectory is represented by a splineSearch in Eureka ↗
15 Adds: 3D trajectory is represented by one or more piecewise polynomialsSearch in Eureka ↗
16 Adds: machine learning feature is associated with a predicted path of a second vehicleSearch in Eureka ↗
17 Adds: (depends on Claim 16) predicted path used to determine whether second vehicle is likely to enter lane occupied by controlled vehicleSearch in Eureka ↗
18 Adds: (depends on Claim 17) controlling vehicle includes adjusting speed or steering to avoid collision with second vehicleSearch in Eureka ↗
19 CRM: non-transitory medium with instructions to receive camera image data, apply ML model to predict 3D trajectory of vehicle lane, control vehicleSearch Claim 19 prior art ↗
20 Method: receiving camera image data, using data as ML model input to predict 3D trajectory of vehicle lane, providing trajectory for vehicle controlSearch Claim 20 prior art ↗
| Metric | This Application | Software / AI Autonomous Driving Norm |
|---|---|---|
| Total claims | 20 | 18 – 30 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.67 : 1 | 6 – 10 : 1 |
| Method claims present? | Yes — Claim 20 | Always |
| 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 patent demonstrates notable breadth in Claim 1's preamble — reciting only 'a processor configured to' receive camera data, apply a trained ML model for 3D trajectory prediction, and control a vehicle — achieving broad coverage without over-specifying the network architecture. However, the complete absence of dependent claims on independent Claims 19 and 20 represents a significant prosecution risk, as any narrowing of Claim 1 during examination will force the applicant to narrow all three claim types simultaneously with no dependent fallback on the CRM or method branches.
✅
Antecedent Basis
The claim set is largely clean on antecedent basis, with proper introduction of "a trained machine learning model" in Claims 1, 19, and 20 followed by correct subsequent reference to "the trained machine learning model" in dependent claims. Claim 2 correctly references "the machine learning feature" introduced in Claim 1, and the chain through Claims 3–6 maintains consistent reference to "the vehicle lane line" introduced at Claim 2. The one minor concern is Claims 19 and 20 independently introduce "a trained machine learning model trained to predict a three-dimensional trajectory of a vehicle lane" — slightly narrower in scope than Claim 1's "machine learning feature" — but both are self-consistent.
✅
Spec–Claim Consistency
The core limitations of Claim 1 — camera image input, trained ML model, 3D trajectory prediction, vehicle control output — map directly to FIG. 1 (system architecture with sensors 101, deep learning network 105, vehicle control module 109) and are elaborated across paragraphs [0016]–[0021]. The dependent claims for spline representation (Claim 14) and piecewise polynomials (Claim 15) are supported by ¶[0014] and ¶[0058]. The time series training data limitations of Claims 10–12 are supported by FIGS. 3 and 5 plus ¶[0033]–[0042]. No claim limitation appears unsupported in the specification.
✅
Transition Word Usage
All three independent claims correctly use "comprising," the open-ended transitional phrase that permits the claims to read on embodiments with additional undisclosed elements — an appropriate and strategically sound choice for AI/software patents in the autonomous driving space where competing systems will incorporate many additional components. The CRM claim (Claim 19) uses "comprising computer instructions for," which is standard and accepted post-Beauregard practice. No opportunities for a tighter "consisting essentially of" formulation appear to be missed, as the invention is defined by function rather than a closed list of components.
✅
§112(f) Means-Plus-Function Risk
No claim uses the classic "means for" language that would trigger §112(f) interpretation. Claim 1 recites "a processor configured to" — not "means for" — which under post-Williamson case law requires structural context that is provided by the "processor" noun, substantially reducing §112(f) risk. The specification at ¶[0009] further clarifies that "processor" refers to "one or more devices, circuits, and/or processing cores configured to process data," providing sufficient structural support. No functional claiming without structural anchor is identified across the 20 claims.
⚠️
§101 Eligibility Risk
Claim 1 faces meaningful Alice/Mayo risk because the core operations — receiving image data, applying a trained ML model, providing trajectory output for vehicle control — can be characterized as abstract information processing steps under Step 2A of the Alice framework. The hardware tie-in rests entirely on "a processor" and "a memory coupled to the processor," which courts have repeatedly found insufficient as mere generic computer components. Claims 19 and 20 are even more vulnerable: the CRM and method claims lack even the processor/memory hardware recitation of Claim 1, and an examiner may view "using image data as a basis of an input to a trained machine learning model" as an abstract mathematical process. A stronger filing would have anchored the §101 defense with specific architectural limitations — e.g., a convolutional neural network on a specialized AI processor with specific sensor integration — as disclosed in the specification but not recited in any independent claim.
⚠️
Dependent Claim Fallback Quality
The dependent claims from Claim 1 add meaningful technical limitations in several respects: Claims 14 and 15 (spline and piecewise polynomial representations) provide concrete representational fallbacks directly tied to specification disclosure; Claims 10–12 (time series training data with odometry and automatic ground truth labeling) capture the core training data innovation described in FIGS. 3 and 5; and Claims 16–18 (second vehicle path prediction and collision avoidance) add a meaningfully distinct use case. However, Claims 7 (camera type) and 13 (speed and steering) add only trivially narrow limitations offering little prosecution value. Critically, Claims 19 and 20 have zero dependent claims, meaning if Claim 1 is cancelled or substantially narrowed, the CRM and method branches have no fallback positions at all.
⚠️
Abstract Quality
The abstract describes the system accurately — "a processor coupled to memory is configured to receive image data based on an image captured by a camera of a vehicle" and apply it to a trained ML model to predict a "three-dimensional trajectory of a machine learning feature" — but critically uses the generic term "machine learning feature" rather than identifying the novel contribution of 3D lane trajectory prediction from time-series odometry-annotated training data. An examiner reading only the abstract would understand the output technology but would not identify the key inventive step (time-series-based automatic ground truth generation enabling 3D prediction from a single image) that distinguishes this from prior 2D segmentation approaches described in ¶[0001].
⚠️
Figure Support Quality
The figures provide solid support for the system architecture (FIG. 1) and process flows (FIGS. 2–4), and FIGS. 5–6 provide strong visual evidence of the 3D trajectory prediction output applied to lane lines. However, a significant gap exists: no figure illustrates the internal architecture of the deep learning network (e.g., the convolutional neural network layers described in ¶[0021]–[0022] and [0028]), which means that dependent Claims 14–15 (spline/polynomial representation) and Claims 10–12 (time series training pipeline) lack direct figure support for their specific technical limitations beyond the high-level flow diagrams. A competitor seeking to design around these claims would find the lack of network architecture figures advantageous.
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
2.8
Spec–Claim Consistency
3.9
Dependent Claim Coverage
3.2
Claim Type Diversity
4.2
Figure Support Quality
3
Key observation: Claim Type Diversity scores highest (4.2/5.0) because Tesla's drafters correctly filed tripartite coverage across system (Claim 1), CRM (Claim 19), and method (Claim 20) formats, ensuring enforcement options across software implementations, hardware systems, and practitioner actions. Prosecution Defensibility scores lowest (2.8/5.0) because the complete absence of dependent claims on Claims 19 and 20 means any §101 or §102 rejection forcing amendment of Claim 1 will simultaneously collapse all three independent claim branches with no narrowing fallback — a structural vulnerability that would concern any patent litigator relying on this patent. Practitioners should consider filing a continuation with robust dependent claim coverage on all three independent claim types and hardware-anchored §101 fallback positions.
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.
CRM and method claims lack dependents Training pipeline not independently claimed No hardware-anchored §101 fallback claims
Unlock Full Analysis — Free Frequently asked questions
US 2020/0249685 A1 — 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