DETAILED ACTION
Introduction
Claims 1, 2, 4-12, and 14-21 are pending. Claims 1, 11, and 20 are amended. Claims 3 and 13 are previously cancelled. Claim 21 is new. This Office action is in response to Applicant’s request for continued examination (RCE) filed on 7/8/2025
Other Relevant Prior Art
Srinivasan (US 2020/0236052) is directed to a system for performing congestion control by providing congestion hints from a switch to a source. See par. 1-3. In addition, Almog (US 2014/0169169) is directed to a method of identifying, by a network device, a class of traffic from data inserted into the traffic by a source, and processing, by the network device, the data traffic using a configuration of the network device that is optimal for the traffic class.
Claim Objections
Claims 1, 11, and 20 are amended to recite the “the tag being set by an application executing on the source host machine where the packet originates… [and] the first traffic class being selected by the source host machine from a plurality of traffic classes.” In other words, the application executing on the host sets the tag and the host selects the traffic class. However, in original claims 1, 11, and 20, the steps of setting the tag and selecting the traffic class were both performed by the same entity, i.e., the source. Would Applicant’s representative please clarify whether the change from performing the setting and selecting steps by the same entity to performing the setting and selecting steps by different entities is intentional or inadvertent?
Claims 2, 4-10, 12, 14-19, and 21 are also objected to for the reasons described in the preceding paragraph by virtue of their dependency upon claims 1, 11, and 20.
Allowable Subject Matter
Claims 8, 9, 18, and 19 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.
Response to Arguments
Examiner discusses the arguments of Applicant’s representative below.
Rejection of claims 1, 11, and 20 under 35 U.S.C. 102
Applicant’s representative has amended claims 1, 11, and 20 to clarify that the tag is set “by an application executing on the source host machine where the packet originates,” and now argues that the combination of Srinivasan and Yang does not teach the system of claims 1, 11, and 20, as amended. In support of this argument, Applicant’s representative argues that Srinivasan teaches marking packets at an intermediate device rather than a source device. Examiner agrees that Srinivasan is unclear as to where the marking actually occurs. For instance, Srinivasan teaches that “an application can explicitly mark a flow at least as latency sensitive or for minimum bandwidth provisioning,” but fails to expressly state that the application is an application running on the device from which the flow originates. Nevertheless, the combination of Srinivasan, Yang, and either Kraemer or Gogic teaches the system of amended claims 1, 11, and 20, as discussed in the rejection below.
Claim Rejections: 35 U.S.C. 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.
Claims 1, 4, 10, 11, 14, and 20 are rejected under 35 U.S.C. 103 because they are unpatentable over Srinivasan (US 2019/0386924) in view of Yang (US 2022/0416948), and in further view of either Kraemer (US 7,774,498) or Gogic (US 2010/0226252).1
Regarding claims 1, 11, and 20, Srinivasan teaches a method comprising: extracting, by a network device in a communication path between a source host machine and a destination host machine, a tag from a packet received by the network device (A network device S0 situated between source and a destination extracts a traffic class marking from a data flow. See par. 36; fig. 1A), the packet originating at the source host machine and whose destination is the destination host machine (The data flow originates from the source and terminates at the destination. See par. 29, 36; fig. 1A), the tag being set by an application, and is indicative of a first traffic class to be associated with the packet, the first traffic class being selected from a plurality of traffic classes (An application applies the marking to the data flow to indicate that the data flow belongs to a particular traffic class selected from a plurality of traffic classes, such as a latency sensitive traffic class and a bandwidth sensitive traffic class. See par. 36); determining, based on the tag, that the first traffic class corresponds to a bandwidth sensitive traffic (The network device may use the marking to determine that the data flow belongs to the bandwidth sensitive traffic class. See par. 40); and processing, by the network device, the packet using one or more settings configured at the network device for processing packets associated with the first traffic class (In response to determining that the data flow belongs to the bandwidth sensitive traffic class, the network device applies flow differentiation that is appropriate for bandwidth sensitive data flows, such as allocating to the bandwidth sensitive data flow an amount of queue space that is appropriate for bandwidth sensitive data flows, allocating the bandwidth sensitive data flow to a queue that is dedicated to bandwidth sensitive data flows, etc. See par. 35, 39, and 55), the processing including setting, based on the first traffic class, a first set of parameters associated with the network device (The network device may configure parameters based on the traffic class determined from the marking, such as allocating queue space for the data flow, determining a polling rate for the data flow, and configuring scheduling policies for the data flow. See par. 35, 39, and 40)
However, Srinivasan does not teach that the processing includes setting, based on the first traffic class, a second set of parameters of a network interface card of the source host machine. Nonetheless, Yang teaches a system for performing differentiated retransmissions whereby a network device determines hybrid automatic request (HARQ) settings and/or other retransmission settings for a network interface of user equipment based on a class of traffic (i.e., latency sensitive or latency insensitive) to be transmitted by the user equipment, and whereby the network device transmits the HARQ settings and/or other retransmission settings to the user equipment for use by the network interface when performing retransmissions. See par. 60-62; fig. 6A-6B; fig. 7, step 720.
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 Srinivasan so that the network device determines settings of a network interface of the source based on the class of traffic to be transmitted by the source, because doing so allows the system to provide the source with the retransmission scheme that is best suited for the class of traffic being sent by the source.
In addition, Srinivasan and Yang do not teach that the application is executing on the source host machine where the packet originals. Nonetheless, Kraemer teaches a system that permits a trusted user application on a user device to set a DSCP marking in an outgoing packet instead of scrubbing or overwriting the DSCP marking at the network edge. See col. 8, ln. 54 – 67; fig. 4, step 302. Similarly, Gogic teaches a system whereby an application running on a user equipment applies a DSCP marking to an outgoing packet. See par. 51; fig. 6.
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 Srinivasan and Yang so that the application that applies the marking is executing on a user device that originates the packet, because doing so allows the system to honor markings applied by trusted applications running on user devices that are outside of a trusted network, thereby reducing the need to apply the markings at the edge of the trusted network.
Regarding claims 4 and 14, Srinivasan, Yang, and Kraemer/Gogic teach the method of claim 1, wherein the first set of parameters associated with the network device includes a first parameter corresponding to a type of explicit congestion notification marking associated with the bandwidth sensitive traffic, and a second parameter corresponding to a depth of a queue associated with the network device (Srinivasan teaches that the configured parameters include an amount of queue space to allocate to the data flow. See par. 35. The configured parameters also include trigger conditions for notifying a source of congestion associated with the data flow, as well as parameters to record congestion statistics for the data flow. See par. 45, 50).
Regarding claim 10, Srinivasan, Yang, and Kraemer/Gogic teach the method of claim 1, wherein the second set of parameters corresponding to the network interface card associated with the source host machine includes an adaptive retransmission parameter, a slow restart parameter, a number of queues parameter, and a packet sequence number parameter (As indicated in the discussion of claim 1, Yang teaches a network device that determines retransmission settings for a network interface of a source. The retransmission settings are adaptive in the sense that they are differentiated based on the class of the traffic that is to be retransmitted. See par. 60. Thus, Yang suggests further modifying the system of Srinivasan, Yang, and Kraemer/Gogic so that the retransmission settings are adaptive retransmission settings, because doing so is beneficial for the reasons provided above with respect to claim 1).
Regarding claim 21, Srinivasan, Yang, and Kraemer/Gogic teach the method of claim 1, wherein the application executing on the source host machine is configured to set the tag based on a user requirement with respect to a workload that includes the packet (Kraemer teaches that the DSCP marking is applied by a trusted user application on the user device. One of ordinary skill in the art would appreciate that the trusted user application is applying the marking to achieve a quality of service desired by the user of the user application. See col. 8, ln. 54 – 67; fig. 4, step 302. Similarly, Gogic teaches that the application running on the user equipment applies the DSCP marking to the outgoing packet in response to a user of the user equipment instructing the application to apply the DSCP marking. See par. 51; fig. 6. Thus, Kraemer/Gogic suggest further modifying the system of Srinivasan, Yang, and Kraemer/Gogic so that the application on the user device that originates the packets applies the marking based on a user requirement for quality of service to be applied to the workload associated with the packet, because doing so is beneficial for the reasons provided above with respect to claim 1).
Claim Rejections: 35 U.S.C. 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.
Claims 2 and 12 are rejected under 35 U.S.C. 103 because they are unpatentable over Srinivasan, Yang, and Kraemer/Gogic, as applied to claims 1 and 11 above, in further view of Le (US 2021/0320866).
Regarding claims 2 and 12, Srinivasan, Yang, and Kraemer/Gogic do not teach the method of claim 1, wherein the network device is a top of rack switch or a spine switch. However, Le teaches a flow control system whereby a switch implementing flow control may be a top of rack switch. See par. 14, 16.
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 Srinivasan, Yang, and Kraemer/Gogic so that the network device is a top of rack switch because doing so allows the system to be used to perform congestion control in a datacenter architecture where a source communicates with a destination in the same rack.
Claims 5 and 15 are rejected under 35 U.S.C. 103 because they are unpatentable over Srinivasan, Yang, and Kraemer/Gogic, as applied to claims 1 and 11 above, in further view of Ravindran (US 9,049,251).
Regarding claims 5 and 15, Srinivasan, Yang, and Kraemer/Gogic do not teach the method of claim 1, wherein the tag is included in a type of service field included in a header portion of the packet, the type of service field being 8 bits long, and wherein 6 bits of the type of service field are allocated to the tag and 2 bits of the type of service field are assigned to a type of explicit congestion notification marking associated with the bandwidth sensitive traffic. However, Ravindran teaches a routing system whereby an 8-bit Type of Service (ToS) field comprises a 6-bit Differentiated Service Code Point Field (DSCP) that functions as a service class tag, and a 2-bit explicit congestion notification (ECN) field for congestion notifications. See col. 12, ln. 5-66; fig. 6.
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 Srinivasan, Yang, and Kraemer/Gogic so that the system uses 6-bit DSCP and 2-bit ECN fields of an 8-bit ToS field included in a header of the data flow, because doing so provides an alternative way of providing the traffic class indication and the congestion notifications.
Claims 6, 7, 16, and 17 are rejected under 35 U.S.C. 103 because they are unpatentable over Srinivasan, Yang, and Kraemer/Gogic, as applied to claims 4 and 14 above, in further view of Chiruvolu (US 6,839,321).
Regarding claims 6 and 16, Srinivasan, Yang, and Kraemer/Gogic do not teach the method of claim 4, wherein the type of explicit congestion notification marking associated with the bandwidth sensitive traffic corresponds to a relaxed and probabilistic manner of marking packets. However, Chiruvolu teaches a congestion control system which uses a relaxed and probabilistic packet marking scheme. See col. 2, ln. 61-65.
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 Srinivasan, Yang, and Kraemer/Gogic so that the system uses a relaxed and probabilistic packet marking scheme to perform the congestion notification function for the data flow, because doing so reduces the chances of dropping a large number of packets of the data flow at a later time by dropping packets at an earlier time when signs of congestion are only beginning to emerge.
Regarding claims 7 and 17, Srinivasan, Yang, Kraemer/Gogic, and Chiruvolu teach the method of claim 6, wherein the relaxed and probabilistic manner of marking packets is achieved by assigning a first threshold parameter associated with a number of packets included in a queue of the network device a first value, assigning a second threshold parameter associated with the queue of the network device a second value, and assigning a third parameter corresponding to a probability of marking a third value, and wherein the second value is greater than the first value (Chiruvolu teaches setting a first queue threshold (“minth”), a second queue threshold (“maxth”), and a third parameter (“Pdrop”) which represents a probability that a packet is to be marking when a queue size is between the first queue threshold and the second queue threshold. See col. 2, ln. 61-65. Thus, Chiruvolu suggests further modifying the system of Srinivasan, Yang, Kraemer/Gogic, and Chiruvolu so that the system employs the minth, maxth, and Pdrop parameters to implement the relaxed and probabilistic packet marking scheme, because doing so is beneficial for the reasons discussed with respect to claim 7).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. 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.
/ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
1 Examiner collectively refers to Kraemer and Gogic as “Kraemer/Gogic.”