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 statements (IDS) submitted on June 14, 2024, August 25, 2025, and October 31, 2025 were filed after the mailing date of the application on November 24, 2023. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Drawings
The drawings were received on November 24, 2023. These drawings are accepted.
Claim Objections
Claims 1, 10, 11, and 20 are objected to because of the following informalities:
Claims 1 and 11 similarly recite, “…execute a single-pass shader to at perform…” but should recite, “…execute a single-pass shader to perform…”
Claims 10 and 20 similarly recite, “…the frame buffer’s original color…” but is suggested to be consistent with its antecedent, “…the original frame buffer color…” of claims 8 and 18, respectively.
Claims 10 and 20 also similarly recite, “…the local pixel storage…” but is suggested to be consistent with its antecedent, “the pixel local storage…” of claims 8 and 18, respectively.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 11 similarly recite, “…set an anti-aliasing stroke…interpolate a distance to the edge of a stroke…” where “the edge” lacks antecedent basis and the claims further fail to distinctly point out if and how each of “an ant-aliasing stroke” and “a stroke” are different. For prior art purposes, it is considered each of “an ant-aliasing stroke” and “a stroke” are the same.
Claims 1 and 11 also similarly recite, “add additional triangles on the outside…” where the claims fail to clearly define the outside of what. For prior art purposes, this portion of the limitation is omitted from interpretation.
Claims 1 and 11 also similarly recite, “…discard a fifth triangle…” where the claims fail to define first, second, third, and fourth triangles. For prior art purposes, a “fifth triangle” may be any triangle.
Claims 2 and 12 similarly recite, “…apply an anti-aliasing stroke to a path…” where claims 2 and 12 depend upon independent claims 1 and 11, respectively, which recite, “an anti-aliasing stroke” thus fail to distinctly point out if and how each of “an ant-aliasing stroke” are different. For prior art purposes, each “anti-aliasing stroke” is considered to be the same.
Claim 3 is rejected for depending upon rejected claims 1 and 2; claim 13 is rejected for depending upon rejected claim 11 and 12.
Claims 4 and 14 similarly recite, “…tessellate the anti-aliasing stroke end path interior into triangles…” where it is unclear if this is meant to be “the anti-aliasing stroke” or “the anti-aliasing stroke end path.” If intended to be “the anti-aliasing stroke,” claim 4 indirectly depend upon claim 2 and independent claim 1, and claim 14 indirectly depend upon claim 12 and independent claim 11, which each recite, “an anti-aliasing stroke,” thus fail to distinctly point out to which is being referred. If intended to be “the anti-aliasing end path…” the claims lack antecedent basis for “the anti-aliasing end path…” For prior art purposes, it is considered the claim intends to be “the anti-aliasing end path…”
Claim 5 is rejected for depending upon rejected claims 1-4; claim 15 is rejected for depending upon rejected claims 11-14.
Claim 6 is rejected for depending upon rejected claims 1-5; claim 16 is rejected for depending upon rejected claims 11-15.
Claims 7 and 17 similarly recite, “…blending the framebuffer at every path fragment…” where the claims lack antecedent basis for “the frame buffer”
Claims 8 and 18 similarly recite, “…storing the original frame buffer color for the current path in the pixel local storage…” where claims 8 and 18 depend upon dependent claims 7 and 17, respectively, which recite, “the framebuffer” but not “an original frame buffer” nor “an original frame buffer color,” thus lack antecedent basis for “the original frame buffer color.” The claims further recite, “the current path” where claims 8 and 18 indirectly depend upon claims 2 and 12, respectively, which recite, “a path,” thus fail to distinctly point out if “the current path” refers to “a path;” if not, “the current path” lack antecedent basis. Lastly, the claims lack antecedent basis for “the pixel local storage.”
Claims 9 and 19 similarly recite, “…enabling incremental re-blending at every fragment…” where claims 9 and 19 indirectly depend upon dependent claims 7 and 17, respectively, which recite, “…every path fragment…” where the claims fail to distinctly point out if and how each of “every fragment” differ from “every path fragment.”
Claims 10 and 20 similarly recite, “…the current contents of the framework and storing the path identification value…” where each “the current contents,” “the framework,” and “the path identification value” lack antecedent basis.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-4 and 11-14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Goel et al. (US 2014/0043342), herein as GoelA, in view of Goel et al. (US 2014/0043341), herein as GoelB.
As to claim 1, GoelA disclose a method for rendering a graphic in an interactive graphics system (Figure 1, further illustrated in Figure 2), via executable code stored in a memory (e.g. memory 10 storing program modules and/or instructions, [0070]) coupled to a graphical processing unit (e.g. graphics processing unit (GPU) 12), wherein the executable code causes the graphical processing unit to trigger control actions (e.g. [0070] thru [0073] notes program modules and/or instructions executed by central processing unit (CPU), which in turn provides commands and data to be executed by GPU 12) to: execute a single-pass GPU shader to at perform at least one of a stroke function or a fill path function ([0086] notes GPU 12 may use a single-pass rendering approach to perform a path stroking operation, [0088] notes techniques used by the GPU 12 to perform the path stroking operation may include 1) the GPU 12 tessellating the path segment into a plurality of line segments using a fixed-function tessellation engine of GPU 12 and a domain shader program executing on a programmable shader unit of GPU 12, 2) the GPU 12 generating the one or more primitives using a geometry shader program executing on a programmable shader unit of GPU 12, and/or 3) the GPU 12 generating the plurality of normal vertices using a domain shader program executing on a programmable shader unit of GPU 12); batch together a defined number or combination of a plurality of stroke functions and a plurality of fill operations ([0061] notes path filling may be divided into main operations: 1) filling a path segment; and 2) stroking a path segment, where one or both of the filling and stroking operations may be performed to completely render a path, where [0081] further notes GPU 12 may render a fill area for the path segment when performing a fill operation, and may render a stroke area for the path segment when performing a stroke operation; set an anti-aliasing stroke to draw a path fill by setting a variable width of the stroke function (Figures 5, [0215], notes example of stroking, which may include widening a line by thickening the line, e.g. by a stroke width, in two directions perpendicular to the line; Figure 6, [0216], notes example of stroking, in which a pair of triangle strips may be positioned to widen at least one of the line segments, see also Figures 12 and 13, [0255] thru [0263], where Figure 15, [0268] and [0269] further notes each of the sixteen sample points of a pixel are an eight bit counter value, where, in one example, the counter may be a winding counter, and the winding counter values may be incremented or decremented during the edge-drawing phase, and once all the edges have been drawn, the fill process examines the value of these counter values and calculates the pixel coverage value for anti-aliasing); interpolate a distance to the edge of a stroke ([0171] notes domain shader 52 may evaluate tessellated vertices’ locations and normals for lines, cubics and elliptic arc, where [0172] and [0173] notes performing linear interpolations of normals and positions of the tessellation locations); and to emit a bevel join (Figure 8, [0220], [0221] notes example of joining path segments as a bevel) and produce a round or a miter join (Figure 9, [0222] thru [0224] notes example of joining path segments as a miter, Figure 10, [0225] thru [0228] notes example of joining path segments as a round).
As noted above, GoelA describes to emit a bevel join and produce a round or a miter join, but fails to disclose, “…discard an inside triangle to emit a bevel join and add additional triangles on the outside to produce a round or a miter join; and discard a fifth triangle…” with portions of the claim not taught emphasized in italics.
GoelB also disclose a method for rendering a graphic in an interactive graphics system (Figure 1, further illustrated in Figure 2), via executable code stored in a memory (e.g. memory 10 storing program modules and/or instructions, [0041]) coupled to a graphical processing unit (e.g. graphics processing unit (GPU) 12), wherein the executable code causes the graphical processing unit to trigger control actions (e.g. [0041] thru [0044] notes program modules and/or instructions executed by central processing unit (CPU), which in turn provides commands and data to be executed by GPU 12) to: execute a single-pass GPU shader to at perform at least one of a stroke function or a fill path function ([0057] notes GPU 12 may use a single-pass rendering approach to perform a path stroking operation, [0059] notes techniques used by the GPU 12 to perform the path stroking operation may include 1) the GPU 12 tessellating the path segment into a plurality of line segments using a fixed-function tessellation engine of GPU 12 and a domain shader program executing on a programmable shader unit of GPU 12, 2) the GPU 12 generating the one or more primitives using a geometry shader program executing on a programmable shader unit of GPU 12, and/or 3) the GPU 12 generating the plurality of normal vectors using a domain shader program executing on a programmable shader unit of GPU 12); batch together a defined number or combination of a plurality of stroke functions and a plurality of fill operations ([0034] notes path filling may be divided into main operations: 1) filling a path segment; and 2) stroking a path segment, where one or both of the filling and stroking operations may be performed to completely render a path, where [0052] further notes GPU 12 may render a fill area for the path segment when performing a fill operation, and may render a stroke area for the path segment when performing a stroke operation); set a stroke to draw a path fill by setting a variable width of the stroke function ([0058] notes to generate one or more primitives (e.g., triangle primitives) that spatially correspond to a stroke area of a line segment, GPU 12 may, in some examples, generate a plurality of normal vectors for the respective line segment, where each of the normal vectors may be indicative of a direction that is perpendicular to a tangent of the path segment at a respective one of a plurality of points along the path segment, and each of the plurality of points along the path segment may correspond to a respective one of the endpoints of the respective line segment, GPU 12 may determine corner points of a stroke area for the respective line segment based on the plurality of normal vectors and a stroke width); interpolate a distance to the edge of a stroke ([0204] notes to generate the slice approximations for a round join, tessellation stages 62 may generate a plurality of sets of two normal vectors where each set of two normal vectors may correspond to a respective one of the slices of the round join, the plurality of sets of normal vectors may include normal vectors that are interpolated between normal vectors associated with the point (e.g. c) where the two path segments meet, where each of the normal vectors may indicate the direction of one of the points along the curved edge of the round join relative to the common endpoint, and each slice approximation may be defined by the common endpoint (e.g. c) and two normal vectors); discard an inside triangle to emit a bevel join (e.g. Figure 8 and associated text, e.g. [0184] notes for bevel joins, GPU 12 may render one or more triangles that spatially correspond to the bevel area, where [0187] notes possible triangles that may correspond to the bevel join area, [0188] further notes to avoid drawing an unnecessary triangle, geometry shader 54 may, in some examples, take the cross product of the difference vectors (u0-l0) and (u1-l1) and identify which triangle to draw based on the cross product of the different vectors, [0189] further notes if the sign of the cross product in either examples described is negative, then geometry shader 54 may then determine to draw the (c,l1,l0) triangle for the bevel join and to not draw the (c,u0,u1) triangle for the bevel join; on the other hand, if the sign of the cross product in the examples described is positive, then geometry shader 54 may determine to draw the (c,u0,u1) triangle for the bevel join and to not draw the triangle (c,l1,l0), where it may be considered the triangles not drawn as “discarding an inside triangle…”) and add additional triangles on the outside to produce a round or a miter join (Figure 9 and associated text, e.g. [0191] notes for miter joins, GPU 12 may render one or more triangles that spatially correspond to the miter area, where [0198] notes possible triangles that may correspond to the miter join, [0199] further notes to avoid drawing an unnecessary triangle, geometry shader 54 may, in some examples, take the cross product of the difference vectors (u0-l0) and (u1-l1) and identify which triangle to draw based on the cross product of the different vectors, [0200] further notes if the sign of the cross product in either examples described is negative, then geometry shader 54 may then determine to draw the triangles in the {(c,l1,l0),(m,l0,l1)} triangle set for the miter join and to not draw the triangles in the {(c,u0,u1),(m,u0,u1)} triangle set for the miter join; on the other hand, if the sign of the cross product in the examples described is positive, then geometry shader 54 may determine to draw the triangles in the {(c,u0,u1),(mu0,u1)} triangle set for the miter join and to not draw the triangle {(c,l1,l0),(m,l0,l1)} triangle set for the miter join, where it may be considered the triangles drawn as “adding additional triangles on the outside…” see Figure 10 and associated text, e.g. [0202] thru [0217] regarding round join); and discard a fifth triangle (e.g. as noted for either of bevel or miter joins, not drawing a triangle or triangles in a triangle set may be considered to “discard a fifth triangle”).
It would have been obvious to one of ordinary skill in the art at the time of the invention to modify GoelA’s method of rendering a graphic comprising emitting a bevel join and producing a round or a miter join with GoelB’s method of determining whether or not to draw triangles, e.g. add or discard triangles, to avoid drawing unnecessary triangles, thus reducing computation time to render triangles, further enhancing the performance of the system (see [0188], [0199] of GoelB).
As to claim 2, GoelA modified with GoelB discloses to apply an anti-aliasing stroke to a path (GoelA, Figure 15, [0268] and [0269] notes each of the sixteen sample points of a pixel are an eight bit counter value, where, in one example, the counter may be a winding counter, and the winding counter values may be incremented or decremented during the edge-drawing phase, and once all the edges have been drawn, the fill process examines the value of these counter values and calculates the pixel coverage value for anti-aliasing).
As to claim 3, GoelA modified with GoelB disclose to execute an algorithm to render an anti-aliased coverage mask for a select path using a single GPU shader program and a single GPU draw call (GoelA, as noted for claim 2, once all the edges have been drawn, the fill process examines the value of these counter values and calculates the pixel coverage value for anti-aliasing, where ).
As to claim 4, GoelA modified with GoelB disclose to tessellate the antialiasing stroke end path interior into triangles (GoelA, [0240] notes the stroking operation may utilize a single-pass approach that may involve, [0241] 1) tessellating a path segment into a plurality of line segments, [0242] 2) calculating normals for the endpoints of the line segments, [0243] 3) determining a stroke area by widening the line segments using the normals, [0244] 4) generating primitives corresponding to the stroke area, [0245] 5) rendering the primitives to a render target with depth test enabled).
As to claim 11, GoelA modified with GoelB disclose (Figure 1, further illustrated in Figure 2) a non-transitory computer-readable medium (e.g. memory 10) storing instructions (e.g. storing program modules and/or instructions) that, when executed on a processor (e.g. central processing unit (CPU) 6, to further control graphics processing unit (GPU) 12), cause the processor to render a graphic, by performing the steps of as outlined in the method of claim 1. Please see the rejection and rationale of claim 1.
Claims 12-14 are similar in scope to claims 2-4, respectively, and are therefore rejected under similar rationale.
Allowable Subject Matter
Claims 5-10 and 15-20 would be allowable if the 112(b) rejection may be overcome, and if rewritten in independent form including ALL of the limitations of the base claim AND any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: Regarding claims 5 and 15, GoelA and GoelB describe determining whether a triangle is oriented in a clockwise or counter-clockwise direction (GoelA, [0259] thru [0262]; GoelB, [0169] thru [0173]), but do not explicitly disclose “…to: connect adjoined stroke edges with a stroke join function and apply coverage to curve triangles, with positive coverage applied to clockwise curve triangles and negative coverage applied to counter-clockwise curve triangles...” as recited. Regarding dependent claims 6-10 are indicated allowable for directly or indirectly depending upon indicated allowable claim 5; dependent claims 16-20 are indicated allowable for directly or indirectly depending upon indicated allowable claim 15.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JACINTA M CRAWFORD whose telephone number is (571)270-1539. The examiner can normally be reached 8:30a.m. to 4:30p.m.
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 Y. Poon can be reached at (571)272-7440. 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.
/JACINTA M CRAWFORD/Primary Examiner, Art Unit 2617