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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 12/12/2024, 03/05/2025, and 10/27/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 103
1 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.
2 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.
3 Claim(s) 1, 4, 6-14, 17, and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saeed et al. (US 20210304489 A1) in view of Peterson et al. (US 20110050698 A1).
4 Regarding claim 1, Saeed teaches an apparatus, comprising: ray intersect circuitry, configured to ([Abstract] reciting “When a programmable execution unit of a graphics processor is executing a graphics processing program to render a frame that represents a view of a scene using a ray tracing process, and the ray tracing process requires the determination of geometry that will be intersected by a ray, the programmable execution unit sends a message to a ray tracing acceleration data structure traversal circuit of the graphics processor”):
receive a ray intersect request that indicates origin and direction information for a ray in a graphics scene ([0086] reciting “Thus it in an embodiment indicates one or more of, and in an embodiment all of: the ray tracing acceleration data structure that is to be traversed; the origin (originating position (e.g. x, y, z coordinates)) for the ray that is to be tested (for which the traversal of the ray tracing acceleration data structure is to be determined); the direction of (a direction vector for) the ray that is to traverse the ray tracing acceleration data structure”);
traverse multiple nodes of a spatially organized acceleration data structure, wherein a given node of the multiple nodes indicates coordinates corresponding to a bounding region of the graphics scene ([Abstract] reciting “…the programmable execution unit sends a message to a ray tracing acceleration data structure traversal circuit of the graphics processor, for the ray tracing acceleration data structure traversal circuit to perform a traversal of a ray tracing acceleration data structure for the scene to determine geometry for the scene that may be intersected by the ray.”; [0111] reciting “In this case, the graphics processor can generate the ray tracing acceleration data structure in any suitable and desired manner, for example by testing geometry defined for the scene against respective bounding volumes, so as to determine the distribution of the geometry in a bounding volume hierarchy for the scene.”);
in response to detection that the ray intersects with a first bounding volume, store a local parametric value for the ray that indicates a point at which the ray intersected the first bounding volume ([0299] reciting “This then allows and facilitates testing a ray against the hierarchy of bounding volumes in the BVH tree until a leaf node is found. It is then only necessary to test the geometry associated with the particular leaf node for intersection with the ray.”; [0310] reciting “In this process, as shown in FIG. 5, the first intersection point 50 for each sampling position in the image plane (frame) is instead determined first using a rasterisation process and stored in an intermediate data structure known as a “G-buffer” 51. Thus, the process of generating a primary ray for each sampling position, and identifying the first intersection point of the primary ray with geometry in the scene, is replaced with an initial rasterisation process to generate the “G-buffer”.”); and
for one or more intersection tests between the ray and one or more child bounding volumes of the first bounding volume ([0297] reciting “FIG. 3 shows an exemplary binary BVH tree 30, constructed by enclosing the complete scene in an axis-aligned bounding volume (AABV), e.g. a cube, and then recursively subdividing the bounding volume into successive pairs of two sub-AABVs according to any suitable and desired, and, e.g. various, subdivision schemes (e.g. same number of objects per child, based on traversal cost, etc.), until a desired smallest subdivision (volume) is reached.”).
5 Although Saeed could teach to retrieve the stored local parametric value and use the retrieved local parametric value as an origin value of the ray for one or more intersection tests between the ray and one or more child bounding volumes of the first bounding volume ([0299] reciting “This then allows and facilitates testing a ray against the hierarchy of bounding volumes in the BVH tree until a leaf node is found. It is then only necessary to test the geometry associated with the particular leaf node for intersection with the ray.”), prior art from Peterson can teach this limitation further.
6 Peterson teaches to retrieve the stored local parametric value and use the retrieved local parametric value as an origin value of the ray for one or more intersection tests between the ray and one or more child bounding volumes of the first bounding volume ([0181] reciting “The origin and direction associated with ray ID 31 is retrieved via 1290. Also shape data, if identified in the packet, is obtained 1715 from memory resource 1291 where it is currently stored. If shape data is provided in the packet, then that shape data is used directly. Then the ray 31 is tested 1720 for intersection with shape 1 (or shapes defined by the retrieved data).”).
7 It would have been obvious to one with ordinary skill before the effective filing date of the claimed invention, to have modified the method (taught by Saeed) to incorporate the teachings of Peterson to provide a clearer method that can retrieve data regarding the values as well as the origin values that can be provided by the teachings of Saeed. Doing so would allow methods like to intersection test any such rays with the indicated geometric shape, and to output indications of any detected intersections as stated by Peterson ([0033] recited).
8 Regarding claim 4, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), wherein the ray intersect circuitry includes bounding volume test circuitry configured to test the ray for intersection with multiple bounding volumes in parallel and store different local parametric values for the ray for different intersected bounding volumes (Saeed; [0063] reciting “…but rather traverses the ray tracing acceleration data structure to determine geometry that a ray should be intersection-tested against, without performing the intersection test itself).”).
9 Regarding claim 6, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), wherein the ray intersect circuitry is configured to provide one or more intersection results to a shader processor based on the traversal of the spatially organized acceleration data structure (Saeed; [0090] reciting “…and the programmable execution unit when executing the shader program, when it reaches the instruction in the shader program, issuing a message to the ray tracing acceleration data structure traversal circuit to cause the ray tracing acceleration data structure traversal circuit to perform a traversal of a ray tracing acceleration data structure for a scene for a ray to determine geometry for the scene that may be intersected by the ray.”).
10 Regarding claim 7, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 above), wherein the intersect circuitry is further configured to group a set of rays into a group based on the set of rays targeting the same first node of the data structure and test the group in parallel for intersection with a bounding volume corresponds to the first node (Saeed; [0068] reciting “The process may involve casting further (secondary) rays from the respective first intersection points of primary rays with objects in the scene, and additionally using the intersection data for the secondary rays in determining the rendering of the sampling positions.”; [0206] reciting “Thus, in an embodiment, ray intersection determinations that are to be performed to continue the processing of sampling positions when ray traversal results are available, are grouped together for execution by the programmable execution unit (at least) based on the geometry type, and in an embodiment the surface type, that the corresponding ray was found to intersect.”).
11 Regarding claim 8, Saeed in view of Peterson teaches the apparatus of claim 1, wherein (see claim 1 rejection above):
the spatially organized data structure includes a node with a bounding region for which multiple primitives are indicated as children; and the spatially organized data structure includes a primitive for which multiple nodes, corresponding to different bounding regions, are indicated as parents (Saeed; [0114] reciting “Thus it may represent the geometry in terms of individual graphics primitives, or sets of graphics primitives, e.g. such that each leaf node of the tree structure represents a corresponding subset of the graphics primitives defined for the scene that occupies the volume that the leaf node corresponds to.”; [0298] reciting “Thus, each node in the BVH tree 30 will have a respective volume of the scene being rendered associated with it, with the end, leaf nodes 31 each representing a particular, non-overlapping, smallest subdivided volume of the scene, and any parent node representing, and being associated with, the volume of its child nodes.”).
12 Regarding claim 9, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), wherein the acceleration data structure is a bounding volume hierarchy (BVH) ([0108] reciting “The ray tracing acceleration data structure(s) can take any suitable and desired form, such as comprising a tree structure, such as a bounding volume hierarchy (BVH) tree.”).
13 Regarding claim 10, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), wherein the ray intersect circuitry includes bounding region test circuitry configured to test in parallel, using multiple bounding region tester circuits at the same time during the traversal, whether multiple rays in a set of rays intersect multiple different bounding volumes indicated by a node of the data structure ([0049] reciting “This can then lead to accelerated and more efficient traversing of the ray tracing acceleration data structures, as compared, for example, to arrangements in which that is done by executing appropriate programs using a programmable processing circuit (which may be relatively inefficient, e.g. due to poor memory access locality for execution threads corresponding to different rays). It can also allow the ray tracing acceleration data structure traversals to be performed in parallel (simultaneously) with the programmable execution unit performing other processing.”; [0062] reciting “In an embodiment, the ray tracing acceleration data structure traversal circuit is configured to and operable to perform a plurality of acceleration data structure traverses (for a plurality of different rays) in parallel (and simultaneously).”; [0219] reciting “…in an embodiment defined, maximum number of ray intersection determinations for which the execution may be performed together, e.g. depending upon the parallel processing capability of the programmable execution unit in this regard.”).
14 Regarding claim 11, Saeed in view of Peterson teaches the apparatus of claim 10, wherein the bounding region test circuitry includes (see claims 1 and 10 rejections above): common node calculation circuitry configured to perform one or more operations whose outputs are shared by the parallel tests ([0282] reciting “It should also be noted here that, as will be appreciated by those skilled in the art, the various functions, etc., of the technology described herein may be duplicated and/or carried out in parallel on a given processor. Equally, the various processing stages, etc., may share processing circuitry/circuits, etc., if desired.”; [0319] reciting “Typically, there will be multiple execution threads each executing at the same time (in parallel).”).
15 Regarding claim 12, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), wherein the ray intersect circuitry is further configured to access a shader memory space that is shared with a shader core configured to execute shader programs that includes commands for the ray intersect circuitry ([0227] reciting “In an embodiment, the graphics processor is part of an overall graphics (data) processing system that includes, e.g., and in an embodiment, a host processor (CPU) that, e.g., executes applications that require processing by the graphics processor. The host processor will send appropriate commands and data to the graphics processor to control it to perform graphics processing operations and to produce graphics processing output required by applications executing on the host processor.”; [0229] reciting “The graphics processor and/or graphics processing system may also comprise, and/or be in communication with, one or more memories and/or memory devices that store the data described herein, and/or the output data generated by the graphics processor, and/or store software (e.g. (shader) programs) for performing the processes described herein.”; [0318] reciting “FIG. 6 shows schematically the relevant configuration of one shader core 61, but as will be appreciated by those skilled in the art, any further shader cores of the graphics processor 60 will be configured in a corresponding manner.”).
16 Regarding claim 13, Saeed in view of Peterson teaches the apparatus of claim 1, wherein the apparatus is a computing device that includes (see claim 1 rejection above):
a graphics processor that includes the ray intersect circuitry ([Abstract] reciting “When a programmable execution unit of a graphics processor is executing a graphics processing program to render a frame that represents a view of a scene using a ray tracing process…”);
a central processing unit ([0078] reciting “The compiler (the compiler processing circuit) is in an embodiment part of, and in an embodiment executes on, a central processing unit (CPU), such as a host processor, of the graphics processing system, and is in an embodiment part of a driver for the graphics processor that is executing on the CPU (e.g. host processor).”); and
network interface circuitry ([0060] reciting “Thus, in an embodiment, the ray tracing acceleration data structure traversal circuit has a ray tracing acceleration data structure traversing (walking) state machine, a memory interface, and can cache partial and full ray tracing acceleration data structure traverses (walks), and ray tracing acceleration data structure entries.”).
17 Claim 14 has similar limitations as of claim 1, therefore it is rejected under the same rationale as claim 1.
18 Claim 17 has similar limitations as of claim 4, therefore it is rejected under the same rationale as claim 4.
19 Claim 19 has similar limitations as of claim 6, therefore it is rejected under the same rationale as claim 6.
20 Regarding claim 20, Saeed teaches a non-transitory computer readable storage medium having stored thereon design information that specifies a design of at least a portion of a hardware integrated circuit in a format recognized by a semiconductor fabrication system that is configured to use the design information to produce the circuit according to the design, wherein the design information specifies that the circuit includes ([0286] reciting “Such an implementation may comprise a series of computer readable instructions either fixed on a tangible, non-transitory intermediate, such as a computer readable intermediate, for example, diskette, CD ROM, ROM, RAM, flash memory, or hard disk.”; [0287] reciting “Further, such instructions may be stored using any memory technology, present or future, including but not limited to, semiconductor, magnetic, or optical, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, or microwave.”)…
21 The remainder of claim 20 has similar limitations as of claim 1, therefore it is rejected under the same rationale as claim 1.
22 Claim(s) 2 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saeed et al. (US 20210304489 A1) in view of Peterson et al. (US 20110050698 A1) as of claim 1 and 14, further in view of Benthin et al. (US 20190318445 A1).
23 Regarding claim 2, Saeed in view of Peterson teaches the apparatus of claim 1, wherein (see claim 1 rejection above): but does not explicitly teach the spatially organized data structure stores quantized bounding volume information for the first bounding volume that encodes coordinates of the first bounding volume; and the ray intersect circuitry is configured to store the local parametric value using a greater precision per coordinate value than the quantized bounding volume information.
24 Benthin teaches the spatially organized data structure stores quantized bounding volume information for the first bounding volume that encodes coordinates of the first bounding volume ([Abstract] reciting “…the compression circuitry to quantize the lowest level nodes to generate quantized lowest level nodes and to store each quantized lowest level node and associated leaf data without the pointers to the leaf data.”; [0249] reciting “What remains is quantizing the AABB inside the quantized oriented space. A problem here is that projecting a point p onto a compressed coordinate axis of that space (e.g., by calculating dot(v.sub.x′, p)) yields values of a potentially large range (as values p are typically encoded as floating point numbers).”); and
the ray intersect circuitry is configured to store the local parametric value using a greater precision per coordinate value than the quantized bounding volume information ([0188] reciting “In one embodiment, ray intersection logic of the graphics processor calculates the hit distances of a ray to axis-aligned planes to perform a ray-box testing. The ray intersection logic can use BVH node logic including support for the quantized node structure of Table 4. The logic can calculate the distances to the lower bounds of the parent bounding box using the higher precision parent lower bounds and the quantized relative extents of the child boxes.”).
25 It would have been obvious to one with ordinary skill before the effective filing date of the claimed invention, to have modified the method (taught by Saeed in view of Peterson) to incorporate the teachings of Benthin to provide a method can store quantized bounding volumes for the specific coordinates, as well as to store the ray intersect circuitry to store the local parametric values from the teachings of Saeed in view of Peterson. Doing so would comprise a plurality of hierarchically arranged nodes as stated by Benthin ([Abstract] recited).
26 Claim 15 has similar limitations as of claim 2, therefore it is rejected under the same rationale as claim 2.
27 Claim(s) 3 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saeed et al. (US 20210304489 A1) in view of Peterson et al. (US 20110050698 A1) as of claim 1, further in view of Clark et al. (US 20190355166 A1).
28 Regarding claim 3, Saeed in view of Peterson teaches the apparatus of claim 1 (see claim 1 rejection above), but does not explicitly teach wherein to store the local parametric value, the ray intersect circuitry is configured to push the local parametric value on to a traversal stack for a depth-first traversal.
29 Clark teaches wherein to store the local parametric value, the ray intersect circuitry is configured to push the local parametric value on to a traversal stack for a depth-first traversal ([Abstract] reciting “the first traversal technique being a depth-first traversal technique; and traversing one or more lower levels of nodes of the hierarchical acceleration structure according to a second traversal technique, the second traversal technique not being a depth-first traversal technique.”; [0066] reciting “The nodes near the top of the hierarchical acceleration structure represent relatively large volumes in the scene (compared to the volumes represented by the nodes near the bottom of the hierarchical acceleration structure), so the number of rays that intersect with nodes near the top of the hierarchy is greater than the number of rays that intersect with nodes near the bottom of the hierarchy.”).
30 It would have been obvious to one with ordinary skill before the effective filing date of the claimed invention, to have modified the method (taught by Saeed in view of Peterson) to incorporate the teachings of Clark to provide a method that utilizes a depth first traversal for storing values from the ray intersect circuitry utilizing the nodes provided by Saeed in view of Peterson. Doing so would provide for performing intersection testing for use in rendering an image of a 3-D scene as stated by Clark ([Abstract] recited).
31 Claim 16 has similar limitations as of claim 3, therefore it is rejected under the same rationale as claim 3.
32 Claim(s) 5 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Saeed et al. (US 20210304489 A1) in view of Peterson et al. (US 20110050698 A1) as of claim 1, further in view of Muthler et al. (US 20210390757 A1).
33 Regarding claim 5, Saeed in view of Peterson teaches the apparatus of claim 1, wherein the apparatus is configured to (see claim 1 rejection above): but does not explicitly teach to transform coordinates of the ray in response to reaching an instance node of the data structure during the traversal.
34 Muthler teaches to transform coordinates of the ray in response to reaching an instance node of the data structure during the traversal ([0073] reciting “Described in another way, in the example of FIG. 3A, each of the nodes 302, 304, 306 and 308 is an instance node (e.g. nodes specifying a transform from one coordinate space to another), and in an embodiment in which only instance nodes may include node masks (which are, in relation to instance nodes, referred to as instance masks), the test for instance masking is performed on the instance nodes.”).
35 It would have been obvious to one with ordinary skill before the effective filing date of the claimed invention, to have modified the method (taught by Saeed in view of Peterson) to incorporate the teachings of Muthler to provide a method that can transform coordinates based on a type of instance node during the traversal methods taught by the teachings of Saeed in view of Peterson. Doing so would support multiple specifiers for controlling the traversal of a ray tracing acceleration data structure as stated by Muthler ([Abstract] recited).
36 Claim 18 has similar limitations as of claim 5, therefore it is rejected under the same rationale as claim 5.
Conclusion
37 The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Hwang et al. (US 20170091898 A1) teaches a traversing tree utilizing ray tracing, as well as verification surrounding a first ray.
Reshetov et al. (US 20080158227 A1) teaches multi-level ray tracing that involves thermal management and various intersections regarding trees.
38 Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHNNY TRAN LE whose telephone number is (571)272-5680. The examiner can normally be reached Mon-Thu: 7:30am-5pm; First Fridays Off; Second Fridays: 7:30am-4pm.
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.
/JOHNNY T LE/Examiner, Art Unit 2614
/KENT W CHANG/Supervisory Patent Examiner, Art Unit 2614
Prosecution Insights