Patent Drafting Analysis of Zoox, Inc.’s Machine-Learning AV Teleoperation Optimization System | US 11,061,398 B2

IP Drafting Analysis · US 11,061,398 B2

Patent Drafting Analysis of Zoox's Machine-Learning AV Teleoperation Optimization System | US 11,061,398 B2

Q: What does US 11,061,398 B2 protect?

US 11,061,398 B2 protects a machine-learning system for optimizing autonomous vehicle teleoperation and planner decisions. The patent covers method, system, and computer-readable medium claim types directed to the specific technical problem of autonomous vehicles encountering events that exceed their autonomous confidence thresholds. The solution is a feedback loop in which teleoperator interactions with those events are captured and used to train an ML model that subsequently outputs recommended actions (candidate trajectories, paths, or policy modifications) for future similar events.

Q: Who owns patent US 11,061,398 B2?

The patent is assigned to Zoox, Inc., located in Foster City, California, USA. The inventors are Jesse Sol Levinson (Redwood City, CA), Gabriel Thurston Sibley (Menlo Park, CA), and Ashutosh Gajanan Rege (San Jose, CA). Zoox, Inc. is an autonomous vehicle company acquired by Amazon in 2020.

Q: What are the independent claims of US 11,061,398 B2?

Claim 1 is a method claim covering receiving sensor data from an autonomous vehicle, determining an event in a region of an environment, receiving a teleoperator interaction associated with that event, and training an ML model based on the teleoperator interaction and event to output recommended actions. Claim 7 is a system claim with the same core limitations implemented as processor-executable instructions in memory. Claim 14 is a non-transitory computer-readable medium (CRM) claim with parallel limitations to Claims 1 and 7.

Q: What technology does this patent cover?

This patent covers a learning system for self-driving cars that improves over time by watching how human operators (teleoperators) handle difficult driving situations. When an autonomous vehicle encounters an unusual situation it cannot handle confidently on its own — such as a road obstruction, construction, or an unexpected object — it requests human teleoperator guidance. The system then captures that human response and uses it to train a machine-learning model so that future autonomous vehicles encountering similar events can receive automated recommendations, reducing the need for repeated human intervention.

Q: What IPC classifications does this patent use?

G05D 1/02 (2020.01) — Control of position, course, altitude, or attitude of land, water, air, or space vehicles, specifically for guiding without a pilot. G05D 1/00 (2006.01) — Control of position, course, altitude, or attitude of land, water, air, or space vehicles. G06N 20/00 (2019.01) — Machine learning. G08G 1/00 (2006.01) — Traffic control systems. G08G 1/16 (2006.01) — Anti-collision systems for road vehicles. G01S 17/86 (2020.01) — Lidar systems for vehicle collision avoidance. G01S 17/931 (2020.01) — Lidar systems for vehicle parking or overtaking. G06Q 10/00 (2012.01) — Administration and management systems.

A structural and strategic analysis of Zoox's granted AV teleoperation patent, examining claim architecture, drafting quality, specification support, and prosecution positioning across method, system, and CRM claim types.

US 11,061,398 B2Filed: Jul 22, 2019Granted: Jul 13, 2021G05D 1/02G05D 1/00G06N 20/00G08G 1/00

Draft a Patent Like This Explore Related Patents

Spec Words

18,400

Across 6 sections

Draft now ↗

Total Claims

3 independent · 17 dependent

Draft now ↗

Figure Sheets

System architecture, flow diagrams, AV components, teleoperation UI

Draft now ↗

Published by PatSnap Insights Team · June 3, 2026 · 14 min read Verified by PatSnap Eureka Data

Overview

Structural Overview

The detailed description dominates at approximately 79% of total specification words (~14,500 of ~18,400), providing extensive embodiment coverage across 39 figures. The patent presents 20 total claims structured across 3 independent claims (method/system/CRM) with 17 dependent claims, yielding a dependent-to-independent ratio of 5.67:1. The 42 drawing sheets provide comprehensive coverage of the autonomous vehicle architecture, teleoperation interfaces, simulator systems, and policy explorer components, though the sheer volume creates some diffusion in claim-to-figure mapping.

Section Word Distribution

↗ Click bars to explore

Figure Inventory — 42 Sheets

Figure	Description	Role
FIG. 1	System overview showing fleet of autonomous vehicles (109a-109e) communicatively networked to autonomous vehicle service platform 101 via networks 106, with bidirectional AV 130 and AV Controller 147.Search in Eureka ↗	System architecture
FIG. 2	Flow diagram (200) showing method to monitor fleet of autonomous vehicles: detecting events with confidence levels, receiving candidate trajectories, identifying guidance data, receiving teleoperator trajectory selection, and transmitting to vehicle.Search in Eureka ↗	Flow diagram
FIG. 3A	Interior diagram of bidirectional autonomous vehicle 330 showing sensors (image capture 340, audio capture 342, LIDAR 346, RADAR 348, sonar 341), AV Control Logic 347, and AV Controller 347a with motion controller 362, planner 364, perception engine 366, and localizer 368.Search in Eureka ↗	Key embodiment
FIG. 3B	Diagram 391 depicting sensor field 301a of sensor 310a showing single Lidar field coverage around autonomous vehicle 330a.Search in Eureka ↗	Other
FIG. 3C	Diagram 392 depicting four overlapping sensor fields from sensors 310a-310d providing redundant coverage regions 301, 302, and 303 around autonomous vehicle 330b.Search in Eureka ↗	Other
FIG. 3D	Diagram 393 depicting loss of sensor field due to failed Lidar 309, showing gap 304 and reduced sensor field coverage 305, 306 around autonomous vehicle 330c traveling in direction of travel 396.Search in Eureka ↗	Other
FIG. 3E	Diagram 394 depicting bidirectional maneuver by autonomous vehicle 330d to restore robust sensor field 302 at leading end, using driveway 397 to switch directionality and relocate taillights 348.Search in Eureka ↗	Other
FIG. 4	Functional block diagram (400) of system showing autonomous vehicle service platform 401 communicatively coupled via communication layer 402 to AV Controller 447, including planner 464 with trajectory evaluator 465, teleoperator 404, and reference data repository 405.Search in Eureka ↗	System architecture
FIG. 5	Flow diagram (500) for controlling autonomous vehicle: receiving multi-modal sensor data (502), correlating subsets (504), deriving object data (506), detecting objects affecting planned path (508), evaluating trajectories (510), determining confidence level (512), transmitting alternate path request to teleoperator (514).Search in Eureka ↗	Flow diagram
FIG. 6	Architecture diagram (600) of autonomous vehicle controller showing processes: motion controller 662, planner 664, perception 666, mapping 640, localization 668, with guidance data 606, 2D/3D map data, and actuators 650.Search in Eureka ↗	System architecture
FIG. 7	Diagram (700) of autonomous vehicle service platform 701 with reference data generator 705, vehicle data controller 702, fleet manager 703, teleoperator manager 707, simulator 740, policy manager 742, and redundant communication channels 770 (networks 771-774) to fleet vehicles 730.Search in Eureka ↗	System architecture
FIG. 8	Diagram (800) of messaging application showing teleoperator application 801 and autonomous vehicle application 830 exchanging data via message routers 854 and teleoperator API 852 over WAN 871 and LAN 872 networks using Data Distribution Service middleware protocol.Search in Eureka ↗	System architecture
FIG. 9	Diagram (900) depicting teleoperation data types including obstacle data 920, planner options data 924, position data 926, telemetry data 940/950, query data 942/952, and command data 946/956 exchanged via data-centric messaging bus 972 between teleoperator application 901 and autonomous vehicle application 930.Search in Eureka ↗	Claim support
FIG. 10	Diagram (1000) illustrating teleoperator interface showing autonomous vehicle service platform 1001 with teleoperator manager 1007, teleoperator display 1010 showing vehicle path 1012, candidate trajectories 1040, teleop-based path 1042, planner-generated path 1044, and unidentified obstacle 1046.Search in Eureka ↗	UI/interface
FIG. 11	Diagram (1100) of planner 1164 configured to invoke teleoperations, showing trajectory evaluator 1120 with state/event manager 1122, confidence level generator 1123, guided trajectory generator 1126, trajectory tracker 1128, receiving policy data 1130 and perception engine data 1132.Search in Eureka ↗	Key embodiment
FIG. 12	Flow diagram (1200) for controlling AV: receiving objects with classification certainty (1202), receiving localizer/map data with event certainty (1204), determining path (1206), local position (1208), probabilistic state of operation (1210), normative state likelihood (1212), transmitting teleoperator monitoring request (1214).Search in Eureka ↗	Flow diagram
FIG. 13	Diagram (1300) showing planner trajectory generation with trajectory evaluator 1320, confidence level generator 1322, teleoperator query messenger 1329, trajectory recalculator 1325, and nominal driving trajectory generator 1327 receiving inputs from perception engine 1366 and localizer 1368.Search in Eureka ↗	Key embodiment
FIG. 14	Diagram (1400) of autonomous vehicle service platform 1401 with teleoperator manager 1407, teleoperator action recommendation controller 1412, simulator interface controller 1414, teleoperator interaction capture analyzer 1416, simulator 1440, policy manager 1442, and reference data updater 1438.Search in Eureka ↗	System architecture
FIG. 15	Flow diagram (1500) showing teleoperator computing device receiving event message data (1502), accessing teleoperation repository for simulation-based and teleoperator-interaction-based recommendations (1504), combining subsets (1506), presenting recommended courses of action (1508), receiving teleoperator selection (1510).Search in Eureka ↗	Flow diagram
FIG. 16	Diagram (1600) of autonomous vehicle fleet manager 1603 with fleet optimization manager 1620 including transit request processor 1631, AV dispatch optimization calculator 1634, hybrid AV/non-AV processor 1640, and non-AV service region 1690 within road network 1650.Search in Eureka ↗	System architecture
FIG. 17	Flow diagram (1700) for managing fleet: receiving policy data (1702), extracting fleet management data (1704), receiving transit request (1706), calculating attributes (1708), selecting autonomous vehicle (1710), generating dispatch data (1712).Search in Eureka ↗	Flow diagram
FIG. 18	Diagram (1800) of autonomous vehicle fleet manager 1803 with communication link manager 1820, environment event detector 1831, policy adaption determinator 1832, policy download manager 1842, COMM-configured AV dispatcher 1844, and reduced communication region 1880.Search in Eureka ↗	System architecture
FIG. 19	Flow diagram (1900) for actions during communication events: receiving policy data (1901), implementing actions including dispatching vehicles as relays, peer-to-peer communications, event policy download, invoking teleoperations, recalculating paths (1902), monitoring fleet (1914).Search in Eureka ↗	Flow diagram
FIG. 20	Diagram (2000) of localizer 2068 with positioning system 2010 and localization system 2012 receiving Lidar 2072, camera 2074, radar 2076 sensor data plus reference data 2020 (2D/3D/4D map data), producing local pose data 2052 via localization data integrator 2014.Search in Eureka ↗	System architecture
FIG. 21	Flow diagram (2100) for generating local pose data: receiving 3D map reference data (2102), localization sensor data (2104), positioning sensor data (2106), integrating data (2108), forming local position data (2110).Search in Eureka ↗	Flow diagram
FIG. 22	Detailed localizer diagram (2200) showing localization system 2210 (projection processor 2254a, odometry processor 2254b, integrator processor 2254c) and relative localization system 2212 (localization processor 2254d, visual registration processor 2254e, radar return processor 2254f) feeding into localization data integrator 2266.Search in Eureka ↗	Key embodiment
FIG. 23	Diagram (2300) of perception engine 2366 with segmentation processor 2310, object tracker 2330, and classifier 2360 receiving local position data 2352, Lidar 2372, camera 2374, and radar 2376 data, producing perception engine data 2354.Search in Eureka ↗	System architecture
FIG. 24	Flow chart (2400) for generating perception engine data: retrieving local position (2402), receiving localization sensor data (2404), segmenting environment features (2406), spatially tracking segmented objects (2408), classifying as static/dynamic (2410), associating classification type (2410), generating classified object data (2412).Search in Eureka ↗	Flow diagram
FIG. 25	Segmentation processor diagram (2500) showing meta spin generator 2521, segmentation processor 2523, scan differencing processor 2513, blob classifier 2520, radar segmentation processor 2514 processing Lidar 2572, camera 2574, and radar 2576 data to produce occupancy grid map 2515 and obstacle velocity data 2517.Search in Eureka ↗	Key embodiment
FIG. 26A	Diagram (2600) of object tracker 2630 and classifier 2660 showing data association processor 2632, image tracker 2633, track updater 2634, track database 2636, and track classification engine 2662 generating static obstacle data 2672 and dynamic obstacle data 2674.Search in Eureka ↗	System architecture
FIG. 26B	Alternate object tracker diagram (2601) showing object tracker 2631 with optional registration portion 2699 including object scan registration and fusion processor 2696 and 3D object database 2698.Search in Eureka ↗	Other
FIG. 27	Front-end processor diagram (2700) for perception engine showing ground segmentation 2723a, over-segmentation 2723b, aggregation classification 2712, data association 2732, track database 2736, and track classification engine 2762 processing colored Lidar data 2775.Search in Eureka ↗	System architecture
FIG. 28	Simulator diagram (2800) showing simulated environment 2803 with simulated autonomous vehicle 2830, simulated AV controller 2847 (perception engine 2866, localizer 2868, motion controller 2862, planner 2864), physics processor 2850 with collision detection 2852, and teleoperator computing device 2804.Search in Eureka ↗	Key embodiment
FIG. 29	Flow chart (2900) for simulating autonomous vehicle: retrieving 3D map data (2902), dynamic object data (2904), forming simulated environment (2906), simulating AV with controller (2908), generating simulated sensor data (2910), generating simulated vehicle commands (2912), evaluating policy compliance (2914).Search in Eureka ↗	Flow diagram
FIG. 30	Flow chart (3000) for generating 3D map data: retrieving trajectory data (3002), localization data with image data (3004, 3006), aligning subsets for global position (3008), generating 3D map data (3010), implementing map data (3012).Search in Eureka ↗	Flow diagram
FIG. 31	Architecture diagram (3100) of 3D mapping engine receiving Lidar log 3172, camera log 3174, radar log 3176, trajectory log 3140 data, with loop closure detector 3150, 3D mapper 3154, Lidar self-calibration 3156, generating 3D map data 3120 for fleet 3164, simulator 3166, and teleoperator 3168.Search in Eureka ↗	System architecture
FIG. 32	Diagram (3200) of autonomous vehicle application on mobile device 3203 showing AV service application 3240 with transportation controller 3242, AV user controller 3244, user identification controller 3246 communicating with autonomous vehicle 3230 via links 3260-3262 to AV service platform 3201.Search in Eureka ↗	UI/interface
FIG. 33	Computing platform diagram (3300) showing processor 3304, memory 3306, storage device 3308, communication interface 3313 with AV controller module 3350 for implementing autonomous vehicle service functions, deployable in autonomous vehicle 3391 or mobile device 3390b.Search in Eureka ↗	Claim support
FIG. 34	Computing platform diagram (3400) showing autonomous vehicle service platform module 3450 in memory 3306 for implementing teleoperator manager and simulator functions of the autonomous vehicle service platform.Search in Eureka ↗	Claim support
FIG. 35	Computing platform diagram (3500) showing AV service module 3550 in memory 3306 for mobile computing device 3390b delivering autonomous vehicle service functionalities.Search in Eureka ↗	Claim support
FIG. 36	Policy explorer diagram (3600) showing road network 3650 with autonomous vehicles 3630/3630a, planner 3670 with telemetry data 3671 and policy data 3672, policy explorer 3699 accessing repositories 3693-3697 to generate updated policy data 3694 communicated to fleet vehicles.Search in Eureka ↗	Key embodiment
FIG. 37	Flow chart (3700) for generating updated policy data: receiving telemetry and policy data (3702), extracting confidence level (3704), determining state of operation (3706), calculating candidate trajectories with confidence levels (3708), generating updated policy data (3710), communicating updated policy data (3712).Search in Eureka ↗	Flow diagram
FIG. 38	Diagram (3800) showing policy explorer 3899 implemented in simulator 3840 accessing physics processor 3850, correlator 3861, comparator 3862, statistical change point detector 3864 to generate updated policy data 3894 communicated to teleoperator 3894, autonomous vehicles 3830, and data repository 3890.Search in Eureka ↗	Key embodiment
FIG. 39	Diagram (3900) showing policy explorer 3999 implemented in teleoperator 3940 accessing correlator 3961, comparator 3962, change point detector 3964 to generate updated policy data 3994 communicated to simulator 3990, autonomous vehicles 3930, and data repository 3991.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 patent presents 3 independent claims covering method (Claim 1), system/apparatus (Claim 7), and non-transitory computer-readable medium/CRM (Claim 14) — a complete tripartite structure providing enforcement coverage across all major claim types. The 17 dependent claims yield a 5.67:1 dependent-to-independent ratio, above the typical 4–8:1 norm for this G05D IPC class but functionally moderate given the breadth of each independent claim. A notable strategic choice is that all three independent claims are structurally parallel, sharing nearly identical core limitations around the ML training loop on teleoperator interactions, which concentrates validity risk at a single claim nucleus.

Core inventive concept: The claims address the problem of autonomous vehicles encountering events that exceed their autonomous decision-making confidence — solved by a machine-learning feedback loop in which teleoperator interactions with events are captured and used to train an ML model to "output a recommended action based at least in part on at least one of the sensor data or the event data" (Claims 1, 7, 14), progressively improving autonomous event resolution without direct human intervention at each future encounter.

Independent Claim Dissection

Claim	Preamble	Transition	Key Body Elements
Claim 1	A method comprising	comprising	receiving sensor data from an autonomous vehicle; determining an event in a region of an environment based on sensor data, event associated with event data; receiving a teleoperator interaction associated with the event including a communication transmitted to and causing AV to perform an action; training based on teleoperator interaction and event a machine-learning (ML) model to output a recommended action based on sensor data or event dataSearch prior art ↗
Claim 7	A system comprising	comprising	one or more processors; memory having stored processor-executable instructions that when executed cause: receiving sensor data from AV; determining event in region of environment; receiving teleoperator interaction associated with event, the interaction associated with communication transmitted to AV; training based on teleoperator interaction and event a machine-learning (ML) model to output a recommended actionSearch prior art ↗
Claim 14	A non-transitory computer-readable medium comprising processor-executable instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising	comprising	receiving sensor data associated with AV; determining event in region of environment based on sensor data, event associated with event data; receiving teleoperator interaction associated with event; training based on teleoperator interaction and event a machine-learning (ML) model to output a recommended action based on sensor data or event dataSearch prior art ↗

Claim Dependency Tree

1 Method: receive AV sensor data → determine event → receive teleoperator interaction → train ML model for recommended actionSearch Claim 1 prior art ↗

2 Adds: receiving additional sensor data from AV or additional vehicle; determining additional event; ML model determines first recommended action; causing display of recommended actionSearch in Eureka ↗

3 Adds: simulating result of implementing first recommended action; causing alert or affirmation display based on simulation resultSearch in Eureka ↗

4 Adds: determining second recommended action based on simulationSearch in Eureka ↗

5 Further: causing at least one of first or second recommended action to be displayedSearch in Eureka ↗

6 Adds: recommended action comprises candidate trajectory, candidate path, region to include/exclude, rule modification, or additional/alternate event identificationSearch in Eureka ↗

7 System: processor + memory with instructions to receive AV sensor data → determine event → receive teleoperator interaction → train ML modelSearch Claim 7 prior art ↗

8 Adds: receiving additional sensor data; determining additional event; ML model determines recommended action; causing display of recommended actionSearch in Eureka ↗

9 Adds: determining confidence level associated with recommended actionSearch in Eureka ↗

10 Adds: simulating result of controlling AV in accordance with recommended action; causing alert or affirmation display based on resultSearch in Eureka ↗

11 Adds: event data and additional event data comprise at least one matching attributeSearch in Eureka ↗

12 Adds: determining additional recommended action based on simulation; causing display of first or additional recommended actionSearch in Eureka ↗

13 Adds: recommended action comprises candidate trajectory, candidate path, region inclusion/exclusion, rule modification, or additional/alternate event identificationSearch in Eureka ↗

14 CRM: non-transitory computer-readable medium with instructions to receive AV sensor data → determine event → receive teleoperator interaction → train ML modelSearch Claim 14 prior art ↗

15 Adds: receiving additional sensor data; determining additional event with additional event data; ML model determines first recommended action; causing displaySearch in Eureka ↗

16 Adds: determining confidence level associated with first recommended action and causing confidence level displaySearch in Eureka ↗

17 Adds: simulating result of controlling AV or additional vehicle with first recommended action; causing alert or affirmation displaySearch in Eureka ↗

18 Adds: event data and additional event data comprise at least one matching attributeSearch in Eureka ↗

19 Adds: determining second recommended action based on simulation; causing display of first or second recommended actionSearch in Eureka ↗

20 Adds: recommended action comprises candidate trajectory or candidate path, region inclusion/exclusion, rule modification, or additional/alternate event identificationSearch in Eureka ↗

Metric	This Application	Autonomous Vehicle / Software Industry Norm
Total claims	20	15 – 25
Independent claim count	3	2 – 4
Dependent : Independent ratio	5.67 : 1	4 – 8 : 1
Method claims present?	Yes — Claim 1	Common
System / apparatus claims?	Yes — Claim 7	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 structural completeness through its tripartite method/system/CRM claim architecture and a large, technically rich specification. However, the three independent claims are near-verbatim replicas of each other with only superficial format changes — a strategic weakness that concentrates invalidity risk and limits prosecution flexibility, particularly given the absence of any explicitly claimed ML model architecture or training mechanism specificity in Claims 1, 7, and 14.

✅

Antecedent Basis

Antecedent basis is generally well-managed across the 20 claims. Key referential terms are properly introduced: "an autonomous vehicle" in Claims 1, 7, and 14 is later referenced as "the autonomous vehicle" correctly throughout. In Claim 8 (dependent on Claim 7), "additional sensor data" is introduced and later referenced as "the additional sensor data" properly in Claims 9-12. One minor concern exists in Claim 11, which references "the event data and the additional event data" — "the additional event data" is only implicitly introduced via Claim 8's "additional event" without explicit recital of the data noun, creating a possible §112(a) challenge.

Explore in Eureka ↗

✅

Spec–Claim Consistency

The specification provides strong support for the core independent claim limitations. FIG. 14 and the description of teleoperator interaction capture analyzer 1416 at col. 21-22 directly support the "receiving a teleoperator interaction" limitation. FIG. 37 (flow chart 3700) and its description at col. 39-41 directly support the "training... a machine-learning (ML) model" limitation. FIG. 36 and the policy explorer 3699 description at col. 37-39 support the "event in a region of an environment" limitation. The specification's extensive treatment of confidence levels (FIG. 11, col. 18-19) also supports dependent claims 9 and 16.

Explore in Eureka ↗

✅

Transition Word Usage

All three independent claims use "comprising" — the broadest available transition — which is appropriate and strategically correct given the complex multi-system nature of autonomous vehicle teleoperation. The open-ended transition means additional steps (e.g., sensor fusion, localization) do not defeat infringement. No "consisting of" or "consisting essentially of" transitions appear in the independent claims, and no narrowing transitions appear in the dependent claims either, maintaining claim breadth throughout the dependency chain.

Explore in Eureka ↗

⚠️

§112(f) Means-Plus-Function Risk

No explicit "means for" language appears in the claims, which reduces §112(f) risk. However, Claim 7 recites "memory having stored thereon processor-executable instructions that, when executed by the one or more processors, cause the system to perform operations" — a nonce-word structure that courts have sometimes found to invoke §112(f) for the "system" as a whole. If a court collapses the system claim into a means-plus-function interpretation, the specification's disclosure of specific structural components (planner 464, teleoperator interaction capture analyzer 1416, policy explorer 3699) would be limiting. The risk is moderate but manageable given the detailed hardware description in FIGS. 33-35.

Explore in Eureka ↗

⚠️

§101 Eligibility Risk

The independent claims recite receiving sensor data, determining an event, receiving a teleoperator interaction, and training an ML model — a sequence that an examiner could characterize under Alice Step 1 as an abstract idea of "collecting, analyzing, and organizing information using machine learning." The §101 defense rests on the tie to an autonomous vehicle and physical action ("communication transmitted to the autonomous vehicle and configured to cause the autonomous vehicle to perform an action" in Claim 1), which grounds the claims in a concrete physical system. However, Claim 14 (CRM) is the most vulnerable, as it lacks explicit recitation of the physical vehicle performing the action beyond a "recommended action" output — a gap that could draw a §101 rejection in reexamination or IPR.

Explore in Eureka ↗

⚠️

Dependent Claim Fallback Quality

The dependent claims exhibit significant parallel redundancy across the three independent claim branches — Claims 2-6 (method), 8-13 (system), and 15-20 (CRM) are structurally identical, adding no unique technical fallback not already present in the parallel branch. Claims 3, 10, and 17 all add simulation-based validation, Claims 4/12/19 add simulation-based secondary recommendations, and Claims 6/13/20 define recommended action types. The most substantive distinct fallback is Claim 9/16, which adds confidence level determination and display — this creates a meaningful additional fallback. Claims 11 and 18 (matching event attributes) add a useful data-matching limitation but are similarly parallel.

Explore in Eureka ↗

⚠️

Abstract Quality

The abstract describes the system as applying "artificial intelligence and/or machine learning techniques to predict an optimal course of action" for an autonomous vehicle system, and mentions semantic scene classification and aggregated sensor data. While accurate, the abstract fails to identify the specific ML feedback loop through teleoperator interactions that is the core novel mechanism claimed — an examiner reading only the abstract would identify "ML for AV path planning" rather than the more specific "teleoperator-interaction-trained ML model" that distinguishes Claims 1, 7, and 14. This creates a mismatch between the abstract's representation of the invention and the actual claimed contribution.

Explore in Eureka ↗

✅

Figure Support Quality

Figure support is extensive and well-mapped to claim limitations. The ML training loop (Claims 1/7/14) maps directly to FIG. 14 (teleoperator interaction capture analyzer 1416) and FIG. 37 (flow chart 3700 stages 3702-3710). The event determination limitation maps to FIG. 36 (policy explorer 3699) and FIG. 11 (confidence level generator 1123). The teleoperator interaction limitation maps to FIGS. 9-10 (teleoperation data flow and UI). The simulation-based dependent claims (3/10/17) map to FIGS. 28-29. The confidence level display limitation (Claims 9/16) maps to FIG. 10's UI display showing speed/charge data. No independent claim limitation appears to lack figure support.

Explore in Eureka ↗

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.2

Spec–Claim Consistency

4.2

Dependent Claim Coverage

2.5

Claim Type Diversity

4.5

Figure Support Quality

4.3

Key observation: Claim Type Diversity scores highest (4.5/5.0) because Zoox effectively covered method, system, and CRM claim types in Claims 1, 7, and 14 respectively, closing all major design-around vectors across implementation modalities. Dependent Claim Coverage scores lowest (2.5/5.0) because Claims 2-6, 8-13, and 15-20 are structurally parallel triplicates that add no independent fallback positions beyond what appears in the other branches — a competitor who invalidates Claim 2 effectively invalidates Claims 8 and 15 simultaneously. Practitioners should note that continuation filings adding unique dependent limitations (e.g., specific ML model architectures, confidence threshold values, or multi-vehicle fleet training scenarios) would substantially strengthen the portfolio's defensive depth.

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.

GAP 01 · HIGHEST IMPACT

ML Model Architecture Entirely Unclaimed — Design-Around Trivial

Claims 1, 7, and 14 recite only "training... a machine-learning (ML) model" without specifying model type, training architecture, loss function, input features, or training data structure — the entire technical substance of the ML implementation is absent from all independent claims. This creates a critical design-around risk: a competitor implementing a rule-based system, a statistical model, or a different ML paradigm (e.g., reinforcement learning without explicit teleoperator training) can argue non-infringement while achieving the same functional result of recommending actions from teleoperator interactions. A stronger filing would have included at least one independent claim reciting structural ML limitations (e.g., neural network layers, training corpus structure, or feature extraction from sensor modalities) and additional dependent claims specifying model types as fallback positions.

GAP 02 · HIGH IMPACT

No Apparatus Claims on Physical AV Hardware Components

The system claim (Claim 7) is directed to a generic "processor + memory" computing platform rather than an autonomous vehicle apparatus per se — the claim does not recite sensors, actuators, or vehicle hardware, meaning a competitor implementing the ML training on cloud infrastructure separate from any vehicle avoids the system claim entirely. This structural weakness means competitors operating pure cloud-based teleoperation ML training platforms (processing AV data remotely) are not covered by Claim 7. A stronger filing would have included an apparatus claim directed to the autonomous vehicle itself comprising sensors, a vehicle controller, and an ML training subsystem coupled to a teleoperator interface, as well as a cloud-platform apparatus claim separately.

GAP 03 · HIGH IMPACT

Fleet-Level Multi-Vehicle ML Training Not Captured in Independent Claims

Unlock to read the full analysis.

🔒

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.

ML architecture entirely unclaimed No physical AV apparatus claims Fleet-level multi-vehicle ML training uncaptured

Unlock Full Analysis — Free

Frequently asked questions

US 11,061,398 B2 — key questions answered

What does US 11,061,398 B2 protect?+

Who owns patent US 11,061,398 B2?+

What are the independent claims of US 11,061,398 B2?+

What technology does this patent cover?+

What IPC classifications does this patent use?+

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.

Link copied to clipboard

AI AGENTS

AI APPLICATIONS

OTHERS

INDUSTRIES

USE CASES

EXPLORE

ENGAGE

SUPPORT & SERVICES

Your Agentic AI Partner
for Smarter Innovation

Great, Please verify your email.

Patent Drafting Analysis of Zoox, Inc.’s Machine-Learning AV Teleoperation Optimization System | US 11,061,398 B2

Patent Drafting Analysis of Zoox's Machine-Learning AV Teleoperation Optimization System | US 11,061,398 B2