Prosecution Insights
Last updated: August 17, 2026
Application No. 18/618,308

PARALLIZATION OF NETWORK COMMUNICATIONS

Non-Final OA §103
Filed
Mar 27, 2024
Examiner
ONAT, UMUT
Art Unit
Tech Center
Assignee
NVIDIA Corporation
OA Round
1 (Non-Final)
80%
Grant Probability
Favorable
1-2
OA Rounds
8m
Est. Remaining
99%
With Interview

Examiner Intelligence

Grants 80% — above average
80%
Career Allowance Rate
427 granted / 535 resolved
+19.8% vs TC avg
Strong +28% interview lift
Without
With
+28.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 0m
Avg Prosecution
24 currently pending
Career history
561
Total Applications
across all art units

Statute-Specific Performance

§101
15.1%
-24.9% vs TC avg
§103
44.5%
+4.5% vs TC avg
§102
14.2%
-25.8% vs TC avg
§112
18.6%
-21.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 535 resolved cases

Office Action

§103
DETAILED ACTION Claims 1-20 are pending in the application. 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 . 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. Examiner’s Notes The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention. Claims 1, 2, 4, 6-9, 11, 13-16, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Raindel et al. (US 2016/0117277 A1; hereinafter “Raindel”) in view of Ohtsuji et al. (US 2022/0222121 A1; hereinafter “Ohtsuji”). With respect to claim 1, Raindel teaches: A Central Processing Unit (CPU) (see e.g. Raindel, Fig. 1: “CPU 22”) comprising: a control circuit controlling operation of the CPU (see e.g. Raindel, paragraph 30: “the CPU allocates a work queue in the host memory for collaborative use by the CPU and the co-processor in controlling an I/O device of the computer. To transmit or receive data, the CPU prepares work requests for insertion in this work queue, specifying the I/O operations that are to be executed by the I/O device”; and Fig. 1), wherein the control circuit causes the CPU to (see e.g. Raindel, paragraphs 30-35): receive, from a Network Interface Card (NIC) (see e.g. Raindel, Fig. 1: “NIC 28”), through a communication network (see e.g. Raindel, Fig. 1: “30”; and paragraph 37: “a packet network 30”), a plurality of data packets (see e.g. Raindel, paragraph 37: “a NIC 28, which connects computer 20 to a packet network 30”; and paragraph 34: “a NIC, which couples the computer to a network, and thus transmits and receives the data by exchanging data packets with other nodes over the network”); post in a Receive Queue (RQ) (see e.g. Raindel, Fig. 1: “RQ 42”; and paragraph 40: “a receive queue (RQ) 42”) of a Graphics Processing Unit (GPU) (see e.g. Raindel, Fig. 1: “GPU 32”; and paragraph 41: “one or more queues among work queues 40, 42 and/or completion queues 44 are shared between CPU 22 and GPU 32”) a plurality of Work Queue Entries (WQEs) (see e.g. Raindel, paragraph 40: “posts work items (WQEs) in queues 40 and 42”), each WQE of the plurality of WQEs corresponding to a packet of the received plurality of packets (see e.g. Raindel, paragraph 40: ‘In response to the work requests submitted to QPs 38, NIC driver software posts work items (WQEs) in queues 40 and 42… receive WQEs (in RQ 42) indicate buffers in memory 24 to which NIC 28 is to write data received from the network”); and poll, [in parallel], a plurality of Completion Queue Entries (CQEs) (see e.g. Raindel, paragraph 4: “a completion report, in the form of a completion queue element (CQE)”) from a Completion Queue (CQ) (see e.g. Raindel, Fig. 1: “CQ 44”; and paragraph 41: “completion queues 44”; and paragraph 52: “GPU 32 polls completion queue 44 to detect a particular CQE 60 as soon as it has been written to the queue… GPU can then use specialized logic to detect that a CQE was written to the completion queue and trigger the appropriate polling and processing”) of the GPU (see e.g. Raindel, paragraph 41: “one or more queues among work queues 40, 42 and/or completion queues 44 are shared between CPU 22 and GPU 32”), each CQE of the plurality of CQEs corresponding to a WQE of the plurality of WQEs (see e.g. Raindel, paragraph 40: “NIC 28 reads and executes the WQEs and thus carries out the requested operations… receive WQEs (in RQ 42) indicate buffers in memory 24 to which NIC 28 is to write data received from the network. Upon completion of a work request, NIC 28 posts a completion report (CQE) to a completion queue 44”; and paragraph 41: “composing work requests and monitoring their completion (based on received CQEs)”). Even though Raindel discloses GPU being configured for parallel processing (see e.g. Raindel, paragraph 37), Raindel does not explicitly disclose the polling being performed “in parallel”. However, Ohtsuji teaches: in parallel (see e.g. paragraph 25: “polls the completion queue 62”; and paragraph 31: “sets of “connection”, “completion queue”, and “polling” processing are executed in parallel”) Raindel and Ohtsuji are analogous art because they are in the same field of endeavor: work item processing by polling completion queues. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Raindel with the teachings of Ohtsuji. The motivation/suggestion would be to improve processing efficiency. With respect to claim 2, Raindel as modified teaches: The CPU of claim 1, wherein posting the plurality of WQEs in the RQ of the GPU comprises: creating the plurality of WQEs in the RQ of the GPU based on the received plurality of packets (see e.g. Raindel, paragraph 40: “In response to the work requests submitted to QPs 38, NIC driver software posts work items (WQEs) in queues 40 and 42… receive WQEs (in RQ 42) indicate buffers in memory 24 to which NIC 28 is to write data received from the network”); issuing a memory barrier instruction (see e.g. Raindel, paragraph 45: “CPU locks QP 38, allocates a work queue entry, and writes the contents of the work request to the allocated entry… CPU does not activate the work request”; and paragraph 46: “Instead, CPU 22 queues a command to activate the work request in GPU work queue 46, following the command to perform processing flow 50. The command specifies one or more write operations to be performed by GPU 32 in order to submit work request 52 for execution by NIC 28”) for a doorbell record of the NIC (see e.g. Raindel, paragraph 46: “the command may comprise write instructions, which tell the GPU to increment the producer index of send queue 40 and to “ring the doorbell” of the NIC, i.e., to write a doorbell record to a designated doorbell address of NIC 28 on bus 26”); and updating the doorbell record of the NIC based on the created plurality of WQEs (see e.g. Raindel, paragraph 46: “CPU 22 queues a command to activate the work request in GPU work queue 46… the command may comprise write instructions, which tell the GPU to increment the producer index of send queue 40 and to “ring the doorbell” of the NIC, i.e., to write a doorbell record to a designated doorbell address of NIC 28 on bus 26”; and paragraph 47: “Upon completing flow 50 and reading the subsequent activation command from queue 46… It then writes a doorbell record to the designated doorbell address of NIC 28, indicating the QP number and the new value of the producer index”). With respect to claim 4, Raindel as modified teaches: The CPU of claim 1, wherein polling, in parallel, the plurality of CQEs from the CQ of the GPU comprises: locking the CQ of the GPU (see e.g. Raindel, paragraph 55: “either the CPU or the GPU may deliberately delay bookkeeping-related processing of the CQEs, in order to allow for work to accumulate and achieve better work batching by the CPU”; and paragraph 45: “locks QP 38”); storing data from each CQE of the plurality of CQEs to memory of the GPU (see e.g. Raindel, paragraph 40: “Upon completion of a work request, NIC 28 posts a completion report (CQE) to a completion queue 44 in memory 24, which is then read by the appropriate software process”; and paragraph 41: “completion queues 44 are shared between CPU 22 and GPU 32”); issuing a memory barrier instruction (see e.g. Raindel, paragraph 45: “CPU locks QP 38, allocates a work queue entry, and writes the contents of the work request to the allocated entry… CPU does not activate the work request”; and paragraph 46: “Instead, CPU 22 queues a command to activate the work request in GPU work queue 46, following the command to perform processing flow 50. The command specifies one or more write operations to be performed by GPU 32 in order to submit work request 52 for execution by NIC 28”) for a doorbell record of the NIC (see e.g. Raindel, paragraph 46: “the command may comprise write instructions, which tell the GPU to increment the producer index of send queue 40 and to “ring the doorbell” of the NIC, i.e., to write a doorbell record to a designated doorbell address of NIC 28 on bus 26”); updating the doorbell record of the NIC (see e.g. Raindel, paragraph 46: “CPU 22 queues a command to activate the work request in GPU work queue 46… the command may comprise write instructions, which tell the GPU to increment the producer index of send queue 40 and to “ring the doorbell” of the NIC, i.e., to write a doorbell record to a designated doorbell address of NIC 28 on bus 26”; and paragraph 47: “Upon completing flow 50 and reading the subsequent activation command from queue 46… It then writes a doorbell record to the designated doorbell address of NIC 28, indicating the QP number and the new value of the producer index”); and unlocking the CQ of the GPU (see e.g. Raindel, paragraph 55: “either the CPU or the GPU may deliberately delay bookkeeping-related processing of the CQEs, in order to allow for work to accumulate and achieve better work batching by the CPU”; and paragraph 46: “unlocks QP 38”). Raindel does not explicitly disclose locking/unlocking the CQ 44. However, since Raindel discloses deliberately delaying processing of CQEs within the CQ 44 (see Raindel, paragraph 55) and locking/unlocking other queues (e.g. queue pair 38; see paragraphs 45-46), it would have been obvious to one of ordinary skill in the art to implement a locking/unlocking mechanism for the CQ 44 in order to implement the delayed processing of the CQEs. The motivation/suggestion for such a modification would be to better manage when the CQEs can be accessed which would improve the reliability and robustness of the delayed CQE processing. With respect to claim 6, Raindel as modified teaches: The CPU of claim 4, wherein polling, in parallel, the plurality of CQEs from the CQ of the GPU comprises polling a plurality of CQEs from each of a plurality of executing threads (see e.g. Raindel, paragraph 52: “GPU 32 polls completion queue 44 to detect a particular CQE 60 as soon as it has been written to the queue by NIC 28”; and paragraph 53: “To invoke CQE polling and processing by GPU 32, CPU 22 typically places a command in GPU work queue 46, instructing the GPU to poll completion queue 44 until a specified word in queue 44 receives a predefined value”; note that GPU polling the CQ 44 inherently teaches GPU executing corresponding threads to poll the CQ 44). With respect to claim 7, Raindel as modified teaches: The CPU of claim 1, wherein the communication network comprises an Ethernet network (see e.g. Raindel, paragraph 37: “a packet network 30, such as an InfiniBand or Ethernet switch fabric”). With respect to claims 8-9, 11, and 13-14: Claims 8-9, 11, and 13-14 are directed to a system comprising a communication network, a NIC, a GPU and a CPU to implement functions corresponding to the functions implemented by the CPU disclosed in claims 1-2, 4 and 6-7, respectively; please see the rejections directed to claims 1-2, 4 and 6-7 above which also cover the limitations recited in claims 8-9, 11, and 13-14. Note that, Raindel also discloses a system 20 including a communication network 30, a NIC 28, a GPU 32, and a CPU 22 to implement the functions of the CPU disclosed in claims 1-2, 4 and 6-7 (see e.g. Raindel, Fig. 1). With respect to claims 15-16, 18, and 20: Claims 15-16, 18, and 20 are directed to a method corresponding to the functions implemented by the CPU disclosed in claims 1-2, 4 and 6, respectively; please see the rejections directed to claims 1-2, 4 and 6 above which also cover the limitations recited in claims 15-16, 18, and 20. Claims 3, 10, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Raindel in view of Ohtsuji as applied to claims 2, 9, and 16 above, and further in view of Matthews et al. (US 10,067,690 B1; hereinafter Matthews). With respect to claim 3, Raindel as modified teaches: The CPU of claim 2, wherein the memory of the GPU comprises a pre-allocated portion of memory mapped to the NIC (see e.g. Raindel, paragraph 38: “Memory 24 contains program code, such as operating system, driver, and application programs run by CPU 22, as well as data 36. This data can be accessed not only by the CPU, but also by NIC 28 and GPU 32 by direct memory access via bus 26. The region of data 36 in memory 24 contains buffers holding data to be transmitted by NIC 28 over network 30 and for data received by NIC 28 from network 30 and written to memory 24. Alternatively, at least some of these buffers (or all of them) could be located in memory that is attached to GPU 32 or to another device in computer 20”; and paragraph 39), Raindel does not but Matthews teaches: wherein the pre-allocated portion of memory mapped to the NIC is split into a plurality of strides (see e.g. Matthews, column 8, lines 28-32: “generate one or more lists including one or more strides. A stride is generated by the link memory by assigning a sequence identifier to a set of one or more storage data elements associated with the incoming data elements received”) of Maximum Transmission Unit (MTU) fixed size (see e.g. Matthews, column 1, lines 22-24: “sizing the internal memories and processing units to be equal in size to the maximum transmission unit (MTU)”), and wherein each WQE of the plurality of WQEs references a different stride of the plurality of strides (see e.g. Matthews, column 8, lines 29-32: “A stride is generated by the link memory by assigning a sequence identifier to a set of one or more storage data elements associated with the incoming data elements received”). Raindel and Matthews are analogous art because they are in the same field of endeavor: managing network packet transmissions. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Raindel with the teachings of Matthews. The motivation/suggestion would be to improve memory management associated with network packets (see e.g. Matthews, column 8, lines 42-48). With respect to claim 10: Claim 10 is directed to a system comprising a communication network, a NIC, a GPU and a CPU to implement functions corresponding to the functions implemented by the CPU disclosed in claim 3; please see the rejection directed to claim 3 above which also covers the limitations recited in claim 10. With respect to claim 17: Claim 17 is directed to a method corresponding to the functions implemented by the CPU disclosed in claim 3; please see the rejections directed to claim 3 above which also covers the limitations recited in claim 17. Claims 5, 12, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Raindel in view of Ohtsuji as applied to claims 4, 11, and 18 above, and further in view of Craddock et al. (US 2003/0023786 A1; hereinafter Craddock). With respect to claim 5, Raindel as modified teaches: The CPU of claim 4, wherein storing data from each CQE of the plurality of CQEs to memory of the GPU comprises: Raindel does not but Craddock teaches: reading an index for the plurality of CQEs (see e.g. Craddock, paragraph 156: “ HCA first checks that the CQ 1300 is not full by comparing the CQ head index 1336 with the CQ tail index 1338 incremented by one”); checking data of a CQE of the plurality of CQEs corresponding to the index for errors (see e.g. Craddock, paragraph 156: “If the CQ head index 1336 is equal to the incremented CQ tail index 1338, the CQ 1300 is full, and the operation is terminated in error. If the CQ 1300 is not full”); in response to the data of the CQE of the plurality of CQEs corresponding to the index being error free, storing the data of the CQE of the plurality of CQEs corresponding to the index in the memory of the GPU (see e.g. Craddock, paragraph 156: “If the CQ 1300 is not full, the HCA 1320 determines the location at which to store the CQE by first locating the page using the CQPT index 1332 in the CQ tail index 1338 (prior to the increment)”; and paragraph 158: “After storing the CQE”); and incrementing the index of the plurality of CQEs (see e.g. Craddock, paragraph 157: “After incrementing, if the page index wraps, the CQPT index 1332 is incremented by one. If the CQPT index 1332 wraps, the CQ tail index 1338 has wrapped to the top of the completion queue 1300”; and paragraph 158: “incremented CQ tail index 1338”). Raindel and Craddock are analogous art because they are in the same field of endeavor: managing CQ storage operations. Therefore, it would have been obvious to one with ordinary skill in the art before the effective filing date of the claimed invention to modify Raindel with the teachings of Craddock. The motivation/suggestion would be to improve CQ tracking and storage management. With respect to claim 12: Claim 12 is directed to a system comprising a communication network, a NIC, a GPU and a CPU to implement functions corresponding to the functions implemented by the CPU disclosed in claim 5; please see the rejection directed to claim 5 above which also covers the limitations recited in claim 12. With respect to claim 19: Claim 19 is directed to a method corresponding to the functions implemented by the CPU disclosed in claim 5; please see the rejections directed to claim 5 above which also covers the limitations recited in claim 19. CONCLUSION The prior art made of record and not relied upon is considered pertinent to applicant's disclosure: Markthub et al. (US 2025/0045216 A1) discloses a plurality of receive queues that can be accessed by a NIC 224 to store incoming data packets from a network until a GPU 215 is ready to process the packet (see paragraph 79). Contact Information Any inquiry concerning this communication or earlier communications from the examiner should be directed to Umut Onat whose telephone number is (571)270-1735. The examiner can normally be reached M-Th 9:00-7:30. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin L Young can be reached at (571) 270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /UMUT ONAT/Primary Examiner, Art Unit 2194
Read full office action

Prosecution Timeline

Mar 27, 2024
Application Filed
Jul 15, 2026
Non-Final Rejection mailed — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12705080
LOAD BALANCING VIRTUAL COMPUTING INSTANCES ASSOCIATED WITH VIRTUAL GRAPHICS PROCESSING UNITS
5y 0m to grant Granted Aug 11, 2026
Patent 12707371
CONTEXT-AWARE MOBILE DEVICE MANAGEMENT
3y 6m to grant Granted Aug 11, 2026
Patent 12693912
AUTOMATICALLY GENERATING APPLICATION PROGRAMMING INTERFACES
3y 9m to grant Granted Jul 28, 2026
Patent 12675349
METHOD AND SYSTEM FOR REAL-TIME COMMUNICATION BETWEEN MULTIPLE BROWSER WINDOWS
3y 8m to grant Granted Jul 07, 2026
Patent 12645511
FULL EVENT TRACKING METHOD AND APPARATUS FOR PAGE, COMPUTER DEVICE, AND STORAGE MEDIUM
1y 6m to grant Granted Jun 02, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

Strategy Recommendation AI-generated — please review before filing

Get a prosecution strategy drawn from examiner precedents, rejection analysis, and claim mapping.
Typically takes 5-10 seconds — AI-generated, attorney review required before filing

Prosecution Projections

1-2
Expected OA Rounds
80%
Grant Probability
99%
With Interview (+28.2%)
3y 0m (~8m remaining)
Median Time to Grant
Low
PTA Risk
Based on 535 resolved cases by this examiner. Grant probability derived from career allowance rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month