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 .
DETAILED ACTION
Priority
U.S. Application No. 18/668,599 is a continuation of U.S. Application No. 16/897,745, filed June 10, 2020, and claims priority thereto under 35 U.S.C. § 120.
Status of Claims
Claims 1–17 are pending in the application. Claims 1, 2, 4, 5, 6, 8, 10, 11, 12, 13, 17 are rejected.
Claims 1, 4-17 are rejected (OTDP).
Claim 3 is objected to.
Allowable Subject Matter
Claim 3 is objected to as being dependent upon a rejected base claim(s), but would be allowable if rewritten in independent form including all of the limitations of the base claim(s) and any intervening claim(s).
It is noted that claims 7, 9, 15, 16 have no prior art rejection however they are rejected under double patenting (as mentioned below).
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees.
A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Here is the general claim correspondence between the inventions:
Instant Invention Claim(s)
1
4
5
6
7
8
9
10
11
12
13
14
15
16
17
US 12,020,367B2 Claim(s)
1
6 (also 1)
1
1
4
2
3
11
12
13
18
19
19
19
14
Claims 1, 5, and 6 of the instant application (18/668,599) are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 1 of U.S. Patent No. 12,020,367B2. Although the conflicting claims are not identical, they are not patentably distinct because they recite the same core ray-tracing-acceleration functionality.
Instant claim 1 generally follows ’367 claim 1. Both recite a ray-tracing acceleration hardware device including circuitry to traverse an acceleration (data) structure with a ray, transform the ray from a first world space to a second world space and then to object space during traversal, update state based on the ray after transforms, and test the ray in object space for intersection with bounding volumes. Any differences in phrasing (e.g., “state storage configured to store a traversal state” vs. “internal state”) are not patentably distinct because ’367 claim 1 expressly requires initializing and updating an internal state during traversal, which necessarily implies maintaining that state in storage.
Instant claim 5 is not patentably distinct from ’367 claim 1 because both require intersection testing of the (further) transformed ray in object space against bounding volumes defined by the acceleration (data) structure.
Instant claim 6 is not patentably distinct from ’367 claim 1 because both require initializing state based on information received from a processor for the ray (in first world space) and the acceleration (data) structure.
Claim 4 of the instant application (18/668,599) is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 6 and 1 of U.S. Patent No. 12,020,367B2. Although the conflicting claims are not identical, they are not patentably distinct.
Instant claim 4 is not patentably distinct from ’367 claims 6 and 1. ’367 claim 6 expressly recites that transforming the ray from the first world space to the second world space is in accordance with information stored in the acceleration data structure, which corresponds directly to instant claim 4’s requirement that the transform is performed in accordance with information stored in the acceleration structure. In addition, ’367 claim 1 recites transform circuitry that performs the world-space transforms responsive to a type of node from the acceleration data structure during traversal, which likewise relies on information from the acceleration data structure to control the transform. Accordingly, instant claim 4 is an obvious variation of ’367 claims 6 and 1 and is not patentably distinct.
Over ’367 claim 4
Claim 7 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 4 of U.S. Patent No. 12,020,367B2. Both claims recite receiving a ray and acceleration-structure information from a processor, where the acceleration (data) structure comprises hierarchically arranged nodes defining bounding volumes for scene objects, with the first world space being an application-defined coordinate space and the object space being the coordinate space for the objects. Any minor wording differences are not patentably distinct.
Over ’367 claim 2
Claim 8 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 2 of U.S. Patent No. 12,020,367B2. Both claims recite that the ray-tracing acceleration hardware device is a coprocessor to a processor and operates on a ray received from that processor. The instant claim is an obvious variation of the same coprocessor relationship.
Over ’367 claim 3
Claim 9 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 3 of U.S. Patent No. 12,020,367B2. Both claims recite maintaining distinct top-level and bottom-level traversal/ray states for world-space vs object-space traversal and storing information about transformed rays in those states. Differences in terminology (“top level traversal state” / “bottom level traversal state” vs “internal state” subdivisions) are not patentably distinct.
Over ’367 claim 11
Claim 10 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 11 of U.S. Patent No. 12,020,367B2. Both claims recite that, upon reaching an instance-node type during traversal, the hardware sends information to the processor about a state of continued traversing. Any differences in the exact phrasing of the returned information are not patentably distinct.
Over ’367 claim 12
Claim 11 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 12 of U.S. Patent No. 12,020,367B2. Both claims recite that circuitry is part of a server/data center employed in generating an image and that the image is streamed to a user device. The claims are not patentably distinct.
Over ’367 claim 13
Claim 12 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 13 of U.S. Patent No. 12,020,367B2. Both claims recite generating an image and using the image for training/testing/certifying a neural network employed in a machine/robot/autonomous vehicle. The claims are not patentably distinct.
Over ’367 claim 18
Claim 13 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 18 of U.S. Patent No. 12,020,367B2. Both claims recite a system including a processor, PPU, memory, and traversal coprocessor performing the same traversal/transform/state-update and intersection testing functionality. The system framing of the instant claim is not a patentable distinction over the corresponding system claim of the patent.
Over ’367 claim 19
Claims 14, 15, and 16 of the instant application are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 19 of U.S. Patent No. 12,020,367B2. The claims recite the same integrated system limitations regarding: (i) memory storing the acceleration data structure with axis-aligned bounding volumes and leaf nodes corresponding to surfaces; (ii) per-frame selection of an alternate world space and rebuilding the acceleration data structure with a top-level transform; and (iii) PPU detection/communication of transform information to a traversal coprocessor, receipt of intersection information, and rendering based on the received intersection information. Any minor differences in wording do not render the instant claims patentably distinct.
Over ’367 claim 14
Claim 17 of the instant application is rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claim 14 of U.S. Patent No. 12,020,367B2. Both claims recite the same method-level functionality: initializing state based on information for a ray in first world space and an acceleration (data) structure; transforming the ray first→second world space and then to object space responsive to node types during traversal; updating state based on the transformed ray; and testing in object space for intersection with bounding volumes. The instant method claim is not patentably distinct.
Overview of Grounds of Rejection
Ground of Rejection
Claim(s)
Statute(s)
Reference(s)
Ground of Rejection 1
1, 2, 4, 5, 6, 8, 10, 12, 13, 14 17
§ 103
Babich et al. (US20200050451A1); Laine et al. (US20160070820A1); Laine et al. (US20170116760A1)
Ground of Rejection 2
11
§ 103
Babich et al. (US20200050451A1); Laine et al. (US20160070820A1); Laine et al. (US20170116760A1); Yao et al. (WO2019183664A1)
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 of this title, 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.
(Please see the cited paragraphs, sections, pages, or surrounding text in the references for the paraphrased content.)
Ground of Rejection 1
Claims 1, 2, 4, 5, 6, 8, 10, 12, 13, 14, 17 are rejected under 35 U.S.C. § 103 as being unpatentable over Babich et al. (US20200050451A1) in view of Laine et al. (US20160070820A1) and further in view of Laine et al. (US20170116760A1).
As per Claim 1, Babich teaches the following portion of Claim 1, which recites:
“A ray tracing acceleration hardware device configured to be connected to a processor, the ray tracing acceleration hardware device comprising:”
Babich et al. teaches: “the SM 1840 may be coupled to … one or more TTUs 700” and “the TTU 700 may be a coprocessor to the SM 1840 … and returns results into the SM register file.” — Babich et al. (US20200050451A1), ¶[0308], ¶[0309].
A TTU coupled to, and operating as a coprocessor to, an SM (processor) meets the claimed ray tracing acceleration hardware device connected to a processor.
Babich alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Laine et al. (US20160070820A1), they collectively teach some of the limitation(s).
Laine et al. (US20160070820A1) teach the following portion of Claim 1, which recites: “at least one state storage configured to store a traversal state of an acceleration structure and a ray;”
Laine et al. (US20160070820A1) teaches: “the interface 505 may load a ray data structure into the local storage 502 and initialize a traversal stack data structure in the local storage 504.” — Laine et al. (US20160070820A1), ¶[0088].
The “ray data structure” corresponds to storing “a ray,” and the “traversal stack data structure” corresponds to storing traversal state for traversing the acceleration structure.
Babich teaches the following portion of Claim 1, which recites:
“circuitry configured to, using the ray, traverse a traversal path in the acceleration structure from a root node in a first world space to a leaf node in an object space …”
Babich et al. teach traversal from root to leaf and distinguishes world space and object space traversal:
“The largest volumetric bounding volume may be termed a ‘root node.’ The smallest subdivisions … (‘leaf nodes’) …” — Babich et al. (US20200050451A1), ¶[0059].
“the top level traversal (in world space) … the bottom level traversal … (in object space) …” —
Babich et al. (US20200050451A1), ¶[0143].
Babich describes BVH traversal from a “root node” to “leaf nodes,” with traversal occurring in “world space” and “object space,” using the ray.
Babich and Laine et al. (US20160070820A1) alone do not explicitly teach all the limitation(s) of the claim. However, when combined with Laine et al. (US20170116760A1), they collectively teach all of the limitation(s).
Babich and Laine et al. (US20170116760A1) teach the following portion of Claim 1, which recites:
“…and during the traversing, update the stored traversal state upon transforming the ray from a first world space to a second world space and from the second world space to the object space.”
(i) First world space → second world space → object space (nested coordinate systems during traversal)
Laine et al. (US20170116760A1) teaches nested coordinate systems in a traversal context, including a ray query:
“the query data structure comprises a ray data structure that represents a ray …” and “a first node … first local coordinate system … a second node … second local coordinate system … both specified relative to a global coordinate system.” — Laine et al. (US20170116760A1), ¶[0034], ¶[0035].
“A first node … first local coordinate system and a second node … second local coordinate system … both specified relative to a global coordinate system.” — Laine et al. (US20170116760A1), ¶[0006].
Laine (US20170116760A1) describes traversal processing of nodes using a ray, where traversal encounters nodes associated with a “first local coordinate system” and then a “second local coordinate system,” both tied to a “global coordinate system.” This corresponds to sequential coordinate-space transitions consistent with “first world space → second world space → object space” during traversal. While Babich explicitly mentions "Object Space", Laine (US20170116760A1) uses the term "Local Coordinate System."
(ii) Update stored traversal state during traversal steps
Babich et al. teaches updating traversal state as traversal proceeds: “To update the traversal state to set up the ray’s next traversal step …” and “returns the ray … to the SM with traversal state modified …” — Babich et al. (US20200050451A1), ¶[0151].
Babich describes hardware operation that updates traversal state to set up the next traversal step and returns the ray with traversal state modified, which corresponds to the claimed updating of stored traversal state during traversal as the ray proceeds through coordinate-space changes taught by Laine (US20170116760A1).
Before the effective filing date of the claimed invention, a person of ordinary skill in the art (POSITA) would have been motivated to incorporate Laine et al. (US20170116760A1)’s nested coordinate-system handling for BVH traversal into Babich et al.’s TTU-based ray traversal pipeline, and to use Laine et al. (US20160070820A1)’s local-storage ray plus traversal-stack organization, because the combination would predictably improve traversal robustness and efficiency. In particular, Laine (US20170116760A1) addresses traversal of nodes associated with multiple local coordinate systems relative to a global coordinate system, which supports hierarchical scenes and compressed representations, while Babich provides a dedicated traversal coprocessor architecture that updates traversal state across traversal steps. Integrating these known techniques would have predictably produced correct ray traversal results while improving manageability of traversal state and supporting intermediate coordinate spaces without changing the fundamental BVH traversal function.
Also, Claim 1 recites, in substance, ray-tracing traversal circuitry with state storage to store a traversal state. Claim 1 of the parent patent describes transform/traversal circuitry that updates an internal state during traversal. A POSITA would have understood that updating internal state during traversal necessarily relies on some form of storage for that state, and providing an explicit state storage for traversal state (as recited in the instant claim) would have been an obvious implementation detail of the parent’s internal-state updating traversal circuitry. Therefore, claim 1 is an obvious variation of claim 1 of the parent.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 2, Babich teaches the limitation(s) of Claim 2 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the update the stored traversal state upon transforming the ray from the first world space to a second world space is performed in response to a first transform node in the traversal path, and the update the stored traversal state upon transforming the ray from the second world space to the object space in response to a second transform node in the traversal path.”
Limitation: “The ray tracing acceleration hardware device according to claim 1, wherein the update the stored traversal state upon transforming the ray from the first world space to a second world space is performed in response to a first transform node in the traversal path …”
Babich et al. teaches node-triggered instance transforms (an instance node is a transform-type node) and the ray being transformed into an instance BVH coordinate system:
“An instance node. … The TTU 700 … can handle one level of instancing natively by transforming the ray into the coordinate system of the instance BVH …” — Babich et al. (US20200050451A1), ¶[0331].
“To update the traversal state to set up the ray’s next traversal step …” — Babich et al. (US20200050451A1), ¶[0151].
Babich describes an instance node and the TTU transforming the ray into the coordinate system of the instance BVH (a “second world space”), with traversal logic that updates traversal state for the next traversal step.
Limitation: “… and the update the stored traversal state upon transforming the ray from the second world space to the object space in response to a second transform node in the traversal path.”
Babich et al. teaches that when the traversal encounters an instance-type node (transform-type node), the TTU transforms the ray into the coordinate system of the child BVH (object-side traversal space):
“When a child of the intersected bounding volume is an instance node … retrieve an appropriate transform matrix … [and] transforms the ray to the coordinate system of the child BVH.” — Babich et al. (US20200050451A1), ¶[0145].
Babich also links “instance nodes” to “transformation nodes”: “describes transformation nodes … in different coordinate systems. The instance nodes … may be similar …” — Babich et al. (US20200050451A1), ¶[0145].
Babich directly ties ray transformation to encountering an instance node in the traversal path, using a transform matrix to transform the ray into a different coordinate system (here, the child BVH). This reads cleanly on a “second transform node” that triggers the second transform step.
(multi-level / first-vs-second transform node): Babich recognizes “multiple levels of instancing” may exist (i.e., more than one transform node may be encountered along a path): “More complicated queries … involving … multiple levels of instancing may require multiple round trips.” — Babich et al. (US20200050451A1), ¶[0077]. And Babich further states: “In other implementations, the hardware can handle two, three or more levels of instancing.” — Babich et al. (US20200050451A1), ¶[0331].
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 4, Babich teaches the limitation(s) of Claim 4 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the transforming the ray from the first world space to the second world space is in accordance with information stored in the acceleration structure.”
Babich et al. (US20200050451A1) teaches that the acceleration structure (world-space BVH) stores the transform information used to transform the ray:
“the transform from world-to-object space is stored in the world space BVH along with a world-space bounding box.” — Babich et al. (US20200050451A1), ¶[0105].
“Objects ... can be represented ... as instance nodes which associate ... in the world space BVH with a transformation that can be applied to the world-space ray ...” — Babich et al. (US20200050451A1), ¶[0061].
“When ... an instance node, the ray transformation ... retrieve an appropriate transform matrix ... [and] transforms the ray to the coordinate system of the child BVH.” — Babich et al. (US20200050451A1), ¶[0145].
Babich describes that the BVH (acceleration structure) stores a transformation/transform matrix, and the traversal hardware uses that stored information to transform the ray into another coordinate system (a “second world space,” e.g., the child BVH or instance coordinate system).
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 5, Babich teaches the limitation(s) of Claim 5 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the circuitry is further configured to test the ray, in the object space, for intersection with bounding volumes defined by the acceleration structure.”
Babich et al. teaches testing a ray against BVH bounding volumes, and doing the tests in object space:
“The traversal co-processor performs a test of each ray against a wide range of bounding volumes, and can cull any bounding volumes that don't intersect with that ray.” — Babich et al. (US20200050451A1), ¶[0060].
“The traversal coprocessor 138 … transform[s] the ray from world (scene) space into object space for purposes of performing the tests … [and] … performs its tests in object space.” — Babich et al. (US20200050451A1), ¶[0105].
Babich describes an acceleration structure as a BVH of bounding volumes that are intersect-tested by the traversal coprocessor, and it states that the coprocessor transforms the ray into object space and performs its tests in object space, which reads directly on Claim 5.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 6, Babich alone does not explicitly teach all the limitation(s) of the claim. However, when combined with Laine et al. (US20160070820A1), they collectively teach all of the limitation(s).
Laine et al. (US20160070820A1) teach the following portion of Claim 6, which recites: “The ray tracing acceleration hardware device according to claim 1, wherein, before the update, the at least one state is initialized based on information received from the processor relating to the ray, defined in the first world space, and the acceleration structure.”
Laine et al. (US20160070820A1) teaches initialization of per-ray state (ray data + traversal stack) based on information received from the processor (SM) and the acceleration structure (BVH):
Information received from the processor and initialization before traversal-state updates: “In order to intersect a ray with the BVH, the SM 340 may transmit an instruction to the interface 505 of the TTU 500. In response to the instruction, the interface 505 may load a ray data structure into the local storage 502 and initialize a traversal stack data structure in the local storage 504. The interface 505 may also push a root node for the BVH onto the traversal stack data structure.” — Laine et al. (US20160070820A1), ¶[0088].
The processor-provided instructions/data identify the acceleration structure and query (ray): “The instructions may include operands such as pointers that direct the TTU 500 to a tree data structure and/or a query data structure …” — Laine et al. (US20160070820A1), ¶[0071].
The ray is defined relative to a global coordinate system (reads on “first world space”): “the ray data structure includes … values for specifying the coordinates of a point relative to a global coordinate system …” — Laine et al. (US20160070820A1), ¶[0089].
Claim 6 is taught by Laine et al. (US20160070820A1) via processor (SM)-provided ray and BVH information used to initialize ray/traversal state (ray data structure + traversal stack with BVH root) before subsequent traversal-state updating.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 8, Babich teaches the limitation(s) of Claim 8 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the ray tracing acceleration hardware device is a coprocessor to the processor.”
Babich et al. teaches the claimed coprocessor relationship:
“the TTU 700 may be a coprocessor to the SM 1840 …” — Babich et al. (US20200050451A1), ¶[0309].
Babich directly characterizes the ray-tracing traversal unit (TTU) as a coprocessor to the streaming multiprocessor (processor), which reads on Claim 8.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 10, Babich teaches the limitation(s) of Claim 10 which recites:
“The ray tracing acceleration hardware device according to claim 1, configured to, in response to reaching a node of an instance node type in the acceleration data structure during the traversing, send information about a state of a continued traversing to a processor.”
Babich et al. teaches returning instance-node information to the processor (SM) when an instance node is reached during traversal: “any intersected instance nodes would be returned to the SM.” — Babich et al. (US20200050451A1), ¶[0145].
Babich et al. also teaches that, to support continued traversal (including software-handled instancing), the hardware provides instance-node state information back to the processor via a dedicated hit-type: “The ‘InstanceNode’ hit type is provided for this purpose, consisting of a pointer to the instance node and the tvalue of the intersection with the leaf bounding box.” — Babich et al. (US20200050451A1), ¶[0331].
Further, Babich et al. describes sending continued-traversal state back for continuation by software, i.e., “relevant state should be written to registers by the TTU 700 and then passed back to the TTU in registers … to continue. This state may take the form of a traversal stack” — Babich et al. (US20200050451A1), ¶[0314].
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 12, Babich teaches the limitation(s) of Claim 12 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the circuitry is employed in generating an image, and the image is used for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle.”
“circuitry is employed in generating an image”: “ray tracing may be implemented … to produce images” — Babich et al. (US20200050451A1), ¶[0247].
Relatedly, ray tracing “directly simulates light traveling through a virtual environment or scene … allows for … computer-generated images” — Babich et al. (US20200050451A1), ¶[0074].
“the image is used for training, testing, or certifying a neural network”: “A deep neural network (DNN) … can be trained … [using an] input image …” — Babich et al. (US20200050451A1), ¶[0353].
“During training … [with] a training dataset …” — Babich et al. (US20200050451A1), ¶[0355].
“neural network employed in a machine, robot, or autonomous vehicle”: “PPU 1700 may be configured to accelerate … deep learning … including autonomous vehicle platforms … and … robotics …” — Babich et al. (US20200050451A1), ¶[0250].
Babich also ties ray tracing to simulation for “robot or vehicle localization,” supporting testing/validation use cases — Babich et al. (US20200050451A1), ¶[0153].
Babich teaches ray tracing that generates computer-generated images by simulating a virtual environment (image generation), and teaches using input images in a training dataset to train a DNN for autonomous vehicle and robotics applications, with ray tracing also used for simulation in robot/vehicle contexts.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
System Claim 13 does not include any additional limitations that would significantly distinguish it from claim 1. Therefore, it is likewise rejected under 35 U.S.C. § 103 in view of the same references and for the same reasons set forth above.
Also, Claim 13 recites a system-level arrangement (e.g., processor/memory with ray-tracing circuitry) that encompasses the same traversal/transform functionality and state handling as the parent’s claim 1. Any additional system packaging (processor/memory recitations) does not render the claim patentably distinct because it merely places the same traversal/transform state-updating circuitry in a conventional system context. Thus, claim 13 is an obvious variation of claim 1 of the parent.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
As per Claim 14, Babich teaches the limitation(s) of Claim 14 which recites:
“The system according to claim 13, wherein the memory is configured to store the acceleration structure of hierarchically-arranged nodes, the hierarchically-arranged nodes defining a plurality of bounding volumes bounding portions of a scene and being axis-aligned in a first coordinate space, and including a plurality of leaf nodes corresponding to surfaces in the scene, the surfaces being in respective object coordinate spaces.”
Babich et al. teaches the acceleration structure in memory as a hierarchy of axis-aligned bounding volumes with leaf nodes corresponding to triangle surfaces, and object-space models:
Memory stores an acceleration structure of hierarchically-arranged nodes: “The tree data structure may be stored in memory … The tree data structure includes a plurality of nodes arranged in a hierarchy.” — Babich et al. ¶[0109].
Hierarchically-arranged nodes define bounding volumes bounding portions of a scene and are axis-aligned in a first coordinate space: “The … acceleration data structure … is a bounding volume hierarchy (BVH) comprising nested axis-aligned bounding boxes …” — Babich et al., ¶[0065].
Also: “for each geometric primitive … [a] … axis-aligned bounding box …” — Babich et al., ¶[0083].
Plurality of leaf nodes corresponding to surfaces in the scene: “The leaf nodes of the BVH contain the primitives (e.g., triangles) to be tested for intersection.” — Babich et al. ¶[0065].
And: “The smallest bounding volumes are represented as leaf nodes … [and] identify … geometric primitives … different numbers of triangles.” — Babich et al. ¶[0108].
Surfaces being in respective object coordinate spaces: “Each of these three objects is defined by a respective model that exists in a respective object space.” — Babich et al. ¶[0106].
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Method Claim 17 does not include any additional limitations that would significantly distinguish it from claims 1 and 6. Therefore, it is likewise rejected under 35 U.S.C. § 103 in view of the same references and for the same reasons set forth above.
Also, Claim 17 likewise recites subject matter directed to the same traversal/transform operation and maintenance/updating of traversal/internal state. To the extent claim 17 varies in form (e.g., additional structural or functional recitations), such variations would have been obvious refinements of the parent’s state-updating traversal circuitry and do not confer patentable distinctness. Thus, claim 17 is an obvious variation of claim 1 of the parent.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Ground of Rejection 2
Claim 11 is rejected under 35 U.S.C. § 103 as being unpatentable over Babich et al. (US20200050451A1) in view of Laine et al. (US20160070820A1), further in view of Laine et al. (US20170116760A1), and still further in view of Yao et al. (WO2019183664A1).
Babich alone do not explicitly teach all the limitation(s) of the claim. However, when combined with Yao et al. (WO2019183664A1), they collectively teach all of the limitation(s).
Babich and Yao teach the limitation(s) of Claim 11 which recites:
“The ray tracing acceleration hardware device according to claim 1, wherein the circuitry is part of a server or a data center employed in generating an image, and the image is streamed to a user device.”
Limitation: “the circuitry is part of a server or a data center employed in generating an image”
Babich et al. (US20200050451A1) teaches a ray-tracing/GPU system for generating images and states the system may be a cloud-based computing system: “FIG. 1 … real time … graphics system … for generating images … [and] can take on … a … cloud-based computing system …” — Babich et al. (US20200050451A1), ¶[0067]-¶[0068].
Babich further teaches data center use and inclusion in servers: “PPU … accelerate … data center … applications” and “PPU … may be included in … servers …” — Babich et al. (US20200050451A1), ¶[0250]-¶[0251].
Limitation: “the image is streamed to a user device” Yao et al. (WO2019183664A1) teaches server-side rendering and streaming to a user device: “generating a scene data render on the server … streaming the scene data render … from the server to the user device … to display the data as it was created on the server …” — Yao et al. (WO2019183664A1), ¶[0009].
Yao also states the server processor is configured to “generate a scene data render … and transmit [it] … to the user device over the network to display the data as it was created on the server.” — Yao et al. (WO2019183664A1), ¶[0017].
Before the effective filing date of the claimed invention, a person of ordinary skill in the art would have been motivated to combine Babich et al.’s ray tracing acceleration circuitry used for image generation in cloud/server or data center deployments with Yao et al.’s server-side rendering and streaming to a user device, because streaming server-generated images provides predictable benefits such as enabling thin clients, reducing client-side computation and power use, centralizing GPU resources in servers/data centers, and improving scalability and manageability of graphics workloads, while yielding the expected result of the same rendered imagery being delivered for display on the user device.
PNG
media_image1.png
13
460
media_image1.png
Greyscale
Conclusion
The prior art made of record and relied upon in this action is as follows:
Patent Literature:
Babich et al. (US20200050451A1) — “Robust, efficient multiprocessor-coprocessor interface”
Laine et al. (US20160070820A1) — “Short stack traversal of tree data structures”
Laine et al. (US20170116760A1) — “Relative encoding for a block-based bounding volume hierarchy”
Yao et al. (WO2019183664A1) — “Method to transmit interactive graphical data between a device and server and system thereof”
Non-Patent Literature (NPL):
(none)
Note: A PDF copy of each NPL reference is attached with this Office Action. URLs are included for applicant convenience. If a link becomes unavailable in the future, the citation information may be used to locate the reference or access archived versions via the Wayback Machine.
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure and is listed as follows:
Patent Literature:
(none)
Non-Patent Literature (NPL):
(none)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ADEEL BASHIR whose telephone number is (571) 270-0440. The examiner can normally be reached Monday-Thursday.
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, Daniel Hajnik can be reached on (571) 276-7642. 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.
/ADEEL BASHIR/
Examiner, Art Unit 2616
/DANIEL F HAJNIK/Supervisory Patent Examiner, Art Unit 2616