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
1. This communication is in response to claims 1-20 filed on 09/03/2024.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2 and 11 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Specifically, for the following reason:
2. Claims 2 and 11 recite “the data rate” however claims 1 and 10, from which claims 2 and 11 respectively depend, recite “calculate/calculating a data rate at which data units for one or more flows [among/of] the plurality of flows are being received” and subsequently recite “each flow [of/among] the one or more flows that has a data rate that exceeds a particular threshold”. It is therefore unclear which of these previous recitations of “a data rate” in claims 1 and 10 “the data rate” in claims 2 and 11 are intended to refer to.
For purposes of examination, “the data rate” recitations in claims 2 and 11 are interpreted as referring to the data rate for the one or more flows among/of the plurality of flows being received.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
3. Claims 1-9 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claims do not fall within at least one of the four categories of patent eligible subject matter because they are directed to an apparatus comprising “a plurality of communication interfaces”, “ingress packet processing logic”, “a flow tracker”, and “an excessive rate policy resolver”, each element broad enough to be implemented as software.
Specifically, paragraph [0037] of the specification describes that the various elements of process flows described may be implemented using one or more of integrated circuits, logic components, computer programs, other software elements, and/or digital logic. Further, paragraph [0110] states that some or all of the components illustrated in FIG. 3 may be software-based logic. Although FIG. 4 illustrates an example of the flow tracker component including memory, the specification describes this merely as an example and therefore does not limit the claimed flow tracker to this exemplary representation.
Therefore, applying the broadest reasonable interpretation to the claims, all of the claimed elements may be software and, as such, the claimed network switching apparatus does not fall within one of the four categories of statutory subject matter.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
4. Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-7, 9-16, and 18-20 of U.S. Patent No. 12,081,444 in view of Beecroft et al. (US 2022/0210081).
Specifically, the correspondence between claim 1 of the present application and claim 1 of U.S. Patent No. 12,081,444 is illustrated below, with any differences shown in bold:
Present Application 18/823,281
U.S. Patent No. 12,081,444
1. A network switching apparatus comprising:
a plurality of communication interfaces configured to receive and send data units;
ingress packet processing logic configured to identify flows among a plurality of flows to which received data units belong;
a flow tracker, configured to:
calculate a data rate at which data units for one or more flows among the plurality of the flows are being received; and
set an excessive rate indicator for each flow of the one or more flows that has a data rate that exceeds a particular threshold;
an excessive rate policy resolver, configured to send a transmission pause request to a sender of data units for a flow having an excessive rate indicator that is set.
9. The network switching apparatus of Claim 1, wherein the excessive rate policy resolver is further configured to cause a packet switcher to drop data units that belong to the flow having an excessive rate indicator that is set at a higher rate than one or more flows that do not have the excessive rate indicator set.
1. A network switching apparatus comprising:
a plurality of communication interfaces configured to receive and send data units;
ingress packet processing logic configured to identify flows to which received data units belong;
flow tracker logic configured to:
determine for each flow of the plurality of the flows, a rate at which data units for the flow are being received; and
set an excessive rate indicator for each flow of the plurality of flows that is being received at a rate that exceeds a particular threshold;
an excessive rate policy resolver, configured to
cause dropping of data units that belong to a particular flow, for which the excessive rate indicator is set, at a higher rate than one or more flows that do not have the excessive rate indicator set.
As shown, claim 1 of U.S. Patent No. 12,081,444 teaches each of the limitations in claim 1 of the present application except the limitation reciting an excessive rate policy resolver configured to send a transmission pause request to a sender of data units for a flow having an excessive rate indicator that is set.
However, Beecroft et al. (US 2022/0210081) teaches sending a transmission pause request to a sender of data units for a flow having an excessive rate indicator that is set (Pause is asserted at the point an input buffer is in danger of overflowing and packet drops will occur, [0095]; To slow down data injection from the source, an FGFC logic block on an ingress edge switch (for example, FGFC logic block 434 in edge switch 406 in FIG. 4A) can use a pause-credit hybrid method to throttle incoming data associated a particular flow or group of flows. A pause-based method typically involves a receiving end issuing a pause command to the transmitter end, which in response can stop transmission until further notice, [0096]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to issue a pause command to a flow source in the system/method of present application as suggested by Beecroft as a way to manage flows which are overwhelming a system. One would be motivated to combine these teachings because a source pausing transmission of a flow would allow time for the system to catch up and properly process packets of the flow.
The following table lists the correspondences between each of the additional claims:
Present Application 18/823,281
U.S. Patent No. 12,081,444
Claim 2
Claim 2
Claim 3
Claim 3
Claim 4
Claim 4
Claim 5
Claim 5
Claim 6
Claim 6
Claim 7
Claim 7
Claim 8
Claim 9
Claims 10 and 18
Claim 10
Claim 11
Claim 11
Claim 12
Claim 12
Claim 13
Claim 13
Claim 14
Claim 14
Claim 15
Claim 15
Claim 16
Claim 16
Claim 17
Claim 18
Claim 19 and 20
Claim 19
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
5. Claims 1, 2, 8, 10, 11, 17, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers et al. (US 2019/0260686, cited in the IDS dated 09/25/2024) in view of Beecroft et al. (US 2022/0210081).
Regarding claim 1, Bowers teaches a network switching apparatus comprising:
a plurality of communication interfaces configured to receive and send data units (Network interface 100 includes one or more ports 102-0 to 102-A. A port can represent a physical port or virtual port. A packet received at a port 102-0 to 102-A is provided to transceiver 104, [0019]; Switch 704 can route packets or frames of any format or in accordance with any specification from any port 702-0 to 702-X to any of ports 706-0 to 706-Y (or vice versa), [0060]);
ingress packet processing logic configured to identify flows among a plurality of flows to which received data units belong (classifier 110 can determine a flow associated with a TCP packet from one or more of: a destination port, a destination IP address, a destination port, or a destination IP address, [0019]; A flow classification can be performed to determine a flow associated with the received packet. The flow of the received packet can be determined based on header or payload properties of the received packet (or both), [0040]);
a flow tracker, configured to:
calculate a data rate at which data units for one or more flows among the plurality of the flows are being received (At 414, a flow counter is read for the current flow. For example, a determination of a packet receive rate can be made to determine a rate of bytes of received packets per second, [0043]; The flow counter can indicate a packet receive rate of the flow. For example, the packet receive rate can be based on the determined received packet bytes over a measure of time (e.g., bytes/second), [0044]); and
set an excessive rate indicator for each flow of the one or more flows that has a data rate that exceeds a particular threshold (The flow can be identified as a heavy flow based on whether the packet receive rate of the flow over the interval of time meets or exceeds a threshold. If the flow is determined to be a heavy flow, then 458 follows where a flow rule is added to identify the flow as a heavy flow and subsequent received packets in the heavy flow can be directed to a heavy queue, [0044]).
However, Bowers does not explicitly disclose an excessive rate policy resolver, configured to send a transmission pause request to a sender of data units for a flow having an excessive rate indicator that is set.
Beecroft teaches an excessive rate policy resolver, configured to send a transmission pause request to a sender of data units for a flow having an excessive rate indicator that is set (Pause is asserted at the point an input buffer is in danger of overflowing and packet drops will occur, [0095]; To slow down data injection from the source, an FGFC logic block on an ingress edge switch (for example, FGFC logic block 434 in edge switch 406 in FIG. 4A) can use a pause-credit hybrid method to throttle incoming data associated a particular flow or group of flows. A pause-based method typically involves a receiving end issuing a pause command to the transmitter end, which in response can stop transmission until further notice, [0096]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to issue a pause command to a flow source in the system/method of Bowers as suggested by Beecroft as a way to manage flows which are overwhelming a system. One would be motivated to combine these teachings because a source pausing transmission of a flow would allow time for the system to catch up and properly process packets of the flow.
Regarding claim 2, Bowers teaches the network switching apparatus of Claim 1, wherein the flow tracker is further configured to track the data rate by incrementing a rate counter assigned to each flow among the one or more flows whenever a data unit belonging to the flow is received (Flow counter 112 can determine a count of received bytes per second for a flow of TCP packets (or other types of packets), [0020]).
Regarding claim 8, Bowers teaches the network switching apparatus of Claim 1, wherein the excessive rate policy resolver is further configured to cause a packet switcher to send data units belonging to the flow having an excessive rate indicator that is set to a different egress queue than when the flow has the excessive rate indicator not set (If driver 168 detects the bytes/second of packets in a flow exceeds a threshold, the flow can be considered heavy and driver 168 instructs filter 114 to route packets in the heavy flow to a heavy receive queue 120, [0021]; flow 1 and flow 5 are re-classified from normal non-heavy flows to heavy flows. A network interface filter directs the heavy flows 1 and 5 to respective queues Q2 and Q3, [0034]).
Claim 10 comprises limitations similar to those of claim 1, and is therefore rejected in view of the same rationale.
Claim 11 comprises limitations similar to those of claim 2, and is therefore rejected in view of the same rationale.
Claim 17 comprises limitations similar to those of claim 8, and is therefore rejected in view of the same rationale.
Claim 19 comprises limitations similar to those of claim 1, and is therefore rejected in view of the same rationale.
6. Claims 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers-Beecroft in view of Ikeda et al. (CA 2,190,716).
Regarding claim 3, Bowers teaches the network switching apparatus of Claim 1, wherein the flow tracker is further configured to track an activity status of each flow among the one or more flows (Flow counter 112 can determine a count of received bytes per second for a flow of TCP packets (or other types of packets), [0020]).
However, Bowers-Beecroft do not explicitly disclose updating an idle timeout value assigned to the flow when a data unit belonging to the flow is received.
Ikeda teaches tracking an activity status of each flow among one or more flows by updating an idle timeout value assigned to the flow when a data unit belonging to the flow is received (In the server control section 50, when the received VC in the VC table 52 is in an idle state, the state is changed to active, page 5 lines 14-18).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to track idle and active states in the system/method of Bowers-Beecroft as suggested by Ikeda when counting transmitted data rates. One would be motivated to combine these teachings because maintaining an updated status of a particular channel and timing between received packets would enable better management of buffer and flow control.
Claim 12 comprises limitations similar to those of claim 3, and is therefore rejected in view of the same rationale.
7. Claims 4 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers-Beecroft in view of Waclawsky et al. (US 2014/0334296).
Regarding claim 4, Bowers-Beecroft do not explicitly disclose the network switching apparatus of Claim 1, wherein the flow tracker is further configured to ignore flows among the plurality of flows that have an indication of one or both of: an inactive activity status or a low rate at which data units are being received.
Waclawsky teaches wherein a flow tracker is further configured to ignore flows among a plurality of flows that have an indication of one or both of: an inactive activity status or a low rate at which data units are being received (some traffic flows (e.g., short flows, low rate flows, etc.) have little impact on network congestion such that reducing their transmission rate may diminish quality of service (QoS) for those flows without meaningfully mitigating congestion, [0018]; congestion conditions may be ignored for short flows, high priority flows, flows being communicated at low transmission rates, flows destined for wireless networks, or any other situation in which reducing the transmission rate is undesirable, [0019]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to ignore flows being communicated at low transmission rates in the system/method of Bowers-Beecroft as suggested by Waclawsky when monitoring flows for congestion conditions. One would be motivated to combine these teachings so as to not use resources for tracking flows which have little impact or are unlikely to meaningfully contribute to congestion.
Claim 13 comprises limitations similar to those of claim 4, and is therefore rejected in view of the same rationale.
8. Claims 5, 9, 14, 18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers-Beecroft in view of Caia et al. (US 2003/0206522).
Regarding claim 5, Bowers-Beecroft do not explicitly disclose the network switching apparatus of Claim 1, wherein the excessive rate policy resolver is further configured to tag data units belonging to the flow having an excessive rate indicator that is set with an excessive-rate or congestion indicator.
Caia teaches wherein an excessive rate policy resolver is further configured to tag data units belonging to a flow having an excessive rate indicator that is set with an excessive-rate or congestion indicator (A non-compliant state 120 means that the flow rate is above its programmed threshold; that is, the flow rate policy is violated and subsequent packets are tagged or dropped, [0009]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to tag packets in a flow being transmitted at a rate above a threshold in the system/method of Bowers-Beecroft as suggested by Caia in order to indicate which packets belong to a flow associated with certain conditions. One would be motivated to combine these teachings so that network elements can identify and properly process packets of a flow which should be treated differently.
Regarding claim 9, Bowers-Beecroft do not explicitly disclose the network switching apparatus of Claim 1, wherein the excessive rate policy resolver is further configured to cause a packet switcher to drop data units that belong to the flow having an excessive rate indicator that is set at a higher rate than one or more flows that do not have the excessive rate indicator set.
Caia teaches wherein an excessive rate policy resolver is further configured to cause a packet switcher to drop data units that belong to a flow having an excessive rate indicator that is set at a higher rate (A non-compliant state 120 means that the flow rate is above its programmed threshold; that is, the flow rate policy is violated and subsequent packets are tagged or dropped, [0009]) than one or more flows that do not have the excessive rate indicator set (A compliant state 110 means that the flow rate is below its programmed threshold; that is, the flow rate policy is met and subsequent packets are not tagged, [0009]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to drop packets from a flow with a very high data rate in the system/method Bowers-Beecroft as suggested by Cai in order to avoid excessive congestion and buffer overflow. One would be motivated to combine these teachings to ensure enforcement of network policies and fair resource distribution.
Claim 14 comprises limitations similar to those of claim 5, and is therefore rejected in view of the same rationale.
Claim 18 comprises limitations similar to those of claim 9, and is therefore rejected in view of the same rationale.
Claim 20 comprises limitations similar to those of claim 9, and is therefore rejected in view of the same rationale.
9. Claims 6 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers-Beecroft in view of Akahane et al. (US 2005/0276230).
Regarding claim 6, Bowers teaches the network switching apparatus of Claim 1, wherein the excessive rate policy resolver is configured to take action on one or more of the data units belonging to the flow having an excessive rate indicator that is set (If driver 168 detects the bytes/second of packets in a flow exceeds a threshold, the flow can be considered heavy and driver 168 instructs filter 114 to route packets in the heavy flow to a heavy receive queue 120, [0021]; flow 1 and flow 5 are re-classified from normal non-heavy flows to heavy flows. A network interface filter directs the heavy flows 1 and 5 to respective queues Q2 and Q3, [0034]).
However, Bowers-Beecroft do not explicitly disclose causing a packet switcher to clone one or more of the data units and forwarding the cloned one or more of the data units to a collector.
Akahane teaches causing a packet switcher to clone one or more of data units belonging to a flow having an indicator that is set and forward the cloned one or more of the data units to a collector (a second statistics control entry defining the statistics control information which indicates to generate a copy of each of the received packets in the packet flow corresponding to the flow identification condition at a specified sampling rate and, when the second statistics control entry is found as the entry corresponding to the flow searching key, the searching unit starts a control operation for generating the copy of the received packet corresponding to the flow identification condition and transferring the copy packet to a specified statistic information collection apparatus, [0026]; The sampling flag 635 indicates that, when the set value is "1", a copy of the received packet should be generated in accordance with the sampling rate 636 and transferred to the collector apparatus C1, [0130]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to transfer a copy packets to a collector in the system/method of Bowers-Beecroft as suggested by Akahane in order for the collector to analyze traffic flows over a network. One would be motivated to combine these teachings because analyzing flow-by-flow statistics would provide information on traffic patterns to better manage network communication resources and quality assurance.
Claim 15 comprises limitations similar to those of claim 6, and is therefore rejected in view of the same rationale.
10. Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Bowers-Beecroft in view of Lamb et al. (US 2013/0235725).
Regarding claim 7, Bowers-Beecroft do not explicitly disclose the network switching apparatus of Claim 1, wherein the excessive rate policy resolver is further configured to adjust a Weighted Random Early Detection (“WRED”) curve that is applied to the flow having an excessive rate indicator that is set and is used to determine a probability for discarding data units on enqueue.
Lamb teaches wherein an excessive rate policy resolver is further configured to adjust a Weighted Random Early Detection (“WRED”) curve that is applied to a flow having an excessive rate indicator that is set (the maximum threshold is selected from a plurality of tail rules maintained by packet processor 210. In block 630, packet processor 210 selects a minimum threshold. In one embodiment, the minimum threshold is selected from a plurality of WRED rules maintained by the packet processor 210, [0045]; This tail dropping can continue until packet processor 210 again performs block 610 to measure the global resource usage measured by the block, at which point blocks 620 through 680 are performed again, based on the updated measured global resource usage, [0051]) and is used to determine a probability for discarding data units on enqueue (FIG. 4 illustrates an exemplary WRED drop plot 400. Plot 400 contrasts the probability that a chunk of data will be randomly dropped from a queue with some measure of the occupancy or fullness of the queue (e.g., average queue length), [0037]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize dynamic WRED rules in the system/method of Bowers-Beecroft as suggested by Lamb in order to allow for varying drop profiles based on real-time conditions and different data priorities. One would be motivated to combine these teachings because it would provide increased flexibility based on current network situations and packet flows.
Claim 16 comprises limitations similar to those of claim 7, and is therefore rejected in view of the same rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kadambi et al. US 6,952,401 – a network switch taking action when a flow rate exceeds a flow rate threshold.
Kwan et al. US 9,215,174 – initiating adjustment of an ingress packet rate in response to an indication of congestion.
Chen et al. US 2013/0155858 – congestion management of buffers receiving a plurality of data flows including a plurality of packets.
Ramanathan et al. US 2014/0219090 – a network device monitoring a congestion level of a plurality of queues and using an alternative queue when congestion is detected.
Bottorff et al. US 2015/0229575 – determining whether a flow control threshold of a queue has been exceeded and sending a message to a source including a pause duration to stop transmitting frames.
Melman et al. US 2017/0339074 – congestion avoidance by determining that a packet should be dropped according to criteria that ensure that overflow of an egress queue in which the packet is to be enqueued is avoided.
Xia et al. US 2020/0099624 – a flow control solution based on a pause frame to resolve a traffic overload problem indicated by a threshold.
Lee et al. US 2020/0280518 – generating a congestion notification packet to a sender of a packet based on random early detection of congestion in a target queue.
Lee et al. US 2021/0320866 – detecting congestion by a queue level exceeding a threshold level or rate of change and pausing flows in response.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MADHU WOOLCOCK whose telephone number is (571)270-3629. The examiner can normally be reached Tuesday, Thursday 9-6 ET.
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, Chris Parry can be reached at 571-272-8328. 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.
MADHU WOOLCOCK
Examiner
Art Unit 2451
/MADHU WOOLCOCK/Primary Examiner, Art Unit 2451