Patent Drafting Analysis of Tesla’s Data Synthesis for Autonomous Control Systems | US 10,678,244 B2
Patent Drafting Analysis of Tesla's Data Synthesis for Autonomous Control Systems | US 10,678,244 B2
A structural and strategic analysis of Tesla's synthetic sensor data patent, examining claim architecture, drafting quality, critical gaps, and prosecution positioning across method and CRM claim formats.
Spec Words
7,200
Across 6 sections
Draft now ↗
Total Claims
22
2 independent · 20 dependent
Draft now ↗
Figure Sheets
6
System architecture, data flow, module diagrams, neural network training
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 58% of total words (~4,200 of ~7,200), providing extensive embodiment disclosure across sensor types, neural network training methods, and simulation architectures. The claim set comprises 22 claims across only 2 independent claims — Claim 1 (method) and Claim 12 (CRM) — with 20 dependent claims creating a deep but narrow dependency tree. Six figure sheets cover the system architecture, data flow pipeline, module internals, and neural network training processes, offering moderate but not comprehensive structural figure support.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 6 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Network environment diagram showing the autonomous control system 110, sensor collection system 150 with high-capacity sensors 112A and replacement sensors 112B, model training system 140, and network 120 interconnections.Search in Eureka ↗ | System architecture |
| FIG. 2 | Data flow diagram illustrating the process of introducing artifacts to original sensor data to generate synthetic images of simulated environments (puddle, precipitation), and using synthetic sensor data for training computer models alongside actual microphone, LIDAR, and camera data.Search in Eureka ↗ | Key embodiment |
| FIG. 3 | Block diagram of the model training system 140 architecture showing sensor quality module 313, sensor simulation module 314, reconstruction module 315, detection module 316, segmentation module 317, control module 319, data synthesizing module 325, sensor readings database 350, synthesized sensor readings database 355, and computer models 360.Search in Eureka ↗ | System architecture |
| FIG. 4 | Neural network training diagram for the sensor quality module 313 showing sensor data input, NN Layer 1, NN Layer(s) with activations and gradients flowing to and from ground-truth sensor quality scores.Search in Eureka ↗ | Claim support |
| FIG. 5 | Neural network training diagram for the reconstruction module 315 showing sensor data input through a data deletion step, NN Layer 1 and NN Layer(s) with activations and gradients, outputting to ground truth reconstructed images with a feedback loop for deleted data.Search in Eureka ↗ | Claim support |
| FIG. 6 | Block diagram of the data synthesizing module 325 architecture showing the environment modeling system 610, behavior modeling system 620, sensor modeling system 630, and object database 650.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 exactly 2 independent claims — Claim 1 (method) and Claim 12 (non-transitory computer-readable medium / CRM) — with 20 dependent claims yielding a 10:1 dependent-to-independent ratio, well above the software/autonomous vehicle norm of 4–8:1. The bipartite independent claim structure provides enforcement coverage across method and CRM formats but notably omits a system/apparatus claim, leaving a significant gap in claim type diversity. The deep dependent chains (Claims 2–11 from Claim 1 and Claims 13–22 from Claim 12) mirror each other almost identically, reducing the effective fallback diversity despite the high dependent count.
Core inventive concept: The claims address the problem of insufficient or unrepresentative training data for autonomous vehicle AI models by generating synthesized sensor data that simulates artifacts (atmospheric conditions, occlusions, sensor malfunctions) through modifying actual sensor measurements or simulating virtual environments, then training computer models on the synthesized data so they can handle those same artifact types when applied to real physical sensor data. Claim 1 recites 'generating, for each of a set of artifacts, the set of synthesized sensor inputs that simulate presence of the set of artifacts... generated by changing the sensor measurements of at least a subset of sensor data to simulate modified responses of the one or more sensors to the presence of the set of artifacts.'
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A method of training a computer model using a set of synthesized sensor data | comprising | obtaining a set of sensor data from one or more sensors sensing a surrounding environment; generating synthesized sensor inputs simulating presence of a set of artifacts by changing sensor measurements of at least a subset of sensor data; training the computer model using synthesized sensor data to reduce differences between predictions and target outputs; applying the computer model to physical sensor data having the same artifact typesSearch prior art ↗ |
| Claim 12 | A non-transitory computer-readable medium storing instructions for execution on a processor, the instructions when executed by the processor causing the processor to perform steps | comprising | obtaining a set of sensor data from one or more sensors sensing a surrounding environment; generating synthesized sensor inputs simulating presence of a set of artifacts by changing sensor measurements; training the computer model to reduce differences between predictions and target outputs; applying the computer model to physical sensor data having the same artifact typesSearch prior art ↗ |
Claim Dependency Tree
1 Method of training a computer model using synthesized sensor data; obtaining sensor data, generating synthesized inputs with artifacts, training model, applying to physical dataSearch Claim 1 prior art ↗
2 Adds: artifacts are atmospheric conditions in the surrounding environmentSearch in Eureka ↗
3 Adds: computer model configured to output estimation indicating atmospheric conditions; target outputs are categorical labelsSearch in Eureka ↗
4 Adds: computer model outputs estimated sensor data attenuating atmospheric conditions; target outputs are non-simulated sensor data subsetSearch in Eureka ↗
5 Adds (dep. on 4): synthesized sensor data from first sensor with first sensing characteristics; target outputs from second sensor with different sensing characteristicsSearch in Eureka ↗
6 Adds (dep. on 1): generating synthesized data comprises omitting at least a portion of sensor measurements corresponding to artifact locationsSearch in Eureka ↗
7 Adds (dep. on 6): computer model configured to output reconstructed sensor data; target outputs simulate sensor measurements for omitted artifact portionsSearch in Eureka ↗
8 Adds (dep. on 7): computer model receives another instance of physical sensor data with complementary measurements for the missing portionSearch in Eureka ↗
9 Adds (dep. on 8): physical sensor data from first sensor with first characteristics; complementary data from second sensor with different characteristicsSearch in Eureka ↗
10 Adds (dep. on 6): artifacts are at least one of a puddle or a dark-colored vehicleSearch in Eureka ↗
11 Adds (dep. on 1): computer model is applied to physical sensor data by an autonomous control systemSearch in Eureka ↗
12 CRM: non-transitory computer-readable medium storing instructions for same steps as Claim 1 — obtaining, generating, training, applyingSearch Claim 12 prior art ↗
13 Adds: artifacts are atmospheric conditionsSearch in Eureka ↗
14 Adds (dep. on 13): computer model outputs atmospheric condition estimation; target outputs are categorical atmospheric labelsSearch in Eureka ↗
15 Adds (dep. on 13): computer model outputs estimated sensor data attenuating atmospheric conditionsSearch in Eureka ↗
16 Adds (dep. on 15): synthesized sensor data from first sensor; target outputs from second sensor with different sensing characteristicsSearch in Eureka ↗
17 Adds (dep. on 12): generating synthesized data comprises omitting sensor measurements at artifact locationsSearch in Eureka ↗
18 Adds (dep. on 17): computer model outputs reconstructed sensor data; target outputs simulate omitted artifact measurementsSearch in Eureka ↗
19 Adds (dep. on 18): computer model receives complementary sensor measurements for missing portionSearch in Eureka ↗
20 Adds (dep. on 19): physical sensor data from first sensor; complementary data from second sensor with different characteristicsSearch in Eureka ↗
21 Adds (dep. on 17): artifacts are at least one of a puddle or a dark-colored vehicleSearch in Eureka ↗
22 Adds (dep. on 12): computer model is applied to physical sensor data by an autonomous control systemSearch in Eureka ↗
| Metric | This Application | Software / Autonomous Systems Norm |
|---|---|---|
| Total claims | 22 | 15 – 25 |
| Independent claim count | 2 | 2 – 4 |
| Dependent : Independent ratio | 10.00 : 1 | 4 – 8 : 1 |
| Method claims present? | Yes — Claim 1 | Common |
| 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 patent demonstrates strong specification depth with detailed embodiment disclosure across sensor types and neural network training mechanisms, and the 'comprising' transitions in Claims 1 and 12 preserve appropriate claim breadth. However, the complete absence of an apparatus/system independent claim — despite the detailed system architecture described in FIGs. 1, 3, and 6 — represents the most significant drafting weakness, creating an immediate design-around path for system-level implementers.
✅
Antecedent Basis
The claim set is generally clean for antecedent basis. In Claim 1, 'the set of artifacts' and 'the set of synthesized sensor data' are properly introduced before their subsequent references. Claim 7's reference to 'the physical sensor data' properly traces to the antecedent in Claim 1's 'applying' step. The dependent claims in the 12-series mirror their method counterparts without introducing new antecedent basis problems, and 'the one or more sensors' is consistently used after introduction in both independent claims.
✅
Spec–Claim Consistency
The core independent claim limitations map well to specific figures and description. FIG. 2 and the corresponding detailed description directly support Claim 1's artifact generation limitation, showing simulated puddle and precipitation scenarios with Simulated Microphone/LIDAR/Camera 1 and 2. FIG. 5 and the reconstruction module discussion support Claims 7–9 and 18–20 covering the omission-and-reconstruction mechanism. FIG. 3 provides architectural support for the model training system underlying the training step in Claims 1 and 12. The sensor quality output mechanism in Claims 3 and 14 is supported by FIG. 4 and the sensor quality module 313 description.
✅
Transition Word Usage
Both independent claims (1 and 12) correctly use 'comprising' as the transition word, preserving open-ended coverage that does not exclude additional steps or instructions. This is strategically appropriate for a method and CRM claim directed at a software-implemented training pipeline where competitors may add additional processing steps. No 'consisting of' or 'consisting essentially of' language appears, avoiding any inadvertent narrowing that would allow easy workarounds by adding preprocessing or postprocessing steps.
⚠️
§112(f) Means-Plus-Function Risk
No explicit 'means for' language appears in the claims, reducing direct §112(f) exposure. However, the functional claim language in Claims 7 and 18 — 'wherein the computer model is configured to receive the physical sensor data and output reconstructed sensor data that reconstructs a missing portion' — describes the computer model purely by its functional output without structural definition of the model architecture. While courts have generally not invoked §112(f) for software 'configured to' language, an examiner could challenge the indefiniteness of 'computer model configured to reconstruct' without a structural anchor, and the spec's reference to 'neural network models' is not imported into the claim.
⚠️
§101 Eligibility Risk
The claims face meaningful Alice/Mayo exposure because the core method of Claim 1 is conceptually directed to 'data augmentation for machine learning,' which an examiner could characterize as an abstract idea. The hardware tie-in is limited: Claim 1 recites 'one or more sensors' and 'one or more physical sensors' but does not require any specific computing hardware. The CRM Claim 12 provides a hardware anchor via the 'non-transitory computer-readable medium' tied to 'a processor,' which is the primary §101 defense. The dependent claims add specificity (atmospheric conditions, puddle/dark-colored vehicle artifacts) but these are environmental details, not technical improvements to computer functionality itself, weakening the Alice Step 2B argument compared to claims that recite specific processing improvements.
⚠️
Dependent Claim Fallback Quality
The 20 dependent claims are structurally redundant: Claims 2–11 mirror Claims 13–22 in an almost exact parallel structure, effectively halving the actual number of distinct fallback positions to approximately 10 unique limitations. High-value fallbacks include Claims 5/16 (cross-sensor characteristic differentiation) and Claims 8/19 (complementary sensor reconstruction), which add genuinely distinct technical limitations. However, Claims 11 and 22 ('computer model is applied by an autonomous control system') add only a context limitation with no structural substance, and Claims 3/14 and 4/15 offer alternative output configurations that could have been more powerfully drafted as separate independent claims given the commercial importance of the atmospheric condition detection use case.
⚠️
Abstract Quality
An examiner reading only the abstract would identify the general category of invention (synthetic data for autonomous control) but would not identify the specific novel contribution — the mechanism of 'changing sensor measurements of at least a subset of sensor data to simulate modified responses of the one or more sensors to the presence of the set of artifacts.' The abstract describes the system's purpose ('augment training data,' 'simulate scenarios,' 'remove unwanted effects') accurately but omits the key technical distinction of sensor measurement modification versus pure virtual environment rendering, which is the primary differentiator from prior simulation-only approaches cited in prosecution.
⚠️
Figure Support Quality
FIGs. 1–3 and 6 support the system architecture and module-level claims, and FIGs. 4–5 support the neural network training process for quality and reconstruction models. However, the independent claims' core limitation — 'changing the sensor measurements... to simulate modified responses' — lacks a dedicated figure showing the signal modification process itself (e.g., a before/after sensor data comparison with specific modification parameters). FIG. 2 shows the input/output flow at a high level but does not illustrate the mathematical or computational mechanism of sensor measurement modification, which is the heart of the inventive contribution and most likely to face claim scope challenges in litigation.
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
3.8
Dependent Claim Coverage
2.5
Claim Type Diversity
2
Figure Support Quality
3.2
Key observation: The strongest dimension is Spec–Claim Consistency (3.8/5.0) — the detailed description provides thorough embodiment support for all independent claim limitations, with FIGs. 2, 4, and 5 mapping directly to the artifact generation, quality model training, and reconstruction model training steps in Claims 1 and 12. The weakest dimension is Claim Type Diversity (2.0/5.0) — despite the specification describing a richly articulated system architecture across FIGs. 1, 3, and 6 with named components (model training system 140, data synthesizing module 325, sensor quality module 313), no system or apparatus independent claim was filed, creating an immediate enforcement gap that allows hardware implementers to practice the invention without method or CRM liability. Practitioners should evaluate whether a continuation filing adding system/apparatus claims for the model training system and data synthesizing module architecture would significantly strengthen Tesla's enforcement position in this space.
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 claim on training system Mirror claims halve fallback positions Sensor simulation model unclaimed
Unlock Full Analysis — Free Frequently asked questions
US 10,678,244 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