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 .
Examiner’s Note
The prior art rejection below cites particular paragraphs, columns, and/or line numbers in the references for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art.
Claims 1 – 23 are pending for examination. Claims 1 – 2, 14, 20 – 21 and 23 are amended.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1 – 23 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claim 1, lines 14 – 15, limitation “in response to determining” that makes the denial message a contingent limitation. The limitation needs to separate “determining” step before the “in response to determining”.
As to claims 2 – 13, they are rejected as their independent claim.
As to claim 14, lines 14 – 15, limitation “in response to determining” that makes the denial message a contingent limitation. The limitation needs to separate “determining” step before the “in response to determining”.
As to claim 15,.at the end of the claim, needs to include limitation “read from the local memory within the second processing tile” (similar to claim 2). Otherwise, presenting any type of data within a denial message can be interpreted as “data needed for computation” (e.g. an error message that identifies the error conditions/reasons can be interpreted as identifying error correction data which is “data needed for the computation”).
As to claims 16 – 20, they are rejected as to their independent claim.
As to claim 21, the claim recites “the method comprising: a first processing unit of the plurality generating”. The method needs to comprise steps (not the first processing unit) and “the plurality” by itself is not clear. The limitation should rewrite – generating, by a first processing unit of the plurality of DRAM-based parallel processing units, an offload request—.
The claim 21 also recites “if the second processing unit or the offload unit determines” which again presents a contingent limitation and needs to be fixed before it can be allowed.
Furthermore, claim 21 needs to recite “read from the local memory within the second processing tile” (similar to claim 2) after limitation “data needed for the computation”..
As to claims 22 - 23, they are rejected as to their independent claim.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 3-7, 14, and 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux (“Remote Processor Messaging (rpmsg) Framework”, 09-2020).
As to claim 1, Putnam teaches a method, comprising (see section 4.1, [page 3 col 2 paragraph 6]-[page 4 col 2 paragraph 2]; the method is two runs of the execution pipeline shown [page 4 col 1 paragraph 2], where "generating" starts at "4. Execute" stage in the first pass through the pipeline, "transmitting" is the "5. Output" stage, and then evaluating congestion criteria... and transmitting a denial message... is the "1. Input" stage of the second pass through the pipeline):
generating, by a first processing tile in a topology including processing tiles, an offload request for [remote] execution of a computation at a second processing tile computation (4. Execute: An instruction executes. Its result goes to the output queue, [page 4 col 1 paragraph 2 bullet 4]; where these are the five pipe stages of a PE, [page 4 col 1 paragraph 2 line 1]; and a PE (processing element) is a tile part of a large topology of processing elements as shown in FIG. 2 with a specific example in FIG. 1, [page 4] ), [the offload request including at least a program counter defining a location within a program at which execution of the computation begins and a destination location within the second processing tile for storing a result of the computation], wherein each processing tile includes one or more processing units that are each directly coupled to a local memory of a total memory (Each PE contains a functional unit, specialized memories to hold operands, and logic to control instruction execution and communication, [page 3 col 1 paragraph 4 lines 1-3]; a spec of the “total memory” is provided in Table 1, [page 4]) and the processing tile is indirectly coupled to the local memories included within each of the remaining processing tiles (see the right panel of FIG. 1, showing data from one processing element can be passed to another processing element "indirectly", [page 4]; Table 1 gives details of the microarchitecture such as the capacity for instructions stored in each PE, the input queue capacity, and the output queue capacity, and the last column of Table 1 describes the "network latency", which shows how many cycles it takes a PE to "offload" from one PE to another PE, [page 4]);
transmitting the offload request from the first processing tile to a second processing tile (5. OUTPUT: Instruction outputs are sent via the output bus to their consumer instructions, ... a remote PE, [page 4 col 1 paragraph 2 bullet 5]), wherein data needed for the computation is stored in the local memory within the second processing tile (an example is shown in the right most panel of FIG. 1, the result of the Shift Left #2 instruction is sitting in the PE in the last column on the right in the second row of PEs, and this PE is waiting for the result of the Mul #2 operation from the left neighboring PE, [page 4]; the actual location in local memory is the matching table; for more details see cycle 0 and cycle 1 in FIG. 4, showing A[1] sitting in the matching table, while A[0] queues up, [page 5]);
evaluating congestion criteria by the second processing tile (INPUT: Operand messages arrive at the PE either from another PE or from itself. The PE may reject messages if too many arrive in one cycle; the senders will then retry on a later cycle, [page 4 col 1 paragraph 2 bullet 1]; the congestion criteria is qualitatively described as "too many", but further details are given later, "INPUT will accept inputs from up to four of these busses each cycle. If more than four arrive during one cycle, an arbiter selects among them, [page 5 col 1 paragraph 1 lines 1-3]); and
in response to determining that the second processing tile is congested, transmitting a denial message from the second processing tile to the first processing tile (INPUT: Operand messages arrive at the PE either from another PE or from itself. The PE may reject messages if too many arrive in one cycle; the senders will then retry on a later cycle, [page 4 col 1 paragraph 2 bullet 1]; rejecting messages is transmitting a denial message; further details are given later, described with respect to the first processing tile, "It is possible, however, that the consumer cannot handle the value that cycle and will reject it. ACK/NACK signals require four cycles for the round trip", [page 7 col 2 paragraph 3 lines 3-5]; here the "round trip" means the result is output from the first PE to the second PE, and an ACK/NACK signal is given response, from the second PE back to the first PE, where "reject" would specifically mean a NACK signal is given in response.).
Putnam does not but Linux teaches remote and the offload request (“…offload CPU-intensive multimedia tasks from the main application processor…” page 1 Introduction, para. 3) including at least a program counter defining a location within a program at which execution of the computation begins and a destination location within the second processing tile for storing a result of the computation (Every rpmsg device is a communication channel with a remote processor (thus rpmsg devices are calledchannels). Channels are identified by a textual name and have a local (“source”) rpmsg address, and remote (“destination”) rpmsg address “ page 1 Introduction last para.).
It 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 was made to modify Putnam by applying the teachings of Linux because Linux would provide source and destination address when make a call/request so it is dispatched to a correct location (page 1 – 2).
With respect to claim 3, Putnam teaches all of the limitations of claim 1, as noted above. Putnam further teaches wherein the offload request includes source data needed for the computation (called an “operand message” because the request includes the “operand” meaning the input needed for the operation/computation, [page 4 col 1 paragraph 2 bullet 1]; more detail about the additional tags provided at [page 5 col 1 paragraph 2]).
With respect to claim 4, Putnam teaches all of the limitations of claim 1, as noted above. Putnam further teaches wherein each local memory comprises a memory stack that is aligned with the one or more processing units in either a vertical or horizontal direction (FIG. 9 shows an architecture with local memory horizontally aligned with one or more PEs, [page 9]).
With respect to claim 5, Putnam teaches all of the limitations of claim 1, as noted above. Putnam further teaches wherein the congestion criteria include a measure of at least one of a processing workload, a processing resource availability, and an offload request buffer capacity (INPUT: Operand messages arrive at the PE either from another PE or from itself. The PE may reject messages if too many arrive in one cycle; the senders will then retry on a later cycle, [page 4 col 1 paragraph 2 bullet 1]; “too many” corresponds with buffer capacity; processing workload and processing resource availability are also discussed with respect to the matching table, which are called “matching table misses”, [page 5 col 2 paragraph 2]).
With respect to claim 6, Putnam teaches all of the limitations of claim 1, as noted above. Putnam further teaches retransmitting the offload request from the first processing tile to the second processing tile (Operand messages arrive at the PE either from another PE or from itself. The PE may reject messages if too many arrive in one cycle; the senders will then retry on a later cycle, [page 4 col 1 paragraph 2 bullet 1]; see specifically “retry”).
With respect to claim 7, Putnam teaches all of the limitations of claim 6, as noted above. Putnam further teaches evaluating the congestion criteria by the second processing tile; and in response to determining that the second processing tile is not congested, executing the computation by the second processing tile (Operand messages arrive at the PE either from another PE or from itself. The PE may reject messages if too many arrive in one cycle; the senders will then retry on a later cycle, [page 4 col 1 paragraph 2 bullet 1]; see specifically “retry”; “retry” means the entire pipeline is repeated until the Ack signal is received, see “After several retries, operands resident in the matching table are evicted to memory, and the newly empty line is allocated to the new operand”, [page 5 col 2 paragraph 2 lines 10-12]).
With respect to claim 14, Putnam teaches A system, comprising a plurality of processing tiles in a topology (see processing elements in a topology in Fig. 2, [page 4]), wherein each processing tile includes one or more processing units that are each directly coupled to a local memory of a total memory (Each PE contains a functional unit, specialized memories to hold operands, and logic to control instruction execution and communication, [page 3 col 1 paragraph 4 lines 1-3]) and the processing tile is indirectly coupled to the local memories that are included within each of the remaining processing tiles, and the plurality of processing tiles are configured to: (see the right panel of FIG. 1, showing data from one processing element can be passed to another processing element "indirectly", [page 4]; Table 1 gives details of the microarchitecture such as the capacity for instructions stored in each PE, the input queue capacity, and the output queue capacity, and the last column of Table 1 describes the "network latency", which shows how many cycles it takes a PE to "offload" from one PE to another PE, [page 4]).
Regarding the rest of claim 14, incorporating the rejection of claim 1, claim 14 is rejected for a substantially similar rationale.
With respect to claim 16, incorporating the rejection of claim 3 and claim 14, claim 16 is rejected for a substantially similar rationale.
With respect to claim 17, incorporating the rejection of claim 4 and claim 14, claim 17 is rejected for a substantially similar rationale.
With respect to claim 18, incorporating the rejection of claim 5 and claim 14, claim 18 is rejected for a substantially similar rationale.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux and further in view of US 11,010,297 B2 (Hansson)
With respect to claim 9, Putnam modified by Linux teaches all of the limitations of claim 1, as noted above. Putnam and Linux do not teach wherein in response to receiving the denial message, the first processing tile executes the computation.
However, Hansson teaches wherein in response to receiving the denial message, the first processing tile executes the computation The upstream memory unit will be waiting at step 920 for the Ack/NAck signal, and when the NAck signal is received, it will not only update its downstream capabilities register at step 922 to identify that there are no downstream memory units capable of performing the operation, but will also evaluate whether it is capable of performing the operation. If it can perform the operation, then it will perform the operation locally using the data that has been returned from the last level memory unit, and thereafter will propagate an Ack signal upstream, [col 11 ln 26-35]).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam, Linux with Hansson because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam discloses a system and method that teaches all of the claimed features except for sending data with the NAck signal. Hansson teaches why this is process is beneficial:
The upstream memory unit will be waiting at step 920 for the Ack/NAck signal, and when the NAck signal is received, it will not only update its downstream capabilities register at step 922 to identify that there are no downstream memory units capable of performing the operation, but will also evaluate whether it is capable of performing the operation. If it can perform the operation, then it will perform the operation locally using the data that has been returned from the last level memory unit, and thereafter will propagate an Ack signal upstream.
(Hansson [col 11 ln 26-35]).
... which will result at some point in the operation being performed by the first upstream memory that is capable of performing that operation.
(Hansson [col 11 ln 40-42]).
The NAck signal indicates that the downstream memory units are not capable of executing the instruction, so this algorithm ensures that the first upstream memory unit that is capable of performing the operation has the data to perform the operation. A person having skill in the art would have a reasonable expectation of having operations execute as quickly as possible in the system and method of Putnam by modifying Putnam with the data transfer along with the NAck signal of Hansson. Therefore, it would have been obvious to combine Putnam with Hansson to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
Claim(s) 8 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux, and further in view of US 2014/0301241 A1 (Kumar).
With respect to claim 8, Putnam modified by Linux teaches all of the limitations of claim 1, as noted above. Putnam and Linux do not teach determining that a distance between the first processing tile and the second processing tile exceeds an offload threshold.
However, Kumar teaches determining that a distance between the first processing tile and the second processing tile exceeds an offload threshold (referred to as latency constraints/requirements in the art, see [0044] lines 1-27; for background see: “Shortest path routing may minimize the latency as Such routing reduces the number of hops from the source to the destination. For this reason, the shortest path may also be the lowest power path for communication between the two components, [0008] lines 8-12; for a description of how distance/latency is calculated in “hops” see FIG. 5(a); and for teaching the threshold: “For a route to be eligible the number of already existing router hops along the route in the layer and the number of new routers that must be instantiated when this flow will be mapped must be smaller than the latency requirement of the flow.”, [0044] lines 19-24).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam, Linux with Kumar because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam already discloses a system and method that teaches all of the claimed features as well as the requirements for an instruction mapping algorithm: “instruction mapping algorithm (which maps dynamically as the program executes) are to place dependent instructions near each other to minimize producer-consumer latency, and to spread independent instructions out in order to utilize resources and exploit parallelism”, (Putnam [page 3 col 1 paragraph 4 lines 10-14]). Putnam focuses on the microarchitecture rather than the routing algorithm. Kumar goes into detail on latency/routing issues, (Kumar [0008]), and further explains:
Different topologies may provide different latency characteristics and number of hops between various components providing routes between components that have different latencies. Thus, traffic flows may be mapped to the topologies based on their latency requirements.
(Kumar [0039] lines 12-17).
A person having skill in the art would have a reasonable expectation of successfully routing instructions “near each other to minimize producer-consumer latency” in the system and method Putnam by modifying Putnam with the latency requirements of Kumar. Therefore, it would have been obvious to combine Putnam with Kumar to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 19, incorporating the rejection of claim 8 and claim 14, claim 19 is rejected for a substantially similar rationale.
Claim(s) 10 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux, and further in view of “Hardware-Accelerated Multi-Tile Streaming for Realtime Remote Visualization” (2018-Biedert).
With respect to claim 10, Putnam teaches all of claim 1, as noted above. Putnam and Linux do not teach wherein at least one of the steps of generating, transmitting, or evaluating is performed on a server or in a data center to generate an image, and the image is streamed to a user device.
However, Biedert teaches wherein at least one of the steps of generating, transmitting, or evaluating is performed on a server or in a data center to generate an image, and the image is streamed to a user device (in FIG. 1, see the vertical columns showing the buffer and encode stages in the HPC system, the lateral rows show the parallel processing pipeline; the following passage describes how the image is processed in parallel, “For instance, a server application could split the framebuffer into two tiles and use two concurrent pipelines to better utilize the available hardware encoding units. A similar approach can be employed at client-side, either to decode and display full frames to distinct monitors, or composite partial tiles of a single display, [page 35 col 2 paragraph 2 lines 18-23]).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam, LInux with Biedert because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam discloses a system and method that teaches all of the claimed features except for a particular application (image processing) using server-client infrastructure for the application. Biedert teaches hardware-accelerated multi-tile streaming which is a parallel processing technique similar to WaveScalar applied to this application (i.e., see “Visualization” in the Title of Biedert) using the server-client infrastructure (i.e., “Realtime Remote” in the Title of Biedert). Biedert goes on to explain why such a use case is important:
Being able to drive high-resolution displays directly from a remote supercomputer opens up novel use cases. In particular, it enables cheaper infrastructure at the client’s side, as all the heavy lifting is done on the server side.
(Biedert [page 33 col 1 paragraph 3 lines 1-4]).
A person having skill in the art would have a reasonable expectation of successfully applying the hardware accelerated microarchitecture in the system and method of Putnam and Linux to the Application area of Remote Visualization as in Biedert by modifying Putnam and Linux with the client-server infrastructure of the image visualization application of Biedert. Therefore, it would have been obvious to combine Putnam, Linux with Biedert to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 20, incorporating the rejection of claim 10 and claim 14, claim 20 is rejected for a substantially similar rationale.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux, and further in view of “A Survey of Coarse-Grained Reconfigurable Architecture and Design: Taxonomy, Challenges, and Applications” (2019-Liu)
With respect to claim 11, Putnam modified by Linux teaches all of claim 1, as noted above. Putnam and Linux do not teach wherein at least one of the steps of generating, transmitting, or evaluating is performed within a cloud computing environment.
However, Liu teaches wherein at least one of the steps of generating, transmitting, or evaluating is performed within a cloud computing environment (table 2 gives a list of architectures classified as CRGAs, where row 7 is wavescalar, [page 13]; section 2.4 gives a list of applications particularly suited for CRGAs including signal and image processing, [page 14 paragraph 3]; and deep learning with DNNs, [page 14 paragraph 4]; Section 4.4 describes the “memory wall” problem as it applies to cloud servers, [page 28 paragraph 3 line 7]; and how the hardware solutions include “3D-stacked Dram, [page 28 paragraph 5 line 3] or integrating computation components in memory, [page 28 paragraph 6 line 10]; finally, FIG. 11 provides “killer applications” meaning applications that are particular suitable for CRGAs, particularly, “A comparison with Figure 11(a) indicates that CGRAs well match the scenarios on the top right, such as datacenters, the mobile end, cloud servers and robotics).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam and Linux with Liu because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam discloses a system and method that teaches all of the claimed features except for applying the microarchitecture on a cloud server. Liu teaches that certain features like energy efficiency and flexibility of programming of these microarchitectures make them uniquely suited for certain applications like Data Centers and cloud servers (see Fig. 11, Liu [page 31]). A person having skill in the art would have a reasonable expectation of successfully applying the microarchitecture of Putnam and Linux to the applications disclosed in Liu by modifying Putnam with the potential applications of Liu. Therefore, it would have been obvious to combine Putnam with Liu to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
With respect to claim 12, Putnam teaches all of claim 1, as noted above. Putnam and Linux do not teach wherein the computation is executed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle.
However, Liu teaches wherein the computation is executed for training, testing, or certifying a neural network employed in a machine, robot, or autonomous vehicle (table 2 gives a list of architectures classified as CRGAs, where row 7 is wavescalar, [page 13]; section 2.4 gives a list of applications particularly suited for CRGAs including signal and image processing, [page 14 paragraph 3]; and deep learning with DNNs, [page 14 paragraph 4]; specifically, “CGRAs are capable of high-throughput computation and on-chip communication, making them a superior implementation for DNNs, [page 14 paragraph 4 lines 4-5] where DNNs refer to learning/training a specific type of neural network with many layers; Section 4.4 describes the “memory wall” problem as it applies to cloud servers, [page 28 paragraph 3 line 7]; and how the hardware solutions include “3D-stacked Dram, [page 28 paragraph 5 line 3] or integrating computation components in memory, [page 28 paragraph 6 line 10]; finally, FIG. 11 provides “killer applications” meaning applications that are particular suitable for CRGAs, particularly, “A comparison with Figure 11(a) indicates that CGRAs well match the scenarios on the top right, such as datacenters, the mobile end, cloud servers and robotics).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam and Linux with Liu because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam discloses a system and method that teaches all of the claimed features except for applying the microarchitecture on a robotics. Liu teaches that certain features like energy efficiency and flexibility of programming of these microarchitectures make them uniquely suited for certain applications like robotics (see Fig. 11, Liu [page 31]). A person having skill in the art would have a reasonable expectation of successfully applying the microarchitecture of Putnam and Linux to the applications disclosed in Liu by modifying Putnam with the potential applications of Liu. Therefore, it would have been obvious to combine Putnam, Linx with Liu to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
Claim(s) 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over “The Microarchitecture of a Pipelined WaveScalar Processor: An RTL-based Study” (2005-Putnam) in view of Linux, and further in view of “GPU Virtualization and Scheduling Methods: A Comprehensive Survey” (2017-Hong)
With respect to claim 13, Putnam teaches all of claim 1, as noted above. Putnam and Linux do not teach wherein at least one of the steps of generating, transmitting, or evaluating is performed on a virtual machine comprising a portion of a graphics processing unit.
However, Hong teaches wherein at least one of the steps of generating, transmitting, or evaluating (GPU scheduling methods, [Abstract] line 9]; see specifically section 7.3 Load Balancing, [page 25 paragraph 3]-[page 26 paragraph 3]; load balancing is a method of generating a task, transmitting the task, and evaluating congestion, for specific examples see specifically performance history method, [page 25 paragraph 3 lines 10-14]; dataflow programming method, [page 25 paragraph 4 lines 17-21]; and the work-stealing algorithm, [page 26 paragraph 3]) is performed on a virtual machine comprising a portion of a graphics processing unit (see FIG. 3 where the light blue “para & full virtualization stack” represent the virtual machine and the GPU is the GPU, [page 14]; see also FIG. 4 with a slightly different configuration, [page 17]; note the scheduling methods taught by section 7 are an overview of GPU scheduling, but are introduced with the intent to address challenges in GPU virtualization, [page 19 paragraph 5]-[page 20 paragraph 1]).
It would have been obvious to one skilled in the art before the effective filing date to combine Putnam, Linux with Hong because a teaching, suggestion, or motivation in the prior art would have led one skilled in the art to combine prior art teaching to arrive at the claimed invention. Putnam discloses a system that teaches all of the claimed features except for GPU virtualization. Hong teaches the same basic microarchitecture but applied to a GPU, (see FIG. 1 of Hong, [page 3]) and notes the benefits of why this architecture is being adopted by cloud providers:
Cloud computing platforms can leverage heterogeneous compute nodes to reduce the total cost of ownership and achieve higher performance and energy efficiency [Crago et al. 2011; Schadt et al. 2011]. A cloud with heterogeneous compute nodes would allow users to deploy computationally intensive applications without the need to acquire and maintain large-scale clusters. In addition to this benefit, heterogeneous computing can offer better performance within the same power budget compared to systems based on homogeneous processors, as computational tasks can be placed on either conventional processors or GPUs depending on the degree of parallelism. These combined benefits have been motivating cloud service providers to equip their offerings with GPUs and heterogeneous programming environments...
(Hong [page 2 paragraph 2]).
A person having skill in the art would have a reasonable expectation of getting the benefit of the GPU virtualization in the system and method of Putnam by modifying Putnam and Linux with the heterogeneous compute described by Hong. Therefore, it would have been obvious to combine Putnam, Linux with Hong to a person having ordinary skill in the art, and this claim is rejected under 35 U.S.C. 103.
Allowable Subject Matter
Claims 21 – 23 are allowed if they are overcome 112(b).
Claims 2 and 15 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 and overcome 112(b).
Response to Arguments
Drawing and Specification Objections (pages 14 – 15 of remark)
Applicant’s arguments, with respect to the Drawing and Specification Objections have been fully considered and are persuasive. Therefore, the objections are withdrawn.
Claim Objections
Applicant’s arguments, with respect to Claim Objections have been fully considered and are persuasive. The Claim Objections has been withdrawn.
Rejections under 35 U.S.C. § 102
Applicant’s arguments, with respect to the rejections of claim(s) 1 under 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Putnam and Linux.
Applicant argued
“As amended, claim 1 recites that the offload request is an offload request for
remote execution of a computation and includes, among other things, a program counter defining a location within a program at which execution of the computation begins and a destination location within the second processing tile for storing a result of the computation. The specification describes such an offload request as an interconnect offload packet. See Specification at paragraphs [0020] and [0038]. These amendments clarify the claimed offload-request and denial-message protocol and distinguish it from Putnam's dataflow operand delivery.
The Office Action's mapping does not disclose the amended offload request. The Office Action identifies Putnam's EXECUTE stage as "generating" the alleged request and Putnam's OUTPUT stage as "transmitting" the alleged request. But, under that mapping, the item being generated and transmitted is the result of an already-executed instruction, sent as an operand or value to one or more consumer instructions. That item is not a request for the receiving PE to begin execution of an offloaded computation at a program counter defined location, and it does not carry a destination location within the receiving tile for storing the result of that offloaded computation. The amended claim language therefore removes any ambiguity between a dataflow operand/result message and the claimed computation offload request.
Putnam's own description confirms the distinction. Putnam describes its PE
pipeline as "entirely data-driven" and explains that "[i]nstead of executing instructions provided by a program counter," values arrive at a PE destined for a particular instruction and trigger execution. See Putnam at § 4.1. Thus, Putnam's received value may be associated with a destination instruction in Putnam's dataflow graph, but it is not an offload request that includes a program counter defining a location within a program at which execution of an offloaded computation begins. Putnam's dataflow execution model therefore does not disclose the amended program-counter limitation, either expressly or inherently.
Putnam also fails to disclose the recited destination location. The amended claims do not merely require that a message identify a consumer instruction or route a value through an interconnect. They require that the offload request include a destination location within the second processing tile for storing a result of the remotely executed computation. The Office Action identifies Putnam's OUTPUT stage and consumer- instruction delivery as the alleged transmission, but those disclosures concern routing instruction outputs in a dataflow graph. They do not disclose an offload request carrying a destination storage location within the receiving tile where the result of the offloaded computation will be stored.
Putnam's ACK/NACK disclosure also does not supply the missing limitations. The Office Action relies on Putnam's disclosure that a PE may reject operand messages if too many arrive in one cycle and that a sender may retry on a later cycle. That rejection is flow control for delivery of an operand value. It is not a denial of a request for remote execution of a computation, and it is not responsive to a request that includes a program counter defining where execution of the computation begins and a destination location for storing the result. Putnam's NACK merely indicates that a consumer PE could not accept a value in a particular cycle; it does not indicate that the receiving tile evaluated and denied a computation offload request having the control and destination fields now recited in the independent claims.
Because Putnam does not disclose each and every element of amended claim 1, the anticipation rejection of claim 1 is improper. Applicant respectfully requests withdrawal of the § 102 rejection of claim 1 and of claims 3-7 depending therefrom. Independent claim 14 has been amended to recite corresponding system limitations. In particular, claim 14 recites that the plurality of processing tiles are configured to generate an offload request for remote execution of a computation at a second processing tile, where the offload request includes at least a program counter defining a location within a program at which execution of the computation begins and a destination location within the second processing tile for storing a result of the computation. The Office Action rejects claim 14 based on a rationale substantially similar to claim 1. For the same reasons discussed above, Putnam does not disclose the amended offload-request limitations of claim 14 and therefore does not anticipate claim 14 or claims 16-18 depending therefrom” (pages 15 - 17 of remark).
In response,
Linux teaches amended limitation of making offload request to remote processor, wherein the request/message include local/source address and remote/destination address (pages 1 – 2) as rejected above.
Therefore, it is combination of Putnam and Linux teaches claim 1 and Linux teaches remote execution of a computation and includes, among other things, a program counter defining a location within a program at which execution of the computation begins and a destination location within the second processing tile for storing a result of the computation.”
Rejections under 35 U.S.C. § 103
Applicant’s arguments, with respect to claims 21 – 23 have been fully considered and are persuasive. The rejection has been withdrawn.
Applicant argued
With respect to claims 11 and 12, Liu is cited for cloud-computing, robotics, and neural-network application contexts, not for the amended offload-request protocol of independent claim 1. Those application-context teachings do not cure Putnam's failure to disclose or suggest the offload request, as now claimed. Accordingly, Liu does not render claims 11, 12, or 23 obvious in combination with Putnam (page 19 of remark).
In response,
As responded above, Putnam and Linux, teaches offload request in amended independent claim 1. Therefore, claims 11 and 12 are taught by Putnam, Linux and Liu.
Applicant argued
“For claims 2, 9, and 15, the Office Action relies on Hansson for returning data
with a NAck signal and for upstream execution after receiving a NAck. Even if Hansson were combined with Putnam, Hansson does not supply the amended offload request of claims 1 and 14. Hansson 's NAck-with-data disclosure does not teach or suggest that Putnam's operand/result messages should be replaced with an offload request for remote execution that includes a program counter defining where execution begins and a destination location within the second processing tile for storing the result.” (page 19 of remark).
In response,
Dependent claims 2 and 15 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 and overcome 112(b).
Regarding to claim 9, as responded above, Linux, teaches offload request in amended independent claim 1. Hansson teaches when receiving a NAK which is deny message, it performs the operation (col 11 ln 26-35). Therefore, it is combination of Putnam, Linux, and Hansson, teaches claim 9.
Applicant argued
“For claims 8 and 19, the Office Action relies on Kumar for distance, latency, hop- count, and threshold concepts. Kumar's routing and latency teachings do not cure Putnam's failure to disclose or suggest the amended offload-request protocol. At most, Kumar addresses how routes may be selected based on latency requirements; it does not teach an offload request carrying the program counter and destination-location information now required by independent claims 1 and 14.” (page 19 of remark).
In response,
Similarly, as responded above, Linux, teaches offload request an offload request carrying the program counter and destination-location information as recited in amended independent claim 1. Therefore, it is combination of Putnam, Linux and Kumar teaches claims 8 and 19.
Applicant argued
“For claims 10 and 20, the Office Action relies on Biedert for server-side or data- center image streaming. Biedert's remote-visualization context does not supply the missing offload-request limitations. Applying Putnam's dataflow operand delivery to a server or data-center visualization environment would still leave the combination without an offload request for remote execution that includes the recited program counter and destination location.” (page 19 of remark).
In response,
Similarly, as responded above, Linux, teaches offload request an offload request carrying the program counter and destination-location information as recited in amended independent claim 1. Therefore, it is combination of Putnam, Linux and Biedert teaches claims 10 and 20.
Applicant argued
“For claims 11 and 12, the Office Action relies on Liu for cloud-computing,
robotics, and neural-network application contexts. Those application contexts do not cure Putnam's failure to disclose or suggest the amended offload request of claim 1. Liu's statements regarding suitable CGRA applications do not teach the claimed computation offload request including a program counter defining where execution begins and a destination location for storing the result.” (page 20 of remark).
In response,
Similarly, as responded above, Linux, teaches offload request an offload request carrying the program counter and destination-location information as recited in amended independent claim 1. Therefore, it is combination of Putnam, Linux and Liu teaches claim 11 and 12.
Applicant argued
“For claim 13, the Office Action relies on Hong for GPU virtualization and scheduling. Hong's GPU virtualization teachings do not supply the missing offload- request protocol. Even if Putnam were implemented in a GPU virtualization environment, the asserted combination would still lack the amended offload request including the program counter and destination location recited in claim 1.” (page 20 of remark).
In response,
Similarly, as responded above, Linux, teaches offload request an offload request carrying the program counter and destination-location information as recited in amended independent claim 1. Therefore, it is combination of Putnam, Linux and Hong teaches claim 13.
Applicant argued
“For claim 22, the Office Action relies on Kumar for the distance-threshold feature in combination with Putnam and Liu. Kumar's distance-threshold teachings do not cure the deficiencies in the Putnam/Liu mapping of independent claim 21. In particular, the combination still fails to teach or suggest an offload request for remote execution that includes the claimed program counter and destination location and further fails to teach the amended non-congested branch in which the second processing unit executes the computation beginning at the program counter and stores the result at the destination location. Accordingly, the § 103 rejections of claims 2, 8-13, 15, 19, 20, and 22 should be withdrawn.” (page 20 of remark).
In response,
Dependent claim 22 is allowed as their independent claim as indicated above.
Conclusion
The prior art made of record but not relied upon request is considered to be pertinent to applicant’s disclosure.
KALAMATIANOS, (US PUB 2022/0188117), discloses a Processor-guided execution of offloaded instructions using fixed function operations, wherein Instructions designated for remote execution by a target device are received by a processor (title, abstract and figures 1 – 7).
Sivasankaran, (US PUB 2018/0173619), discloses a method for Distributed Logical To Physical Address Mapping, wherein multiple memory channels, perform a respective read operation at a logical address specified by the host command, identifies the memory channel based on the specified logical address, and also identifies a portion of logical to physical address mapping information (title, abstract and figures 1 – 4).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 PHUONG N HOANG whose telephone number is (571)272-3763. The examiner can normally be reached 9:5-30.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/PHUONG N HOANG/ Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
