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 .
This is responsive to amendment filed on 10/20/25. Claims 1-20 are pending.
Response to Amendment
Claims 12 and 15 are amended. Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 5/1/26 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
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.
Claim(s) 1-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Flinck et al. (US 2014/0376371 A1), hereinafter “Flinck”, in view of Niu et al. (US 2021/0083972 A1), hereinafter “Niu”.
As to claim 1, Flinck disclose a method for a first router to utilize a Border Gateway Protocol (BGP) to dynamically request that a second router instantiate a service on the second router (Flinck, ¶ [0010]-[0012], fig. 1), the method comprising:
receiving, at the first router, input from a network operator that causes the service to be instantiated on the first router (service management via NMS/SMS/domain controller and local user requests; NMS issues service request…9. A suitable (e.g., optimal) edge node 113 (border BGP router) and the adjacent domain B 102 are selected; a request for an inter-domain service is conveyed to said edge node 113) (Flinck, ¶ [0003-0004, 0109-0120], fig. 1);
receiving, at the first router, a first BGP message from the second router that indicates one or more capabilities of the second router (once at least one service template has been advertised from at least one adjacent domain to the local domain, the following steps may be conducted (the numerals refer to the respective steps also shown in FIG. 2): [0120] 7. A local user at the domain A 101 may request an inter-domain TE-path, e.g., by using a client interface on a NMS 104 or a universal network interface (UNI) if an intra-domain control plane is present. The request may be directed to a Central Control Entity (CCE), e.g., an SMS, an NMS or a domain controller, which holds information about local topology with TE constraints, current reservations and available inter-domain services. The CCE may calculate multi constrained TE-paths or query a path from a PCE. [0121] 8. If according to the locally maintained information the inter-domain path request can be fulfilled (i.e. the service requested and the required resources are available), an intra-domain path is calculated and resources can be reserved. [0122] 9. A suitable (e.g., optimal) edge node 113 (border BGP router) and the adjacent domain B 102 are selected; a request for an inter-domain service is conveyed to said edge node 113. [0123] 10. A service request, e.g. for an inter-domain TE-path, is conveyed via a BGP UPDATE message from the edge node 113 to the edge node 111 of the domain B 102. This BGP UPDATE message may advertise a requestor in a Network Layer Reachability Information field and it may specify a path request in another attribute that indicates which previously advertised service this domain would like to use. [0124] 11. The edge node 111 (e.g., a BGP router at the edge of the domain B 102) receives the service request and forwards it to its local control entity, i.e. the domain controller 105, for further processing) (Flinck, ¶ [0109-0129], fig. 1);
determining that the service is not instantiated on the second router such that data associated with the service cannot be communicated with the second router (once at least one service template has been advertised from at least one adjacent domain to the local domain, the following steps may be conducted (the numerals refer to the respective steps also shown in FIG. 2): [0120] 7. A local user at the domain A 101 may request an inter-domain TE-path, e.g., by using a client interface on a NMS 104 or a universal network interface (UNI) if an intra-domain control plane is present. The request may be directed to a Central Control Entity (CCE), e.g., an SMS, an NMS or a domain controller, which holds information about local topology with TE constraints, current reservations and available inter-domain services. The CCE may calculate multi constrained TE-paths or query a path from a PCE. [0121] 8. If according to the locally maintained information the inter-domain path request can be fulfilled (i.e. the service requested and the required resources are available), an intra-domain path is calculated and resources can be reserved. [0122] 9. A suitable (e.g., optimal) edge node 113 (border BGP router) and the adjacent domain B 102 are selected; a request for an inter-domain service is conveyed to said edge node 113. [0123] 10. A service request, e.g. for an inter-domain TE-path, is conveyed via a BGP UPDATE message from the edge node 113 to the edge node 111 of the domain B 102. This BGP UPDATE message may advertise a requestor in a Network Layer Reachability Information field and it may specify a path request in another attribute that indicates which previously advertised service this domain would like to use. [0124] 11. The edge node 111 (e.g., a BGP router at the edge of the domain B 102) receives the service request and forwards it to its local control entity, i.e. the domain controller 105, for further processing) (Flinck, ¶ [0109-0129], fig. 1);
determining, based at least in part on the one or more capabilities, that the second router supports a capability for interpreting a service request to instantiate the service on the second router (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane) (Flinck, ¶ [0109-0129], 0140-0142, fig. 1);
receiving, at the first router, additional input from the network operator, the additional input indicating service parameters comprising: and a service identifier (ID) that indicates the service to the second router (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1);
generating, at the first router, a second BGP message that includes a service request indicating the service parameters usable by the second router to instantiate the service (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1);
sending, from the first router, the second BGP message to the second router (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1); receiving, at the first router and from the second router, an acknowledgement packet indicating that the service has been instantiated on the second router such that the second router is able to receive data associated with the service (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1); and
sending, from the first router, data traffic associated with the service via a path and to the second router to be provided to the user device (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1).
However, Flinck does not explicitly disclose the additional input indicating service parameters comprising: a router Internet Protocol (IP) address of the second router to which a user device is onboarded; a port Media Access Control (MAC) address of the second router to which the user device is connected.
In an analogous art, Niu discloses receiving, at the first router, additional input from the network operator, the additional input indicating service parameters comprising: a router Internet Protocol (IP) address of the second router to which a user device is onboarded (Service routing packet carries path ID, source SN ID, destination SN ID, Destination SN / SR IP address in underlay/IP header ) (Niu, ¶0063-0067, 0093-0096, fig. 1B, Table 2); a port Media Access Control (MAC) address of the second router to which the user device is connected (Underlay network header may use MAC addresses (Ethernet underlay)) (Niu, ¶0086, 0157).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed invention was made to implement’s Niu teachings into Flinck teaching of receiving, at the first router, additional input from the network operator, the additional input indicating service parameters comprising: a router Internet Protocol (IP) address of the second router to which a user device is onboarded; a port Media Access Control (MAC) address of the second router to which the user device is connected. This combination effectively provide a service routing packet processing method and apparatus, and a network system, which are used to implement support of an independent SN for service routing.
As to claim 2, Flinck-Niu discloses the method of claim 1, further comprising: receiving, at the first router, a service level agreement (SLA) parameter associated with the data traffic (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104.) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1); sending the SLA parameter to the second router via at least one of the second BGP message or a third BGP message (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, QoS parameters (bandwidth/delay/jitter/sanctions) in templates via BGP UPDATE , TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104.) (Flinck, ¶ [0006, 0109-0129], 0140-0148, fig. 1); receiving, at the first router, an indication that the SLA parameter associated with the data traffic was violated (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, QoS parameters (bandwidth/delay/jitter/sanctions) in templates via BGP UPDATE , TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104.) (Flinck, ¶ [0006, 0109-0129], 0140-0148, fig. 1); and providing the network operator with an alert that the SLA parameter was violated (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, QoS parameters (bandwidth/delay/jitter/sanctions) in templates via BGP UPDATE , TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104.) (Flinck, ¶ [0006, 0109-0129], 0140-0148, fig. 1).
As to claim 3, Flinck-Niu disclose the method of claim 1, wherein: the second BGP message includes a service request attribute that is a set of elements encoded as a Type-Length-Values (TLV); the service request attribute is a service-request TLV that includes an indication of at least one of: an Internet Protocol (IP) address of a second user device associated with a particular user of the service (Service routing packet carries path ID, source SN ID, destination SN ID, Destination SN / SR IP address in underlay/IP header ) (Niu, ¶0063-0067, 0093-0096, fig. 1B, Table 2); a Media Access Control (MAC) address of the second user device; a Virtual Local Area Network (VLAN) identifier (ID) to which the user device is connected; a destination router identifier; a destination port identifier; the port MAC address; or a source port MAC address to which the second user device is connected. The Examiner supplies the same rationale for the combination of references Flinck-Niu as in Claim 1 above.
As to claim 4, Flinck-Niu disclose the method of claim 1, wherein determining that the service has been instantiated on the second router includes receiving, from the second router, an acknowledgement message indicating that the service was instantiated on the second router (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1).
As to claim 5, The method of claim 1, wherein the service parameters are at
least one of: a template identifier (ID) that refers to a template defining specific configuration usable by the second router to instantiate the service (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1); a hash-key that indicates the template; an encrypted hash-key that indicates the template; or a catalog key that indicates the template.
As to claim 6, Flinck-Niu disclose the method of claim 1, further comprising sending, from the first router, at least one of: an indication of a lifetime for a connection established between the first router and the second router via at least one of the second BGP message or a third BGP message; or an indication of at least one of a latency, jitter, or bandwidth allocation for the connection established between the first router and the second router via at least one of the second BGP message or the third BGP message (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1).
As to claim 7, Flinck-Niu disclose the method of claim 1, wherein the service request included in the second BGP message sent to the second router includes an indication of an underlay transport protocol for the second router to use to communicate the data traffic with the first router (the BGP UPDATE message can be extended with an optional and non-transitive attribute called "eBGP service" so that it can carry service templates, TE-path request templates and/or request accept or request reject templates from adjacent domains. These templates may carry detailed information regarding the service offered, requested, or accepted/rejected via a specific BGP router on its border (also referred to as edge node). Elements such as a destination information, a price information, and/or one or more QoS attributes such as bandwidth, delay and/or delay jitter can be included in the template. An intra-domain path is signaled and set up within the domain B 102. [0138] 23. The edge node 111 conveys an accept message via a BGP UPDATE message toward the edge node 113 of the domain A 101. [0139] 24. The edge node 113 forwards the message received from the edge node 111 towards the NMS 104. [0140] 25. The NMS 104 sets up the intra-domain path across the domain A 101 by applying the path to the nodes of the data plane; a service requesting phase 502, the domain A 101 conveys a service request (template) via the domain B 102 to the domain C 103. The service request template can be embedded in a (modified) BGP UPDATE message. In a service utilization or service handling phase 504, the service requested could be accepted providing an accept message (template) from the domain C 103 via the domain B 102 to the domain A 101. This accept template can be conveyed via a (modified) BGP UPDATE message. Accepting the service offered is summarized in FIG. 5 as a service acceptance phase 503) (Flinck, ¶ [0109-0129], 0140-0148, fig. 1).
Claims 8-14 list all the same elements of claims 1-7, but in A head-end router comprising: one or more processors (Flinck, ¶ [0109-0129], 0140-0148, fig. 1); and one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (Flinck, ¶ [0109-0129], 0140-0148, fig. 1) to carry out method steps of the device form. Therefore, the supporting rationale of the rejection to claims 1-7 applies equally as well to claims 8-14.
Claims 15-20 list all the same elements of claims 1-4, 6-7, but in a method for a tail-end router to instantiate a service using service parameters provided from a head-end router (Flinck, ¶ [0109-0129], 0140-0148, fig. 1) to carry out method steps of. Therefore, the supporting rationale of the rejection to claims 1-7 applies equally as well to claims 15-20.
Response to Arguments
Response to 103 rejections applicant’s amendments to the claim change the scope. Therefore, amended claims necessitated new ground(s) of rejections presented in this office action in view of Niu et al. (US 2021/0083972 A1), have been introduced to address amended. Applicant’s arguments have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Satterlee et al. (US 2010/0098072 A1) disclose a method of routing data in an anycast environment includes sending an instruction from an intelligent route reflector device to an anycast router associated with an anycast network. The instruction signals the anycast router to statically pin up to an initial service node corresponding to a network service. The initial service node is associated with an anycast address. The method includes identifying prefixes of Internet protocol (IP) addresses of customer endpoints that communicate with the anycast network via the anycast router, and sending a route advertisement to a service node router associated with the initial service node. The route advertisement instructs the service node router to send an advertisement to the anycast network announcing that the service node router is a next best hop for data traffic related to the network service and bound for a customer endpoint having an IP address that includes any of the identified prefixes.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HITESH R PATEL whose telephone number is (571)270-5442. The examiner can normally be reached Monday-Friday 7am-3pm.
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, James Trammell can be reached at 571-272-6712. 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.
/Hitesh Patel/Supervisory Patent Examiner, Art Unit 3667
7/28/26
Prosecution Insights