DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This Office action is in response to the amendment filed on 01/27/2026.
Claims 11-20 are presented for examination.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 11-20 are rejected under 35 U.S.C. 103 as being unpatentable over Vegesna et al. (US 2021/0297343 A1), in view of Eberle et al. (US 2023/0261794 A1), Foong et al. (US 2009/0086736 A1), Comparan et al. (US 2014/0281402 A1).
As to claim 11, Vegesna discloses the invention as claimed, including a method for packet processing in a system comprising multiple packet processing engines (Fig. 1, 19, DPU group; ¶0045, “one of DPUs 17A-17H (collectively, “DPUs 17”) for processing streams of information, such as network packets…DPUs 17 may be arranged into multiple different DPU groups 19, each including any number of DPUs”; ¶0046-¶0047), the method comprising:
receiving, at a scheduler operating in a first mode of operation (i.e., out of order) in which packets are distributed among the multiple packet processing engines for processing (Fig. 1, 19, DPU group), an ordering request (Figs. 13-14; ¶0144; ¶0165, “a request message arrives out of order at the FCP receiver”; ¶0188, “sender state handler 262 participates in a request generation by generating a request to a request scheduler 264 (276)”; ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0189, “packet scheduler 266A (282). FCP sender state handler 262 parses the incoming fabric grants (280) against the FCP transmit queue state as the arrivals could be out of order. The accepted FCP grants are queued in separate queues of packet scheduler 266A (282)”; ¶0209);
switching, by the scheduler in response to the ordering request, to a second mode of operation (¶0073, “DF component 36A is configured to reorder the received packets to recreate the original sequence of the packet flow prior to transmitting the packet flow to the destination server 12, 13”; ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0209, “The grant scheduler 314A reacts to the reorder buffer state at egress reorder state handler 312 (296) and stops sending all the new grants if the reorder buffer state (out of order bytes, grants in flight, and buffer occupancy) reaches a limit”; ¶0212; ¶0239, “the destination DPU first reorders the FCP packets into an original sequence of the packet flow sent by the source storage node 12/compute node 13. The source DPU may assign a packet sequence number to each of the FCP packets of the packet flow, enabling the destination DPU to reorder the FCP packets based on the packet sequence number of each of the FCP packet”);
determining, by the scheduler, that the in-order processing is complete (Figs. 14-16; ¶0167; ¶0170, “At the FCP receiver, DBN indicates the last block that has been received after the reorder processing is complete”; ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0184, “At a packet reorder engine 257 of receiver node 252, the packets may be reordered on a per tunnel context before they are pushed to application queues 259. The example of FIG. 12 shows that receiver node 252 may be performing packet reordering and enqueuing a packet after the reorder is complete”; ¶0209).
Although Vegesna discloses switching, by the scheduler in response to the ordering request, to a second mode of operation (¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”), Vegesna does not specifically disclose switching, by the scheduler in response to the ordering request, to a second mode of operation in which all packets belonging to a same ordering domain are sent to a single engine for in-order processing.
However, Eberle discloses switching, by the scheduler in response to the ordering request, to a second mode of operation in which all packets belonging to a same ordering domain are sent to a given engine for in-order processing (Fig. 1, “ordered-unordered and unreliable-ordered”; ¶0094, “FIG. 3B, REQ2 and REQ4 arrive OOO and are held in the reorder buffer until they become in-order once REQ1 and REQ3, respectively, are received”; ¶0097, “In FIG. 3B, REQ2 is the first REQ to arrive at the destination and open a flow. According to the history filter, REQ1 was not received. REQ2 was, therefore, received out-of-order and forwarded to the reorder buffer. Next, REQ1 is received and forwarded. Whenever, a REQn is forwarded, the reorder buffer is checked whether it contains REQn+1”; ¶0116, “In-order delivery of responses necessitates a response buffer to hold RSPs until they are in order”;
¶0191, “enforcing packet ordering in the network becomes onerous and reduces performance. If the network cannot guarantee packet ordering, it will violate the memory consistency model. Because enforcing ordering in the network reduces performance, endpoint devices (the final target of transported memory operations) may reorder packets to enforce a memory consistency model”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vegesna to include switching, by the scheduler in response to the ordering request, to a second mode of operation in which all packets belonging to a same ordering domain are sent to a given engine for in-order processing, as taught by Eberle because it would improve the efficiency of the CPU's memory cache by reducing latency and enhancing performance (Eberle; Fig. 1, “ordered-unordered and unreliable-ordered”; ¶0116; ¶0271).
Foong, on the other hand discloses a second mode of operation in which all packets belonging to a same ordering domain are sent to a single engine for in-order processing (Fig. 3; ¶0008; ¶0009, “a single processing core may have the ability to maintain the maximum throughput of a single network flow. Therefore, in-order packet processing within such systems may be achieved relatively easily. For example, in-order processing may be achieved by ensuring that all packets belonging to the same flow are processed by a single processing core”; ¶0010). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vegesna to include a second mode of operation in which all packets belonging to a same ordering domain are sent to a single engine for in-order processing, as taught by Foong because doing so would prevent data corruption (Foong; ¶0008- ¶0010).
Vegesna does not specifically disclose switching, by the scheduler, back to the first mode.
However, Comparan discloses switching, by the scheduler, back to the first mode (Figs. 10-11; ¶0104, “Scheduler 1008 may determine the order of each ready to be executed instruction is provided to execution stage 712 by multiplexor 1006.1. As noted above, several instructions operating in the out-of-order mode may be located in issue queue 722 and are ready to be executed by execution stage 712. Several instructions operating in the in-order mode may be located in plurality of latches 1004.1 and 1004.2 and are ready to be executed by execution stage 712”; ¶0108, “pipeline 700 dynamically switches between in-order mode and out-of-order mode. In an embodiment, a compiler may include code that informs hybrid pipeline 700 whether in-order mode or out-of-order mode is more appropriate. The compiler could make the determination to dynamically switch by scheduling the code a first time and rating the performance of the execution of the instructions. The compiler may then schedule the code a second time to speculate the execution of the instructions in the out-of-order mode”; ¶0114, “dynamically switches between out-of-order mode and in-order mode”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vegesna to include switching, by the scheduler, back to the first mode, as taught by Comparan because doing so would increase the flexibility of data processing (Comparan; ¶0104; ¶0108).
As to claim 12, Vegesna discloses the method of claim 11, further comprising:
issuing, in response to the ordering request, a fence instruction to one or more other processing engines; receiving a fence acknowledgment from each of the one or more other processing engine, the fence acknowledgment; and indicating that a respective engine has finished committing instructions (¶0117, “generates rFCP grant/ACK messages for every tunnel and instructs packet buffer 174 to send the rFCP grant/ACK messages. In response to receipt of FCP and rFCP data packets, packet buffer 174 optionally sends the received data packets to packet reorder engine 176 for reordering and reassembly”).
As to claim 13, Vegesna discloses the method of claim 12, wherein the ordering request comprises an indication that a parameter associated with processes implemented by at least one of the multiple packet processing engines has changed (¶0073, “DF component 36A is configured to reorder the received packets to recreate the original sequence of the packet flow prior to transmitting the packet flow to the destination server 12, 13”; ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0239, “the destination DPU first reorders the FCP packets into an original sequence of the packet flow sent by the source storage node 12/compute node 13. The source DPU may assign a packet sequence number to each of the FCP packets of the packet flow, enabling the destination DPU to reorder the FCP packets based on the packet sequence number of each of the FCP packet”).
As to claim 14, Vegesna discloses the method of claim 13, further comprising: incrementing a shared counter when an ordering request is received; and decrementing the shared counter when the ordering request is complete, wherein the shared counter is stored in a shared memory (¶0105, “timeout counters 168, which may include a packet reorder timer”; ¶0183, “meter 258 is incremented on the grant transmit time and decremented on the packet arrival time”; ¶0203, “The outgoing non-FCP packets are enqueued with the packet scheduler where they are rate limited if the traffic needs to be shared between FCP/non-FCP queues”; ¶0215, “the grant pacer keeps track of pending blocks over fabric by incrementing a granted block counter at the time of sending FCP grant messages and decrementing the counter with the data block count at the time of receiving FCP data packets”).
As to claim 15, Vegesna discloses the method of claim 13, wherein the shared memory supports a request state, a response state, and a completion state (Figs. 14-16; ¶0167; ¶0170, “At the FCP receiver, DBN indicates the last block that has been received after the reorder processing is complete” ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0184, “At a packet reorder engine 257 of receiver node 252, the packets may be reordered on a per tunnel context before they are pushed to application queues 259. The example of FIG. 12 shows that receiver node 252 may be performing packet reordering and enqueuing a packet after the reorder is complete”; ¶0203; ¶0209).
As to claim 16, Vegesna discloses the method of claim 14, further comprising changing, by the given engine, a state of the shared memory to the response state when the acknowledgment is received from each engine (¶0084, “In response to receiving the packets of the packet flow, DF component 36A of DPU 17M may optionally reorder the packets of the packet flow based on sequence numbers of the packets. As such, with respect to full routing tables for the data center, only the core switches 22 may need to perform full lookup operations”; ¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”).
As to claim 17, Vegesna discloses the method of claim 15, further comprising changing the state of the shared memory to the completion state when in-order processing is complete (¶0170, “At the FCP receiver, DBN indicates the last block that has been received after the reorder processing is complete”; ¶0184, “At a packet reorder engine 257 of receiver node 252, the packets may be reordered on a per tunnel context before they are pushed to application queues 259. The example of FIG. 12 shows that receiver node 252 may be performing packet reordering and enqueuing a packet after the reorder is complete”; ¶0209).
As to claim 18, Vegesna discloses the method of claim 11, wherein in the first mode the packets are distributed among the packet processing engines without consideration of an ordering identifier (i.e., out-of-order; ¶0144; ¶0165, “a request message arrives out of order at the FCP receiver”; ¶0189, “FCP sender state handler 262 parses the incoming fabric grants (280) against the FCP transmit queue state as the arrivals could be out of order. The accepted FCP grants are queued in separate queues of packet scheduler 266A (282)”; ¶0209, “The grant scheduler 314A reacts to the reorder buffer state at egress reorder state handler 312 (296) and stops sending all the new grants if the reorder buffer state (out of order bytes, grants in flight, and buffer occupancy) reaches a limit”).
As to claim 19, Vegesna discloses the method of claim 11, further comprising: receiving at an Access Control List (ACL) table an ordering constraint, wherein the ordering constraint updates the ACL table (¶0073, “DF component 36A is configured to reorder the received packets to recreate the original sequence of the packet flow prior to transmitting the packet flow to the destination server 12, 13. In other examples, DF component 36A may not need to reorder the received packets of the packet flow prior to transmitting the packet flow to the destination server 12, 13”; ¶0189, “FCP sender state handler 262 parses the incoming fabric grants (280) against the FCP transmit queue state as the arrivals could be out of order. The accepted FCP grants are queued in separate queues of packet scheduler 266A (282)”; ¶0209, “The grant scheduler 314A reacts to the reorder buffer state at egress reorder state handler 312 (296) and stops sending all the new grants if the reorder buffer state (out of order bytes, grants in flight, and buffer occupancy) reaches a limit”).
As to claim 20, Vegesna discloses the method of claim 19, wherein the ordering constraint is translated to the ordering request (Figs. 13-14; ¶0144; ¶0165, “a request message arrives out of order at the FCP receiver”; ¶0189, “FCP sender state handler 262 parses the incoming fabric grants (280) against the FCP transmit queue state as the arrivals could be out of order. The accepted FCP grants are queued in separate queues of packet scheduler 266A (282)”; ¶0209, “The grant scheduler 314A reacts to the reorder buffer state at egress reorder state handler 312 (296) and stops sending all the new grants if the reorder buffer state (out of order bytes, grants in flight, and buffer occupancy) reaches a limit”).
Applicant’s arguments with respect to claim(s) 11-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Applicant asserts on page 6 of Remarks that “Vegnesa in view of Eberle does not teach
or suggest "a scheduler that operates in a first mode where "packets of packet flow are distributed among multiple packet processing engines."
Examiner respectfully disagrees. Eberle discloses operation of a general processing cluster configured to route packets received from the work distribution unit to appropriate logical units within the general processing cluster (¶0236). Eberle further discloses a parallel processing unit (PPU) (Fig. 28, 2820) having a highly scalable multi-engine architecture (¶0224) that includes a scheduler unit (Fig. 28, 2808) and a work distribution unit (Fig. 28, 2810). Eberle discloses the scheduler that operates in a first mode (i.e., out-of-order) where "packets of packet flow are distributed among multiple packet processing engines (Fig. 3B; ¶0094; ¶0097, “received out-of-order and forwarded to the reorder buffer. Next, REQ1 is received and forwarded. Whenever, a REQn is forwarded, the reorder buffer is checked whether it contains REQn+1. In the example, REQ2 as well as REQ4 are found in the reorder buffer when REQ1 and REQ3, respectively, are received. Once a REQ in the reorder buffer is in order, it is released and forwarded to destination memory”).
PNG
media_image1.png
486
499
media_image1.png
Greyscale
In addition, Vegesna discloses multiple packet processing engines (Fig. 1, 19, DPU group; ¶0045, “one of DPUs 17A-17H (collectively, “DPUs 17”) for processing streams of information, such as network packets…DPUs 17 may be arranged into multiple different DPU groups 19, each including any number of DPUs”; ¶0046-¶0047), and a data packet scheduler (Fig. 13, 266A; ¶0031) that operates in a first mode (i.e., out of order) where "packets of packet flow are distributed among multiple packet processing engines (¶0171, “When a data packet arrives out of order at FCP receiver, it may go through a packet reorder engine. At the end of reorder process, the packets are sent to one of the processing cores”; ¶0189, “packet scheduler 266A (282). FCP sender state handler 262 parses the incoming fabric grants (280) against the FCP transmit queue state as the arrivals could be out of order. The accepted FCP grants are queued in separate queues of packet scheduler 266A (282)”).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNGWON CHANG whose telephone number is (571)272-3960. The examiner can normally be reached 9AM-5:30PM.
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, GLENTON BURGESS can be reached at (571)272-3949. 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.
/JUNGWON CHANG/Primary Examiner, Art Unit 2454 May 16, 2026
Prosecution Insights