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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 8/28/2026 has been entered.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claim 1 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 1 recites, “each first core comprising a geometry processing master unit...” and “each second core comprising a fragment shading master unit...” The Specification discloses in [0024], “One of the first cores may comprise a geometry processing master unit...” The Specification also discloses in [0026], “One of the second cores may comprise a fragment shading master unit...” There is no support in the Specification for each first core having a geometry processing master unit and each second core having a fragment shading master unit. Therefore, these limitations are considered to be NEW MATTER.
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 is silent regarding each first core comprising 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, however, PSVita teaches
each first core comprising 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, (“The Master VDM splits vertex processing work amongst the cores in order in order to load balance their usage... 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.”; PSVita, p. 3, 2nd para under “Master VDM”)
The Master VDM (each first core comprising a geometry processing master unit) splits vertex processing work according to a pre-defined split threshold in number of primitives (split the stream of primitives into groups of primitives), amongst the cores (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 each first core comprising 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, in order to load balance the vertex processing amongst the cores while preserving primitive submission order to ensure correct rasterization, as taught by PSVita (p. 3, 2nd para under Master VDM).
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 is silent regarding each second core comprising a fragment shading master unit, configured to assign the tiles among the second cores, however, PSVita teaches
each second core comprising a fragment shading master unit, configured to assign the tiles among the second cores, (“The Master IPF – Master ISP Parameter Fetch – is responsible for processing the Parameter Buffer produced by the multiple cores and initiating the rasterization process... Using information provided by the Master VDM, the Master IPF also ensures primitives binned in each tile are rasterized in submission order... the Master IPF will also distribute rasterization and fragment processing amongst the cores... distribution across the cores is naturally achieved in terms of tiles; this is the fundamental unit of rasterization work at master level. Each tile assigned to a core is rasterized and processed entirely on that core.”; PSVita, p. 4, 1st–2nd para under Master IPF)
The Master IPF (second core comprising a fragment shading master unit) initiates the rasterization process by ensuring that the primitives binned in each tile are rasterized in submission order. The Master IPF distributes rasterization and fragment processing amongst the cores in terms of tiles (assign the tiles among the second cores). Each tile is assigned to a core (assign the tiles among the second 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 each second core comprising a fragment shading master unit, configured to assign the tiles among the second cores, in order to ensure that the tiles are efficiently load balanced, as taught by PSVita (p. 4, 2nd para under Master IPF).
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 state 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 7/28/2026 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 (in addition to the other limitations nowhere disclosed or suggested by the prior art as further discussed below).”
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. 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 under Master IPF). 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 also teaches, “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 under Master IPF). 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).
Applicant's arguments filed 7/28/2026 have been fully considered but they are not persuasive. Applicant argues:
“First, Applicant submits that there is nothing in the prior art that discloses or suggests putting a geometry processing master unit in any of the first cores, let alone all of the first cores. The rejection of original claim 4 contended that it would have been obvious to put one geometry processing master unit in one core of the plurality of cores as allegedly disclosed in Danskin. However, for the reasons submitted in the previous response, Applicant disagrees that it would have been obvious to incorporate, into the multithreaded core array disclosed in Danskin, any of the processing tasks in PSVita that are performed centrally by master units away from the cores (e.g., by the Master VDM).”
Examiner disagrees. As discussed above in the 35 U.S.C § 112(a) Rejection, there is no support in the Specification for each first core having a geometry processing master unit and each second core having a fragment shading master unit. Thus, this is considered to be NEW MATTER. Also, as discussed above, PSVita teaches that the Master VDM (each first core comprising a geometry processing master unit) splits vertex processing work according to a pre-defined split threshold in number of primitives (split the stream of primitives into groups of primitives), amongst the cores (assign the groups of primitives among the first cores). (PSVita, p. 3, 2nd para under “Master VDM”). 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 of references that teach the limitations of claim 1.
Applicant's arguments filed 7/28/2026 have been fully considered but they are not persuasive. Applicant argues:
“Secondly, notwithstanding the above, none of the cited prior art suggests providing a geometry processing master unit in every first core, as required by amended claim 1. In both PSVita and Danskin, any geometry-processing allocation functionality is provided centrally by a single unit located away from the cores. In Howson, geometry processing is not performed by the cores, and so there is no geometry processing master unit as defined by claim 1. PSVita discloses only a single Master VDM and provides no reason to incorporate Master VDM functionality into each first core of Danskin's multithreaded core array. Similarly, in Danskin, the allocation of data for geometry processing is performed centrally by a single data assembler 206 located away from the cores (see Fig. 2 and paragraphs [0051] and [0052]). Neither reference provides any reason to depart from these single-unit arrangements by providing every first core with the claimed master capability.”
Examiner disagrees. As discussed above in the 35 U.S.C § 112(a) Rejection, there is no support in the Specification for each first core having a geometry processing master unit and each second core having a fragment shading master unit. Thus, this is considered to be NEW MATTER. As discussed above, PSVita teaches that the Master VDM (each first core comprising a geometry processing master unit) splits vertex processing work according to a pre-defined split threshold in number of primitives (split the stream of primitives into groups of primitives), amongst the cores (assign the groups of primitives among the first cores). (PSVita, p. 3, 2nd para under “Master VDM”). 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 of references that teach the limitations of claim 1.
Applicant's arguments filed 7/28/2026 have been fully considered but they are not persuasive. Applicant argues:
“In summary, Applicant submits that it would not have been obvious to configure each first core in a multicore graphics system to comprise 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. Applicant maintains that there is no disclosure or suggestion in any of the cited documents of the stitching together of the control lists by the second cores, as required by claim 1, as previously explained. The Master IPF disclosed in PSVita is a central master unit located away from the cores, as confirmed on page 3, in the section "Block Overview", and in the section "SGX543+ Core Block Overview", beginning on page 5. At point 32 of the "Response to Arguments" section of the final Office action, the Examiner does not appear to contest this. However, the Office action then asserts, without articulating a technical reason to support the assertion, that Danskin's cores would be modified to perform the Master IPF function. Applicant disagrees.”
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. 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 under Master IPF). 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 also teaches, “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 under Master IPF). 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).
Applicant's arguments filed 7/28/2026 have been fully considered but they are not persuasive. Applicant argues:
“Applicant submits that there is nothing in the cited prior art that discloses or suggests providing any core, let alone every second core, with a fragment shading master unit configured to assign the tiles among the second cores. In each of Howson, Danskin and PSVita, any allocation of fragment processing work is always performed in a single, central unit that is located away from the cores. Even if one fragment shading master unit were provided in one core - which is neither suggested by nor obvious from the prior art - there is nothing in the prior art that discloses or suggests modifying the cores in the multithreaded core array of Danskin to require each second core to comprise a fragment shading master unit. Each cited reference instead provides the relevant master functionality using a single central unit, separately from all cores, and none provides any reason to depart from that arrangement by providing every second core with its own fragment shading master unit. Applicant therefore submits that it would not be obvious in view of the cited prior art to modify the cores in the multithreaded core array of Danskin to contain a fragment shading master unit. In summary, Applicant submits that neither of the features added to claim 1 above, requiring each first core to comprise a geometry processing master unit and each second core to comprise a fragment shading master unit, would have been obvious from the prior art.”
Examiner disagrees. PSVita teaches that the Master IPF (second core comprising a fragment shading master unit) initiates the rasterization process by ensuring that the primitives binned in each tile are rasterized in submission order. The Master IPF distributes rasterization and fragment processing amongst the cores in terms of tiles (assign the tiles among the second cores). Each tile is assigned to a core (assign the tiles among the second cores). It would have been obvious to modify Howson and Danskin to include the Master IPF of PSVita in order to ensure that the tiles are efficiently load balanced, as taught by PSVita (p. 4, 2nd para under Master IPF). 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 of references that teach the limitations of claim 1.
Applicant's arguments filed 7/28/2026 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. Claims 1, 6-8 and 11-13 have been rejected. Please see the corresponding rejections.
Conclusion
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