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 .
This is in response to Applicant’s Request for Continued Examination with Amendments and Remarks filed on 3/12/2026. Claims 8-13 and 15 have been amended. Claims 1, 3-15, and 17-20 are present for examination.
The 35 USC 101 rejections have been withdrawn in view of the amendments.
Response to Arguments
Applicant's arguments filed 3/12/2026 with respect to the 35 USC 103 rejection have been fully considered but they are not persuasive.
Applicant submits: “In Lee, the transmission from the intersection tester to the centralized controller occurs prior to any node-type evaluation, and the controller only subsequently identifies the node type to determine a next action. Consequently, even when combined with Saleh, the resulting architecture lacks an intersection engine capable of selecting, based on a type of the first node, between sending the intersection result via a first transmission path to a shader and sending the intersection result via a second transmission path to hardware traversal recursion circuitry.” (See Remarks filed on 3/12/2026, p. 7, last para. – p. 8, 1st para.)
The examiner respectfully disagrees. Saleh teaches performing ray intersection with a BVH structure, if the ray intersects with a non-leaf node (box node, or a node of a first type), it will continue to test its children node, and if the ray intersects with a leaf node (or node of a second type), one or more stages of the ray tracing pipeline based will be invoked, these stages associated with shader programs. Therefore, Saleh already discloses transmitting intersection results to different places (traversal recursion circuitry for continue ray intersection with a node or ray-triangle intersection and shading). Saleh just does not expressly disclose for the first node via a first transmission path to traversal recursion circuitry; and performing a traversal operation at the traversal recursion circuitry. On the other hand, Lee discloses transmitting a result via a first transmission path to traversal recursion circuitry (Lee, FIG. 6, showing steps of determining whether nodes intersects ray, and if the type of next target node is inner node, the process going back to step S610 for further intersection determination with child nodes, FIG. 8, showing information from the intersection tester 320 can be transmitted via a first transmission path to the unit 120, indicating if the next target node is inner node as the first type, a result from the intersection tester can be transmitted to the unit 120 as the traversal recursion circuitry via a first transmission path). Combining Saleh and Lee would allow transmitting an intersection result via a first transmission path.
Applicant further submits: “Lee describes the intersection tester 320 transmits results to the controller 330 (next target node determiner 332). (See, e.g., Lee at [0148]-[0149] and FIG. 8) The controller 330 then determines the next target node and only subsequently determines the node type (e.g., inner node vs. lead node) to determine a next action. (Lee at FIG. 6, element S625-S645.) Thus, in Lee, the transmission from the intersection tester to the controller occurs prior to any node-type evaluation. (Id.)” (See Remarks filed on 3/12/2026, p. 8, 4th para.) “Consequently, Lee at least fails to disclose ‘transmitting an intersection result for the first node … to traversal recursion circuitry’ ‘in response to identifying that ]the] first node… is of a first type,’ as recited by independent claim 1 (emphasis added). In Lee, the intersection tester does not identify the node type in order to select a transmission path; it simply passes data to the controller. (See, e.g., Lee at [0148]-[0149] and FIGs. 6 and 8.)” (See Remarks filed on 3/12/2026, p. 8, last par. – p. 9., 1st para.)
The examiner respectfully disagrees. As discussed above, Saleh discloses transmitting intersection results to different places based on the type of nodes. Lee, para. [105] discloses if the next target node is an inner node, information is transmitted to information obtainer 310, and para. [0106] discloses if the next target node is a lead node, information is transmitted to the IST unit 130. Transmitting information to different destination indicates the transmission paths to one destination is different than the transmission path to a different destination. Lee, FIG. 8 also shows different paths to 310 and 130. Therefore, Lee discloses information transmission from the controller occurs after a node-type evaluation. Because intersection results are fed into the controller and the controller can pass information via different paths based on the node type, combining Saleh and Lee could allow transmission intersection results via different paths to different destinations based on the node types.
Applicant further submits: “Furthermore, Lee fails to disclose ‘transmitting an intersection result for the second node via a second transmission path to a shader’ in response to identifying the node type at the intersection engine. In Lee, the path from the intersection tester is fixed to the controller. The intersection tester in Lee does not function as a router that selectively transmits to a shader via one path or to recursion circuitry via another path based on the node type. Applicant’s claimed architecture offloads this decision-making and routing to the intersection engine circuitry to bypass the shader for specific node types, a structural feature absent from the rigid, centralized controller pipeline of Lee.” (See Remarks filed on 3/12/2026, p. 9., 1st para.)
The examiner respectfully disagrees. In the final rejection dated 11/12/2025, Saleh is cited to teach in response to identifying a second node of the raytracing acceleration structure is of a second type, transmitting an intersection result for the second node via a second transmission path to a shader. Also Lee FIG. 8 shows the results are transmitted via different paths, going back to the intersection tester or to shading unit, or to the shading unit via IST UNIT.
Therefore, Applicant’s arguments are not persuasive. The 35 USC 103 rejections have been maintained.
Claim Objections
Claim 9 is objected to because of the following informalities: “selecting” should be “transmitting”. Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “compute unit” in claim 15.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
Claim(s) 1, 3, 4, 8, 9, 11, 14, 15, 17, and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Publication No. 2021/0287421 A1 to Saleh et al. in view of US Patent Publication No. 20150348308 A1 to Lee et al.
Regarding claim 1, Saleh discloses a method (Saleh, Abstract, a technique for performing a ray tracing operation for a ray) comprising:
in response to identifying a first node of a raytracing acceleration structure is of a first type, providing an intersection result for the first node to traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304 performs a ray intersection test, para. [0028], disclosing the acceleration structure traversal stage 304 traverses an acceleration structure, para. [0057], disclosing if a ray does not intersect with a non-leaf node, the non-leaf nodes’ descendant nodes are eliminated from traversal, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box and the ray intersection test unit 304 tests descendants of that node for intersection with the ray, indicating when the ray intersect the box node (identified as a first type of nodes of bounding volume hierarchy), the ray passing through the axis-aligned bounding box (an intersection result for the first node) is provided to the acceleration structure traversal stage (the traversal recursion circuitry) to test descendants of the node for intersection with the ray);
in response to identifying a second node of the raytracing acceleration structure is of a second type, transmitting an intersection result for the second node via a second transmission path to a shader (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0070], disclosing invoking one or more stages of the ray tracing pipeline based on the results of the ray-triangle intersection tests, and these stages are associated with shader programs, indicating when the traversed node is a leaf node (second node of the raytracing acceleration structure is a of a second type), the ray-triangle intersection test is performed and the results of the ray-triangle intersection tests (an intersection result for the second node) are transmitted via a second transmission path to a shader); and
in response to the intersection result for the first node, performing a traversal operation for the raytracing acceleration structure (Saleh, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box (the intersection result) and the ray intersection test unit 304 tests descendants of that node for intersection with the ray (traversal operations)).
However, Saleh does not expressly disclose transmitting an intersection result for the first node via a first transmission path to traversal recursion circuitry; and performing a traversal operation at the traversal recursion circuitry.
On the other hand, Lee discloses transmitting a result via a first transmission path to traversal recursion circuitry (Lee, FIG. 6, showing steps of determining whether nodes intersects ray, and if the type of next target node is inner node, the process going back to step S610 for further intersection determination with child nodes, FIG. 8, showing information from the intersection tester 320 can be transmitted via a first transmission path to the unit 120, para. [105] discloses if the next target node is an inner node, information is transmitted to information obtainer 310, indicating if the next target node is inner node as the first type, a result from the intersection tester can be transmitted to the unit 120 including unit 310 and 320 as the traversal recursion circuitry via a first transmission path); and performing a traversal operation for the raytracing acceleration structure at the traversal recursion circuitry (Lee, FIG. 8, showing the unit 120 including an intersection tester and next target node determiner, para. [0069], disclosing an AS including root node, inner node, leave node, and primitive, para. [0145], disclosing the TRV unit 120 receives ray information and information for traversing a next node, indicating the TRV unit 120, different than the intersection tester, can be the traversal recursion circuitry that can perform a traversal operation for the AS (the raytracing acceleration structure)). Because Saleh discloses providing intersection results for the first node to the traversal recursion circuitry, combining Saleh and Lee could allow transmitting an intersection result for the first node via a first transmission path to the traversal recursion circuitry.
Before the invention was effectively filed, it would have been obvious for a person skilled in the art to combine Saleh with Lee. The suggestion/motivation would have been to efficiently perform an intersection test between a ray and each child node, as suggested by Lee (see Lee, para. [0154]).
PNG
media_image1.png
600
746
media_image1.png
Greyscale
PNG
media_image2.png
446
704
media_image2.png
Greyscale
PNG
media_image3.png
780
558
media_image3.png
Greyscale
Regarding claim 3, Saleh in view of Lee discloses the method of claim 1, wherein the first type is a box node (Saleh, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box and the ray intersection test unit 304 tests descendants of that node for intersection with the ray, indicating the first type of the node is a non-leaf node (box node)).
Regarding claim 4, Saleh in view of Lee discloses the method of claim 3, wherein the second type is a triangle node (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), indicating the second type is a leaf node (triangle node)).
Regarding claim 8, Saleh discloses a method (Saleh, Abstract, a technique for performing a ray tracing operation for a ray) comprising:
identifying via intersection engine circuitry an intersection result for a first node of a raytracing acceleration structure (Saleh, para. [0024], disclosing acceleration structure traversal stage 304 performs a ray intersection test, para. [0028], disclosing the acceleration structure traversal stage 304 traverses an acceleration structure, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0057], disclosing if a ray does not intersect with a non-leaf node, the non-leaf nodes’ descendant nodes are eliminated from traversal, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box and the ray intersection test unit 304 tests descendants of that node for intersection with the ray, FIG. 3, showing Acceleration Structure Traversal Stage (Ray Intersection Test Unit) 304, indicating when a ray intersect a node, a type of the node, non-leaf node or leaf node of the bounding volume hierarchy (raytracing acceleration structure), can be identified via the Acceleration Structure Traversal Stage (Ray Intersection Test Unit) 304 as the intersection engine circuitry); and
transmitting, based on a type of the first node, the intersection result via a first transmission path to a shader or via a second transmission path to hardware traversal recursion circuitry (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box (the intersection result) and the ray intersection test unit 304 tests descendants of that node for intersection with the ray (traversal operations), para. [0070], disclosing invoking one or more stages of the ray tracing pipeline based on the results of the ray-triangle intersection tests, and these stages are associated with shader programs, indicating when the traversal node is a leaf node, sending the intersection result via a first transmission path to a shader teaches transmitting, based on a type of the first node (leaf node), the intersection result via a first transmission path to a shader).
However, although Saleh discloses transmitting, based on a type of the first node, the intersection result to hardware traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304 performs a ray intersection test, para. [0028], disclosing the acceleration structure traversal stage 304 traverses an acceleration structure, para. [0057], disclosing if a ray does not intersect with a non-leaf node, the non-leaf nodes’ descendant nodes are eliminated from traversal, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box and the ray intersection test unit 304 tests descendants of that node for intersection with the ray, indicating when the ray intersect the box node (identified as a type of nodes of bounding volume hierarchy), the ray passing through the axis-aligned bounding box (an intersection result for the first node) is transmitted to the acceleration structure traversal stage (the hardware traversal recursion circuitry) to test descendants of the node for intersection with the ray), Saleh does not expressly disclose responsive to transmitting the intersection result via the second transmission path, performing a traversal operation at the hardware traversal recursion circuitry.
On the other hand, Lee discloses transmitting, based on a type of the first node, a result via a second transmission path to hardware traversal recursion circuitry (Lee, FIG. 6, showing steps of determining whether nodes intersects ray, and if the type of next target node is inner node, the process going back to step S610 for further intersection determination with child nodes, FIG. 8, showing information from the intersection tester 320 can be transmitted via a first transmission path to the unit 120, para. [105] discloses if the next target node is an inner node, information is transmitted to information obtainer 310, indicating if the next target node is inner node as the first type, a result from the intersection tester can be transmitted to the unit 120 including units 310 and 320 as the hardware traversal recursion circuitry via a second transmission path), and responsive to transmitting the intersection result via the second transmission path, performing a traversal operation at the hardware traversal circuitry (Lee, FIG. 8, showing the unit 120 including an intersection tester and next target node determiner, para. [0069], disclosing an AS including root node, inner node, leave node, and primitive, para. [0145], disclosing the TRV unit 120 receives ray information and information for traversing a next node, indicating the TRV unit 120, different than the intersection tester, can be the hardware traversal recursion circuitry that can perform a traversal operation for the AS (the raytracing acceleration structure) in responsive to transmitting the result via the second transmission path). Because Saleh discloses providing the intersection result to hardware circuitry, combining Saleh and Lee could provide responsive to transmitting the intersection result via the second transmission path, performing a traversal operation at the hardware traversal circuitry.
Before the invention was effectively filed, it would have been obvious for a person skilled in the art to combine Saleh with Lee. The suggestion/motivation would have been to efficiently perform an intersection test between a ray and each child node, as suggested by Lee (see Lee, para. [0154]).
Regarding claim 9, Saleh in view of Lee discloses the method of claim 8, wherein selecting comprises: transmitting the intersection result via the second transmission path to the hardware traversal recursion circuitry in response to the first node being a box node (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box (the intersection result) and the ray intersection test unit 304 tests descendants of that node for intersection with the ray (traversal operations), para. [0070], disclosing invoking one or more stages of the ray tracing pipeline based on the results of the ray-triangle intersection tests, and these stages are associated with shader programs, Lee, FIG. 6, showing steps of determining whether nodes intersects ray, and if the type of next target node is inner node, the process going back to step S610 for further intersection determination with child nodes, FIG. 8, showing information from the intersection tester 320 can be transmitted via a second transmission path to the unit 120, indicating when the first node is an inner node corresponding to a box node, the intersection result will be transmitted via the second transmission path to the unit 120 as the hardware traversal recursion circuitry to test descendants of that node for intersection with the ray (traversal operations) in response to the traversed node is a non-leaf node (box node)). Before the invention was effectively filed, it would have been obvious for a person skilled in the art to combine Saleh with Lee. The suggestion/motivation would have been to efficiently perform an intersection test between a ray and each child node, as suggested by Lee (see Lee, para. [0154]).
Regarding claim 11, Saleh in view of Lee discloses the method of claim 9, further comprising: transmitting the intersection result via a first transmission path to the shader in response to the first node being a triangle node (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy, for each non-leaf node tested, eliminating branches below that node if the box test for that non-leaf node fails, for leaf nodes that are not eliminated, a ray-triangle intersection test is performed to determine whether the ray intersects the triangle at that leaf node, para. [0066], disclosing a bounding volume hierarchy 404 includes non-leaf nodes (“box nodes”) and leaf nodes (“triangle nodes”), the ray intersection test unit 304 tests a box node for intersection, if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box (the intersection result) and the ray intersection test unit 304 tests descendants of that node for intersection with the ray (traversal operations), para. [0070], disclosing invoking one or more stages of the ray tracing pipeline based on the results of the ray-triangle intersection tests, and these stages are associated with shader programs, indicating the shader is selected in response to the traversed node is a leaf node (triangle node) and the intersection result is transmitted via the first transmission path to the shader).
Regarding claim 14, Saleh in view of Lee discloses the method of claim 8, wherein the raytracing acceleration structure comprises a bounding volume hierarchy (Saleh, para. [0035], disclosing a ray intersection test would be performed by traversing through the bounding volume hierarchy).
Regarding claim 15, it recites similar limitations of claim 1 but in a processing unit form. The similar rationale of claim 1 rejection can be used to reject claim 15. In addition, Saleh discloses A processing unit (Saleh, para. [0014], disclosing a processor includes a CPU, a GPU, or one or more processor cores) comprising: intersection engine circuitry and traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0028], disclosing the acceleration structure traversal stage traverses an acceleration structure and tests the ray against triangles in the scene, indicating the acceleration structure traversal stage can correspond to intersection engine circuitry and traversal recursion circuitry). Also, Lee discloses intersection engine circuitry and traversal recursion circuitry (see Lee, FIG. 8, Intersection Tester 320 and Unit 120).
Regarding claim 17, it recites similar limitations of claim 3 but in a processing unit form. The similar rationale of claim 3 rejection can be used to reject claim 17. In addition, Saleh discloses A processing unit (Saleh, para. [0014], disclosing a processor includes a CPU, a GPU, or one or more processor cores) comprising: intersection engine circuitry and traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0028], disclosing the acceleration structure traversal stage traverses an acceleration structure and tests the ray against triangles in the scene, indicating the acceleration structure traversal stage can correspond to intersection engine circuitry and traversal recursion circuitry). Also, Lee discloses intersection engine circuitry and traversal recursion circuitry (see Lee, FIG. 8, Intersection Tester 320 and Unit 120).
Regarding claim 18, it recites similar limitations of claim 4 but in a processing unit form. The similar rationale of claim 4 rejection can be used to reject claim 18. In addition, Saleh discloses A processing unit (Saleh, para. [0014], disclosing a processor includes a CPU, a GPU, or one or more processor cores) comprising: intersection engine circuitry and traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0028], disclosing the acceleration structure traversal stage traverses an acceleration structure and tests the ray against triangles in the scene, indicating the acceleration structure traversal stage can correspond to intersection engine circuitry and traversal recursion circuitry). Also, Lee discloses intersection engine circuitry and traversal recursion circuitry (see Lee, FIG. 8, Intersection Tester 320 and Unit 120).
Claim(s) 5, 10, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saleh in view of Lee as applied to claims 1, 9, and 15 above, and further in view of US Patent Publication No. 2024/0078741 to Bruce.
Regarding claim 5, Saleh in view of Lee discloses the method of claim 1. However, Saleh or Lee does not expressly disclose wherein the traversal operation comprises generating an address pointer for a second node of the raytracing acceleration structure.
On the other hand, Bruce discloses the traversal operation comprises generating an address pointer for a second node of the raytracing acceleration structure (Bruce, Fig. 10, showing for each hit child (957), calculating node index (961) or calculating leaf index (965), para. [0361], disclosing executing ray-volume testing with a given node in the BVH tree, a ray performing the traversal operation that needs to be tested for intersection with the node (step 951), para. [0363], disclosing for each child node volume that was intersected, a result of the intersection testing is then returned, para. [0365], disclosing a node index for a non-leaf child node or a leaf index for a leaf child node is calculated, indicating the node/leaf index for the child node (an address pointer) for the child node (a second node) of the BVH (the raytracing acceleration structure) is generated by the traversal generation).
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Bruce to generate address pointers to a second node when traversing the raytracing acceleration structure. The suggestion/motivation would have been to determine a node traversal order for vising the child nodes during the ray-volume intersection testing and to optimize the overall ray tracing traversal operation, as suggested by Bruce (see Bruce, paras. [0370] and [0372]).
PNG
media_image4.png
660
426
media_image4.png
Greyscale
Regarding claim 10, Saleh in view of Lee discloses the method of claim 9, further comprising: response to transmitting the intersection result via the second transmission path: traverse a second node, at the hardware traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0066], disclosing if the ray does intersect the box node, then the ray does pass through the axis-aligned bounding box and the ray intersection test unit 304 tests descendants of that node for intersection with the ray, Lee, FIG. 8, showing the results from Intersection Tester 320 is selected to send to the Unit 120 as the hardware traversal recursion circuitry, indicating traversing a second node included in the descendants of the intersected box node is performed at the ray intersection test unit 304 as the hardware traversal recursion circuitry). However, Saleh or Lee does not expressly disclose generating, at the hardware traversal recursion circuitry, an address pointer for a second node of the raytracing acceleration structure.
On the other hand, Bruce discloses generating, an address pointer for a second node of the raytracing acceleration structure (Bruce, Fig. 10, showing for each hit child (957), calculating node index (961) or calculating leaf index (965), para. [0361], disclosing executing ray-volume testing with a given node in the BVH tree, a ray performing the traversal operation that needs to be tested for intersection with the node (step 951), para. [0363], disclosing for each child node volume that was intersected, a result of the intersection testing is then returned, para. [0365], disclosing a node index for a non-leaf child node or a leaf index for a leaf child node is calculated, indicating the node/leaf index for the child node (an address pointer) for the child node (a second node) of the BVH (the raytracing acceleration structure) is generated by the traversal generation). Combining Saleh in view of Lee with Bruce would allow the node index as the address pointer to be generated at the ray intersection test unit 304 as the hardware traversal recursion circuitry.
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Bruce to generate address pointers to a second node when traversing the raytracing acceleration structure. The suggestion/motivation would have been to determine a node traversal order for vising the child nodes during the ray-volume intersection testing and to optimize the overall ray tracing traversal operation, as suggested by Bruce (see Bruce, paras. [0370] and [0372]).
Regarding claim 19, it recites similar limitations of claim 5 but in a processing unit form. The similar rationale of claim 5 rejection can be used to reject claim 19. In addition, Saleh discloses A processing unit (Saleh, para. [0014], disclosing a processor includes a CPU, a GPU, or one or more processor cores) comprising: intersection engine circuitry and traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0028], disclosing the acceleration structure traversal stage traverses an acceleration structure and tests the ray against triangles in the scene, indicating the acceleration structure traversal stage can correspond to intersection engine circuitry and traversal recursion circuitry). Also, Lee discloses intersection engine circuitry and traversal recursion circuitry (see Lee, FIG. 8, Intersection Tester 320 and Unit 120).
Claim(s) 6, 7, 12, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saleh in view of Lee as applied to claims 1, 9, and 15 above, and further in view of US Patent Publication No. 2017/0178385 A1 to Akenine-Moller.
Regarding claim 6, Saleh in view of Lee discloses the method of claim 1. However, Saleh or Lee does not expressly disclose in response to identifying that a number of operations generated by the raytracing acceleration structure exceeds a threshold, providing an intersection result for a second node of the raytracing acceleration structure to a shader.
On the other hand, Akenine-Moller discloses in response to identifying a number of operations generated by the raytracing acceleration structure exceeds a threshold, providing an intersection result for a second node of the raytracing acceleration structure to a shader (Akenine-Moller, para. [0120], disclosing rays are sent as input to the traversal units which traverse each ray against a BVH or other acceleration data structure, para. [0124], disclosing a traversal unit (TU) offload engine detects when one or more TU queues are full, or have reached a threshold, and offloads to traversal program code executed on one or more of the execution units of the graphics processor, traversal work is then performed concurrently by the TU engines and the execution units running the traversal program code, para. [0125], disclosing FIG. 16 shows both the TU offload engine for offloading work from the TU queues to the traversal program code and the IU offload engine for offloading work from the IU queues to the intersection program code , both traversal and intersection can be done on the EUs depending on where the bottlenecks are. Since these processing operations may vary within a frame, offloading of work may be changed dynamically depending on the pressure on the system, indicating when the work in the TU queues and/or IU queues can correspond to the operations generated by the raytracing acceleration structure for node traversal and/or intersection testing and when the number of entries in the queues exceeds a threshold, they are offloaded to corresponding program code (shader), and such offloaded work in the queues will include intersection results for second node in the structure).
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Akenine-Moller to offload work in traversal or intersection unit queues to corresponding program code (shader) when the queues are full or reaching a threshold. The suggestion/motivation would have been to preventing the intersection units from becoming overloaded and reducing or removing the traversal unit bottleneck (see Akenine-Moller, para. [0121] and [0124]).
PNG
media_image5.png
422
550
media_image5.png
Greyscale
Regarding claim 7, Saleh in view of Lee discloses the method of claim 1. However, Saleh or Lee does not expressly disclose providing the intersection result for the second node based on an amount of space available at a stack associated with the raytracing acceleration structure.
On the other hand, Akenine-Moller discloses providing the intersection result for the second node based on an amount of space available at a stack associated with the raytracing acceleration structure (Akenine-Moller, para. [0120], disclosing rays are sent as input to the traversal units which traverse each ray against a BVH or other acceleration data structure, para. [0124], disclosing a traversal unit (TU) offload engine detects when one or more TU queues are full, or have reached a threshold, and offloads to traversal program code executed on one or more of the execution units of the graphics processor, traversal work is then performed concurrently by the TU engines and the execution units running the traversal program code, para. [0125], disclosing FIG. 16 shows both the TU offload engine for offloading work from the TU queues to the traversal program code and the IU offload engine for offloading work from the IU queues to the intersection program code , both traversal and intersection can be done on the EUs depending on where the bottlenecks are. Since these processing operations may vary within a frame, offloading of work may be changed dynamically depending on the pressure on the system, indicating when the TU queues and/or IU queues can correspond to a stack associated with the BVH (raytracing acceleration structure), when they are full or have reached a threshold (corresponding to the space available), the work in the queue are offloaded to corresponding program code (shader), and such offloaded work in the queues will include intersection results for second node in the structure).
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Akenine-Moller to offload work in traversal or intersection unit queues to corresponding program code (shader) when the queues are full or reaching a threshold (based on an amount of space available). The suggestion/motivation would have been to preventing the intersection units from becoming overloaded and reducing or removing the traversal unit bottleneck (see Akenine-Moller, para. [0121] and [0124]).
Regarding claim 12, Saleh in view of Lee discloses the method of claim 9. However, Saleh or Lee does not expressly disclose transmitting the intersection result via the first transmission path to the shader in response to a number of recursion operations generated by the hardware traversal recursion circuitry exceeding a threshold.
On the other hand, Akenine-Moller discloses selecting the shader in response to a number of recursion operations generated by the hardware traversal recursion circuitry exceeding a threshold (Akenine-Moller, para. [0120], disclosing rays are sent as input to the traversal units which traverse each ray against a BVH or other acceleration data structure, para. [0124], disclosing a traversal unit (TU) offload engine detects when one or more TU queues are full, or have reached a threshold, and offloads to traversal program code executed on one or more of the execution units of the graphics processor, traversal work is then performed concurrently by the TU engines and the execution units running the traversal program code, para. [0125], disclosing FIG. 16 shows both the TU offload engine for offloading work from the TU queues to the traversal program code and the IU offload engine for offloading work from the IU queues to the intersection program code, both traversal and intersection can be done on the EUs depending on where the bottlenecks are. Since these processing operations may vary within a frame, offloading of work may be changed dynamically depending on the pressure on the system, indicating when the work in the IU queues can correspond to the operations generated by the TU as hardware traversal recursion circuitry and when the number of entries in the queue exceeds a threshold, they are offloaded to corresponding program code (shader)). Because Saleh discloses transmitting the intersection result via the first transmission path to the shader, combining Saleh in view of Lee with Akenine-Moller could allow transmitting the intersection result via the first transmission path to the shader in response to a number of recursion operations generated by the hardware traversal recursion circuitry exceeding a threshold.
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Akenine-Moller to offload work in traversal or intersection unit queues to corresponding program code (shader) when the queues are full or reaching a threshold. The suggestion/motivation would have been to preventing the intersection units from becoming overloaded and reducing or removing the traversal unit bottleneck (see Akenine-Moller, para. [0121] and [0124]).
Regarding claim 13, Saleh in view of Lee discloses the method of claim 9. However, Saleh or Lee does not expressly disclose transmitting the intersection result via the first transmission path to the shader in response to an amount of space at a stack associated with the raytracing acceleration structure being below a threshold.
On the other hand, Akenine-Moller discloses selecting the shader in response to an amount of space at a stack associated with the raytracing acceleration structure being below a threshold (Akenine-Moller, para. [0120], disclosing rays are sent as input to the traversal units which traverse each ray against a BVH or other acceleration data structure, para. [0124], disclosing a traversal unit (TU) offload engine detects when one or more TU queues are full, or have reached a threshold, and offloads to traversal program code executed on one or more of the execution units of the graphics processor, traversal work is then performed concurrently by the TU engines and the execution units running the traversal program code, para. [0125], disclosing FIG. 16 shows both the TU offload engine for offloading work from the TU queues to the traversal program code and the IU offload engine for offloading work from the IU queues to the intersection program code, both traversal and intersection can be done on the EUs depending on where the bottlenecks are. Since these processing operations may vary within a frame, offloading of work may be changed dynamically depending on the pressure on the system, indicating the IU queues can correspond to a stack associated with the BVH (raytracing acceleration structure), when they are full (an amount of space being below a threshold), the work in the queue are offloaded to corresponding program code (shader), and such offloaded work in the queues will include intersection results for second node in the structure). Because Saleh discloses transmitting the intersection result via the first transmission path to the shader, combining Saleh in view of Lee with Akenine-Moller could allow transmitting the intersection result via the first transmission path to the shader in response to an amount of space at a stack associated with the raytracing acceleration structure being below a threshold.
Before the effective filing date of the claimed invention, it would have been obvious for a person skilled in the art to modify Saleh in view of Lee with Akenine-Moller to offload work in traversal or intersection unit queues to corresponding program code (shader) when the queues are full or reaching a threshold (based on an amount of space available). The suggestion/motivation would have been to preventing the intersection units from becoming overloaded and reducing or removing the traversal unit bottleneck (see Akenine-Moller, para. [0121] and [0124]).
Regarding claim 20, it recites similar limitations of claim 6 but in a processing unit form. The similar rationale of claim 6 rejection can be used to reject claim 20. In addition, Saleh discloses A processing unit (Saleh, para. [0014], disclosing a processor includes a CPU, a GPU, or one or more processor cores) comprising: intersection engine circuitry and traversal recursion circuitry (Saleh, para. [0024], disclosing acceleration structure traversal stage 304, para. [0026], disclosing the acceleration structure traversal stage can be implemented in hardware, para. [0028], disclosing the acceleration structure traversal stage traverses an acceleration structure and tests the ray against triangles in the scene, indicating the acceleration structure traversal stage can correspond to intersection engine circuitry and traversal recursion circuitry). Also, Lee discloses intersection engine circuitry and traversal recursion circuitry (see Lee, FIG. 8, Intersection Tester 320 and Unit 120).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HAIXIA DU whose telephone number is (571)270-5646. The examiner can normally be reached Monday - Friday 8:00 am-4:00 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, Kee Tung can be reached at 571-272-7794. 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.
/HAIXIA DU/Primary Examiner, Art Unit 2611