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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 3/5/2026 has been entered.
Claim status
Claims 1, 4, and 7-8 are amended.
Claims 1-8 are pending for examination.
Response to arguments.
Re: 35 USC § 103 rejection
Applicant’s response has been fully considered. Independent claims have been amended. Next section provides detailed reasons for rejection based on the amended claims.
35 USC § 103 rejection is not withdrawn.
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.
Claims 1-8 are rejected under 35 U.S.C. 103 as being unpatentable over Thomas et al.( US 11,750,441 B1), hereinafter “Thomas”, in view of “Bidirectional Forwarding Detection (BFD)”, rfc5880, by Katz and Ward, hereinafter “rfc5880”.
Claims 1 and 7:
Regarding claim 1, Thomas teaches a communication system, comprising: at least one processor; and at least one memory device (Thomas: Fig.2) storing instructions which, when executed by the at least one processor, cause the at least one processor to perform operations comprising:
executing a first bidirectional forwarding detection daemon (bfdd) which transmits and receives BFD packets to and from a second bfdd which is a bfdd included in a communication partner of the communication system (Thomas: Col.7, lines 1-5, a packet management (PPM) daemon executing on an SCC 122 of multi-chassis router 4 may generate a periodic packet using a link-level keep-alive protocol and send the packet to neighboring devices and/or nodes at a periodic interval … Examples of link level keep-alive protocols may include a system heartbeat, the Trivial Network Protocol (TNP) developed by Juniper Networks of Sunnyvale, Calif., Bidirectional Forward Detection (BFD) protocol, etc.; and
lines 22-28, “connectivity between two nodes ( e.g., SCC 122A and LCC 128A) may go down; that is, one or 30 more links 136 may become unavailable. A link level keep-alive protocol, such as BFD, may be used to detect a connectivity failure between two adjacent nodes, including interfaces and data links. For example, in BFD operation, nodes exchange hello packets at a specified time interval and detect a neighbor failure if no reply is received within the specified time interval.).
Regarding claim, restricting, in response to detection of no transmission of BFD packets from the second bfdd, transmission of the bidirectional forwarding detection (BFD) packets to the second bfdd by the first bfdd, is not expressly disclosed by Thomas.
Though Thomas fails to expressly disclose the claim element, it discloses, “The destination node sends a reply to the keep-alive probe. Receipt of the reply indicates that the TCP socket is still operational. If the local node does not receive a reply to the keep-alive probe within a predetermined time period, the local node may determine that the TCP socket has failed. The local node may then take actions to remediate that TCP socket, including terminating the TCP socket” (Col.11, lines 8-15).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to interpret the disclosure of terminating the TCP socket, in a broad sense, as, restricting, in response to detection of no transmission of BFD packets from the second bfdd, transmission of the bidirectional forwarding detection (BFD) packets to the second bfdd by the first bfdd, as per the claim.
A person of ordinary skill would be motivated to do so for reduction of waste and resource when a link is failed.
Thomas teaches about communication partners in Col.7, lines 1-5, “a packet management (PPM) daemon executing on an SCC 122 of multi-chassis router 4 may generate a periodic packet using a link-level keep-alive protocol and send the packet to neighboring devices and/or nodes at a periodic interval,”, where the neighboring devices may be considered as communication partners.
Thomas also teaches about IP address of a bfdd in Col. 13, lines 16-25, “error modules 324 may be configured to communicate with BFD daemons 318. This is just one example, error modules 324 may be configured to communicate with any type of link level keep-alive protocol. In one example, BFD 318A may detect an error on a link 370 20 between SCC 122A and LCC 128A. Error module 324A may be configured to read this error and determine the source IP address (e.g., the IP address of SCC 122A) and the destination IP address (e.g., the IP address of LCC 128A) affected by the detected link failure.”
Thomas however fails to teach the claim, releasing the restriction for transmission of the BFD packets in response to the first bfdd receiving address information for a third bfdd which is a bfdd included in the communication partner.
rfc5880 in the same field of endeavor discloses failure scenario in Pg.4, “BFD can provide failure detection on any kind of path between systems, including direct physical links, virtual circuits, tunnels, MPLS Label Switched Paths (LSPs), multihop routed paths, and unidirectional links (so long as there is some return path, of course).”, and multiple BFD sessions, “Multiple BFD sessions can be established between the same pair of systems when multiple paths between them are present in at least one direction, even if a lesser number of paths are available in the other direction (multiple parallel unidirectional links or MPLS LSPs, for example).”; and
in Pg.5, discloses, creations of sessions when an address is received, “The service primitives provided by BFD are to create, destroy, and modify a session, given the destination address and other parameters.”
Based on disclosures by rfc5880, when an address of a bfdd is received, a session will be created and resume transmission of the BFD packets in response to the first bfdd receiving address information for a third bfdd which is a bfdd included in the communication partner, as per the claim.
Regarding the claim, wherein the IP address of the third bfdd is different from an IP address of the second bfdd, it is obvious that when a session is created with a different node, the IP address of the BFD daemon would also be different, that is the third bfdd, the new one, will have IP address different from the second one, the one released. would also be different, and also obvious that the address information indicates that the third bfdd was recovered in response to a node failure in the communication partner, because the switchover happens only when a node fails triggering a failover scenario, as disclosed by Thomas, “The local node may then take actions to remediate that TCP socket, including terminating the TCP socket, restarting the TCP socket, or failing over to a backup node. The backup node may restart and/or maintain the process executed by the local node over a different TCP socket.” (Col.11, lines 14-18).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine disclosure by rfc5880 with that of Thomas to come up with the claimed invention motivated by BFD session running between two nodes by resuming communication in a session after failure of another session, as disclosed by Thomas, “Timely detection and failover in response to failure of individual applications executing on given nodes is required in order to reduce impact on network traffic.” (Col.2, lines 32-35).
Regarding claim 7, it is change in category with respect to claim 1. Claim elements are discussed above in claim 1. Claim is rejected based on rejection of claim 1.
Regarding claim 2, Thomas teaches the communication system according to claim 1 (discussed above),
Thomas however does not teach, but disclosed by rfc5880, wherein the restricting comprises lengthening, in response to the detection, an interval of the transmission of the BFD packets to the second bfdd by the first bfdd. The teaching by Thomas is implied by the following:
(Pg.43 or rfc 5880) “The mechanisms for detecting congestion are outside the scope of this specification, but may include the detection of lost BFD Control packets (by virtue of holes in the authentication sequence number space, or by BFD session failure) or other means. The mechanisms for reducing BFD’s traffic load are the control of the local and remote packet transmission rate via the Min RX Interval and Min TX Interval fields.
Note that any mechanism that increases the transmit or receive intervals will increase the Detection Time for the session”;
“bfd.DetectMult - The desired Detection Time multiplier for BFD Control packets on the local system. The negotiated Control packet transmission interval, multiplied by this variable, will be the Detection Time for this session (as seen by the remote system). This variable MUST be a nonzero integer” (rfc5880); and
“The Detection Time (the period of time without receiving BFD packets after which the session is determined to have failed) is not carried explicitly in the protocol. Rather, it is calculated independently in each direction by the receiving system based on the negotiated transmit interval and the detection multiplier” (rfc5880 § 6.8.4 ) Multiplier value being non-zero, implies that the detection time/interval of BFD transmission.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to combine disclosure by rfc5880 with that of Thomas motivated by taking care of congestion as discussed above and of jitter dictating the number of packets to be missed in a row to declare the session to be down, as disclosed by rfc5880 in § 6.8.4.
Regarding claim 3, Thomas teaches the communication system according to claim 1 (discussed above), wherein the restricting comprises stopping, in response to the detection, the transmission of the BFD packets to the second bfdd by the first bfdd (discussed above in claim 1).
Regarding claim 4, Thomas teaches the communication system according to claim 1 (discussed above).
Though Thomas does not expressly teach, operations further comprise: outputting, in response to the releasing the restriction, an instruction to change a pairing from the second bfdd to the third bfdd, the claim is implied based on the disclosure by Thomas and discussed above in claim 1, “The backup node may restart and/or maintain the process executed by the local node over a different TCP socket.” (Col.11, lines 16-18)”.
Regarding claim 5, combination of Thomas and rfc5880 teaches the communication system according to claim 4 (discussed above), wherein the releasing comprises releasing the restriction on the transmission of the BFD packets to the third bfdd from the first bfdd (implied by disclosure in Thomas Col.10, lines 56-61, “In some examples, applications 310A may communicate between nodes using a transmission control protocol (TCP) socket. Typically, TCP sockets are one-to-one connections defined by the address of a local node ( e.g., Internet protocol (IP) address) and port number) and the address of another node.”. When address is recovered, the socket that includes the address, is active and restriction needs to be removed – the failure recovered, so the transmission of BFD packets will continue and this time to the third bfdd, because that is the bfdd for which socket is active).
Regarding claim 6, combination of Thomas and rfc5880 teaches the communication system according to claim 4 (discussed above).
Regarding the claim, wherein the operations further comprise accessing a storage which stores address data indicating an address of the bfdd included in the communication partner to acquire the address data, wherein the releasing comprises releasing the restriction on the transmission of the BFD packets in response to detection of a change in the address indicated by the address data, though Thomas or rfc5880 does not expressly teach it, to a person of ordinary skill in the art it would have been obvious based on disclosure by Thomas in Col.7, lines 22-28, “if node SCC 122A detects a failure of node LCC128A, a routing table may be updated, and traffic may be routed to other ones of LCCs 128 ( e.g., LCC 128B, LCC 128C, etc.). In addition, if a failure of SCC 122A is detected, multi-chassis router may be configured to perform a failover process so that a backup SCC (e.g., SCC 122B) may take over the control responsibilities of SCC 122A.”. When a backup SCC takes over, the address is changed and the BFD process should be back to normal and restriction released.
Claim 8 is regarding, a communication system, comprising: at least one processor; and at least one memory device storing instructions which, when executed by the at least one processor, cause the at least one processor to perform operations comprising: executing a first bidirectional forwarding detection daemon (bfdd) which transmits and receives bidirectional forwarding detection (BFD) packets to and from a second bfdd which is a bfdd included in a communication partner of the communication system, wherein the BFD packets have a first interval of transmission ; and
restricting, in response to detection of no transmission of BFD packets from the second bfdd, transmission of the BFD packets to the second bfdd by the first bfdd (discussed above in claim 1 where the first interval of transmission is the periodic interval discussed above in claim 1),
wherein the restricting comprises lengthening, in response to the detection, an interval of the transmission of the BFD packets to the second bfdd by the first bfdd to a second interval (discussed above in claim 2) of 20 seconds to 60 seconds (rfc5880: “The actual interval is negotiated between the two systems. This MUST be initialized to a value of at least one second (1,000,000 microseconds) according to the rules described in section 6.8.3.”; The actual interval may be implementation dependent and based on decision of keeping the bandwidth consumed as negligible), and the second interval is longer than the first interval (as discussed above in claim 2, the lengthening of interval implies that second interval is longer than the first interval).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. US 7,957,330 B1 discloses network device’s proactively automatically and dynamically lengthening the response interval in a BFD protocol by negotiating a second response interval to avoid network thrashing.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to INTEKHAAB AALAM SIDDIQUEE whose telephone number is (571)272-0895. The examiner can normally be reached Monday to Friday 9AM-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Yemane Mesfin can be reached at 571-272-3927. 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.
/INTEKHAAB A SIDDIQUEE/Primary Examiner, Art Unit 2462