Patent Drafting Analysis of Tesla’s Machine Learning Models for Autonomous Vehicles | US 11,816,585 B2
Patent Drafting Analysis of Tesla's Dual-Frequency ML Models for Autonomous Vehicles | US 11,816,585 B2
A structural and strategic analysis of Tesla's granted patent covering dual-frequency machine learning inference for autonomous vehicle object detection, examining claim architecture, drafting quality, critical gaps, and prosecution positioning across all 18 claims.
Spec Words
5,200
Across 6 sections
Draft now ↗
Total Claims
18
3 independent · 15 dependent
Draft now ↗
Figure Sheets
4
System architecture, method flowchart, detector-tracker diagrams
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 53% of total specification words (~2,800 of ~5,200), providing substantial embodiment disclosure across four distinct figures covering system architecture, method flow, and two detector-combination paradigms. The claim set comprises 18 claims with 3 independent claims — one method (Claim 1), one system (Claim 12), and one CRM (Claim 16) — yielding a dependent-to-independent ratio of 5:1. Figure coverage spans system-level schematic (FIG. 1), process flowchart (FIG. 2), and two block-diagram variations of the dual-ML-model architecture (FIGs. 3 and 4), providing adequate but not exhaustive structural support for the claimed elements.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 4 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | High-level schematic of image processing system 100, showing cameras 114, first image processing engine 104, second image processing engine 106, image database 108, output database 110, client device 112, and endpoint interconnections.Search in Eureka ↗ | System architecture |
| FIG. 2 | Flowchart depicting four-step method: receiving first frame (202), processing with first image processing engine (204), receiving second frame while first is being processed (206), sending to second engine (208), and combining outputs for object prediction (210).Search in Eureka ↗ | Flow diagram |
| FIG. 3 | Block diagram of example 300 illustrating object detection with tracker 306 and detector 308, showing frame-by-frame processing pipeline where detector output feeds into the tracker to generate combined outputs 304.Search in Eureka ↗ | Claim support |
| FIG. 4 | Block diagram of example 400 showing dual-detector configuration with faster detector 406 and slower detector 408, illustrating how high-accuracy output from detector 408 feeds into detector 406 across frames 402 to generate outputs 404.Search in Eureka ↗ | Claim support |
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 covering all three primary claim types: method (Claim 1), system (Claim 12), and non-transitory computer-readable storage medium (Claim 16), providing tripartite enforcement coverage. The 15 dependent claims yield a 5:1 ratio, which is slightly below the software/AI industry norm of 6–8:1, leaving some potential fallback positions underdeveloped. Claims 1, 12, and 16 are structurally parallel, reciting essentially the same dual-frequency ML model limitations across formats — a deliberate strategy that maximizes coverage but reduces differentiation among independent claims.
Core inventive concept: The claims address the latency-accuracy tradeoff in autonomous vehicle perception by combining a first machine learning model operating at a full camera threshold frequency with a second machine learning model operating at a lower subset frequency, wherein the first model is configured to "periodically receive output information from the second machine learning model, the received output information being input into the first machine learning model in combination with a first image" to increase location determination accuracy. This architecture — explicitly recited in Claims 1, 12, and 16 — solves the problem of slower high-accuracy detectors producing stale outputs by using the slow model's outputs as prior information to boost the fast model's per-frame accuracy.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method implemented by a system of one or more processors | comprising | obtaining plurality of images at threshold frequency from image sensors on vehicle; determining location information of classified objects via first ML model at threshold frequency; first ML model periodically receives output from second ML model operating at less than threshold frequency; plurality of images is a sequence with first image analyzed before second ML model completes; outputting location information for autonomous drivingSearch prior art ↗ |
| Claim 12 | A system comprising one or more processors and non-transitory computer storage media storing instructions | comprising | obtaining plurality of images at threshold frequency from image sensors on vehicle; first ML model analyzes at threshold frequency; second ML model configured for subset of analyzed images at less than threshold frequency; second ML model classifies objects; first ML model updates location information for each analyzed image; prior to classification completion, at least one image analyzed via first ML model; outputting location information for autonomous drivingSearch prior art ↗ |
| Claim 16 | Non-transitory computer storage media storing instructions that when executed by a system of one or more processors | cause the one or more processors to perform operations comprising | obtaining plurality of images at threshold frequency from image sensors on vehicle; first ML model at threshold frequency; first ML model uses output from second ML model for subset of analyzed images at less than threshold frequency; second ML model classifies objects; first ML model updates location information per analyzed image; prior to classification completion, at least one image analyzed via first ML model; outputting location information for autonomous drivingSearch prior art ↗ |
Claim Dependency Tree
1 Method: obtaining images at threshold frequency; dual-ML model system where first model runs at full rate, second at subset frequency, first periodically receives second's outputSearch Claim 1 prior art ↗
2 Adds: first ML model is tracker; second ML model is detectorSearch in Eureka ↗
3 Further: determining location information comprises instructing second ML model to analyze first image; first ML model updates location info for prior images in sequenceSearch in Eureka ↗
4 Further: second image subsequent to first image; second ML model determines objects classified and location info in first image; provides output to first ML model for analyzing second imageSearch in Eureka ↗
5 Further: for second image, first ML model determines updated location information associated with objects depicted in the first imageSearch in Eureka ↗
6 Adds: (dep. on Claim 2) second ML model classifies objects in subset; first ML model updates location information for each image for classified objectsSearch in Eureka ↗
7 Further: (dep. on Claim 6) plurality of images is sequence; first ML model determines optical flow information between images in sequenceSearch in Eureka ↗
8 Adds: (dep. on Claim 1) first ML model is first detector with first accuracy; second ML model is second detector with second, greater accuracySearch in Eureka ↗
9 Further: (dep. on Claim 8) sequence comprises first image and one or more second images; instructing second ML model to analyze first image; prior to completion, analyzing first image and second images via first ML modelSearch in Eureka ↗
10 Further: (dep. on Claim 9) sequence further comprises third image; second ML model analyzes first image determining objects and location info; provides output to first ML model for analyzing third image with increased accuracySearch in Eureka ↗
11 Further: (dep. on Claim 8) first ML model is trained based on periodically using output information from second ML model as inputSearch in Eureka ↗
12 System: processors + CRM instructions; obtaining images at threshold frequency; first ML model at threshold frequency; second ML model at subset frequency; outputs location info for autonomous drivingSearch Claim 12 prior art ↗
13 Adds: (dep. on Claim 12) first ML model periodically receives output from second ML model; received output usable to increase accuracy of determining location informationSearch in Eureka ↗
14 Adds: (dep. on Claim 12) first ML model is tracker; second ML model is detectorSearch in Eureka ↗
15 Adds: (dep. on Claim 12) first ML model is first detector with first accuracy; second ML model is second detector with second, greater accuracySearch in Eureka ↗
16 CRM: non-transitory storage media; obtaining images at threshold frequency; first ML model at threshold frequency with second ML model at subset frequency; second classifies objects; first updates location info; outputs for autonomous drivingSearch Claim 16 prior art ↗
17 Adds: (dep. on Claim 16) first ML model is tracker; second ML model is detectorSearch in Eureka ↗
18 Adds: (dep. on Claim 16) first ML model is first detector with first accuracy; second ML model is second detector with second, greater accuracySearch in Eureka ↗
| Metric | This Application | Software / AI Industry Norm |
|---|---|---|
| Total claims | 18 | 15 – 25 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.00 : 1 | 5 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| System / apparatus claims? | Yes — Claim 12 | 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 tripartite coverage across method, system, and CRM claim types, and the detailed description provides robust embodiment support for the dual-frequency ML architecture through FIGs. 1–4. However, the claims carry moderate §101 eligibility risk because the hardware tie-in — "one or more processors" and "image sensors positioned about a vehicle" — is functional rather than structural, and a competitor could challenge whether the claimed innovations are directed to an abstract idea of data combination without a sufficiently specific technical improvement.
✅
Antecedent Basis
The claim set is largely clean on antecedent basis, with proper introduction of "a threshold frequency" in Claim 1 before subsequent "the threshold frequency" references. The "first machine learning model" and "second machine learning model" are consistently introduced in each independent claim before being referenced as "the first" and "the second" in dependent claims. Claim 3's reference to "the second machine learning model" correctly traces to the antecedent in Claim 2, and Claims 9–10 correctly maintain the "first image" / "second images" / "third image" chain introduced in Claim 9.
✅
Spec–Claim Consistency
The detailed description maps well to the independent claim limitations. FIG. 1 and col. 4 directly support the "image sensors positioned about a vehicle" and dual-engine architecture of Claims 1, 12, and 16. FIG. 2 (steps 202–210) maps directly to the method steps in Claim 1. FIG. 3 supports Claims 2, 14, and 17 (tracker/detector configuration), while FIG. 4 supports Claims 8, 15, and 18 (dual-detector configuration). The "periodically receive output information" limitation in Claims 1 and 13 is supported by col. 3 describing the first model's periodic receipt of output from the second model.
✅
Transition Word Usage
All independent claims (1, 12, 16) correctly use "comprising" as the transition, which is the optimal open-ended choice for software and system claims — it permits the inclusion of additional ML models, sensors, or processing steps without defeating infringement. Claim 16's transition "cause the one or more processors to perform operations comprising" is the standard and legally robust formulation for CRM claims. No narrowing transitions ("consisting of" or "consisting essentially of") appear anywhere in the claim set, which is strategically appropriate for this technology domain.
✅
§112(f) Means-Plus-Function Risk
No "means for" or "step for" language appears in the claim set, which avoids mandatory §112(f) claim construction that would limit scope to disclosed structures. The claims use functional language ("configured to", "being configured to perform analyses") which is standard and generally does not trigger §112(f) treatment under post-Williamson doctrine because the claim elements are coupled to structural nouns: "first machine learning model," "second machine learning model," and "one or more processors." The specification provides sufficient structural disclosure of examples including R-CNN, YOLO, optical flow trackers to support these functional descriptions.
⚠️
§101 Eligibility Risk
Claims 1, 12, and 16 face moderate Alice Step 1 risk because the core concept — using output of a slow, high-accuracy model to improve a fast, low-accuracy model — could be characterized as an abstract idea of "combining information from two sources at different temporal resolutions." The §101 defense rests on the "images being obtained from one or more image sensors positioned about a vehicle" and the autonomous driving output limitation, which tie the claims to a specific technical application. However, neither the hardware tie-in nor the autonomous driving output is claimed with sufficient structural specificity to be unassailable — a challenger could argue these are mere field-of-use limitations appended to an otherwise abstract data-processing method.
⚠️
Dependent Claim Fallback Quality
The dependent claims add meaningful technical distinctions in certain cases — notably Claim 7 (optical flow computation), Claim 11 (training on second model's periodic output), and Claim 10 (three-image sequence with accuracy improvement) — but the claim tree is heavily redundant across the three independent branches. Claims 2/14/17 all add the identical tracker/detector limitation to Claims 1, 12, and 16 respectively, and Claims 8/15/18 add the identical dual-detector accuracy limitation. This parallelism provides enforcement breadth but does not add genuinely distinct technical fallback positions — a competitor who designs around Claims 2 and 14 has automatically designed around Claim 17 as well, defeating the purpose of the tripartite structure.
⚠️
Abstract Quality
The abstract states that "a first machine learning model uses output information from a second machine learning model, the second machine learning model being performed at less than the threshold frequency" — which correctly identifies the novel mechanism. However, the abstract omits the specific consequence of this architecture (reducing latency-accuracy tradeoff in autonomous vehicle perception) and the training feedback loop described in Claim 11, which is one of the most commercially significant dependent claim limitations. An examiner reading only the abstract would understand the dual-frequency concept but might not identify the trained-model feedback loop or optical flow combination as distinct inventive aspects warranting claim scope.
✅
Figure Support Quality
All four structural claim limitations in Claims 1, 12, and 16 have figure support: image sensors/cameras are shown in FIG. 1 (element 114); the first ML model (fast, threshold-frequency processor) maps to engine 104 in FIG. 1 and tracker 306 in FIG. 3; the second ML model (slow, subset-frequency processor) maps to engine 106 in FIG. 1 and detector 308 in FIG. 3; and the output to endpoint 112 maps to the autonomous driving output in FIG. 1. The dual-detector variation (Claims 8, 15, 18) is specifically covered by FIG. 4 showing detectors 406 and 408. The optical flow limitation in Claim 7 lacks a dedicated figure but is described in the detailed description, which is sufficient for written description but marginally weaker.
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.2
Dependent Claim Coverage
3
Claim Type Diversity
4.5
Figure Support Quality
4
Key observation: The highest-scoring dimension is Claim Type Diversity (4.5/5.0) — Claims 1, 12, and 16 provide complete tripartite coverage across method, system, and CRM formats, ensuring that any implementer of the dual-frequency ML architecture in software, hardware, or distributed form faces infringement exposure across all three formats. The lowest-scoring dimension is Dependent Claim Coverage (3.0/5.0) — the 15 dependent claims are structurally redundant, with Claims 2/14/17 and 8/15/18 adding identical limitations to each of the three parallel independent claims without creating genuinely distinct technical fallback positions, meaning a successful design-around of one branch automatically circumvents the parallel limitations in the other two branches. Practitioners drafting continuation applications should consider adding asymmetric dependent claims — particularly on Claims 11 (training feedback) and 7 (optical flow) — that extend only from one independent claim to create non-redundant prosecution fallback.
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 vehicle apparatus claim filed Threshold frequency undefined — design-around risk Training feedback loop lacks independent claim
Unlock Full Analysis — Free Frequently asked questions
US 11,816,585 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