DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is in response to claim amendments and remarks filed by Applicant’s representative on June 16, 2026. Claims 21-40 are pending, claims 1-20 have been canceled, and no new claims have been added.
Response to Amendments and Remarks
Applicant’s latest filed claim amendments and corresponding remarks dated June 16, 2026 have been received and fully considered. Applicant’s remarks and/or comments are generally directed to the current claim amendment(s), and accordingly deemed moot in light of the new grounds of rejection provided with this action.
With regards to Applicant’s latest amendments and remarks, Applicant firstly notes and remarks that the independent claim(s), and particularly independent claim 21, has been further amended to now expressly recite
“A network device, comprising: one or more memories storing instructions; and one or more processors coupled to the one or more memories and configured to execute the instructions, wherein execution of the instructions causes the network device to:
receive an advertisement message sent by a second network device, wherein the advertisement message comprises segment routing (SR) policy information and traffic feature information, and the SR policy information comprises a segment identifier (SID) list; and
establish a correspondence between the traffic feature information and the SID list according to the advertisement message, wherein the correspondence is used to guide forwarding of a packet comprising the traffic feature information,
wherein the traffic feature information comprises one or more of a destination address, a source address, an internet protocol (IP) protocol number, a destination port number, a source port number, a packet length, an internet control message protocol (ICMP) type, an ICMP code, a transmission control protocol (TCP) flag, a differentiated services code point (DSCP) identifier, and an IP segmentation type”.
With respect to the above, Applicant notes and remarks that none of the prior art reference(s) applied in rejecting independent claim 1 [Bhargava et al], either individually or in combination with other prior art, expressly and properly discloses or suggests the above amended claim feature(s) or limitation(s) of wherein the traffic feature information comprises one or more of a destination address, a source address, an internet protocol (IP) protocol number, a destination port number, a source port number, a packet length, an internet control message protocol (ICMP) type, an ICMP code, a transmission control protocol (TCP) flag, a differentiated services code point (DSCP) identifier, and an IP segmentation type -- as currently recited by amended independent claim 1 above (and similarly in independent claims 31 and 32).
In particular, and in support of his position, Applicant states or remarks that the information that Bhargava advertises is a BSID to SR policy mapping – namely, an SR policy expressed as a < source, color, destination/endpoint > tuple together with an associated Binding SID, but none of these advertised items are any of the items recited as the ‘traffic feature’ information. Bhargava does not disclose advertising a destination address, a source address, an IP protocol number, a destination or source port number, a packet length, an ICMP type, and ICMP code, a TCP flag, a DSCP identifier, or an IP segmentation type – and accordingly does not disclose the recited traffic feature information [Applicant Remarks: par 1, pg. 9 – par 2, pg. 10]. Accordingly, Applicant remarks that the independent claims are distinguishable from the applied prior art and/or prior art combination(s) used to reject the claims, and that the respective dependent claims are also distinguishable by virtue of their dependency on their respective parent independent claims.
However, the Office asserts and notes that the noted feature(s) of the amended independent claims are now expressly taught or disclosed in further view of teachings and/or disclosures by at least Marques et al, as discussed / cited below in a new ground of rejection with this action.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103(a) 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) 21-22, 28-33, 39-40 is/are rejected under 35 U.S.C. 103 as being disclosed by Bhargava et al (hereinafter Bhargava), US Patent Publication 20230269167 A1 (publication date February 2022) in view of Marques et al (hereinafter Marques), Non-Patent Literature Publication titled “Dissemination of Flow Specification Rules” (publication date August 2009).
As per claim{s} 21, 31, 32, Bhargava discloses substantial features of the claimed invention, such as a network device (Bhargava: e.g., Computer System 20 {i.e., a ‘Border node’ such as Node D, and/or a ‘Head-End node’ such as Node A) [0089; Figs. 1 & 2], comprising:
one or more memories storing instructions (Bhargava: e.g., Memory Device_24) [0077-0078; Fig. 2]; and one or more processors (Bhargava: e.g., Processing Device_22) [0077-0078; Fig. 2] coupled to the one or more memories and configured to execute the instructions [(e.g., Processing device 22 may also include or utilize stored program ‘instructions’ (e.g., stored in hardware, software, and/or firmware) for control of the Computing system 20 executing the program instructions) [0077-0078; Fig. 2], wherein execution of the instructions causes the network device to:
receive an advertisement message (Bhargava: e.g., SR Policy ‘advertisement’) [0033] sent by a second network device (Bhargava: e.g. expressly teaches in one aspect that a ‘border node’ may ‘advertise SR policy’ including ‘color’ specification / information, for example) [0033] (e.g., Computing system 20, which may represent ‘one or more of the nodes’ {i.e., Nodes A, D, etc.) in the distributed system 10 may be configured for “obtaining, receiving, creating, or generating new SR policies” {i.e., ‘hierarchical SR policies’}, which may include stitching a remote portion of the SR policy to an end thereof. The status of ‘paths’ affecting remote ‘SR policies’ in downstream domains may be ‘advertised’ by the ‘Border Nodes’ to ‘other Nodes’ in the local (upstream) domain. The Border nodes may ‘advertise’ the ‘BSID and SR policies’ within the local SR domain or within any suitable area defined by IGP (accordingly, the Office notes that Bhargava teaches / discloses wherein border Node D, for example, may both ‘receive an SR policy advertisement’ from a source and/or ‘advertise’ the SR policy message to ‘other Nodes’ of the network)) [0077-0078; 0093; Fig. 2], wherein the advertisement message comprises segment routing (SR) policy information and traffic feature information, and the SR policy information comprises a segment identifier (SID) list (Bhargava: e.g., method steps can include using the SR Policy to forward packets/traffic to the destination using the binding SID. The SR policy and the BSID can be obtained via one of the Interior Gateway Protocol (IGP) and the Border Gateway Protocol (BGP)) [0012] (e.g., ‘Segment Routing (SR)’ is one of many types of routing techniques that may be used for transmitting packets from a source node to a destination node in a communications network. In SR, a packet may include an SR policy having a number of “segments” that define forwarding instructions. Thus, a ‘list (or stack) of segments’ in the SR policy can be created or initiated by a Head-end node (e.g., the Source Node) for defining at least portions of the path from the source node to the destination node. Each of the ‘segments’ of the SR policy can be ‘identified’ or represented by a unique ‘Segment Identifier (SID)’. One type of SID is a Binding SID (BSID), which is configured to steer the packet to another associated SR policy) [0002]; and
establish a correspondence between the traffic feature information and the SID list according to the advertisement message, wherein the correspondence is used to guide forwarding of a packet comprising the traffic feature information (Bhargava: e.g., method steps can include using the SR Policy to forward packets/traffic to the destination using the binding SID. The SR policy and the BSID {advertisement} can be obtained {received} via one of the Interior Gateway Protocol (IGP) and the Border Gateway Protocol (BGP)) [0012] (e.g., According to the embodiments of the present disclosure, when ‘BSID to SR policy mapping’ {traffic feature information} is ‘advertised’ in IGP, this mapping can be stored in the SR-TED each local node in the local domain and used during the SR policy explicit path verification. In some embodiments, for example, SR policy information for the remote portion of the SR policy (locally initiated) may include a “source” field, a “color” field, and a “destination” field (or end-point field) {traffic feature information}, which may be incorporated as new features in the SR protocols. A Network operator may use the techniques described with respect to the present embodiments to ‘route’ a SR policy using its “<source, color, end-point> “(i.e., where “end-point” may represent the destination). This can be done while configuring an ‘explicit path’ that includes the SR policy) [0064; 0093] (e.g., explicitly discloses that part of the ‘advertising’ or signaling functionality includes describing how BSID “T” {traffic feature information} is ‘associated with the SR policy’. The BSID may include the end (remote) portion of the SR policy and may specifically include the ‘color’ and ‘destination fields’, as defined by the various embodiments in the present disclosure. For example, Node D may signal that ‘T’ is ‘mapped’ {corresponds} to ‘SR policy’ with ‘color <10>’ and ‘destination <node L>’, and when BSID ‘T’ is' provisioned {allocated}, it is going to be ‘advertised’…. When a ‘packet’ arrives at Node D with BSID ‘T’ {value}, Node D is configured to ‘look up’ this BSID in its database, which may be configured to store multiple BSIDs for ‘routing’ packets to any downstream nodes along any suitable ‘path’ {correspondence of traffic feature information to SID list according to the advertisement message}….The ‘color’ can have any range of values that represents a label. Node A too can look into its database and find ‘T’ {correspondence of traffic information to SID list according to the advertisement message}. With the knowledge of the existence of ‘Node D’ (as the source of the remote portion) and that BSID ‘T’ is configured to pass packets from ‘Node D to Node L’ along a ‘path’ defined by the “color” field, a Network operator (using Node A) can utilize the ‘available SR policies’ regarding remote paths and stitch these remote BSIDs to the ‘hierarchical SR policy’ to reach a certain ‘destination’ (e.g., Node L) ) [0098-0099].
But while Bhargava discloses substantial features of the invention as above, he does not explicitly disclose the additional recited feature(s) of the network device wherein the traffic feature information comprises one or more of a destination address, a source address, an internet protocol (IP) protocol number, a destination port number, a source port number, a packet length, an internet control message protocol (ICMP) type, an ICMP code, a transmission control protocol (TCP) flag, a differentiated services code point (DSCP) identifier, and an IP segmentation type.
However, in a related endeavor, Marques particularly discloses the additional feature(s) of the network device wherein the traffic feature information comprises one or more of a destination address, a source address, an internet protocol (IP) protocol number, a destination port number, a source port number, a packet length, an internet control message protocol (ICMP) type, an ICMP code, a transmission control protocol (TCP) flag, a differentiated services code point (DSCP) identifier, and an IP segmentation type (Marques: e.g., ‘Flow Specification’ NLRI type may include several traffic ‘components’ or optional ‘subcomponents’ / attributes for traffic routing or propagation, and may includes at least one of: ‘Type 1 [Wingdings font/0xE0] Destination Prefix’, ‘Type 2 [Wingdings font/0xE0] Source Prefix’, ‘Type 3 [Wingdings font/0xE0] IP Protocol’ value, ‘Type 4 [Wingdings font/0xE0] Port’, ‘Type 5 [Wingdings font/0xE0] Destination Port’, ‘Type 6 [Wingdings font/0xE0] Source Port’, ‘Type 7 [Wingdings font/0xE0] ICMP Type’, ‘Type 8 [Wingdings font/0xE0] ICMP Code’, ‘Type 9 [Wingdings font/0xE0] TCP Flags’, ‘Type 10 [Wingdings font/0xE0] Packet Length’, ‘Type 11 [Wingdings font/0xE0] DSCP Code, etc.) [Section 4. Dissemination of Information: pg. 6, par 2 – pg. 11, par 1].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify Bhargava’s invention with the above said additional feature(s), as expressly disclosed by Marques, for the motivation of providing methods and systems for dissemination of network traffic flow specification rules, using BGP Network Layer Reachability Information {BGP NLRI} information that can be used to distribute traffic flow specifications, and which allows the routing system to propagate information regarding specific ‘traffic components’ {traffic features} for traffic filtering and/or routing [Marques: Abstract, 0002-0003; pg. 1, par 1].
Claim(s) 31 recite(s) substantially the same limitations / features as claim 21, but from the perspective of the ‘second network device’ {source node of the ‘advertisement’ message}, which is nonetheless also expressly disclosed by Bhargava (above), and the claim is accordingly rejected on the same basis.
Claim(s) 32 recite(s) substantially the same limitations / features as the combination of claim(s) 21 and 31, and disclosed previously above (Bhargava: e.g., ‘Computer System’_20 {i.e., comprising a ‘Border node’ such as Node D, and/or a ‘Head-End node’ such as Node A) [0089; Figs. 1 & 2]. The claim is also distinguishable by its statutory category (system), and accordingly rejected on the same basis.
As per claim{s} 22, 33, Bhargava discloses the network device wherein executing the instructions further causes the network device to generate a routing entry according to the advertisement message, wherein the routing entry comprises the correspondence between the traffic feature information and the SID list (Bhargava: e.g., the method comprises steps that include ‘obtaining {receiving by a Network element [NE] / Node} a Segment Routing (SR) policy’ for routing a packet along a ‘path’ in a downstream domain, the SR policy including at least a ‘destination field’ and a ‘color field’, the destination field defining an end-point of the path in the downstream domain, the end-point representing a destination node or service instance, the color field defining the path in the downstream domain that provides certain characteristics such as QoS, reliability, security, etc., and “storing {by the Network element [NE] / Node } the SR policy in the database” {generating a routing entry}) [0011] (e.g., According to the embodiments of the present disclosure, when ‘BSID to SR policy mapping’ is ‘advertised’ in IGP, this ‘mapping’ can be ‘stored in the SR-TE Database [ST-TED] by each local node in the local domain and used during the SR policy explicit path verification….) [0064].
As per claim{s} 28, 39, Bhargava discloses the network device wherein executing the instructions further causes the network device to wherein the routing entry is an SR policy routing entry (Bhargava: e.g., the method comprises steps that include ‘obtaining {receiving by a Network element [NE] / Node} a Segment Routing (SR) policy’ for routing a packet along a ‘path’ in a downstream domain, the SR policy including at least a ‘destination field’ and a ‘color field’, the destination field defining an end-point of the path in the downstream domain, the end-point representing a destination node or service instance, the color field defining the path in the downstream domain that provides certain characteristics such as QoS, reliability, security, etc., and “storing {by the Network element [NE] / Node } the SR policy in the database” {generating a routing entry}) [0011] (e.g., According to the embodiments of the present disclosure, when ‘BSID to SR policy mapping’ is ‘advertised’ in IGP, this ‘mapping’ can be ‘stored in the SR-TE Database [ST-TED] by each local node in the local domain and used during the SR policy explicit path verification….) [0064].
As per claim{s} 29, 40, Bhargava discloses the network device wherein executing the instructions further causes the network device to wherein the advertisement message is an SR policy message (Bhargava: e.g., the method comprises steps that include ‘obtaining {receiving by a Network element [NE] / Node} a Segment Routing (SR) policy’ for routing a packet along a ‘path’ in a downstream domain, the SR policy including at least a ‘destination field’ and a ‘color field’, the destination field defining an end-point of the path in the downstream domain, the end-point representing a destination node or service instance, the color field defining the path in the downstream domain that provides certain characteristics such as QoS, reliability, security, etc., and “storing {by the Network element [NE] / Node } the SR policy in the database” {generating a routing entry}) [0011] (e.g., According to the embodiments of the present disclosure, when ‘BSID to SR policy mapping’ is ‘advertised’ in IGP, this ‘mapping’ can be ‘stored in the SR-TE Database [ST-TED] by each local node in the local domain and used during the SR policy explicit path verification….) [0064].
As per claim{s} 30, Bhargava in view of Wu discloses the network device wherein the advertisement message comprises a second path attribute field, and the second path attribute field carries the traffic feature information (Bhargava: e.g., explicitly discloses that part of the ‘advertising’ or signaling functionality includes describing how BSID “T” is ‘associated with the SR policy’. The BSID may include the end (remote) portion of the SR policy and may specifically include the ‘Color’ and ‘Destination fields’ {first / second path attribute field(s)}, as defined by the various embodiments in the present disclosure. For example, Node D may signal that ‘T’ is ‘mapped’ {corresponds} to ‘SR policy’ with ‘color <10>’ and ‘destination <node L>’, and when BSID ‘T’ is' provisioned {allocated}, it is going to be ‘advertised’…. When a ‘packet’ arrives at Node D with BSID ‘T’ {value}, Node D is configured to ‘look up’ this BSID in its database, which may be configured to store multiple BSIDs for ‘routing’ packets to any downstream nodes along any suitable ‘path’ {correspondence of traffic feature information to SID list according to the advertisement message}….The ‘color’ can have any range of values that represents a label. Node A too can look into its database and find ‘T’ {correspondence of traffic information to SID list according to the advertisement message}. With the knowledge of the existence of ‘Node D’ (as the source of the remote portion) and that BSID ‘T’ is configured to pass packets from ‘Node D to Node L’ along a ‘path’ defined by the “color” field, a Network operator (using Node A) can utilize the ‘available SR policies’ regarding remote paths and stitch these remote BSIDs to the ‘hierarchical SR policy’ to reach a certain ‘destination’ (e.g., Node L) ) [0098-0099].
Claim(s) 23-27, 34-38 is/are rejected under 35 U.S.C. 103 as being disclosed by Bhargava in view of Marques and in further view of Wu et al (hereinafter Wu), EURO Patent Publication (EP) 4311311 A1 (publication date May 2022).
As per claim{s} 23, 34, the combination of Bhargava in view of Marques discloses substantial features of the invention as above, but does not explicitly disclose the additional feature(s) of the network device wherein the routing entry is a flow specification (Flowspec) routing entry.
However, in a related endeavor, Wu particularly discloses the additional feature(s) of the network device wherein the routing entry is a flow specification (Flowspec) routing entry (Wu: e.g., It should be noted that the ‘matching’ condition information may be existing / defined in a ‘flow specification’ component type information, where the ‘flow specification’ component type information may be understood as ‘matching of traffic’ based on a “source address/destination address/Differentiated Services Code Point (DSCP)” of a data packet ) [0033] (e.g., A BGP Flowspc client may receive ‘Flowspc’ routing information carrying the extended community attribute information, and then save contents of a flow filtering rule in the Flowspc routing information. The BGP Flowspc client searches for a {Flowspc} ‘forwarding entry’ in local mapping information according to the slice identifier/application identifier (for scenarios where no path is specified), which may be realized through an existing redirection to a next hop action. Alternatively, the BGP Flowspc client can directly find the corresponding ‘forwarding entry’ for forwarding according to a path in the ‘slice identifier/application identifier’ ) [0037].
It would thus be obvious to one of ordinary skill in the art before the effective date of the invention to modify the combination with the above said additional feature(s), as expressly disclosed by Wu, for the motivation of providing methods and systems for traffic message forwarding, which provides for traffic path adjustment and optimization in routing of traffic in accordance with traffic forwarding policy / policies [Wu: Abstract, 0002-0003; Figs.1-2 & 8-11].
As per claim{s} 24, 35, Bhargava in view of Marques in view of Wu, and Wu in particular, discloses the network device wherein the advertisement message is a border gateway protocol flow specification message (BGP Flowspec message) (Wu: e.g., a BGP Flowspc client may receive ‘Flowspc’ routing information carrying the extended community attribute information, and then save contents of a flow filtering rule in the Flowspc routing information. The BGP Flowspc client searches for a {Flowspc} ‘forwarding entry’ in local mapping information according to the slice identifier/application identifier (for scenarios where no path is specified), which may be realized through an existing redirection to a next hop action. Alternatively, the BGP Flowspc client can directly find the corresponding ‘forwarding entry’ for forwarding according to a path in the ‘slice identifier/application identifier’ ) [0037] (e.g., At S1710, the Controller delivers / sends ‘BGP Flowspc’ routing information {routing / advertisement message} carrying an application identifier filtering rule to a Head node.) [0101; Fig. 17].
As per claim{s} 25, 36, Bhargava in view of Marques in view of Wu discloses the network device wherein the advertisement message comprises a first path attribute field, and the first path attribute field carries the SR policy information (Bhargava: e.g., explicitly discloses that part of the ‘advertising’ or signaling functionality includes describing how BSID “T” {first path attribute / traffic feature } is ‘associated with the SR policy’. The ‘BSID’ may include the end {remote} portion of the SR policy and may specifically include the ‘color’ and ‘destination fields’ {first / second path attribute field(s)}, as defined by the various embodiments in the present disclosure. For example, Node D may signal that ‘T’ is ‘mapped’ {corresponds} to ‘SR policy’ with ‘color <10>’ and ‘destination <node L>’, and when BSID ‘T’ is' provisioned {allocated}, it is going to be ‘advertised’…. When a ‘packet’ arrives at Node D with BSID ‘T’ {value}, Node D is configured to ‘look up’ this BSID in its database, which may be configured to store multiple BSIDs for ‘routing’ packets to any downstream nodes along any suitable ‘path’ {correspondence of traffic feature information to SID list according to the advertisement message}….The ‘color’ can have any range of values that represents a label. Node A too can look into its database and find ‘T’ {correspondence of traffic information to SID list according to the advertisement message}. With the knowledge of the existence of ‘Node D’ (as the source of the remote portion) and that BSID ‘T’ is configured to pass packets from ‘Node D to Node L’ along a ‘path’ defined by the “color” field, a Network operator (using Node A) can utilize the ‘available SR policies’ regarding remote paths and stitch these remote BSIDs to the ‘hierarchical SR policy’ to reach a certain ‘destination’ (e.g., Node L) ) [0098-0099].
As per claim{s} 26, 37, Bhargava in view of Marques in view of Wu, and Wu in particular, discloses the network device wherein the advertisement message comprises one or more extended community attributes, and each extended community attribute carries a SID in the SID list comprised in the SR policy information (Wu: e.g., it should be noted that redirected ‘Extended Community Attribute’ information may be redirected to a universal ‘Slice identifier’ or application identifier or a ‘path’ in the universal slice identifier / application identifier, for example, a Segment Routing Policy (SR-Policy), a Segmental Routing-Traffic Engineering (SR-TE) tunnel, or a Segment Routing Transport ‘Profile’-Traffic Engineering (SR-TP) tunnel ) [0035].
As per claim{s} 27, 38, Bhargava in view of Marques in view of Wu, and Wu in particular, discloses the network device wherein the one or more extended community attributes each further comprise a ranking identifier corresponding to the carried SID, and each ranking identifier indicates a ranking of its corresponding carried SID in the SID list (Wu: e.g., it should be noted that redirected ‘Extended Community Attribute’ information may be redirected to a universal ‘Slice identifier’ or application identifier or a ‘path’ in the universal slice identifier / application identifier, for example, a Segment Routing Policy (SR-Policy), a Segmental Routing-Traffic Engineering (SR-TE) tunnel, or a Segment Routing Transport ‘Profile’-Traffic Engineering (SR-TP) tunnel ) [0035] (e.g., expressly discloses / illustrates with respect to Table 1 the ‘correspondence’ / mapping between traffic ‘filtering’ rule / matching condition { ‘Slice identifier’ [Wingdings font/0xE0] Slice 1, Slice 2..etc. } and the respective ‘forwarding entry’ {BSID 1, BSID 2…etc.}, where Slice 1 is ordered {ranked} above Slice 2) [0084-0090; Fig. 14].
Conclusion
Applicant’s amendment(s) necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP 706.06(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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GLENFORD J MADAMBA whose telephone number is (571)272-7989. The examiner can normally be reached on Mondays to Fridays, 9am-5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached on 571-272-8328. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
/GLENFORD J MADAMBA/Primary Examiner, Art Unit 2451
Prosecution Insights