DETAILED ACTION
This action is responsive to communications filed 30 September 2024.
Claim 9 has been canceled.
Claims 12-21 have been added.
Claims 1-8 and 10-21 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.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 30 September 2024, 06 June 2025, 21 October 2025 and 06 March 2026. The submission 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 § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 10 and 11 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
The claims recite “so as to determine a basis for checksum calculation”; however, the claim is unclear on what is the basis for a checksum calculation, or what is determined to be the basis for checksum calculation, and further how the IPv6 address of a last endpoint node corresponding to the SRv6 packet is utilized.
Upon examination of the specification it denotes:
[p. 9, l. 1-5] “… IPv6 destination address is used as the basis for checksum calculation, which ensures that the calculation basis used by the last endpoint node in calculating the checksum is consistent with the calculation basis used by the encapsulation node in calculating the checksum …”
Such that the basis for checksum calculation is determined to be an IPv6 destination address.
Nowhere in the claims does it define how/why/what the determination is for the basis of checksum calculation, as such, the language renders the claim indefinite.
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-5, 7, 10-11, 13-18 and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Retana et al. (US-11374848-B2) hereinafter Retana in view of Gandhi et al. (US-20220286395-A1) hereinafter Gandhi.
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
setting a first IPv6 address of the IPv6 routing header to be an IPv6 address of a last endpoint node corresponding to 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)), so as to determine a basis for 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, 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)).
Retana does not explicitly disclose:
a Segment Routing with IPv6 data plane (SRv6) packet comprising compressed Segment Identifiers (uSIDs);
However, Gandhi discloses:
a Segment Routing with IPv6 data plane (SRv6) packet comprising compressed Segment Identifiers (uSIDs) ([0079] one or more SRv6 micro segments (uSIDs) are encoded in a single SID);
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 Gandhi to have a SRv6 packet comprising uSIDs. One of ordinary skill in the art would have been motivated to do so to leverage benefits of IP, such as, but not limited to, longest prefix matching forwarding, prefix summarization, identifying entropy, etc. (Gandhi, [0079])
Regarding claim 15, Retana-Gandhi disclose:
The electronic device according to claim 11, wherein the processor is configured to run the computer program, set forth above, so as to further execute the following operations:
Retana discloses:
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).
Regarding claim 16, Retana-Gandhi 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-Gandhi 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-Gandhi 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-Gandhi 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-Gandhi 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-Gandhi 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, Gandhi discloses:
the other IPv6 addresses among the multiple IPv6 addresses comprise compressed SIDs ([0079] one or more SRv6 micro segments (uSIDs) are encoded in a single SID).
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 Gandhi to have a SRv6 packet comprising uSIDs. One of ordinary skill in the art would have been motivated to do so to leverage benefits of IP, such as, but not limited to, longest prefix matching forwarding, prefix summarization, identifying entropy, etc. (Gandhi, [0079]).
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 Gandhi et al. (US-20220286395-A1) hereinafter Gandhi further in view of Nainar et al. (US-10749794-B2) hereinafter Nainar.
Regarding claim 19, Retana-Gandhi 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-Gandhi 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 Gandhi et al. (US-20220286395-A1) hereinafter Gandhi further in view of Dong et al. (US-20240283738-A1) hereinafter Dong.
Regarding claim 12, Retana-Gandhi disclose:
The address setting method according to claim 1, set forth above, further comprising:
Retana-Gandhi 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-Gandhi 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.
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