DETAILED ACTION
1. Applicant’s response filed on 12/23/2025 has been entered and made of record.
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 .
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.
Response to Arguments
Applicant’s remarks, filed on 12/23/2025, regarding Rejections under 35 U.S.C. § 102 and § 103 have been fully considered but are moot in view of new grounds of rejections. Please see the below rejection for further details.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-4, 11-14 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. (US 2021/0306252 A1), hereinafter “Jain” in view of Nelson et al. (US 2023/0216779 A1), hereinafter “Nelson”.
Regarding claim 1, Jain discloses a method comprising:
Receiving, by a network device, a layer-2 probe packet from an originating network device via an ingress port of the network device, wherein a header of the probe packet includes a source address associated with the originating network device (see Jain [Pg. 4, Claim 1], “receiving, at a first network device, a control packet originating from a originating network device, wherein the control packet has a control MAC address identifying the originating network device …”);
Determining, by the network device, whether the network device is the originating network device of the probe packet by comparing the source address with a local address allocated to the network device (see Jain [Pg. 4, Claim 1], “determining, by the first network device, whether the control MAC address of the control packet matches a MAC address of the first network device; …”);
In response to determining that the network device is not the originating network device (see Jain [Pg. 4, Claim 1], “… when it is determined that the control MAC address of the control packet does not match the MAC address of the first network device …”):
Appending the local address in a payload of the probe packet (see Jain [Pg. 2, ¶0017], “The forwarding information can include entries that map network addresses (e.g., MAC addresses or IP addresses) and/or ports to respective network paths toward the recipient device(s).”; Note: It is understood that the forwarding information is updated while mapping network addresses and/or ports in respective paths towards target devices.); and
Forwarding the probe packet via an egress port based on a destination address in the header of the probe packet (see Jain [Pg. 4, Claim 1], “…transmit the control packet to a second network device on the network without blocking any port on the first network device that received the control packet …”); and
In response to determining that the network device is the originating network device (see Jain [Pg. 4, Claim 1], “… when it is determined that the control MAC address of the control packet matches a MAC address of the first network device …”):
Determining presence of a loop associated with the network device (see Jain [Pg. 4, Claim 1], “… determine, by the first network device, that the match is indicative of the loop …”); and
Determining a trace path of the loop based on addresses in the payload of the probe packet, wherein the addresses in the payload correspond to devices on the trace path (see Jain [Pg. 2, ¶0017], “The forwarding information can include entries that map network addresses (e.g., MAC addresses or IP addresses) and/or ports to respective network paths toward the recipient device(s). … This process of appending trace information is performed by a respective participating device on a path to the target device.”).
Jain does not explicitly disclose appending the local address in a payload of the probe packet and determining a trace path of the loop based on addresses in the payload of the probe packet, wherein the addresses in the payload correspond to devices on the trace path.
Nelson discloses appending the local address in a payload of the probe packet (see Nelson [Pg. 2, ¶0033], “If the participating device is an intermediate device (i.e., not the target device), the participating device can append the local trace information in the payload in associated with the forward direction and decrement the TTL value in the header. … This process of appending trace information is performed by a respective participating device on a path to the target device.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to incorporate appending the local address in a payload of the probe packet as detailed by Nelson, onto the system of Jain, in order to improve system autonomy and troubleshooting by detailing path information as the trace packet is forwarded to each participating device (see Nelson [Pg. 1, ¶0018], “One aspect of the present technology can provide a system for layer-2 path tracing.”).
Nelson discloses determining a trace path of the loop based on addresses in the payload of the probe packet, wherein the addresses in the payload correspond to devices on the trace path (see Nelson [Pg. 1, ¶0015], “Layer-2 protocols, such as Ethernet, facilitate the operations of a number of such protocols and services. As a result, identifying issue in layer-2 paths (e.g., links and nodes) can be essential for troubleshooting. Examples of such issues can include, but are not limited to, layer-2 configuration errors, cabling issues, and identifying layer-2 loops.”; also see Nelson [Pg. 2, ¶0033], “On the other hand, if the participating device is the target device, upon appending the local trace information, the participating device terminates the forward trace. A respective participating device can also generate a copy of the packet as a response packet. The participating device can change the direction indicator in the payload to indicate a reverse trace to the originating device.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the determining a trace path of the loop based on addresses in the payload of the probe packet, wherein the addresses in the payload correspond to devices on the trac path as detailed by Nelson, onto the system of Jain, in order to confirm the existence of a layer-2 issue needed for troubleshooting and sending back a response packet with the detailed path of the involved devices.
Regarding claim 2, Jain combined with Nelson discloses the method of claim 1, wherein, in response to determining that the network device is the originating network device, the method further comprises performing a corrective action associated with the loop, wherein the corrective action includes one or more of:
Blocking the ingress port for preventing the loop (see Jain [Pg. 4, Claim 1], “… block, by the first network device, a port of the first network device that the control packet arrived on without blocking any other ports on the first network device, wherein no ports are blocked on other devices on the network that received the control packet …”); and
Generating an error notification associated with the loop.
Regarding claim 3, Jain combined with Nelson discloses the method of claim 1, further comprising determining the probe packet as a loop detection packet based on a type of the packet indicated by a predefined value in the header of the probe packet (see Jain [Pg. 2, ¶0016], “In some aspects, the system 100 may transmit special loop avoidance control packets that are used for loop detection and avoidance, while in other aspects the loop avoidance and detection information may be included in a normal control packet and/or in a control packet with additional types of information, included but not limited to payload data.”).
Regarding claim 4, Jain combined with Nelson discloses the method of claim 1, wherein, in response to determining that the network device is not the originating network device, the method further comprises appending respective identifiers of the ingress port and the egress port in the payload of the probe packet (see Jain [Pg. 2, ¶0017], “The forwarding information can include entries that map network addresses (e.g., MAC addresses or IP addresses) and/or ports to respective network paths toward the recipient device(s).”; Note: It is understood that the forwarding information is updated while mapping network addresses and/or ports in respective paths towards target devices.).
Regarding claim(s) 11 and 20, Jain combined with Nelson discloses the limitations set forth in claim 1 which are substantially identical to claim(s) 11 and 20 from the perspective of the computer system and non-transitory computer-readable storage medium. Jain discloses a processor and a machine-readable storage medium (see Jain [Pg. 3, ¶0035], “… system 400 includes a processor 402 and a machine-readable storage medium 404.”; Note: It is understood, to one of ordinary skill in the art, that there is inherently a plurality of ports in the system in order to operate the invention as disclosed (i.e., specific port blocking)).
Regarding claim(s) 12-14, Jain combined with Nelson discloses the limitations set forth in claim(s) 2-4 which are substantially identical to claim(s) 2-4 from the perspective of the computer system and non-transitory computer-readable storage medium.
Claim(s) 6, 7, 16, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. (US 2021/0306252 A1), hereinafter “Jain” in view of Nelson et al. (US 2023/0216779 A1), hereinafter “Nelson” in further view of Wang et al. (US 2023/0208757 A1), hereinafter “Wang”.
Regarding claim 6, Jain combined with Nelson discloses the method of claim 1.
Jain combined with Nelson does not explicitly disclose wherein the payload of the probe packet comprises a plurality of data sets, wherein a respective data set includes information, which includes an address, associated with a device on the trace path.
Wang discloses wherein the payload of the probe packet comprises a plurality of data sets, wherein a respective data set includes information associated with a network device included in the trace path, and wherein the information includes an address of the network device in the trace path (see Wang [Pg. 8, ¶0126], “For example, the identifier of the first network device may be encapsulated in the TLV format into the data part in the probe packets of the structure shown in FIG. 6. The TLV includes a tag in the TLV, a length of the identifier of the first network device, and the identifier of the first network device.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate the probe packet comprising data sets as detailed by Wang, onto the combined system of Jain and Nelson, in order to increase tunnel detection accuracy and improve running compatibility (see Wang [Pg. 1-2, ¶0010], “According to the packet transmission method provided in this embodiment of this application … tunnel detection accuracy is improved … which helps improve running compatibility and friendliness of a network.”)
Regarding claim 7, Jain combined with Nelson and Wang discloses the method of claim 1, wherein the payload of the probe packet comprises one of:
A type-length-value (TLV) encoded field comprising the addresses corresponding to the devices on the trace path (see Wang [Pg. 8, ¶0126], “For example, the identifier of the first network device may be encapsulated in the TLV format into the data part in the probe packets of the structure shown in FIG. 6. The TLV includes a tag in the TLV, a length of the identifier of the first network device, and the identifier of the first network device.”); and
A set of TLVs, each comprising an address corresponding to a device on the trace path (see Wang [Pg. 13, ¶0200], “The PE 1 finds that there is the addition indication ow in the probe packet, searches the data part in the probe packet for the MAC address of the PE 1 stored in the TLV format, adds the MAC address of the PE 1 to a destination MAC address in the response packet of the probe packet, encapsulates the response packet of the probe packet, and sends the response packet to the egress device of the tunnel through the EVPN VPWS tunnel.”; Note: It is understood with the addition function, there are multiple sets of identifying information in TLV format.).
Regarding claim(s) 16 and 17, Jain combined with Nelson and Wang discloses the limitations set forth in claim(s) 6 and 7 which are substantially identical to claim(s) 16 and 17 from the perspective of the computer system and non-transitory computer-readable medium.
Claim(s) 5, 8-10, 15, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Jain et al. (US 2021/0306252 A1), hereinafter “Jain” in view of Filsfils et al. (US 2022/0329518 A1), hereinafter “Filsfil”.
Regarding claim 5, Jain combined with Nelson discloses the method of claim 1.
Jain combined with Nelson does not explicitly disclose wherein determining the trace path further comprises determining presence of a remote network device not supporting the trace path based on port information indicated in the payload of the probe packet.
Filsfil discloses wherein determining the trace path further comprises determining presence of a remote network device not supporting the trace path based on port information indicated in the payload of the probe packet (see Filsfil [Pg. 10, ¶0087], “The PTI flag in the ELV field may be set by the source node to trigger the path tracing behavior at each of the midpoint nodes along the path. The PTI flag may be used to indicate the presence of path tracing TLVs within the probe message. The path tracing TLVs may cause the midpoint nodes receiving the probe message to record their MCD in the MCD stack of the probe message.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate a path tracing indicator in the probe message as detailed by Filsfil, onto the combined system of Jain and Nelson, in order to improve system visibility on a per-hop basis allowing for detailed path analysis (see Filsfil [Pg. 1, ¶0003-4], “Further, to improve performance of their networks, it can be desirable for network operators to characterize their networks in terms of delay and load on a per-hop basis. … These solutions would allow network operators to verify various characteristics of their networks while allowing network operators to identify and trouble any routing problems.”).
Regarding claim 8, Jain combined with Nelson discloses the method of claim 1.
Jain combined with Nelson does not explicitly disclose wherein, in response to determining that the network device is not the originating network device, the method further comprises incrementing a hop count value included in the probe packet.
Filsfil discloses wherein, in response to determining that the network device is not the originating network device, the method further comprises incrementing a hop count value included in the probe packet (see Filsfil [Pg. 3, ¶0034], “Upon receipt of an SR packet, an SR-aware router or node will set the destination address to the address of the next segment in the SR list, and decrease the Segments Left (SL) counter.”; also see Filsfil [Pg. 10, ¶0088], “For example, the MCD can include node addresses/identifiers and packet counters.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate a counter as detailed by Filsfil, onto the combined system of Jain and Nelson, in order to track the allowed traversals for the probe packet commonly used in the art in various forms including TTL counters .
Regarding claim 9, Jain combined with Nelson and Filsfil discloses the method of claim 8, further comprising:
Determining whether a maximum length of the probe packet is reached based on the hop count value in the probe packet (see Filsfil [Pg. 3, ¶0034], “When the packet reaches the last SR hop or segment in the SR list, …”); and
In response determining that the maximum length of the probe packet is reached, refraining from appending the local address in the payload of the probe packet (see Filsfil [Pg. 3, ¶0034], “Depending on the value of a flag in the header, the SRH can be stripped by the last SR hop or segment so the destination receives a vanilla IPv6 packet.”).
Regarding claim 10, Jain combined with Nelson discloses the method of claim 1.
Jain combined with Nelson does not explicitly disclose wherein the probe packet includes an indicator indicating support of the trace path.
Filsfil discloses wherein the probe packet includes an indicator indicating support of the trace path (see Filsfil [Pg. 10, ¶0087], “The PTI flag in the ELV field may be set by the source node to trigger the path tracing behavior at each of the midpoint nodes along the path. The PTI flag may be used to indicate the presence of path tracing TLVs within the probe message. The path tracing TLVs may cause the midpoint nodes receiving the probe message to record their MCD in the MCD stack of the probe message.”). It would have been obvious to one of ordinary skill in the art, before the effective filing date of the claimed invention, to incorporate a path tracing indicator in the probe message as detailed by Filsfil, onto the combined system of Jain and Nelson, in order to improve system visibility on a per-hop basis allowing for detailed path analysis (see Filsfil [Pg. 1, ¶0003-4], “Further, to improve performance of their networks, it can be desirable for network operators to characterize their networks in terms of delay and load on a per-hop basis. … These solutions would allow network operators to verify various characteristics of their networks while allowing network operators to identify and trouble any routing problems.”).
Regarding claim(s) 15, 18, and 19, Jain, Nelson and Filsfil discloses the limitations set forth in claim(s) 5, 8, and 9 which are substantially identical to claim(s) 15, 18, and 19 from the perspective of the computer system and non-transitory computer-readable medium.
Conclusion
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 JIA H DENG whose telephone number is (703)756-4545. The examiner can normally be reached M-F 9:00 am - 5:00pm.
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.
/J.D./Examiner, Art Unit 2462
/YEMANE MESFIN/Supervisory Patent Examiner, Art Unit 2462
Prosecution Insights