DETAILED ACTION
Status of the Claims
Claims 1, 2, 4–12, and 14–21 are pending and have been examined. Claims 1, 11, and 20 were amended in the reply filed in response to the non-final Office action mailed December 18, 2025. Claims 3 and 13 are cancelled. Claims 1, 2, 4–12, and 14–21 are objected to. Claims 1, 2, 4–7, 10–12, 14–17, 20, and 21 are rejected under 35 U.S.C. § 103, as set forth below. 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.
Allowable Subject Matter
Claims 8, 9, 18, and 19 would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims, including the limitations of claims 7 and 17 from which they respectively depend. The prior art of record does not teach or suggest the specific threshold and probability values recited in claims 8 and 18 (the first value set to 2000, the second value set to 10,000, and the third value set to 20%), nor the linear increase of the marking probability from 0% to 20% over the recited queue-occupancy range recited in claims 9 and 19.
Jia (US 11,991,082 B2), applied in the alternative rejection of claims 7 and 17 above, teaches the linear-increase limitation of claims 9 and 19 but not the specific-value limitation of claims 8 and 18. As to claims 9 and 19, Jia teaches that between the lower and upper ECN thresholds the marking probability is directly proportional to the queue depth, rising from zero at the lower threshold to the maximum marking probability at the upper threshold (Jia, col. 12, lines 11–12; col. 17, lines 39–44; fig. 1). As to claims 8 and 18, however, Jia expresses its thresholds and maximum marking probability only as configurable parameters, without the recited values of 2000, 10,000, and 20% and without expressing its thresholds as numbers of packets. The specific values of claims 8 and 18 thus remain untaught, and claims 8, 9, 18, and 19 remain allowable.
Other Prior Art
Callaghan (US 11,240,157 B1) discloses an adaptive classifier that tracks network packets transferred in data flows and applies quality-of-service classifications to the packets, applying different quality-of-service markings to packets in a data flow based on data-flow metadata (Callaghan, Abstract).
Ghetie (US 7,698,457 B2) discloses a system for managing quality of service for individual traffic flows traversing hosts separated by one or more networks enabled with a set of traffic classes, in which a services manager determines a set of traffic attributes for a flow and oversees its admission to an appropriate traffic class (Ghetie, Abstract).
Gobriel et al. (US 10,237,171 B2) discloses quality-of-service support for software-based packet processing in which quality-of-service rate-limiting for received and locally generated packet flows is offloaded to network interface controller hardware of the host compute platform (Gobriel, Abstract).
Claim Objections
Claims 1, 11, and 20
Independent claims 1, 11, and 20 are objected to as ambiguous in the identity of the actor that performs the recited parameter-setting step, an ambiguity the Office invites Applicant to clarify. Amended claim 1 recites 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, the processing including setting, based on the first traffic class, a first set of parameters associated with the network device and a second set of parameters of a network interface card of the source host machine. Claims 11 and 20 recite a corresponding limitation in commensurate form.
On its face, the limitation attributes the act of setting to the network device, yet the object of that act includes both a first set of parameters associated with the network device and a second set of parameters of a network interface card of the source host machine, yielding at least two constructions. Under the first, the network device itself configures the second set of parameters at the source host’s network interface card, an in-path device reaching across the communication path to set parameters resident on the source host. Under the second, the second set of parameters is set at the source host’s network interface card in correspondence with the first traffic class as indicated by the tag, without the network device itself configuring those parameters.
The specification does not appear to resolve the ambiguity in favor of the first construction. It describes the second set of parameters as parameter settings performed at the network interface card (NIC) level i.e., NIC on a source host machine ([0145]), namely an adaptive retransmission parameter, a multiple queue pairs parameter, a slow restart parameter, and a packet sequence number parameter ([0145]–[0146], [0150]). The specification describes no mechanism by which the network device configures those parameters at the source host’s network interface card, nor any by which it communicates its traffic-class determination to the source host. Rather, it describes an application on the source host setting the tag to indicate the traffic type ([0163]), the network device separately determining the traffic class from that tag and the parameters then being set based on that class ([0164]), and the class-based settings being applied to the network devices in the communication path ([0168]), while expressly permitting these steps to be performed in a different order or in parallel ([0161]). The specification thus supports setting the second set of parameters at the source host’s network interface card in correspondence with the traffic class reflected in the source-authored tag, rather than in response to any determination made and communicated by the network device.
Clarification is respectfully requested as to which construction is intended: that the network device itself configures the second set of parameters at the source host’s network interface card (the first), or that those parameters are set at the source-host network interface card in correspondence with the first traffic class as indicated by the tag (the second). For purposes of the rejection below, the limitation has been given its broadest reasonable interpretation consistent with the specification and treated as requiring only the latter, the second set of parameters being set at the source host’s network interface card in correspondence with the first traffic class indicated by the tag, without the in-path network device performing that configuration or communicating any traffic-class determination to the source host.
Claims 2, 4–10, 12, 14–19, and 21
Claims 2, 4–10, 12, 14–19, and 21 are objected to for the reasons set forth above with respect to claims 1, 11, and 20, by virtue of their dependency upon claims 1, 11, and 20.
Response to Arguments
The arguments of Applicant’s representative filed 6/15/2026 have been fully considered.
Rejection of Claim 1 under 35 U.S.C. § 103 over Srinivasan, Yang, and either Kraemer or Gogic, in further view of Chirivolu
Independent claim 1 has been amended to recite that the type of explicit congestion notification marking comprises linearly increasing a probability of marking the packet based on a total number of packets included in a queue of the network device being within a first predetermined range. Applicant’s representative argues that Chirivolu does not describe or suggest this linearly-increasing-probability feature. Examiner agrees. Nonetheless, Srinivasan, Aloni, and Nendica teach amended claim 1, 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, 6, 7, 10, 11, 14, 16, 17, 20, and 21 are rejected under 35 U.S.C. § 103 as being unpatentable over Srinivasan et al. (US 2019/0386924 A1; “Srinivasan”) in view of Aloni et al. (US 8,660,137 B2; “Aloni”) and in further view of the non-patent literature entitled “IEEE 802 Nendica Report: Intelligent Lossless Data Center Networks” (“Nendica”).
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, the packet originating at the source host machine and whose destination is the destination host machine, Srinivasan teaches that a flow is tagged using one or more fields carried in the packet headers or preamble, and that a network device disposed in the path between a transmitter endpoint and a destination endpoint reads that mark from the received packet and uses it to allocate the flow to a queue and to guide buffer-allocation and scheduling policies, such that the device does not need to independently determine the flow classification (Srinivasan, [0040]–[0041]; fig. 1, network device 150). The network device’s reading of the in-packet mark from the received packet is the recited extracting of a tag from a packet received by a network device in the communication path.
the tag being set by an application executing on the source host machine where the packet originates, 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; Srinivasan teaches that an application program interface is available for use by applications to mark a flow based on the type of flow and its latency and bandwidth needs, and that an application can explicitly mark a flow as latency-sensitive or for minimum-bandwidth provisioning, using host-resident application interfaces such as the Message Passing Interface (MPI) or RDMA Verbs (Srinivasan, [0036]). Because MPI and RDMA Verbs are interfaces invoked by the application on the host that originates the flow, the marking application executes on the source host machine where the packet originates. Srinivasan further teaches that this marking is carried as the in-packet field used to tag the flow (the same field the network device reads, as set forth above), and that the marking selects among a plurality of traffic classes, including traffic classes extended beyond the standard eight classes (Srinivasan, [0040]–[0041]).
determining, based on the tag, that the first traffic class corresponds to a bandwidth sensitive traffic; and Srinivasan teaches that the network device differentiates flows according to the tagged traffic class and identifies a flow marked for minimum-bandwidth provisioning (a bandwidth-sensitive class, as distinct from a latency-sensitive class) and applies the corresponding scheduling and buffer-allocation policy on that basis (Srinivasan, [0036], [0040]–[0041]).
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, the processing including setting, based on the first traffic class, a first set of parameters associated with the network device Srinivasan teaches that, based on the traffic class of the flow, the network device applies class-specific settings configured at the network device, including selection of an egress queue and the associated buffer-allocation and scheduling policy, to process the packets of that flow (Srinivasan, [0040]–[0042]; fig. 1, egress queues).
However, Srinivasan does not teach the processing including setting, based on the first traffic class, … a second set of parameters of a network interface card of the source host machine. Nonetheless, Aloni teaches a converged network interface card (CNIC) on a host that processes packets and I/O requests for transmission based on a class associated with each, and configures a set of transmission parameters at the CNIC in correspondence with that class, including per-class rate shaping, per-queue flow control, and bandwidth allocation (Aloni, col. 8, lines 5–12, 45–58; col. 9, lines 58–67; col. 10, lines 1–2). Aloni maps a traffic type such as RDMA traffic to a class of service using the 802.1p priority, VLAN, or DSCP field of the packet, and regulates the rate at which packets of that class are handled at the CNIC based on that class (Aloni, col. 9, lines 58–67). That class is a traffic class encoded in a packet-header field, the same kind of designation Srinivasan uses to tag a flow and the network device determines, and is therefore the first traffic class of the claim rather than a generic quality-of-service category. The CNIC that originates the traffic and configures its transmission parameters by class is the source host machine’s network interface card, and the per-class parameters configured there are the recited second set of parameters.
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, in correspondence with the bandwidth-sensitive traffic class indicated by the tag, a second set of parameters is configured at the source host machine’s network interface card, as taught by Aloni, because doing so aligns the source host’s per-class transmission parameters, including its bandwidth allocation, with the class-based handling of the flow and thereby provides consistent treatment of the differentiated traffic class at both the network device and the source host.
Further, the combination of Srinivasan and Aloni does not teach the recited content of the first set of parameters, wherein the first set of parameters includes a first parameter corresponding to a type of explicit congestion notification (ECN) marking associated with the bandwidth sensitive traffic, and wherein the type of ECN marking comprises linearly increasing a probability of marking the packet based on a total number of packets included in a queue of the network device being within a first predetermined range. Nonetheless, Nendica teaches a congestion point in the switches along the path that marks packets with ECN as a function of egress-queue occupancy evaluated against configurable thresholds: below a lower threshold (Kmin) traffic is not marked, above an upper threshold (Kmax) all packets are marked, and between Kmin and Kmax the marking probability increases according to the extent of the queue length, as specified by the Data Center Quantized Congestion Notification (DCQCN) scheme on which Nendica relies (Nendica, section “Improving Congestion Notification”). That behavior is the well-known random early detection ramp, in which the marking probability increases linearly with egress-queue length from zero at Kmin to a maximum probability (Pmax) at Kmax. Nendica further teaches that the ECN marking is associated with the traffic class, the marking thresholds being set per class, a low threshold benefiting latency-sensitive flows and a high threshold benefiting bandwidth-sensitive flows, and the switch thresholds and the NIC rate-reduction and response parameters being coordinated for the differentiated classes (Nendica, section “High throughput and low latency tradeoff”; section “Intelligent ECN threshold optimization”; fig. 19).
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 Aloni so that the first set of parameters applied by the network device to the bandwidth-sensitive traffic class includes the queue-occupancy-proportional ECN marking taught by Nendica, because doing so optimizes the throughput-versus-latency tradeoff for the bandwidth-sensitive class and, together with coordinated source-side rate and response parameters, avoids the congestion-induced packet loss that degrades RDMA traffic in the lossless data-center environment.
Regarding claims 4 and 14, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, and Nendica further teaches wherein the first set of parameters associated with the network device includes a second parameter corresponding to a depth of the queue associated with the network device. Nendica teaches that the congestion point in the switch evaluates the egress-queue occupancy against configurable queue-length thresholds, and that the lower threshold (Kmin) and upper threshold (Kmax) against which the queue length is evaluated are configured at the switch as parameters governing the class-based marking behavior, such that a queue-depth parameter associated with the network device is among the first set of parameters configured at the network device (Nendica, section “Improving Congestion Notification”; fig. 19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the first set of parameters configured at the network device includes a queue-depth parameter associated with the network device, as taught by Nendica, because doing so allows the switch to tune the onset and rate of congestion marking to the available buffer for the differentiated traffic class and thereby avoid both premature throttling and buffer overflow for the bandwidth-sensitive flow.
Regarding claims 6 and 16, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, and Nendica further teaches wherein the type of explicit congestion notification marking associated with the bandwidth sensitive traffic corresponds to a relaxed and probabilistic manner of marking packets. Nendica teaches that, when the egress-queue length lies between the lower threshold (Kmin) and the upper threshold (Kmax), the congestion point marks packets with a probability that increases with the extent of the queue length rather than marking every packet, which is a relaxed and probabilistic manner of marking packets as distinct from deterministic marking of all packets above a single threshold (Nendica, section “Improving Congestion Notification”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the explicit congestion notification marking for the bandwidth-sensitive traffic is performed in a relaxed and probabilistic manner, as taught by Nendica, because probabilistic marking smooths the congestion signal and avoids the synchronized rate reductions that result from marking all flows at once, thereby maintaining higher utilization for the bandwidth-sensitive class.
Regarding claims 7 and 17, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 6, and Nendica further teaches 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. Nendica teaches that the probabilistic marking is governed by a lower queue-length threshold (Kmin) assigned a first value, an upper queue-length threshold (Kmax) assigned a second value greater than the first, and, under the Data Center Quantized Congestion Notification (DCQCN) scheme on which Nendica relies, a maximum marking probability (Pmax) assigned a third value that the marking probability reaches at Kmax, the marking probability rising from zero at Kmin to that maximum marking probability at Kmax as the queue length increases between the two thresholds (Nendica, section “Improving Congestion Notification”; fig. 19).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the relaxed and probabilistic marking is configured by assigning a lower queue-length threshold, a higher queue-length threshold, and a maximum marking probability as taught by Nendica, because parameterizing the marking ramp in this way gives the operator direct control over where congestion signaling begins and how aggressively it scales, allowing the bandwidth-sensitive class to be tuned for sustained throughput.
Regarding claim 10, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, and Aloni further teaches 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. Aloni teaches that the converged network interface card (CNIC 202) utilizes multiple queues for transmission of differentiated traffic classes, the recited number of queues parameter (Aloni, col. 7, lines 18–20), and synchronizes sequence numbers so that every octet is received and acknowledged, the recited packet sequence number parameter (Aloni, col. 7, lines 2–4). Aloni further teaches that the CNIC manages congestion-driven recovery, including retransmission responsive to lost or unacknowledged data and a rate-control mechanism that decreases and then gradually re-increases the transmission rate to avoid bursty transmission, corresponding to the recited adaptive retransmission and slow restart parameters governing the source-host transmission behavior (Aloni, col. 2, lines 19–31). The specification describes each of these two parameters only as a binary on-or-off parameter, with adaptive retransmission corresponding to the time taken to recover from a disruption and slow restart controlling the rate at which the queues build up to avoid bursty traffic, reciting no algorithm, threshold, or value distinguishing either from the enabling and disabling of the recovery and rate-control behavior already taught by Aloni.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the second set of parameters at the source host machine’s network interface card includes the number of queues, packet sequence number, adaptive retransmission, and slow restart parameters as taught by Aloni, because configuring these parameters at the source network interface card in correspondence with the traffic class lets the source host segregate, sequence, and rate-control the bandwidth-sensitive flow and recover reliably from congestion signaled by the network device. As to the adaptive retransmission and slow restart parameters, each recited in the specification only as a binary on-or-off parameter, providing them amounts to no more than enabling or disabling the recovery and anti-burst rate-control behavior Aloni already provides; the specification discloses no criticality for either state and no new or unexpected result from enabling either parameter, so selecting whether to enable a known behavior performing its known function is an obvious matter of design choice.
Regarding claim 21, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, and Srinivasan further teaches 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. Srinivasan teaches that the application marks a flow through a host-resident application interface based on the type of flow and its latency and bandwidth needs, for example marking a flow as latency-sensitive or for minimum-bandwidth provisioning, such that the tag is set according to the requirement of the application’s workload to which the packet belongs (Srinivasan, [0036], [0040]–[0041]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the source-host application sets the tag based on a requirement of the workload that includes the packet, as taught by Srinivasan, because tying the tag to the workload’s own bandwidth and latency requirements ensures that each flow receives the differentiated network and source-host treatment appropriate to its needs.
Claims 2 and 12 are rejected under 35 U.S.C. § 103 as being unpatentable over Srinivasan, Aloni, and Nendica, as applied to claims 1 and 11 above, in further view of the non-patent literature entitled “Congestion Control for Large-Scale RDMA Deployments” (“Zhu”).
Regarding claims 2 and 12, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, but does not teach wherein the network device is a top of rack switch or a spine switch. Nonetheless, Zhu teaches a data-center network fabric in which the network devices are arranged as top-of-rack (ToR) switches, leaf switches, and spine switches, the testbed comprising four ToR switches, four leaf switches, and two spine switches interconnecting the host machines (Zhu, section 2.2; fig. 2). The top-of-rack switch and the spine switch of Zhu are each a network device disposed in the communication path between the source and destination host machines, which is the recited top of rack switch or spine switch.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the in-path network device is a top of rack switch or a spine switch as taught by Zhu, because arranging the congestion-managing network devices as top-of-rack and spine switches is the conventional data-center fabric topology for which the differentiated traffic-class handling of the combination is intended, and doing so places the class-based processing at the standard aggregation points of the data-center network.
Claims 5 and 15 are rejected under 35 U.S.C. § 103 as being unpatentable over Srinivasan, Aloni, and Nendica, as applied to claims 1 and 11 above, in further view of Lauer (US 8,452,276 B2; “Lauer”).
Regarding claims 5 and 15, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 1, but does not teach 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. Nonetheless, the combination of Lauer and Nendica teaches this limitation. Lauer teaches that the differentiated services code point (DSCP) is a six-bit field in the header of an IP packet used to classify and mark the packet, replacing the earlier three-bit precedence field in the eight-bit type of service byte of the IP header (Lauer, col. 11, lines 45–49); the tag is thus carried in a six-bit DSCP within the eight-bit type of service field of the packet header, which is the recited eight-bit type of service field with six bits allocated to the tag. Nendica teaches that the ECN marking applied to the differentiated traffic class is carried in the two-bit explicit congestion notification field of that same eight-bit type of service byte, which is the recited assignment of two bits to the ECN marking (Nendica, section “Improving Congestion Notification”). The two references together thus teach an eight-bit type of service field in which six bits carry the DSCP tag and the remaining two bits carry the ECN marking.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the tag is carried in the six-bit differentiated services code point of the eight-bit type of service field of the IP header as taught by Lauer, with the explicit congestion notification marking carried in the remaining two bits of that field as taught by Nendica, because using the standardized differentiated services code point and explicit congestion notification subfields of the existing eight-bit type of service byte conveys both the traffic class and the congestion signal within a single standard header field, avoiding any additional header overhead and ensuring interoperability with conventional IP forwarding equipment.
Alternatively, claims 7 and 17 are rejected under 35 U.S.C. § 103 as being unpatentable over Srinivasan, Aloni, and Nendica, as applied to claims 6 and 16 above, in further view of Jia et al. (US 11,991,082 B2; “Jia”).
Jia qualifies as prior art under 35 U.S.C. § 102(a)(2). Although Jia issued May 21, 2024 and published June 30, 2022 as US 2022/0210069 A1, Jia is a continuation of International Application No. PCT/CN2020/115158, filed September 14, 2020, which claims priority to Chinese Application No. 201910872367.5, filed September 16, 2019, and is therefore entitled to an effective filing date before the April 20, 2022 effective filing date of the claimed invention.
Alternatively, regarding claims 7 and 17, the combination of Srinivasan, Aloni, and Nendica teaches the method of claim 6, but does not expressly teach 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. Nonetheless, Jia teaches explicit congestion notification marking in which the ECN configuration information includes a lower ECN threshold, an upper ECN threshold, and a maximum ECN marking probability: below the lower threshold no packet is marked, above the upper threshold every packet is marked, and between the two thresholds the switch marks a fraction of the packets with a probability greater than zero and less than the maximum marking probability (Jia, col. 11, lines 52–60; col. 12, lines 18–33; fig. 1). The lower ECN threshold is the recited first threshold parameter assigned a first value, the upper ECN threshold is the second threshold parameter assigned a second value, and the maximum ECN marking probability is the third parameter corresponding to a probability of marking assigned a third value; Jia’s fig. 1 places the upper threshold (Kmax) above the lower threshold (Kmin) on the queue-length axis, the recited second value greater than the first.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Srinivasan, Aloni, and Nendica so that the relaxed and probabilistic marking is configured by assigning a lower threshold, an upper threshold greater than the lower threshold, and a maximum marking probability as taught by Jia, because expressing the marking behavior as a defined set of configurable threshold and probability parameters gives the operator direct control over where congestion marking begins, where it saturates, and how aggressively it scales, allowing the bandwidth-sensitive class to be tuned for sustained throughput.
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 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 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
Prosecution Insights