DETAILED ACTION
This action is responsive to communications filed 13 July 2026.
Claim 9 remains canceled.
Claims 2 and 15 have been canceled.
Claims 22-23 have been added.
Claims 1, 3-8, 10-14 and 16-23 are subject to examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
The 35 U.S.C. 112 rejections have been withdrawn in view of amendments.
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 3-5, 7, 10-11, 13-14, 16-18, 20 and 22-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Retana et al. (US-11374848-B2) hereinafter Retana in view of Lin et al. (CN-113595897-A) hereinafter Lin.
Regarding claim 11, Retana discloses:
An electronic device ([15:61-16:9] network device 1900), comprising a memory and a processor ([16:22-41] processor 1930 … memory devices 1940), wherein the memory stores a computer program ([17:15-29] storing computer-readable instructions), and the processor is configured to run the computer program so as to execute ([17:48-61] when executed by the processor 1930 performs network processing and network switch operations) the following operations:
adding, by an encapsulation node ([6:26-48] edge node R3 (104) encapsulates the original packet (i.e. encapsulation node)), an Internet Protocol Version 6 (IPv6) routing header to a Segment Routing with IPv6 data plane (SRv6) packet comprising Segment Identifiers (SIDs) ([6:26-48] encapsulates the original packet with a new encapsulation header 112 [7:10-39] segment routing is defined … IETF … network instructions are inserted into an IPv6 packet header using a Segment Routing Header (SRH) … 128-bit SRv6 SID (IPv6 Destination Address) … SRv6 extension header (i.e. SRv6 packet), see [FIG. 1], see also [FIGs. 4-5] SRv6 packet, added IPv6 header [9:36-44] encapsulates the original data packet 900 with new IPv6 header 902 that contains the path information): and
the processor is configured to run the computer program so as to further execute the following operations:
replacing, by a second-to-last segment endpoint node corresponding to the SRv6 packet ([FIG. 14] R5 in a path of R3 to R4 to R5 to R8), an IPv6 destination address of the SRv6 packet with the first IPv6 address of the IPv6 routing header ([12:4-41] encapsulation information 1410 specifying the source address 50::16 and the destination address 80::0 for the segment from R5 -> R8 is provide in path 1 and the source and destination addresses are swapped since that function is enabled at R5 (50::1), see [FIG. 14] R5 in a path of R3 to R4 to R5 to R8), wherein the second-to-last segment endpoint node is a segment endpoint node that the SRv6 packet passes through in a transmission process of the SRv6 packet ([FIG. 14] R5 in a path of R3 to R4 to R5 to R8); and
forwarding, by the second-to-last segment endpoint node ([FIG. 14] R5 in a path of R3 to R4 to R5 to R8), the SRv6 packet to a last segment endpoint node ([12:4-41 R5 -> R8, see [FIG. 14] e.g. R5 -> R8).
Retana does not explicitly disclose:
adding, by an encapsulation node, an Internet Protocol Version 6 (IPv6) routing header to a Segment Routing with IPv6 data plane (SRv6) packet comprising compressed Segment Identifiers (uSIDs): and
setting, by the encapsulation node, a first IPv6 address of the IPv6 routing header to be an IPv6 address of a last endpoint node corresponding to the SRv6 packet, and using, by the encapsulation node, the IPv6 address of the last endpoint node corresponding to the SRv6 packet as a basis for checksum calculation; and
However, Lin discloses:
adding, by an encapsulation node ([p. 5] N0 transmission band SRH encapsulated bidirectional forwarding detection (BFD) message (i.e. encapsulation node performs this)), an Internet Protocol Version 6 (IPv6) routing header to a Segment Routing with IPv6 data plane (SRv6) packet comprising compressed Segment Identifiers (uSIDs) ([p. 5] compressed SRv6SID … IP address of the N4 (e.g. destination device) corresponding to the TE-Policy is inserted in the SID [0] position of the SRH … message head comprises IPv6 head and SRH): and
setting, by the encapsulation node ([p. 5] N0 transmission band SRH encapsulated bidirectional forwarding detection (BFD) message (i.e. encapsulation node performs this)), a first IPv6 address of the IPv6 routing header to be an IPv6 address of a last endpoint node corresponding to the SRv6 packet ([p. 5] IP address of the N4 (e.g. destination device) corresponding to the TE-Policy is inserted in the SID [0] position of the SRH … message head comprises IPv6 head and SRH), and using, by the encapsulation node ([p. 5] N0 transmission band SRH encapsulated bidirectional forwarding detection (BFD) message (i.e. encapsulation node performs this)), the IPv6 address of the last endpoint node corresponding to the SRv6 packet as a basis for checksum calculation ([p. 5] when performing User Datagram Protocol (UDP) verification and checksum calculation, the destination address uses the IPv6 address of N4); and
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana in view of Lin to have the method performed with use of compressed SIDs and set, by the encapsulation node, a first IPv6 address of the IPv6 routing header to be an IPv6 address of a last endpoint node corresponding to the SRv6 packet and using the IPv6 address of the last endpoint node corresponding to the SRv6 packet as a basis for checksum calculation. One of ordinary skill in the art would have been motivated to do so to solve the problem of message head overhead in SRv6 by using compressed SRV6SID and perform UDP verification and checksum calculation because the destination address in the current IPv6 head cannot be used as it is changed (Lin, [p. 5]).
Regarding claim 16, Retana-Lin disclose:
The electronic device according to claim 15, wherein the processor is configured to run the computer program, set forth above, so as to further execute the following operations:
Retana discloses:
when verifying a checksum carried in the SRv6 packet, performing, by the last segment endpoint node ([FIG. 15] R5), the checksum calculation according to the IPv6 destination address ([13:14-42] when the other border router R4 receives the packet, it verifies the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security, see [FIG. 15] e.g. intra domain of B between R4 and R5 (i.e. last segment endpoint), see also [15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header, e.g. see [6:26-48] encapsulation header 12 … new destination address is 40::1 for the edge node R4, see [FIG. 1] e.g. last node)).
Regarding claim 17, Retana-Lin disclose:
The electronic device according to claim 15, wherein the processor is configured to run the computer program, set forth above, so as to execute the following operations:
Retana discloses:
replacing, by the second-to-last segment endpoint node ([FIG. 14] R5 in a path of R3 to R4 to R5 to R8), the IPv6 destination address of the SRv6 packet with the first IPv6 address of the IPv6 routing header in a direct replacement manner ([12:4-41] encapsulation information 1410 specifying the source address 50::16 and the destination address 80::0 for the segment from R5 -> R8 is provide in path 1 and the source and destination addresses are swapped (i.e. directly by swapping) since that function is enabled at R5 (50::1), see [FIG. 14] R5 in a path of R3 to R4 to R5 to R8).
Regarding claim 18, Retana-Lin disclose:
The electronic device according to claim 11, wherein the processor is configured to run the computer program, set forth above, so as to execute the following operations:
Retana discloses:
setting a routing type of the IPv6 routing header added to the SRv6 packet to be a routing type 4 of a segment routing header ([FIG. 5] e.g. 406 (i.e. routing TYPE = 4)), and setting a flag bit in the segment routing header as 1 so as to distinguish the IPv6 routing header from other segment routing headers ([7:53-62] Tag field 414 tags a packet as part of a class or group of packets (i.e. tagging it distinguishes it from other packets having other headers)); or
setting the routing type of the IPv6 routing header added to the SRv6 packet to be another routing type value that is different from the routing type 4 of the segment routing header, so as to distinguish the IPv6 routing header from the segment routing header.
Regarding claim 20, Retana-Lin disclose:
The electronic device according to claim 11, wherein the processor is configured to run the computer program, set forth above, so as to execute the following operations:
Retana discloses:
in a case where the SRv6 packet comprises a User Datagram Protocol (UDP) packet header ([13:14-42] UDP header checksum [15:41-60] checksum in the UDP header (i.e. comprises UDP header)), performing, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), the checksum calculation according to the IPv6 address of the last endpoint node corresponding to the SRv6 packet ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header)), and filling, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), a UDP checksum field in the UDP packet header with a checksum obtained by the checksum calculation ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header), see [FIG. 15] UDP header would comprise a field with a checksum value)); and
performing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), the checksum calculation ([13:14-42] when the other border router R4 receives the packet, it verifies (i.e. to verify is to calculate it and match the calculated value) the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security), and comparing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), a result of the checksum calculation with the checksum carried in the SRv6 packet for verification ([13:14-42] when the other border router R4 receives the packet, it verifies the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security, see [FIG. 15] e.g. intra domain of B between R4 and R5 (i.e. last segment endpoint)).
Regarding claims (1/10), 2-5 and 7, they do not further define nor teach over the limitations of claims 11, 15-18 and 20, therefore, claims (1/10), 2-5 and 7 are rejected for at least the same reasons set forth above as in claims 11, 15-18 and 20.
Regarding claim 13, Retana-Lin disclose:
The address setting method according to claim 1, set forth above,
Retana discloses:
wherein the IPv6 routing header comprises one IPv6 address or multiple IPv6 addresses ([7:10-39] 128-bit SRv6 SID (IPv6 Destination Address), see [FIG. 5] e.g. segment list [0] [1], etc. depending on how long the list of segment routing is).
Regarding claim 14, Retana-Lin disclose:
The address setting method according to claim 13, set forth above,
Retana discloses:
wherein in a case where the IPv6 routing header comprises multiple IPv6 addresses ([7:10-39] 128-bit SRv6 SID (IPv6 Destination Address), see [FIG. 5] e.g. segment list [0] [1], etc. depending on how long the list of segment routing is), the first IPv6 address among the multiple IPv6 addresses is set to be the IPv6 address of the last endpoint node of the SRv6 packet ([7:10-39] 128-bit SRv6 SID (IPv6 Destination Address) [8:24-32] Segment List [0] is the last segment, see [FIG. 5] segment list [0] = A4 (i.e. last node)), and
Retana does not explicitly disclose:
the other IPv6 addresses among the multiple IPv6 addresses comprise compressed SIDs.
However, Lin discloses:
the other IPv6 addresses among the multiple IPv6 addresses comprise compressed SIDs ([p. 5] hop-by-hop node needs to be appointed by the SID, so the forwarding path is longer, the number of SID on the path is more, the cost of the message head is larger … solve the problem … using … compressed SRv6SID (i.e. multiple addresses are all compressed SIDs)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana in view of Lin to have the method performed with use of compressed SIDs. One of ordinary skill in the art would have been motivated to do so to solve the problem of message head overhead in SRv6 by using compressed SRV6SID and perform UDP verification and checksum calculation because the destination address in the current IPv6 head cannot be used as it is changed (Lin, [p. 5]).
Regarding claim 22, Retana-Lin disclose:
The address setting method according to claim 1, set forth above,
Retana discloses:
wherein an encapsulation format of the SRv6 packet comprises: an IPv6 source address, an IPv6 destination address, and the IPv6 routing header, wherein the IPv6 destination address is used to carry multiple SIDs ([FIG. 5] e.g. source address, destination address, IPv6 header, next header (i.e. routing header), and SIDs e.g. segment list [xxx]).
Retana does not explicitly disclose:
wherein the IPv6 destination address is used to carry multiple uSIDs.
However, Lin discloses:
wherein the IPv6 destination address is used to carry multiple uSIDs ([p. 5] hop-by-hop node needs to be appointed by the SID, so the forwarding path is longer, the number of SID on the path is more, the cost of the message head is larger … solve the problem … using … compressed SRv6SID (i.e. multiple addresses are all compressed SIDs)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana in view of Lin to have the method performed with use of compressed SIDs. One of ordinary skill in the art would have been motivated to do so to solve the problem of message head overhead in SRv6 by using compressed SRV6SID and perform UDP verification and checksum calculation because the destination address in the current IPv6 head cannot be used as it is changed (Lin, [p. 5]).
Regarding claim 23, Retana-Lin disclose:
The address setting method according to claim 22, set forth above,
Retana discloses:
wherein the IPv6 destination address of the SRv6 packet at the encapsulation node does not point to the IPv6 address of the last endpoint node of the SRv6 packet, but points to a first endpoint node that the SRv6 packet needs to pass through ([8:24-32] IP destination address is set to the first segment, and the packet is sent according to the IP destination address using normal IPv6 forwarding (e.g., segment routing (SR) capable, see [FIG. 5]).
Claim(s) 6, 8, 19 and 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Retana et al. (US-11374848-B2) hereinafter Retana in view of Lin et al. (CN-113595897-A) hereinafter Lin further in view of Nainar et al. (US-10749794-B2) hereinafter Nainar.
Regarding claim 19, Retana-Lin disclose:
The electronic device according to claim 11, wherein the processor is configured to run the computer program, set forth above, so as to execute the following operations:
Retana discloses:
in a case where the SRv6 packet comprises a User Datagram Protocol (UDP) packet header ([13:14-42] UDP header checksum [15:41-60] checksum in the UDP header (i.e. comprises UDP header)), performing, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), the checksum calculation according to the IPv6 address of the last endpoint node corresponding to the SRv6 packet ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header)), and filling, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), a UDP checksum field in the UDP packet header with a checksum obtained by the checksum calculation ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header), see [FIG. 15] UDP header would comprise a field with a checksum value)); and
performing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), the checksum calculation ([13:14-42] when the other border router R4 receives the packet, it verifies (i.e. to verify is to calculate it and match the calculated value) the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security), and comparing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), a result of the checksum calculation with the checksum carried in the SRv6 packet for verification ([13:14-42] when the other border router R4 receives the packet, it verifies the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security, see [FIG. 15] e.g. intra domain of B between R4 and R5 (i.e. last segment endpoint)).
Retana does not explicitly disclose:
in a case where the SRv6 packet comprises a Transmission Control Protocol (TCP) packet header,
However, Nainar discloses:
in a case where the SRv6 packet comprises a Transmission Control Protocol (TCP) packet header ([10:35-58] next header field can be changed from SRH to TCP),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana in view of Nainar to have the SRv6 packet comprise a TCP packet header. One of ordinary skill in the art would have been motivated to do so to detect an error associated with packet and rewrite the header for error signaling (Nainar, [10:35-11:34]).
Regarding claim 21, Retana-Lin disclose:
The electronic device according to claim 11, wherein the processor is configured to run the computer program, set forth above, so as to execute the following operations:
Retana discloses:
in a case where the SRv6 packet comprises a User Datagram Protocol (UDP) packet header ([13:14-42] UDP header checksum [15:41-60] checksum in the UDP header (i.e. comprises UDP header)), performing, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), the checksum calculation according to the IPv6 address of the last endpoint node corresponding to the SRv6 packet ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header)), and filling, by the encapsulation node ([15:41-60] network node that adds the UDP header … typically a network node at an edge of a first domain), a UDP checksum field in the UDP packet header with a checksum obtained by the checksum calculation ([15:41-60] checksum in the UDP header is calculated based on the data packet and the encapsulation header, so any changes to either would cause a change in the checksum (i.e. basis for checksum calculation based on encapsulation header), see [FIG. 15] UDP header would comprise a field with a checksum value)); and
performing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), the checksum calculation ([13:14-42] when the other border router R4 receives the packet, it verifies (i.e. to verify is to calculate it and match the calculated value) the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security), and comparing, by the last endpoint node ([FIG. 1] last node, see also [FIG. 15] last node R5), a result of the checksum calculation with the checksum carried in the SRv6 packet for verification ([13:14-42] when the other border router R4 receives the packet, it verifies the UDP header checksum … UDP header may also be used in intra-domain scenarios for extra security, see [FIG. 15] e.g. intra domain of B between R4 and R5 (i.e. last segment endpoint)).
Retana does not explicitly disclose:
in a case where the SRv6 packet comprises an Internet Control Message Protocol version 6 (ICMPv6) packet header,
However, Nainar discloses:
in a case where the SRv6 packet comprises an Internet Control Message Protocol version 6 (ICMPv6) packet header ([10:35-58] next header field can be changed from SRH to TCP or other appropriate header indicator … ICMPv6),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana in view of Nainar to have the SRv6 packet comprise an ICMPv6 packet header. One of ordinary skill in the art would have been motivated to do so to detect an error associated with packet and rewrite the header for error signaling (Nainar, [10:35-11:34]).
Regarding claims 6 and 8, they do not further define nor teach over the limitations of claims 19 and 21, therefore, claims 6 and 8 are rejected for at least the same reasons set forth above as in claims 19 and 21.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Retana et al. (US-11374848-B2) hereinafter Retana in view of Lin et al. (CN-113595897-A) hereinafter Lin further in view of Dong et al. (US-20240283738-A1) hereinafter Dong.
Regarding claim 12, Retana-Lin disclose:
The address setting method according to claim 1, set forth above, further comprising:
Retana-Lin do not explicitly disclose:
setting the routing type of the IPv6 routing header added to the SRv6 packet to be another routing type value that is different from the routing type 4 of the segment routing header, so as to distinguish the IPv6 routing header from the segment routing header.
However, Dong discloses:
setting the routing type of the IPv6 routing header added to the SRv6 packet to be another routing type value that is different from the routing type 4 of the segment routing header ([0119] routing type field being 1, 2, 3, 5 or the like), so as to distinguish the IPv6 routing header from the segment routing header ([0119] is different from a method for processing an extension header of an SRH type).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Retana-Lin in view of Dong to have set the routing type different than 4 to distinguish the IPv6 routing header from the segment routing header. One of ordinary skill in the art would have been motivated to do so to perform a different method of processing an extension header (Dong, [0119]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Filsfils et al. (US-20200412846-A1) Enhanced Segment Routing Processing Of Packets;
Goud Gadela et al. (US-11611506-B2) Processing A Flow At The Egress Node In Segment Routing.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) 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 Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kamal Divecha can be reached at (571)272-5863. 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.
/Alex Tran/Primary Examiner, Art Unit 2453
Prosecution Insights