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 .
Drawings
The replacement drawings were received on June 3, 2024. These drawings are accepted.
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
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 and 3-23 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.
Claim 1 recites, “…generates a respective data element for each of a plurality of work items…storing data elements for a plurality of work items…” where the claim fails to distinctly point out if and how each of “a plurality of work items” are different. For prior art purposes, each of “a plurality of work items” may be considered the same.
Claims 3-11 are rejected for depending upon rejected independent claim 1.
Claim 12 recites, “…a processing circuit configured to…store the generated data elements…” and further recites, “…a processing circuit configured to…use an identifier…” and further recites, “…a processing circuit configured to store the data element…” where the claim fails to distinctly point and if and how each “processing circuit” are different. For prior art purposes, it may be considered each “processing circuit” may be the same.
Claim 13 recites, “…a processing circuit configured to…use an identifier…” and further recites, “…a processing circuit configured to read the data element…” For prior art purposes, it may be considered each “processing circuit” may be the same.
Claims 14-23 are rejected for depending upon rejected independent claim 1.
Claims 21 and 22 further recite, “…a processing circuit…” where claims 21 and 22 depend upon independent claim 12, which refers to multiple processing circuits as noted above, thus fail to distinctly point out if and how each “processing circuit” are different.
Claim 23 further recites, “…a base address…a work item packet…a work item identifier…” where claim 23 depends upon independent claim 12 which refers to these elements, thus fails to distinctly point out if and how each of “…a base address…a work item packet…a work item identifier…” are different. For prior art purposes, it is considered each of “…a base address…a work item packet…a work item identifier…” are the same.
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-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Engh-Halstvedt et al. (US 2019/0012829).
As to claim 12, Engh-Halstvedt et al. disclose a graphics processor operable to execute a graphics processing pipeline (Figure 1, graphics processing pipeline 10, further illustrated in Figures 2 and 3 as graphics processing pipeline 20) comprising a plurality of pipeline stages to generate an output (e.g. first, position, vertex shading stage 21, tiler 22, second, varying, vertex shading stage 23, and/or fragment shading stage 24), the graphics processor comprising: a processing circuit (e.g. to execute tiler 22) configured to, when the graphics processor is executing a pipeline stage (e.g. one or more of first, position, vertex shading stage 21, tiler 22, and/or second, varying, vertex shading stage 23) that generates a respective data element for each of a plurality of work items being processed by the pipeline stage (e.g. generates vertex shaded attribute data for at least one vertex attribute of one or more vertices, e.g. for the position attributes (via first, position, vertex shading stage 21) and/or varying attributes of vertices (via second, varying, vertex shading stage 23), and/or generates a respective primitive list (tile list) for each tile (and/or for set(s) of plural tiles), indicating the primitives that should be processed for that tile (via tiler 22))([0253] notes in response to a position shading request for the vertices, the position shading stage 21 will read in the raw position attributes data for the vertices from memory 25, then perform vertex shading computations on the positional attributes of the vertices (e.g. by means of some transformation function) to generate vertex-shaded data for the position attributes of the vertices; [0254] notes the tiler 22 uses the transformed position data and the list of indices to identify which primitives should be processed for each tile that the render output has been divided into, and prepares (and stores in memory 210) a respective primitive list (tile list) for each tile (and/or for set(s) of plural tiles), indicating the primitives that should be processed for that tile; [0263] notes in response to a varying shading request for the vertex (or group of vertices) from the tiler 22, the varying shading stage 23 reads in the raw varying attributes data for the vertex (or group of vertices) from memory 26, then performs vertex shading computations on the varyings attributes of the vertex (or group of vertices) to generate vertex-shaded data for the varyings attributes of the vertex (or group of vertices)): store the generated data elements as one or more work item packets (e.g. Figures 9 and 10, storing the generated attributes data described above as vertex packets, further described below), each work item packet configured for storing data elements for a plurality of work items (e.g. each vertex packet storing attributes data for n vertices); wherein the data elements in a work item packet are stored as one or more groups of N data elements in the work item packet ([0285] notes each vertex packet 50 can store attributes data for n vertices, and consists of (and stores) n positions 90 starting at offset “0” in the vertex packet (one for each of the n vertices in the packet), and then n sets of non-position attributes (varyings) starting at a position (offset) axn bytes into the block (packet) (e.g. for all the n vertices has been stored)(where a is the number of bytes that the position attributes for a vertex will take up)); and a processing circuit (e.g. to execute tiler 22) configured to, when storing a data element for a work item (e.g. when storing attributes data of the vertices): use an identifier for the work item (e.g. vertex packet attribute descriptor with an internal vertex ID) configured such that a first part of the work item identifier indicates an offset for the group of N data elements that the data element for the work item belongs to relative to a base address ([0288] notes equation for accessing the vertex data in the vertex packets, where [0289] notes the packet_size/attribute_stride/attribute_offset fields are configured statically by the driver, using a new “vertex packet attribute” descriptor, the internal vertex ID is the sequence index allocated to the vertex in question, n is the number of vertices that can be stored in a vertex packet, and the base address is the base address for the overall memory pool 15 where the vertex data is being stored), and a second, different part of the work item identifier (e.g. the internal vertex ID) indicates the relative position of the data element for the work item within the group of N data elements that the data element for the work item belongs to (e.g. [0256], [0257] notes tiler 22 determines which vertices should be allocated memory space in the memory pool 15 for storing their vertex shaded attribute values, e.g. by assuming that each vertex that belongs to a primitive that is to be included in a primitive list (e.g. each vertex that has been determined to belong to a (potentially) visible primitive) should be allocated memory space in the memory space pool 15), to determine a memory address at which to store the data element for the work item ([0332] notes when it is determined that memory space should be allocated to a vertex, memory space is allocated to it by assigning an internal vertex ID, which is the vertex’s position in the sequential index of vertices that have been allocated memory space, to the vertex, this internal vertex ID is then used to control the actual memory allocation (and encoded into the primitive list to identify the vertex), [0336] notes when vertex shaded varying attributes data is generated, the data is written to the correct location in a vertex packet 50 in the memory pool 15 using the received internal vertex ID (sequence index) for the vertex, and the base address, packet_size, attribute_stride and attribute_offset (which can be retrieved from the appropriate descriptor(s), etc.), as noted above, [0338] notes the new internal vertex ID allocated to a vertex is used, together with the base address and the vertex packet size, to calculate where in memory to store the (already vertex shaded) position attributes for the vertex); and a processing circuit (e.g. to execute tiler 22) configured to store the data element for the work item at the determined memory address ([0339] indicates storing the vertex shaded position data for visible primitives).
As noted above, Engh-Halstvedt et al. disclose various graphics processing pipeline stages, e.g. first, position, vertex shading stage 21, tiler 22, second, varying, vertex shading stage 23, and/or fragment shading stage 24, where Engh-Halstvedt et al. further disclose any one or more or all of the processing stages of the technology described herein may be embodied as processing stage circuit/circuitry, e.g., in the form of one or more fixed-function units (hardware) (processing circuits/circuitry), and/or in the form of programmable processing circuit/circuitry that can be programmed to perform the desired operation, thus may further be considered “a processing circuit” as described, yielding predictable results, without changing the scope of the invention. Additionally, as noted above, Engh-Halstvedt et al. describes its vertex packet attribute descriptor and internal vertex ID as separate elements instead of separate parts of the same element. However, Engh-Halstvedt et al. explicitly disclose that each of the vertex packet attribute descriptor and internal vertex ID are used, e.g. collectively, to calculate where in memory to store the attributes data for the vertices [0338], and further describes modifications may be made to the system as suited [0344]. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Engh-Halstvedt et al. vertex packet attribute descriptor and internal vertex ID as separate parts of a single identifier, as the functionalities may be the same, thus does not change the scope of the invention, further yielding predictable results.
Claim 1 is similar in scope to claim 12 above, and is therefore rejected under similar rationale.
As to claim 13, Engh-Halstvedt et al. disclose a graphics processor operable to execute a graphics processing pipeline (Figure 1, graphics processing pipeline 10, further illustrated in Figures 2 and 3 as graphics processing pipeline 20) comprising a plurality of pipeline stages to generate an output (e.g. first, position, vertex shading stage 21, tiler 22, second, varying, vertex shading stage 23, and/or fragment shading stage 24), the graphics processor comprising: a processing circuit (e.g. to execute fragment shading stage 14/24) configured to, when a data element for a work item is needed for a pipeline stage that uses data elements for each of a plurality of work items being processed by the pipeline stage (e.g. when attributes data for vertices are needed by tiler 22 being processed by the tiler 22)([0253] notes in response to a position shading request for the vertices (e.g. from tiler 22), the position shading stage 21 will read in the raw position attributes data for the vertices from memory 25, then perform vertex shading computations on the positional attributes of the vertices (e.g. by means of some transformation function) to generate vertex-shaded data for the position attributes of the vertices; [0254] notes the tiler 22 uses the transformed position data and the list of indices to identify which primitives should be processed for each tile that the render output has been divided into, and prepares (and stores in memory 210) a respective primitive list (tile list) for each tile (and/or for set(s) of plural tiles), indicating the primitives that should be processed for that tile; [0263] notes in response to a varying shading request for the vertex (or group of vertices) from the tiler 22, the varying shading stage 23 reads in the raw varying attributes data for the vertex (or group of vertices) from memory 26, then performs vertex shading computations on the varyings attributes of the vertex (or group of vertices) to generate vertex-shaded data for the varyings attributes of the vertex (or group of vertices)), which data elements have been stored as one or more work item packets (e.g. attributes data stored as vertex packets, further described below), each work item packet configured for storing data elements for a plurality of work items (e.g. each vertex packet storing attributes data for n vertices, as further described below), with the data elements in a work item packet being stored as one or more groups of N data elements in the work item packet ([0285] notes each vertex packet 50 can store attributes data for n vertices, and consists of (and stores) n positions 90 starting at offset “0” in the vertex packet (one for each of the n vertices in the packet), and then n sets of non-position attributes (varyings) starting at a position (offset) axn bytes into the block (packet) (e.g. for all the n vertices has been stored)(where a is the number of bytes that the position attributes for a vertex will take up)): use an identifier for the work item (e.g. vertex packet attribute descriptor with an internal vertex ID) configured such that a first part of the work item identifier indicates an offset for the group of N data elements that the data element for the work item belongs to relative to a base address ([0288] notes equation for accessing the vertex data in the vertex packets, where [0289] notes the packet_size/attribute_stride/attribute_offset fields are configured statically by the driver, using a new “vertex packet attribute” descriptor, the internal vertex ID is the sequence index allocated to the vertex in question, n is the number of vertices that can be stored in a vertex packet, and the base address is the base address for the overall memory pool 15 where the vertex data is being stored), and a second, different part of the work item identifier (e.g. the internal vertex ID) indicates the relative position of the data element for the work item within the group of N data elements that the data element for the work item belongs to (e.g. [0256], [0257] notes tiler 22 determines which vertices should be allocated memory space in the memory pool 15 for storing their vertex shaded attribute values, e.g. by assuming that each vertex that belongs to a primitive that is to be included in a primitive list (e.g. each vertex that has been determined to belong to a (potentially) visible primitive) should be allocated memory space in the memory space pool 15), to determine a memory address from which to read the data element for the work item ([0332] notes when it is determined that memory space should be allocated to a vertex, memory space is allocated to it by assigning an internal vertex ID, which is the vertex’s position in the sequential index of vertices that have been allocated memory space, to the vertex, this internal vertex ID is then used to control the actual memory allocation (and encoded into the primitive list to identify the vertex), [0336] notes when vertex shaded varying attributes data is generated, the data is written to the correct location in a vertex packet 50 in the memory pool 15 using the received internal vertex ID (sequence index) for the vertex, and the base address, packet_size, attribute_stride and attribute_offset (which can be retrieved from the appropriate descriptor(s), etc.), as noted above, [0338] notes the new internal vertex ID allocated to a vertex is used, together with the base address and the vertex packet size, to calculate where in memory to store the (already vertex shaded) position attributes for the vertex); and a processing circuit (e.g. to execute fragment shading stage 14/24) configured to read the data element for the work item from the determined memory address (e.g. [0241] notes the vertex shaded positions and varying data (and the primitive lists) are stored in the allocated memory space in the memory space pool 15, and read therefrom by the fragment shader stage 14 of the graphics processing pipeline 10 for subsequent processing).
As noted above, Engh-Halstvedt et al. disclose various graphics processing pipeline stages, e.g. first, position, vertex shading stage 21, tiler 22, second, varying, vertex shading stage 23, and/or fragment shading stage 24, where Engh-Halstvedt et al. further disclose any one or more or all of the processing stages of the technology described herein may be embodied as processing stage circuit/circuitry, e.g., in the form of one or more fixed-function units (hardware) (processing circuits/circuitry), and/or in the form of programmable processing circuit/circuitry that can be programmed to perform the desired operation, thus may further be considered “a processing circuit” as described, yielding predictable results, without changing the scope of the invention. Additionally, as noted above, Engh-Halstvedt et al. describes its vertex packet attribute descriptor and internal vertex ID as separate elements instead of separate parts of the same element. However, Engh-Halstvedt et al. explicitly disclose that each of the vertex packet attribute descriptor and internal vertex ID are used, e.g. collectively, to calculate where in memory to store the attributes data for the vertices [0338], and further describes modifications may be made to the system as suited [0344]. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the invention to modify Engh-Halstvedt et al. vertex packet attribute descriptor and internal vertex ID as separate parts of a single identifier, as the functionalities may be the same, thus does not change the scope of the invention, further yielding predictable results.
Claim 2 is similar in scope to claim 13 above, and is therefore rejected under similar rationale.
As to claims 3 and 14, Engh-Halstvedt et al. disclose the pipeline stage is: a vertex shading stage, a geometry processing stage, a fragment processing stage, a compute shading stage, or a binning/tiling stage (e.g. as noted in claim 12 above, the pipeline stage may include a first, position, vertex shading stage 21, tiler 22, and/or second, varying, vertex shading stage 23, where Figure 2 further illustrates a fragment shading stage 24).
As to claims 4 and 15, Engh-Halstvedt et al. disclose the work items are vertices, and the data elements are positions for the vertices, or sets of one or more varyings for the vertices (e.g. as noted in claim 12 above, the work items may include vertices, and the data elements may include attributes data for vertices, e.g. position attributes (via first, position, vertex shading stage 21) and/or varying attributes of vertices (via second, varying, vertex shading stage 23)).
As to claims 5 and 16, Engh-Halstvedt et al. disclose the work items are primitives, and the data elements are sets of one or more attributes for the primitives (e.g. as noted in claim 12 above, the work items may include primitives (e.g. identified by tiler 22), to which the vertices described may belong, and the data elements are attributes for the primitives may correlates to the attributes data for vertices, e.g. position attributes (via first, position, vertex shading stage 21) and/or varying attributes of vertices (via second, varying, vertex shading stage 23)).
As to claims 6 and 17, Engh-Halstvedt et al. disclose the work item packet (e.g. vertex packet) stores plural different sets of groups of N data elements for a set of work items (as noted in claim 12 above, each vertex packet 50 can store attributes data for n vertices, and consists of (and stores) n positions 90 starting at offset “0” in the vertex packet (one for each of the n vertices in the packet), and then n sets of non-position attributes (varyings) starting at a position (offset) axn bytes into the block (packet) (e.g. for all the n vertices has been stored)(where a is the number of bytes that the position attributes for a vertex will take up)), the different sets of groups of N data elements being stored in an interleaved manner in the work item packet ([0141] notes the position data and the non-position (varyings) data for the vertices in an embodiment is not (is other than) interleaved in a memory space pool block (vertex packet), where [0344] notes various modifications may be made to the system as suited, thus denotes a different embodiment may interleave the position and non-position (varyings) data).
As to claims 7 and 18, Engh-Halstvedt et al. disclose the work item packet stores plural different sets of groups of N data elements for a set of work items (e.g. as noted in claim 12 above, each vertex packet 50 can store attributes data for n vertices, and consists of (and stores) n positions 90 starting at offset “0” in the vertex packet (one for each of the n vertices in the packet), and then n sets of non-position attributes (varyings) starting at a position (offset) axn bytes into the block (packet) (e.g. for all the n vertices has been stored)(where a is the number of bytes that the position attributes for a vertex will take up)), and the processing circuit (e.g. to execute tiler 22) is configured to: use the same identifier for a work item to determine the memory address for the data element for the work item in each of plural different sets of groups of N data elements for the set of work items in the work item packet; and use a different base address to determine the memory address for the data element for the work item for different sets of groups of N data elements for the set of work items in the work item packet (e.g. as noted in claim 12 above, tiler 22 determines which vertices should be allocated memory space in the memory pool 15 for storing their vertex shaded attribute values, e.g. by assuming that each vertex that belongs to a primitive that is to be included in a primitive list (e.g. each vertex that has been determined to belong to a (potentially) visible primitive) should be allocated memory space in the memory space pool 15, where the internal vertex ID allocated to a vertex is used, together with the base address and the vertex packet size, to calculate where in memory to store the (already vertex shaded) position attributes for the vertex, thus the base address may be different for different sets attributes data of the vertices).
As to claims 8 and 19, Engh-Halstvedt et al. disclose each group of N data elements is stored at a contiguous set of memory addresses, starting at a memory address that is aligned with the beginning of a cache line ([0283] notes each block (vertex packet) 50 is the same size, and is configured to be an integer number of the cache lines, meaning that the start of each new block (vertex packet) will be cache-line aligned, where [0138] notes the assigned internal vertex ID (sequence index) for a vertex modulo n (e.g. internal vertex ID modulo 64 for a 64-byte cache line cache) equaling 0 can then be used as a test to indicate that a new block (vertex packet) needs to be allocated (at least in the case where there is a contiguous memory space allocation at increasing addresses), [0286] notes, e.g. each cache line is 64-bytes and each vertex has 4×FP32 coordinates, accordingly, n is set to 64 so as to ensure that a vertex packet will always be an integer number of cache lines and a is set to 16); and the first part of a work item identifier indicates a cache line offset from a base address (e.g. similarly noted in claim 12 above, [0143] notes the packet_size/attribute_stride/attribute_offset fields can be and are in an embodiment configured statically by the driver, e.g. using a new “vertex packet attribute” descriptor, the internal vertex ID is the sequence index allocated to the vertex in question, n is the number of vertices that will be stored in a vertex packet (and so in an embodiment corresponds to the number of bytes that can be stored in a cache line, such as 64), and the base address is the base address for the overall memory pool where the vertex data is being stored).
As to claims 9 and 20, Engh-Halstvedt et al. disclose the same base address is used for plural work item packets (e.g. as noted in claim 12 above, the same base address may be used for a plurality of vertex packets).
As to claims 10 and 21, Engh-Halstvedt et al. disclose a processing circuit (e.g. to execute tiler 22) configured to: determine a base address to be used for determining the memory address for a work item packet or packets (e.g. as noted in claim 12 above, the base address is the base address for the overall memory pool 15 where the vertex data is being stored); and determine work item identifiers to be used to determine the memory addresses for data elements for work items in the work item packet based on the determined base address (e.g. as noted in claim 12 above, the base address is the base address for the overall memory pool 15 where the vertex data is being stored, whereas further noted in claim 12 above, tiler 22 determines which vertices should be allocated memory space in the memory pool 15 for storing their vertex shaded attribute values, and when it is determined that memory space should be allocated to a vertex, memory space is allocated to it by assigning an internal vertex ID, which is the vertex’s position in the sequential index of vertices that have been allocated memory space, to the vertex, this internal vertex ID is then used to control the actual memory allocation (and encoded into the primitive list to identify the vertex), thus further based on the base address, e.g. of memory pool 15).
As to claims 11 and 22, Engh-Halstvedt et al. disclose a processing circuit (e.g. to execute tiler 22) configured to: determine the memory address for a data element as: memory address for data element = base address + offset indicated by first part of work item identifier + (second part of work item identifier * stride) where the stride is the (data) size of a data element in the group of data elements ([0288] notes in order to access the vertex data in the vertex packets, the following addressing scheme is used: Address=base address+floor(internal vertex ID/n)*packet_size+(internal vertex ID % n)*attribute_stride+Attribute_offset, where
[0289] further notes the packet_size/attribute_stride/attribute_offset fields are configured statically by the driver, using a new “vertex packet attribute” descriptor, the internal vertex ID is the sequence index allocated to the vertex in question, n is the number of vertices that can be stored in a vertex packet, and the base address is the base address for the overall memory pool 15 where the vertex data is being stored).
As to claim 23, Engh-Halstvedt et al. disclose a hardware controlled buffer (e.g. memory space pool 15) configurable with a base address (e.g. base address) that is to be used for accessing data elements in a work item packet (e.g. for accessing attributes data in vertex packet), together with a data size for a data element (e.g. together with the data size, e.g. packet size)(as noted in claim 12 above, [0288] notes in order to access the vertex data in the vertex packets, the following addressing scheme is used: Address=base address+floor(internal vertex ID/n)*packet_size+(internal vertex ID % n)*attribute_stride+Attribute_offset, where [0289] notes the packet_size/attribute_stride/attribute_offset fields are configured statically by the driver, using a new “vertex packet attribute” descriptor, the internal vertex ID is the sequence index allocated to the vertex in question, n is the number of vertices that can be stored in a vertex packet, and the base address is the base address for the overall memory pool 15 where the vertex data is being stored); and configured to: take as an input a work item identifier for a work item (e.g. internal vertex ID), and then determine the memory address for the data element for that work item from the work item identifier, base address and data element data size (e.g. as noted in claim 12 above, [0338] notes the new internal vertex ID allocated to a vertex is used, together with the base address and the vertex packet size, to calculate where in memory to store the (already vertex shaded) position attributes for the vertex).
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