DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This action is in response to the amendment filed on 7th August, 2026. Claim 20 has been cancelled. Claims 1-19 and 21 remain rejected in the application.
Response to Arguments
Applicant's arguments with respect to Claims 1-19 and 21, filed on 7th August, 2026, with respect to the rejection under 35 U.S.C. § 103 regarding that the prior art does not teach "each allocated memory block: is linked to one or more other memory blocks associated with the ray to form a linked memory stack", "a local buffer", and "allocate at least one memory block in a memory device to the ray stack, wherein the memory device is external to the system, responsive to the at least one ray stack lacking capacity during intersection testing of the ray against one or more nodes of a hierarchical acceleration structure". The proposed amended claim limitations have been fully considered, but are not persuasive.
In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., “the cited combination does not disclose or suggest a required relationship among memory blocks associated with the ray” and “Rabbani […] does not disclose the claimed relationship among linked memory blocks associated with the ray”) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). The current claim language does not detail the specifics of any relationship between linked memory blocks. The current claim language can be interpreted as simply memory blocks (or similar types of data structures) being linked together. Furthermore, linked lists by their very nature require a type of linked relationship to each node/index of the list. Therefore, applicant’s remark cannot be considered persuasive.
In response to applicant's argument that the prior art does not teach "each allocated memory block: is linked to one or more other memory blocks associated with the ray to form a linked memory stack" as recited in Claim 1, these limitations are taught by the combination of Rabbani and Davison. In particular, Rabbani teaches the following:
Paragraph [0173]: discloses a singly-linked list implementation, interpreted to be a linked memory stack, for grouping rays (i.e., associated rays), where each ray queue entry, which have been allocated in memory to be stored in, includes a ray ID, a stack top field that indicates the next target node, and a next ray field that indicates the location of the next ray in the list, such as a reference pointer; the rays queue entries (i.e., nodes of the linked list) are being interpreted as memory blocks; additionally, the linked nodes, where each node includes its own stack, is being interpreted as a linked memory stack.
Therefore, applicant’s remark cannot be considered persuasive.
In response to applicant's argument that the prior art does not teach "a local buffer" as recited in Claim 16, these limitations are taught by Rabbani. In particular, Rabbani teaches the following:
Paragraph [0111]: discloses a graphics processor implementing a device memory space 1250, which is interpreted to be a form of local buffer, in which an ADS is stored as shown in FIG. 12.
Therefore, applicant’s remark cannot be considered persuasive.
In response to applicant's argument that the prior art does not teach "allocate at least one memory block in a memory device to the ray stack, wherein the memory device is external to the system, responsive to the at least one ray stack lacking capacity during intersection testing of the ray against one or more nodes of a hierarchical acceleration structure" as recited in Claim 1, these limitations are taught by Rabbani. In particular, Rabbani teaches the following:
Paragraph [0097]: discloses ray stack data containing ray stack entries for rays during traversal, where "each ray may have a dedicated space for its stack, but the stacks for all rays may be interleaved, which may reduce footprint and may reduce the overall number of pages used for stack SCS";
Paragraph [0153]: discloses the processor maintaining a transformation stack that stores coordinate information prior to the transform for traversal back to a previous level;
Paragraph [0170]: discloses using separate dedicated circuitry, such as a memory device, to store lists of rays, interpreted to be memory blocks of stored rays, that target the same leaf node (or same type of leaf, e.g., for shading coherency);
Paragraph [0111]: discloses device memory space 1250 storing the ADS (i.e., a hierarchical acceleration structure);
Paragraph [0193]: discloses a cache-memory hierarchy that is accessible by shader core 2210 and other circuitry, such as RAM, SSDs, external disc-based drives, memory spaces, etc.;
Paragraph [0180]: discloses the ray intersect circuitry may allocate a new group for a ray that does not match any currently-allocated group (i.e., interpreted to be the existing groups not having enough memory or lacking capacity, where a new group is then generated); and
Paragraph [0215]: discloses the "dynamically-formed SIMD group may include a set of threads determined to have the same condition result for a conditional control transfer instruction"; it is noted that determining that a thread has the same condition result is being interpreted as having enough capacity, where differing condition results (i.e., non-existent results) can occur, which can lead to the ray intersect circuitry allocating a new group; it is also noted that "lacking capacity" is not clearly defined in the current claim limitation and that further definition would overcome this claim limitation aspect.
Therefore, applicant’s remark cannot be considered persuasive.
Regarding arguments to Claims 2-8, 10-15, 17-19, and 21, they directly/indirectly depend on independent Claims 1, 9, and 16 respectively. Applicant does not argue anything other than independent Claims 1, 9, and 16. The limitations in those claims, in conjunction with combination, was previously established as explained.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 6-7, 9, 12-14, 16, 18-19, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Rabbani Rankouhi et al. (US 20220036637 A1, previously cited), hereinafter referenced as Rabbani, in view of Davison (US 20230334770 A1, previously cited).
Regarding Claim 1, Rabbani discloses a system (Rabbani, [0228]: teaches a system/device 2700) comprising:
ray tracing circuitry configured to maintain, for a ray, at least one ray stack in a first memory (Rabbani, [0169]: teaches a ray intersection circuitry (e.g., a Ray Intersection Accelerator (RIA)) <read on ray tracing circuitry> including a grouping control circuitry 1910 that is configured to assign rays to groups of rays <read on ray stack> and includes content-addressable memory structures <read on first memory> that maintains ray groups); and
memory allocation circuitry configured to allocate at least one memory block to the ray in a second memory, responsive to intersection testing of the ray against one or more nodes of a hierarchical acceleration structure (Rabbani, [0093]: teaches the organization of a ray shader core space (SCS) for storing ray data, where "the ray SCS is a private memory space <read on second memory> that may be dynamically allocated and may allow sharing of data between different thread groups"; [0095]: teaches the SCS including "regions for ray core data 820, ray stack data 830 <read on memory stack>, ray extended data 840, and token buffers 810" as shown in FIG. 8; [0163]: teaches a single-instruction multiple-data (SIMD) group including "an instruction to allocate memory space for the set of rays <read on allocate memory block to ray from memory stack> in the shader memory space prior to executing the ray intersection instruction"; [0133]: teaches RIA 190 forming a second SIMD group, where the shader memory space includes a memory region for ray stack data used by the intersect circuitry; [0169]: teaches the RIA including grouping control circuitry 1910 <read on memory allocation circuitry> that assigns rays to groups; FIG. 14B teaches an example method for forming SIMD groups for primitive testing, where between steps 1410-1430, the ray intersect circuitry receives a ray intersect instruction <read on responsive to intersection testing of ray against nodes> for a first SIMD group, which then traverses multiple nodes of a spatially organized acceleration data structure, which then forms a second SIMD group in response to reaching a node in the acceleration data structure <read on node of hierarchical acceleration structure>); wherein
PNG
media_image1.png
573
155
media_image1.png
Greyscale
PNG
media_image2.png
343
459
media_image2.png
Greyscale
each allocated memory block: is linked to one or more other memory blocks associated with the ray to form a linked memory stack (Rabbani, [0173]: teaches a singly-linked list <read on linked memory stack> implementation for grouping rays <read on associated rays>, where each ray queue entry <read on allocated memory block> indicates a ray ID, a stack top field that indicates the next target node, and a next ray field that indicates the location of the next ray in the list, such as a reference pointer; the rays queue entries are being interpreted as memory blocks); and
[[stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray.]]
However, Rabbani does not expressly disclose
stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray.
Davison discloses
stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray (Davison, FIG. 5 teaches searching for possible candidate reinsertions <read on candidate nodes> from an initial BVH, where each candidate node is scored for optimal reinsertion; [0127]: teaches updating the structure of a current BVH in temporary storage (e.g., in the node buffer 110) with the selected reinsertions; [0099]: teaches reinsertions being identified by searching <read on subsequent traversal> the hierarchy for a target node that maximizes the expected SAH reduction for a given input node; [0092]: teaches finding the VCH tree that minimizes the average computational cost that will be incurred in ray traversal and for ray intersection testing; [0083]: teaches nodes of a BVH being represented "by data <read on node data> held in a respective slot of a node buffer 110, with one slot per node," where "the node buffer 110 is maintained by the BVH module 102).
PNG
media_image3.png
635
270
media_image3.png
Greyscale
Davison is analogous art with respect to Rabbani because they are from the same field of endeavor, namely performing efficient ray tracing. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray tracing system rebalance the BVH hierarchy through candidate node reinsertions as taught by Davison into the teaching of Rabbani. The suggestion for doing so would allow the BVH hierarchy to be reorganized and balanced, thereby allowing for faster node searches, thus making future ray intersection testing faster and more efficient. Therefore, it would have been obvious to combine Davison with Rabbani.
Regarding Claim 9, it recites the limitations that are similar in scope to Claim 1, but in a method. As shown in the rejection, the combination of Rabbani and Davison discloses the limitations of Claim 1. Additionally, Rabbani discloses a method (Rabbani, [0060]: teaches a method for detecting ray intersection using ray intersection circuitry) comprising:…
Thus, Claim 9 is met by Rabbani according to the mapping presented in the rejection of Claim 1, given the system corresponds to a method.
Regarding Claims 4 and 12, the combination of Rabbani and Davison discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is further configured to
associate the ray with the at least one memory block (Rabbani, [0178]: teaches "the ray intersect circuitry (e.g. using grouping circuitry 1910 <read on memory allocation circuitry>) groups portions of the set of rays <read on associate ray with memory block> into multiple groups based on the node of the data structure that they target next"; [0182]: teaches the groups being specified by a linked list, where "entries in a ray queue <read on memory block> include a field that points to a next ray in the linked list for the corresponding ray's current group").
Regarding Claims 6 and 13, the combination of Rabbani and Davison discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is further configured to
identify the at least one memory block using a free-list structure (Rabbani, [0169]: teaches "each time the top of the traversal stack changes for a given ray, the RIA searches allocated groups to find a match for the corresponding key," where the "RIA may include grouping control circuitry 1910 <read on memory allocation circuitry> as shown in FIG. 19B configured to assign rays to groups"; [0172]: teaches "the matching group determined by grouping circuitry 1910 is an index into dedicated circuitry configured to store lists of rays for each allocated group <read on identify memory block>," where "the matching group may be indicated using attributes of a data structure <read on free-list structure>"; Note: it should be noted that a free-list structure is commonly known as a linked list that manages a pool of available memory blocks in preparation for memory allocation).
PNG
media_image4.png
147
368
media_image4.png
Greyscale
Regarding Claims 7 and 14, the combination of Rabbani and Davison discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein the linked memory stack comprises
a plurality of memory blocks in a linked list data structure (Rabbani, [0173]: teaches a linked list implementation <read on linked list data structure> for grouping rays <read on memory stack>, where "each ray queue entry <read on memory blocks> indicates a ray ID (e.g., for rays A, C, and E), a stack top field that indicates the next target node (e.g., where 0x2C is a node identifier that identifies node 1 in the example of FIG. 19A), and a next ray field that indicates the location of the next ray in the list"; Note: it should be noted that the memory blocks are being interpreted as nodes of a linked list data structure).
PNG
media_image5.png
145
455
media_image5.png
Greyscale
Regarding Claim 16, Rabbani discloses a system (Rabbani, [0228]: teaches a system/device 2700) comprising:
a local buffer (Rabbani, [0111]: teaches a graphics processor implementing a device memory space 1250 <read on local buffer> in which an ADS is stored as shown in FIG. 12); and
PNG
media_image6.png
665
452
media_image6.png
Greyscale
processing circuitry configured to (Rabbani, [0061]: teaches a graphics shader circuitry <read on processing circuitry>):
maintain, for a ray, at least one ray stack comprising a plurality of memory blocks in the local buffer (Rabbani, [0169]: teaches a ray intersection circuitry (e.g., a Ray Intersection Accelerator (RIA)) including a grouping control circuitry 1910 that is configured to assign rays to groups of rays <read on ray stack> and includes content-addressable memory structures, such as lists <read on memory blocks>, that maintains ray groups; [0173]: teaches the grouping circuitry 1910 maintaining the ray group list and tail pointer); and
allocate at least one memory block in a memory device to the ray stack (Rabbani, [0097]: teaches ray stack data containing ray stack entries for rays during traversal, where "each ray may have a dedicated space for its stack, but the stacks for all rays may be interleaved, which may reduce footprint and may reduce the overall number of pages used for stack SCS"; [0153]: teaches the processor maintaining a transformation stack that stores coordinate information prior to the transform for traversal back to a previous level; [0170]: teaches using separate dedicated circuitry <read on memory device> to store lists <read on memory blocks> of rays that target the same leaf node (or same type of leaf, e.g., for shading coherency)), wherein
the memory device is external to the system, responsive to the at least one ray stack lacking capacity during intersection testing of the ray against one or more nodes of a hierarchical acceleration structure (Rabbani, [0111]: teaches device memory space 1250 storing the ADS <read on hierarchical acceleration structure>; [0193]: teaches a cache-memory hierarchy that is accessible by shader core 2210 and other <read on external> circuitry, such as RAM, SSDs, disc-based drives, memory spaces, etc.; [0180]: teaches the ray intersect circuitry may allocate a new group for a ray that does not match any currently-allocated group <read on lacking capacity>; [0215]: teaches the "dynamically-formed SIMD group may include a set of threads determined to have the same condition result for a conditional control transfer instruction"; Note: it is noted that determining that a thread has the same condition result is being interpreted as having enough capacity, where differing condition results (i.e., non-existent results) can occur, which can lead to the ray intersect circuitry allocating a new group; it is also noted that "lacking capacity" is not clearly defined in the current claim limitation and that further definition would overcome this claim limitation aspect); wherein
[[the at least one memory block stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray.]]
However, Rabbani does not expressly disclose
the at least one memory block stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray.
Davison discloses
the at least one memory block stores node data identifying at least one candidate node of the hierarchical acceleration structure for subsequent traversal and intersection testing by the ray (Davison, FIG. 5 teaches searching for possible candidate reinsertions <read on candidate nodes> from an initial BVH, where each candidate node is scored for optimal reinsertion; [0127]: teaches updating the structure of a current BVH in temporary storage (e.g., in the node buffer 110) with the selected reinsertions; [0099]: teaches reinsertions being identified by searching <read on subsequent traversal> the hierarchy for a target node that maximizes the expected SAH reduction for a given input node; [0092]: teaches finding the VCH tree that minimizes the average computational cost that will be incurred in ray traversal and for ray intersection testing; [0083]: teaches nodes of a BVH being represented "by data <read on node data> held in a respective slot of a node buffer 110, with one slot per node," where "the node buffer 110 is maintained by the BVH module 102).
Davison is analogous art with respect to Rabbani because they are from the same field of endeavor, namely performing efficient ray tracing. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray tracing system rebalance the BVH hierarchy through candidate node reinsertions as taught by Davison into the teaching of Rabbani. The suggestion for doing so would allow the BVH hierarchy to be reorganized and balanced, thereby allowing for faster node searches, thus making future ray intersection testing faster and more efficient. Therefore, it would have been obvious to combine Davison with Rabbani.
Regarding Claim 18, the combination of Rabbani and Davison discloses the system of Claim 16. Additionally, Rabbani further discloses wherein the processing circuitry is further configured to
store data that associates the ray stack with the at least one memory block (Rabbani, [0178]: teaches "the ray intersect circuitry (e.g. using grouping circuitry 1910) groups portions <read on stored data> of the set of rays <read on associate ray with memory block> into multiple groups based on the node of the data structure that they target next"; [0182]: teaches the groups being specified by a linked list, where "entries in a ray queue <read on memory block> include a field that points to a next ray in the linked list for the corresponding ray's current group").
Regarding Claim 19, the combination of Rabbani and Davison discloses the system of Claim 18. Additionally, Rabbani further discloses wherein the processing circuitry is configured to
store data that identifies a memory block in the memory device that remains to be processed (Rabbani, [0172]: teaches "the matching group determined <read on identified> by grouping circuitry 1910 is an index into dedicated circuitry configured to store lists of rays for each allocated group <read on memory block>," where "the matching group may be indicated using attributes of a data structure").
Regarding Claim 21, the combination of Rabbani and Davison discloses the system of Claim 16. Additionally, Rabbani further discloses wherein the memory device comprises
a plurality of memory blocks in a linked list data structure associated with a ray stack (Rabbani, [0169]: teaches "each time the top of the traversal stack changes for a given ray, the RIA searches allocated groups to find a match for the corresponding key," where the "RIA may include grouping control circuitry 1910 <read on memory device> as shown in FIG. 19B configured to assign rays to groups"; [0173]: teaches a linked list implementation <read on linked list data structure> for grouping rays, where "each ray queue entry <read on memory blocks> indicates a ray ID (e.g., for rays A, C, and E), a stack top field that indicates the next target node (e.g., where 0x2C is a node identifier that identifies node 1 in the example of FIG. 19A), and a next ray field that indicates the location of the next ray in the list"; [0098]: teaches ray core data 820 being indexed using a ray identifier, which corresponds to the ray ID of a queue entry of the linked list implementation <read on linked list data structure associated with ray stack>; Note: it should be noted that it is being interpreted that there is an association between a given ray core data and a respective ray stack data).
Claims 2-3, 5, 8, 10, 15, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Rabbani Rankouhi et al. (US 20220036637 A1, previously cited), hereinafter referenced as Rabbani, in view of Davison (US 20230334770 A1, previously cited) as applied to Claims 1, 9, and 16 above respectively, and further in view of Majewski et al. (US 20230359496 A1, previously cited), hereinafter referenced as Majewski.
Regarding Claims 2 and 10, the combination of Rabbani and Davison discloses the system and the method of Claims 1 and 9 respectively. Additionally, Rabbani further discloses wherein
[[the ray stack has a fixed size and]]
the linked memory stack has a variable size (Rabbani, [0107]: teaches the ADS tree structure with variable-sized leaf nodes, where the leaf nodes are linked <read on linked memory>).
However, the combination of Rabbani and Davison does not expressly disclose
the ray stack has a fixed size.
Majewski discloses
the ray stack has a fixed size (Majewski, [1031]: teaches "the ray tracing hardware unit manages the ray tracing stack allocation counters to keep the active set size <read on fixed size> within the predefined or limit—e.g., so that it fits into the L1 data cache/LSC").
Majewski is analogous art with respect to Rabbani, in view of Davison because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Davison. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Davison.
Regarding Claims 3 and 11, the combination of Rabbani and Davison discloses the system and the method of Claims 2 and 10 respectively. Additionally, Rabbani further discloses wherein the memory allocation circuitry is configured to:
store, in the at least one memory block, data associated with a [[candidate]] node of the hierarchical acceleration structure [[identified during traversal of the ray]] (Rabbani, FIG. 19A teaches an example situation with different rays currently targeting different nodes <read on current node> in an ADS <read on hierarchical acceleration structure> during tree traversal; [0166]: teaches "the graphics processor is configured to group rays to increase the number of rays testing against a node at a given time"; [0168]: teaches "information for each group indicates a list of rays in that group," where "dedicated circuitry is configured to store the list of rays for each bin" and "various numbers of entries may be used for grouping in various implementations, e.g., 64, 128, 256, or 512 groups with 4, 8, 16, 32, or 64 entries each"; [0173]: teaches the linked list implementation for grouping rays as ray queue entries <read on store in memory block data>, where a ray ID is used for each ray queue to indicate their respective ray from the ray stack); and
PNG
media_image7.png
210
324
media_image7.png
Greyscale
create a link between the at least one memory block and one or more other memory blocks in the linked memory stack associated with the ray (Rabbani, [0173]: teaches a linked list implementation <read on linked memory> for grouping rays, where each "when a ray is grouped, it may be added to the end of the group list <read on creating a link between memory blocks in memory stack> and a tail pointer maintained by the grouping circuitry 1910 may be updated").
However, the combination of Rabbani and Majewski does not expressly disclose
store, in the at least one memory block, data associated with a candidate node of the hierarchical acceleration structure identified during traversal of the ray.
Davison discloses
store, in the at least one memory block, data associated with a candidate node of the hierarchical acceleration structure identified during traversal of the ray (Davison, [0106]: teaches a search step that searches <read on during traversal of ray> for possible candidate reinsertions <read on candidate node>).
Davison is analogous art with respect to Rabbani, in view of Majewski because they are from the same field of endeavor, namely performing efficient ray tracing. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray tracing system rebalance the BVH hierarchy through candidate node reinsertions as taught by Davison into the teaching of Rabbani, in view of Majewski. The suggestion for doing so would allow the BVH hierarchy to be reorganized and balanced, thereby allowing for faster node searches, thus making future ray intersection testing faster and more efficient. Therefore, it would have been obvious to combine Davison with Rabbani, in view of Majewski.
Regarding Claim 5, the combination of Rabbani and Davison discloses the system of Claim 1. The combination of Rabbani and Davison does not expressly disclose the limitations of Claim 5; however, Majewski discloses wherein
the ray stack is in a memory local to the ray tracing circuitry (Majewski, [1023]: teaches the RT Stack 9300 <read on ray stack> being stored in a local cache, such as LSC 9202A, to reduce access latency and increase bandwidth as shown in FIG. 92B; FIG. 92B teaches L1/LSC 9202A and RT HW 9203A <read on ray tracing circuitry> being located in core 9211A of slice 9201A <read on memory being local to ray tracing circuitry>, which communicates data with L2/L3 9210 cache memory as shown in FIG. 92A), and
PNG
media_image8.png
318
406
media_image8.png
Greyscale
the linked memory stack is in a memory that is not local to the ray tracing circuitry (Majewski, FIG. 92A teaches memory 9298 <read on memory stack> communicating with memory interface 9215 of L2/L3 9210 cache memory, where memory 9298 is located outside <read on memory not being local to ray tracing circuitry> of slice 9201A, which contains RT HW 9203A <read on ray tracing circuitry>).
PNG
media_image9.png
312
583
media_image9.png
Greyscale
Majewski is analogous art with respect to Rabbani, in view of Davison because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Davison. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Davison.
Regarding Claims 8 and 15, the combination of Rabbani and Davison discloses the system and the method of Claims 1 and 9 respectively. The combination of Rabbani and Davison does not expressly disclose the limitations of Claims 8 and 15; however, Majewski discloses
a plurality of ray stacks, each associated with a separate linked memory stack (Majewski, FIG. 52A teaches traversal 5002, where rays are allocated by allocator 5205 to either ray bank 0 or ray bank 1 <read on ray stacks>, which corresponds to stack 0 and stack 1 <read on separate memory stacks>).
PNG
media_image10.png
344
575
media_image10.png
Greyscale
Majewski is analogous art with respect to Rabbani, in view of Davison because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Davison. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Davison.
Regarding Claim 17, the combination of Rabbani and Davison discloses the system of Claim 16. The combination of Rabbani and Davison does not expressly disclose the limitations of Claim 17; however, Majewski discloses wherein the local buffer comprises
a plurality of ray stacks, each having a fixed size (Majewski, [1031]: teaches "the ray tracing hardware unit manages the ray tracing stack allocation counters to keep the active set size <read on fixed size> within the predefined or limit—e.g., so that it fits into the L1 data cache/LSC"; [1023]: teaches "both rays to be traversed and traversal results are passed through these ray tracing stack 9300 allocations <read on plurality of ray stacks>").
Majewski is analogous art with respect to Rabbani, in view of Davison because they are from the same field of endeavor, namely efficient processing of ray-traced BVH data structures. Before the effective filing date of the claimed invention, it would have been obvious to a person of ordinary skill in the art to have the ray stack stored on local L1 cache memory as taught by Majewski into the teaching of Rabbani, in view of Davison. The suggestion for doing so would allow for faster processing of ray-traced BVH data structures, thereby improving overall rendering performance. Therefore, it would have been obvious to combine Majewski with Rabbani, in view of Davison.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Potter et al. (US 20220148249 A1) discloses memory space management for ray tracing operations;
Muthler et al. (US 20240095995 A1) discloses ray tracing hardware accelerator for traversing a hierarchical acceleration structure with reduced false positive ray intersections; and
Saleh et al. (US 20190197761 A1) discloses a texture processor-based ray tracing accelerator.
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARL TRUONG whose telephone number is (703)756-5915. The examiner can normally be reached 10:30 AM - 7:30 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kent Chang can be reached at (571) 272-7667. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/K.D.T./Examiner, Art Unit 2614
/KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614
Prosecution Insights