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 .
Election/Restrictions
Claims 1-11 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected inventions, there being no allowable generic or linking claim. Election was made without traverse in the reply filed on August 14, 2026.
Applicant’s election without traverse of claims 12-20 in the reply filed on August 14, 2026 is acknowledged.
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 12-20 are 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.
Claim 12 recites the limitation “the network devices”. There is insufficient antecedent basis for this limitation in the claim. It appears that claim 12 should be amended to change the phrase “…dampening network activity associated with the network devices…” to ““…dampening network activity associated with the network interfaces…” in view of the disclosure of the specification. Claims 13-20 are rejected as being dependent upon claim 12.
Claim 13 recites the limitation "the first duration" and “the second duration” in lines 1-2. There is insufficient antecedent basis for this limitation in the claim. Claims 14-15 are also rejected as being dependent upon claim 13.
Claim 16 recites the limitation "identifying the first network interface having the associated sequence of link state changes that exceeds the predefined time rate threshold" in lines 1-3. There is insufficient antecedent basis for this limitation in the claim. Claims 17-8 also rejected as being dependent upon claim 16.
Claim 19 recites the limitations "the first network interface" in line 3, and “the predetermined time rate threshold” in line 7. There is insufficient antecedent basis for these limitations in the claim. Claim 20 is also rejected as being dependent upon 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.
Claim(s) 12-14 are rejected under 35 U.S.C. 103 as being unpatentable over Floyd, III et al. (US 2018/0006875 A1)(hereinafter “Floyd”) in view of Agarwal (US 9,210,067 B1)(hereinafter “Agarwal”).
Regarding claim 12, Floyd discloses a method comprising:
detecting, by a network device (Fig. 1, [0014]: isolable switch 102), link state toggling bursts associated with respective network interfaces of the network device ([0014]: embodiments presented in this disclosure provide techniques for dampening flapping rates of network interfaces to improve stability of a network environment. [0015]: network instability may occur when the network interface 110 exhibits flapping behavior. In one embodiment, the flapping behavior is characterized by a failure of the isolable switch 102, that causes the network interface 110 to continually fluctuate between online and offline states. Fig. 4, [0029]: at step 406, the dampening logic 108 determines whether the threshold count of flapping occurrences has been exceeded. If so, then at step 412, the dampening logic 108 sends an indication to the connected switch 104 that the interface 110 is to be designated as being in the isolated mode.);
responsive to the detection, dampening network activity associated with the network devices (Fig. 4, [0029]: at step 406, the dampening logic 108 determines whether the threshold count of flapping occurrences has been exceeded. If so, then at step 412, the dampening logic 108 sends an indication to the connected switch 104 that the interface 110 is to be designated as being in the isolated mode. The indication also conveys to the connected switch 104 to designate the network interface 114 as being in the isolated mode.), wherein the dampening comprises:
disabling, by the network device, the network interfaces for respective recovery times ([0029]: at step 412, the dampening logic 108 sends an indication to the connected switch 104 that the interface 110 is to be designated as being in the isolated mode. The indication also conveys to the connected switch 104 to designate the network interface 114 as being in the isolated mode. At least in some embodiments, the indication includes an isolation duration for the isolable switch 102 and the connected switch 104 to each take into account in keeping the network interfaces 110, 114 in the isolated mode.)…;
measuring, by the network device, the recovery times (Fig. 7, [0036]: the method 700 begins at step 702, where the dampening logic 108 checks the isolation timer. ); and
re-enabling, by the network device, the network interfaces responsive to expirations of the respective recovery times (Fig. 7, [0036]: if the isolation timer indicates that the isolation duration has elapsed (step 704), the dampening logic 108 designates the network interface 110 as being in the active mode, thereby exiting the isolated mode (step 706). At least in some embodiments, the reply logic 112 similarly designates the network interface 114 as being in the active mode upon determining that the isolation duration has elapsed, thereby exiting the isolated mode.).
Floyd does not disclose that the respective recovery times are different with respect to each other. However, Agarwal discloses respective recovery times that are different with respect to each other (col. 6, lines 26-34: a misbehaving or flapping interface could generate a large number of interface state change events, which can cause a large number of messages to be sent to the master node. In one embodiment, the client node does not throttle the messages that the client node sends to the master node; instead, the client node throttles the interface state change events themselves, i.e., the client node stops generating interface state change events for misbehaving or flapping interfaces. Col. 7, lines 38-45: if the network has a large number of client nodes, the master node may receive a large number of “hello reply” messages at the same time, which can cause congestion. To prevent this, the client node can start a timer with a random interval value, and send the “hello reply” message when the timer expires. The random interval timer can help spread out the “hello reply” messages over a time interval. Col. 12, lines 3-7: client nodes can use a timer to determine when to send a “hello reply” message. For example, when a client node receives a “hello” message, the client node can start a timer with a random value. When the timer expires, the client node can send a “hello reply” message to the master node. Accordingly, Agarwal discloses setting random values for recovery times for different node interfaces to begin sending messages for recovering from flapping conditions, thereby producing recovery times that are different with respect to each other.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to disable, by a network device, network interfaces for respective recovery times, as taught by Floyd, in which the respective recovery times are different with respect to each other, as taught by Agarwal. Doing so allows for reducing congestion by preventing network interfaces to begin communicating at substantially the same time (see Agarwal, col. 7, lines 38-45).
Regarding claim 13, Floyd in view of Agarwal discloses all features of claim 12 as outlined above.
Floyd does not disclose wherein varying the first duration relative to the second duration comprises randomly or pseudorandomly generating a first time value corresponding to the first duration and randomly or pseudorandomly generating a second time value corresponding to the second duration. However, Agarwal discloses wherein varying the first duration relative to the second duration comprises randomly or pseudorandomly generating a first time value corresponding to the first duration and randomly or pseudorandomly generating a second time value corresponding to the second duration (Col. 7, lines 38-45: if the network has a large number of client nodes, the master node may receive a large number of “hello reply” messages at the same time, which can cause congestion. To prevent this, the client node can start a timer with a random interval value, and send the “hello reply” message when the timer expires. The random interval timer can help spread out the “hello reply” messages over a time interval. Col. 12, lines 3-7: client nodes can use a timer to determine when to send a “hello reply” message. For example, when a client node receives a “hello” message, the client node can start a timer with a random value. When the timer expires, the client node can send a “hello reply” message to the master node. Accordingly, Agarwal discloses setting different duration recovery durations (e.g., a first and second time value) for different interfaces in which the first and second times values are determined randomly or pseudorandomly.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to disable, by a network device, network interfaces for respective recovery times, as taught by Floyd, in which the respective recovery times are determined randomly or pseudorandomly, as taught by Agarwal. Doing so allows for reducing congestion by preventing network interfaces to begin communicating at substantially the same time (see Agarwal, col. 7, lines 38-45).
Regarding claim 14, Floyd in view of Agarwal discloses all features of claim 13 as outlined above.
Floyd also discloses reading, by the network device, configuration data representing a boundary for the first time value, wherein…generating the first time value comprises constraining the first time value to the boundary ([0029]: at step 412, the dampening logic 108 sends an indication to the connected switch 104 that the interface 110 is to be designated as being in the isolated mode. The indication also conveys to the connected switch 104 to designate the network interface 114 as being in the isolated mode. At least in some embodiments, the indication includes an isolation duration for the isolable switch 102 and the connected switch 104. The examiner submits that the indicated duration is indicative of a boundary for the time value.).
Floyd does not disclose wherein the time value is generated randomly or pseudorandomly. However, Agarwal discloses generating the first time value randomly or pseudorandomly ((Col. 7, lines 38-45: if the network has a large number of client nodes, the master node may receive a large number of “hello reply” messages at the same time, which can cause congestion. To prevent this, the client node can start a timer with a random interval value, and send the “hello reply” message when the timer expires. The random interval timer can help spread out the “hello reply” messages over a time interval. Col. 12, lines 3-7: client nodes can use a timer to determine when to send a “hello reply” message. For example, when a client node receives a “hello” message, the client node can start a timer with a random value. When the timer expires, the client node can send a “hello reply” message to the master node. Accordingly, Agarwal discloses setting the first time value randomly or pseudorandomly.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to disable, by a network device, network interfaces for respective recovery times, as taught by Floyd, in which the first time value is determined randomly or pseudorandomly, as taught by Agarwal. Doing so allows for reducing congestion by preventing network interfaces to begin communicating at substantially the same time (see Agarwal, col. 7, lines 38-45).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Dion (US 2020/0245162 A1) – Network Path Reliability – discloses waiting a pseudo-random time between booth-up before proceeding to path validation.
Klacar et al. (US 2018/0129623 A1) – Link Role Determination In A Dual-Mode Peripheral Component Interconnect Express (PCIe) Device – discloses using a random delay or back-off when a link state indicates that a configuration and initiation sequence on a link has failed.
Sweeney et al. (US 2014/0337506 A1) – System and Method For Slow Link Flap Detection – discloses monitoring a link for a slow link flap event over a plurality of time intervals in which a slow link flap event results from detecting a maximum number of link flap violations over the plurality of time intervals.
Weinstein et al. (US 6,977,937 B1) – Radio Network Routing Apparatus – discloses that a radio node is activate by a power on step after a delay of a random duration. After the delay, a router executes a receiving step for receiving link state information that has been forwarded to the router.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL W MADDOX whose telephone number is (571)272-5834. The examiner can normally be reached M-Th 7:30am-5:00pm, 1st F 7:30am-4:00pm, 2nd F off.
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, Asad M Nawaz can be reached at 571-272-3988. 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.
/MICHAEL WAYNE MADDOX/Examiner, Art Unit 2463
/CHI TANG P CHENG/Primary Examiner, Art Unit 2463
Prosecution Insights