DETAILED ACTION
This action is in response to communications: Amendment filed February 9, 2026.
Claims 1-20 are pending in this case. No claims have been newly amended, added, or cancelled. This action is made FINAL.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statements (IDS) submitted on September 30, 2025 and February 9, 2026 were filed before/after the mailing date of the Non-Final Office Action on October 1, 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-3, 6-8, 10-13, 16-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2015/0379672).
As to claims 1 and 11, Wang discloses a graphics processor (e.g. one or more of Figures 3-16) comprising: processing circuits (e.g. various components illustrated) configured to execute a tile-based graphics processing pipeline (e.g. tile-based deferred rendering (TBDR) pipelines) to generate an output (e.g. to generate an output), the graphics processing pipeline being executed comprising: a sequence of one or more geometry processing stages to perform geometry processing (e.g. for simplicity, Figure 5, input assembler unit (IA) 311, shader stage 1 410 to shader stage n 412, cull, clip, viewport (CCV) 313, as part of binning pass 405, where [0049] notes binning pass processes the geometry of the scene); a binning stage (binning pass including binning unit 315) that generates data structures for identifying geometry to be processed for respective rendering tiles of a render output being generated (e.g. generates buffered results identifying geometry to be processed in tile rendering pass noted below); and a rendering stage (e.g. IA 311, shader stage 1 410 to shader stage n 412, CCV 313, more rendering stages 430, as part of tile rendering pass 406) for rendering tiles of a render output being generated (e.g. rendering tiles of a render output, e.g. to tile buffer, where [0049] notes tile rendering pass as final rendering pipeline for processing each of screen tiles); wherein: the geometry processing stage or stages of the graphics processing pipeline generate respective packets for processing, each packet storing data for geometry to be processed (e.g. storing output of each geometry stage noted above in respective buffers 1 420 to buffer n+1 423, considered “packets,” where [0056] notes binning pass 405 includes buffer 1 420 that stores an output from the shader stage 1 410, buffer 2 421 that stores output from shader stage 2 411, buffer n 422 that stores output from the shader stage n 412, and buffer n+1 423 that stores output from the CCV 313); the graphics processor further comprising: a processing circuit (e.g. mechanisms in graphics pipelines such as Stream Out mechanism in D3D and the Transform Feedback mechanism in OpenGL, [0059], and/or GPU driver software [0064]) configured to: determine, for a packet, whether to defer some of the geometry processing of the sequence of one or more geometry processing stages of the graphics processing pipeline being executed until the rendering stage (e.g. determining whether to defer some of the stages of the binning pass 405 until the tile rendering pass 406)([0054] and [0055] notes at any point of the graphics pipeline where the results produced at that point can be saved during the binning pass (e.g. binning pass 405 of Figure 5) and consumed in the tile rendering pass (e.g. tile rendering pass 406 of Figure 5), where TBDR pipeline may be modified based on various criteria, such as implementation cost, complexity, power efficiency and performance, where Figure 17, step 1710, [0097] notes determining granularity for the optimal graphics pipeline configuration based on graphics state information and one or more factors, step 1720, [0098] further notes determining an optimal pipeline configuration during a processing phase of the graphics pipeline based on estimating one or more of memory power consumption and computation power consumption for storing and regenerating intermediate results based on graphics state information and one or more factors, step 1730, [0099] further notes collecting runtime information for primitives from pipeline hardware including factors from tessellation or using graphics state information for determining geometry expansion at an output of one or more shader stages, see also [0100] thru [0103]); when it is determined to defer some of the geometry processing for a packet to the rendering stage, associate with the packet an indication that further geometry processing should be performed for the packet at the rendering stage (e.g. when it is determined to defer stages from the binning pass to the tile rendering pass, further provide information indicating each memory buffer that has stored intermediate results to be retrieved for the tile rendering pass)(step 1740, [0099] notes determining intermediate results to save from a previous processing pass by comparing memory power consumption to save the intermediate results with computation power as well as memory power needed for regenerating the intermediate results in one or more later tile rendering passes, where [0104] notes further providing information that indicates each particular memory buffer that the saved intermediate results will be retrieved from based on matching granularity for a current configuration of the graphics pipeline system); and when it is other than determined to defer geometry processing for the packet to the rendering stage, trigger the performing of all of the sequence of one or more geometry processing stages for the graphics processing pipeline being executed for the packet before providing the packet to the binning stage (e.g. when it is determined not to defer stages from the binning pass to the tile rendering pass, processing each of the stages of the binning pass and tile rendering pass in sequence)([0054] notes that the pipeline may also choose not to save the results in the binning pass but reproduce that in the tile rendering pass, if that is more beneficial).
As noted above, Wang discloses one or more stages of its binning pass may generate data that is stored in respective memory buffers, where this data generated and stored may be considered “packets” as claimed, which may be then used as input for the deferred geometry processing in the tile rendering pass as described, thus yielding predictable results, without changing the scope of the invention.
As to claims 2 and 12, Wang discloses the geometry processing that is deferred for a packet comprises one of: vertex shading; mesh shading; tessellation evaluation shading; or geometry shading (e.g. as noted in claims 1 and 11, [0054] and [0055] notes deferring any stage at any point, e.g. Figure 4 illustrates vertex (position) shader (VSPOS (position only)) 312 may be deferred, Figure 5 illustrates multiple shader stages 1 410 to shader stage n 412 may be deferred, Figure 7 illustrates vertex shader (VS) 327, hull shader (HS) 630, tessellator 710, domain shader (DSPOS (position only)) 650, and geometry shader (GSPOS (position only)) 660 may be deferred).
As to claims 3 and 13, Wang discloses a processing circuit or circuitry configured to, for a packet for which some of the geometry processing is deferred until the rendering stage: store in a binning data structure an indicator indicating that geometry processing for the packet has been deferred, and information for performing the deferred geometry processing for the packet (e.g. as noted in claims 1 and 11, [0104] notes providing information that indicates each particular memory buffer that the saved intermediate results will be retrieved from based on matching granularity for a current configuration of the graphics pipeline system, where [0060] notes information specifying, for each primitive, from which buffer the saved results should be fetched or it has to proceed through the full pipeline to reproduce all necessary data, e.g. a 2-bit number for primitives, [0061] notes three types of information including a first type of information specifying, after the binning pass, which primitive(s) will be rendered in the following rendering pass, a second type of information containing intermediate or final results of the primitives and vertices produced in the pipeline during the binning pass, and third type of information specifying, for each primitive, from where the saved information needs to be fetched from).
As to claims 6 and 16, Wang discloses the determination of whether to defer some of the geometry processing for a packet to the rendering stage takes account of the amount of data that would be generated and need to be stored at the rendering stage when performing the deferred geometry processing for the packet (e.g. as noted in claims 1 and 11, determining whether to defer stages of the binning pass to the tile rendering pass may be based on certain criteria, such as implementation cost, complexity, power efficiency and performance, where step 1720, [0098] notes determining an optimal pipeline configuration during a processing phase of the graphics pipeline based on estimating one or more of memory power consumption and computation power consumption for storing and regenerating intermediate results based on graphics state information and one or more factors, and step 1740, [0099] notes determining intermediate results to save from a previous processing pass by comparing memory power consumption to save the intermediate results with computation power as well as memory power needed for regenerating the intermediate results in one or more later tile rendering passes).
As to claims 7 and 17, Wang discloses a render output is divided into a plurality of regions for the purposes of determining whether to defer some of the geometry processing for packets to the rendering stage (e.g. as noted in claims 1 and 11, determining whether to defer stages of the binning pass to the tile rendering pass may be based on certain criteria, such as implementation cost, complexity, power efficiency and performance, where [0049] further notes power efficiency is one of the key goals in mobile GPU design, tile-base architecture is popular in mobile device GPUs due to its power efficiency advantages, in particular in reducing DRAM traffic, thus by dividing the screen space into tiles and rendering the scene tile by tile, depth and color buffers for a tile can be small enough to be stored on-chip, and therefore power consuming DRAM traffic for accessing depth and color data may be avoided).
As to claims 8 and 18, Wang discloses a processing circuit or circuits configured to: divide a render output being generated into a plurality of regions for the purposes of determining whether to defer geometry processing for packets (e.g. as noted in claims 7 and 17, determining whether to defer stages of binning pass to tile rendering pass based on power efficiency and memory consumption, where [0049] notes dividing the screen space into tiles and rendering the scene tile by tile, depth, and color buffers for a tile); and for each region that the render output has been divided into, maintain an estimate of the amount of data to be stored when performing geometry processing that has been deferred to the rendering stage for the region of the render output (step 1720, [0098] notes determining an optimal pipeline configuration during a processing phase of the graphics pipeline based on estimating one or more of memory power consumption and computation power consumption for storing and regenerating intermediate results based on graphics state information and one or more factors); and when the amount of data to be stored when performing geometry processing that has been deferred to the rendering stage for the render output for a region reaches a permitted threshold value, determine not to defer geometry processing of any more packets for the region for the render output (step 1740, [0099] notes determining intermediate results to save from a previous processing pass by comparing memory power consumption to save the intermediate results with computation power as well as memory power needed for regenerating the intermediate results in one or more later tile rendering passes, where the comparison may be considered to be determined against a threshold).
As to claims 10 and 20, Wang discloses a processing circuit or circuits configured to: after the binning stage has generated a binning data structure or structures that can be used to determine whether packets storing data for geometry to be processed should be processed for a rendering tile, for each of a plurality of regions that the render output has been divided into (e.g. after binning pass has generated memory buffers as noted in claims 1 and 11, where [0049] notes dividing the screen space into tiles and rendering the scene tile by tile, depth, and color buffers for a tile): use the binning data structure(s) to identify packets storing data for geometry to be processed that need to be processed for the region of the render output (e.g. identify, via information, which memory buffers have saved intermediate results, further noted below); determine whether any of the packets identified as needing to be processed for the region of the render output require further geometry processing to be performed for them (e.g. determining whether further geometry processing needs to be performed, e.g. in the tile rendering pass, further noted below); for any packets that have been identified as requiring further geometry processing to be performed, trigger the performing of the further geometry processing (e.g. performing further geometry processing in the tile rendering pass on the intermediate results stored in memory buffers)(e.g. as noted in claims 3 and 13, [0104] notes providing information that indicates each particular memory buffer that the saved intermediate results will be retrieved from based on matching granularity for a current configuration of the graphics pipeline system, where [0060] notes information specifying, for each primitive, from which buffer the saved results should be fetched or it has to proceed through the full pipeline to reproduce all necessary data, e.g. a 2-bit number for primitives, [0061] notes three types of information including a first type of information specifying, after the binning pass, which primitive(s) will be rendered in the following rendering pass, a second type of information containing intermediate or final results of the primitives and vertices produced in the pipeline during the binning pass, and third type of information specifying, for each primitive, from where the saved information needs to be fetched from).
Claim(s) 4, 5, 9, 14, 15, and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wang (US 2015/0379672) as applied to claims 1 and 11 above, and further in view of KAKARLAPUDI et al. (WO 2022/084666).
As to claims 4 and 14, Wang do not disclose, but KAKARLAPUDI et al. disclose the processing circuit is configured to determine whether to defer some of the geometry processing for a packet to the rendering stage using a bounding box for a packet; and a bounding box for a packet is determined by one or more of (Figures 5 and 6): triggering position shading to provide appropriately transformed vertex positions for vertices for primitives in the packet to allow a bounding box for the packet to be determined; using information from an application that defines a bounding volume for the packet and a way to transform the bounding volume to derive a bounding box for the packet; and using information that has been generated by a geometry processing stage that has already been executed for the packet (page 35, paragraphs 6-8 notes when a bounding box representation is received by the hypertiling circuit, at step 70, the hypertiling circuit first issues a task for shading the bounding box, e.g. to convert the bounding box from the user space format in which it was initially specified by the application (and hence provided to the graphics processor) into the desired screen space; step 71, a shader core then executes a suitable shader program in order to produce a transformed bounding box; step 72, the hypertiling circuit can then read the transformed bounding boxes in order to perform the hypertiling/sorting operation, as part of this, the hypertile circuit can initially check whether any of the geometry can be discarded at this stage (pre-culled), e.g. by checking whether the bounding box representation falls entirely outside of a desired view frustum, and if the bounding box representation falls entirely outside of a desired view frustum, at step 73, the geometry can be discarded without any further processing; on the other hand, if the geometry cannot be discarded, at step 74, the hypertiling operation is then performed to sort the geometry into the respective hypertiles, and to thereby generate the hypertile lists).
It would have been obvious to one of ordinary skill in the art at the time of the invention to further modify Wang’s system and method of deferring geometry processing to incorporate KAKARLAPUDI et al.’s method of using bounding boxes to determine whether any of the geometry may be discard, e.g. by checking the bounding box representations to further determine if geometry processing may be deferred, to further save the graphics processor from performing all geometry-related processing up-front, which may reduce overall latencies in the system (page 9 last paragraph continued to page 10, second paragraph of KAKARLAPUDI et al.).
As to claims 5 and 15, Wang do not disclose, but KAKARLAPUDI et al. disclose geometry processing for a packet is not deferred when a bounding box for a packet is larger than a threshold size (pages 21 and 22, paragraphs 5-6 notes the graphics processor is operable to perform different sorting operations, e.g. for different sets of geometry, thus when a new set of geometry is received to be processed, the method may further comprise first checking whether or not the set of geometry should be processed in the manner described above (e.g. by performing the “hypertiling” operation, and if so, proceeding to do so), where various options would be possible in this regard, e.g. in a tile-based graphics processor at least, sets of geometry could be added to such hypertile lists in the case where the position representation, e.g. bounding box, for the set of geometry falls entirely within a single hypertile/sorting region of the render output (e.g. considered smaller than a threshold size), but in the case where the bounding box for a set of geometry falls into more than one hypertile/sorting region of the render output (e.g. considered larger than a threshold size), then for that set of geometry a conventional tiling process could be performed instead, where the positions for the actual vertices of the geometry in question are fetched by the graphics processor, transformed to screen space, and then the geometry in the set of geometry is sorted into tile lists for the “rendering tiles” (as opposed to the hypertiles)(e.g. the “conventional tiling process” considered “not to defer geometry processing”)). See the rationale to combine of claims 4 and 14 above.
As to claims 9 and 19, Wang discloses a processing circuit or circuits configured to: divide a render output being generated into a plurality of regions for the purposes of determining whether to defer geometry processing for packets (e.g. as noted in claims 7 and 17, determining whether to defer stages of binning pass to tile rendering pass based on power efficiency and memory consumption, where [0049] notes dividing the screen space into tiles and rendering the scene tile by tile, depth, and color buffers for a tile), where KAKARLAPUDI et al. further disclose divide a render output being generated into a plurality of regions for the purposes of determining whether to defer geometry processing for packets; and when a bounding box for a packet extends over plural of the regions that the render output has been divided into for the purposes of considering whether to defer geometry processing for packets, determine not to defer geometry processing for the packet (pages 21 and 22, paragraphs 5-6 notes the graphics processor is operable to perform different sorting operations, e.g. for different sets of geometry, thus when a new set of geometry is received to be processed, the method may further comprise first checking whether or not the set of geometry should be processed in the manner described above (e.g. by performing the “hypertiling” operation, and if so, proceeding to do so), where various options would be possible in this regard, e.g. in a tile-based graphics processor at least, sets of geometry could be added to such hypertile lists in the case where the position representation, e.g. bounding box, for the set of geometry falls entirely within a single hypertile/sorting region of the render output (e.g. considered smaller than a threshold size), but in the case where the bounding box for a set of geometry falls into more than one hypertile/sorting region of the render output (e.g. considered larger than a threshold size), then for that set of geometry a conventional tiling process could be performed instead, where the positions for the actual vertices of the geometry in question are fetched by the graphics processor, transformed to screen space, and then the geometry in the set of geometry is sorted into tile lists for the “rendering tiles” (as opposed to the hypertiles)(e.g. the “conventional tiling process” considered “not to defer geometry processing”)). See the rationale to combine of claims 4 and 14 above.
Response to Arguments
Applicant’s arguments, see page 9, filed February 9, 2026, with respect to the title have been fully considered and are persuasive. Applicant amends the title of the present application. Therefore, the objection to the specification with regards to the title has been withdrawn.
Applicant's arguments filed February 9, 2026 have been fully considered but they are not persuasive. Applicant argues on pages 9-11 of the Amendment filed that the prior art of record, Wang, fails to teach or suggest the limitations of independent claims 1 and 11 as recited, more specifically, “…determine, for a packet, whether to defer some of the geometry processing of the
sequence of one or more geometry processing stages of the graphics processing pipeline
being executed until the rendering stage; when it is determined to defer some of the
geometry processing for a packet to the rendering stage, associate with the packet an
indication that further geometry processing should be performed for the packet at the
rendering stage; and when it is other than determined to defer geometry processing for the
packet to the rendering stage, trigger the performing of all of the sequence of one or more
geometry processing stages for the graphics processing pipeline being executed for the
packet before providing the packet to the binning stage…” Applicant further argues, “…In the system of Wang, a decision is made as to whether the output at each stage of the early geometry processing stages is stored into memory, or whether it is discarded at the binning stage. If the output of an early processing stage is discarded then that processing step is repeated in the later geometry processing stages…since its output was not stored and so cannot be reused. The decision between storing data or repeating the processing step allows a decision to be made as to whether to make greater use of memory or processing power…The decision made in Wang is thus not whether certain geometry processing steps are deferred or not, but rather whether the outputs of the early steps are retained in memory or not (in which case the steps are repeated instead). In Wang there are no geometry processing steps which are sometimes done, and sometimes not done, before binning (i.e. no steps which are conditionally or optionally deferred, sometimes being carried out before binning and other times only after). Instead, Wang teaches optionally not repeating some steps in the tile rendering phase if the result of the same step from before binning has been retained in memory and can be reused but teaches always doing the same set of steps before the binning stage…In Wang, the decision which is made thus does not relate to deferring some geometry processing but is rather whether to store outputs of certain early processing stages, or repeat these stages at the rendering stage. In all three of the possible scenarios described in Wang, a certain set of fixed, predetermined stages always take place before the binning stage…” (second through fourth paragraphs of page 10 continued to page 11 of the Amendment filed).
In reply, as outlined in the rejection above, in Figure 5, Wang describes a tile-based deferred rendering (TBDR) pipeline including a binning pass 405 and a tile rendering pass 406. The binning pass 405 includes stages (“geometry processing stages”) such as an input assembler unit (IA) 311, various shader stages 410 to 412, and a cull, clip, viewport (CCV) 313 with respective buffers 420-423, as well as a binning stage 315 while the tile rendering pass 406 (“rendering stage”) further includes an input assembler unit (IA) 311, various shader stages 410 to 412, a cull, clip, viewport (CCV) 313, and additional rendering stages 430. Referring to the associated text of Figure 5, [0054] and [0055], Wang discloses that the TBDR pipeline may be modified in order to choose to save arbitrary information, e.g. intermediate results produced at any point in the middle of the binning pass 405, and consume that in the tile rendering pass 406. This means the TBDR pipeline may execute as normal, where all stages of the binning pass 405 execute sequentially (e.g. no deferring), or the TBDR pipeline may be modified where only a portion of the binning pass 405 may be executed up to a certain point, e.g. less than all stages of the binning pass are executed, where the result(s) that have already been produced by those executed stage(s) of the binning pass 405 are stored in one of respective buffers 420-423, which, in turn, are picked up by the next corresponding stage in the tile rendering pass 406, where processing continues using the stored result(s) from the binning pass 405 (e.g. deferring). Because the TBDR pipeline may stop at any stage in the binning pass 405 (e.g. not all of the stages of the binning pass are executed), and the processing continues in the tile rendering pass 406, this is considered “…deferring some of the geometry stages…until the rendering stage…” Wang further discloses this modification of the TBDR pipeline is performed by a graphics processing unit (GPU) (“processing circuit”) which determines whether to save the information in the binning pass or to reproduce it in the tile rendering pass, based on certain criteria, such as implementation cost, complexity, power efficiency, and performance. In other words, based on the certain criteria noted above, the GPU may determine that the TBDR pipeline should execute as normal, where all stages of the binning pass 405 execute sequentially with the final stage as the binning stage 315, and the results are then forward to the tile rendering pass 406 OR the GPU may determine to modify the TBDR pipeline to stop execution at a particular stage in the binning pass 405, save the result(s) of the executed stage(s) in a respective buffer, and forward those result(s) to the tile rendering pass 406 to pick up processing where the binning pass 405 left off, thus considered to “…determine…whether to defer some of the geometry processing of the sequence of one or more geometry processing stages of the graphics processing pipeline being executed until the rendering stage…” The determination process is further outlined in Figure 17, [0097] thru [0104], of Wang, which further describes when it is determined to modify the TBDR pipeline, e.g. stop processing at a particular stage of the binning pass 405, save the result(s) in a respective buffer, and forward the result(s) to the tile rendering pass 406 (“when it is determined to defer some of the geometry processing for a packet to the rendering stage”), further providing additional information (e.g. “associate with the packet an indication”) that indicates each particular buffer that the result(s) will be retrieved for the tile rendering pass (“that further geometry processing should be performed for the packet at the rendering stage”). In contrast, when it is determined not to modify the TBDR pipeline (“when it is other than determined to defer geometry processing for a packet to the rendering stage”), all stages of the binning pass 405 are executed as normal (“trigger the performing of all of the sequence of one or more geometry processing stages for the graphics processing pipeline being executed for the packet before providing the packet to the binning stage”). Therefore, for these reasons, it is believed that Wang teaches the limitations of the claims as recited.
Applicant further argues on page 11 of the Amendment filed that “…Wang fails to disclose these steps because no determination is made of whether to defer geometry processing (since it does not teach deferment of any geometry processing steps in the claimed manner), and, furthermore clearly no indication is associated with a packet for which some geometry process is deferred…Furthermore, there is no teaching in Wang of making any processing decision in relation specifically to “packets”, i.e. per-packet, where these packets are generated by early geometry processing stages and each store data for geometry to be processed. In contrast, Wang appears to teach making the decision on storing data or repeating processing on a per-frame or per-primitive basis, as described in paragraph [0060]…” (second and third paragraphs of page 11 of the Amendment filed).
In reply, independent claims 1 and 11 similarly recite, “…the geometry processing stage or stages of the graphics processing pipeline generate respective packets for processing, each packet storing data for geometry to be processed…” which defines a “packet.” As outlined in the rejection above and as noted in the Examiner’s response to arguments above, Wang describes the binning pass 405 of TBDR pipeline includes geometry stages such as an input assembler unit (IA) 311, various shader stages 410 to 412, and a cull, clip, viewport (CCV) 313 with respective buffers 420-423 as well as a binning stage 315. The TBDR pipeline may execute as normal where all stages of the binning pass 405 executes sequentially or the TBDR pipeline may be modified to “defer” one or more stages of the binning pass 405 to the tile rendering pass 406 by saving arbitrary information, e.g. intermediate results produced at any point in the middle of the binning pass pipeline, and consume that in the tile rendering pass. Thus, each stage of the binning pass 405 may generate intermediate results, which are used for additional processing, e.g. either by a next stage of the binning pass 405 or a next corresponding stage of the tile rendering pass 406. Therefore, based on this “definition” of a “packet,” the Examiner appropriately considers such intermediate results generated as a “packet” as the intermediate results are generated by one or more stages of binning pass 405 which may be further considered “stored” data from previous stages and/or a respective stage which is “to be processed” by a next stage. The intermediate results, e.g. a packet, may be from a single stage or collective stages of the binning pass as each stage may pass intermediate results to a next stage to be consumed to generate respective intermediate results, based on whether or not the TBDR pipeline is modified and at what stage the TBDR pipeline is modified as described. Therefore, for these reasons and the reasons noted in the Examiner’s response above, Wang teaches the limitations of the claims as recited.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 JACINTA M CRAWFORD whose telephone number is (571)270-1539. The examiner can normally be reached 8:30a.m. to 4:30p.m.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, King Y. Poon can be reached at (571)272-7440. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JACINTA M CRAWFORD/Primary Examiner, Art Unit 2617