DETAILED ACTION
The amendment to Application Ser. No. 18/933,767 filed on August 3, 2026, has been entered. Claims 1, 15 and 20 are currently amended. Claims 1-20 are pending and are examined.
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 .
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 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.
Information Disclosure Statement
Applicant’s submission of the Information Disclosure Statement dated April 2, 2026, is acknowledged by the Examiner and the cited references have been considered in the examination of the claims now pending (see attached PTO-1449).
Response to Arguments
The arguments with respect to the rejection of Claims 1-20 under 35 U.S.C. 103 have been fully considered by the examiner and are persuasive in part.
The declaration under 37 CFR 1.130(a) filed on August 3, 2026, is sufficient to overcome the rejection of Claims 1-20 based on the IETF Internet Draft authored by Ananthamurthy et al., titled “BGP Route Type Capability”. The declaration asserts that Ananthamurthy conceived of the subject matter regarding the optional capability exchange of route types disclosed in the Internet Draft and that the contributions of the other named authors were limited to non-inventive activities such as reviewing, formatting, and editing the Internet Draft for publication. The rejections under 35 U.S.C. 103 based in part on the teachings of Ananthamurthy are hereby withdrawn.
With respect to rejection of Claim 1 under 35 U.S.C. 103 based on the combination of Wu and Sharma, on page 10 of the response filed August 3, 2026, Applicant argues, “Claims 1-11, 13-17 and 20 were rejected under § 103 over Wu in view of Sharma. Claims 2-11 and 13-14 ultimately depend from independent Claim 1. Applicant notes that dependent claims that depend from an allowable base claim are deemed allowable (In re Hall). Thus, because Applicant believes that independent base Claim 1 is now in a condition for allowance, no further arguments are needed with respect to Claims 2-11 and 13-14. Therefore, Applicant believes that the rejections under 35 U.S.C. §103 should be withdrawn and that Claims 2-11 and 13-14 be allowed. Notice to that effect is requested.”
Examiner respectfully disagrees. Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the combination of Wu and Sharma. For the reasons set forth below in the rejection of Claim 1 under 35 U.S.C. 103, Claim 1 is obvious in view of the combination of Wu and Sharma.
New grounds of rejection under 35 U.S.C. 103, necessitated by the amendment, are set forth in this Office Action.
Claim Interpretation
The references presented herein are read and interpreted in view of an understanding of the Border Gateway Protocol (BGP) as described in the relevant RFCs.
Claim Objections
The claims are objected to because of the following informalities:
regarding Claim 15, the word “is” recited in line 14 should be deleted.
Appropriate correction is required.
Claim Rejections - 35 USC § 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-11, 13-17 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Wu et al., Pub. No. US 2023/0117035 A1, hereby “Wu” in view of the internet draft authored by Sharma et al., Pub. No. US 2025/0080452 A1, hereby “Sharma”.
Regarding Claim 1, Wu discloses “A network device (Wu fig. 5 and paragraph 52: network device 1), comprising:
a processor (Wu fig. 10 and paragraph 127: one or more processors 801); and
a memory communicatively coupled to the processor (Wu fig. 10 and paragraph 127: memory 803), wherein the memory comprises a session logic that is configured to:
receive an announcing message... (Wu fig. 5 and paragraph 52: network device 1 receives an OPEN packet from network device 2);” and
“transmit an update message... to the peer network device (Wu figs. 2 and 5 and paragraphs 48 and 52: network device 1 transmits an Update packet to network device 2).”
However, while Wu discloses that the Open packet comprises an “Optional Parameters” field that can carry “capability indication information” indicating a capability supported by the network device (Wu fig. 2 and paragraphs 48 and 100-101), Wu does not explicitly disclose “receive an announcing message configured to indicate a route type capability of a peer network device, wherein the network device supports a set of route types;
select, based on the route type capability of the peer network device, a subset of route types from the set of route types, wherein the subset of route types corresponds to an intersection of the set of route types supported by the network device and route types supported by the peer network device; and
transmit an update message configured to advertise the subset of route types to the peer network device (emphasis added).”
In the same field of endeavor, Sharma discloses “receive an announcing message configured to indicate a route type capability of a peer network device, wherein the network device supports a set of route types (Sharma fig. 4 and paragraphs 14-15, 26, 29, 43 and 46: router 12 receives a route refresh message, i.e., an announcing message, from a BGP peer, e.g., router 14, wherein the route refresh message includes a subset of Route Types of all of the Route Types, i.e., an indication of route type capability of router 14, wherein router 12 supports a set of route types, e.g., RT1 to RT5);
select, based on the route type capability of the peer network device, a subset of route types from the set of route types, wherein the subset of route types corresponds to an intersection of the set of route types supported by the network device and route types supported by the peer network device (Sharma fig. 4 and paragraphs 26, 43 and 46: router 12 obtains updated route types for the subset of Route Types indicated in the route refresh message – as known in the art, a BGP speaker advertises and updates capabilities that it supports. See RFC 5492. Therefore, while not explicitly stated, selection of the subset of Route Types supported by both router 14 and router 12 is inferred from the obtaining of the updated route types.); and
transmit an update message configured to advertise the subset of route types to the peer network device (Sharma fig. 4 and paragraphs 43 and 46: router 12 sends updated routes for only the subset of Route Types to the BGP peer – while not explicitly stated, sending of the updated routes for the subset of route types using a BGP UPDATE message is implied. See RFC 4271.).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer and to advertise updated rates for only the subset of route types in the Update packet sent to the peer device as suggested by Sharma. One of ordinary skill in the art would have been motivated to combine indicating a subset of route types in the OPEN packet received from the BGP peer and to advertise updated rates for only the subset of route types in the Update packet sent to the peer device to avoid sending of updated routes for all route types when only a selective route types are required (Sharma paragraphs 3 and 40).
Regarding Claim 2, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Wu discloses “wherein the session logic is further configured to transmit another announcing message... to the peer network device (Wu figs. 2 and 5 and paragraphs 48 and 52: network device 1 transmits an OPEN packet to network device 2).”
However, while Wu discloses that the Open packet comprises an “Optional Parameters” field that can carry “capability indication information” indicating a capability supported by the network device (Wu fig. 2 and paragraphs 48 and 100-101), Wu does not explicitly disclose “wherein the session logic is further configured to transmit another announcing message configured to indicate a route type capability of the network device to the peer network device (emphasis added)”.
In the same field of endeavor, Sharma discloses using bits in the reserved field or payload of the route refresh message to indicate the subset of route types (Sharma paragraphs 29 and 45-47: “In an embodiment, bits in the reserved field can be used to designate one or more Route Types for the subset of Route Types based on the indication in the reserved field.”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 3, the combination of Wu and Sharma discloses all of the limitations of Claim 2.
Additionally, Wu discloses “wherein the session logic is further configured to transmit the another announcing message prior to transmitting the update message (Wu fig. 5 and paragraph 52: as shown in Figure 5, network device 1 sends the Open packet to network device 2 before sending the Update packet to network device 2).”
Regarding Claim 4, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Wu discloses “wherein a Border Gateway Protocol session is established between the network device and the peer network device based on the announcing message (Wu fig. 5 and paragraph 52: while not explicitly stated, establishment of the BGP session between network device 1 and network device 2 is implied. See RFC 4271.).”
Regarding Claim 5, the combination of Wu and Sharma discloses all of the limitations of Claim 4.
Additionally, Wu discloses “wherein the session logic is further configured to transmit the update message during the Border Gateway Protocol session (Wu fig. 5 and paragraph 52: while not explicitly stated, sending of the Update packet during the established BGP session is implied. See RFC 4271.).”
Regarding Claim 6, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Sharma discloses “wherein the route type capability indicates one or more route types supported by the peer network device (Sharma paragraphs 29 and 45-47: “In an embodiment, bits in the reserved field can be used to designate one or more Route Types for the subset of Route Types based on the indication in the reserved field.”).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 7, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Wu discloses “wherein the announcing message corresponds to a Border Gateway Protocol OPEN message (Wu figs. 2 and 5 and paragraphs 48 and 52: the Open packet is a BGP Open message).”
Regarding Claim 8, the combination of Wu and Sharma discloses all of the limitations of Claim 7.
However, while Wu discloses that the Open packet comprises an “Optional Parameters” field that can carry “capability indication information” indicating a capability supported by the network device (Wu fig. 2 and paragraphs 48 and 100-101), Wu does not explicitly disclose “wherein the Border Gateway Protocol OPEN message includes an optional parameters field that is configured to indicate the route type capability (emphasis added)”.
In the same field of endeavor, Sharma discloses using bits in the reserved field or payload of the route refresh message to indicate the subset of route types (Sharma paragraphs 29 and 45-47: “In an embodiment, bits in the reserved field can be used to designate one or more Route Types for the subset of Route Types based on the indication in the reserved field.”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate the subset of route types in the Optional Parameters field of the BGP Open message as suggested by Sharma because doing so constitutes a simple substitution of one known element (a reserved field) for another (an Optional Parameters field) to obtain predictable and desirable results (indicating the subset of route types). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
Regarding Claim 9, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Wu discloses “wherein the update message corresponds to a Border Gateway Protocol UPDATE message (Wu figs. 3 and 5 and paragraphs 49 and 52: the Update packet is a BGP UPDATE message).
Regarding Claim 10, the combination of Wu and Sharma discloses all of the limitations of Claim 9.
Additionally, Sharma discloses “wherein the Border Gateway Protocol UPDATE message includes a network layer reachability information field that is configured to advertise the subset of route types (Sharma fig. 4 and paragraphs 43 and 46: router 12 sends updated routes for only the subset of Route Types to the BGP peer – while not explicitly stated, advertising the subset of Route Types within an NLRI field of a BGP UPDATE message is implied. See RFC 4760.).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer and to advertise updated rates for only the subset of route types in the Update packet sent to the peer device as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 11, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Sharma discloses “wherein the route type capability is associated with at least one of an Address Family Indicator (AFI) or a Subsequent AFI (SAFI) (Sharma figure 2 and paragraphs 15, 26 and 29-30: the new type is associated with an AFI and SAFI ).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 13, the combination of Wu and Sharma discloses all of the limitations of Claim 1.
Additionally, Sharma discloses “wherein the route type capability is associated with a unique identifier code (Sharma fig. 2 and paragraphs 29-30 and 46-47: a new value is assigned to indicate the resource refresh message is a new type – while not explicitly stated, uniqueness of the value is implied in order for the new type to be identified).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 14, the combination of Wu and Sharma discloses all of the limitations of Claim 13.
Additionally, Sharma discloses “wherein the announcing message is further configured to indicate the unique identifier code (Sharma fig. 2 and paragraphs 29-30 and 46-47: a new value is indicated in reserved field 22 of resource refresh message 20).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 1.
Regarding Claim 15, Wu discloses “A network device (Wu fig. 5 and paragraph 52: network device 2), comprising:
a processor (Wu fig. 10 and paragraph 127: one or more processors 801); and
a memory communicatively coupled to the processor (Wu fig. 10 and paragraph 127: memory 803), wherein the memory comprises a session logic that is configured to:
transmit an announcing message... (Wu figs. 2 and 5 and paragraphs 48 and 52: network device 2 sends an OPEN packet to network device 1);” and
“receive, in response to the announcing message, an update message from the peer network device (Wu figs. 2 and 5 and paragraphs 48 and 52: network device 2 receives an Update packet from network device 1).”
However, while Wu discloses that the Open packet comprises an “Optional Parameters” field that can carry “capability indication information” indicating a capability supported by the network device (Wu fig. 2 and paragraphs 48 and 100-101), Wu does not explicitly disclose “transmit an announcing message configured to indicate a route type capability of the network device to a peer network device, wherein the peer network device supports a set of route types (emphasis added);” and
“wherein: the update message is configured to advertise a subset of route types selected from the set of route types based on the route type capability, and the subset of route types corresponds to an intersection of the set of route types supported by the peer network device and route types is supported by the network device.”
In the same field of endeavor, Sharma discloses “transmit an announcing message configured to indicate a route type capability of the network device to a peer network device, wherein the peer network device supports a set of route types (Sharma fig. 4 and paragraphs 14-15, 26, 29, 43 and 46: router 14, transmits a route refresh message, i.e., an announcing message, to a BGP peer, e.g., router 12, wherein the route refresh message includes a subset of Route Types of all of the Route Types, i.e., an indication of route type capability of router 14, wherein router 12 supports a set of route types, e.g., RT1 to RT5); and
receive, in response to the announcing message, an update message from the peer network device (Sharma fig. 4 and paragraphs 43 and 46: router 14 receives updated routes for only the subset of Route Types from router 12 – while not explicitly stated, sending of the updated routes for the subset of route types using a BGP UPDATE message is implied. See RFC 4271.), wherein:
the update message is configured to advertise a subset of route types selected from the set of route types based on the route type capability, and the subset of route types corresponds to an intersection of the set of route types supported by the peer network device and route types is supported by the network device (Sharma fig. 4 and paragraphs 26, 43 and 46: router 12 obtains updated route types for the subset of Route Types indicated in the route refresh message – as known in the art, a BGP speaker advertises and updates capabilities that it supports. See RFC 5492. Therefore, while not explicitly stated, selection of the subset of Route Types supported by both router 14 and router 12 is inferred from the obtaining of the updated route types.).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer and to advertise updated rates for only the subset of route types in the Update packet sent to the peer device as suggested by Sharma. One of ordinary skill in the art would have been motivated to combine indicating a subset of route types in the OPEN packet received from the BGP peer and to advertise updated rates for only the subset of route types in the Update packet sent to the peer device to avoid sending of updated routes for all route types when only a selective route types are required (Sharma paragraphs 3 and 40).
Regarding Claim 16, the combination of Wu and Sharma discloses all of the limitations of Claim 15.
Additionally, Wu discloses “wherein the session logic is further configured to receive another announcing message... (Wu figs. 2 and 5 and paragraphs 48 and 52: network device 2 receives an Open packet from network device 1).”
However, while Wu discloses that the Open packet comprises an “Optional Parameters” field that can carry “capability indication information” indicating a capability supported by the network device (Wu fig. 2 and paragraphs 48 and 100-101), Wu does not explicitly disclose “wherein the session logic is further configured to receive another announcing message that indicates a route type capability of the peer network device (emphasis added)”.
In the same field of endeavor, Sharma discloses using bits in the reserved field or payload of the route refresh message to indicate the subset of route types (Sharma paragraphs 29 and 45-47: “In an embodiment, bits in the reserved field can be used to designate one or more Route Types for the subset of Route Types based on the indication in the reserved field.”).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu to indicate a subset of route types in the OPEN packet received from the BGP peer as suggested by Sharma for the reasons set forth in the rejection of Claim 15.
Regarding Claim 17, the combination of Wu and Sharma discloses all of the limitations of Claim 15.
Additionally, Wu discloses “wherein the network device and the peer network device are acting as Border Gateway Protocol speakers (Wu fig. 5 and paragraph 52: while not explicitly stated, network device 1 and network device 2 are necessarily acting as BGP speakers by virtue of their implementing BGP. See RFC 4271.).
Insofar as it recites similar claim elements, Claim 20 is rejected for substantially the same reasons presented above with respect to Claim 1.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wu and Sharma in view of Appanna et al., Pub. No. US 2008/0089348 A1, hereby “Appanna”.
Regarding Claim 12, the combination of Wu and Sharma discloses all of the limitations of Claim 11.
However, while Sharma discloses the route type capability is associated with at least one of an Address Family Indicator (AFI) or a Subsequent AFI (SAFI) (Sharma figure 2 and paragraphs 15, 26 and 29-30), the combination of Wu and Sharma does not explicitly disclose “wherein the announcing message is further configured to indicate at least one of the AFI or the SAFI.
In the same field of endeavor, Appanna discloses including AFI and SAFI associated with a supported capability within the BGP OPEN message (Appanna fig. 3 and paragraph 77: BGP OPEN message 300 comprises AFI field 303 and sub-AFI (SAFI) field 304).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu, as modified by Sharma, to include the AFI and SAFI associated with the Route Type capability in the BGP Open message as taught by Appanna because doing so constitutes applying a known technique (including the AFI and SAFI associated with a supported capability in a BGP Open message) to known devices and/or methods (a network device implementing BGP) ready for improvement to yield predictable and desirable results (indication of the Route Types supported). See KSR International Co. v. Teleflex Inc., 82 USPQ2d 1385 (U.S. 2007).
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wu and Shamra in view of Chen, Pat. No. US 6,553,423 B1.
Regarding Claim 18, the combination of Wu and Sharma discloses all of the limitations of Claim 15.
However, while Sharma discloses including an indication of the subset of route types within the route refresh message (Sharma paragraphs 29 and 45-47), the combination of Wu and Sharma does not explicitly disclose “wherein the session logic is further configured to determine an update in the route type capability.”
In the same field of endeavor, Chen suggests determining an update to an advertised capability (Chen column 5, line 56 through column 7, line 56: a BGP-enabled router announces an updated capability to a peer router - while not explicitly stated, detection of an updated capability is implied).
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu, as modified by Sharma, to detect an updated capability as taught by Chen. One of ordinary skill in the art would have been motivated to combine detecting an updated capability to enable the network device to dynamically announce updates of capabilities to peer devices (Chen column 3, lines 13-18).
Regarding Claim 19, the combination of Wu, Sharma and Chen discloses all of the limitations of Claim 18.
Additionally, Chen discloses “wherein the session logic is further configured to transmit a new announcing message configured to indicate the updated route type capability to the peer network device (Chen column 5, line 56 through column 7, line 56: the router announces sends BGP capability message 800, i.e., a new announcing message, to announce the updated capability to a BGP peer).”
It would have been obvious to one of ordinary skill in the art at the time of the effective filing to modify the network device of Wu, as modified by Sharma, to detect an updated capability as taught by Chen for the reasons set forth in the rejection of Claim 18.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Dutta et al., Pub. No. US 2022/0094637 A1, discloses techniques for reducing unnecessary sessions and reachability advertisements between routers that are interconnected by a mutli-access network, wherein a router can specify supported route types within a field of a Hello Message transmitted during BGP neighbor discovery.
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 WILLIAM C MCBETH whose telephone number is (571)270-0495. The examiner can normally be reached on Monday - Friday, 8:00AM - 4:30PM 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, Vivek Srivastava can be reached on 571-272-7304. 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.
/WILLIAM C MCBETH/Examiner, Art Unit 2449
