DETAILED ACTION
Notice of 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.
Priority
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. In particular, this application claims foreign priority to an international application filed on 27 May 2024. Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
The Reply amended two of the three independent claims to require the packet steering circuit to receive information associated with the elephant flow from the data path circuit. Claims 1 and 10. The Reply correctly notes that the anticipation rejection of the Non-final Rejection did not explicitly teach the driver 168 providing this information to the interface 100. Reply, 8-9. However, the anticipation rejection has been reformulated, such that Bowers still teaches all limitations of the independent claims. Specifically, filter 114, which steers packet to either the RSS or the heavy receive queue teaches the claimed “packet steering circuit” and flow counter 112, which provides the bytes/second of each flow to filter 114, teaches the claimed “data path circuit.” Given the reformulation of the anticipation rejection, the remaining arguments in the Rule 111 Reply are moot.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1, 3, 5-7, 9, 10, 11-14, and 16-19 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Bowers (US 20190260686).
Regarding claims 1, 10, and 171, Bowers teaches a system comprising at least one processor for network communications, the at least one processor associated with a data path circuit and a packet steering circuit, one or more circuits associated with the circuits, and a method for network communications, the method comprising:
providing at least one processor (Bowers, figure 1 – processors 134) to be associated with a data path circuit (Bower, figure 1 – flow counter 112) and a packet steering circuit (Bowers, figure 1 – filter 114);
receiving communications associated with a plurality of communication protocols using the data path circuit (Bowers, ¶19 and – received packets are associated with several protocols and has shown in figure 1 are received by flow counter 112);
determining an elephant flow in the communications based in part on a size indication associated with the communications (Bowers, ¶¶21, 32 – if the byte rate of a packet flow exceeds a threshold, the packet flow is classified as a heavy or elephant flow; Bowers, ¶40 – number of bytes represents a size indication);
receiving, into the packet steering circuit and from the data path circuit, information associated with the elephant flow (Bowers, ¶20 and figure 1 – flow counter 112 provides bytes/second of one or more flows, which is received by filter 114 as shown in figure 1); and
enforcing at least one rule, using the packet steering circuit, and based in part on the information associated with the elephant flow, to steer incoming packets for different receive queues associated with respective ones of the communication protocols. Bowers, ¶¶20, 42 (filter 114 applies one or more rules to route a received packet to either receive queues associated with RSS or heavy receive queues based on the bytes/second of each flow received from the flow counter 112).
Regarding claim 3, Bowers also teaches wherein the plurality of communication protocols are different Transmission Control Protocol (TCP)-based connections.” Bowers, ¶3 (network interface 100 receives TCP packets for many connections).
Regarding claims 5 and 12, Bowers also teaches wherein the at least one rule is to steer the incoming packets to one of the different receive queues which is associated with one of the plurality of communication protocols (Bowers, ¶20 and figure 2B – a filter rule is used to steer packets of different flows to either queues for normal flows via RSS or queues for heavy flows [see rejections of claims 3 and 18 for a flow of TCP packets being a TCP connection and where specific queues in figure 2B are “associated” with each TCP flow/connection]), based in part on the elephant flow being associated with the one of the plurality of communication protocols. Bowers, ¶34 and figure 2B (e.g. heavy flow 1 is associated with queue Q2 and, as discussed above, each flow of TCP packets is a TCP connection, which according to the Specification, constitutes being associated with a communication protocol).
Regarding claims 6 and 13, Bowers also teaches wherein the at least one rule is to steer the incoming packets to the one of the different receive queues by an override to a receive side scaling (RSS) logic associated with the one of the different receive queues or is to leave as unchanged an existing rule to steer the incoming packets to the one of the different receive queues. Bowers, figure 2B (heavy flows 1 and 5, which previously went to RSS as shown in figure 2B, are now steered to queues Q2 and Q3 respectively, while the normal flow continue to go to RSS).
Regarding claims 7 and 14, Bowers also teaches wherein the size indication is based in part on one or more of bytes per second of one flow associated with one of the plurality of communication protocols, relative to other flows in the communications; a packet count relative to other flows in the communications; or a large send offload. Bowers, ¶18 (heavy flow is identified by a byte count per second exceeding a threshold); Bowers, ¶¶15, 20 (TCP flow is an elephant flow).
Regarding claims 9 and 16, Bowers also teaches wherein the elephant flow is to be migrated, as part of the steering for the incoming packets, from a first transmit queue and a first receive queue of a first one of the communication protocols to a second transmit queue and a second receive queue of a second one of the communication protocols. Bowers, figure 2A and 2B (flow 1 migrates from Q0 to Q2 as a result of it being classified as a heavy flow); Bowers, figure 1 (flows received by network interface 100 traverse both transmit and receive queues when involved in communication with host 150 [e.g. elements 118, 120, 706, 158, 160, and “transmit queues” in host 150]); see also rejections to claims 3 and 18 for a flow of TCP packets being a TCP connection, which according to the Specification constitutes a communication protocol.
Regarding claim 11, Bowers also teaches wherein the data path circuit is further to indicate that the elephant flow is inactive for stipulated period (Bower, ¶38 – a flow is indicated as heavy based on its data rate exceeding a threshold over a period of time [i.e. if less than the threshold, then the flow is no longer considered heavy, but non-heavy or “inactive”]) to cause the elephant flow to be inactive by, at least in part, removal of a steering entry for the elephant flow from a steering table. Bower, ¶36 (driver 168/302 removes a filter from the flow filter table when the status of a flow changes from heavy to non-heavy); see also id., figure 2C for a flow changing from heavy to non-heavy.
Regarding claim 18, Bowers also teaches
determining that the elephant flow is associated with the one of the plurality of communication protocols (Bowers, ¶¶19, 82 – classifier 110 of network interface 100 can determine a flow to be a TCP packet based on one or more identifiers, where other packet types include UDP and SCTP packets [i.e. TCP is one of a plurality of protocols])2; and
performing an override to a receive side scaling (RSS) logic, associated with one of the different receive queues, to steer the incoming packets to one of the different receive queues which is associated with one of the plurality of communication protocols. Bowers, figure 2B (heavy flows 1 and 5, which previously went to RSS as shown in figure 2B, are now steered to queues Q2 and Q3 respectively); Bowers, ¶20 (a flow, such as flows 1 or 5, are each a TCP connection, which results in queues Q2 and Q3 in figure 2B being “associated” with a respective TCP flow).
Regarding claim 19, Bowers also teaches
determining that the elephant flow is associated with the one of a plurality of communication protocols (Bowers, ¶44 – determines if a flow to TCP packets is s heavy or non-heavy flow; see also rejections to claims 3 and 18 for a flow of TCP packets being a TCP connection, which according to the Specification constitutes a communication protocol); and
leaving, as unchanged, an existing rule to steer the incoming packets to one of the different receive queues that is associated with the one of the plurality of communication protocols. Bowers, ¶93 (network interface 100 applies existing rule when steering a flow of TCP packet to queues for either a heavy flow or a non-heavy flow).
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.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Bowers (of record) in view of Kutch (US 20210117360).
Regarding claim 2, Bowers teaches the system of claim 1, but does not explicitly teach “wherein the at least one processor is a processing sub-system of a Virtio standard data processing unit (DPU).” However, Kutch teaches a CPU 1630, which uses a driver that is a virtIO device. Kutch, ¶137. At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to implement the virtIO driver, as taught by Kutch, as the driver executed by the host in Bowers, in order to implement Bower’s packet queuing in a virtualized environment. Kutch, ¶¶100-101. This enables a guest to access resources. Id. at ¶¶90, 93.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Bowers (of record) in view of Musleh (US 20220210075).
Regarding claim 4, Bowers teaches the system of claim 1 and individual TCP connections (Bowers, ¶3 – TCP flow of packets is a connection, which according to the Specification is a communication protocol) and a packet flow’s queue being associated with a particular processor core (Bowers, ¶25), but does not explicitly teach its TCP connections “are associated with individual ones of different virtual machines (VMs).” However, Musleh teaches TCP flows being assigned to specific virtual circuits. Musleh, ¶50. Musleh also teaches a flow ID that is associated with an application. Musleh, ¶47. An application is used interchangeably with virtual machine (VM) by Musleh. Id. at ¶17. As a result, Musleh associates a flow ID with a VM. Musleh, ¶18. At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to associate each flow of TCP packets, taught by Bowers, with specific virtual machines or applications, as taught by Musleh, in order to enable flow differentiation between elephant and mice flows. Musleh, ¶39.
Claims 8, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers (of record) in view of Francini (US 20210112006).
Regarding claims 8, 15,3 and 20, Bowers teaches the system of claim 1, the circuits of claim 10, and the method of claim 17, further comprising . . .
determining a second parameter associated with a fairness protocol to provide individual ones of the plurality of communication protocols with a chance to be part of an elephant flow (Bowers, ¶41 – a flow may be designated as heavy if its rate of bytes per second meets or exceeds a threshold; Bowers, figure 4 – step 456 offers the chance of a flow to be treated as part of the elephant flows); and
enabling the enforcement of the at least one rule to be based in part on the one or more first parameter or the second parameter. Bowers, ¶¶41, 44 (an allocated flow rule is applied based on whether the flow is heavy or non-heavy).
Bowers does not explicitly teach “determining a first parameter associated with at least one overflow limit for a steering table of the packet steering circuit.” However, Francini teaches a set of classification rules (i.e. a template is a “table”) by an input handler that steers a packet to a particular queue. Francini, ¶45-46 (handler 250 uses template to initiate congestion control when assigning a packet to a flow queue 220); see also id., ¶61 (input handler executing figure 4). In one template, the congestion control rules require the marking of a packet with explicit congestion notification (ECN) when the length of its assigned queue exceeds a threshold (i.e. overflow limit). Id. at ¶67 (when Ls > Bs, the template requires a packet to marked). The ECN constitutes “a first parameter” associated with an excessive queue length. At the time of the effective filing date of the invention, it would have been obvious for one of ordinary skill in the art to implement the ECN marking, taught by Francini, when mapping the TCP packets of Bowers to a queue, in order to trigger congestion control based on application-related aspects of the flows (Francini, ¶34) outside of the prior hashing of packets to a flow queue. Francini, ¶68 (template classification does not affect mapping packets to queues).
Conclusion
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 BENJAMIN S LAMONT whose telephone number is (571)270-7514 and email address is benjamin.lamont@uspto.gov (see MPEP 502.03 for using EFS or mail, but not email to authorize electronic communications). The examiner can normally be reached M-F 7am to 3pm EST.
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, Huy Vu can be reached at 571-272-3155. 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.
/Benjamin Lamont/Primary Examiner, Art Unit 2461
1 Claim 17 is the broadest independent claim. It does not require the packet steering circuit to receive information associated with the elephant flow from the data path circuit, which was added to the claimed inventions of claims 1 and 10 by the Rule 111 Reply, received 19 Aug 2026.
2 Spec., ¶20 – “different communication protocols” may be “different TCP connections” (i.e. the same protocol is used, but resulting in different packet flows. See rejection of claim 3 for Bowers teaching multiple TCP connections or flows.
3 Claims 8 and 15 are broader in scope than claim 20 by not requiring the determination of both the first and second parameters.
Prosecution Insights