DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The Amendment filed April 6th, 2026 has been entered. Claims 1-9 and 11-20 are pending in the application. Applicant’s amendments to the Claims 1 and 15 have overcome the rejections previously set forth in the Final Office Action mailed February 4th 2026. Further search has been performed to address the material amended in the aforementioned claims. Newly added reference Gambetta (NPL: Clipping) was used for the amended claim limitations.
Response to Arguments
Applicant’s arguments with respect to claims 1 and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Claim Objections
Claims 1, 2, and 15 objected to because of the following informalities: Claims 1, 2, and 15 recite: “before the rendering the section view of the 3D mesh …”. The claims should be amended to read “before the rendering of the section view of the 3D mesh” or similar. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(d):
(d) REFERENCE IN DEPENDENT FORMS.—Subject to subsection (e), a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
The following is a quotation of pre-AIA 35 U.S.C. 112, fourth paragraph:
Subject to the following paragraph [i.e., the fifth paragraph of pre-AIA 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 2 rejected under 35 U.S.C. 112(d) or pre-AIA 35 U.S.C. 112, 4th paragraph, as being of improper dependent form for failing to further limit the subject matter of the claim upon which it depends, or for failing to include all the limitations of the claim upon which it depends.
In the previous amendment, the Applicant amended the contents of dependent claim 2 into independent claim 1. However, this results in claim 2 no longer further limiting the scope of claim 1 because the limitations in claim 2 are duplicated in claim 1. Applicant may cancel the claim, amend the claim to place the claim in proper dependent form, rewrite the claim in independent form, or present a sufficient showing that the dependent claim complies with the statutory requirements.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, 3, 8, 9, 11, 12, 13, 14, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Paulovich (US 20180322690 A1; from applicant’s IDS) in view of Wittenbrink (US 7292242 B1; see attached document for paragraph numbers) and Gambetta (NPL: Clipping).
Regarding claim 1:
Paulovich teaches:
A computer-implemented method for rendering, by a Graphical Processing Unit (GPU) (Paulovich: Graphics processor 215, for example, may represent a graphics processing unit (GPU) [0018]), a section view of a 3D mesh in a single pass (Paulovich: without transfer via the system bus [0053]), the method comprising:
obtaining the 3D mesh, the 3D mesh having convex polygons (Paulovich: method 300 includes receiving, at a graphics processing unit, object data representing a model of a three-dimensional object, the object data including a plurality of interrelated polygons [0037]);
obtaining a clipping plane (Paulovich: method 300 includes receiving, at the graphics processing unit, coordinates for one or more clipping boundaries [0039]), the clipping plane representing a 2D surface (Paulovich: Clipping boundaries 620 (front), 621 (left side), 622 (right side) and 623 (rear) are depicted as planes extending upward from each edge of table 610 [0075]; see Note 1K); and
rendering the section view of the 3D mesh by:
rendering the convex polygons of the 3D mesh (Paulovich: Object data to be rendered for presentation on a display screen may enter the graphics pipeline as a set of polygons that are interrelated to each other [0036]; Each polygon may be a triangle and thus include three vertices [0021]; see Note 1A), the rendering of the convex polygons of the 3D mesh comprising, for each convex polygon:
determining, by a geometry shader, if the convex polygon intersects the clipping plane (Paulovich: method 300 includes, using a geometry shader, performing per-polygon clipping on each polygon that intersects with at least one clipping boundary [0043]; see Note 1B);
if the convex polygon intersects the clipping plane, computing a pair of points on edges of the convex polygon intersected by the clipping plane (Paulovich: new vertices 435, 436, 440, 441, 442, 450, 455, 456, and 470 may be designated edge vertices by nature of their intersection with clipping boundaries 402 and 404 [0063]; see Note 1C); and
storing the pair of points in a GPU-writable buffer (see Note 1D) wherein the computing and storing of the pair of points on edges of the convex polygon intersected by the clipping plane being performed, (Paulovich: method 300 includes, using a geometry shader, performing per-polygon clipping on each polygon that intersects with at least one clipping boundary [0043]; Paulovich: Geometry shader (GS) 245 may generate new graphics primitives, such as points, lines, and triangles, from those primitives that were sent to the beginning of the graphics pipeline [0029]) in a single parallel computation, by the geometry shader thereby reducing calls to a CPU while performing the rendering (see Note 1G and Note 1H); and
rendering the stored pairs of points in the GPU-writable buffer as a set of lines (Paulovich: Triangles that incorporate one or more edge vertices and/or one or more edge lines may be designated edge triangles […] These primitives, when converted into pixels by the rasterizer, may be rendered using one or more edge effects at the pixel shader [0063]), the rendering of the section view thereby comprising the rendered convex polygons and the rendered set of lines (Paulovich: Fig. 6; see Note 1E).
wherein the method further comprises before the rendering the section view of the 3D mesh, obtaining a viewing direction (Paulovich: view frustum [0032]; see Note 2A), and wherein
the rendering of the section view further comprises rendering convex polygons (Paulovich: During rasterization, each primitive is converted into pixels, while interpolating per-vertex values across each primitive [0032]) positioned along the viewing direction associated to the clipping plane and excluding the rendering of convex polygons not positioned along the viewing direction (Paulovich: Rasterization may include clipping vertices to a view frustum, […] and/or determining how to invoke pixel shader 255 [0032]; Paulovich: A pixel shader may render for display only portions of the object that lie within the clipping boundaries [0014]; see Note 2B).
Note 1A: Triangles are known in the art to be convex polygons: All the interior angles of a convex polygon are less than 180 degrees.
Note 1B: Performing per-polygon clipping based on whether each polygon intersects with at least one clipping boundary requires determining if each polygon intersects with said clipping boundary.
Note 1C: Paulovich teaches that new vertices may be defined due to intersection with the clipping plane as cited above in [0063]. Furthermore, Figure 4B of Paulovich showcases that the points can be grouped into pairs based on the edges formed by the newly generated vertices, For instance, vertices 450 and 440 form edge 251, vertices 440 and 441 form edge 443, etc.
Note 1D: Paulovich teaches that object modification may be performed on the GPU: “The geometry shader has access to same object data and constructs as does the CPU, but can render this data without transfer via the system bus. By performing object truncation on the GPU, parallelization is enabled, and bus transfer time is reduced,” [0053]. Paulovich further teaches memory writable by the graphics processor used for modification of meshes: “Graphics processor 215 and graphics memory 220 may be configured to allow changing and/or modification of the appearance of meshes,” [0021]. Therefore, one of ordinary skill in the art would be motivated to store the pair of points in a GPU-writable buffer.
Note 1E: Paulovich showcases in Fig. 6 a clipped 3D mesh where the clipped region (the region filled by diagonal lines) is delineated by an edge. Note that while the line is drawn as a continuous edge, the mesh is formed by triangles as showcased in Fig. 4A and Fig. 4B, and therefore the edge must be composed of a set of individual smaller lines.
The view showcased in Fig. 6 also comprises the 3D mesh, which is composed of a set of triangles (or ‘convex polygons’ as discussed above in Note 1A).
Note 1F: Paulovich teaches that the geometry shader designates primitives that coincide with the clipping boundaries as an edge primitive in [0048] as cited above.
Note 1G: One of ordinary skill in the art would understand that parallel processing is a type of computation in which many calculations or processes are carried out simultaneously. The specification of the present application defines a “single pass” as: “more than one of the steps of the method are performed in the GPU, substantially at the same time” (Pg. 8, ln. 25-26). For this reason, one of ordinary skill in the art would understand that when the GPU is parallelized as taught by Paulovich, the operations are being done in a “single pass”, or a “single parallel computation”.
Note 1H: Paulovich teaches that object truncation may be performed on the GPU instead of the CPU, which would necessarily reduce calls to the CPU: “By performing object truncation on the GPU, parallelization is enabled, and bus transfer time is reduced. For example, while the GPU can run this process at 60 fps, the CPU would be reduced to 15-20 fps, which would make an immersive holographic experience challenging for the user to enjoy.” [0053].
Note 1I: Paulovich teaches in the example depicted in Fig. 6 that each clipping boundary is a 2D plane that extends from the edge of the table. One of ordinary skill in the art would reasonably consider each clipping boundary to represent a 2D surface.
Note 2A: Paulovich teaches: “Rasterization may include clipping vertices to a view frustum, […] During rasterization, each primitive is converted into pixels, while interpolating per-vertex values across each primitive. Rasterization clipping may include clipping the edges of one polygon that lies outside of another polygon,” [0032]. That is, clipping of geometry may be relative to a view frustum, wherein the view frustum inherently comprises a viewing direction. Therefore, in order to render or “rasterize” the section view of the 3D mesh, the viewing direction associated with the clipping plane must be obtained prior to rendering.
Note 2B: As cited in [0032] in Note 2A, Paulovich teaches “clipping vertices to a view frustum”. One of ordinary skill in the art would recognize that Paulovich is teaching a method similar to frustum culling, where geometry outside of a view frustum is excluded from rendering. As shown in note 2A, the view frustum comprises a viewing direction, and therefore, one of ordinary skill in the art would be motivated to render convex polygons positioned along the viewing direction and exclude the rendering of convex polygons not positioned along the viewing direction.
Paulovich fails to explicitly teach:
obtaining a clipping plane, the clipping plane representing a 2D surface; and
before the rendering the section view of the 3D mesh, obtaining a viewing direction associated to the clipping plane, and wherein
the rendering of the section view further comprises rendering convex polygons positioned along the viewing direction associated to the clipping plane and excluding the rendering of convex polygons not positioned along the viewing direction, and
wherein the determining if the convex polygon intersects the clipping plane further includes:
determining if only one of vertices of the convex polygon is lying on the 2D surface represented by the clipping plane, and if only one of the vertices of the convex polygon is lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction,
determining if only two of the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if only two of the vertices of the convex polygon are lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction, and
determining if all the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if all the vertices of the convex polygon are lying on said 2D surface, rendering the convex polygon, the method thereby excluding the rendering of polygons that lie on the clipping plane but deform the surface of the section view.
Wittenbrink teaches:
before the rendering the section view of the 3D mesh (Wittenbrink: In some embodiments, VPC block 304 culls various primitives that are not visible, (38); see Note 2C), obtaining a viewing direction associated to the clipping plane (Wittenbrink: Embodiment of the present invention may clip to any number of planes, including all planes of a view frustum or other view volume, (112); see Note 2D), and wherein
the rendering of the section view further comprises rendering convex polygons positioned along the viewing direction associated to the clipping plane (Wittenbrink: the clipping plane, which can be defined by an arbitrary plane equation in the clip coordinate space, has a visible side and an invisible side (95); Wittenbrink: Embodiment of the present invention may clip to any number of planes, including all planes of a view frustum or other view volume, (112); see Note 2D) and excluding the rendering of convex polygons not positioned along the viewing direction (Wittenbrink: VPC block 304 culls various primitives that are not visible. For example, primitives that are entirely outside the viewable volume […] may be culled, (38)).
Note 2C: Wittenbrink showcases in Fig. 3 “a block diagram of a 3D rendering pipeline 300 according to an embodiment,” (32). The block diagram showcases a VPC block 304 prior to the last step of sending pixel colors to the pixel buffer (under step 312). Sending pixel colors to the pixel buffer is analogous to rendering, and therefore, Wittenbrink teaches obtaining a viewing direction for clipping prior to rendering the 3D mesh.
Note 2D: Wittenbrink states that the view frustum may be analogous to the clipping plane in (112) as cited above. In Note 2A, it was shown that the view frustum comprises a viewing direction. Therefore, Wittenbrink teaches obtaining a viewing direction associated to the clipping plane.
Wittenbrink teaches that: “it is not critical whether the plane exactly matches a boundary of the view volume, and the clipping plane may be defined such that some of the geometry on the visible side is actually outside the view volume.” (95). However, it is noted that one of ordinary skill in the art would recognize that there should be at minimum some association between the visible side of the clipping plane and the view volume, as it would be detrimental to the rendering system to only view the invisible side of the clipping plane and therefore be unable to render any content.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Wittenbrink with Paulovich. Obtaining a viewing direction associated to the clipping plane, as in Wittenbrink, would benefit the Paulovich teachings by ensuring that the correct side of the geometry is culled so as to not disorient or confuse a viewer.
Paulovich in view of Wittenbrink fails to teach:
wherein the determining if the convex polygon intersects the clipping plane further includes:
determining if only one of vertices of the convex polygon is lying on the 2D surface represented by the clipping plane, and if only one of the vertices of the convex polygon is lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction,
determining if only two of the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if only two of the vertices of the convex polygon are lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction, and
determining if all the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if all the vertices of the convex polygon are lying on said 2D surface, rendering the convex polygon, the method thereby excluding the rendering of polygons that lie on the clipping plane but deform the surface of the section view.
Gambetta teaches:
wherein the determining if the convex polygon intersects the clipping plane further includes:
determining if only one of vertices of the convex polygon is lying on the 2D surface represented by the clipping plane, and if only one of the vertices of the convex polygon is lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction (Gambetta: One vertex in front. Let A be the vertex of the that is in front of the plane. In this case, are the intersections of ABC and AB AC is discarded, and a new triangle AB′C′ is added, Pg. 6, Clipping Triangles; see also Note 1J),
determining if only two of the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if only two of the vertices of the convex polygon are lying on said 2D surface, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction (Gambetta: Two vertices in front. Let A and B be the vertices of the triangle ABC that are in front of the plane. In this case, ABC is discarded and two new triangles are added, Pg. 7; see also Note 1J), and
determining if all the vertices of the convex polygon are lying on the 2D surface represented by the clipping plane, and if all the vertices of the convex polygon are lying on said 2D surface, rendering the convex polygon (Gambetta: Three vertices in front. In this case the whole triangle is in front of the clipping plane, so it’s accepted and no further clipping against this plane is needed, Pg. 6, par. Clipping Triangles; see also Note 1J),
the method thereby excluding the rendering of polygons that lie on the clipping plane but deform the surface of the section view (see Note 1K).
Note 1J: The specification teaches a viewing direction is “a direction from a side of the clipping plane. In other words, the viewing direction denotes a side of the clipping plane maintain geometry that is meant to be displayed to the user” (Pg. 12, ln. 2-4). Gambetta teaches that “we’ll choose not to render anything behind the projection plane Z=d. This clipping plane lets us classify any point as being inside or outside of the clipping volume—that is, the subset of space that is actually visible from the camera. In this case, the clipping volume is “whatever is in front of Z=d.” We’ll only render the parts of the scene that are inside the clipping volume.” (Pg. 1, An Overview of the Clipping Process, par. 2). In other words, a PHOSITA would understand that Gambetta teaches that points in front of the clipping volume are “positioned along the viewing direction”.
Gambetta teaches that: “If the distance is zero or positive, the vertex is in front of the clipping plane; otherwise, it’s behind.” (emphasis added, Pg. 6, Clipping Triangles, par. 1) In other words, a PHOSITA would understand the following from the teachings of Gambetta:
a vertex is considered positioned along the viewing direction if it is lying on the 2D surface (i.e., the distance to the 2D surface is zero) represented by the clipping plane.
a disclosure by Gambetta of a vertex being “in front” includes vertices lying on the 2D surface represented by the clipping plane.
vertices that are not in front of the clipping plane are behind.
It follows that for the cases when Gambetta teaches excluding the triangle ABC based on one or two vertices being in front of the 2D surface representing the clipping plane, Gambetta teaches by extension “excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction”.
Note 1K: “In Hoffer v. Microsoft Corp., 405 F.3d 1326, 1329, 74 USPQ2d 1481, 1483 (Fed. Cir. 2005), the court held that when a “‘whereby’ clause states a condition that is material to patentability, it cannot be ignored in order to change the substance of the invention.” Id. However, the court noted that a “‘whereby clause in a method claim is not given weight when it simply expresses the intended result of a process step positively recited.’” Id. (quoting Minton v. Nat’l Ass’n of Securities Dealers, Inc., 336 F.3d 1373, 1381, 67 USPQ2d 1614, 1620 (Fed. Cir. 2003)).” (see MPEP 2111.04)
The thereby clause appears to state a result of the previous method steps, because the corresponding matter in the specification teaches that “The method thus improves the quality of the rendering of the section view, as it excludes rendering "corners", that is, polygons that lie on the clipping plane but deform the surface of the section view” (Pg. 13, ln. 15-18). The Examiner interprets “corners” to refer to the “corner cases” referred to on Pg. 18 of the specification: “The method also determines, for the input triangle, the following corner cases: […]” (Pg. 18, ln. 6-23). Omitted by the ellipsis are the same cases described in the claims.
Furthermore, the polygons omitted by the clipping process described by Gambetta would deform the section view of Paulovich if rendered because the would-be excluded polygons contain points behind the clipping plane, when the section view would otherwise be aligned with the clipping plane. It follows that when the teachings of Gambetta are combined with the teachings of Paulovich and Wittenbrink, it would be obvious to exclude the rendering of polygons that lie on the clipping plane but deform the surface of the section view.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Gambetta with Paulovich in view of Wittenbrink. Determining the intersection of a triangle with the clipping plane, as in Gambetta, would benefit the Paulovich in view of Wittenbrink teachings by ensuring that triangles are properly intersected with the clipping plane: “If the sphere–plane test isn’t enough to determine whether an object is fully in front or fully behind the clipping plane, we have to clip each triangle against it.” (Gambetta, Pg. 6, Clipping Triangles)
Regarding claim 2:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), further comprising:
before the rendering the section view of the 3D mesh, obtaining a viewing direction (Paulovich: view frustum [0032]; see Note 2A), and wherein
the rendering of the section view further comprises rendering convex polygons (Paulovich: During rasterization, each primitive is converted into pixels, while interpolating per-vertex values across each primitive [0032]) positioned along the viewing direction associated to the clipping plane and excluding the rendering of convex polygons not positioned along the viewing direction (Paulovich: Rasterization may include clipping vertices to a view frustum, […] and/or determining how to invoke pixel shader 255 [0032]; Paulovich: A pixel shader may render for display only portions of the object that lie within the clipping boundaries [0014]; see Note 2B).
Paulovich fails to explicitly teach:
before the rendering the section view of the 3D mesh, obtaining a viewing direction associated to the clipping plane, and wherein
the rendering of the section view further comprises rendering convex polygons positioned along the viewing direction associated to the clipping plane and excluding the rendering of convex polygons not positioned along the viewing direction.
Wittenbrink teaches:
before the rendering the section view of the 3D mesh (Wittenbrink: In some embodiments, VPC block 304 culls various primitives that are not visible, (38); see Note 2C), obtaining a viewing direction associated to the clipping plane (Wittenbrink: Embodiment of the present invention may clip to any number of planes, including all planes of a view frustum or other view volume, (112); see Note 2D), and wherein
the rendering of the section view further comprises rendering convex polygons positioned along the viewing direction associated to the clipping plane (Wittenbrink: the clipping plane, which can be defined by an arbitrary plane equation in the clip coordinate space, has a visible side and an invisible side (95); Wittenbrink: Embodiment of the present invention may clip to any number of planes, including all planes of a view frustum or other view volume, (112); see Note 2D) and excluding the rendering of convex polygons not positioned along the viewing direction (Wittenbrink: VPC block 304 culls various primitives that are not visible. For example, primitives that are entirely outside the viewable volume […] may be culled, (38)).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Wittenbrink with Paulovich. Obtaining a viewing direction associated to the clipping plane, as in Wittenbrink, would benefit the Paulovich teachings by ensuring that the correct side of the geometry is culled so as to not disorient or confuse a viewer.
Regarding claim 3:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 2 (as shown above), wherein the determining if the convex polygon intersects the clipping plane further comprises:
determining if only one of the vertices of the convex polygon is lying on the clipping plane, and if only one of the vertices of the convex polygon is lying on the clipping plane the convex polygon intersects the clipping plane, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction (Gambetta: One vertex in front. Let A be the vertex of the that is in front of the plane. In this case, are the intersections of ABC and AB AC is discarded, and a new triangle AB′C′ is added, Pg. 6, Clipping Triangles; see also Note 1J); and/or
determining if only two of the vertices of the convex polygon are lying on the clipping plane, and if only two of the vertices of the convex polygon are lying on the clipping plane, excluding the rendering of the convex polygon if the remaining vertices are not positioned along the viewing direction (Gambetta: Two vertices in front. Let A and B be the vertices of the triangle ABC that are in front of the plane. In this case, ABC is discarded and two new triangles are added, Pg. 7; see also Note 1J); and/or
determining if all the vertices of the convex polygon are lying on the clipping plane; and if all the vertices of the convex polygon are lying on the clipping plane, rendering the convex polygon (Gambetta: Three vertices in front. In this case the whole triangle is in front of the clipping plane, so it’s accepted and no further clipping against this plane is needed, Pg. 6, par. Clipping Triangles; see also Note 1J).
Regarding claim 8:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), wherein the convex polygons of the 3D mesh comprise triangles (Paulovich: Each polygon may be a triangle and thus include three vertices [0021]; see Note 1A).
Regarding claim 9:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), wherein the obtaining the 3D mesh is performed by a vertex shader (Paulovich: Vertex shader 240 may retrieve additional data from graphics memory 220, such as data stored in one or more buffers 275, […] For example, each buffer 275 may include a collection of elements (e.g., raw data). A vertex buffer may contain per-vertex data. A simple vertex buffer may contain one type of data, such as position data. [0027]) and
the obtaining the clipping plane is performed by the vertex shader (Paulovich: receiving, at the graphics processing unit, coordinates for one or more clipping boundaries, [0094]; see Note 9A).
Note 9A: Paulovich teaches that the vertex shader may receive data from graphics memory such as position data: “Vertex shader 240 may retrieve additional data from graphics memory 220, such as data stored in one or more buffers 275, […] For example, each buffer 275 may include a collection of elements (e.g., raw data). […] A simple vertex buffer may contain one type of data, such as position data.” [0027]. Because the clipping boundaries are defined by coordinates, (Paulovich: receiving, at the graphics processing unit, coordinates for one or more clipping boundaries, [0094]), because the coordinates are analogous to position data, it would be obvious to one of ordinary skill in the art to utilize the vertex shader to also receive the clipping plane data.
Regarding claim 11:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), wherein the rendering the stored pairs of points in the GPU-writable buffer as a set of lines is performed by a rasterizer and a fragment shader (Paulovich: The rasterizer may then output object data representing a clipped model of the 3D object to a pixel shader [0049]; see Note 11A).
Note 11A: A pixel shader is known in the art to be analogous to a fragment shader.
Regarding claim 12:
Paulovich in view of Wittenbrink and Gambetta teaches:
A method of applying, with a shader pipeline, the rendering according to claim 1, comprising:
obtaining:
the shader pipeline having a vertex shader for obtaining the 3D mesh (Paulovich: Vertex shader 240 may retrieve additional data from graphics memory 220, such as data stored in one or more buffers 275, […] For example, each buffer 275 may include a collection of elements (e.g., raw data). A vertex buffer may contain per-vertex data. A simple vertex buffer may contain one type of data, such as position data. [0027]) and the clipping plane (Paulovich: receiving, at the graphics processing unit, coordinates for one or more clipping boundaries, [0094]; see Note 9A) and a geometry shader for performing determining if the convex polygon intersects the clipping plane (Paulovich: The intersection of each clipping boundary and the truncated object may define an object edge. As such, the geometry shader may designate each primitive (e.g., vertex, line, polygon) within the clipped model that coincides with one or more clipping boundaries as an edge primitive [0048]; see Note 10A), if the convex polygon intersects the clipping plane, computing the pair of points on edges of the convex polygon intersected by the clipping plane, and storing the pair of points in a GPU-writable buffer (Paulovich: method 300 includes, using a geometry shader, performing per-polygon clipping on each polygon that intersects with at least one clipping boundary [0043]; Paulovich: Geometry shader (GS) 245 may generate new graphics primitives, such as points, lines, and triangles, from those primitives that were sent to the beginning of the graphics pipeline [0029]); and
a rasterizer and a fragment shader for performing the rendering the stored pairs of points in the GPU-writable buffer (Paulovich: The rasterizer may then output object data representing a clipped model of the 3D object to a pixel shader [0049]) as the set of lines (Paulovich: The pixel shader may also render the object edges for display based on a predetermined edge treatment [0014]), the rendering of the section view thereby including the rendered convex polygons and the rendered set of lines (Paulovich: Triangles that incorporate one or more edge vertices and/or one or more edge lines may be designated edge triangles […] These primitives, when converted into pixels by the rasterizer, may be rendered using one or more edge effects at the pixel shader [0063]); and rendering the section view comprising the rendered convex polygons and the rendered set of lines (Paulovich: Fig. 6; see Note 1E).
Regarding claim 13:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 12, further comprising displaying the rendered section view of the 3D mesh (Paulovich: FIG. 6 shows an example mixed reality environment including a truncated three-dimensional object with a visual edge treatment. [0008]; Paulovich: When included, display subsystem 730 may be used to present a visual representation of data held by storage machine 720 [0091]).
Regarding claim 14:
Paulovich in view of Wittenbrink and Gambetta teaches:
A non-transitory computer readable medium having stored thereon a program that when executed by a computer causes the computer to implement the method (Paulovich: Storage machine 720 includes one or more physical devices configured to hold instructions executable by the logic machine to implement the methods and processes described herein [0085]) according to claim 1 (as shown above).
Regarding claim 15:
Claim 15 is substantially similar to claim 1, and is therefore rejected for similar reasons. Claim 15 contains the following notable differences:
Claim 15 claims a system instead of a method. Paulovich teaches a system: “In some embodiments, the methods and processes described herein may be tied to a computing system of one or more computing devices.” [0080]
Claims 4, 16, 17, and 18 are rejected under 35 U.S.C 103 as being unpatentable over Paulovich (US 20180322690 A1; from applicant’s IDS) in view of Wittenbrink (US 7292242 B1; see attached document for paragraph numbers), Gambetta (NPL: Clipping) and Gould (US 20190042410 A1).
Regarding claim 4:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above),
Paulovich in view of Wittenbrink and Gambetta fails to teach:
wherein the GPU-writable buffer is pre-allocated.
Gould teaches:
wherein the GPU-writable buffer is pre-allocated (Gould: memory page addresses are ready for use in buffer structure 133 ahead of time, and buffer service 125 can quickly respond to data buffer needs of shader unit 121 in a dynamic fashion, [0038]; see Note 4A).
Note 4A: Gould teaches: “In FIG. 2, graphics processor 120 establishes (201) a pool of available memory pages for use in a growable data structure,” [0036], and that “The pool of available memory pages is typically tracked in an associated tracking data structure 132 using pointers to pages of memory prefetched or pre-allocated for later use,” [0036]. That is, the pages of memory may be pre-allocated.
Gould further teaches that the growable data structure may comprise buffers: “A growable data structure, such as buffer structure 133,” [0036]; and “memory page addresses are ready for use in buffer structure 133 ahead of time, and buffer service 125 can quickly respond to data buffer needs of shader unit 121 in a dynamic fashion,” [0038]. Therefore, buffers may be pre-allocated.
Gould further teaches: “A growable data structure, such as buffer structure 133, can be increased or decreased in size according to dynamic needs of data processing elements, such as shaders of a GPU.” [0036]. That is, the pre-allocated memory may be dynamically adjusted to fit the needs of the rendering system. Therefore, Gould teaches that the buffers may be dynamically pre-allocated.
Gould further teaches: “Responsive to requests by at least a shader unit of the graphics processor for space in the growable data structure in which to write shader data, the method includes providing to the shader unit at least write pointers to locations within memory pages from the growable data structure in accordance with data sizes indicated in the requests.” That is, the GPU may request data be written to the buffers, and therefore, the buffers are GPU-writable. Therefore, Gould teaches that GPU-writable buffers may be dynamically pre-allocated.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Gould with Paulovich in view of Wittenbrink and Gambetta. Having the GPU-writable buffer be pre-allocated, as in Gould, would benefit the Paulovich in view of Wittenbrink and Gambetta teachings by enabling the GPU to optimize memory usage based on the current rendering configuration: (Gould: The enhanced buffer structures herein allow for flexibility in sizing of the buffers in response to current graphics processing demands, providing for more efficient usage of memory resources, as well as batching data operations and sorting among data operations for shading operations in graphics processors. [0013])
Regarding claim 16:
Claim 16 recites the same limitation(s) as claim 4 and only differs in that claim 16 is dependent on 2 and claim 4 is dependent on 1. Because both claim 2 and 1 are rejected based on Paulovich in view of Wittenbrink and Gambetta, the rationale for combining reference Gould for the rejection of claim 16 is the same as the rationale for the rejection of claim 4.
Regarding claim 17:
Claim 17 recites the same limitation(s) as claim 4 and only differs in that claim 17 is dependent on 2 and claim 4 is dependent on 1. Because both claim 2 and 1 are rejected based on Paulovich in view of Wittenbrink and Gambetta, the rationale for combining reference Gould for the rejection of claim 17 is the same as the rationale for the rejection of claim 4.
Regarding claim 18:
Paulovich in view of Wittenbrink and Gambetta in view of Gould teaches:
The method of claim 4 (as shown above), wherein the GPU-writable buffer is dynamically pre-allocated (Gould: memory page addresses are ready for use in buffer structure 133 ahead of time, and buffer service 125 can quickly respond to data buffer needs of shader unit 121 in a dynamic fashion, [0038]; see Note 4A above).
Claims 5, 6, 19, and 20 are rejected under 35 U.S.C 103 as being unpatentable over Paulovich (US 20180322690 A1; from applicant’s IDS) in view of Wittenbrink (US 7292242 B1; see attached document for paragraph numbers), Gambetta (NPL: Clipping), Gould (US 20190042410 A1) and StackExchange (NPL: Dynamic-length arrays as Shader Storage Buffer Objects).
Regarding claim 5:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), wherein the storing the pair of points in a GPU-writable buffer further comprises:
storing in the GPU writable buffer one of the points of the pair as a start point and the other point of pair as an end point (see Note 5A); and
Note 5A: In Note 1C, it was shown that each pair of points is part of an edge, such as vertices 450 and 440 forming edge 251, vertices 440 and 441 forming edge 443, etc. One of ordinary skill in the art would further recognize that vertex 450 is a start point of edge 251, while vertex 440 is an end point. Similar reasoning applies to the other newly added vertices showcased in Figure 4B. Therefore, one of ordinary skill in the art would be motivated to store in the buffer one of the points of the pair as a start point and the other point of pair as an end point.
Paulovich in view of Wittenbrink and Gambetta fails to teach:
incrementing by two a value stored in the GPU writable buffer.
Gould teaches:
incrementing by two a value (Gould: Buffer service 125 also tracks the amount of data written into buffer structure 133, [0038]; see Note 5B)
Note 5B: Gould teaches: “Buffer service 125 also tracks the amount of data written into buffer structure 133.” [0038]. In Note 4A, it was shown that buffer structure 133 may comprise a buffer. Therefore, when the system stores two points in the GPU writable buffer, it would be obvious to one of ordinary skill in the art to increment a value related to said buffer by two.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Gould with Paulovich in view of Wittenbrink and Gambetta. Incrementing a value by two, as in Gould, would benefit the Paulovich in view of Wittenbrink and Gambetta teachings by ensuring there is an accurate count of the amount of data used by the rendering system.
Paulovich in view of Wittenbrink, Gambetta, and Gould still fails to teach:
incrementing by two a value stored in the GPU writable buffer.
StackExchange teaches:
incrementing by two a value stored in the GPU writable buffer (StackExchange: pass the number of elements actually used to the shader. This can either be an independent uniform variable (uniform uint ballCount;), or you can pack it into the SSBO itself; see Note 5C).
Note 5C: StackExchange teaches: “When the number of elements changes very often, then I suggest not to resize/reallocate the SSBO every time, but to reserve a large enough buffer once and pass the number of elements actually used to the shader. This can either be an independent uniform variable (uniform uint ballCount;), or you can pack it into the SSBO itself,” (Pg. 2, par. 1). That is, the number of elements (in the case of StackExchange, the amount of balls in the buffer) may be stored within the same buffer object as the data (the SSBO) or separated into another uniform buffer.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of StackExchange with Paulovich in view of Wittenbrink, Gambetta, and Gould. Incrementing by two a value stored in the GPU writable buffer, as in StackExchange, would benefit the Paulovich in view of Wittenbrink, Gambetta, and Gould teachings by ensuring there is an accurate count of the amount of data used by the rendering system and that the count is stored in an easily accessible location.
Regarding claim 6:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), wherein the storing the pair of points in a GPU-writable buffer further comprises:
storing in a first GPU writable buffer one of the points of the pair as a start point and the other point of pair as an end point (see Note 5A); and
Paulovich in view of Wittenbrink and Gambetta fails to teach:
incrementing by two a value stored in a second GPU writable buffer.
Gould teaches:
incrementing by two a value (Gould: Buffer service 125 also tracks the amount of data written into buffer structure 133, [0038]; see Note 5B)
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Gould with Paulovich in view of Wittenbrink and Gambetta. Incrementing a value by two, as in Gould, would benefit the Paulovich in view of Wittenbrink and Gambetta teachings by ensuring there is an accurate count of the amount of data used by the rendering system.
Paulovich in view of Wittenbrink, Gambetta, and Gould still fails to teach:
incrementing by two a value stored in a second GPU writable buffer.
StackExchange teaches:
incrementing by two a value stored in a second GPU writable buffer (StackExchange: pass the number of elements actually used to the shader. This can either be an independent uniform variable (uniform uint ballCount;), or you can pack it into the SSBO itself; see Note 5C).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of StackExchange with Paulovich in view of Wittenbrink, Gambetta, and Gould. Incrementing by two a value stored in the GPU writable buffer, as in StackExchange, would benefit the Paulovich in view of Wittenbrink, Gambetta, and Gould teachings by ensuring there is an accurate count of the amount of data used by the rendering system and that the count is stored in an easily accessible location.
Regarding claim 19:
Claim 19 recites the same limitation(s) as claim 5 and only differs in that claim 19 is dependent on 2 and claim 5 is dependent on 1. Because both claim 2 and 1 are rejected based on Paulovich in view of Wittenbrink and Gambetta, the rationale for combining references Gould and StackExchange for the rejection of claim 19 is the same as in the rationale for the rejection of claim 5.
Regarding claim 20:
Claim 20 recites the same limitation(s) as claim 5 and only differs in that claim 20 is dependent on 3 and claim 5 is dependent on 1. Because both claim 3 and 1 are rejected based on Paulovich in view of Wittenbrink and Gambetta, the rationale for combining references Gould and StackExchange for the rejection of claim 20 is the same as in the rationale for the rejection of claim 5.
Claim 7 is rejected under 35 U.S.C 103 as being unpatentable over Paulovich (US 20180322690 A1; from applicant’s IDS) in view of Wittenbrink (US 7292242 B1; see attached document for paragraph numbers), Gambetta (NPL: Clipping), Khronos Group (NPL: Shader Storage Buffer Objects; from applicant’s IDS; hereinafter KhronosGroup A) and Khronos Group (NPL: glDrawArraysIndirect; from applicant’s IDS; hereinafter KhronosGroup B)
Regarding claim 7:
Paulovich in view of Wittenbrink and Gambetta teaches:
The method of claim 1 (as shown above), comprising:
rendering the stored pairs of points in the GPU-writable buffer as a set of lines (Paulovich: Triangles that incorporate one or more edge vertices and/or one or more edge lines may be designated edge triangles […] These primitives, when converted into pixels by the rasterizer, may be rendered using one or more edge effects at the pixel shader [0063]).
Paulovich in view of Wittenbrink and Gambetta fails to teach:
wherein the GPU-writable buffer is an OpenGL-supported shader storage buffer object, and wherein
rendering the stored pairs of points in the GPU-writable buffer as a set of lines is performed by executing an OpenGL indirect draw command.
Khronos Group A teaches:
wherein the GPU-writable buffer is an OpenGL-supported shader storage buffer object (see Note 7A), and wherein
Note 7A: In Note 1D, it was shown that Paulovich teaches a GPU-writable buffer for use with the geometry shader. Because Khronos Group A teaches “SSBOs are writable, even atomically,” (Pg. 1, par. 1), it would be obvious to one of ordinary skill in the art to utilize an OpenGL-supported shader storage buffer object as a GPU-writable buffer.
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Khronos Group A with Paulovich in view of Wittenbrink and Gambetta. Having the GPU-writable buffer be an OpenGL-supported shader storage buffer object, as in Khronos Group A, would benefit the Paulovich in view of Wittenbrink and Gambetta teachings by ensuring an ample amount of memory is available for the rendering system to use: (Khronos Group A: “The spec guarantees that SSBOs can be up to 128MB. Most implementations will let you allocate a size up to the limit of GPU memory.” (Pg. 1, par. 1))
Paulovich in view of Wittenbrink, Gambetta, and Khronos Group A still fails to teach:
rendering the stored pairs of points in the GPU-writable buffer as a set of lines is performed by executing an OpenGL indirect draw command.
Khronos Group B teaches:
rendering the stored pairs of points in the GPU-writable buffer (Khronos Group B: glDrawArraysIndirect — render primitives from array data, taking parameters from memory, Pg. 1, Name) as a set of lines (Khronos Group B: mode: Specifies what kind of primitives to render. […] GL_LINE_STRIP, GL_LINE_LOOP, GL_LINES, GL_LINE_STRIP_ADJACENCY, GL_LINES_ADJACENCY, etc., Pg. 1, Parameters) is performed by executing an OpenGL indirect draw command (see Note 7B).
Before the effective filing date of the claimed invention, it would have been obvious to a person having ordinary skill in the art to combine the teachings of Khronos Group B with Paulovich in view of Khronos Group A. Rendering the stored pairs of points in the GPU-writable buffer as a set of lines is performed by executing an OpenGL indirect draw command, as in Khronos Group B, would benefit the Paulovich in view of Khronos Group A teachings by enabling the system to reduce the amount of subroutine calls while drawing the same amount of objects, which may increase performance of the rendering system: “glDrawArraysIndirect specifies multiple geometric primitives with very few subroutine calls” (Khronos Group B, Pg. 1, Description, par. 1).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINCENT ALEXANDER PROVIDENCE whose telephone number is (571)270-5765. The examiner can normally be reached Monday-Thursday 8:30-5:00.
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, King Poon can be reached at (571)270-0728. 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.
/VINCENT ALEXANDER PROVIDENCE/Examiner, Art Unit 2617 /KING Y POON/Supervisory Patent Examiner, Art Unit 2617
Prosecution Insights