DETAILED ACTION
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 .
Status of Claims
Claims 1-20 are pending in the instant application.
Priority
Acknowledgment is made of applicant's claim for foreign priority under 35 U.S.C. 119(a)-(d). The certified copy has been filed in Foreign Application Priority No. IN-202441057710, filed on July 30, 2024.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on December 22, 2025 was filed before the mailing of a First Office Action on the Merits. The information disclosure statement is being considered by the examiner.
Claim Objections
Claim 12 is objected to because of the following informalities: Claim 12 appears to contain a typographical error and a duplicated word, specifically claim reciting “Internel Protocol (IP) Protocol field…”. The claim should recite instead, “Internet Protocol (IP) . Appropriate correction is required.
Claim 17 is objected to because of the following informalities: Claim 17 appears to contain a typographical error (second VTP) and is inconsistent with the term “VTEP” used elsewhere in the claims (e.g., claim 11) and the specification. Applicant is required to cancel or amend "VTP" in claim 17 to consistently recite "VTEP" (or clarify if a different term was intended). Appropriate correction is required.
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.
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-3, 7-10, 12-13, 18 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Desai et al. [Desai] (US 2021/0234898 A1) in view of Nedeltchev et al. [Ned] (US 2013/0322258 A1), and in further view of Yadav et al. [Yadav] (US 2019/0379572 A1).
Regarding claim 1, Desai discloses a non-transitory machine-readable storage medium storing instructions that upon execution cause a first network device in a first domain to (Desai: See Fig. 6A-6B, ¶ 0216, processor where software instructions are incorporated into the actual processor design. ¶ 0219, a computer-readable medium in connection with the necessary hardware components, such as the processor 610, bus 605, output device 635, and so forth, to carry out the function): the first virtual tunnel header containing a first policy identifier (Desai: ¶ 0056; Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification (e.g., a classID, etc.) of a respective source SGT or EPG in the respective source domain and the virtual network identification of the respective destination domain; [Examiner’s Notes: Desai teaches that i-VXLAN packets (virtual tunnel headers) carry a classID (SGT/EPG) that identifies a source security group or endpoint group. The classID is a policy identifier contained in the virtual tunnel header]); receive, at the first network device, a response packet comprising a second virtual tunnel header and probe information (Desai: ¶ 0192, At step 572, the second domain provides the first domain with a response to the data request, in accordance with the access policy. ¶ 0057, Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification; [Examiner’s Notes: Desai discloses that the first domain (consumer domain) receives a response from the second domain (provider domain). The response packet crosses domains and would carry a virtual tunnel header (i-VXLAN) with policy identification. The first network device in the first domain receives this response]), the first gateway device and the second gateway device being in a path of a virtual tunnel between the first network device in the first domain and a second network device in the second domain (Desai: ¶ 0033, “gateway” refers to router(s) connecting a domain with other domains. Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services. ¶ 0214, Respective Gateways 510B and 511B then advertise routes for Endpoints 510F and 511F to each other. ¶ 0024, Overlay connectivity automation is achieved by using border gateway protocol over an Ethernet virtual private network (BGP-EVPN) for control plane services and virtualized network infrastructures (e.g., VxLAN, etc.) for data plane services. ¶ 0180, Consumer Domain 510 is a networking domain containing Access Engine 520 and User 540. ¶ 0183, Access Point 550 can handle requests attempting to access data in Provider Domain 511; [Examiner’s Notes: Desai teaches gateway devices (510B in Consumer Domain 510, 511B in Provider Domain 511) in a path of virtual overlay tunnels (VXLAN/EVPN) between network devices in the first domain and network devices in the second domain. The gateways are in the data plane path for traffic crossing domains.]).
Desai does not explicitly disclose send, from the first network device to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request; the probe information containing a translated policy identifier field to store any translated policy identifier produced by a second gateway device of the second domain; and initiate, by the first network device, an update of a trace record by adding a policy identifier contained in the translated policy identifier field to support diagnostics relating to a policy identifier mistranslation.
However, Ned teaches send, from the first network device to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request (Ned: ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request). ¶ 0022, R1, which, as a head-end node of tunnel 305, inserts (encapsulates) the message 310 into the tunnel; [Examiner’s Notes: Ned teaches sending a trace packet (message 310 as a trace request) through a network device (R1) that encapsulates it in a tunnel (virtual tunnel header) and forwards it toward a destination. Trace request constitutes a probe request requesting responses from nodes along the path]);
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, send, from the first network device to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request, as taught by Ned, since doing so would have achieved enabling trace packets to traverse cross-domain gateway boundaries which allow operators to diagnose connectivity while simultaneously observing hoe policy identifiers are handled at each domain boundary.
Desai and Ned do not explicitly disclose the probe information containing a translated policy identifier field to store any translated policy identifier produced by a second gateway device of the second domain; and initiate, by the first network device, an update of a trace record by adding a policy identifier contained in the translated policy identifier field to support diagnostics relating to a policy identifier mistranslation.
However, Yadav teaches the probe information containing a translated policy identifier field to store any translated policy identifier produced by a second gateway device of the second domain (Yadav: ¶ 0179, translate policies defined for security groups in the second network 504 into policies defined by endpoint groups in the first network 502; [Examiner’s Notes: Yadav teaches translating policies between different network domains, i.e., security groups to endpoint groups, which produces a translated policy identifier]); and initiate, by the first network device, an update of a trace record by adding a policy identifier contained in the translated policy identifier field to support diagnostics relating to a policy identifier mistranslation (Yadav: ¶ 0184, determine mismatches, e.g. as part of correlated fabric data, in policies between different networks. ¶ 0185, generate a policy mismatch event. The policy mismatch event can be used to alert an administrator of policy mismatches across networks. ¶ 0192, correlates the first fabric data with the normalized second fabric data to create correlated fabric data. ¶ 0198, allow the master microprocessor 804 to efficiently perform routing computations, network diagnostics, security functions, etc.; [Examiner’s Notes: Yadav teaches determining policy mismatches, generating mismatch events, and correlating fabric data, collectively constituting updating a record with translated policy information to support diagnostics relating to policy mistranslation. The correlation of fabric data functions as updating a trace record by adding the translated policy identifier, and the mismatch detection constitutes diagnosing policy identifier mistranslation]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai and Ned by further including, the probe information containing a translated policy identifier field to store any translated policy identifier produced by a second gateway device of the second domain; and initiate, by the first network device, an update of a trace record by adding a policy identifier contained in the translated policy identifier field to support diagnostics relating to a policy identifier mistranslation, as taught by Yadav, since doing so would have achieved the desirable result of providing an end-to-end visibility into policy transformations at domain gateways and enable rapid identification of policy mistranslations.
Regarding claim 2, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 1.
Desai does not explicitly disclose wherein the response packet comprises information of a policy action applied at the second network device in the second domain based on a policy identified by the policy identifier contained in the translated policy identifier field, and wherein the update adds the information of the policy action to the trace record.
However, Yadav teaches wherein the response packet comprises information of a policy action applied at the second network device in the second domain based on a policy identified by the policy identifier contained in the translated policy identifier field (Yadav: ¶ 0185, a policy mismatch event can include indicators of actual mismatches between policies and subsequently be used to alert an administrator of the actual mismatches…the cross-domain assurance system 506 can provide insight into exact semantics (e.g. forwarding, policy, etc.) that may be causing communication (or lack thereof) between two or more endpoints in each domain; [Examiner’s Notes: Yadav teaches that diagnostic events include indicators of actual policy states and semantics applied during forwarding decisions, which, when included in the response and recorded in the mismatch event, constitute a response packet comprising policy action information that updates the trace record.]), and wherein the update adds the information of the policy action to the trace record (Yadav: ¶ 0192, cross-domain assurance system 506 can compare policies in the second network with policies in the first network, using the first fabric data and the normalized second fabric data, to determine whether the policies are compatible with each other; [Examiner’s Notes: Yadav teaches that the system evaluates policy compatibility across different networks and records these policy enforcement actions directly within diagnostic logs to track execution history.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Yadav, since doing so would have achieved the desirable result of generating a comprehensive audit trail of path reachability and policy execution.
Regarding claim 3, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 2.
Desai does not explicitly disclose wherein the trace packet is a first trace packet, and the response packet is a first response packet, the first trace packet comprising an Internet Protocol (IP) header having a time to live (TTL) field set to a first value, and wherein the probe information of the first response packet comprises a probe stop indication to indicate that the first trace packet has reached an egress edge network device, the egress edge network device being the second network device.
However, Ned further teaches wherein the trace packet is a first trace packet, and the response packet is a first response packet, the first trace packet comprising an Internet Protocol (IP) header having a time to live (TTL) field set to a first value, and wherein the probe information of the first response packet comprises a probe stop indication to indicate that the first trace packet has reached an egress edge network device, the egress edge network device being the second network device (Ned: ¶ 0019, trace process 248 can discover a path and/or measure transit delay of packets across networks (e.g., IP networks) via trace requests and trace responses. ¶ 0022, the message traverses the tunnel (e.g., via R2 and R3) to the tail-end node R4. ¶ 0026, a traceroute (a time-to-live or TTL-based ping request). ¶ 0029, generate and transmit a trace response message 415 which may comprise the monitoring and statistical collection called for in the trace request 410 (or, simply, a TTL error message)… trace response message 415 comprises a header…response payload that may comprise node information response blocks. ¶ 0032, R4 may eventually receive both the in-tunnel trace request 410a as well as the out-of-tunnel trace request 410b, and may respond to each independently; [Examiner’s Notes: Ned teaches a first trace packet (trace request 410) comprising an IP header with a TTL field set to a first value, and a corresponding first response packet (trace response message 415) containing a probe stop indication that confirms the packet has reached the egress edge network device (tail-end node R4).]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Ned, since doing so would have achieved the desirable result of identifying the specific gateway processing a packet and correlating policy identifier changes with precise network positions.
Regarding claim 7, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 2.
Desai further discloses wherein the policy action comprises one of dropping the trace packet or forwarding the trace packet (Desai: ¶ 0212, Dom2, or Consumer Domain 510, associated with Tenant 1 510D (e.g., either of tenants "1,2") are allowed access, See Table 1. ¶ 0064, These contract rule actions may be permitted or redirected to, for example, an L4L7 graph inside the ACI fabric; [Examiner’s Notes: Desai explicitly discloses “Allow” and “Deny” as policy action outcomes in its filter table. “Allow” corresponds to forwarding the packet, and “Deny” corresponds to dropping the packet. The claim limitation specifies the policy action as one of dropping or forwarding, which is precisely what Desai’s Allow/Deny actions represent.]).
Regarding claim 8, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 1.
Desai further discloses wherein the first virtual tunnel header comprises a Virtual eXtensible LAN (VXLAN) header (Desai: ¶ 0056, Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification. ¶ 0024, virtualized network infrastructures (e.g., VxLAN, etc.) for data plane services; [Examiner’s Notes: Desai explicitly discloses i-VXLAN packets and VXLAN as the data plane overlay technology, i-VXLAN is a variant of VXLAN. i-VxLAN packets with their tunnel headers encompasses “a VXLAN header”]) , and the virtual tunnel between the first gateway device and the second gateway device comprises a VXLAN tunnel (Desai: ¶ 0024, virtualized network infrastructures (e.g., VxLAN, etc.) for data plane services. ¶ 0033, Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services; [Examiner’s Notes: Desai discloses VXLAN as the data plane overlay between domains, with gateways as the data plane endpoints. The virtual tunnel between the two gateways (510B and 511B) is implemented using VXLAN, constituting a VXLAN tunnel]).
Regarding claim 9, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 8.
Desai further discloses wherein the first and second domains comprise Ethernet Virtual Private Network (EVPN) domains (Desai: ¶ 0024, Overlay connectivity automation is achieved by using border gateway protocol over an Ethernet virtual private network (BGP-EVPN) for control plane services and virtualized network infrastructures (e.g., VxLAN, etc.) for data plane services. As a result, a provider service in a first domain can be exposed to many consumers in other domains, and vice versa; [Examiner’s Notes: Desai discloses that both the first and second domains are EVPN domains, utilizing BGP-EVPN for control plane services and VXLAN for data plane services to connect the consumer and provider domains.]).
Regarding claim 10, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 8.
Desai further discloses wherein the response packet is from the second network device in the second domain, and the response packet from the second network device passed through the second gateway device over the virtual tunnel to the first gateway device (Desai: ¶ 0192, At step 572, the second domain provides the first domain with a response to the data request, in accordance with the access policy. ¶ 0214, Respective Gateways 510B and 511B then advertise routes for Endpoints 510F and 511F to each other. ¶ 0033, Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services; [Examiner’s Notes: Desai discloses that gateways function as data plane endpoints for traffic between domains, a response originating from a network device in the provider domain must pass through its local gateway and over an overlay tunnel to the consumer domain's gateway to achieve cross-domain delivery.])
Regarding claim 12, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 1.
Desai further discloses wherein the probe request of the trace packet comprises a first inner packet encapsulated by the first virtual tunnel header (Desai: ¶ 0056, Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification; [Examiner’s Notes: Desai discloses packets with encapsulated structure, i.e., i-VXLAN packets have inner and outer headers.])
Desai does not explicitly disclose the first inner packet comprises an Internel Protocol (IP) Protocol field set to an experimental code point.
However, Ned teaches the first inner packet comprises an Internel Protocol (IP) Protocol field set to an experimental code point (Ned: ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request); [Examiner’s Notes: Ned teaches that specialized trace request packets need unique identification to separate them from normal data traffic. These packets use a non-standard protocol number in their IP header for this distinction. Protocols waiting for an official number use experimental code points in the IP Protocol field as standard practice.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the first inner packet comprises an Internet Protocol (IP) Protocol field set to an experimental code point, as taught by Ned, since doing so would have achieved the desirable result of efficiently distinguishing specialized diagnostic traffic from normal data packets without waiting for a formally assigned protocol number.
Regarding claim 13, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 12.
Desai does not explicitly disclose wherein the probe information of the response packet that is responsive to the trace packet comprises a second inner packet encapsulated by the second virtual tunnel header, and the second inner packet comprises an IP Protocol field set to the experimental code point.
However, Ned further teaches wherein the probe information of the response packet that is responsive to the trace packet comprises a second inner packet encapsulated by the second virtual tunnel header, and the second inner packet comprises an IP Protocol field set to the experimental code point (Ned: ¶ 0029, trace response message 415 comprises a header (e.g., responder version, session, and request information) and a response payload. ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request); [Examiner’s Notes: Ned teaches that trace response messages use the same specialized format as the corresponding trace request. The response to a media trace request uses the same protocol identification (experimental code point) as the request. The response packet’s inner packet carries the same experimental protocol code point, ensuring symmetric identification.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the probe information of the response packet that is responsive to the trace packet comprises a second inner packet encapsulated by the second virtual tunnel header, and the second inner packet comprises an IP Protocol field set to the experimental code point, as taught by Ned, since doing so would have achieved the desirable result of having symmetric protocol identification ensuring that both the trace request and its response are consistently identifiable by network devices. Further, consistent identification of both request and response packets enables end-to-end correlation of trace transactions and ensures policy identifier information in responses is properly processed by the originating device.
Regarding claim 18, Desai discloses a method comprising: the first virtual tunnel header containing a first group-based policy identifier (GBP ID) (Desai: ¶ 0056; Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification (e.g., a classID, etc.) of a respective source SGT or EPG in the respective source domain and the virtual network identification of the respective destination domain; [Examiner’s Notes: Desai teaches that i-VXLAN packets (virtual tunnel headers) carry a classID (SGT/EPG) that identifies a source security group or endpoint group. The classID is a policy identifier contained in the virtual tunnel header]); receiving, at the first network device, a response packet comprising a second virtual tunnel header and probe information (Desai: ¶ 0192, At step 572, the second domain provides the first domain with a response to the data request, in accordance with the access policy. ¶ 0057, Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification; [Examiner’s Notes: Desai discloses that the first domain (consumer domain) receives a response from the second domain (provider domain). The response packet crosses domains and would carry a virtual tunnel header (i-VXLAN) with policy identification. The first network device in the first domain receives this response]), the first gateway device and the second gateway device being in a path of a virtual tunnel between the first network device in the first domain and a second network device in the second domain (Desai: ¶ 0033, “gateway” refers to router(s) connecting a domain with other domains. Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services. ¶ 0214, Respective Gateways 510B and 511B then advertise routes for Endpoints 510F and 511F to each other. ¶ 0024, Overlay connectivity automation is achieved by using border gateway protocol over an Ethernet virtual private network (BGP-EVPN) for control plane services and virtualized network infrastructures (e.g., VxLAN, etc.) for data plane services. ¶ 0180, Consumer Domain 510 is a networking domain containing Access Engine 520 and User 540. ¶ 0183, Access Point 550 can handle requests attempting to access data in Provider Domain 511; [Examiner’s Notes: Desai teaches gateway devices (510B in Consumer Domain 510, 511B in Provider Domain 511) in a path of virtual overlay tunnels (VXLAN/EVPN) between network devices in the first domain and network devices in the second domain. The gateways are in the data plane path for traffic crossing domains.]).
Desai does not explicitly disclose sending, from a first network device in a first domain to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request, the probe information containing a translated GBP ID field to store a translated GBP ID produced by a second gateway device of the second domain, updating a trace record by adding the translated GBP ID contained in the translated GBP ID field; and applying a remediation action to address a GBP ID mistranslation identified based on the trace record.
However, Ned teaches sending, from a first network device in a first domain to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request (Ned: ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request). ¶ 0022, R1, which, as a head-end node of tunnel 305, inserts (encapsulates) the message 310 into the tunnel; [Examiner’s Notes: Ned teaches sending a trace packet, comprising a virtual tunnel header and a probe request, by disclosing that a head-end node encapsulates an application-layer trace or traceroute request into a tunnel and forwards it toward a destination to elicit responses from nodes along the path.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, sending, from a first network device in a first domain to a first gateway device of the first domain, a trace packet targeted to a destination device in a second domain, the trace packet comprising a first virtual tunnel header and a probe request, as taught by Ned, since doing so would have achieved enabling trace packets to traverse cross-domain gateway boundaries which allow operators to diagnose connectivity while simultaneously observing how policy identifiers are handled at each domain boundary.
Desai and Ned do not explicitly disclose the probe information containing a translated GBP ID field to store a translated GBP ID produced by a second gateway device of the second domain, updating a trace record by adding the translated GBP ID contained in the translated GBP ID field; and applying a remediation action to address a GBP ID mistranslation identified based on the trace record.
However, Yadav teaches the probe information containing a translated GBP ID field to store a translated GBP ID produced by a second gateway device of the second domain (Yadav: ¶ 0179, translate policies defined for security groups in the second network 504 into policies defined by endpoint groups in the first network 502; [Examiner’s Notes: Yadav teaches translating policies between different network domains, i.e., security groups to endpoint groups, which produces a translated policy identifier]), updating a trace record by adding the translated GBP ID contained in the translated GBP ID field; and applying a remediation action to address a GBP ID mistranslation identified based on the trace record (Yadav: ¶ 0185, if a policy mismatch is identified, then the cross-domain assurance system 506 can generate a policy mismatch event. The policy mismatch event can be used to alert an administrator of policy mismatches across networks. Further, a policy mismatch event can include indicators of actual mismatches between policies … the cross-domain assurance system 506 can provide insight into exact semantics (e.g. forwarding, policy, etc.) that may be causing communication (or lack thereof) between two or more endpoints in each domain. ¶ 0198, allow the master microprocessor 804 to efficiently perform routing computations, network diagnostics, security functions, etc.; [Examiner’s Notes: Yadav teaches a cross-domain assurance system that updates its trace records with a translated GBP ID when a mapping inconsistency across networks is identified. These updated records pinpoint the exact semantic and forwarding mismatches causing communication issues between endpoints. The system then automatically triggers a remediation action, such as generating an administrative alert or applying policy adjustments, to resolve the conflict.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai and Ned by further including, the probe information containing a translated GBP ID field to store a translated GBP ID produced by a second gateway device of the second domain, updating a trace record by adding the translated GBP ID contained in the translated GBP ID field; and applying a remediation action to address a GBP ID mistranslation identified based on the trace record, as taught by Yadav, since doing so would have achieved the desirable result of automating detection, recording, and alerting of GBP ID mistranslations which enable proactive resolution of cross-domain policy failures before they cause sustained communication outages.
Regarding claim 20, Desai, Ned and Yadav teach the method of claim 18.
Desai does not explicitly disclose further comprising: determining, based on a probe stop indication in the probe information, that the trace packet reached the second network device, wherein the probe stop indication was added by the second network device responsive to receipt of the trace packet by the second network device.
However, Ned teaches further comprising: determining, based on a probe stop indication in the probe information, that the trace packet reached the second network device, wherein the probe stop indication was added by the second network device responsive to receipt of the trace packet by the second network device (Ned: ¶ 0032, R4 may eventually receive both the in-tunnel trace request 410a as well as the out-of-tunnel trace request 410b, and may respond to each independently. Claim 4, the out-of-tunnel trace request causes each subsequent node along a path of the tunnel to i) generate and transmit a respective trace response to the head-end node, and ii) transmit the out-of-tunnel trace request to any additional subsequent node along the path of the tunnel until the out-of-tunnel trace request reaches the tail-end node. ¶ 0022, the message traverses the tunnel (e.g., via R2 and R3) to the tail-end node R4; [Examiner’s Notes: Ned teaches that the tail-end node (second network device) receives the trace request and responds independently, effectively terminating the trace chain because no further nodes forward the trace packet. This independent, terminal response constitutes a probe stop indication added by the second network device responsive to receiving the trace packet. The head-end node receives this final response to determine that the trace packet successfully reached the second 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 modify the teachings of Desai by further including, further comprising: determining, based on a probe stop indication in the probe information, that the trace packet reached the second network device, wherein the probe stop indication was added by the second network device responsive to receipt of the trace packet by the second network device, as taught by Ned, since doing so would have achieved the desirable result of verifying seamless, multi-domain trace packet delivery via the probe stop indication, which enables the originating device to close the diagnostic loop by correlating the completed trace with the corresponding translated policy identifiers.
Claims 4-6, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Desai in view of Ned and Yadav, and in further view of PANDEY et al. [Pandey] (US 2025/0219936 A1).
Regarding claim 4, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 3.
Desai does not explicitly disclose wherein the instructions upon execution cause the first network device to: set a TTL field in an IP header in a second trace packet to a second value that is less than the first value; send, from the first network device to the first gateway device, the second trace packet targeted to the destination device in the second domain, the second trace packet comprising a virtual tunnel header and a probe request, the virtual tunnel header of the second trace packet containing the first policy identifier, wherein the second trace packet is sent before the first trace packet; and receive, at the first network device, a second response packet comprising a virtual tunnel header and probe information, the probe information of the second response packet containing a translated policy identifier field, and the probe information of the second response packet is without the probe stop indication, wherein the sending of the first trace packet is responsive to the probe information of the second response packet being without the probe stop indication.
However, Ned teaches wherein the instructions upon execution cause the first network device to: set a TTL field in an IP header in a second trace packet to a second value that is less than the first value; send, from the first network device to the first gateway device, the second trace packet targeted to the destination device in the second domain, the second trace packet comprising a virtual tunnel header and a probe request, the virtual tunnel header of the second trace packet containing the first policy identifier, wherein the second trace packet is sent before the first trace packet (Ned: ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request. Claim 4, the out-of-tunnel trace request causes each subsequent node along a path of the tunnel to i) generate and transmit a respective trace response to the head-end node, and ii) transmit the out-of-tunnel trace request to any additional subsequent node along the path of the tunnel until the out-of-tunnel trace request reaches the tail-end node. ¶ 0022, R1, which, as a head-end node of tunnel 305, inserts (encapsulates) the message 310 into the tunnel (e.g., established by tunnel process 246); [Examiner’s Notes: Ned teaches a trace packet structure utilizing virtual tunnel encapsulation alongside standard traceroute methodologies to monitor network paths. Under this framework, multiple trace packets are sent iteratively, allowing a second packet with a lower TTL value to be transmitted prior to a first packet with a higher TTL value]); and receive, at the first network device, a second response packet comprising a virtual tunnel header and probe information, the probe information of the second response packet is without the probe stop indication, wherein the sending of the first trace packet is responsive to the probe information of the second response packet being without the probe stop indication (Ned: ¶ 0026, no trace response is generated, but, instead, message 310 is merely forwarded on to R4 since the nodes within tunnel 305 are unaware of any encapsulated trace requests. Claim 4, the out-of-tunnel trace request causes each subsequent node along a path of the tunnel to i) generate and transmit a respective trace response to the head-end node, and ii) transmit the out-of-tunnel trace request to any additional subsequent node along the path of the tunnel until the out-of-tunnel trace request reaches the tail-end node; [Examiner’s Notes: Ned teaches that intermediate nodes within a tunnel do not generate responses for in-tunnel trace requests, leaving their probe information without a probe stop indication. Consequently, sending subsequent trace packets is directly triggered by prior responses that lack probe stop indications].
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Ned, since doing so would have achieved the desirable result of efficiently mapping the tunnel's internal architecture from the outside-in by sequentially deploying increasing-TTL trace packets to systematically isolate connectivity failures at exact domain boundaries without relying on intermediate node responses.
Desai and Ned do not explicitly disclose the probe information of the second response packet containing a translated policy identifier field.
However, Pandey teaches the probe information of the second response packet containing a translated policy identifier field (Pandey: ¶ 0025, the second gateway may decapsulate the EVPN MPLS packet…may encapsulate the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload with the outer Ethernet header, the outer IP header, the outer UDP header, and the outer VXLAN header to generate the VXLAN packet. ¶ 0026, The second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include the TPID and the GPB-Id and thus may preserve the source TSI group identifier of the VXLAN packet; [Examiner’s Note: Pandey teaches that when a response packet passes through the second gateway, the GPB-Id (policy identifier) is preserved in the VXLAN header of the re-encapsulated packet. The response packet received by the first network device this contains the translated/preserved policy identifier field (GPB-Id) in its virtual tunnel header, constituting probe information containing a translated policy identifier field.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai and Ned by further including, the probe information of the second response packet containing a translated policy identifier field, as taught by Pandey, since doing so would have achieved the desirable result of guaranteeing the translated policy identifier is available in the second response packet to detect mistranslations at intermediate gateway boundaries.
Regarding claim 5, modified Desai teaches the non-transitory machine-readable storage medium of claim 4.
Desai does not explicitly disclose wherein the probe information of the first response packet comprises a probe stop indicator set to a first value to provide the probe stop indication, and the probe information of the second response packet comprises the probe stop indicator set to a different second value to indicate that the second response packet is without the probe stop indication.
However, Ned teaches wherein the probe information of the first response packet comprises a probe stop indicator set to a first value to provide the probe stop indication, and the probe information of the second response packet comprises the probe stop indicator set to a different second value to indicate that the second response packet is without the probe stop indication (Ned: ¶ 0026, a traceroute (a time-to-live or TTL-based ping request). Claim 4, the out-of-tunnel trace request causes each subsequent node along a path of the tunnel to i) generate and transmit a respective trace response to the head-end node, and ii) transmit the out-of-tunnel trace request to any additional subsequent node along the path of the tunnel until the out-of-tunnel trace request reaches the tail-end node. ¶ 0029, generate and transmit a trace response message 415 which may comprise the monitoring and statistical collection called for in the trace request 410 (or, simply, a TTL error message)… trace response message 415 comprises a header… response payload that may comprise node information response blocks…a standard ICMP ping and TTL error message; [Examiner’s Notes: Ned teaches the use of standard ICMP packets where a destination node's terminal response type serves as a probe stop indicator set to a first value to convey a probe stop indication, whereas an intermediate node's TTL-expired error message serves as a different second value indicating the absence of a probe stop indication, whereas a terminal tail-end response conveys a first value providing the probe stop indication.])
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Ned, since doing so would have achieved the desirable result of integrating standard protocol signaling, thereby enabling efficient differentiation between intermediate node traversal and final packet termination.
Regarding claim 6, modified Desai teaches the non-transitory machine-readable storage medium of claim 4.
Desai does not explicitly disclose wherein the instructions upon execution cause the first network device to: initiate, by the first network device, a further update of the trace record by adding a policy identifier contained in the translated policy identifier field of the second response packet.
However, Pandey teaches wherein the instructions upon execution cause the first network device to: initiate, by the first network device, a further update of the trace record by adding a policy identifier contained in the translated policy identifier field of the second response packet (Pandey: ¶ 0026, the second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include the TPID and the GPB-Id and thus may preserve the source TSI group identifier of the VXLAN packet. ¶ 0025, the second gateway may decapsulate the EVPN MPLS packet…may encapsulate the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload with the outer Ethernet header, the outer IP header, the outer UDP header, and the outer VXLAN header to generate the VXLAN packet. ¶ 0028, provide the packet to a gateway of the first data center, and the gateway may decapsulate the packet to generate an EVPN MPLS packet with the TSI group identifier; [Examiner’s Note: Pandey teaches that the re-encapsulated VXLAN packet preserves the translated policy identifier (GPB-Id) within its header, thereby supplying the exact identifier required for the first network device to update the trace record.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Pandey, since doing so would have achieved the desirable result of enabling comprehensive, end-to-end telemetry and hop-by-hop visibility across heterogeneous network domains.
Regarding claim 11, Desai, Ned and Yadav teach the non-transitory machine-readable storage medium of claim 10.
Desai does not explicitly disclose wherein the first network device comprises a first VXLAN tunnel endpoint (VTEP), and the second network device comprises a second VTEP.
However, Pandey teaches wherein the first network device comprises a first VXLAN tunnel endpoint (VTEP), and the second network device comprises a second VTEP (Pandey: ¶ 0017, the first network device of the first data center may correspond to Leaf 11. ¶ 0026, The second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include the TPID and the GPB-Id and thus may preserve the source TSI group identifier of the VXLAN packet. ¶ 0020, the VXLAN packet may include an outer Ethernet header, an outer Internet protocol (IP) header, an outer user datagram protocol (UDP) header, an outer VXLAN header. See claims 2-3; [Examiner’s Note: Pandey teaches that both the first network device, Leaf 11, and the second network device generate and receive VXLAN packets with outer VXLAN headers. A network device that encapsulates and decapsulates VXLAN packets is, by definition, a VXLAN Tunnel Endpoint (VTEP). Both devices function as VTEPs establishing and maintaining VXLAN tunnels]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Pandey, since doing so would have achieved the desirable result of maximizing network throughput and reducing packet encapsulation latency by enabling direct, edge-to-edge VXLAN tunnel encapsulation and decapsulation between the first and second network devices.
Regarding claim 19, Desai, Ned and Yadav teach the method of claim 18.
Desai does not explicitly disclose wherein the updating of the trace record comprises adding information of a policy action performed by the second network device according to a group-based policy identified by the translated GBP ID.
However, Pandey teaches wherein the updating of the trace record comprises adding information of a policy action performed by the second network device according to a group-based policy identified by the translated GBP ID (Pandey: ¶ 0027, the second network device (e.g., Leaf 21) may apply the policy associated with the TPID and the GPB-Id (e.g., the TSI group identifier) of the VXLAN packet.; [Examiner’s Note: Pandey teaches that the second network device applies a policy specifically associated with the GPB-Id (group-based policy identifier). The policy action is performed “according to” the group-based policy identified by the GPB-Id (translated GBP ID)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, wherein the updating of the trace record comprises adding information of a policy action performed by the second network device according to a group-based policy identified by the translated GBP ID, as taught by Pandey, since doing so would have achieved the desirable result of providing complete end-to-end visibility and verification of policy enforcement across different network domains.
Claims 14, 15 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Desai in view of Ned, and in further view of Pandey.
Regarding claim 14, Desai discloses an egress edge network device of a first domain, the egress edge network device comprising: a processor; and a non-transitory storage medium comprising instructions executable on the processor to (Desai: See Fig. 6A-6B, ¶ 0216, processor where software instructions are incorporated into the actual processor design. ¶ 0219, a computer-readable medium in connection with the necessary hardware components, such as the processor 610, bus 605, output device 635, and so forth, to carry out the function. ¶ 0065, Each campus SGT is represented as an external EPG in the ACI BL. Data plane learning can be used to add campus end points (e.g., IP addresses) into a respective external EPG; [Examiner’s Note: Desai teaches the ACI Border Leaf (BL) as an edge network device in the provider (first) domain that processes incoming traffic from other domains. The ACI BL has a processor and storage medium with executable instructions. The ACI BL functions as an “egress edge network device” for the first domain (traffic enters the first domain through this device)]): the first virtual tunnel header containing a first policy identifier (¶ 0056, Certain packets, such as, for example and without imputing limitation, i-VxLAN packets, crossing domains may carry identification (e.g., a classID, etc.) of a respective source SGT or EPG in the respective source domain and the virtual network identification of the respective destination domain; [Examiner’s Notes: Desai explicitly discloses virtual tunnel headers i-VXLAN containing policy identifiers (classID/SGT/EPG) in packets crossing domains.), the destination device connected to the egress edge network device, and where the trace packet was sent from an ingress edge network device in a second domain different from the first domain (Desai: ¶ 0180, Consumer Domain 510 is a networking domain containing Access Engine 520 and User 540. ¶ 0183, Access Point 550 can handle requests attempting to access data in Provider Domain 511. ¶ 0018, the SDA campus and the ACI data centers are disjoint policy domains; [Examiner’s Note: Desai manages two separate domains: the Provider/ACI Domain (first domain) and the Consumer/SDA Domain (second domain). The scenario described applies to traffic originating in the Consumer Domain and traveling through its ingress edge device toward the Provider Domain.]); the first gateway device connected to the second gateway device over a virtual tunnel (Desai: ¶ 0192, At step 572, the second domain provides the first domain with a response to the data request, in accordance with the access policy. ¶ 0214, Respective Gateways 510B and 511B then advertise routes for Endpoints 510F and 511F to each other. ¶ 0033, Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services; [Examiner’s Notes: Desai discloses that gateways function as data plane endpoints for traffic between domains, a response originating from a network device in the provider domain must pass through its local gateway and over an overlay tunnel to the consumer domain's gateway to achieve cross-domain delivery.]); and send, from the egress edge network device, the response packet to the first gateway device for forwarding by the first gateway device over the virtual tunnel and through the second gateway device to the ingress edge network device (Desai: ¶ 0192, At step 572, the second domain provides the first domain with a response to the data request, in accordance with the access policy. ¶ 0033, “gateway” refers to router(s) connecting a domain with other domains. Gateways are both control plane end point for route exchange and data plane end points for traffic going between consumers and providers/services. ¶ 0214, Respective Gateways 510B and 511B then advertise routes for Endpoints 510F and 511F to each other; [Examiner’s Note: Desai teaches that the response flows from the first domain’s edge device back through the first gateway (511B), over the overlay tunnel, through the second gateway (510B), to the consumer domain’s ingress device. This gateway chain forwarding is built directly into Desai’s architecture]).
Desai does not explicitly disclose receive, at the egress edge network device from a first gateway device of the first domain, a trace packet targeted to a destination device in the first domain, the trace packet comprising a first virtual tunnel header and a probe request; generate, at the egress edge network device as a response to the trace packet, a response packet comprising a second virtual tunnel header and probe information containing a translated policy identifier field to store any translated policy identifier produced by the first gateway device of the first domain from a policy identifier produced by a second gateway device of the second domain.
However, Ned teaches receive, at the egress edge network device from a first gateway device of the first domain, a trace packet targeted to a destination device in the first domain, the trace packet comprising a first virtual tunnel header and a probe request (Ned: ¶ 0026, assume that the message 310 is forwarded through network 100 as a type of "trace request", such as a media trace request (an application-layer trace request), a traceroute (a time-to-live or TTL-based ping request). ¶ 0032, R4 may eventually receive both the in-tunnel trace request 410a as well as the out-of-tunnel trace request 410b, and may respond to each independently. ¶ 0022, R4 receives the message 310, and may then forward the message on to SW2 to reach the destination, ES-B; [Examiner’s Note: Ned teaches that the tail-end node receives an encapsulated trace packet from the head-end gateway targeted to a destination connected to that egress device. This trace packet contains a probe request that is wrapped within a virtual tunnel header.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Ned, since doing so would have achieved the desirable result of enabling comprehensive path visibility and diagnostic analysis across both in-tunnel and out-of-tunnel network segments to efficiently isolate connectivity issues between the head-end gateway and the final destination device.
Desai and Ned do not explicitly disclose generate, at the egress edge network device as a response to the trace packet, a response packet comprising a second virtual tunnel header and probe information containing a translated policy identifier field to store any translated policy identifier produced by the first gateway device of the first domain from a policy identifier produced by a second gateway device of the second domain.
However, Pandey teaches generate, at the egress edge network device as a response to the trace packet, a response packet comprising a second virtual tunnel header and probe information containing a translated policy identifier field to store any translated policy identifier produced by the first gateway device of the first domain from a policy identifier produced by a second gateway device of the second domain (Pandey: ¶ 0022, the first gateway may decapsulate the VXLAN packet by removing header information from the VXLAN packet…The first gateway may not remove the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload from the VXLAN packet. The first gateway may encapsulate the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload with an EVPN MPLS header … to generate the EVPN MPLS packet. ¶ 0025, the second gateway may decapsulate the EVPN MPLS packet… may encapsulate the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload with the outer Ethernet header, the outer IP header, the outer UDP header, and the outer VXLAN header to generate the VXLAN packet. ¶ 0026, The second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include the TPID and the GPB-Id and thus may preserve the source TSI group identifier of the VXLAN packet; [Examiner’s Note: Pandey teaches the specific gateway-chain mechanism: the first gateway (of the first domain) receives a packet, preserves the GPB-Id, and re-encapsulates with EVPM MPLS header. The second gateway (of the second domain) receives the EVPN MPLS packet, preserves the GPB-ID, and re-encapsulates with a VXLAN header. The GPB-Id in the final VXLAN packet was “produced” (preserved/carried) by the first gateway from the identifier that was in the packet the second gateway produced. The egress edge network device (second network device/Leaf 21) receives this VXLAN packet containing the translated/preserved GPB-Id field]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai and Ned by further including, the above-mentioned features, as taught by Pandey, since doing so would have achieved the desirable result of achieving seamless, end-to-end group-based policy enforcement across heterogeneous multi-domain network architectures.
Regarding claim 15, Desai, Ned and Pandey teach the egress edge network device of claim 14.
Desai does not explicitly disclose wherein the probe information further comprises a probe stop indication to indicate that the trace packet has reached the egress edge network device.
However, Ned further teaches wherein the probe information further comprises a probe stop indication to indicate that the trace packet has reached the egress edge network device (Ned: ¶ 0032, R4 may eventually receive both the in-tunnel trace request 410a as well as the out-of-tunnel trace request 410b, and may respond to each independently. Claim 4, the out-of-tunnel trace request causes each subsequent node along a path of the tunnel to i) generate and transmit a respective trace response to the head-end node, and ii) transmit the out-of-tunnel trace request to any additional subsequent node along the path of the tunnel until the out-of-tunnel trace request reaches the tail-end node; [Examiner’s Notes: Ned teaches that the tail-end node R4 (egress edge network device) responds independently to the trace request. This independent response, which terminates the trace chain (no further forwarding occurs after R4’s response), constitutes a probe stop indication that the trace packet has reached the egress edge 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 modify the teachings of Desai by further including, the probe information further comprises a probe stop indication to indicate that the trace packet has reached the egress edge network device, as taught by Ned, since doing so would have achieved the desirable result of identifying the specific gateway processing a packet and correlating policy identifier changes with precise network positions.
Regarding claim 17, Desai, Ned and Pandey teach the egress edge network device of claim 14.
Desai does not explicitly disclose comprising: a first VXLAN tunnel endpoint (VTEP) to establish the virtual tunnel with a second VTP in the ingress edge network device.
However, Pandey teaches comprising: a first VXLAN tunnel endpoint (VTEP) to establish the virtual tunnel with a second VTP in the ingress edge network device (Pandey: ¶ 0017, the first network device of the first data center may correspond to Leaf 11. ¶ 0026, The second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include the TPID and the GPB-Id and thus may preserve the source TSI group identifier of the VXLAN packet. ¶ 0020, the VXLAN packet may include an outer Ethernet header, an outer Internet protocol (IP) header, an outer user datagram protocol (UDP) header, an outer VXLAN header. See claims 2-3; [Examiner’s Note: Pandey teaches that both the first network device, Leaf 11, and the second network device (in the second domain) generate and receive VXLAN packets with outer VXLAN headers. A network device that encapsulates and decapsulates VXLAN packets is, by definition, a VXLAN Tunnel Endpoint (VTEP). Both devices function as VTEPs establishing and maintaining VXLAN tunnels. The first VTEP (egress edge device in first domain) establishes the virtual tunnel with the second VTEP (ingress edge device in second domain)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the above-mentioned features, as taught by Pandey, since doing so would have achieved the desirable result of maximizing network throughput and reducing packet encapsulation latency by enabling direct, edge-to-edge VXLAN tunnel encapsulation and decapsulation between the first and second network devices.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Desai in view of Ned and Pandey, and in further view of Yadav.
Regarding claim 16, Desai, Ned and Pandey teach the egress edge network device of claim 14.
Desai, Ned and Pandey do not explicitly disclose wherein the probe information further comprises information of a policy action applied by the egress edge network device on the trace packet.
However, Yadav teaches wherein the probe information further comprises information of a policy action applied by the egress edge network device on the trace packet (Yadav: ¶ 0192, cross-domain assurance system 506 can compare policies in the second network with policies in the first network, using the first fabric data and the normalized second fabric data, to determine whether the policies are compatible with each other; [Examiner’s Notes: Yadav teaches that the system evaluates policy compatibility across different networks and records these policy enforcement actions directly within diagnostic logs to track execution history.]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Desai by further including, the probe information further comprises information of a policy action applied by the egress edge network device on the trace packet, as taught by Yadav, since doing so would have achieved the desirable result of generating a comprehensive audit trail of path reachability and policy execution.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Zheng et al. (US 2016/0373335 A1); Zheng et al. teaches a way to diagnose network problems across multiple layers of a network tunnel. The proposed methodology involves encoding characteristic diagnostic information within system messages, facilitating their subsequent propagation through multi-layered networks and diverse management domains. Because each reported diagnosis result carries the same identifying information, the instruction center can correlate results from different layers and different tunnels as one diagnosis event. The system also supports cross-domain notification so a peer end can forward diagnosis into another tunnel/domain. This replaces separate, disconnected OAM checks with a linked diagnosis flow. See [¶¶ 0004-06, 12-14, 26, 58-60, 81-83].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAJDI ALSOMIRI whose telephone number is (571) 270-0427. The examiner can normally be reached 7AM-5PM.
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, Ayman Abaza can be reached at (571) 270-0422. 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.
/M.A./Examiner, Art Unit 2465
/John Pezzlo/
Primary Examiner, AU 2465B
17 September 2026
Prosecution Insights