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 .
Information Disclosure Statement
The IDS filed 5/21/2025 has been considered.
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.
Claim(s) 1-8, 10, 12-17, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils et al. (US 10764175, as cited in the IDS filed 5/21/2025, hereinafter referred to as “Filsfils 1”) in view of Filsfils et al., (US 20200351199, hereinafter referred to as "Filsfils 2").
Regarding claim 1, Filsfils 1 teaches a method implemented by a network node (abstract – router node) in a current network domain (figure 2B: SR domain 280), the method comprising:
obtaining a packet in an internet protocol (IP) version six (IPv6) format (col 4, lines 62-64: an SR header may be inserted in an IPv6 packet at a source node or at an ingress node, or even encapsulated at the ingress node);
determining a next domain ID from the domain ID list field (col. 5, lines 3-4: An SR header may be inserted in an IPv6 packet at a source node or at an ingress node, or even encapsulated at the ingress node);
determining a next domain interface IP address based on the next domain ID (col. 5, lines 7-18: When SR-IPv6 packet 290b is communicated to the ingress node (i.e. node 212 or B), the DA is modified by the ingress node to include the next or second node in the SL (i.e. node D), as indicated in SR-IPv6 packet 292b. When SR-IPv6 packet 292b is communicated to the node D (via node C), the DA is modified by node D to include the next or third node in the SL (i.e. node G), as indicated in SR-IPv6 packet 294b. When SR-IPv6 packet 294b is further communicated to the node G (via node F), the DA is modified by node G to include the next or fourth node in the SL (i.e. node Z which is the destination node), as indicated in SR-IPv6 packet 296b.);
copying the next domain address into the destination address field (col. 15, lines 6-20: the making of the copy having the network resource identifiers may be performed as part of a forwarding and punting a copy of the message (i.e. punt a copy of the received packet after forwarding it). In SRv6 Network Programming (draft-filsfils-spring-srv6-network-programming-04) described earlier above, an SRH.Flags.O-bit is defined to instruct a “forward and punt a copy of the packet” behavior (i.e. punt the copy of the received packet after forwarding it). A “forward and punt a copy of the packet” processes a packet without head-of-line blocking in switching the packet, and hence is efficient and hardware-friendly. The router node that may implement the forward and punt behavior is assumed to punt the entire packet, including an internal header of the packet.); and
forwarding the packet toward the next domain (col. 5, line 57 to col. 6, line 4: each router node of the first network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the first path determination criteria (and e.g. mostly limit its entries to such determined paths). On the other hand, each router node of the second network slice may be configured to establish routes based on second path determination criteria associated with a second identifier (step 306b of FIG. 3). More specifically, each router node of the second network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the second path determination criteria (and e.g. mostly limit its entries to such determined paths). Such path determination criteria may be provisioned at the router nodes by a controller).
However, Filsfils 1 does not explicitly teach determining a next domain interface IP address, copying the next domain interface IP address into the base IPv6 destination address field, and forwarding the packet toward the next domain interface IP address in the base IPv6 destination address field.
In an analogous art, Filsfils 2 teaches determining a next domain interface IP address, copying the next domain interface IP address into the base IPv6 destination address field, and forwarding the packet toward the next domain interface IP address in the base IPv6 destination address field (abstract - receiving a packet comprising a destination address in a destination address field of the packet, where the destination address including at least a first global identifier and a second global identifier, determining that the first global identifier corresponds to the first network apparatus, determining that a local identifier in the destination address is associated with the first global identifier, identifying one or more instructions associated with the local identifier, performing one or more functions instructed by the one or more instructions, updating the destination address in the destination field of the packet to an updated destination address, determining a forwarding rule associated with the packet, and forwarding the packet with the updated destination address based on the forwarding rule.).
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the teaching of Filsfils 2 into the teaching of Filsfils 1 in order to enable inter-domain routing, thus simplifying routing enforcement across different domains.
Regarding claim 2, Filsfils 1 teaches the method of claim 1, wherein the header further comprises a domains left field containing a pointer to the next domain ID in the domain ID list field, and wherein the method further comprises decrementing the pointer upon determining the next domain ID (col. 7, lines 35-44: Given the above scheme, (i) Router node 9 may advertise Prefix SID B:0:9:1:: for ALGO 0, Prefix SID B:128:9:1:: for ALGO 128, and Prefix SID B:129:9:1:: for ALGO 129 (ii) Router node 3 may advertise Prefix SID B:0:3:1:: for Algo 0, and Prefix SID B:128:3:1:: for ALGO 128.-SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with an IPv6 header with source address SA, destination addresses DA, and next header which is an SRH. SRH (S3, S2, S1; SL) is an SRH with SID list <S1, S2, S3> with SegmentsLeft=SL).
Regarding claim 3, Filsfils 1 teaches the method of claim 1, wherein the header further comprises a routing type field set to indicate domain level source routing is used for the packet (figure 2: SR header identifies segment routing type).
Regarding claim 4, Filsfils 1 teaches the method of claim 1, wherein the header further comprises a first domain field containing a pointer to a first domain ID in the domain ID list field (col. 8, lines 10-17: Beginning at a start block 502 of FIG. 5A, the router node may perform a validation procedure with respect to a forwarding table entry in its forwarding table (step 504 of FIG. 5A). Here, in general, the router node may forward a probe message towards a target downstream router node according to the forwarding table entry (step 506 of FIG. 5A). The probe message may include the first identifier associated with the router node in the first network slice. Note: the entry defines position withing segment).
Regarding claim 5, Filsfils 1 teaches the method of claim 1, wherein the domain ID list field contains a list of domain IDs for each domain along a path between a source of the packet and a destination of the packet (col. 4, lines 34-37: SR header 270 may include an ordered list of segments 272 which defines a network path 250 along which the SR-IPv6 packet 260 will be communicated in network 200a.).
Regarding claim 6, Filsfils 1 teaches the method of claim 1, wherein the header further comprises an original destination address field containing an address of a destination of the packet (col. 4, lines 27-50: A basic data format of an SR-IPv6 packet 260 for use in SRv6 routing is also shown in FIG. 2A. As illustrated, the data format of SR-IPv6 packet 260 includes an IPv6 header 262 and a payload 264. For SRv6 routing of IPv6 packet 260, the data format of IPv6 packet 260 further includes an SR header 270 or “SRH” (i.e. an extension header for SR as defined by RFC 2460). SR header 270 may include an ordered list of segments 272 which defines a network path 250 along which the SR-IPv6 packet 260 will be communicated in network 200a. In the example of FIG. 2A, the ordered list of segments 272 includes node 214 (“node C”), node 220 (“node F”), and node 224 (“node H”) in network path 250. A segment is or includes an instruction (e.g. forwarding, servicing, application-specific, etc.) to be applied to the SR-IPv6 packet 260. Thus, an SR-IPv6 packet (e.g. SR-IPv6 packet 260) may be communicated in network 200a from a source node (e.g. node 210 or A) to a destination node (e.g. a node 226 or Z) along a desired or predetermined network path 250. The source node (e.g. node 210 or A) may operate to choose this network path 250 and encode it in the SR header 270 as the ordered list of segments 272. The rest of network 200a may operate to execute the encoded instructions without any further per-flow state.).
Regarding claim 7, Filsfils 1 teaches the method of claim 1, wherein a value of the base IPv6 destination address field is changed at each domain along a path between a source of the packet and a destination of the packet (col. 10, lines 34-47: The loopback probe message 610 may include a source address directed to a target downstream router node 3 and a destination address directed to a loopback interface of router node 1. In response, router node 1 may receive via the loopback interface the loopback probe message 612 which is looped back from the upstream router node 0. This received loopback probe message 612 may include a destination address directed to the target downstream router node 3. Router node 1 may (attempt to) forward the received loopback probe message 614 towards the target downstream router node 3 according to its forwarding table entry. The forwarded probe message 614 may include the first identifier associated with router node 1 in the first network slice.).
Regarding claim 8, Filsfils 1 teaches the method of claim 7, wherein a value of an original destination address field is not changed along the path between the source of the packet and the destination of the packet (in SRv6, final destination semantics are preserved, therefore this is implicitly taught).
Regarding claim 10, Filsfils 1 teaches the method of claim 1, wherein the network node includes a domain entry table, wherein the domain entry table includes entries correlating domain IDs of domains to interface addresses of the domains, and wherein the next domain ID is used to determine the next domain interface IP address in the domain entry table (col. 6, lines 39-62: FIG. 4 is an example illustrative representation of a plurality of interconnected router nodes 400 of the mobile network to better illustrate the context as described in relation to FIG. 3. A first plurality of router nodes 1, 2, 3, and 4 are allocated to a first network slice, and a second plurality of router nodes 5, 6, 7, and 8 are allocated to a second network slice. Each router node 1, 2, 3 4 of the first network slice may being configured to establish routes based on first path determination criteria associated with a first identifier. More specifically, each router node 1, 2, 3, and 4 of the first network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the first path determination criteria (and e.g. mostly limit its entries to such determined paths). On the other hand, each router node 5, 6, 7, and 8 of the second network slice may be configured to establish routes based on second path determination criteria associated with a second identifier. More specifically, each router node 5, 6, 7, and 8 of the second network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the second path determination criteria (and e.g. mostly limit its entries to such determined paths). Such path determination criteria may be provisioned at the router nodes by a controller.).
Regarding claim 12, Filsfils 1 teaches the method of claim 1, further comprising: querying a controller to obtain a list of domain IDs for each domain along a path between a source of the packet and a destination of the packet; and including the list of domain IDs in the domain ID list field (col. 6, lines 39-62: FIG. 4 is an example illustrative representation of a plurality of interconnected router nodes 400 of the mobile network to better illustrate the context as described in relation to FIG. 3. A first plurality of router nodes 1, 2, 3, and 4 are allocated to a first network slice, and a second plurality of router nodes 5, 6, 7, and 8 are allocated to a second network slice. Each router node 1, 2, 3 4 of the first network slice may being configured to establish routes based on first path determination criteria associated with a first identifier. More specifically, each router node 1, 2, 3, and 4 of the first network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the first path determination criteria (and e.g. mostly limit its entries to such determined paths). On the other hand, each router node 5, 6, 7, and 8 of the second network slice may be configured to establish routes based on second path determination criteria associated with a second identifier. More specifically, each router node 5, 6, 7, and 8 of the second network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the second path determination criteria (and e.g. mostly limit its entries to such determined paths). Such path determination criteria may be provisioned at the router nodes by a controller.).
Regarding claim 13, Filsfils 1 teaches a method implemented by a network node (abstract – router node) in a current network domain (figure 2B: SR domain 280), the method comprising:
receiving a packet in an internet protocol (IP) version six (IPv6) format (col 4, lines 62-64: an SR header may be inserted in an IPv6 packet at a source node or at an ingress node, or even encapsulated at the ingress node), the packet containing a header comprising a domains left field, and a base IPv6 destination address field (col. 7, lines 35-44: Given the above scheme, (i) Router node 9 may advertise Prefix SID B:0:9:1:: for ALGO 0, Prefix SID B:128:9:1:: for ALGO 128, and Prefix SID B:129:9:1:: for ALGO 129 (ii) Router node 3 may advertise Prefix SID B:0:3:1:: for Algo 0, and Prefix SID B:128:3:1:: for ALGO 128.-SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with an IPv6 header with source address SA, destination addresses DA, and next header which is an SRH. SRH (S3, S2, S1; SL) is an SRH with SID list <S1, S2, S3> with SegmentsLeft=SL); and
determining a current network domain is a final domain on a path based on the domains left field (col. 11, lines 5-21: the router node 1 may operate to test all (or at least most) of the possible paths that any customer data packet may exercise. This testing may include testing all (or at least most) of the ingress and egress line card forwarding across available equal-cost multi-paths (ECMPs). This may be achieved by injecting the loopback probe message 610 towards upstream router node 0 and looping it back to a targeted line card, by using an adjacency SID at the upstream router node 0 towards the targeted line card. In the detailed example, the loopback probe message 610 sent by router node 1 on the interface to router node 0 will be (A1::, 99:0:1::0) (B:128:3:1::, SL=1, 0=1). Due to use of the adjacency SID 99:0:1::0, router node 0 may process the SRH and send the loopback probe message 612 (A1::, B:128:3:1::)(B:128:3:1::, SL=1, 0=1) back to router node 1. Here, the SRH.0 bit may be set so that the SRH is not removed.);
However, Filsfils 1 does not explicitly teach an original destination address field, copying an original destination address into the base IPv6 destination address field; and
forwarding the packet toward the original destination address in the base IPv6 destination address field.
In an analogous art, Filsfils 2 teaches an original destination address field, copying an original destination address into the base IPv6 destination address field ([0028] FIG. 3A, the second network apparatus 252 may copy the second global identifier 213 before shifting the bits in the destination address, and write the copied second global identifier 213 to the last 16 bits of the updated destination address 310. FIG. 3B illustrates an example destination address after a global identifier being rotated. The second global identifier 213 may be written at the end of the updated destination address 320. Although this disclosure describes updating the destination address by rotating a global identifier at the end of the destination address in a particular manner, this disclosure contemplates updating the destination address by rotating a global identifier at the end of the destination address in any suitable manner.); and
forwarding the packet toward the original destination address in the base IPv6 destination address field a method includes receiving a packet comprising a destination address in a destination address field of the packet, where the destination address including at least a first global identifier and a second global identifier, determining that the first global identifier corresponds to the first network apparatus, determining that a local identifier in the destination address is associated with the first global identifier, identifying one or more instructions associated with the local identifier, performing one or more functions instructed by the one or more instructions, updating the destination address in the destination field of the packet to an updated destination address, determining a forwarding rule associated with the packet, and forwarding the packet with the updated destination address based on the forwarding rule.
Before the effective filing date of the invention, one of ordinary skill in the art would have been motivated to incorporate the teaching of Filsfils 2 into the teaching of Filsfils 1 in order to ensure correct delivery to the final destination.
Regarding claim 14, Filsfils 1 teaches the method of claim 13, wherein the base IPv6 destination address field contains an IPv6 address of the network node prior to copying the original destination address into the base IPv6 destination address field (col. 15, lines 7-20: the making of the copy having the network resource identifiers may be performed as part of a forwarding and punting a copy of the message (i.e. punt a copy of the received packet after forwarding it). In SRv6 Network Programming (draft-filsfils-spring-srv6-network-programming-04) described earlier above, an SRH.Flags.O-bit is defined to instruct a “forward and punt a copy of the packet” behavior (i.e. punt the copy of the received packet after forwarding it). A “forward and punt a copy of the packet” processes a packet without head-of-line blocking in switching the packet, and hence is efficient and hardware-friendly. The router node that may implement the forward and punt behavior is assumed to punt the entire packet, including an internal header of the packet.).
Regarding claim 15, Filsfils 1 teaches the method of claim 13, wherein the header further comprises a routing type field set to indicate domain level source routing is used for the packet (figure 2: SR header identifies segment routing type).
Regarding claim 16, Filsfils 1 teaches the method of claim 13, wherein the header further comprises a domain ID list field containing a list of domain IDs for each domain along a path between a source of the packet and a destination of the packet (col. 5, line 57 to col. 6, line 4: each router node of the first network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the first path determination criteria (and e.g. mostly limit its entries to such determined paths). On the other hand, each router node of the second network slice may be configured to establish routes based on second path determination criteria associated with a second identifier (step 306b of FIG. 3). More specifically, each router node of the second network slice may be configured to populate its forwarding table with forwarding table entries of paths determined according to the second path determination criteria (and e.g. mostly limit its entries to such determined paths). Such path determination criteria may be provisioned at the router nodes by a controller).
Regarding claim 17, Filsfils 1 teaches the method of claim 16, wherein the header further comprises a first domain field containing a pointer to a first domain ID in the domain ID list field (col. 7, lines 35-44: Given the above scheme, (i) Router node 9 may advertise Prefix SID B:0:9:1:: for ALGO 0, Prefix SID B:128:9:1:: for ALGO 128, and Prefix SID B:129:9:1:: for ALGO 129 (ii) Router node 3 may advertise Prefix SID B:0:3:1:: for Algo 0, and Prefix SID B:128:3:1:: for ALGO 128.-SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with an IPv6 header with source address SA, destination addresses DA, and next header which is an SRH. SRH (S3, S2, S1; SL) is an SRH with SID list <S1, S2, S3> with SegmentsLeft=SL).
Claim 20 is a network node version of claim 1. It further recites a processor, transmitter, receiver, and memory. Nevertheless, this is taught by Filsfils 1 in figure 7. The rest of the claim limitation is rejected under the same rationale as claim 1.
Allowable Subject Matter
Claims 9, 11, 18 and 19 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Regarding claim 9, the prior art of record does not teach the method of claim 1, wherein the header further comprises a domain level source routing (DLSR) options type length value (TLV) containing quality of service (QOS) data for domains traversed by the packet.
Regarding claim 11, the prior art of record does not teach the method of claim 1, wherein the header includes an IPV6 header containing the base IPv6 destination address field and an extended domain level source routing (DLSR) header containing the domain ID list field, a domains left field, a routing type field, a first domain field, an original destination address field, and a DLSR options type length value (TLV).
Claims 18 and 19 are objected for the same reason as claims 9 and 11, respectively.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
RFC 8754: “IPv6 Segment Routing Header (SRH)” - Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header called the Segment Routing Header (SRH).
Filsfils et al., US 20210092053 - multi-domain network in which a source device generates an IPv6 packet that is forwarded by intermediary devices onto a destination device using domain-specific, micro-segment routing instructions.
Negi et al., US 11962496 - establishing a segment routing (SR) tunnel based on an Internet Protocol version 6 (IPv6) data plane using a Path Computation Element Communication Protocol (PCEP).
Bashandy et al., US 20220232112 - processing and sending of Internet Protocol packets in packet network, adding and communicating packets according to a Segment Routing Policy.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ALINA N BOUTAH whose telephone number is (571)272-3908. The examiner can normally be reached M-F 7:00 AM - 3:00 PM.
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, Umar Cheema can be reached at (571) 270-3037. 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.
ALINA BOUTAH
Primary Examiner
Art Unit 2458
/ALINA A BOUTAH/Primary Examiner, Art Unit 2458
Prosecution Insights