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 .
Claim 1, 9, 17 has been amended. Claims 21 -25 have been added.
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.
Claim(s) 1-3, 6, 8-11, 14, 16-19, 21-25 is/are rejected under 35 U.S.C. 103 as being unpatentable over LIU et al ("SRv6-based BGP Service Capability" herein after Liu) in view of Zhuang et al. (US20240414079 herein after Zhuang) further in view of Chen (US20220393936).
Regarding claim 1, 9, 17, Liu teaches A Border Gateway Protocol (BGP) speaker (page 6 lines 1-5 “If the BGP speaker can obtain the capability for SRv6-based service of its peers, the advertisements of SRv6-based BGP service routes can be controlled”, page 4 lines 1-12 “If the Transposition Scheme is used … part of SID-1 is encoded in the MPLS Label field of the NLRI, PE1 may choose the route which is originally the SRv6 based route and use the label field in the NLRI of this route as MPLS VPN label for packet encapsulation”)),
and includes an Address Family Indicator (AFI) and a Subsequent Address Family Indicator (SAFI) indicating a specific type of NLRI entries to which the advertised transposition capability applies (page 2 lines 14-25 “this proposal leverages the existing AFI/SAFIs of MPLS-based services …the Transposition Scheme in [RFC9252], the function and/or the argument part of the SRv6 SID is encoded in the MPLS Label filed of the NLRI and the SID value in the SRv6 Services TLV carries only the locator part of the SID),
and advertise a service SID to the BGP peer with transposition based on the capability advertisement of the BGP page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”, (Examiner’s Note: Liu shows the SID and MPLS label are advertised in messages, and page 4 lines 1-10 states that whether the transposition scheme is used == transposition capability, however it is unclear whether Liu advertise based on the BGP peer’s capability and not it own ), page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”)
Liu does not explicitly teach comprising circuitry configured to: wherein the capability advertisement includes the BGP peer’s capability, the capability advertisement of the BGP peer’s capability, wherein the capability advertisement includes an Address Family Indicator (AFI), a Subsequent Address Family Indicator (SAFI), and a field, and wherein the capability advertisement is per RFC 5492, and wherein the capability advertisement is carried in a Capabilities Optional Parameter of a BGP OPEN message.
Zhuang teaches comprising circuitry configured to ([0265] “The communication apparatus includes a memory and a processor. The memory is configured to store program code. The processor is configured to run instructions in the program code, so that the communication apparatus”):
wherein the capability advertisement includes the BGP peer’s capability ([0305] “In an example, when the SID 1 is an SRv6 SID, and the SID 1 is a BGP peer node SID or a BGP peer set SID, the communication apparatus R1 may send an SRv6 SID NLRI to the controller, where the SRv6 SID NLRI includes the SID 1 and an SRv6 BGP peer node SID type-length-value (type length value, TLV). Refer to FIG. 1 b . FIG. 1 b is a schematic diagram of a structure of an SRv6 BGP peer node SID TLV. Key fields in the SRv6 BGP peer node SID TLV are a peer autonomous system number (peer AS number) and a peer border gateway protocol identifier (peer BGP identifier)”),
the capability advertisement of the BGP peer’s capability ([0305] “In an example, when the SID 1 is an SRv6 SID, and the SID 1 is a BGP peer node SID or a BGP peer set SID, the communication apparatus R1 may send an SRv6 SID NLRI to the controller, where the SRv6 SID NLRI includes the SID 1 and an SRv6 BGP peer node SID type-length-value (type length value, TLV). Refer to FIG. 1 b . FIG. 1 b is a schematic diagram of a structure of an SRv6 BGP peer node SID TLV. Key fields in the SRv6 BGP peer node SID TLV are a peer autonomous system number (peer AS number) and a peer border gateway protocol identifier (peer BGP identifier)”),
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Liu to incorporate the teachings of Zhuang. One of ordinary skill in the art would have been motivated to make this modification in order to increase the forwarding efficiency.
Zhuang does not teach wherein the capability advertisement includes an Address Family Indicator (AFI), a Subsequent Address Family Indicator (SAFI), and a field, and wherein the capability advertisement is per RFC 5492, and wherein the capability advertisement is carried in a Capabilities Optional Parameter of a BGP OPEN message.
Chen teaches wherein the capability advertisement includes an Address Family Indicator (AFI), a Subsequent Address Family Indicator (SAFI), and a field ([0125] “ includes a capability code 426 of 1 octet, a capability length 427 of 1 octet, a controllers address family identifier (AFI) 428, a controllers sub-address family identifier (SAFI) 429, and flags 403. The capability code 426 is similar to the capability code 401 of FIG. 4A. The capability length 427 is similar to the capability length 402 of FIG. 4A”),
and wherein the capability advertisement is per RFC 5492 ([0126] “FIG. 4B is based on the capability optional parameters defined by RFC 5492”),
and wherein the capability advertisement is carried in a Capabilities Optional Parameter of a BGP OPEN message.([0128] “Referring now to FIG. 4D, shown is an OPEN message 475 pursuant to RFC 4271 including the capability optional parameter 450 of FIG. 4C. In an embodiment, the controller 109A-D or the NE 110-111 includes the capability optional parameter 450 of FIG. 4C in the OPEN message 475 when the controller 109A-D or the NE 110-111 sending the OPEN message 475 is capable of implementing BGP for network HA (e.g., establishing enhanced BGP sessions 130-133, 203, and 206 and transmitting BGP messages 140 with extensions). The capability optional parameter 450 of FIG. 4C includes either the controllers capability triple 400 of FIG. 4A or the controllers capability triple 425 of FIG. 4B”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Liu, Zhuang to incorporate the teachings of Chen. One of ordinary skill in the art would have been motivated to make this modification in order to increase the reliability.
Regarding claims 2, 10, 18, Liu teaches wherein the circuitry is further configured to advertising the BGP’s transposition capability to the BGP peer (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”), such that the BGP peer utilizes transposition to the BGP speaker based thereon (page 6 lines 1-5 “If the BGP speaker can obtain the capability for SRv6-based service of its peers, the advertisements of SRv6-based BGP service routes can be controlled”).
Regarding claim 3, 11, 19, Liu teaches wherein the circuitry is further configured to failing to receive a second capability advertisement from a second BGP peer where the capability advertisement includes the BGP peer’s transposition capability (page 4 lines 1-15 “if the Transposition Scheme is used … 2) be dropped, in case the value of sid-1 does not correspond to an allocated MPLS label, page 6 lines 1-20 “if it has not received the SRv6 based BGP service capability in the BGP OPEN message from its peer on that BGP session, the BGP speaker must not send on that session any UPDATE message that includes the SRv6 service TLVs” … since PE1 only supports MPLS … the MPLS-based service between PE1 and PE3 is unaffected)),
and advertising the service SID to the BGP peer without transposition based on the failing to receive the second capability advertisement of the second BGP peer’s transposition capability (page 6 lines 1-20 “if it has not received the SRv6 based BGP service capability in the BGP OPEN message from its peer on that BGP session, the BGP speaker must not send on that session any UPDATE message that includes the SRv6 service TLVs” … since PE1 only supports MPLS … the MPLS-based service between PE1 and PE3 is unaffected).
Regarding claim 5, 13 Liu teaches wherein the capability advertisement is per RFC 5492 (page 6 lines 4-10 “[RFC5492] defines the ‘Capabilities Optional Parameter’. A BGP speaker can include a Capabilities Optional Parameter in a BGP OPEN message”).
Regarding claim 6, 14, Liu teaches wherein the BGP peer’s transposition capability includes whether the BGP peer can process transposed Network Layer Reachability Information (NLRI) entries, can send the NLRIs entries using transposition, and a combination thereof (page 4 lines 1-12 “If the Transposition Scheme is used … part of SID-1 is encoded in the MPLS Label field of the NLRI”, page 2 lines 15-30 “the first method SRv6 SIDs are encoded as a whole … MPLS Label fileds of the corresponding NLRI is set to Implicit Null … the second method is referred to as the Transposition Scheme in [RFC9252], …is encoded in the MPLS Label filed of the NLRI”).
Regarding claim 8, 16, Liu teaches wherein the capability advertisement includes fields indicating any of (1) whether the BGP speaker can process transposed entries, (2) whether the BGP speaker can send transposed entries, and (3) a combination of both (page 5 lines 4-20 “[RFC9252] specifies that implementations MUST provides a mechanism to control advertisement of SRv6-based BGP service routes on a per neighbor and per service basis … If there’s no route reflector in the network, which neighbors can the SRv6 service routes to be advertised to should be specified when configuring SRv6 services on the PEs”, (Examiner’s Note: RFC9252 defines procedures and messages for SRv6-based services, for example transposition scheme on page 2).
Regarding claim 21, Liu teaches wherein the capability advertisement includes a capability value field comprising the Address Family Indicator (AFI), the Subsequent Address Family Indicator (SAFI) (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”),
and a send/receive field, and wherein the send/receive field indicates whether the BGP peer(page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”), (ii) can send NLRI entries using the transposition scheme, or (iii) both (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”).
Regarding claim 22, 24, Liu teaches wherein the capability advertisement includes a capability value field comprising the Address Family Indicator (AFI), the Subsequent Address Family Indicator (SAFI) (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”), and a send/receive field (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”).
Regarding claim 23, 25, Liu teaches wherein the send/receive field indicates whether the BGP peer (i) can process transposed Network Layer Reachability Information (NLRI) entries (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”), (ii) can send NLRI entries using the transposition scheme, or (iii) both (page 3 lines 15-23 “The SRv6 service SID and a MPLS VPN route labe for the service 1 are advertised in separate update messages … depending on whether the Transposition Scheme is used”, page 4 lines 1-10 “IF the Transposition Scheme is used, the function and/or argument part of SID-1 is encoded in the MPLS Label filed of the NLRI of the SRv6 -based service route”).
Claim(s) 7, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Liu in view of Zhuang further in view of Chen further in view of Nainar et al. (US 20180034727).
Regarding claim 7, 15, Liu teaches wherein the circuitry is further configured to receiving a second service SID from a second BGP peer with the second service SID having transposition capability and where the second BGP peer has not provided the capability advertisement of the BGP peer’s transposition capability to the BGP speaker (page 6 lines 1-20 “if it has not received the SRv6 based BGP service capability in the BGP OPEN message from its peer on that BGP session, the BGP speaker must not send on that session any UPDATE message that includes the SRv6 service TLVs”, (Examiner’s Note: drops messages no mention of error notification),
Liu, Zhuang, Chen does not teach and sending an error notification to the second BGP.
Nainar teaches and sending an error notification to the second BGP ([0030] “Embodiments of a communication system as described herein can resolve the aforementioned issues (and more) associated with enhanced error signaling and error handling in a network environment using segment routing. In communication system 100, when an error associated with a packet of a flow is detected at a node in a segment routing domain that receives the packet (e.g., nodes 150), an error message can be generated. In one example, an error message can be generated using ICMPv6. The packet associated with the detected error can be rewritten before imposing it in the error message”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the combination of Liu, Zhuang, Chen to incorporate the teachings of Nainar. One of ordinary skill in the art would have been motivated to make this modification in order to improve the error handling process that may occur in segment routing topologies such as, for example, IPv6 network environments with segment routing [0031].
Response to Arguments
Applicant's arguments filed 03/20/2026 have been fully considered but they are not persuasive.
Applicant’s Argument
Importantly, even in combination, Liu and Zhuang fail to teach or suggest the amended limitation requiring that the capability advertisement be carried in a Capabilities Optional
Parameter of a BGP OPEN message. The Examiner's reliance on Liu for RFC 5492 and Zhuang for a purported "field indicative" of capability does not remedy this deficiency, as Zhuang's cited disclosures relate to NLRI/TLV structures and not to BGP OPEN capability negotiation.
Examiner’s Response
Examiner respectfully disagrees. See update rejection. Newly added reference Chen is added.
Chen is relied upon to show and wherein the capability advertisement is carried in a Capabilities Optional Parameter of a BGP OPEN message ([0128] “Referring now to FIG. 4D, shown is an OPEN message 475 pursuant to RFC 4271 including the capability optional parameter 450 of FIG. 4C. In an embodiment, the controller 109A-D or the NE 110-111 includes the capability optional parameter 450 of FIG. 4C in the OPEN message 475 when the controller 109A-D or the NE 110-111 sending the OPEN message 475 is capable of implementing BGP for network HA (e.g., establishing enhanced BGP sessions 130-133, 203, and 206 and transmitting BGP messages 140 with extensions). The capability optional parameter 450 of FIG. 4C includes either the controllers capability triple 400 of FIG. 4A or the controllers capability triple 425 of FIG. 4B”).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH TRAN-DANH FOLLANSBEE whose telephone number is (571)272-3071. The examiner can normally be reached 10am -6 pm M-Th.
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, Derrick Ferris can be reached at 571-272-3123. 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.
/K.T.F./Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights