DETAILED ACTION
This is in response to the application filed on 6/2/2026 in which claims 1 - 20 are presented for examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR
1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/19/2026 has been entered.
Claim Rejections- 35 USC§ 102
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.
Claims 1-4, 6-10, 12-15, and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zhao et al., U.S. Patent 10,325, 343 (hereinafter referred to as Zhao) (listed in the IDS dated 8/21/2024).
Referring to claim 1, Zhao discloses one or more processors (GPU servers 120-1, 120-2, 120-s of computer system 100, Fig. 1), comprising: circuitry to, in response to an application programming interface (API) call (GPU Application Programming Interface 114, Fig. 1), at least:
obtain one or more representations of hardware topology comprising representations of one or more interconnects (See steps 400, 402, and 404 in Fig. 4; Fig. 3A shows the representation of hardware topology of a GPU server node 300 comprising representations of one or more interconnects including, e.g., PCIe switch 305, NVLink 307, etc.; and Col. 12, lines 9-13, “FIG. 5 illustrates an example hardware topology of a GPU server node 500, and a corresponding system topology view 520 generated by the topology detection and scoring module 232 using a topology detection command utility, according to an embodiment of the invention.” ) ;
determine, based at least in part on the one or more representations of hardware topology, two or more different paths (Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. For the data communication between GPU0 and GPU, the GPU interconnect path includes PCIe Switch 305, and the GPU interconnect path includes NVLINK 307, see Figs. 3A, will be determined) usable to transfer data between two (GPU0 and GPU1) or more hardware devices, wherein each of the two or more different paths comprises at least one of the one or more interconnects (PCIe Switch 305 or NVLink 307);
obtain one or more performance metrics (Fig. 6A, 2nd col., priority score (performance metrics)) of the one or more interconnects from the two or more different paths (see Fig. 6A, first col., different connection types of GPU interconnect paths; see also Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”) ;
select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics (See Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”; and
Note: Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C.
For example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score) “1”, see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score) “2”.) ; and
transfer information between the two or more hardware devices (See, e.g., Fig. 3A, GPU0 and GPU1 in the hardware topology of GPU server node 300) using the selected path (See, e.g., in Fig. 3A, the one interconnect path 307 includes NVLINK).
Referring to claim 2, Zhao discloses the one or more processors of claim 1, wherein one or more of the two or more hardware devices are a graphics processing unit (GPU). (See Fig. 5, e.g., GPU0, GPU1, GPU2, and GPU3)
Referring to claim 3, Zhao discloses the one or more processors of claim 1, wherein the circuitry is to select the at least one of the one or more interconnects based, at least in part, on a function call that specifies a data transfer operation (See Col. 4, lines 24-31, “The service requests are transmitted along with blocks of application code (e.g., compute kernels) of the GPU-accelerated applications 112 and any associated data, for processing by one or more GPU devices 124 of one or more GPU servers of the server cluster 120. In addition, the GPU APIs 114 comprise routines to handle local GPU-related processing such as executing GPU application code, manipulating data, handling errors, etc.”).
Referring to claim 4, Zhao discloses the one or more processors of claim 1, wherein the
circuitry is to select the at least one of the one or more interconnects based, at least in part, on a device hierarchy tree (See Col. 8, line 54 to Col. 9, line 9, “FIG. 3A schematically illustrates a hardware topology of a GPU server node 300 … The GPUs GPU0, GPU1, GPU2, and GPU3 can be interconnected 307 using any suitable wire-based communications protocol such as NVLINK developed by NVidia. NVLINK allows for transferring of data and control code between the GPUs, and can also be used for communication between the GPUs and CPUs”. Note: the hardware topology of a GPU server node 300 shown in Fig. 3A, and the hardware topology of a GPU server node 500 shown in Fig. 5 each are a device hierarchy tree).
Referring to claim 6, Zhao discloses the one or more processors of claim 1, wherein the circuitry is to determine a set of buffers to use in one or more midpoints devices between the two or more hardware devices along the selected path. (see Fig. 3A, e.g., between hardware devices GPU0 and HBA 302, the 1st path including PCle Switch 305, CPU 304; and the 2nd path including PCle Switch 305, CPU 303 and CPU 304 are determined. The 1st path is the selected path due to better performance. Therefore, the circuitry is to determine a set of buffers to use in one or more midpoints devices (PCle Switch 305, and CPU 304). Note: the buffers in PCle Switch 305, and/or CPU 304 are essential for managing data flow.
Referring to claim 7, Zhao discloses the one or more processors of claim 1, wherein the circuitry is to select the at least one of the one or more interconnects based, at least in part, on a function call that specifies a read operation (See Col. 4, lines 24-31, “The service requests are transmitted along with blocks of application code (e.g., compute kernels) of the GPU-accelerated applications 112 and any associated data, for processing by one or more GPU devices 124 of one or more GPU servers of the server cluster 120. In addition, the GPU APIs 114 comprise routines to handle local GPU-related processing such as executing GPU application code, manipulating data, handling errors, etc.” See also Col. 6, lines 60-66, “The storage interface circuitry 204 enables the processors 202 to interface and communicate with the system memory 210, and other local storage and off-infrastructure storage media on the GPU server node 200, using one or more standard communication and/or storage control protocols to read data from or write data to volatile and non-volatile memory/storage devices”).
Referring to claim 8, Zhao discloses a system (a computer system 100, see Fig. 1) comprising: one or more processors (GPU servers 120-1,1202, 120-s of computer system 100, Fig. 1) to, in response to an application programming interface (API) call (GPU Application Programming Interface 114, Fig. 1), at least:
obtain one or more representations of hardware topology comprising representations of one or more interconnects (See steps 400, 402, and 404 in Fig. 4; Fig. 3A shows the representation of hardware topology of a GPU server node 300 comprising representations of one or more interconnects including, e.g., PCIe switch 305, NVLink 307, etc.; and Col. 12, lines 9-13, “FIG. 5 illustrates an example hardware topology of a GPU server node 500, and a corresponding system topology view 520 generated by the topology detection and scoring module 232 using a topology detection command utility, according to an embodiment of the invention.” ) ;
determine, based at least in part on the one or more representations of hardware topology, two or more different paths (Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. For the data communication between GPU0 and GPU, the GPU interconnect path includes PCIe Switch 305, and the GPU interconnect path includes NVLINK 307, see Figs. 3A, will be determined) usable to transfer data between two (GPU0 and GPU1) or more hardware devices, wherein each of the two or more different paths comprises at least one of the one or more interconnects (PCIe Switch 305 or NVLink 307);
obtain one or more performance metrics (Fig. 6A, 2nd col., priority score (performance metrics)) of the one or more interconnects from the two or more different paths (see Fig. 6A, first col., different connection types of GPU interconnect paths; see also Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”) ;
select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics (See Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”; and
Note: Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C.
For example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score) “1”, see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score) “2”.) ; and
transfer information between the two or more hardware devices (See, e.g., Fig. 3A, GPU0 and GPU1 in the hardware topology of GPU server node 300) using the selected path (See, e.g., in Fig. 3A, the one interconnect path 307 includes NVLINK).
Referring to claim 9, Zhao discloses the system of claim 8, wherein the one or more processors are to select the one or more interconnects from a set of interconnects that includes a first type of interconnect and a second type of interconnect different from the first type of interconnect. (Fig 6A, first col. shows different connection types of GPU interconnect paths, such as the path including NVLINK which is different from the path including PIX (internal PCIe Switch).
Referring to claim 10, Zhao discloses the system of claim 8, wherein one or more of the two or more hardware devices are a graphics processing unit (GPU). (See Fig. 5, e.g., GPU0, GPU1, GPU2, and GPU3).
Referring to claim 12, Zhao discloses the system of claim 8, wherein the one or more processors are to select the at least one of the one or more interconnects based, at least in part, on a function call that specifies a write operation (See Col. 4, lines 24-31, “The service requests are transmitted along with blocks of application code (e.g., compute kernels) of the GPU-accelerated applications 112 and any associated data, for processing by one or more GPU devices 124 of one or more GPU servers of the server cluster 120. In addition, the GPU APIs 114 comprise routines to handle local GPU-related processing such as executing GPU application code, manipulating data, handling errors, etc.” See also Col. 6, lines 60-66, “The storage interface circuitry 204 enables the processors 202 to interface and communicate with the system memory 210, and other local storage and off-infrastructure storage media on the GPU server node 200, using one or more standard communication and/or storage control protocols to read data from or write data to volatile and non-volatile memory/storage devices.”).
Referring to claim 13, Zhao discloses the system of claim 8, wherein the one or more processors are to select the at least one of the one or more interconnects based, at least in part, on a device hierarchy tree (See Col. 8, line 54 to Col. 9, line 9, “FIG. 3A schematically illustrates a hardware topology of a GPU server node 300 … The GPUs GPU0, GPUl, GPU2, and GPU3 can be interconnected 307 using any suitable wire-based communications protocol such as NVLINK developed by NVidia. NVLINK allows for transferring of data and control code between the GPUs, and can also be used for communication between the GPUs and CPUs”. Note: the hardware topology of a GPU server node 300 shown in Fig. 3A, and the hardware topology of a GPU server node 500 shown in Fig. 5 each are a device hierarchy tree).
Referring to claim 14, Zhao discloses the system of claim 8, wherein one or more of the two or more hardware devices are a central processing unit (CPU) (See Fig. 5, CPU1 and CPU0).
Referring to claim 15, Zhao discloses a method, comprising: in response to a call to an application programming interface (API) (GPU Application Programming Interface 114, Fig. 1), at least:
obtaining one or more representations of hardware topology comprising representations of one or more interconnects (See steps 400, 402, and 404 in Fig. 4; Fig. 3A shows the representation of hardware topology of a GPU server node 300 comprising representations of one or more interconnects including, e.g., PCIe switch 305, NVLink 307, etc.; and Col. 12, lines 9-13, “FIG. 5 illustrates an example hardware topology of a GPU server node 500, and a corresponding system topology view 520 generated by the topology detection and scoring module 232 using a topology detection command utility, according to an embodiment of the invention.” ) ;
determining, based at least in part on the one or more representations of hardware topology, two or more different paths (Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. For the data communication between GPU0 and GPU, the GPU interconnect path includes PCIe Switch 305, and the GPU interconnect path includes NVLINK 307, see Figs. 3A, will be determined) usable to transfer data between two (GPU0 and GPU1) or more hardware devices, wherein each of the two or more different paths comprises at least one of the one or more interconnects (PCIe Switch 305 or NVLink 307);
obtaining one or more performance metrics (Fig. 6A, 2nd col., priority score (performance metrics)) of the one or more interconnects from the two or more different paths (see Fig. 6A, first col., different connection types of GPU interconnect paths; see also Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”) ;
selecting a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics (See Col. 11, lines 13-28, “The topology detection and scoring module 232 implements methods that are configured to (i) detect the hardware elements (and properties) (e.g., GPUs, network adapters (IB, RoCE, IPoIB, Ethernet) and the hardware interconnect topology ( e.g., PCIe, NVLink, other internal interconnection bus/link technologies, etc.), and (ii) generate a topology performance metrics table that is stored in the data store of performance metric tables 240. The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations.”; and
Note: Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C.
For example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score) “1”, see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score) “2”.) ; and
transferring information between the two or more hardware devices (See, e.g., Fig. 3A, GPU0 and GPU1 in the hardware topology of GPU server node 300) using the selected path (See, e.g., in Fig. 3A, the one interconnect path 307 includes NVLINK).
Referring to claim 17, Zhao discloses the method of claim 15, further comprising: performing an information transfer operation requested by a function call using the selected path (See Col. 11, lines 21-28, “The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations”. Note: for example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score “1”), see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score “2”). See also Col. 4, lines 24-31, “The service requests are transmitted along with blocks of application code (e.g., compute kernels) of the GPU-accelerated applications 112 and any associated data, for processing by one or more GPU devices 124 of one or more GPU servers of the server cluster 120. In addition, the GPU APIs 114 comprise routines to handle local GPU-related processing such as executing GPU application code, manipulating data, handling errors, etc.”).
Referring to claim 18, Zhao discloses the method of claim 15, wherein one or more of the two or more hardware devices are a graphics processing unit (GPU) (See Fig. 5, e.g., GPU0, GPU1, GPU2, and GPU3).
Referring to claim 19, Zhao discloses the method of claim 15, further comprising: selecting the at least one of the one or more interconnects based, at least in part, on a function call (See Col. 11, lines 21-28, “The topology detection and scoring module 232 would detect the hardware environment and interconnect topology for a given GPU server node, and generate a performance metrics table which includes performance metrics (e.g., priority scores) for the detected hardware environment and interconnect topology, and then store the performance metrics table in the data store 240 for subsequent access and use in GPU mapping/re-balancing operations”. Note: for example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score “1”), see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score “2”). See also Col. 4, lines 24-31, “The service requests are transmitted along with blocks of application code (e.g., compute kernels) of the GPU-accelerated applications 112 and any associated data, for processing by one or more GPU devices 124 of one or more GPU servers of the server cluster 120. In addition, the GPU APIs 114 comprise routines to handle local GPU-related processing such as executing GPU application code, manipulating data, handling errors, etc.”).
Referring to claim 20, Zhao discloses the method of claim 15, further comprising: performing one or more of decompression, compression, decryption, and encryption (See Co. 1, lines 33-41, “For example, GPUs are used to accelerate data processing in high-performance computing (HPC) and embedded computing systems, for various applications such as financial modeling, scientific research, machine learning, data mining, video data transcoding, image analysis, image recognition, virus pattern matching, augmented reality, encryption/decryption, weather forecasting, big data comparisons, and other applications … ”).
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.
4. 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.
5. Claims 5, 11, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Zhao in view of Richardson et al., Patent Application Publication US2009/0248786 A1 (hereinafter referred to as Richardson).
As per claims 5, 11 and 16, Zhao does not appear to explicitly disclose “wherein the one or more performance metrics include a latency metric associated with at least one of the two or more different paths.”
However, Zhao discloses wherein the one or more performance metrics include bandwidth and speed associated with at least one of the two or more different paths. (See Col. 9, lines 31-35, “For instance, the topology of FIG. 3A provides a high-performance configuration primarily due to the PCIe switch 305 which can be implemented with a large number of data transmission lanes, e.g., 96 lanes, for high bandwidth communications.” Note: PCIe switch 305 is shown in Fig. 3A and included in the performance metrics (priority score) of GPU interconnect path shown in Fig. 6A. See also Col. 13, lines 48-51, “The performance metrics table 610 provides an indication of the performance (e.g., speed) of a given interconnect between two GPU devices or between a GPU and a network adapter, for example.” Further note: The performance of either bandwidth or speed is closely related a performance of latency.)
Furthermore, Richardson discloses “the network performance criteria can correspond to measurements of network performance for transmitting data … network data transfer latencies associated with the delivery of the requested resource …” see PARA 0060, lines 12-17.
Zhao and Richardson are analogous art because they are dealing with data transfer in a network.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Zhao and Richardson before him or her, to modify the teachings of Zhao to include a latency metric associated with at least one of the two or more different paths.
The motivation for doing so would have been to set up performance metrics of interconnects for properly selecting data paths in a hardware topology.
Therefore, it would have been obvious to combine Zhao and Richardson to obtain the invention as specified in the instant claim.
Double Patenting
6. The non statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Langi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321 (c) or 1.321 (d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321 (b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111 (a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission.
The resource page for eTerminal Disclaimer can be located at:
https://www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer
7. Claims 1-4, 6-10, 12-15, and 17-19 are rejected on the ground of non statutory double patenting as being unpatentable over Claims 1-4, 7, and 10-32 of Modukuri et al. [U.S. Patent No. 11,132,326 B1] in view of lshizaki [U.S. Pat. App. Pub. No. 2018/0253290 A1].
The patent claims are worded a bit differently, but they include limitations that cover the application claims except for the application claim limitations directed to an application programming interface (API) used to select the interconnects.
lshizaki shows a data transfer system to transfer data between a CPU and GPU in a computer system using an API ([0002]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the application to utilize an API to effect data transfers as shown by lshizaki in the patent claims to provide an automated high-performance transfer mechanism.
Claims 5, 11, and 16 are rejected on the ground of non-statutory double patenting as being unpatentable over Claims 1-4, 7, and 10-32 of Modukuri et al. in view of lshizaki, and further in view of in view of Richardson et al. [Patent Application Publication US2009/0248786 A1] (hereinafter referred to as Richardson).
As per claims 5, 11 and 16, Modukuri et al. in view of lshizaki does not appear to explicitly disclose “wherein the one or more performance metrics include a latency metric associated with at least one of the two or more different paths.”
However, Richardson discloses the network performance criteria can correspond to measurements of network performance for transmitting data … network data transfer latencies associated with the delivery of the requested resource, see PARA 0060, lines 20-26.
Modukuri et al./lshizaki and Richardson are analogous art because they are dealing with the data transfer in a network.
Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Richardson before him or her, to modify the teachings of Modukuri et al./lshizaki to include a latency metric associated with at least one of the two or more different paths.
The motivation for doing so would have been to set up performance metrics of interconnects for properly selecting data paths in a hardware topology.
Therefore, it would have been obvious to combine Modukuri et al./lshizaki and Richardson to obtain the invention as specified in the instant claim.
Claim 20 is rejected on the ground of non-statutory double patenting as being unpatentable over Claims 1-4, 7, and 10-32 of Modukuri et al. in view of lshizaki, and further in view of Kish [U.S. Pat. App. Pub. No. 2017/0251052 A1].
As per claim 20, Modukuri et al. in view of lshizaki does not appear to explicitly disclose performing one or more of decompression, compression, decryption, and
encryption.
However, Kish shows network communication using APls (e.g., [0004, 0033]) including performance of at least encryption/decryption ([0033]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the application to use APls for encrypting/decrypting data as shown by Kish in the system of Modukuri et al. and lshizaki in order to protect client confidential information (Kish , [0033]).
Instant Application (18634832)
Patent (US 11132326)
1. (Currently Amended) One or more processors, comprising: circuitry to, in response to an application programming interface (API) call, at least:
obtain one or more representations of hardware topology comprising representations of one or more interconnects;
determine, based at least in part on the one or more representations of hardware topology, two or more different paths usable to transfer data between two or more hardware devices, wherein each of the two or more different paths comprises at least one of the one or more interconnects;
obtain one or more performance metrics of the one or more interconnects from the two or more different paths;
select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics;
and transfer information between two or more hardware devices using the selected path.
1. A processor comprising: one or more circuits to determine a path over which to transfer data from a first hardware component of a computer system to a second hardware component of the computer system based, at least in part, on a device tree and one or more characteristics of different paths usable to transfer the data.
3. The processor of claim 1, wherein the device tree is a representation of a hardware topology that includes the first hardware component and the second hardware component.
4. The processor of claim 3, wherein the device tree is a device hierarchy tree, and the one or more circuits are further to generate the device hierarchy tree based, at least in part, on peripheral component interconnect express (PCIe) bus device function (BDF) information.
10. The processor of claim 1, wherein the one or more circuits are further to determine a plurality of values corresponding to a plurality of dynamic component conditions, and to determine the path based, at least in part, on the plurality of values.
And in view of Ishizaki.
2. The one or more processors of claim 1, wherein one or more of the two or more hardware devices are a graphics processing unit (GPU).
2. The processor of claim 1, wherein one or more of the first hardware component and the second hardware component is a graphics processing unit (GPU).
3. (Currently Amended) The one or more processors of claim 1, wherein the circuity is to select the at least one of one or more interconnects based, at least in part, on a function call that specifies a data transfer operation.
1. A processor comprising: one or more circuits to determine a path over which to transfer data from a first hardware component of a computer system to a second hardware component of the computer system based, at least in part, on a device tree and one or more characteristics of different paths usable to transfer the data.
And in view of Ishizaki.
4. (Currently Amended) The one or more processors of claim 1, wherein the circuitry is to select the at least one of the one or more interconnects based, at least in part, on a device hierarchy tree.
3. The processor of claim 1, wherein the device tree is a representation of a hardware topology that includes the first hardware component and the second hardware component.
4. The processor of claim 3, wherein the device tree is a device hierarchy tree, and the one or more circuits are further to generate the device hierarchy tree based, at least in part, on peripheral component interconnect express (PCIe) bus device function (BDF) information.
5. (Currently Amended) The one or more processors of claim 1, wherein the one or more performance metrics include a latency metric associated with at least one of the two or more different paths
10. The processor of claim 1, wherein the one or more circuits are further to determine a plurality of values corresponding to a plurality of dynamic component conditions, and to determine the path based, at least in part, on the plurality of values.
And in view of Richardson et al., Patent Application Publication US2009/0248786 A1.
6. (Currently Amended) The one or more processors of claim 1, wherein the circuitry is to determine a set of buffers to use in one or more midpoints devices between the two or more hardware devices along the selected path.
7. The processor of claim 1, wherein the path includes a buffer managed by an intermediate device.
7. The processor of claim 1, wherein the API is to select the one or more interconnects based, at least in part, on a function call that specifies a read operation.
Claim 1 and in view of Ishizaki.
Claims 8-14 system and 15-19 method
Claims 11-17 CRM and 18-32 method
20. (Currently Amended) The method of claim 15, further comprising: performing one or more of decompression, compression, decryption, and encryption.
further in view of Kish, U.S. Pat. App. Pub. No. 2017/0251052 A1.
Response to Arguments
10. Applicant's arguments filed 5/19/2026 have been fully considered but they are not persuasive.
Applicant argues, on page 7, lines 16-17, that “Accordingly, Applicant submits that the amendments have rendered the double patenting rejections moot. Applicant therefore respectfully requests that the Office withdraw the pending double patenting rejection."
The examiner disagrees.
The double patenting rejection has been updated in the current office action according to the new claim amendments.
Applicant argues, on page 8, lines 15-29, that “Without conceding to the appropriateness of the rejection, Applicant has amended claim 1 to recite, in part, "obtain one or more performance metrics of the one or more interconnects from the two or more different paths," and "select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics." Applicant respectfully submits that Zhao does not teach or suggest such subject matter. … This grouping indicates how the GPU resources are to be allocated, rather than the selection of different paths. See, e.g., col. 3, lines 56-62.”
The examiner disagrees.
Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. As shown in the 102 rejections to claim 1, Zhao discloses one or more processors (GPU servers 120-1,1202, 120-s of computer system 100, Fig. 1), comprising: circuitry to, in response to an application programming interface (API) call (GPU Application Programming Interface 114, see Fig. 1), at least
obtain one or more performance metrics (Fig. 6A, 2nd col., priority score (performance metrics)) of the one or more interconnects from the two or more different paths (see Fig. 6A, first col., different connection types of GPU interconnect paths; see also Col. 11, lines 13-28);
select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics (See Col. 11, lines 13-28, and Note: Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. For example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score) “1”, see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score) “2”.)
Applicant argues, on page 9, lines 9-17, that thus, while Zhao describes "performance metrics," the performance metrics are predefined priority scores that correspond to different types of possible connections in a GPU server topology, rather than dynamically collected metrics. These scores are used by Zhao to score the interconnection topology when determining a GPU grouping for a given client requesting GPU resources. This is not the same as, "select[ing] a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics" and "transfer[ring] information between the two or more hardware devices using the selected path," as recited in amended claim 1. Accordingly, Zhao fails to anticipate claim 1 as amended.
The examiner disagrees.
Claim 1 does not comprise the language of “dynamically collected metrics”. Zhao discloses the claimed limitations, see the above 102 rejection to claim1.
Referring to claim 1, Zhao discloses one or more processors (GPU servers 120-1,1202, 120-s of computer system 100, Fig. 1), comprising: circuitry to, in response to an application programming interface (API) call (GPU Application Programming Interface 114, see Fig. 1), at least:
select a path from the two or more different paths based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics (See Col. 11, lines 13-28, and Note: Zhao discloses the data communication between GPUs, see Figs. 3A, 3B, and 3C. For example, based on the one hardware topology of GPU server node 300 in Fig. 3A, and a higher performance metric (priority score) “1”, see Fig. 6A, the one interconnect 307 including NVLINK will be selected for the path to transfer information between GPU0 and GPU1, instead of selecting the interconnect including PCIe Switch 305 having a lower performance metric (priority score) “2”); and
transfer information between two or more hardware devices. (See, e.g., Fig. 3A, GPU0 and GPU1 in the hardware topology of GPU server node 300) using the selected path (See, e.g., in Fig. 3A, the one interconnect path 307 includes NVLINK).
Conclusion
11. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Atia et al. (US 2017/0078192 A1) discloses a method for determining a plurality of communication ports that the data storage entity utilizes to transfer data to the computing entity. The method further includes identifying a plurality of computing resources respectively associated with the determined plurality communication ports that the data storge entity utilizes to transfer the data to the computing entity, see Fig. 6. It appears that the reference teaches determining, based at least in part on the one or more representations of hardware topology, two or more different paths usable to transfer data between two or more hardware devices, wherein each of the two or more different paths comprises at least one of the one or more interconnects; and the selecting step as Claim 1 of the instant application.
Balle et al. (US 10,579,547 B2) discloses technologies for providing I/O channel abstraction for accelerator device kernels include an accelerator device comprising circuitry to obtain availability data indicative of an availability of one or more accelerator device kernels in a system, including one or more physical communication paths to each accelerator device kernel. The reference, see Fig. 19, also discloses establishing a logical communication path with other accelerator device kernel(s) based on the availability data when determining the path having the lowest latency. It appears that the reference teaches, as Claim 1 of the instant application, determining two or more different paths usable to transfer data between two or more hardware devices; and selecting a path from the two or more different paths at least one of the one or more interconnects based, at least in part, on the one or more representations of the hardware topology and the one or more performance metrics, see Balle et al.’s Claim 2.
Contact Information
12. Any inquiry concerning this communication or earlier communications from the examiner should be directed to HENRY TSAI whose telephone number is 571-272-4176. The examiner can normally be reached Mon-Fri, 9:00AM-5:00PM. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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 (AlR) at http://www. us pto.gov/interviewpractice.
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.
/HENRY TSAI/
Supervisory Patent Examiner, Art Unit 2184
Prosecution Insights