Patent Drafting Analysis of NVIDIA’s Hybrid Differentiable Rendering for Light Transport Simulation | US 11,922,558 B2

IP Drafting Analysis · US 11,922,558 B2

Patent Drafting Analysis of NVIDIA's Hybrid Differentiable Rendering for Light Transport Simulation | US 11,922,558 B2

Q: What does US 11,922,558 B2 protect?

US 11,922,558 B2 protects a hybrid differentiable rendering system and method that combines rasterization with specular light transport simulation (via BRDF evaluation) to compute radiance values and determine pixel values for 3D models. The patent covers method, system, and processor claim types, solving the problem of achieving physically accurate lighting in a computationally tractable, end-to-end differentiable rendering pipeline suitable for training machine learning models. The core mechanism involves rasterizing a virtual frame using 3D geometry information to map pixels to 3D model portions, then computing radiance using specular light transport simulation to determine final pixel values.

Q: Who owns patent US 11,922,558 B2?

US 11,922,558 B2 is assigned to NVIDIA Corporation, headquartered in Santa Clara, California, US. The inventors are Wenzheng Chen (Toronto, CA), Joey Litalien (Montreal, CA), Jun Gao (North York, CA), Zian Wang (Toronto, CA), Clement Tse Tsian Christophe Louis Fuji Tsang (Toronto, CA), Sameh Khamis (Oakland, CA, US), Or Litany (Sunnyvale, CA, US), and Sanja Fidler (Toronto, CA).

Q: What are the independent claims of US 11,922,558 B2?

Claim 1 is a method claim covering: rasterizing a virtual frame depicting 3D models using 3D geometry information; computing radiance values for model portions using specular light transport simulation; and determining pixel values based on those radiance values. Claim 10 is a system claim covering processing units that generate 3D geometry information using machine learning models (MLMs), rasterize 3D models, compute radiance via specular light transport, and update MLM parameters based on radiance values. Claim 16 is a processor claim covering circuits that determine pixel values for virtual frame pixels based on specular light transport simulation radiance values corresponding to 3D model portions.

Q: What technology does this patent cover?

This patent covers a rendering technology that generates realistic-looking images of 3D objects by combining two normally separate techniques: rasterization (a fast method for mapping 3D geometry to pixels) and ray-tracing-style light simulation (which accurately models how light bounces off surfaces). The key innovation is making this combined rendering process mathematically differentiable — meaning the system can automatically calculate how to improve its outputs — so it can be used to train AI models to understand materials, lighting, and geometry from real images without needing expensive manual labeling or controlled capture setups.

Q: What IPC classifications does this patent use?

G06T 15/06 (2011.01) — Image generation of three-dimensional [3D] objects, involving illumination models. G06T 15/50 (2011.01) — Shading. G06T 19/20 (2011.01) — Editing of 3D images, e.g. changing shapes or appearance, painting texture on an object.

A structural and strategic analysis of NVIDIA's hybrid differentiable rendering patent, covering claim architecture, drafting quality signals, critical gaps, and prosecution positioning across method, system, and processor claim types.

US 11,922,558 B2Filed: May 27, 2022Granted: Mar. 5, 2024G06T 15/06G06T 15/50G06T 19/20

Draft a Patent Like This Explore Related Patents

Spec Words

9,200

Across 6 sections

Draft now ↗

Total Claims

3 independent · 17 dependent

Draft now ↗

Figure Sheets

Pipeline, geometry, BRDF, flow diagrams, hardware

Draft now ↗

Published by PatSnap Insights Team · June 4, 2026 · 12 min read Verified by PatSnap Eureka Data

Overview

Structural Overview

The detailed description dominates at approximately 60% of total words (~5,850 words across 9 specification columns), with the claims section itself representing a substantial ~30%, reflecting the technical density of the 20-claim set. The patent deploys 3 independent claims across method (Claim 1), system (Claim 10), and processor (Claim 16) types, supported by 17 dependent claims yielding a 5.67:1 dependent-to-independent ratio. The 9 drawing sheets provide layered coverage of the pipeline architecture (FIG. 1), geometry and BRDF concepts (FIGS. 2A–2D), the training loop (FIG. 3), method flows (FIGS. 4–5), and hardware/infrastructure contexts (FIGS. 6–7).

Section Word Distribution

↗ Click bars to explore

Figure Inventory — 9 Sheets

Figure	Description	Role
FIG. 1	High-level pipeline diagram showing input data 120 flowing through machine learning model(s) 102, geometry projector 104, rasterizer 106, light transport simulator 108, and pixel determiner 110 to output data 130, with input/output image pairs 116/132.Search in Eureka ↗	System architecture
FIG. 2A	Geometry projection and rasterization example showing 3D model M (geometry 226), image plane 202, camera 206, ray 204, surface point 210/212, color information 218, surface normals 214, and model mask 216.Search in Eureka ↗	Key embodiment
FIG. 2B	Light transport simulation diagram illustrating BRDF 222 at surface point x, surface normal n, outgoing direction ω_o, incoming light direction ω_i, and incident radiance L_i with multiple SG sphere representations.Search in Eureka ↗	Claim support
FIG. 2C	Comparison of environmental lighting representations showing Monte Carlo (MC) lighting model 220A and spherical Gaussian (SG) lighting model 220B rendered outputs side by side.Search in Eureka ↗	Key embodiment
FIG. 2D	Example rendered output images 132 and 232 showing tiger model rendered under MC and SG lighting models respectively to illustrate visual quality of hybrid differentiable rendering output.Search in Eureka ↗	Other
FIG. 3	Training loop system diagram 300 showing machine learning model(s) 102 connected to geometry projector 104, rasterizer 106, light transport simulator 108, pixel determiner 110, output analyzer 308, training engine 304, loss function data 314, and parameter adjuster 306 with update data 316.Search in Eureka ↗	System architecture
FIG. 4	Flow diagram 600 of method for rendering an image using hybrid differentiable rendering, showing steps B502 (receive 3D geometry), B504 (rasterize 3D models), B506 (compute radiance), and B508 (determine pixel values).Search in Eureka ↗	Flow diagram
FIG. 5	Flow diagram 500 of method for training MLMs using hybrid differentiable render, showing steps: generate 3D geometry information using MLMs, rasterize B504, compute radiance B506, and update MLM parameters B508 based on radiance.Search in Eureka ↗	Flow diagram
FIG. 6	Block diagram of example computing device 600 showing interconnect system 602 coupling memory 604, CPU(s) 606, GPU(s) 608, communication interface 610, I/O ports 612, I/O components 614, power supply 616, presentation components 618, and logic units 620.Search in Eureka ↗	System architecture
FIG. 7	Block diagram of example data center 700 showing layered architecture including data center infrastructure layer 710 (with resource orchestrator 712, grouped computing resources 714, node C.R.s 716), framework layer 720, software layer 730, and application layer 740.Search in Eureka ↗	Other

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: Claim 1 (method), Claim 10 (system), and Claim 16 (processor), providing tripartite coverage across core claim types. The 5.67:1 dependent-to-independent ratio (17 dependents across 3 independents) is at the lower-middle end for G06T computer graphics patents, which typically see 4–8:1. The claim strategy notably omits a computer-readable medium (CRM) claim type, leaving a significant design-around opportunity, while Claim 15 and Claim 20 create broad downstream application fallback positions through their enumerated use-context limitations.

Core inventive concept: The claims solve the problem of rendering 3D models with physically accurate lighting effects while remaining computationally tractable and differentiable for ML training — by combining rasterization (Claim 1: "rasterizing a virtual frame...using three-dimensional (3D) geometry information") with specular light transport simulation via BRDF evaluation, then using the resulting radiance values to determine pixel values and/or update ML model parameters. This hybrid approach, as recited across Claims 1, 10, and 16, enables end-to-end differentiable gradient flow through the rendering pipeline for tasks such as disentangling material properties from lighting.

Independent Claim Dissection

Claim	Preamble	Transition	Key Body Elements
Claim 1	A method comprising:	comprising	rasterizing a virtual frame depicting one or more 3D models using 3D geometry information to determine portions corresponding to pixels; computing radiance values for those portions using specular light transport simulation; determining pixel values based on the radiance valuesSearch prior art ↗
Claim 10	A system comprising:	comprising	one or more processing units performing operations: generating 3D geometry information using MLMs; rasterizing 3D models using 3D geometry information; computing radiance values using specular light transport simulation; updating MLM parameters based on radiance valuesSearch prior art ↗
Claim 16	A processor comprising:	comprising	one or more circuits to determine, based on radiance values computed using specular light transport simulation, pixel values for pixels of a virtual frame depicting 3D models, where radiance values correspond to portions of the 3D models that correspond to the pixelsSearch prior art ↗

Claim Dependency Tree

1 Method: rasterize virtual frame using 3D geometry; compute radiance via specular light transport; determine pixel valuesSearch Claim 1 prior art ↗

2 Adds: projecting 3D model portion onto image plane via rays from cameras; identifying intersection points for radiance computationSearch in Eureka ↗

3 Adds: specular light transport simulation includes evaluating a specular BRDF with respect to the 3D model portionsSearch in Eureka ↗

4 Further: specular BRDF sampled via ray-tracing or represented using spherical Gaussian basis (depends on Claim 3)Search in Eureka ↗

5 Adds: applying images of objects to neural networks trained to predict 3D geometry and color information; pixel values further based on color informationSearch in Eureka ↗

6 Adds: specular light transport simulation uses surface normal information corresponding to the 3D model portionsSearch in Eureka ↗

7 Adds: generating color information using neural networks to disentangle color from lighting; pixel values further determined based on color informationSearch in Eureka ↗

8 Adds: determining pixel values includes modifying lighting using radiance values and computing pixel values using modified lighting dataSearch in Eureka ↗

9 Adds: determining pixel values includes modifying color information to generate modified color data and computing pixel values from that dataSearch in Eureka ↗

10 System: processing units generate 3D geometry via MLMs; rasterize; compute radiance via specular light transport; update MLM parameters on radianceSearch Claim 10 prior art ↗

11 Adds: generating data is based on MLMs processing image data representative of objects corresponding to the 3D modelsSearch in Eureka ↗

12 Adds: rasterizing uses differentiable mapping; updating parameters based on pixel values using differentiable parameterization of shadingSearch in Eureka ↗

13 Adds: data further indicative of environmental lighting map; specular light transport based on incoming radiance from environmental lighting mapSearch in Eureka ↗

14 Adds: updating based on comparing first pixel values generated using radiance values to second pixel values from input data to the MLMsSearch in Eureka ↗

15 Adds: system comprises at least one of: autonomous machine control/perception, simulation, digital twin, light transport, collaborative 3D, deep learning, edge, robot, conversational AI, synthetic data, VM, data center, or cloudSearch in Eureka ↗

16 Processor: circuits determine pixel values for virtual frame pixels based on specular light transport radiance values corresponding to 3D model portionsSearch Claim 16 prior art ↗

17 Adds: specular light transport simulation includes evaluating a specular BRDFSearch in Eureka ↗

18 Further: evaluating specular BRDF includes sampling via ray-tracing or representing using spherical Gaussian basis (depends on Claim 17)Search in Eureka ↗

19 Adds: circuits further apply images of objects to neural networks trained to predict 3D geometry and color information; pixel values further based on geometry and color informationSearch in Eureka ↗

20 Adds: processor comprises at least one of: autonomous machine control/perception, simulation, digital twin, light transport, collaborative 3D, deep learning, edge, robot, conversational AI, synthetic data, VM, data center, or cloudSearch in Eureka ↗

Metric	This Application	Software / Cloud 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 — Claims 10, 16	Common

Analysis powered by PatSnap Eureka. Patent text and figures publicly available from USPTO. Draft a Similar Patent

Drafting Quality

Drafting Quality Signals

The claim set demonstrates strong technical specificity in its BRDF and light transport simulation recitations (Claims 3, 4, 17, 18), providing meaningful prosecution fallback, while the broad "comprising" transitions in all three independent claims preserve maximum scope. The most significant quality concern is the absence of a computer-readable medium (CRM) claim and the near-identical parallel structure of Claims 3–4 and 17–18 across method and processor independent claims, which adds redundancy without expanding coverage.

✅

Antecedent Basis

The claim set is largely clean on antecedent basis. The "one or more 3D models" introduced in Claim 1's rasterization step is consistently referenced as "the one or more 3D models" throughout Claims 1, 2, and 3. Similarly, "the one or more radiance values" in Claim 1's determination step traces cleanly to "one or more radiance values" in the computing step. Claim 10's parallel structure mirrors this pattern without introducing orphaned references.

Explore in Eureka ↗

✅

Spec–Claim Consistency

The independent claim limitations map directly to specific figures and paragraphs. The rasterization step of Claim 1 is supported by FIG. 1 (rasterizer 106), FIG. 2A (rasterization of 3D geometry 226), and columns 7–8 of the detailed description. The specular light transport simulation limitation maps to FIG. 2B (BRDF 222) and columns 9–10. The pixel determination step maps to FIG. 4 step B508. All three independent claim structures are well-anchored in the specification.

Explore in Eureka ↗

✅

Transition Word Usage

All three independent claims (1, 10, 16) use "comprising" as the transition, which is the broadest available choice and appropriate for a software/AI pipeline patent where unclaimed additional steps should not defeat infringement. The dependent claims also use "comprising" or introduce new limitations by substitution, consistent with open-ended claim drafting norms for G06T class patents. No narrowing "consisting of" language appears, preserving maximum scope.

Explore in Eureka ↗

⚠️

§112(f) Means-Plus-Function Risk

Claim 16 recites "one or more circuits to determine" — a functional claim element without explicit structural definition beyond the broad term "circuits." While "circuits" has been treated as structural by some courts, the purely functional recitation ("to determine...pixel values") without specifying circuit topology may invite §112(f) interpretation in litigation. The specification's FIG. 6 shows generic CPU/GPU hardware (606, 608) but does not disclose specific circuit structures corresponding to the claimed determination function, which could limit claim scope if §112(f) is triggered.

Explore in Eureka ↗

⚠️

§101 Eligibility Risk

Claims 1 and 10 have moderate Alice exposure as the core operations — rasterizing, computing radiance, determining pixel values — are abstract mathematical/computational concepts. The §101 defense rests primarily on the hardware tie-in in Claim 16 ("a processor comprising one or more circuits") and the system claim in Claim 10 ("one or more processing units"), but Claim 1 as a pure method claim lacks explicit hardware anchoring. The specification's references to GPUs (608) and specific rendering pipeline components provide written description support, but prosecution may require amendment to add hardware nexus language to Claim 1 in any continuation.

Explore in Eureka ↗

⚠️

Dependent Claim Fallback Quality

The dependent claims show significant structural redundancy: Claims 3–4 (method) and Claims 17–18 (processor) are nearly identical in subject matter — both add the specular BRDF evaluation and spherical Gaussian representation. This parallelism consumes 4 of 17 dependent claim slots without extending coverage. In contrast, Claims 5 and 7 (neural network color disentanglement) and Claim 12 (differentiable mapping with differentiable parameterization of shading) add genuinely distinct fallback positions. Claims 15 and 20 (use-context lists) are unlikely to add meaningful claim scope in inter partes review.

Explore in Eureka ↗

⚠️

Abstract Quality

The abstract accurately describes the hardware pipeline and ML training approach but omits the critical distinguishing feature — the combination of rasterization (for pixel-to-geometry mapping) with specular BRDF-based light transport simulation in an end-to-end differentiable pipeline. An examiner reading only the abstract would identify the domain (3D model rendering) but might fail to distinguish the invention from standard rasterization or standard ray-tracing approaches, potentially broadening the prior art search to include conventional renderers rather than focusing on hybrid differentiable methods.

Explore in Eureka ↗

✅

Figure Support Quality

Figure coverage of claim limitations is strong. FIG. 1 provides system pipeline support for all three independent claim structures. FIG. 2A supports the rasterization and pixel-to-geometry mapping limitations in Claims 1 and 10. FIG. 2B directly supports the specular BRDF/light transport simulation limitations in Claims 1, 3, 10, 16, and 17. FIG. 3 supports the MLM parameter update limitation in Claim 10. The one gap is that no figure specifically illustrates the differentiable parameterization of shading recited in Claim 12, which relies entirely on textual description in column 8.

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

Spec–Claim Consistency

4.2

Dependent Claim Coverage

Claim Type Diversity

Figure Support Quality

Key observation: The highest-scoring dimension is Spec–Claim Consistency (4.2/5.0) — every independent claim limitation maps to a specific figure and paragraph in the detailed description, with FIG. 2B providing explicit BRDF geometry support for the specular light transport recitations in Claims 1, 3, 10, 16, and 17. The lowest-scoring dimensions are Dependent Claim Coverage and Claim Type Diversity (both 3.0/5.0): the near-identical mirroring of Claims 3–4 across Claims 17–18 wastes fallback positions, and the complete absence of a computer-readable medium (CRM) claim leaves a major design-around path open for competitors who implement the same algorithm in software without dedicated processor hardware. Practitioners reviewing this patent for FTO or continuation strategy should prioritize filing CRM claims and restructuring dependent claims to cover the differentiable shading parameterization of Claim 12 as a standalone independent.

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

No Computer-Readable Medium Claim Filed

The claim set covers method (Claim 1), system (Claim 10), and processor (Claim 16) types but completely omits a computer-readable medium (CRM) or non-transitory storage medium claim, leaving uncovered any embodiment where the hybrid differentiable rendering pipeline is implemented purely as executable software stored on a medium without requiring a dedicated processor structure. A competitor could design around all three independent claims by distributing the pipeline as a software package (e.g., a Python library or CUDA toolkit) without infringing the processor limitation of Claim 16 or the processing unit structure of Claim 10. A stronger filing would have included a fourth independent CRM claim reciting non-transitory computer-readable media storing instructions that, when executed by a processor, perform the rasterization, radiance computation, and pixel determination steps of Claim 1.

GAP 02 · HIGH IMPACT

Method Claim 1 Lacks Hardware Nexus for §101 Defense

Claim 1's preamble recites only "A method comprising" with no hardware anchor — all three operative steps (rasterizing, computing radiance, determining pixel values) are recited as pure functional operations without naming a processor, GPU, or computing system. This creates an Alice/Mayo vulnerability: under step two of the Alice framework, an examiner or inter partes review petitioner could argue that rasterization and BRDF-based radiance computation are abstract mathematical operations applied without an inventive concept, since the claim does not specify a particular machine. The specification's detailed GPU and computing device descriptions (FIG. 6, columns 13–16) provide written description support that was not incorporated into Claim 1. A stronger filing would have included a preamble recitation such as "A computer-implemented method" or added a step reciting execution on a graphics processing unit.

GAP 03 · HIGH IMPACT

Differentiable Mapping Limitation Underclaimed

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.

No CRM claim filed Method claim lacks hardware anchor Differentiable mapping underclaimed in independents

Unlock Full Analysis — Free

Frequently asked questions

US 11,922,558 B2 — key questions answered

What does US 11,922,558 B2 protect?+

Who owns patent US 11,922,558 B2?+

What are the independent claims of US 11,922,558 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 NVIDIA’s Hybrid Differentiable Rendering for Light Transport Simulation | US 11,922,558 B2

Patent Drafting Analysis of NVIDIA's Hybrid Differentiable Rendering for Light Transport Simulation | US 11,922,558 B2