Patent Drafting Analysis of NVIDIA Corporation’s Ray-Traced Light Resampling Using Screen Space Visibility | US 11,922,556 B2

IP Drafting Analysis · US 11,922,556 B2

Patent Drafting Analysis of NVIDIA Corporation's Ray-Traced Light Resampling Using Screen Space Visibility | US 11,922,556 B2

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

US 11,922,556 B2 protects a ray-traced image rendering technique that addresses the high computational cost of final visibility rays in the ReSTIR (Reservoir-based Spatio-Temporal Importance Resampling) method. The patent covers method, system, and machine-readable medium claims directed to computing lighting effects for a first image region using a visibility parameter obtained from a final visibility ray, then reusing that visibility parameter to determine lighting for a second image region that neighbors the first either spatially (same frame, adjacent pixel) or temporally (same pixel, adjacent frame). The key mechanism includes age and distance thresholds that control how long and how far a visibility parameter can be reused before a new final visibility ray must be traced.

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

US 11,922,556 B2 is owned by NVIDIA CORPORATION, headquartered in Santa Clara, California, United States. The sole listed inventor is Alexey Yuryevich Panteleev, located in El Dorado Hills, California, United States.

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

Claim 1 is a computer-implemented method claim covering computing lighting effects for a first image region using a visibility parameter from a final visibility ray, and reusing that parameter to compute lighting for a neighboring image region spatially or temporally. Claim 13 is a system claim covering processors and memories that obtain light samples via cheaper first rays, trace an expensive second ray to determine a visibility parameter, and determine a second amount of light for a neighboring image region based on that parameter. Claim 20 is a non-transitory machine-readable medium (CRM) claim covering instructions that determine a second amount of light for a second image region based on a visibility parameter determined for a first image region using a higher-quality first ray.

Q: What technology does this patent cover?

This patent covers a technique to make realistic 3D image rendering — specifically ray tracing, which simulates how light bounces around a scene — faster and more efficient. Ray tracing normally requires expensive computations called 'visibility rays' for every pixel of every frame. This patent's innovation is to reuse those expensive visibility calculations from one pixel for neighboring pixels in the same frame, or for the same pixel in nearby video frames, rather than recomputing them from scratch. To prevent visual artifacts from stale reuse, the system tracks how old a visibility calculation is and how far it has traveled across the screen, automatically discarding it and computing a fresh one when it gets too old or too far displaced.

Q: What IPC classifications does this patent use?

G06T 15/06 (2011.01) — Image generation, i.e. processing of two-dimensional [2D] or three-dimensional [3D] data: rendering, specifically relating to 3D rendering with ray tracing. G06T 15/50 (2011.01) — Image generation, relating to shading.

A structural and strategic analysis of US 11,922,556 B2 examining claim architecture, drafting quality, critical gaps, and prosecution positioning for NVIDIA's ReSTIR visibility parameter reuse rendering technology.

US 11,922,556 B2Filed: Apr 12, 2021Granted: Mar 5, 2024G06T 15/06G06T 15/50

Draft a Patent Like This Explore Related Patents

Spec Words

18,400

Across 6 sections

Draft now ↗

Total Claims

3 independent · 24 dependent

Draft now ↗

Figure Sheets

Rendering methods, reservoir structures, GPU/processor architectures, software stacks

Draft now ↗

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

Overview

Structural Overview

The detailed description dominates at approximately 71% of total specification words (~14,200 of ~18,400), providing extensive GPU and software stack context that, while thorough for enablement, devotes substantial real estate to generic hardware descriptions unrelated to the core inventive concept. The claim architecture comprises 27 claims across three independent claims (Claims 1, 13, and 20) covering method, system, and CRM formats, with a dependent-to-independent ratio of 8:1. The 44 drawing sheets include both the core rendering method figures (FIGS. 1–6) and a very large set of generalized GPU architecture figures (FIGS. 7–38) that provide broad hardware context but add limited specific support for the novel visibility-reuse limitations.

Section Word Distribution

↗ Click bars to explore

Figure Inventory — 44 Sheets

Figure	Description	Role
FIG. 1	Block diagram of a computing system 100 with computing device 102, memory 106 storing instructions 104, 3D geometry module 108, image rendering module 110, and reservoirs 112.Search in Eureka ↗	Key embodiment
FIG. 2A	Example virtual camera 208 capturing image of scene 200 with surface 202, objects 203/204, and multiple light sources 206A-206C projecting onto pixel grid 220.Search in Eureka ↗	Key embodiment
FIG. 2B	Light sources shining light on intersection point 212 on surface 202 that is reflected toward virtual camera 208, illustrating initial light sample directions A1–A4.Search in Eureka ↗	Key embodiment
FIG. 2C	Final visibility rays A1 and A4 shining light on intersection point 212 after occlusion testing, illustrating the third ReSTIR stage with selected final visibility rays.Search in Eureka ↗	Claim support
FIG. 3	Flow diagram of method 300 showing pixel-level rendering loop: receive 3D geometry, identify frame, select pixel/create reservoir, generate primary ray, generate/select light samples, check for neighbors, trace final visibility rays, store visibility parameters/age/distance, shade pixel, check for last pixel/frame.Search in Eureka ↗	Flow diagram
FIG. 4	Two successive frames 220 and 420 showing pixel 222 moving to pixel 422 and corresponding reservoirs 400, 424, and 434 with data fields: relevant samples 402, statistical info 404, visibility parameters 410, age 412, and distance 414.Search in Eureka ↗	Claim support
FIG. 5	Flow diagram of method 500 for neighboring reservoir processing: combine neighboring reservoirs, store final relevant light samples, obtain visibility parameters and age/distance values, evaluate age threshold (block 508) and distance threshold (block 510), then copy visibility parameters or trace new final visibility rays and store results.Search in Eureka ↗	Flow diagram
FIG. 6	Experimental output comparing raw sample images versus 1000+ accumulated frames at 0.1, 0.3, and 0.95 rays per pixel, demonstrating image quality improvements of method 300.Search in Eureka ↗	Other
FIG. 7	Exemplary data center 700 architecture with infrastructure layer 710, framework layer 720 (job scheduler 732, configuration manager 734, resource manager 736, distributed file system 738), software layer 730, and application layer 740.Search in Eureka ↗	System architecture
FIG. 8	Processing system 800 block diagram showing processor 802, graphics processor 808, memory device 820, external graphics processor 812, display device 811, platform controller hub 830, and various I/O controllers.Search in Eureka ↗	System architecture
FIG. 9	Computer system 900 block diagram with processor 910, display 924, touch screen 925, GPS 955, WWAN unit 956, WLAN unit 950, Bluetooth 952, SSD 920, and numerous sensors and I/O components.Search in Eureka ↗	System architecture
FIG. 10	System 1000 block diagram with processor 1010, memory controller hub 1016, graphics/video card 1012, I/O controller hub 1030, data storage 1024, wireless transceiver 1026, and network controller 1034.Search in Eureka ↗	System architecture
FIG. 11	Exemplary integrated circuit 1100 showing application processors 1105, graphics processor 1110, image processor 1115, video processor 1120, memory 1165, and various peripheral interface controllers including USB, UART, and HDMI.Search in Eureka ↗	System architecture
FIG. 12	Computing system 1200 with processing subsystem 1201 containing processors 1202, memory hub 1205, I/O subsystem 1211, parallel processors 1212, and display devices 1210A/B via I/O switch 1216.Search in Eureka ↗	System architecture
FIG. 13	AMD accelerated processing unit (APU) 1300 with core complex 1310, graphics complex 1340 (SIMD units 1352, shared memory 1354), fabric 1360, I/O interfaces 1370, memory controllers 1380, display controller 1392, and multimedia engine 1394.Search in Eureka ↗	System architecture
FIG. 14	AMD CPU 1400 showing core complexes 1410(1)-(N), core 1420 with fetch/decode unit 1422, integer execution engine 1424, floating point execution engine 1426, L2/L3 caches, fabric 1460, I/O interfaces 1470, and system memory 1490.Search in Eureka ↗	System architecture
FIG. 15	Exemplary accelerator integration slice 1590 showing processor 1507, system memory 1514 with application effective address space 1582 and OS virtual address space 1585, and graphics acceleration module 1546 with MMU 1539 and interrupt management 1547.Search in Eureka ↗	System architecture
FIG. 16A	Graphics processor 1610 of SoC type with vertex processor 1605, multiple fragment processors 1615A-1615N, MMUs 1620A/B, caches 1625A/B, and circuit interconnects 1630A/B.Search in Eureka ↗	System architecture
FIG. 16B	Higher-performance graphics processor 1640 featuring inter-core task manager 1645, multiple shader cores 1655A-1655N, tiling unit 1658, MMUs 1620A/B, caches 1625A/B, and interconnects 1630A/B.Search in Eureka ↗	System architecture
FIG. 17A	Graphics core 1700 with shared instruction cache 1702, texture unit 1718, slices 1701A-1701N each containing instruction cache, thread scheduler, thread dispatcher, registers, and execution units (AFU, FPU, ALU, ACU, DPFPU, MPU), plus cache/shared memory 1720.Search in Eureka ↗	System architecture
FIG. 17B	General-purpose graphics processing unit (GPGPU) 1730 with host interface 1732, global scheduler 1734, compute clusters 1736A-1736H, cache memory 1738, memory controllers 1742A/B, memory 1744A/B, I/O hub 1739, and GPU link 1740.Search in Eureka ↗	System architecture
FIG. 18A	Parallel processor 1800 architecture with parallel processing unit 1802 containing I/O unit 1804, front end 1808, scheduler 1810, processing array 1812 (clusters 1814A-1814N), memory crossbar 1816, memory partition units 1820A-1820N, and parallel processor memory 1822.Search in Eureka ↗	System architecture
FIG. 18B	Processing cluster 1894 showing pipeline manager 1832, graphics multiprocessor 1834, texture unit 1836, raster engine 1408, PROP unit 2404, data crossbar 1840, preROP 1842, MMU 1845, and L1 cache 1848.Search in Eureka ↗	System architecture
FIG. 18C	Graphics multiprocessor 1896 internals: instruction cache 1852, instruction unit 1854, address mapping unit 1856, register file 1858, GPGPU cores 1862, LSUs 1866, memory and cache interconnect 1868, shared memory 1870, and cache memory 1872.Search in Eureka ↗	System architecture
FIG. 19	Graphics processor 1900 showing ring interconnect 1902, pipeline front-end 1904, media engine 1937, and graphics cores 1980A-1980N each with sub-cores 1950A/1960A and shared resources 1970A including execution units and samplers.Search in Eureka ↗	System architecture
FIG. 20	Processor 2000 out-of-order execution engine 2003 with front end 2001, allocator/register renamer 2040, fast/slow schedulers, integer and FP register file/bypass networks 2008/2010, and execution block 2011 with AGUs, ALUs, FP units.Search in Eureka ↗	System architecture
FIG. 21	Processor 2100 with cores 2102A-2102N, integrated graphics processor 2108, cache units 2104A-2104N, shared cache units 2106, ring 2112, system agent core 2110 with display/memory controllers, I/O 2113, and embedded memory module 2118.Search in Eureka ↗	System architecture
FIG. 22	Graphics processor core 2200 showing graphics SoC interface 2237, graphics microcontroller 2238, fixed function block 2230 with geometry/fixed function pipeline 2236, sub-cores 2201A-2201F each with EU arrays, 3D samplers, TD/IC logic, media samplers, shader processors, and SLM.Search in Eureka ↗	System architecture
FIG. 23	Parallel processing unit (PPU) 2300 with I/O unit 2306, front-end unit 2310, scheduler unit 2312, work distribution unit 2314, hub 2316, general processing clusters (GPC(X)) 2318, crossbar (Xbar) 2320, memory partition units 2322, and memory 2304.Search in Eureka ↗	System architecture
FIG. 24	General processing cluster (GPC) 2400 with pipeline manager 2402, PROP unit 2404, raster engine 2408, DPC(V) 2406 containing primitive engine 2412 and streaming multiprocessor (SM) 2414, work distribution crossbar (WDX) 2416, and MMU 2418.Search in Eureka ↗	System architecture
FIG. 25	Streaming multiprocessor (SM) 2500 showing instruction cache 2502, scheduler units 2504 with dispatch 2506, register file 2508, processing cores 2510, SFUs 2512, LSUs 2514, interconnect network 2516, and shared memory/L1 cache 2518.Search in Eureka ↗	System architecture
FIG. 26	Software stack 2600 architecture with application 2601, APIs/libraries 2602/2603, runtime 2605 with API(s) 2604, device kernel driver 2606, and hardware 2607 showing programming platform layering.Search in Eureka ↗	Other
FIG. 27	CUDA software stack 2700 implementation of FIG. 26 with application 2701, CUDA APIs 2702, CUDA libraries 2703, CUDA runtime API 2704, CUDA runtime 2705, CUDA driver API 2706, CUDA driver 2707, device kernel driver 2708, and hardware 2709.Search in Eureka ↗	Other
FIG. 28	ROCm software stack 2800 implementation with application 2801, language runtime 2803, ROCr system runtime API 2804, ROCm thunk API 2806, thunk 2807, ROCm driver 2808, and hardware 2809.Search in Eureka ↗	Other
FIG. 29	OpenCL software stack 2900 with application 2901, OpenCL kernel 2902, OpenCL framework 2910 (platform API 2903, compiler 2904), OpenCL runtime 2906 with runtime API 2905, device kernel driver 2907, and hardware 2908.Search in Eureka ↗	Other
FIG. 30	Software layers supported by programming platform 3004 including multiple frameworks 3001(1-N), middleware/library layers 3002(1-M), and programming models 3003(1-O) built on programming platform 3004.Search in Eureka ↗	Other
FIG. 31	Compiling code on programming platforms showing source code 3100 fed to compiler 3101 producing host executable code 3102 and device executable code 3103.Search in Eureka ↗	Other
FIG. 32	Detailed compilation flow 3201 with compiler front end 3202 splitting source code 3200 into host code 3203 and device code 3204, compiled separately by host compiler 3205 and device compiler 3206, linked by linker 3209 into executable file 3210.Search in Eureka ↗	Other
FIG. 33	Source code translation flow: source code 3300 through translation tool 3301 to translated source code 3302, then compiler 3303 to host executable code 3304 and device executable code 3305.Search in Eureka ↗	Other
FIG. 34A	System 3400 for compiling and executing CUDA source code 3410 showing CUDA-to-HIP translation tool 3420, HIP source code 3430, HIP compiler driver 3440, CUDA compiler 3450, and HCC 3460 producing host and device executables for CPU 3490 and CUDA/HCC GPUs.Search in Eureka ↗	Other
FIG. 34B	System 3404 configured to compile CUDA source code using CPU 3490 and CUDA-enabled GPU 3494, with HIP/NVCC compilation path through CUDA compiler 3450 using HIP-to-CUDA translation header 3452.Search in Eureka ↗	Other
FIG. 34C	System 3406 for compiling CUDA source code using CPU 3490 and non-CUDA-enabled GPU 3492, with HIP/HCC compilation path through HCC 3460 using HCC header 3456 and HIP/HCC runtime library 3458.Search in Eureka ↗	Other
FIG. 35	Exemplary CUDA source code 3410 kernel MatAdd and main function alongside HIP source code 3430 equivalent after CUDA-to-HIP translation, illustrating hipLaunchKernelGGL syntax versus CUDA triple-chevron syntax.Search in Eureka ↗	Other
FIG. 36	Non-CUDA-enabled GPU 3492 with command processor 3610, programmable processing units 3620(1/E) each containing workload manager 3630 and compute units 3640 with SIMD units 3650 and shared memory 3660, plus DMA engines 3680 and memory controllers 3670.Search in Eureka ↗	System architecture
FIG. 37	CUDA grid 3720 thread mapping showing thread blocks 3730(BX,BY) with threads 3740 mapped to compute units 3640(1) and 3640(2) of programmable processing unit 3620(1), illustrating SIMD execution model.Search in Eureka ↗	Other
FIG. 38	CUDA-to-DPC++ code migration workflow: CUDA source code 3800 through DPC++ compatibility tool 3802 to human readable DPC++ 3804, then complete coding and tune to desired performance 3806, yielding DPC++ source code 3808.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 (computer-implemented method), Claim 13 (system), and Claim 20 (non-transitory machine-readable medium/CRM), providing the standard tripartite enforcement structure across all major claim types. With 24 dependent claims across 3 independent claims, the dependent-to-independent ratio of 8:1 is above average for the G06T software/graphics class (industry norm: 4–6:1), indicating above-norm fallback depth. Claims 2–12 depend from Claim 1, Claims 14–19 depend from Claim 13, and Claims 21–27 depend from Claim 20, creating three parallel claim families that mirror each other, raising strategic efficiency concerns about claim differentiation.

Core inventive concept: The independent claims address the computational cost problem of ray tracing by reusing a previously computed visibility parameter — one that was ray-traced for a first image region and indicates a first amount of light to apply to that region — to determine a second amount of light for a neighboring image region, where neighboring is defined as at least one of spatially or temporally adjacent. The mechanism requires that the second ray (the final visibility ray for the neighboring region) is "more computationally costly than" the first rays, creating an explicit quality hierarchy that justifies the reuse decision.

Independent Claim Dissection

Claim	Preamble	Transition	Key Body Elements
Claim 1	A computer-implemented method	comprising	computing first lighting effects for first image region using at least one visibility parameter based on at least one final visibility ray traced from light samples obtained by ray tracing initial visibility rays; computing second lighting effects for second image region based at least in part on the at least one visibility parameter, the second image region neighboring the first image region at least one of spatially or temporallySearch prior art ↗
Claim 13	A system	comprising	one or more processors; one or more memories storing instructions causing processors to: obtain light samples at least in part by ray tracing first rays; trace a second ray from a point on a surface visible in first image region to a selected light sample (second ray being more computationally costly than at least one first ray); determine at least one visibility parameter indicating light contribution; determine second amount of light for second image region based on the visibility parameter, second image region neighboring first image region spatially or temporallySearch prior art ↗
Claim 20	A non-transitory machine-readable medium having stored thereon a set of instructions, which if performed by one or more processors, cause the one or more processors to	at least:	determine second amount of light for second image region based at least in part on at least one visibility parameter determined for first image region using at least one first ray traced from light samples obtained using second rays (first ray being of higher quality than second rays); visibility parameter indicating first amount of light from light samples to apply to first image region; second image region neighboring first image region at least one of spatially or temporallySearch prior art ↗

Claim Dependency Tree

1 Computer-implemented method: compute lighting using visibility parameter from final visibility ray; reuse for neighboring image regionSearch Claim 1 prior art ↗

2 Adds: storing first age value before determining second lighting effects; determining second age value after; associating second age value with second lighting effectsSearch in Eureka ↗

3 Adds: determining whether to use visibility parameter for third image region based on comparison of age threshold value with first or second age valueSearch in Eureka ↗

4 Adds: storing first distance value before; determining second distance value after when second region neighbors first both temporally and spatially, second distance = sum of first distance + distance between image locations minus motionSearch in Eureka ↗

5 Adds: determining whether to use visibility parameter for third region based on comparison of distance threshold with first or second distance valueSearch in Eureka ↗

6 Adds: single image comprises first and second image regions; second image region neighbors first spatiallySearch in Eureka ↗

7 Adds: first image comprises first image region; second image comprises second image region; second image region neighbors first image region temporallySearch in Eureka ↗

8 Adds: second image region neighbors first image region spatiallySearch in Eureka ↗

9 Adds: obtaining visibility parameter by selecting light sample, ray tracing particular final visibility ray from point on surface in first image region to light sample, determining light contributionSearch in Eureka ↗

10 Adds: selecting set of first light samples for each of plurality of image regions; combining sets; selecting selected light sample from combined setSearch in Eureka ↗

11 Adds: importance sampling used to select set of first light samplesSearch in Eureka ↗

12 Adds: importance sampling used to select the selected light sample from the set of second light samplesSearch in Eureka ↗

13 System: processors and memories; obtain light samples via first rays; trace second ray more costly than first rays; determine visibility parameter; determine second amount of light for neighboring regionSearch Claim 13 prior art ↗

14 Adds: select set of first light samples for each of plurality of image regions; identify occluded light samples using first rays; remove occluded samples; combine sets to obtain one or more light samplesSearch in Eureka ↗

15 Adds: importance sampling used to select set and selected light sampleSearch in Eureka ↗

16 Adds: store first age value; determine second age value after second amount determined; associate second age value with second amount; determine whether to use visibility parameter for third region based on age thresholdSearch in Eureka ↗

17 Adds: store first distance value; determine second distance value (= first distance + screen-space distance minus motion); determine whether to use visibility parameter for third region based on distance thresholdSearch in Eureka ↗

18 Adds: render image comprising first and second image regions with respective first and second amounts of lightSearch in Eureka ↗

19 Adds: first and second amounts of light are identicalSearch in Eureka ↗

20 Non-transitory machine-readable medium (CRM): determine second amount of light based on visibility parameter from first image region; first ray of higher quality than second rays; second region neighbors first spatially or temporallySearch Claim 20 prior art ↗

21 Adds: render image comprising first and second image regions with respective first and second amounts of lightSearch in Eureka ↗

22 Adds: store first age value; determine second age value; associate second age value with second amount; determine whether to use visibility parameter for third region based on age threshold with second age valueSearch in Eureka ↗

23 Adds: store first distance value; determine second distance value (= first distance + screen-space distance minus motion); determine whether to use for third region based on distance thresholdSearch in Eureka ↗

24 Adds: obtain visibility parameter by selecting light sample; tracing particular first ray from point on surface visible in first image region to selected light sample; determining light contributionSearch in Eureka ↗

25 Adds: select set of first light samples for each of plurality of image regions; identify occluded samples using first rays; remove occluded; combine setsSearch in Eureka ↗

26 Adds: importance sampling used to select set of light samples for plurality of image regions and to select the selected light sampleSearch in Eureka ↗

27 Adds: store the at least one visibility parameter in association with the second image regionSearch in Eureka ↗

Metric	This Application	Software / GPU / Graphics Norm
Total claims	27	15 – 25
Independent claim count	3	2 – 4
Dependent : Independent ratio	8.00 : 1	4 – 7 : 1
Method claims present?	Yes — Claim 1	Always
System / apparatus claims?	Yes — Claim 13	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's strongest drafting feature is its consistent tripartite claim coverage across method (Claim 1), system (Claim 13), and CRM (Claim 20) formats, providing enforcement flexibility across hardware vendors and software licensees. However, the three independent claims diverge in their characterization of the core concept — Claim 1 uses "first amount of light" and "second amount of light" language, while Claim 13 introduces "more computationally costly" language not present in Claim 1, and Claim 20 frames the quality hierarchy differently again — creating potential inconsistency vulnerabilities during prosecution or litigation.

✅

Antecedent Basis — Clean

The claims maintain consistent antecedent basis throughout the dependency chain. "The at least one visibility parameter" in Claims 2–12 properly refers back to the "at least one visibility parameter" introduced in Claim 1. Similarly, "the first image region" and "the second image region" introduced in the preambles of Claims 1, 13, and 20 are properly tracked through all dependent claims. No floating antecedent issues were identified across the 27-claim set, which reduces prosecution risk of §112(b) indefiniteness rejections.

Explore in Eureka ↗

✅

Spec–Claim Consistency — Well Supported

The core claim limitations map clearly to specific figures and paragraphs. The visibility parameter (Claim 1) maps to FIG. 4's reservoir structure 400 with visibility parameters 410, and to paragraphs describing block 318 in the detailed description. The age value and distance value limitations in Claims 2–5 map directly to reservoir fields 412 and 414 in FIG. 4 and to method blocks 508/510/522 in FIG. 5. The "neighboring spatially or temporally" limitation maps to FIG. 4 showing frames 220 and 420 and the motion vector discussion in the spec.

Explore in Eureka ↗

✅

Transition Word Usage — Strategically Appropriate

All three independent claims use "comprising" as the transitional phrase, which is the broadest open-ended transition, correctly chosen here to ensure that additional rendering steps or components not recited in the claims cannot be used to design around the invention. The dependent claims similarly use "further comprising" and "wherein" appropriately. No use of "consisting of" or "consisting essentially of" was found, which would have been strategically harmful given the algorithm-centric nature of the claims.

Explore in Eureka ↗

✅

§112(f) Means-Plus-Function Risk — Low

No "means for" or "step for" language appears in any of the 27 claims. The system claims (Claims 13–19) use processor and memory elements with functional language tied to hardware, which could attract §112(f) scrutiny if the claim drafting were not paired with corresponding structural disclosure. However, the specification's extensive hardware descriptions in FIGS. 7–38 provide ample structural support for the processor and memory claim elements, effectively managing §112(f) risk even though the hardware descriptions are largely generic to NVIDIA's GPU portfolio.

Explore in Eureka ↗

⚠️

§101 Eligibility Risk — Moderate Exposure

The method Claim 1 recites "computing" lighting effects and "determining" amounts of light, which are mathematical/computational steps that could attract an Alice Step 1 abstract idea characterization. The §101 defense rests primarily on the ray-tracing hardware tie-in (final visibility rays, ray tracing initial visibility rays) present in the independent claims, but an examiner could argue these are merely instructions directing generic computer hardware to perform mathematical calculations. Claim 13 is better anchored with "trace a second ray" and the explicit computational cost comparison, and Claim 20 uses the higher-quality ray framing. The patent was granted, suggesting the examiner accepted the hardware nexus, but litigation counsel should note the method claim's relative vulnerability.

Explore in Eureka ↗

⚠️

Dependent Claim Fallback Quality — Parallel Mirroring Reduces Value

The three claim families (Claims 1–12, 13–19, 20–27) substantially mirror each other, with Claims 2/16/22 adding age values, Claims 4/17/23 adding distance values, and Claims 10/14/25 adding the light sample selection pool. This mirroring means that a defendant who invalidates a limitation in one family will simultaneously invalidate the parallel limitation in the other families. Claims 6 (spatial only) and 7/8 (temporal then spatial) provide genuinely distinct fallback scope, as does Claim 19 (first and second amounts are identical), which covers a specific degenerate case not elsewhere claimed. Claims 3, 5, 11, and 12 add threshold-based gating logic that provides meaningful prosecution history estoppel management.

Explore in Eureka ↗

⚠️

Abstract Quality — Undersells Novel Contribution

The abstract states only that "at least one visibility parameter determined for a first image region is reused for a different second image region that neighbors the first image region (e.g., spatially and/or temporally)." While accurate, this description fails to identify the distinguishing mechanism — specifically that the reused parameter derives from a computationally expensive final visibility ray that would otherwise need to be re-traced, or that the age and distance threshold system controls the validity of reuse. An examiner reading only the abstract may characterize the invention too broadly as generic temporal reuse, potentially over-expanding the prior art search and missing the specific ReSTIR improvement being claimed.

Explore in Eureka ↗

⚠️

Figure Support Quality — Core Invention Well Covered, Architecture Figures Generic

FIGS. 1–6 provide strong, specific support for the core inventive claim limitations: FIG. 3 maps to the method steps of Claim 1 step-by-step, FIG. 4 provides the reservoir data structure (visibility parameters 410, age 412, distance 414) supporting Claims 2–5 and 16–17 and 22–23, and FIG. 5 maps to the threshold-gating logic in Claims 3 and 5. However, the 38 additional architectural figures (FIGS. 7–38) provide only generic GPU system support and do not illustrate the specific interaction between the rendering module 110 and the reservoir data structures 112 in multi-GPU or data center configurations, leaving a gap in support for distributed rendering embodiments the spec mentions.

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

Prosecution Defensibility

3.5

Spec–Claim Consistency

4.2

Dependent Claim Coverage

Claim Type Diversity

Figure Support Quality

3.5

Key observation: The highest-scoring dimension is Claim Type Diversity (5.0/5.0) — the patent achieves full tripartite coverage with method, system, and CRM independent claims, ensuring NVIDIA can assert against software implementers, hardware manufacturers, and cloud service providers alike. The lowest-scoring dimension is Dependent Claim Coverage (3.0/5.0) because the three claim families mirror each other structurally, meaning a successful invalidity argument on the age-value limitation in one family simultaneously collapses the parallel limitation across all three families — a strategic practitioner would have differentiated the dependent claim trees to create independent fallback positions. Continuation practitioners should consider filing narrower claims targeting specific threshold value ranges or GPU shader pipeline implementations to create non-mirrored fallback positions.

See how your own draft compares — Open Eureka IP Drafting →

Critical Gaps

3 Critical Gaps in This Claim Set

A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.

GAP 01 · HIGHEST IMPACT

Independent claim tripartite inconsistency in computational cost framing

Claim 13's system claim requires that the second ray be "more computationally costly than at least one of the set of first rays" — a structural limitation absent from both Claim 1 (method) and Claim 20 (CRM), which instead rely on "final visibility ray" and "higher quality" language respectively. This inconsistency creates a prosecution history estoppel risk where a defendant could argue that the system claim's explicit cost comparison limits the method claim's scope by negative implication, or that the CRM claim's "higher quality" language encompasses a broader or narrower set of rays than the system claim. A stronger filing would have used identical or explicitly parallel language across all three independent claims, or would have filed separate continuation claims specifically targeted to the cost-differential limitation as a standalone dependent claim in each family.

GAP 02 · HIGH IMPACT

No claims directed to real-time rendering or gaming application embodiments

The specification explicitly discloses real-time ray tracing with age threshold values of 8 frames and distance threshold values of 16 pixels (described in detail with experimental results in FIG. 6), but no claims are directed specifically to real-time rendering systems, game engine implementations, or threshold value ranges. A competitor implementing a ReSTIR variant with different threshold values could potentially design around the broadly-stated claims while practicing the core inventive concept. This gap creates a specific design-around opportunity where a competitor sets age threshold to a fixed value (e.g., always 8 frames) and argues they do not "determine whether to use" the visibility parameter based on any threshold comparison. A stronger filing would have included dependent claims reciting specific threshold value ranges or claims directed to real-time rendering contexts where per-frame latency constraints apply.

GAP 03 · HIGH IMPACT

Missing claims on reservoir combination and spatiotemporal weighting algorithm

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.

Claim inconsistency across independent claim types No real-time rendering or threshold-range claims Reservoir combination algorithm not independently claimed

Unlock Full Analysis — Free

Frequently asked questions

US 11,922,556 B2 — key questions answered

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

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

What are the independent claims of US 11,922,556 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 Corporation’s Ray-Traced Light Resampling Using Screen Space Visibility | US 11,922,556 B2

Patent Drafting Analysis of NVIDIA Corporation's Ray-Traced Light Resampling Using Screen Space Visibility | US 11,922,556 B2