DETAILED ACTION
1. It is hereby acknowledged that 18/664336 the following papers have been received and placed of record in the file: Amendment dated 07/13/26
2. Claims 1-20 are presented for examination. Claims 1 and 15 have been amended.
Response to Argument
3. Applicant’s arguments, see remarks, filed 07/13/26 with respect to the rejection(s) of claim(s) 1-20 upon further consideration, a new ground(s) of rejection is made. Applicant also argues Biderman reference uses pre-assigment descriptors, examiner respectfully disagrees and does not specifically see paragraph [0027] stating this.
Claim Rejections - 35 USC § 103
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) A patent may not be obtained through the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
5. Claims 1, 2, 4-5, 15, 16 and 18 are rejected under 35 U.S.C. §103 as being unpatentable over Biederman et al (US 2024/0111691A1) in view of Bachmutsky et al(US 2019/0317802A1),
Regarding claim 1, Biederman teaches a system, comprising (i) one or more processors, and (ii) multiple network devices to connect the one or more processors to a network, wherein: the one or more processors are to issue work requests to the multiple network devices, (see Biederman paragraph [0027] explains in such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer). by the one or more processors posting work descriptors on one or more shared queues that are each accessible to the multiple network devices; (see Biederman paragraph [0027] explains in such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer). and the network devices are to pull the work descriptors from the one or more shared queues, and to execute the work requests responsively to the work descriptors, wherein the descriptors are not pre-assigned by the one or more processors to any specific network device. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0035] explains…. A send queue (also referred to as a “submission queue”) is used for the application to post work requests (WRs) to transmit data (or a read request) to the remote system. A work request may have one or more opcodes which may include: send, send with solicited event, RDMA Write, RDMA Read, etc. The receive queue is used for the application to post work requests with buffers for placing untagged messages from the remote system. Elements in the completion queue indicate, to the application, that a request has been completed. The application may poll the completion queue to identify any completed operations. The CQ may be associated with one or more send queues and/or one or more receive queues)
While it can be understood Biederman teaches wherein the work descriptors are not pre-assigned by the one or more processors to any specific network device as explained above.
However to further explain this Bachmutsky is introduced and explains for example, given n priorities, every enqueue and dequeue buffer pair may be assigned a different priority such that n buffers are allocated for enqueue requests and n buffers are allocated for dequeue requests. Each incoming request has a priority that is either pre-assigned by the requesting core/thread or assigned by the QMD upon receipt by the QMD. Each request is then stored in a buffer that corresponds to the request's priority (1-n) and/or type (enqueue or dequeue) and/or other parameters. (see paragraph [0029])
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement of managing latency for applications(See paragraph[0052])
Regarding claim 2, the modified Biederman taught the system according to claim 1, as described above. Biederman further teaches wherein, in posting a work descriptor on the shared queue, a processor is to make the work descriptor available to any of the multiple network devices. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0057] explains…. In some embodiments, the entries in the TPTs 116a, 116b may be used to pace the fetching of elements in the send queues 208a, 208b by the NICs 108a, 108b. I)
Regarding claim 4, the modified Biederman taught the system according to claim 1, as described above. The modified Biederman further teaches wherein a network device is to pull a work descriptor from the shared queue, not in response to an assignment of the work descriptor to the network device by the one or more processors. (see Bachmutsky paragraph [0029]explains for example, given n priorities, every enqueue and dequeue buffer pair may be assigned a different priority such that n buffers are allocated for enqueue requests and n buffers are allocated for dequeue requests. Each incoming request has a priority that is either pre-assigned by the requesting core/thread or assigned by the QMD upon receipt by the QMD. Each request is then stored in a buffer that corresponds to the request's priority (1-n) and/or type (enqueue or dequeue) and/or other parameters. ; see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0035] explains…. A send queue (also referred to as a “submission queue”) is used for the application to post work requests (WRs) to transmit data (or a read request) to the remote system. A work request may have one or more opcodes which may include: send, send with solicited event, RDMA Write, RDMA Read, etc. The receive queue is used for the application to post work requests with buffers for placing untagged messages from the remote system. Elements in the completion queue indicate, to the application, that a request has been completed. The application may poll the completion queue to identify any completed operations. The CQ may be associated with one or more send queues and/or one or more receive queues)
Regarding claim 5, the modified Biederman taught the system according to claim 1, as described above. The modified Biederman further teaches wherein a network device is to estimate a communication load experienced by the network device, and to pull a work descriptor in response to finding that the estimated communication load is sufficiently low, in accordance with a defined criterion. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0035] explains…. A send queue (also referred to as a “submission queue”) is used for the application to post work requests (WRs) to transmit data (or a read request) to the remote system. A work request may have one or more opcodes which may include: send, send with solicited event, RDMA Write, RDMA Read, etc. The receive queue is used for the application to post work requests with buffers for placing untagged messages from the remote system. Elements in the completion queue indicate, to the application, that a request has been completed. The application may poll the completion queue to identify any completed operations. The CQ may be associated with one or more send queues and/or one or more receive queues paragraph [0104],[0105] explains…..In some embodiments, PCC (Programmable congestion Control) may be implemented. In some embodiments, the PCC may use time control windows to schedule traffic. In some embodiments, PCC may measure the times it takes for packets to transverse the network, and then adjust the traffic accordingly. )
Regarding claim 15, Biederman teaches a method, comprising: issuing work requests from one or more processors to multiple network devices that connect the one or more processors to a network, by the one or more processors posting work descriptors on one or more shared queues that are each accessible to the multiple network devices; (see Biederman paragraph [0027] explains in such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer). and in the multiple network devices, pulling the work descriptors from the one or more shared queues and executing the work requests responsively to the work descriptors, wherein the descriptors are not pre-assigned by the one or more processors to any specific network device. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0035] explains…. A send queue (also referred to as a “submission queue”) is used for the application to post work requests (WRs) to transmit data (or a read request) to the remote system. A work request may have one or more opcodes which may include: send, send with solicited event, RDMA Write, RDMA Read, etc. The receive queue is used for the application to post work requests with buffers for placing untagged messages from the remote system. Elements in the completion queue indicate, to the application, that a request has been completed. The application may poll the completion queue to identify any completed operations. The CQ may be associated with one or more send queues and/or one or more receive queues)
While it can be understood Biederman teaches wherein the work descriptors are not pre-assigned by the one or more processors to any specific network device.
However to further explain this Bachmutsky explains for example, given n priorities, every enqueue and dequeue buffer pair may be assigned a different priority such that n buffers are allocated for enqueue requests and n buffers are allocated for dequeue requests. Each incoming request has a priority that is either pre-assigned by the requesting core/thread or assigned by the QMD upon receipt by the QMD. Each request is then stored in a buffer that corresponds to the request's priority (1-n) and/or type (enqueue or dequeue) and/or other parameters. (see paragraph [0029])
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement of managing latency for applications(See paragraph[0052])
Regarding claim 16, the modified Biederman taught the method according to claim 15, as described above. The modified Biederman wherein posting a work descriptor on the shared queue comprises making the work descriptor available to any of the multiple network devices. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0057] explains…. In some embodiments, the entries in the TPTs 116a, 116b may be used to pace the fetching of elements in the send queues 208a, 208b by the NICs 108a, 108b. I)
Regarding claim 18, the modified Biederman taught the method according to claim 15, as described above. The modified Biederman teaches wherein pulling a work descriptor from the shared queue, by a network device, is performed not in response to an assignment of the work descriptor to the network device by the one or more processors. (see Biederman paragraph [0027] … Further still, the applications 114a, 114b may include timing information to provide control over how individual messages (e.g., sends, writes, reads etc.) go out onto the wire, via time information inserted in message work descriptors (e.g., work queue entries, or WQEs). In such embodiments, applications 114a, 114b post these the descriptors to the NICs 108a, 108b, requesting data transfer. The NIC 108b or NIC 108b may include the timing information in a message work descriptor in one or more entries of the TPTs 116a, 116b). ….paragraph [0035] explains…. A send queue (also referred to as a “submission queue”) is used for the application to post work requests (WRs) to transmit data (or a read request) to the remote system. A work request may have one or more opcodes which may include: send, send with solicited event, RDMA Write, RDMA Read, etc. The receive queue is used for the application to post work requests with buffers for placing untagged messages from the remote system. Elements in the completion queue indicate, to the application, that a request has been completed. The application may poll the completion queue to identify any completed operations. The CQ may be associated with one or more send queues and/or one or more receive queues)
6. Claims 3, 6, 17, 19 are rejected under 35 U.S.C. §103 as being unpatentable over Biederman et al (US 2024/0111691A1) in view of BAchmutsky et al(US 2019/0317802A1)
in further view of Sankaran(WO-2018125250-A1)
Regarding claim 3, Biederman taught the system according to claim 1, as described above. Biederman alone does not explicitly disclose these limitations however further combined with Sankaran teaches wherein, upon issuing a work descriptor on a shared queue, a processor is to issue a doorbell to the multiple network devices, notifying the multiple network devices that the work descriptor has been posted. (see Sankaran paragraph [0666] explains… For devices supporting the Shared Virtual Memory (SVM) capability, the doorbell and work-queues are set up by the kernel-mode driver to identify the Process Address Space Identifier (PASID) of the application process to which the doorbell and work-queue is mapped. When processing a work item dispatched through a particular work-queue, the device uses the respective PASID configured for that work-queue for virtual to physical address translations through the I/O Memory Management Unit (IOMMU).see [00667], ) _
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement workload based on characteristic (See paragraph[0153])
Regarding claim 6, Biederman taught the system according to claim 1, as described above. Biederman alone does not explicitly disclose these limitations however further combined with Sankaran teaches wherein: the one or more shared queue are multiple shared queues that are each accessible to the multiple network devices; the one or more processors are to issue the work requests to the multiple network devices by posting the work descriptors on the multiple shared queues; and a network device is to choose a queue from among at least the multiple shared queues in accordance with a Quality-of-Service (QoS) criterion, and to pull a work descriptor from the chosen queue. (see Sankaran paragraph [0433] As illustrated in FIG. 34, in one implementation, there are two different types of work queues: dedicated work queues 3400 and shared work queues 3401. Dedicated work queues 3400 store descriptors for a single application 3413 while shared work queues 3401 store descriptors submitted by multiple applications 3410-3412. A hardware interface/arbiter 3402 dispatches descriptors from the work queues 3400-3401 to the accelerator processing engines 3405 in accordance with a specified arbitration policy (e.g., based on the processing requirements of each application 3410-3413 and QoS/fairness policies).)
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement workload based on characteristic (See paragraph[0153])
Regarding claim 17, Biederman taught the method according to claim 15, as described above. Biederman alone does not explicitly disclose these limitations however further combined with Sankaran teaches further comprising, upon issuing a work descriptor on a shared queue, issuing a doorbell to the multiple network devices, notifying the multiple network devices that the work descriptor has been posted. (see Sankaran paragraph [0666] explains… For devices supporting the Shared Virtual Memory (SVM) capability, the doorbell and work-queues are set up by the kernel-mode driver to identify the Process Address Space Identifier (PASID) of the application process to which the doorbell and work-queue is mapped. When processing a work item dispatched through a particular work-queue, the device uses the respective PASID configured for that work-queue for virtual to physical address translations through the I/O Memory Management Unit (IOMMU).see [00667], ) _
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement workload based on characteristic (See paragraph[0153])
Regarding claim 19, Biederman taught the method according to claim 15, as described above. Biederman alone does not explicitly disclose these limitations however further combined with Sankaran teaches wherein: the one or more shared queue are multiple shared queues that are each accessible to the multiple network devices; issuing the work requests to the multiple network devices comprises posting the work descriptors on the multiple shared queues; and pulling the work descriptors comprises choosing a queue from among at least the multiple shared queues in accordance with a Quality-of-Service (QoS) criterion, and pulling a work descriptor from the chosen queue. (see Sankaran paragraph [0433] As illustrated in FIG. 34, in one implementation, there are two different types of work queues: dedicated work queues 3400 and shared work queues 3401. Dedicated work queues 3400 store descriptors for a single application 3413 while shared work queues 3401 store descriptors submitted by multiple applications 3410-3412. A hardware interface/arbiter 3402 dispatches descriptors from the work queues 3400-3401 to the accelerator processing engines 3405 in accordance with a specified arbitration policy (e.g., based on the processing requirements of each application 3410-3413 and QoS/fairness policies).)
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improvement workload based on characteristic (See paragraph[0153])
7. Claims 7 and 20 are rejected under 35 U.S.C. §103 as being unpatentable over Biederman et al (US 2024/0111691A1) in view of BAchmutsky et al(US 2019/0317802A1)
in further view of Thottethodi (WO2017156549-A1)
Regarding claim 7, Biederman taught the system according to claim 1, as described above. Biederman alone does not teach these limitations however further combined with Thottethodi teaches wherein a shared queue is associated with a shared read pointer that is indicative of a head of the shared queue, and wherein, upon attempting to pull a work descriptor from the shared queue, a network device is to increment the read pointer using an atomic fetch-and-add command. (see Thottethodi paragraph [0024] explains in other embodiments, the tail pointer is atomically adjusted (either increased or decreased) by slightly more than the size of the message (e.g., up to 10% more, up to 25% more or up to 50% more). The tail pointer adjustment may be done modulo arithmetic in the case of a circular queue, or regular arithmetic for other types of queue address space schemes. In the disclosed RIMA system, the tail-pointer 111 is part of the append queue's attributes and can be maintained in the TPTB by the NIC 107. As such, the RIMA's atomic-fetch-and-add of the tail pointer 111 is very fast._
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improve on memory overhead (See paragraph [0007])
Regarding claim 20, Biederman taught the method according to claim 15, as described above. Biederman alone does not teach these limitations however further combined with Thottethodi teaches wherein a shared queue is associated with a shared read pointer that is indicative of a head of the shared queue, and comprising, upon attempting to pull a work descriptor from the shared queue, incrementing the read pointer using an atomic fetch-and-add command. (see Thottethodi paragraph [0024] explains in other embodiments, the tail pointer is atomically adjusted (either increased or decreased) by slightly more than the size of the message (e.g., up to 10% more, up to 25% more or up to 50% more). The tail pointer adjustment may be done modulo arithmetic in the case of a circular queue, or regular arithmetic for other types of queue address space schemes. In the disclosed RIMA system, the tail-pointer 111 is part of the append queue's attributes and can be maintained in the TPTB by the NIC 107. As such, the RIMA's atomic-fetch-and-add of the tail pointer 111 is very fast._
One of ordinary skill in the art would have been motivated to make this modification before the effective filling data of the claimed invention to further improve on memory overhead (See paragraph [0007])
Allowable Subject Matter
8. Claims 8-11 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.
9. 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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GERALD A SMARTH whose telephone number is (571)270-1923. The examiner can normally be reached on Monday-Thursday 6am-4:30pm ET.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Joseph Avellino can be reached on 571-272-7784. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/GERALD A SMARTH/Primary Examiner, Art Unit 2478
Prosecution Insights