DETAILED ACTION
This is in response to the Applicant's arguments and amendments filed on 17 October 2023 in which claims 1-20 are currently pending.
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 references listed in the Information Disclosure Statement, filed on 19 September 2024, 17 March 2025, have been considered by the examiner (see attached PTO-1449 form or PTO/SB/08A and 08B forms).
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.
Claims 1-3, 7-13, 16-18 are rejected under 35 U.S.C. 103 as being unpatentable over Filsfils et al. (PG Pub US 2023/0336450 A1) in view of Richards et al. (US Patent No. 11,528,201 B1).
Regarding claims 1, 11, Filsfils discloses a method and a first network device that is a first edge network device in a first network domain (fig. 4A).
a non-transitory memory configured to store instructions; and one or more processors coupled to the non-transitory memory and configured to execute the instructions to cause the first network device to (fig. 10):
receive a first packet of a service flow, wherein the first packet comprises a detection header instructing detection of, based on the detection header, transmission performance of the service flow (“the source node 118(1) may encapsulate the path tracing packet 122 with a segment routing header and set a value of the segment routing header “T” flag to enable the downstream nodes 118(2)-118(4) to read a Tag field of the segment routing header. Additionally, the source node 118(1) may encode the Tag field of the segment routing header to indicate what type of telemetry data is to be encoded by the downstream nodes” [0052]);
obtain, based on the first packet, a second packet comprising processing identification information and the detection header, wherein the processing identification information instructs processing of the detection header (“the Tag field may include a first indication (e.g., “action” bits) that indicates the type of telemetry data and a second indication (e.g., “offset” bits) that indicates the offset where the telemetry data is to be recorded within the telemetry carrier of the path tracing packet 122” [0053]); and
send the second packet to a second network device that is outside the first network domain and that is a next-hop device of the first network device on a transmission path of the service flow (“The midpoint nodes 118(2) and 118(3) may, in turn, forward the path tracing packet 122 downstream. The midpoint node may use the indication (action/offset bits) from and encode the telemetry data in IPv6 hop-by-hop option” [0053], “The sink node 118(4) (or tail end node) may, in some examples, receive the path tracing packet 122 from the midpoint node 118(3), record its own telemetry data (e.g., short timestamp, full timestamp, interface ID, etc.), and forward all of the telemetry data 124 (e.g., all of the telemetry data added by the nodes 118(1)-118(4)) to the collector 116” [0054], “an egress provider edge node” [0038], “The network 102 may include devices, virtual resources, or other nodes that relay packets from one network segment to another” [0048]).
However, Filsfils does not explicitly disclose obtain, based on the first packet, a second packet.
Nevertheless, Richards discloses “the network device 104 may subsequently send another telemetry-enriched packet to the network device 114. The network device 104 may determine that a loss of data has occurred based upon not receiving a response to the subsequent telemetry-enriched packet within a certain time limit based upon the previously determined round-trip time” col 13 lines 49-54.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to obtain, based on the first packet, a second packet because “In enriching packets, the network device 104 may intercept (e.g., select) one or more packets of the network traffic being encapsulated and enrich the one or more packets with telemetry information to be sent with the payload information. The network device 104 may enrich network traffic corresponding to different virtualized computing environments at different rates and/or times” col 9 lines 61-67.
Regarding claim 16, Filsfils discloses a second network device outside a first network domain (fig. 4A).
a non-transitory memory configured to store instructions; and one or more processors coupled to the non-transitory memory and configured to execute the instructions to cause the second network device to (fig. 10):
receive a second packet from a first network device that is an edge network device in the first network domain such that the second network device is a next-hop device of the first network device on a transmission path of a service flow (“The midpoint nodes 118(2) and 118(3) may, in turn, forward the path tracing packet 122 downstream. The midpoint node may use the indication (action/offset bits) from and encode the telemetry data in IPv6 hop-by-hop option” [0053], “The sink node 118(4) (or tail end node) may, in some examples, receive the path tracing packet 122 from the midpoint node 118(3), record its own telemetry data (e.g., short timestamp, full timestamp, interface ID, etc.), and forward all of the telemetry data 124 (e.g., all of the telemetry data added by the nodes 118(1)-118(4)) to the collector 116” [0054], “an egress provider edge node” [0038], “The network 102 may include devices, virtual resources, or other nodes that relay packets from one network segment to another” [0048]), wherein the second packet is based on a first packet of the service flow, wherein the second packet comprises processing identification information and a detection header (“the Tag field may include a first indication (e.g., “action” bits) that indicates the type of telemetry data and a second indication (e.g., “offset” bits) that indicates the offset where the telemetry data is to be recorded within the telemetry carrier of the path tracing packet 122” [0053]), wherein the processing identification information instructs the second network device to process the detection header, and wherein the detection header instructs detection of a transmission performance of the service flow (“the source node 118(1) may encapsulate the path tracing packet 122 with a segment routing header and set a value of the segment routing header “T” flag to enable the downstream nodes 118(2)-118(4) to read a Tag field of the segment routing header. Additionally, the source node 118(1) may encode the Tag field of the segment routing header to indicate what type of telemetry data is to be encoded by the downstream nodes” [0052]); and
detect the transmission performance of the service flow based on the processing identification information and the detection header (“read the Tag field of the segment routing header to determine which type of telemetry data to record in the path tracing packet 122 and record the telemetry data at a location specified by an indication in the Tag field. For instance, the Tag field may include a first indication (e.g., “action” bits) that indicates the type of telemetry data and a second indication (e.g., “offset” bits) that indicates the offset where the telemetry data is to be recorded within the telemetry carrier of the path tracing packet 122” [0053]).
However, Filsfils does not explicitly disclose the second packet is based on a first packet.
Nevertheless, Richards discloses “the network device 104 may subsequently send another telemetry-enriched packet to the network device 114. The network device 104 may determine that a loss of data has occurred based upon not receiving a response to the subsequent telemetry-enriched packet within a certain time limit based upon the previously determined round-trip time” col 13 lines 49-54.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have the second packet be based on a first packet because “In enriching packets, the network device 104 may intercept (e.g., select) one or more packets of the network traffic being encapsulated and enrich the one or more packets with telemetry information to be sent with the payload information. The network device 104 may enrich network traffic corresponding to different virtualized computing environments at different rates and/or times” col 9 lines 61-67.
Regarding claims 2, 12, 17, Filsfils, Richards discloses everything claimed as applied above. In addition, Richards discloses the second packet further comprises a media access control (MAC) header and an Internet Protocol (IP) header, and wherein the processing identification information and the detection header are located between the MAC header and the IP header (“the telemetry-enriched packet 200 may be divided into multiple layers, portions, headers, or sections such as an IP address layer 202, an enrichment information layer 204, an IP information layer 206, a TCP information layer 208, and a payload information layer 210 .. include additional fields or layers such as a user datagram protocol layer, an Ethernet layer, or a trivial file transfer protocol layer. One or more layers of the telemetry-enriched packet may correspond to layers of the packet such as the IP information layer 206, TCP information layer 208, and the payload information layer 210. In some embodiments, more or less layers of the telemetry-enriched packet may correspond to layers of the packet. One or more layers of the telemetry-enriched packet may correspond to layers added via the encapsulation process such as the IP address layer 202 and the enrichment information layer 204. In some embodiments, more or less layers of the telemetry-enriched packet may correspond to layers added via the encapsulation of the packet” col 14 lines 17-37; where the location of the headers would be obvious variants based on packet generation design choice).
Regarding claims 3, 13, 18, Filsfils, Richards discloses everything claimed as applied above. In addition, Richards discloses the processing identification information is located closer to the MAC header than the detection header is, and the processing identification information and the detection header are adjacent to each other (“the telemetry-enriched packet 200 may be divided into multiple layers, portions, headers, or sections such as an IP address layer 202, an enrichment information layer 204, an IP information layer 206, a TCP information layer 208, and a payload information layer 210 .. include additional fields or layers such as a user datagram protocol layer, an Ethernet layer, or a trivial file transfer protocol layer. One or more layers of the telemetry-enriched packet may correspond to layers of the packet such as the IP information layer 206, TCP information layer 208, and the payload information layer 210. In some embodiments, more or less layers of the telemetry-enriched packet may correspond to layers of the packet. One or more layers of the telemetry-enriched packet may correspond to layers added via the encapsulation process such as the IP address layer 202 and the enrichment information layer 204. In some embodiments, more or less layers of the telemetry-enriched packet may correspond to layers added via the encapsulation of the packet” col 14 lines 17-37; where the location of the headers would be obvious variants based on packet generation design choice).
Regarding claim 7, Filsfils, Richards discloses everything claimed as applied above. In addition, Filsfils discloses the second network device is a second edge network device in a second network domain (“edge routers .. The network interfaces may include devices configured to couple to personal area networks (PANs), wired and wireless local area networks (LANs), wired and wireless wide area networks (WANs), and so forth” [0110]).
Regarding claim 8, Filsfils, Richards discloses everything claimed as applied above. In addition, Filsfils discloses the first network device is a tail node device of a first tunnel that belongs to the first network domain, wherein the second network device is a head node device of a second tunnel that belongs to the second network domain, and wherein the first tunnel and the second tunnel are segments of a third tunnel on the transmission path (“a segment list of a segment routing header of the packet” [0038], “source node (e.g., source provider edge node) .. sink node (e.g., egress provider edge node)” [0050]).
Regarding claim 9, Filsfils, Richards discloses everything claimed as applied above. In addition, Filsfils discloses the first network domain or the second network domain is a virtual private network (VPN) (“Virtual Private Networks (VPNs)” [0048]).
Regarding claim 10, Filsfils, Richards discloses everything claimed as applied above. In addition, Filsfils discloses enabling a capability of carrying the processing identification information and the detection header in a single packet for transmission through a first interface of the first network device; and further sending the second packet to the second network device through the first interface (“the Tag field of the segment routing header to indicate what type of telemetry data is to be encoded by the downstream nodes 118(2)-118(4), as well as an offset within the telemetry carrier” [0052], “the first node may determine a short interface ID indicative of an interface of the first node used to receive the packet” [0073], “the telemetry data may include a first short interface identifier indicative of an interface of the source node 118(1) used to send the packet” [0082]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Filsfils, Richards in view of Nainar et al. (PG Pub US 2019/0372877 A1).
Regarding claim 6, Filsfils, Richards discloses everything claimed as applied above. However, Filsfils, Richards does not explicitly disclose the detection header is an In-situ Flow Information Telemetry (IFIT) header.
Nevertheless, Nainar discloses “In-Situ Operations Administrator and Management (IOAM) is an inband telemetry data collection technique” [0002].
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to have an In-situ Flow Information Telemetry (IFIT) header because “In-Situ OAM allows a network/service operator to collect real-time telemetry data by embedding the data inband within actual data traffic. Such collected inband telemetry data allows a network/service operator to instantly react to any network events” [0002].
Allowable Subject Matter
Claims 4-5, 14-15, 19-20 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.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHRISTINE T DUONG whose telephone number is (571)270-1664. The examiner can normally be reached Monday - Friday 8 AM - 6 PM EST with every other Friday off.
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, Yemane Mesfin can be reached at (571)272-3927. 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.
/CHRISTINE T DUONG/ Primary Examiner, Art Unit 2462 01/06/2026