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 .
DETAILED ACTION
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.
Claim 13 is 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.
In claim 13, line 4, “other component” lacks proper antecedent basis since it was not mentioned previously.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Singh et al. (U.S. Publication No. 2020/0081850 A1), hereafter referred to as Singh’850.
Referring to claim 1, Singh’850 as claimed, a multi-processor data movement method comprising: setting a retarget address field of a transfer address one or more times to a dataspace of one or more processors (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1); setting one or more control fields to indicate a dataflow transfer or a configuration transfer (Further, the host processor, e.g., by way of the runtime, is aware of the particular circuitry (e.g. image or configuration bitstream) loaded into each hardware accelerator…The driver, for example, is capable of performing the automatic discovery of the hardware accelerator sequence, see para. [0066]; also note: buffer object include data that supports administrative functions and remote flag, see paras. [0071]-[0073]; selecting loading of configuration bitstream, see para. [0103]); setting a chip identifier field to indicate a destination accelerator processor (the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]); and routing the transfer address to the destination accelerator processor based on the retarget address field, the one or more control fields and the chip identifier field (to perform the task offloaded from the host processor, compute unit 160-1 must retrieve the data from the target address in memory 140-2, see paras. [0069], [0084], [0086]).
As to claim 2, Singh’850 also discloses setting a flow identifier field for the dataflow transfer (flow control, see Fig. 3 and paras. [0036], [0046], [0052], [0061]-[0064]); and routing the transfer address to the destination processor further based on the flow identifier field (to perform the task offloaded from the host processor, compute unit 160-1 must retrieve the data from the target address in memory 140-2, see paras. [0069], [0084], [0086]).
As to claim 3, Singh’850 also discloses setting, by a host processor, the retarget address field, the one or more control fields, the flow identifier field and the chip identifier field of the transfer address for the dataflow transfer (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1); sending the transfer address for the dataflow transfer to a data output port of the host processor for transmission to a data input port of a first accelerator processor (Figs. 1-3; also note: host processor may receive data from I/O device and provide such data over PCIe to hardware accelerator 135-1, see para. [0090]; compute unite 160-1 have a control port to which the target address may be stored, see para. [0076]); receiving the transfer address at the data input port of the first accelerator processor (initiating hardware accelerator (e.g. the first hardware accelerator) receives the task from the host processor. End point 145-1, for example may receive the task and provide the task to compute unit 160-1, see para. [0076]); determining by the first accelerator processor the destination accelerator processor from the chip identifier field of the transfer address (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]); and routing the transfer address from the data input port to a given ingress data register within the first accelerator processor based on the flow identifier field when the destination accelerator processor of the dataflow transfer is determined to be the first accelerator processor (compute unit 160-1 for example, may have a control port to which the target address may be stored, see para. [0076], and Fig. 1; also note: paras. [0067]-[0073] regarding each hardware accelerator with buffer object and para. [0076], regarding identifier (ID) bits).
As to claim 4, Singh’850 also discloses change the retarget address field to retarget the transfer address of the dataflow transfer from a data input port to a data output port of the first accelerator processor; sending the transfer address for the dataflow transfer to a data output port of the first accelerator processor for transmission to a data input port of a second accelerator processor (transaction forwarded to specified hardware accelerator, see Figs 1, 4, and paras. [0057], [0079], [0082]-[0085]); receiving the transfer address at the data input port of the second accelerator processor; determining by the second accelerator processor the destination accelerator processor from the chip identifier field of the transfer address (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
As to claim 5, Singh’850 also discloses setting, by a host processor, (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1) the retarget address field, the one or more control fields, and the chip identifier field of the transfer address for a first portion of the configuration transfer (Further, the host processor, e.g., by way of the runtime, is aware of the particular circuitry (e.g. image or configuration bitstream) loaded into each hardware accelerator…The driver, for example, is capable of performing the automatic discovery of the hardware accelerator sequence, see para. [0066]; also note: buffer object include data that supports administrative functions and remote flag, see paras. [0071]-[0073]; selecting loading of configuration bitstream, see para. [0103]); sending the transfer address for the first portion of the configuration transfer to an output port of the host processor for transmission to a control input port of a first accelerator processor (Figs. 1-3; also note: host processor may receive data from I/O device and provide such data over PCIe to hardware accelerator 135-1, see para. [0090]; compute unite 160-1 have a control port to which the target address may be stored, see para. [0076]); receiving the transfer address at the control input port of the first accelerator processor (initiating hardware accelerator (e.g. the first hardware accelerator) receives the task from the host processor. End point 145-1, for example may receive the task and provide the task to compute unit 160-1, see para. [0076]); determining by the first accelerator processor the destination accelerator processor from the chip identifier field of the transfer address of the first portion of the configuration transfer (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]); and routing the transfer address from the control input port to a given control register within the first accelerator processor when the destination accelerator processor of the configuration transfer is determined to be the first accelerator processor (compute unit 160-1 for example, may have a control port to which the target address may be stored, see para. [0076], and Fig. 1; also note: paras. [0067]-[0073] regarding each hardware accelerator with buffer object and para. [0076], regarding identifier (ID) bits).
As to claim 6, Singh’850 also discloses changing the retarget address field to retarget the transfer address of the first portion of the configuration transfer from a control input port to a control output port of the first accelerator processor (transaction forwarded to specified hardware accelerator, see Figs 1, 4, and paras. [0057], [0079], [0082]-[0085]); sending the transfer address of the first portion of the configuration transfer to a control output port of the first accelerator processor for transmission to a control input port of a second accelerator processor; receiving the transfer address of a second portion of the configuration transfer at the control input port of the second accelerator processor (routing to other circuits or forwarding transactions to be serviced by hardware accelerator to next hardware accelerator, see paras [0082]-[0085]); and determining by the second accelerator processor the destination accelerator processor from the chip identifier field of the transfer address of the first portion of the configuration transfer (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
As to claim 7, Singh’850 also discloses setting, by the host processor, (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1) the retarget address field, the one or more control fields, and the chip identifier field of the transfer address for a second portion of the configuration transfer (Further, the host processor, e.g., by way of the runtime, is aware of the particular circuitry (e.g. image or configuration bitstream) loaded into each hardware accelerator…The driver, for example, is capable of performing the automatic discovery of the hardware accelerator sequence, see para. [0066]; also note: buffer object include data that supports administrative functions and remote flag, see paras. [0071]-[0073]; selecting loading of configuration bitstream, see para. [0103]); sending the transfer address for the second portion of the configuration transfer to an output port of the host processor for transmission to a control input port of the first accelerator processor (Figs. 1-3; also note: host processor may receive data from I/O device and provide such data over PCIe to hardware accelerator 135-1, see para. [0090]; compute unite 160-1 have a control port to which the target address may be stored, see para. [0076]); receiving the transfer address at the control input port of the first accelerator processor (initiating hardware accelerator (e.g. the first hardware accelerator) receives the task from the host processor. End point 145-1, for example may receive the task and provide the task to compute unit 160-1, see para. [0076]); determining by the first accelerator processor the destination accelerator processor from the chip identifier field of the transfer address of the second portion of the configuration transfer (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]); and routing the transfer address from the control input port to a given control register within the first accelerator processor when the destination accelerator processor of the configuration transfer is determined to be the first accelerator processor (compute unit 160-1 for example, may have a control port to which the target address may be stored, see para. [0076], and Fig. 1; also note: paras. [0067]-[0073] regarding each hardware accelerator with buffer object and para. [0076], regarding identifier (ID) bits).
As to claim 8, Singh’850 also discloses changing the retarget address field to retarget the transfer address of the second portion of the configuration transfer from a control input port to a control output port of the first accelerator processor (transaction forwarded to specified hardware accelerator, see Figs 1, 4, and paras. [0057], [0079], [0082]-[0085]); sending the transfer address of the second portion of the configuration transfer to a control output port of the first accelerator processor for transmission to a control input port of a second accelerator processor; receiving the transfer address of a second portion of the configuration transfer at the control input port of the second accelerator processor (routing to other circuits or forwarding transactions to be serviced by hardware accelerator to next hardware accelerator, see paras [0082]-[0085]); and determining by the second accelerator processor the destination accelerator processor from the chip identifier field of the transfer address of the second portion of the configuration transfer (example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
Referring to claim 9, Singh’850 as claimed, a multi-processor computing device (see Fig. 1) comprising: a host processor (host processor 105, see Fig. 1); one or more accelerator processors (accelerator processors 135-1, 135-2, 135-3, see Fig. 1) coupled in series to the host processor by respective communication interfaces (interface circuitry 115, link circuits 150-1, 150-2, 150-3, see Fig. 1) that support configuration transfers and dataflow transfers (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1; example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
As to claim 10, Singh’850 also discloses the host processor programs a first accelerator processor with a first portion of a computation model and a second accelerator processor with a second portion of the computation model (initiating hardware accelerator (e.g. the first hardware accelerator) receives the task from the host processor. End point 145-1, for example may receive the task and provide the task to compute unit 160-1, see para. [0076]; example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082] and Figs. 1, 4).
As to claim 11, Singh’850 also discloses the host processor programs a first accelerator processor with a first computation model and a second accelerator processor with a second computation model (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator, see paras. [0036]-[0038] and Fig. 1; example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
As to claim 12, Singh’850 also discloses the configuration transfers and the dataflow transfers between the host processor and the one or more accelerator processors include a transfer address comprising a retarget address field identifying a given memory space of the host processor and the accelerator processors a first control field identifying the transfer address as a configuration transfer address or a dataflow transfer address (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator; modifying addresses, see paras. [0035]-[0038] and Fig. 1), and a chip identifier field identifying a destination accelerator processor (the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082]).
As to claim 13, Singh’850 also discloses the configuration transfer address further includes a second control field identifying an accelerator processor or other component (initiating hardware accelerator (e.g. the first hardware accelerator) receives the task from the host processor. End point 145-1, for example may receive the task and provide the task to compute unit 160-1, see para. [0076]; example of write transaction from hardware accelerator 135-1 to hardware accelerator 135-3 and routing the transaction internally or forwarded to the next hardware accelerator, see paras. [0038], [0083]-[0085]; the target address in this example is located in hardware accelerator 135-2, see paras. [0069], [0082] and Figs. 1, 4).
As to claim 14, Singh’850 also discloses the dataflow transfer address further includes a flow identifier field identifying a given one of a plurality of data in buffers or a given one of a plurality of data out buffers (to perform the task offloaded from the host processor, compute unit 160-1 must retrieve the data from the target address in memory 140-2, see paras. [0069], [0084], [0086]; also note: (flow control, see Fig. 3 and paras. [0036], [0046], [0052], [0061]-[0064]).
As to claim 15, Singh’850 also discloses the given memory space of the host processor and the accelerator processors include an address space of a data input port of the accelerator processors, an address space of a control input port of the accelerator processors, an address space of an output data port of the accelerator processors, and an address space of an output control port of the accelerator processors (host processor may initiate a data transfer involving hardware accelerators 135-2 and 135-3. Hardware accelerator 135-2 may be the initiator. In this example, host processor 105 creates buffer object 176 corresponding to hardware accelerator 135-2 and buffer object 178 corresponding to hardware accelerator 135-3. Host processor 105 sets remote flag 182 indicating that the target address for the data transfer is remote relative to the initiating hardware accelerator; modifying addresses, see paras. [0035]-[0038], [0068], and Fig. 1).
Note claim 16 recites similar limitations of claims 3 and 4. Therefore it is rejected based on the same reason accordingly.
Note claim 17 recites similar limitations of claims 5 and 6. Therefore it is rejected based on the same reason accordingly.
Note claim 18 recites similar limitations of claims 7 and 8. Therefore it is rejected based on the same reason accordingly.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Sity et al. (U.S. Publication No. 2022/0164297 A1) discloses distributed processor memory chip with multi-port processor subunits.
Biran et al. (U.S. Publication No. 2016/0335215 A1) discloses accelerator engine commands submission over an interconnect link.
Minkin et al. (U.S. Patent No. 11,868,872 B1) discloses direct memory access operation for neural network accelerator.
DRYSDALE et al. (U.S. Publication No. 2018/0095750 A1) discloses hardware accelerators and methods for offload operations.
NARAYANAN et al. (U.S. Publication No. 2022/0019365 A1) discloses an apparatus for offloading data transfer operations between source and destination storage devices to a hardware accelerator.
KUTCH et al. (U.S. Publication No. 2021/0117360 A1) discloses Network and Edge Acceleration Tile (NEXT) architecture.
BACHMUTSKY et al. (U.S. Publication No. 2019/0317802 A1) discloses architecture for offload of linked work assignments.
Bleiweiss et al. (U.S. Publication No. 2019/0205737 A1) discloses machine learning accelerator mechanism.
TORUDBAKKEN et al. (U.S. Publication No. 2021/0357340 A1) discloses a gateway for use in a computing system to interface a host with a subsystem for acting as a work accelerator to the host.
Modukuri et al. (U.S. Publication No. 2024/0273054 A1) discloses techniques to transfer data among hardware devices.
The examiner requests, in response to this office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist the examiner in prosecuting the application. When responding to this office action, applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 C.F.R. 1.111(c).
In amending in reply to a rejection of claims in an application or patent under reexamination, the applicant or patent owner must clearly point out the patentable novelty which he or she thinks the claims present in view the state of the art disclosed by the references cited or the objections made. The applicant or patent owner must also show how the amendments avoid such references or objections.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TITUS WONG whose telephone number is (571)270-1627. The examiner can normally be reached Monday-Friday, 10am-6pm.
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, Idriss Alrobaye can be reached on (571) 270-1023. 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.
/TITUS WONG/Primary Examiner, Art Unit 2181
Prosecution Insights