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 .
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1, 2, 3, 4, 5, 17, 18, 19 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Howson et al. U.S. Pub. No. 2020/0380755 in view of Danskin et al. U.S. Pub. No. 2007/0159488 and “Graphics – SGX543MP4”, September 13, 2020, XP093061510, Retrieved from the Internet: URL: https://www.psedevwiki.com/vita/Graphics (hereinafter PSVita).
Re: claim 1, Howson teaches
1. A multicore graphics rendering system, comprising: a plurality of cores, configured to implement tile-based deferred rendering of a stream of primitives, (“In order to render a tile, the fetch unit 112 fetches the control stream for a tile and the primitives relevant to that tile from the memory 1041. For example, the rendering unit may implement rasterization according to a deferred rendering technique, such that one or more of the processor core(s) 114 are used to perform hidden surface removal to thereby remove fragments of the primitives which are hidden in the scene, and then one or more of the processor core(s) 114 are used to apply texturing and/or shading to the remaining primitive fragments to thereby form rendered image values... The graphics processing system 100 described above is a deferred rendering system because the rendering logic 110 is configured to perform the HSR processing on a primitive fragment before the texturing/shading processing is applied to the primitive fragment.”; Howson, [0007], [0009])
The fetch unit fetches the control stream for a tile and the primitives relevant to that tile (stream of primitives), then, the rendering unit implements rasterization according to deferred rendering for the tile (tile-based deferred rendering), such that one or more processor cores (a plurality of cores) perform hidden surface removal to remove fragments of the primitives which are hidden in the scene (which defers rendering).
(“Fig. 2 shows an example of a rendering space 200... The tiles may be grouped into sets of one or more tiles that can be assigned to the processor cores 114 of the graphics processing system 100 to perform a render N. As described above, the processor cores 114 may be arranged into one or more processor groups, where each processor group contains one or more processor cores.”; Howson, [0084], Fig. 2)
Fig. 2 illustrates that tiles are grouped into sets and assigned to processor cores to perform rendering.
Howson is silent regarding first cores of the plurality are configured to perform geometry processing work, and second cores of the plurality are configured to perform fragment processing work, however Danskin teaches
wherein first cores of the plurality are configured to perform geometry processing work, and second cores of the plurality are configured to perform fragment processing work, (“... vertex shader programs and geometry shader programs are executed using the same programmable processing engines in multithreaded core array 202. Thus, at certain times, a given processing engine may operate as a vertex shader, receiving and executing vertex program instructions, and at other times the same processing engine may operate as a geometry shader, receiving and executing geometry program instructions. The processing engines can be multithreaded, and different threads executing different types of shader programs may be in flight concurrently multithreaded core array 202.”; Danskin, [0037])
The vertex shader programs and geometry shader programs are executed using the same programmable processing engines. At certain times, a processing engine may operate as a vertex shader and at other times the same processing engine may operate as a geometry shader (first cores of the plurality are configured to perform geometry processing work). The processing engine are multithreaded and different threads executing different programs may be in flight concurrently
(“Pixel shader programs are advantageously executed in multithreaded core array 202 using the same programmable processing engines that also execute the vertex and/or geometry shader programs. Thus, at certain times, a given processing engine may operate as a vertex shader, receiving and executing vertex program instructions; at other times the same processing engine may operate as a geometry shader, receiving and executing geometry program instructions; and at still other times the same processing engine may operate as a pixel shader, receiving and executing pixel shader program instructions. It will be appreciated that the multithreaded core array can provide natural load-balancing between pixel and vertex processing: where the application is geometry intensive... a larger fraction of the processing cycles in multithreaded core array 202 will tend to be devoted to vertex and/or geometry shaders, and where the application is pixel intensive... a larger fraction of the processing cycles will tend to be devoted to pixel shaders.”; Danskin, [0043])
The pixel shader programs are executed using the same programmable processing engines that also execute the vertex and/or geometry shader programs. At certain times a given processing engine may operate as a vertex shader, and at other times the same processing engine may operate as a geometry shader (first cores of the plurality are configured to perform geometry processing work), and at still other times, the same processing engine may operate as a pixel shader. The multithreaded core array provides load-balancing between pixel and vertex processing, such that, for example, if the application is geometry intensive, a larger fraction of the processing cycles in the multithreaded core array is devoted to vertex and/or geometry shaders (first cores of the plurality are configured to perform geometry processing work) and where the application is pixel intensive, a larger fraction of the processing cycles will be devoted to pixel shaders (second cores of the plurality are configured to perform fragment processing work). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of first cores of the plurality are configured to perform geometry processing work, and second cores of the plurality are configured to perform fragment processing work, in order to provide a graphics processor that can adapt to varying loads on different shaders while maintaining a high degree of parallelism, as taught by Danskin ([0008]).
Howson teaches, wherein each first core is configured to process groups of primitives, to produce a set of tile control lists describing, for each of a plurality of tiles, the primitives processed by that first core that are present in that tile,... each first core being configured to write the tile control lists, including the group indices, to a memory, (“The tiling unit 410 determines which primitives are present within each of the ties of the rendering space of the graphics processing system 400. The tiling unit 410 assigns primitives to tiles of the rendering space by creating control streams for the tiles, wherein the control stream for a tile includes indication of the primitives which are present within the tile. The control streams and the primitives are outputted from the tiling unit 410 and stored in the memory 404.”; Howson, [0108])
The tiling unit (first cores) determines which primitives (groups of primitives) are present within each of the tiles (each of a plurality of tiles) and assigns primitives to the tiles by creating control streams (control lists) for the tiles (each first core is configured to process groups of primitives produce a set of tile control lists describing, for each of the plurality of tiles, the primitives processed by that first core that are present in that tile). The control stream of a tile includes indication of the primitives which are present within the tile. The control streams (tile control lists, including the group indices) are outputted from the tiling unit and stored in the memory.
... each group being associated with a group index, the group indices defining the ordering of the groups in the stream of primitives, (“In this example, the sets of tiles are assigned, or allocated, to the processor groups in raster scan order, but in other examples sets of tiles could be allocated to the processor cores in any other suitable order. Once a processor group has finished processing its assigned set of tiles, the next set of tiles according to a specified ordering pattern is assigned to that processor group. The tile sets may be assigned according to any suitable ordering pattern, for example raster scan order, N order, Z order, etc.”; Howson, [0088])
The sets of tiles are assigned (each group being associated with a group index) to processor groups in raster scan order (the group indices defining the ordering of groups in the stream of primitives). In this case, the group index indicates raster scan order.
(“The scheduling logic 416 allocates the sets of one or more tiles to the processor groups based on a scheduling order. That scheduling order could for example be the raster scan order. Alternatively, the scheduling logic may implement some other scheduling order, such as z-order. ”; Howson, [0110])
The scheduling logic sets the tiles to the processor groups based on a scheduling order, which is for example, raster scan order.
Howson and Danskin are silent regarding each second core comprising at least one rasterisation pipeline, each rasterisation pipeline comprising one or more processors configured to perform fragment processing for one or more of the tiles, wherein each rasterisation pipeline is configured to, for each tile to be processed by its one or more processors: read from the memory the tile control lists produced for that tile by the first cores; and stitch together the tile control lists, to produce a combined tile control stream for the tile, wherein the rasterisation pipeline stitches together the tile control lists in the order defined by the group indices, however PSVita teaches
each second core comprising at least one rasterisation pipeline, each rasterisation pipeline comprising one or more processors configured to perform fragment processing for one or more of the tiles, (“Each tile assigned to a core is rasterized and processed entirely on that core.”; PSVita, p. 4, 2nd para)
Each tile is assigned to a core (second core), and the assigned core is rasterized and processed on that core (at least one rasterisation pipeline, each rasterisation pipeline comprising one or more processors).
(“The PDM – Pixel Data Master – is responsible for starting rasterization and fragment processing within the core. The PDM accepts tile command streams, stored in the Parameter Buffer, from the Master IPF. One tile command stream is received per tile, containing references to primitive data (output by vertex programs) and stat data. The tile command streams contain all the information needed to setup and execute all subsequent fragment processing stages.”; PSVita, p. 5, 1st para under “PDM”)
Rasterization and fragment processing is performed on the tiles within the core.
wherein each rasterisation pipeline is configured to, for each tile to be processed by its one or more processors: read from the memory the tile control lists produced for that tile by the first cores; and stitch together the tile control lists, to produce a combined tile control stream for the tile, wherein the rasterisation pipeline stitches together the tile control lists in the order defined by the group indices. (“The Master IPF – Master ISP Parameter Fetch – is responsible for processing the Parameter Buffer produced by the multiple cores and initiating the rasterization process. As Master IPF reads the Parameter Buffer, it combines the individual subsets produced by the cores, such that each tile has a single tile command stream. A tile command stream contains references to primitive data (output by vertex programs) and state data required for rasterization and fragment processing.”; PSVita, p. 4, 1st para)
The Master IPF reads (read from the memory the tile control list) the Parameter Buffer produced by multiple cores (produced for that tile by the first cores), and combines (stitch together) subsets (tile control lists) produced by the cores, such that each tile has a single control stream (to produce a combined control stream for the tile).
(“Using information provided by the Master VDM, the Master IPF also ensures primitives binned in each tile are rasterization submission order. ”; PSVita, p. 4, 2nd para)
The Master IPF (rasterisation pipeline) combines subsets (stitch together tile control lists) and uses information from the Master VDM to ensure that primitives binned in each tile are in rasterization submission order (in the order defined by the group of indices). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of each second core comprising at least one rasterisation pipeline, each rasterisation pipeline comprising one or more processors configured to perform fragment processing for one or more of the tiles, wherein each rasterisation pipeline is configured to, for each tile to be processed by its one or more processors: read from the memory the tile control lists produced for that tile by the first cores; and stitch together the tile control lists, to produce a combined tile control stream for the tile, wherein the rasterisation pipeline stitches together the tile control lists in the order defined by the group indices, in order to perform the Parameter Buffer read and distribute rasterization and fragment processing amongst the cores in parallel to ensure they are efficiently load balanced, as taught by PSVita (p. 4, 2nd para).
Re: claim 2, Howson in view of Danskin and PSVita teach
2. The multicore graphics rendering system of claim 1, wherein the combined tile control stream for each tile is provided by the rasterisation pipeline directly to the one or more processors. (“As Master IPF reads the Parameter Buffer, it combines the individual subsets produced by the cores, such that each tile has a single tile command stream... In parallel to the Parameter Buffer read, the Master IPF will also distribute rasterisation and fragment processing amongst the cores; and ensure that they are efficiently load balanced.”; PSVita, p. 4, 2nd para)
The Master IPF combines individual subsets produced by cores so that each tile has a single tile command stream (the combined tile control stream for a tile), which is used for rasterization, which is distributed among the cores (provided by the rasterisation pipeline directly to the one or more processors). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of the combined tile control stream for each tile is provided by the rasterisation pipeline directly to the one or more processors, in order to perform the Parameter Buffer read and distribute rasterization and fragment processing amongst the cores in parallel to ensure they are efficiently load balanced, as taught by PSVita (p. 4, 2nd para).
Re: claim 3, Howson in view of Danskin and PSVita teach
3. The multicore graphics rendering system of claim 1, wherein at least one of the second cores comprises multiple rasterisation pipelines. (“... the Master IPF will also distribute rasterization and fragment processing amongst the cores... Each tile assigned to a core is rasterized and processed entirely on that core.”; PSVita, p. 4, 1st para)
The Master IPF distributes rasterization amongst the cores (at least one of the second cores comprises multiple rasterization pipelines). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of at least one of the second cores comprises multiple rasterisation pipelines, in order to perform the Parameter Buffer read and distribute rasterization and fragment processing amongst the cores in parallel to ensure they are efficiently load balanced, as taught by PSVita (p. 4, 2nd para).
Re: claim 4, Howson in view of Danskin and PSVita teach
4. The multicore graphics rendering system of claim 1, wherein one of the first cores comprises a geometry processing master unit, configured to split the stream of primitives into the groups of primitives, and assign the groups of primitives among the first cores. (“The Master VDM splits vertex processing work amongst the cores in order to load balance their usage, while at the same time preserving primitive submission order to ensure correct rasterization. Vertex processing is basically split according to a pre-defined split threshold (in number of primitives). These primitive chunks are the fundamental unit of vertex processing work at master level.”; PSVita, p. 3, 2nd para under “Master VDM”)
The Master VDM (geometry processing master unit) splits vertex processing into primitive chunks (groups of primitives) and distributes (assign the groups of primitives among the first cores) these chunks amongst the cores (one of the first cores comprises a geometry processing master unit, configured to split the stream of primitives into groups of primitives, and assign the groups of primitives among the first cores) Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of one of the first cores comprises a geometry processing master unit, configured to split the stream of primitives into the groups of primitives, and assign the groups of primitives among the first cores, in order to split vertex processing amongst the cores to load balance their usage, while preserving primitive submission order to ensure correct rasterization, as taught by PSVita (p. 3, 2nd para under “Master VDM”).
Re: claim 5, Howson in view of Danskin and PSVita teach
5. The multicore graphics rendering system of claim 1, wherein each of the first cores comprises a geometry processing slave unit, configured to control the processing of the groups of primitives assigned to that core, to produce the respective set of tile control lists. (“The VDM – Vertex Data Master – is responsible for starting vertex processing within the core. The VDM accepts VDM command stream segments from the Master VDM via a FIFO. The VDM command stream contains high-level commands such as Draw Index List and Set Vertex Processing State, which in turn reference primitive (vertex) indices and state data.”; PSVita, p. 5, 1st para under “VDM”)
The VDM (geometry processing slave unit) starts vertex processing within the core (control the processing of the groups of primitives assigned to that core) using a VDM command stream, which includes, for example a draw index list (to produce the respective set of tile control lists). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of each of the first cores comprises a geometry processing slave unit, configured to control the processing of the groups of primitives assigned to that core, to produce the respective set of tile control lists, in order to reduce redundant vertex shading computation, as taught by PSVita (p. 5, 2nd para under “VDM”).
Re: claim 17, Howson in view of Danskin and PSVita teach
17. A graphics processing system comprising the multicore graphics rendering system as set forth in claim 1 and a memory.
(“The present disclosure is directed to processing graphics data in a graphics processing system that comprises multiple groups of one or more processor cores... In response to a processor core, working on the second render, requesting data from a region of a memory modifiable by the still in progress first render, a progress indication is checked.”; Howson, [0082])
The graphics processing system comprises multiple groups of processor cores (multicore graphics rendering system as set forth in claim 1) and a memory.
Re: claim 18, Howson in view of Danskin and PSVita teach
18. A method of manufacturing a graphics processing system as set forth in claim 17 comprising inputting an integrated circuit definition dataset to an integrated circuit manufacturing system, which configures the integrated circuit manufacturing system to manufacture the graphics processing system. (“There is provided a method of manufacturing, using an integrated circuit manufacturing system, a graphics processing unit as described herein.”; Howson, [0062])
The method of manufacturing a graphics processing unit (method of manufacturing a graphics processing system as set for thin claim 17) uses an integrated circuit manufacturing system (inputting an integrated circuit definition dataset to an integrated circuit manufacturing system, which configures the integrated circuit manufacturing system to manufacture the graphics processing system).
Re: claim 19, Howson in view of Danskin and PSVita teach
19. A non-transitory computer readable storage medium having stored thereon an integrated circuit definition dataset that, when processed in an integrated circuit manufacturing system, configures the integrated circuit manufacturing system to manufacture a graphics processing system as set forth in claim 17. (“There is provided a non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing unit as described herein.”; Howson, [0063])
The non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit (an integrated circuit definition dataset) that when processed in an integrated manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing system as described herein.
Re: claim 20, Howson in view of Danskin and PSVita teach
20. An integrated circuit manufacturing system configured to manufacture a graphics processing system as set forth in claim 17. (“There is provided a non-transitory computer readable storage medium having stored thereon a computer readable description of an integrated circuit that, when processed in an integrated circuit manufacturing system, causes the integrated circuit manufacturing system to manufacture a graphics processing unit as described herein.”; Howson, [0063])
An integrated circuit manufacturing system, that processes a computer readable description of an integrated circuit and causes the manufacture of a graphics processing unit (configured to manufacture a graphics processing system as set forth in claim 17).
Claim(s) 6 and 7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Howson in view of Danskin and PSVita as applied to claim 1 above, and further in view of Redshaw U.S. Pub. No. 2020/0265547.
Re: claim 6, Howson in view of Danskin and PSVita are silent regarding the second cores are configured to execute a partial render, comprising performing fragment processing for primitives in a renderable range of groups, the renderable range starting with a starting group and ending with an ending group, wherein, before executing the partial render, geometry processing has been completed for every group ahead of the ending group in the ordering, however, Redshaw teaches
6. The multicore graphics rendering system of claim 1, wherein the second cores are configured to execute a partial render, comprising performing fragment processing for primitives in a renderable range of groups, the renderable range starting with a starting group and ending with an ending group, (“Fig. 3 shows a graphics processing system 300 which is configured to allow the processing of primitives to switch between primitives of different tiles before all of the primitives of a particular tile have finished being processed. In this sense the graphics processing system 300 can have “multiple tiles in flight”, i.e., multiple tiles for which the primitives are partially processed at a given time... In the example shown in Fig. 3, the block of queues 312 comprises four queues 3141 to 3142;... ”; Redshaw, [0032], Fig. 3)
The rendering process includes the graphics processing system processing (rendering) primitives by switching between the primitives of different tiles before all of the primitives of a particular tile have finished being processed (execute a partial render). In this case there are four tiles (primitives in a renderable range of groups) that are stored in four queues and that are being switched between (fragment processing for primitives in a renderable range of groups, the renderable range starting with a starting group and ending with an ending group). There are multiple tiles for which the primitives are partially processed at a given time (partial render).
(“Primitives of different tiles are received at the block of queues 312 of the graphics processing system 300. The primitives may relate to objects of a scene to be rendered... The primitives are associated with tiling data which indicates one or more tiles 202 in which the primitives will be processed... Each of the queues 3141 to 3142 is configured to store the primitives for a respective tile at a time... The graphics processing system 300 shown in Fig. 3 can have up to four tiles in flight at a given time.”; Redshaw, [0033])
Primitives of different tiles are received at the block of queues, each of which stores the primitives for a respective tile.
(“The processing module 302 has a processing unit which operates on one primitive at a time. However, since the graphics processing system 300 comprises a plurality of depth buffers 3181 to 3182, it is able to switch between processing primitives from different tiles before finishing the processing of all of the primitives within a tile. ”; Redshaw, [0038])
Fig. 3 illustrates a processing module that switches between processing primitives from different tiles before finishing the processing of all the primitives within a tile (partial render).
wherein, before executing the partial render, geometry processing has been completed for every group ahead of the ending group in the ordering. (“The HSR performed by the processing module 302 for a primitive comprises determining which sample positions lie within the primitives (based on the vertex positions of the primitives), and performing depth tests at these sample positions based on the depth values stored in the relevant depth buffer 318.”; Redshaw, [0036])
Before the partial render, HSR is performed for primitives in a tile (every group) based on the vertex positions of the primitives (geometry processing has been completed for every group ahead of the ending group in the ordering). Redshaw is combined with Howson, Danskin and PSVita such that the processing of Redshaw is performed by the cores of Howson. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of the second cores are configured to execute a partial render, comprising performing fragment processing for primitives in a renderable range of groups, the renderable range starting with a starting group and ending with an ending group, wherein, before executing the partial render, geometry processing has been completed for every group ahead of the ending group in the ordering, in order to enable greater flexibility in the order in which the primitives are processed by the processing module, which leads to more efficient processing of the primitives by the graphics processing system 300, as taught by Redshaw ([0038]).
Re: claim 7, Howson in view of Danskin, PSVita and Redshaw teach
7. The multicore graphics rendering system of claim 6, wherein: the primitives are described in primitive block data stored in the memory; (“The Master VDM splits vertex processing work amongst the cores in order to load balance their usage, while at the same time preserving primitive submission order to ensure correct rasterization. Vertex processing work is basically split according to a pre-defined split threshold (in number of primitives). These primitive chunks are the fundamental unit of vertex processing work at master level. Consequently, it is possible for individual Draw commands to be split over multiple cores. Once the cores accept their requested vertex processing work they operate independently, generating their own subset of the Parameter Buffer.”; PSVita, p. 4, 1st para)
The Master VDM splits the vertex processing work amongst the cores, while at the same time preserving primitive submission order (primitives are described). The vertex processing work is split into primitive chunks (primitives are described in primitive block data) and stored in the Parameter Buffer (stored in memory).
the tile control lists contain pointers to the primitive block data, (“As Master IPF reads the Parameter Buffer, it combines the individual subsets produced by the cores, such that each tile has a single tile command stream. A tile command stream contains references to primitive data (output by vertex programs) and state data required for rasterization and fragment processing... Using information provided by the Master VDM, the Master IPF also ensures primitives binned in each tile are rasterized in submission order.”; PSVita, p. 4, 1st-2nd paras)
Each tile has a single tile command stream (tile control list), which includes references (pointers) to primitive data (to the primitive block data).
and the graphics rendering system is configured to free memory associated with portions of tile control lists and primitive block data that have been rendered in the partial render. (“As vertex processing proceeds individual cores request memory pages from the Master DPM, which are allocated from a free list. As fragment processing proceeds and sections of the scene are rendered, the Master DPM receives lists of memory pages back from the cores.”; PSVita, p. 4, 2nd para under “Master DPM”)
As fragment processing proceeds and sections of the scene are rendered (partial render), the Master DPM receives lists of memory pages back from the cores (free memory associated with portions of tile control lists and primitive block data that have been rendered in the partial render). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of the primitives are described in primitive block data stored in the memory; the tile control lists contain pointers to the primitive block data, and the graphics rendering system is configured to free memory associated with portions of tile control lists and primitive block data that have been rendered in the partial render, in order to ensure the maximum amount of free Parameter Buffer memory is maintained, as taught by PSVita (p. 4, 2nd para under “Master DPM”).
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Howson in view of Danskin and PSVita as applied to claim 1 above, and further in view of Yang U.S. Pub. No. 2011/0292032.
Re: claim 8, Howson in view of Danskin and PSVita are silent regarding each first core maintains, for each tile control list that it produces: a head pointer, indicating the start of the tile control list; and a tail pointer, indicating the location in memory where the first core should continue writing the tile control list if it encounters a primitive that belongs in the respective tile, wherein each first core further maintains, for each tile control list, a record of the group index of the primitive last written by the core to the tile control list, however, Yang teaches
8. The multicore graphics rendering system of claim 1, wherein each first core maintains, for each tile control list that it produces: a head pointer, indicating the start of the tile control list; (“The primitives are then grouped into primitive blocks with a fixed maximum number of vertices and primitives, and are written into memory at 102 in Fig. 1. The number of vertices and primitives together with the memory addresses of the primitive blocks (primitive block pointers) are sent to a Tiling Engine at 103 to be added to a control stream for a display list for the tiles which are covered by the primitives.”; Yang, [0007])
Yang teaches that it is well known in the art that the primitives are grouped into primitive blocks and written to memory. The number of vertices, primitives and memory addresses of the primitive blocks are sent to the Tiling Engine to be added to a control stream for a display list for the tiles (tile control list).
(“The primitive block is added to the display list for any tile which is covered by any primitives in the primitive block. The control data written in the control stream associated with the display list of the tile includes a primitive block header for the number of vertices and primitives in the primitive block, a primitive block pointer for the memory address of the primitive block written to, and a primitive mask for the primitives which are visible in the tile.”; Yang, [0009])
The control data written in the control stream of associated with the display list of the tile includes, for example, a primitive block pointer for the memory address of the primitive block written to (which includes a head pointer, indicating the start of the tile control list).
(“3D image processing in the 3D computer graphics system is performed at 104 for each tile of the screen from a region array 300 of Fig. 3. It traverses through the control stream of each tile 301 in Fig. 3, reads the vertex and primitive data from memory addresses pointed to by the primitive block pointer in the control data 302.”; Yang, [0012])
Image processing is performed for each tile by traversing through the control stream of each tile (for each tile control list that it produces), reading the vertex and primitive data from memory addresses pointed to by the primitive block pointer in the control data (which includes, a head pointer, indicating the start of the tile control list).
and a tail pointer, indicating the location in memory where the first core should continue writing the tile control list if it encounters a primitive that belongs in the respective tile, (“Separate memory spaces are allocated to each tile for the control stream data in the display list. A memory address pointer called a tail pointer is used for the next free address in the control stream data of each tile.”; Yang, [0010])
A tail pointer is used to indicate the next free address in the control stream data of each tile (which includes indicating the location in memory where the first core should continue writing the tile control list if it encounters a primitive that belongs in the respective tile).
wherein each first core further maintains, for each tile control list, a record of the group index of the primitive last written by the core to the tile control list. (“All the tiles are traversed by Tiling Engine to decide if any primitives are inside the tile and control stream data associated to the primitive block which is visible in the tile are written to memory for the tile display list. In the example display control stream T5 will include control data for the address pointers of the three primitive blocks and triangle visible mask of the triangles within the three primitive blocks. For example the first three triangles from left in primitive block 602 and the first triangle from right of primitive block 603 are visible in T5 together with triangle 604. ”; Yang, [0013])
Fig. 6 illustrates that the control stream for tile T5 (tile control list) includes control data for the address pointers of the three primitive blocks, such as the first three triangles from the left in primitive block 602 (group index), the first triangle from right of primitive block 603 (group index) and triangle 604 (group index). For example, the control stream for tile T5 includes control data for the first three triangles from the left in primitive block 602 (a record of the group index of the primitive last written by the core to the tile control list). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of each first core maintains, for each tile control list that it produces: a head pointer, indicating the start of the tile control list; and a tail pointer, indicating the location in memory where the first core should continue writing the tile control list if it encounters a primitive that belongs in the respective tile, wherein each first core further maintains, for each tile control list, a record of the group index of the primitive last written by the core to the tile control list, in order to reduce the requirement for large internal storage and memory bandwidth, as taught by Yang ([0015]).
Claim(s) 11 and 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Howson in view of Danskin, PSVita and Yang as applied to claim 8 above, and further in view of Lee et al. U.S. Pub. No. 2017/0256016.
Claim 11 is a system analogous to the system of claim 6, is similar in scope and is rejected under the same rationale. Claim 11 has an additional limitation. Re: claim 11, Howson in view of Danskin, PSVita and Yang are silent regarding upon execution of the partial render, each first core updates its tail pointers based on a comparison of its group index records with the renderable range of groups rendered in the partial render, however, Lee teaches
11. The multicore graphics rendering system of claim 8,... wherein, upon execution of the partial render, each first core updates its tail pointers based on a comparison of its group index records with the renderable range of groups rendered in the partial render. (“Circular buffers enable the streaming of large chunks of data, such as images, through a relatively small memory, such as SRAM 607a-607x implement inside an SoC. The circular buffer implementation illustrated in Fig. 7 includes a shared buffer 702 in which actual data is stored a circular buffer writer 701 having write access to the shared buffer 702, and one or more circular buffer readers 705 each having read access to the shared buffer 702. A head pointer 703, which indicates write progress, is transferred from shared buffer writer 701 to each of shared buffer readers 705. A tail pointer 704, which indicates read progress, is transferred from one of the shared buffer readers 705 performing a read to the shared buffer writer 701.”; Lee, [0053], Fig. 7)
Circular buffers enable the streaming of large chunks of data, such as images, where the tail pointer indicates read progress
(“The head pointer 703 is updated by circular buffer writer 701 to indicate that data at locations lower than the value indicated is valid. Each tail pointer 605 is updated by it respective circular buffer reader 705 to indicate that the data at locations lower than the value indicated has been fully consumed and will not be needed in the future. ”; Lee, [0054])
Fig. 7 illustrates that the tail pointers are updated, by a respective circular buffer reader, to indicate that data at locations lower than the value indicated (based on a comparison of its group index records with the renderable range of groups in the partial render) will not be needed in the future. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of upon execution of the partial render, each first core updates its tail pointers based on a comparison of its group index records with the renderable range of groups rendered in the partial render, in order to indicate fully consumed locations that will not be needed in the future, as taught by Lee ([0054]).
Re: claim 12, Howson in view of Danskin, PSVita, Yang and Lee teach
12 The multicore graphics rendering system of claim 11, wherein, upon execution of the partial render, if a tail pointer is associated with a group index in the renderable range, the first core is configured to invalidate said tail pointer. (“The head pointer 703 is updated by circular buffer writer 701 to indicate that data at locations lower than the value indicated is valid. Each tail pointer 605 is updated by it respective circular buffer reader 705 to indicate that the data at locations lower than the value indicated has been fully consumed and will not be needed in the future. ”; Lee, [0054])
Fig. 7 illustrates that the tail pointers are updated, by a respective circular buffer reader, to indicate that data at locations lower than the value indicated (tail pointe is associated with a group index in the renderable range) based on a comparison of its group index records with the renderable range of groups in the partial render) will not be needed in the future (invalidate said tail pointer). Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of upon execution of the partial render, if a tail pointer is associated with a group index in the renderable range, the first core is configured to invalidate said tail pointer, in order to indicate fully consumed locations that will not be needed in the future, as taught by Lee ([0054]).
Re: claim 13, Howson in view of Danskin, PSVita and Lee teach
13. The multicore graphics rendering system of claim 1, wherein each tile control list has an associated head pointer, pointing to the start of the tile control list, (“The buffer 702 is addressed in blocks of storage of width W. The buffer entries having a starting address ranging from a value equal to a base address (0, in the example depicted) and a value less than an ending address of the last block... The value 801 within the head pointer 703 indicates the next buffer entry to which data may be written by the circular buffer writer 701, which may indicate an address ranging up to a buffer entry address value 802... The circular buffer writer 701 may write data to locations greater than or equal to the head pointer value 801 and less than a value 802 based on the sum of the buffer size and the lowest (minimum) of all tail pointers 803-805”; Lee, [0055], Fig. 8)
Fig. 8 illustrates a circular buffer with the head pointer 703 (head pointer) indicating (pointing) the next buffer entry to which data may be written at 801 (to the start of the tile control list). Data may be written between locations 801 (start of the tile control list) and 802.
wherein each rasterisation pipeline of each second core is configured to read, from the memory location indicated by the head pointer, a portion of the respective tile control list. (“Each of circular buffer readers 705 may read data from any location that is less than the head pointer value 801 and greater than or equal to its respective tail pointer value 803, 804 or 805... Whenever the respective one of the hardware accelerators 1701-1710 operates by raster reads and writes for the operation(s) performed in the use case implemented, the allocated memory space may be configured in the form of a circular buffer; when necessary, however, the allocated memory space may be configured as a tile buffer.”; Lee, [0055], [0083] Fig. 8)
The circular buffer is read from any location that is less than the head pointer value 801 (read from the memory location indicated by the head pointer, a portion of the respective control list), where the reading is performed during rasterization. Therefore, it would have been obvious to one of ordinary skill in the art at the time of the effective filing date, to modify the graphics processing system of Howson by adding the feature of ach tile control list has an associated head pointer, pointing to the start of the tile control list, wherein each rasterisation pipeline of each second core is configured to read, from the memory location indicated by the head pointer, a portion of the respective tile control list, in order to indicate fully consumed locations that will not be needed in the future, as taught by Lee ([0054]).
Allowable Subject Matter
Claims 9, 10, 14-16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. None of the prior art teaches or suggests::
From claim 9 – “wherein, if the first core encounters a primitive that belongs in a given tile, and the first core determines that the tail pointer for the respective tile control list is invalid, then the first core is configured to: request a memory allocation for that tile control list; receive a first address of a first portion of memory allocated in response to the request; and update the head pointer to point to said first address.” Claim 10 depend from claim 9 and includes all of the limitations of claim9.
From claim 14 – “wherein, when stitching together the tile control lists, each rasterisation pipeline of each second core is configured to remove the group indices and the pointers.”
From claim 15 – “wherein, when stitching together the tile control lists, each rasterisation pipeline is configured to read from the tile control list associated with the earliest group index, and to append data read from that tile control list to the combined tile control stream.”
From claim 16 – “and if the last group index encountered by the rasterisation pipeline in that particular tile control list is the group index of the ending group of the renderable range, stop stitching, and update the head pointers of the other tile control lists to point to the earliest unrenderable group in the respective tile control lists.”
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Response to Arguments
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“In particular, neither Howson, nor Danskin, nor PSVita discloses the concept of stitching together tile control lists produced by first cores by second cores. Consequently, no possible combination of Howson, Danskin or Graphics or modification of one by one or more of the others, could have resulted in the claimed invention for this reason alone... ”
Examiner disagrees. PSVita teaches, “The Master IPF – Master ISP Parameter Fetch – is responsible for processing the Parameter Buffer produced by the multiple cores and initiating the rasterization process. As Master IPF reads the Parameter Buffer, it combines the individual subsets produced by the cores, such that each tile has a single tile command stream (tile control lists). A tile command stream contains references to primitive data (output by vertex programs) and state data required for rasterization and fragment processing.” (PSVita, p. 4, 1st para). The Master IPF reads the parameter buffer The Master IPF reads (read from the memory the tile control list) the Parameter Buffer produced by multiple cores (produced for that tile by the first cores), and combines (stitch together) subsets, which are tile command streams (tile control lists) produced by the cores, such that each tile has a single control stream (to produce a combined control stream for the tile).
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Applicant respectfully submits that the rejection is based on an improper use of hindsight by using the claimed invention as a template from which to pick and choose elements from the prior art to "stitch" together in an attempt to recreate the invention. The rejection improperly dissociates claim 1 into separate limitations and then attempts to match each isolated limitation to unrelated disclosures in the cited references. This piecemeal mapping fails to address the invention as a whole, but instead treats the claim as a collection of disconnected concepts. Such an approach effectively rebuilds the invention by starting from claim 1 and then retrospectively searching for partial matches in the prior art. As such, in order to arrive at the present invention from the prior art, the person of ordinary skill must already know the invention and then reconstruct it from In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).”
Examiner disagrees. It is the combination of references that reject the claims. In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971). In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“In particular, the Examiner acknowledges Howson fails to disclose first and second cores that are configured to respectively perform geometry and fragment processing. In Howson, the geometry processing work, je. the processing of groups of primitives to produce a set of tile control lists, is not performed by a core, but instead is performed centrally by the tiling unit (see element 108 in Fig. 1). There is only one tiling unit 108 and it is separate and independent from the processor cores (elements 114 in Fig. 1). The cores in Howson exclusively perform fragment processing. None of the cores performs geometry processing. Furthermore, the specific features of each second core as set forth in claim 1, in particular the features of the rasterization pipeline, are also not disclosed in Howson. ”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The combination teaches the limitation. Howson teaches that the tiling unit performs the function of and is considered to include first cores, determines which primitives (groups of primitives) are present within each of the tiles (each of a plurality of tiles) and assigns primitives to the tiles by creating control streams (control lists) for the tiles (each first core is configured to process groups of primitives produce a set of tile control lists describing, for each of the plurality of tiles, the primitives processed by that first core that are present in that tile). Danskin teaches the first and second cores, where the first cores perform geometry processing and the second cores perform fragment processing. Danskin teaches that the vertex shader programs and geometry shader programs are executed using the same programmable processing engines. At certain times, a processing engine may operate as a vertex shader and at other times the same processing engine may operate as a geometry shader (first cores of the plurality are configured to perform geometry processing work). The processing engine are multithreaded and different threads executing different programs may be in flight concurrently. (Danskin, [0037]). Danskin is combined with Howson such that the cores of Danskin are included in the tiling unit of Howson.
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Moreover, Applicant submits that Howson fails to disclose more than the features of claim 1 acknowledged to be missing from Howson. Specifically, Howson does not describe "each group being associated with a group index, the group indices defining the ordering of the groups in the stream of primitives". Paragraph [0088] of Howson neither discloses nor suggests the claimed "group indices" or the division of a primitive stream into ordered groups as recited in claim 1. The passage cited in the rejection describes the assignment of sets of tiles to processor groups (for rendering), where the "order" refers to the sequence in which tiles are allocated (e.g., raster scan, Z-order, N- order). This is fundamentally different from claim 1, which (implicitly prior to geometry processing by the first cores) divides the stream of primitives into ordered groups, assigns each group to a first core, and generates tile control lists associated with group indices to preserve the original primitive order. Instead, Howson addresses tile scheduling for load balancing and not the preservation of primitive order across cores or the generation of group-indexed control lists. Accordingly, claim 1 is further distinguished from Howson by this limitation. Moreover, neither Danskin nor PSVita discloses the use of group indices as defined by claim 1. Accordingly, Applicant submits that claim 1 is patentable over the applied prior art for this feature alone, as no possible combination of the prior art would have attained this feature. ”
Examiner disagrees. Howson teaches that the sets of tiles are assigned (each group being associated with a group index) to processor groups in raster scan order (the group indices defining the ordering of groups in the stream of primitives). In this case, the group index indicates raster scan order. (Howson, [0088]).
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Applicant further submits that in asserting that Danskin teaches "wherein first cores of the plurality are configured to perform geometry processing work, and second cores of the plurality are configured to perform fragment processing work," the Office action improperly dissociates the limitation into disconnected elements. The Examiner refers to paragraph [0037], which discloses programmable processing engines that may be configured to perform geometry shader programs or vertex shader programs. Both of those shader types are executed before any sort of rasterization (see paragraph [0039]), and thus before any fragments have been produced. Therefore, paragraph [0039] is not a disclosure of first cores configured to perform geometry processing work and second cores configured to perform fragment processing work. Not only does this paragraph have nothing to do with fragment processing work, but it fails to disclose the sort of geometry processing work defined later in the claims as being performed by the first cores. In particular, Danskin does not disclose cores that process groups of primitives to produce tile control lists, as required of the first cores in claim 1. The setup module is arguably the closest Danskin comes to approximating the production of tile control lists (see element 208 in Fig. 2), since it is positioned before rasterization and uses edge equations to make determinations about the coverage of a primitive (although it is emphasized that the setup module does not produce tile control lists). However, that is away from the multithreaded core array (element 202). Therefore, Danskin also fails to teach first cores configured to perform geometry processing work as required by claim 1. ”
Examiner disagrees. Danskin teaches that the pixel shader programs are executed using the same programmable processing engines (cores) that also execute the vertex and/or geometry shader programs. At certain times a given processing engine may operate as a vertex shader, and at other times the same processing engine may operate as a geometry shader (first cores of the plurality are configured to perform geometry processing work), and at still other times, the same processing engine may operate as a pixel shader. The multithreaded core array provides load-balancing between pixel and vertex processing (which are being processed in parallel), such that, for example, if the application is geometry intensive, a larger fraction of the processing cycles, which operate in parallel, in the multithreaded core array is devoted to vertex and/or geometry shaders (first cores of the plurality are configured to perform geometry processing work) and where the application is pixel intensive, a larger fraction of the processing cycles, which operate in parallel, will be devoted to pixel shaders (second cores of the plurality are configured to perform fragment processing work). (Danskin, [0043]). Thus, the programmable processing engines (cores) perform vertex/geometry processing and the pixel processing are performed in parallel, where when the application is geometry intensive, a larger fraction of the processing cycles is devoted to vertex/geometry shaders and when the application is pixel intensive, a larger fraction of the processing cycles is devoted to pixel shaders.
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Moreover, even if the Examiner's intent was to correlate the pixel shader programs in paragraph [0043] of Danskin to the claimed fragment processing work, the mapping is still deficient because the Danskin programmable processing engines do not incorporate a rasterization pipeline as required of the second cores by current claim 1. Danskin clearly presents rasterizer 210 (Fig. 2) as separate to the multithreaded core array 202. Consequently, in both the case of the first cores and second cores, the Office action's mapping ignores the other requirements of the recited limitation in respect of those cores. Even if the skilled person were motivated to adapt Howson on the basis of Danskin (which Applicant maintains is not the case), it is unrealistic to suggest that the multithreaded core array of Danskin would be introduced to Howson without at least also introducing the Danskin rasterizer, to compensate for the lack of rasterization pipeline in the Danskin multithreaded array. However, that combination would then still not arrive at the claimed features (even ignoring the lack of production of tile control lists in Danskin) because the claim requires the second cores to each comprise a rasterization pipeline.”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). The combination teaches the limitations. PSVita teaches that each tile is assigned to a core (second core), and the assigned core is rasterized and processed on that core (at least one rasterisation pipeline, each rasterisation pipeline comprising one or more processors). (PSVita, p. 4, 2nd para). Rasterization and fragment processing are performed on the tiles within the core. (PSVita, p. 5, 1st para under “PDM”). PSVita is combined with Howson and Danskin such that the cores of PSVita performing fragment processing and rasterization are included in the cores of Danskin.
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Additionally, Applicant submits that there is no disclosure in the cited prior art of the stitching together by the second cores of the control lists produced by the first cores. Claim 1 requires the second cores to comprise rasterization pipelines that are configured to stitch together the tile control lists in the order defined by the group indices, ie the stitching is performed in the second cores. However, in PSVita cited for this feature, the Master IPF combines the individual subsets produced by the cores (see page 4, 1st paragraph). The Master IPF is a master block which is separate from the cores. This is confirmed on page 3, in the section "Block Overview", which states: "the SGX543MP4+ multi-core GPU contains four SGX543+ cores and several master blocks whose role it is to orchestrate and distribute work amongst the cores efficiently." Applicant further notes that the cores described in section "SGX543+ Core Block Overview", beginning on page 5, do not include any master blocks. It is clear, therefore, that the stitching in PSVita is performed in a master unit separate from the cores. As none of the cited references discloses or suggests second cores configured to "stitch together tile control lists to produce a combined tile control stream for the tile," this feature of claim 1 represents a further patentable distinction over the purported combination of Howson, Danskin and PSVita. ”
Examiner disagrees. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). It is the combination that teaches the limitation. PSVita teaches that the Master IPF reads (read from the memory the tile control list) the Parameter Buffer produced by multiple cores (produced for that tile by the first cores), and combines (stitch together) subsets (tile control lists) produced by the cores, such that each tile has a single control stream (to produce a combined control stream for the tile). (PSVita, p. 4, 1st para). The Master IPF (rasterisation pipeline) combines subsets (stitch together tile control lists) and uses information from the Master VDM to ensure that primitives binned in each tile are in rasterization submission order (in the order defined by the group of indices). (PSVita, p. 4, 2nd para). PSVita is combined with Danskin and Howson such that the cores of Danskin perform the functions of the Master IPF of PSVita.
Applicant's arguments filed 10/28/2025 have been fully considered but they are not persuasive. Applicant argues:
“Redshaw (U.S. Pub. 2020/0265547), relied on in combination with Howson, Danskin and PSVita to reject claims 6 and 7, Yang (U.S. Pub. 2011/0292032), relied on in combination with Howson, Danskin and PSVita to reject claim 8, and Lee (U.S. Pub. 2017/0256016), relied on in combination with Howson, Danskin, PSVita and Yang to reject claims 11-13, each fail to rectify the flaws in the primary proposed combination of Howson, Danskin and PSVita with respect to the requirements of the independent claims. Accordingly, no addition of any or all of Redshaw, Yang and Lee to Howson, Danskin and PSVita could have resulted in the invention set forth in claims 6-8 or 11-13.”
Examiner disagrees. Claim 1 as well as claims 6-8 and 11-13 have been rejected. Please see the corresponding rejections.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DONNA J RICKS whose telephone number is (571)270-7532. The examiner can normally be reached on M-F 7:30am-5pm EST (alternate Fridays off).
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, Devona Faulk can be reached on 571-272-7515. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Donna J. Ricks/Examiner, Art Unit 2612
/DEVONA E FAULK/Supervisory Patent Examiner, Art Unit 2618
Prosecution Insights