Patent Drafting Analysis of Intel Corporation’s Triangle Pairs and Shared Transformation Circuitry for Ray Tracing | US 11,922,557 B2
Patent Drafting Analysis of Intel Corporation's Ray Tracing Triangle Pairs and Shared Transformation Circuitry | US 11,922,557 B2
A structural and strategic analysis of US 11,922,557 B2 covering claim architecture, drafting quality signals, critical gaps, and prosecution positioning for Intel's shared transformation ray tracing hardware invention.
Spec Words
12,400
Across 6 sections
Draft now ↗
Total Claims
18
3 independent · 15 dependent
Draft now ↗
Figure Sheets
26
GPU architectures, ray tracing pipeline, triangle pair geometry
Draft now ↗
Published by PatSnap Insights Team · · 12 min read Verified by PatSnap Eureka Data
Overview
Structural Overview
The detailed description dominates at approximately 63% of total words, with 26 drawing sheets providing extensive GPU architecture context — though only Figures 15–17 directly address the novel triangle-pair and shared transformation mechanism. The claim set is compact at 18 claims across 3 independent claims (apparatus, method, CRM), providing tripartite type coverage. Figure coverage is broad across general GPU architecture but narrowly targeted for the specific inventive contribution, with FIG. 15 illustrating triangle pairs, FIG. 16 showing the shared transformation architecture, and FIG. 17 depicting the method flow.
Section Word Distribution
↗ Click bars to exploreFigure Inventory — 26 Sheets
| Figure | Description | Role |
|---|---|---|
| FIG. 1 | Block diagram of a computer system 100 showing processor cores 107, graphics processors 108, memory controller 116, and platform controller hub 130.Search in Eureka ↗ | Other |
| FIG. 2A | Block diagram of processor 200 with multiple processor cores 202A-202N, integrated memory controller 214, and integrated graphics processor 208.Search in Eureka ↗ | Other |
| FIG. 2B | Hardware logic block diagram of graphics processor core 219 showing sub-cores 221A-221F, EU arrays, samplers, shared function logic 235, and media pipeline 234.Search in Eureka ↗ | System architecture |
| FIG. 2C | Block diagram of GPU 239 with multi-core groups 240A-240N showing GFX cores 243, tensor cores 244, ray tracing cores 245, and L1/L2 caches.Search in Eureka ↗ | System architecture |
| FIG. 2D | Block diagram of GPGPU 270 showing compute units 260A-260N with vector registers 261, scalar registers 262, shared memory 256, and DMA controller 269.Search in Eureka ↗ | System architecture |
| FIG. 3A | Block diagram of discrete graphics processor 300 with graphics processing engine 310, 3D pipeline 312, media pipeline 316, display controller 302, and memory interface 314.Search in Eureka ↗ | System architecture |
| FIG. 3B | Tiled graphics processor 320 showing graphics processing engine cluster 322 with graphics engine tiles 310A-310D interconnected via fabric interconnect 324.Search in Eureka ↗ | System architecture |
| FIG. 3C | Compute accelerator 330 with compute engine cluster 332, compute engine tiles 340A-340D, and L3 cache 336 configured for parallel compute acceleration.Search in Eureka ↗ | Other |
| FIG. 4 | Graphics processing engine 410 showing graphics core array 414, shared function logic 420 (sampler 421, math 422, ITC 423), 3D pipeline 312, and media pipeline 316.Search in Eureka ↗ | System architecture |
| FIG. 5A | Thread execution logic 500 with shader processor 502, thread dispatcher 504, ray tracer 505, execution units 508A-508N, sampler 510, and data cache 512.Search in Eureka ↗ | System architecture |
| FIG. 5B | Graphics execution unit 508 internal structure showing thread arbiter 522, GRF 524, ARF 526, SIMD FPUs 534, SIMD ALUs 535, and instruction fetch path.Search in Eureka ↗ | System architecture |
| FIG. 6 | Execution unit 600 showing compute 610 with ALU 611, systolic array 612, math 613, register file 606, thread control 601, and instruction fetch/prefetch 603.Search in Eureka ↗ | Other |
| FIG. 7 | Graphics processor instruction formats 700 showing 128-bit instruction 710 (opcode 712, control 714, exec-size 716, dest 718, SRC0-2) and 64-bit compact instruction 730 with opcode decode 740.Search in Eureka ↗ | Other |
| FIG. 8 | Graphics processor 800 pipeline showing geometry pipeline 820 with vertex shader 807, hull shader 811, tessellator 813, domain shader 817, geometry shader 819, media pipeline 830, and render output pipeline 870.Search in Eureka ↗ | System architecture |
| FIG. 9A | Graphics processor command format 900 showing fields: client 902, opcode 904, sub-opcode 905, data 906, and command size 908.Search in Eureka ↗ | Other |
| FIG. 9B | Graphics processor command sequence 910 flow diagram showing pipeline flush 912, pipeline select 913, pipeline control 914, return buffer state 916, and 3D/media pipeline branching.Search in Eureka ↗ | Flow diagram |
| FIG. 10 | Data processing system 1000 showing 3D graphics application 1010, OS 1020 with graphics API 1022, shader compiler 1024, user/kernel mode graphics drivers 1026/1029, graphics processor 1032.Search in Eureka ↗ | System architecture |
| FIG. 11A | IP core development system 1100 showing software simulation 1110, simulation model 1112, RTL design 1115, hardware model 1120, non-volatile memory 1140, and fabrication facility 1165.Search in Eureka ↗ | Other |
| FIG. 11B | Cross-section of package assembly 1170 showing logic units 1172/1174 connected to substrate 1180 via interconnect structure 1173 and bridge 1182, with package interconnect 1183.Search in Eureka ↗ | Other |
| FIG. 11C | Package assembly 1190 with multiple hardware logic chiplets including logic 1172, I/O 1174, memory 1175 connected via interconnect structures 1173 and fabric 1185 on substrate 1180.Search in Eureka ↗ | Other |
| FIG. 11D | Package assembly 1194 showing interchangeable chiplets 1195 assembled onto base chiplets 1196/1198 connected via bridge interconnect 1197.Search in Eureka ↗ | Other |
| FIG. 12 | SoC integrated circuit 1200 showing application processors 1205, graphics processor 1210, image processor 1215, video processor 1220, and peripheral interfaces including USB, UART, HDMI, MIPI.Search in Eureka ↗ | Other |
| FIG. 13 | Graphics processor 1310 showing vertex processor 1305, multiple fragment processors 1315A-1315N, MMUs 1320A-1320B, caches 1325A-1325B, and interconnects 1330A-1330B.Search in Eureka ↗ | Other |
| FIG. 14 | Graphics processor 1340 with inter-core task manager 1345, multiple shader cores 1355A-1355N, tiling unit 1358, MMUs 1320A-1320B, and interconnects 1330A-1330B.Search in Eureka ↗ | Other |
| FIG. 15 | Illustration of individual triangle 1501 and triangle pair 1502 sharing a common edge 1505, directly depicting the core inventive primitive structure claimed in Claim 1.Search in Eureka ↗ | Claim support |
| FIG. 16 | Shared transformation unit 1600 architecture showing queue 1698, ordering 1697, pairing search 1694, matrix multiply 1650, ray-triangle intersection 1670, ping-pong buffer registers 1660/1661, multiplexers 1690-1692, and Boolean control 1640.Search in Eureka ↗ | Key embodiment |
| FIG. 17 | Method flow 1700 for triangle pair shared transformation showing steps: identify and merge triangle pairs 1701, input to shared intersection circuitry 1702, cycle decision 1703, vertex transformation 1704 using triangle pairs, and ray transformation 1705 using ray direction/origin data.Search in Eureka ↗ | Flow diagram |
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 (apparatus — graphics processor), Claim 7 (method), and Claim 13 (non-transitory machine-readable medium), providing full tripartite coverage across all standard claim types. The dependent:independent ratio is 5.00:1, which is below the semiconductor/GPU norm of 6–10:1, suggesting a slightly lean dependent claim strategy. The claim strategy clearly mirrors the core technical architecture: each independent claim captures the same shared transformation and triangle-pair intersection concept in its respective type, creating layered enforcement coverage.
Core inventive concept: The claims address the computational bottleneck of ray tracing hierarchy traversal by pairing triangles that share an edge — represented by four vertices in first coordinate space — and routing them through shared transformation circuitry that alternates between vertex transformations (on the merged pair) and ray transformations (on ray direction/origin data), enabling a single hardware transformation unit to service both operations and reducing per-triangle transformation overhead from six to four. Claims 1, 7, and 13 each require identifying triangle pairs where unpaired triangles are paired with an 'invalid triangle,' performing per-vertex transformation to produce four transformed vertices in a canonical ray coordinate space, and conducting ray-triangle intersection testing on those four vertices.
Independent Claim Dissection
| Claim | Preamble | Transition | Key Body Elements |
|---|---|---|---|
| Claim 1 | A graphics processor | comprising | a queue storing a plurality of triangles from which triangle pairs are identified (each pair: two edge-sharing triangles represented by four vertices in first coordinate space, with unpaired triangles forming pairs with invalid triangles); shared transformation circuitry to perform per-vertex transformation on vertices of a first triangle pair to generate four transformed vertices in a second coordinate space in which a first ray has a canonical form; ray-triangle intersection circuitry to perform intersection test between the first ray and the first triangle pair based on the four transformed verticesSearch prior art ↗ |
| Claim 7 | A method | comprising | identifying a plurality of triangle pairs from a plurality of triangles stored in a queue (each triangle pair: two edge-sharing triangles represented by four vertices in first coordinate space, with unpaired triangles forming pairs with invalid triangles); performing per-vertex transformation on vertices of a first triangle pair of the plurality of triangle pairs to generate four transformed vertices in a second coordinate space in which a first ray has a canonical form; performing intersection test between the first ray and the first triangle pair based on the four transformed verticesSearch prior art ↗ |
| Claim 13 | A non-transitory machine-readable medium having program code stored thereon which, when executed by a machine, causes the machine to perform operations of | comprising | identifying a plurality of triangle pairs from a plurality of triangles stored in a queue (each triangle pair: two edge-sharing triangles represented by four vertices in first coordinate space, with unpaired triangles forming invalid pairs); performing per-vertex transformation on vertices of a first triangle pair to generate four transformed vertices in a second coordinate space in which a first ray has a canonical form; performing intersection test between the first ray and the first triangle pair based on the four transformed verticesSearch prior art ↗ |
Claim Dependency Tree
1 Graphics processor comprising queue, shared transformation circuitry, and ray-triangle intersection circuitry for triangle pair processingSearch Claim 1 prior art ↗
2 Adds: intersection test determines first and second triangles of the pair based on four transformed vertices, each triangle being a subsetSearch in Eureka ↗
3 Further: each subset comprises three of the four transformed verticesSearch in Eureka ↗
4 Adds: shared transformation circuitry further performs ray transformations on ray direction/origin data associated with a second ray following per-vertex transformation of first triangle pair to generate a transformed raySearch in Eureka ↗
5 Adds: further comprising triangle pairing search circuitry to identify triangle pairs from the plurality of triangles stored in the queueSearch in Eureka ↗
6 Adds: shared transformation circuitry comprises a matrix multiplication circuit to multiply first matrix data associated with vertices of first triangle pair with ray direction data associated with the first raySearch in Eureka ↗
7 Method comprising identifying triangle pairs from queue, performing per-vertex transformation, and performing intersection testSearch Claim 7 prior art ↗
8 Adds: determining first and second triangles of the first triangle pair based on the four transformed verticesSearch in Eureka ↗
9 Further: each subset comprises three of the four transformed verticesSearch in Eureka ↗
10 Adds: performing ray transformations on ray direction/origin data associated with a second ray following per-vertex transformation of first triangle pair to generate a transformed raySearch in Eureka ↗
11 Adds: identifying triangle pairs from the plurality of triangles stored in the queue (dedicated identification step)Search in Eureka ↗
12 Adds: per-vertex transformation comprises multiplying first matrix data associated with vertices of first triangle pair with ray direction data associated with the first raySearch in Eureka ↗
13 Non-transitory machine-readable medium for identifying triangle pairs, performing per-vertex transformation, and intersection testSearch Claim 13 prior art ↗
14 Adds: determining first and second triangles of the first triangle pair based on four transformed verticesSearch in Eureka ↗
15 Further: each subset comprises three of the four transformed verticesSearch in Eureka ↗
16 Adds: performing ray transformations on ray direction/origin data associated with a second ray following per-vertex transformation of first triangle pair to generate a transformed raySearch in Eureka ↗
17 Adds: identifying triangle pairs from the plurality of triangles stored in the queueSearch in Eureka ↗
18 Adds: per-vertex transformation comprises multiplying first matrix data associated with vertices of first triangle pair with ray direction data associated with the first raySearch in Eureka ↗
| Metric | This Application | Semiconductor / GPU Industry Norm |
|---|---|---|
| Total claims | 18 | 18 – 30 |
| Independent claim count | 3 | 2 – 4 |
| Dependent : Independent ratio | 5.00 : 1 | 6 – 10 : 1 |
| Method claims present? | Yes — Claim 7 | Always |
| System / apparatus claims? | Yes — Claim 1 | Always |
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 §101 defensibility through concrete hardware recitations — specifically the queue, shared transformation circuitry, and ray-triangle intersection circuitry in Claim 1 — providing a robust machine-tie-in that distinguishes this patent from abstract algorithm claims. However, the dependent claims exhibit structural redundancy: Claims 8/14 and Claims 11/17 add nearly identical limitations to their respective independent method and CRM claims, weakening fallback diversity and suggesting a missed opportunity to capture additional design-around barriers.
✅
Antecedent Basis
The claim set is clean for antecedent basis throughout all 18 claims. Claim 1 introduces "a queue," "shared transformation circuitry," and "ray-triangle intersection circuitry" in the body, and dependent Claims 2–6 consistently reference "the first triangle pair" and "the four transformed vertices" with proper antecedent established in Claim 1. Similarly, Claims 7–12 and 13–18 maintain proper "a first triangle pair" introduction before any subsequent "the first triangle pair" references in dependent claims. No orphaned "the" references were identified across the claim set.
✅
Spec–Claim Consistency
All three independent claim limitations map directly to specific figures and paragraphs. FIG. 15 and the "Triangle-Pair Formation" section directly support the queue and triangle-pair identification limitations of Claim 1. FIG. 16 (shared transformation unit 1600) and the corresponding detailed description paragraphs support the shared transformation circuitry and ray-triangle intersection circuitry limitations. FIG. 17 and the associated method description at col. 37-38 support the method steps of Claims 7 and 13. The canonical form coordinate space and four-vertex representation are explicitly described and illustrated.
✅
Transition Word Usage
All three independent claims appropriately use "comprising" as the transition word, which is the maximally inclusive open-ended transition for this technology type, allowing for additional undisclosed components. This is particularly important for Claims 1 and 13 since a GPU implementation would inevitably contain additional hardware components beyond those recited. No claims use "consisting of" or "consisting essentially of," which would be unnecessarily restrictive. The choice of "comprising" in all three independent claims is strategically sound for enforcement breadth.
✅
§112(f) Means-Plus-Function Risk
No "means for" language appears anywhere in the 18 claims. While Claim 1 uses "circuitry to perform" constructions — specifically "shared transformation circuitry to perform per-vertex transformation" and "ray-triangle intersection circuitry to perform intersection test" — these functional recitations are paired with specific structural labels ("circuitry") that courts have generally found sufficient to avoid §112(f) invocation for hardware claims. The specification provides detailed structural disclosure of both circuitry elements in FIG. 16, further insulating against any §112(f) challenge.
✅
§101 Eligibility Risk
§101 exposure is low for this patent. Claim 1's apparatus structure — a graphics processor with a physical queue, dedicated shared transformation circuitry, and ray-triangle intersection circuitry — is clearly tied to specific hardware components and avoids the abstract idea category under Alice Step 1. Even under Step 2A, the transformation circuitry integrates the claimed technique into a specific hardware structure (the shared matrix multiplication unit 1650 depicted in FIG. 16), going well beyond a mere instruction to "apply the abstract idea." The CRM Claim 13 adds some residual §101 risk but is mitigated by its "non-transitory" qualifier and the underlying hardware context.
⚠️
Dependent Claim Fallback Quality
The dependent claim set suffers from structural mirroring across the three independent claims: Claims 8/14 add identical triangle subdivision logic, Claims 9/15 add the same three-vertex subset limitation, Claims 10/16 add the same ray transformation step, Claims 11/17 add the same triangle identification step, and Claims 12/18 add the same matrix multiplication characterization. While this tripartite mirroring ensures consistent fallback across claim types, it means only Claims 2-6 under Claim 1 add truly distinct hardware-specific fallbacks (pairing search circuitry in Claim 5, matrix multiplication circuit in Claim 6) that could survive independent validity challenges. A stronger filing would have added fallbacks covering BVH-level ray transformation, queue ordering logic, and the Boolean multiplexer control mechanism shown in FIG. 16.
⚠️
Abstract Quality
The abstract accurately describes the core hardware mechanism — the queue, ordering circuitry, pairing circuitry, and shared transformation circuitry — and specifically names the alternating vertex/ray transformation function. However, it omits the key technical differentiator of the four-vertex canonical space representation that is central to the watertight ray/triangle intersection compatibility. An examiner reading only the abstract would understand the shared hardware concept but might not identify the canonical coordinate space transformation as a patentable distinction over conventional ray-triangle intersection hardware, potentially affecting art search quality during prosecution.
✅
Figure Support Quality
All structural limitations of the independent claims have direct figure support. FIG. 15 supports the triangle-pair and shared-edge limitations; FIG. 16 supports the queue (1698), shared transformation circuitry (1600), matrix multiply unit (1650), ray-triangle intersection circuitry (1670), and the multiplexer-based alternating mechanism (1690-1692); FIG. 17 supports the method steps of Claims 7 and 13. The Boolean control 1640 and ping-pong buffer registers 1660-1661 disclosed in FIG. 16 are not claimed but provide valuable specification support. The 23 background GPU architecture figures (FIGs. 1–14) provide context but do not directly illustrate the claimed circuitry, which could have been better served by additional detailed figures of the transformation unit's internal structure.
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
4
Spec–Claim Consistency
4.5
Dependent Claim Coverage
2.5
Claim Type Diversity
4.5
Figure Support Quality
3.5
Key observation: This patent scores highest on Spec–Claim Consistency (4.5/5.0) and Claim Type Diversity (4.5/5.0) — every independent claim limitation maps directly to FIG. 15, 16, or 17, and the tripartite apparatus/method/CRM structure provides complete enforcement coverage across all implementation vectors. The weakest dimension is Dependent Claim Coverage (2.5/5.0): twelve of the fifteen dependent claims are structural mirrors across the three independent claims, meaning a practitioner would face essentially identical fallback positions regardless of which independent claim is litigated, with no dependent claims capturing the ping-pong buffer architecture, the Boolean multiplexer control, or the BVH-level ray output mechanism disclosed in FIG. 16. Practitioners analyzing this patent for freedom-to-operate should focus their design-around analysis on the four-vertex canonical space representation and the alternating transformation cycle, as these are the two unduplicated limitations that appear consistently across all three independent claims.
See how your own draft compares — Open Eureka IP Drafting →
Critical Gaps
3 Critical Gaps in This Claim Set
A senior-attorney lens on the three highest-priority structural weaknesses — what each exposes in prosecution and litigation, and what a stronger filing would have done differently.
🔒
3 Critical Gaps in This Claim Set
See the full attorney-level analysis of what this application leaves unprotected — and how to draft it more defensively for your own filings.
Queue ordering circuitry not claimed Ping-pong buffer architecture unclaimed BVH-level ray output pathway missing
Unlock Full Analysis — Free Frequently asked questions
US 11,922,557 B2 — key questions answered
Still have questions? PatSnap Eureka can answer them from patent data instantly. Search in Eureka
Disclaimer: This analysis is generated by PatSnap Eureka AI based on publicly available patent data from the USPTO. It does not constitute legal advice and should not be relied upon as such. Patent data may be subject to change as prosecution progresses. Scores and assessments reflect automated analysis and may not capture all relevant legal or technical nuances. Always consult a qualified patent attorney for formal legal opinions on patentability, freedom to operate, or infringement.
Ask anything about this patent.
PatSnap Eureka searches patents and data to answer instantly.
PatSnap Eureka searches patents and data to answer instantly.
Powered by PatSnap Eureka
Link copied to clipboard