DETAILED ACTION
This action is responsive to communications filed 28 January 2025.
Claims 1-20 are subject to examination.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 28 January 2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 9-15 and 19-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (US-9419889-B2) hereinafter Xiao in view of Nakil et al. (US-10565001-B2) hereinafter Nakil.
Regarding claim 11, Xiao discloses:
A system for discovering network paths using an enhanced traceroute procedure ([5:40-56] technique for path discovery involves using probe packets that have the same per-flow load balancing parameters as a user application and that have a special path discovery signature to differentiate the probe packets from user application packets [6:3-17] … illustrate an application packet and probe packets that are generated for a user application and various traceroute tools, see [10:58-11:8] path discovery controllers and the path discovery filters of each computing device are embodied within the respective computing device as software … computer readable instructions stored on a non-transitory computer readable storage medium, see also [2:8-32] system for discovering a path of network traffic)), the system ([2:8-32] system as above) comprising:
a source node including at least one processor and a memory ([10:58-11:8] path discovery controllers and the path discovery filters of each computing device are embodied within the respective computing device as software … computer readable instructions stored on a non-transitory computer readable storage medium [12:32-47] computing device … computer … includes a processor); and
a network topology discoverer implemented by the at least one processor ([10:58-11:8] path discovery module … software module for path discovery … computer readable instructions stored on a non-transitory computer readable storage medium [12:3-47] execution by a computer/on a computer … computing device … computer … includes a processor) for generating a plurality of probe request packets ([6:63-7:15] probe packet … generated by a path discovery controller, see [8:30-9:4] probe packets), the probe request packets being addressed to a destination node and each being associated with an entropy value that identifies a packet flow ([8:30-9:4] probe packets have the same five-tuple (i.e. entropy value) as the user application packets, see [6:63-7:15] probe packet will travel the same path as the user application packet in the presence of per-flow load balancing routers (i.e. identifying a packet flow)), the network topology discoverer for including, in each of the probe request packets ([8:30:9-4] probe packets), a signature value that is unique to the probe request packet within the packet flow ([6:63-7:15] bits from the identification field in the IP header and bits from the sequence number field in the TCP header are used to form a path discovery signature to uniquely identify the packet as a probe packet), setting time to live (TTL) values in the probe request packets for the packet flow to incrementally increasing values ([4:24-37] probe packets are sent with increasing time-to-live (TTL) values in order to identify each subsequent hop in the network), transmitting the probe request packets to a next-hop node in the network topology ([8:30-9:4] multiple probe packets are transmitted with different TTL values so that each hop along the path can be discovered (i.e. to a next-hop and (if existing) another next-hop, etc.)), receiving, by the source node ([10:58-11:8] path discovery controllers and the path discovery filters of each computing device [12:32-47] computing device … as above), probe response packets in response to the probe request packets ([8:30-9:4] each hop and a router returns a message to the source host 120 when the TTL reaches zero, see [FIG. 5A] e.g. 120 of computing device A 100), the probe response packets each including the signature value ([9:5-18] path discovery signature that is carried in the payload of the reply packets), reading, by the source node and from the probe response packets ([10:58-11:8] path discovery controllers and the path discovery filters of each computing device [12:32-47] computing device … as above [9:5-18] reply packets), the signature values ([9:5-18] path discovery signature (i.e. signatures for many packets)), and determining, by the source node and using the signature values read from the probe response packets ([10:58-11:8] path discovery controllers and the path discovery filters of each computing device [12:32-47] computing device … as above [9:5-18] signature … reply packets), a topology of hops from the source node to the destination node ([9:19-57] reply packets are used by the path discovery controller to generate path information that indicates the actual path of the user application traffic, see [FIG. 5B] e.g. user application 128 through host a 120 TCP/IP stack to nodes 110 to NIC 114 to host b 122 to user application 130), wherein the network topology discoverer ([10:58-11:8] path discovery module … software module for path discovery … computer readable instructions stored on a non-transitory computer readable storage medium [12:3-47] execution by a computer/on a computer … computing device … computer … includes a processor) is configured to, in transmitting the probe request packets ([8:30-9:4] multiple probe packets are transmitted with different TTL values so that each hop along the path can be discovered (i.e. to a next-hop and (if existing) another next-hop, etc.)), for a first packet flow ([6:63-7:15] bits from the identification field in the IP header and bits from the sequence number field in the TCP header are used to form a path discovery signature to uniquely identify the packet as a probe packet), transmit a first probe request packet having a first TTL value ([4:24-37] probe packets are sent with increasing time-to-live (TTL) values in order to identify each subsequent hop in the network) and, prior to receiving a probe response packet corresponding to the first probe request packet ([8:30-9:4] each hop and a router returns a message to the source host 120 when the TTL reaches zero, see [FIG. 5A] e.g. 120 of computing device A 100 (i.e. multiple probes with varying TTLs are transmitted and only responded to upon expiry of the timer; not another packet sent upon a first packet expiring, as above)), transmit, for the first packet flow ([6:63-7:15] bits from the identification field in the IP header and bits from the sequence number field in the TCP header are used to form a path discovery signature to uniquely identify the packet as a probe packet), a second probe request packet having a second TTL value different from the first TTL value ([8:30-9:4] multiple probe packets are transmitted with different TTL values so that each hop along the path can be discovered (i.e. to a next-hop and (if existing) another next-hop, etc.)).
Xiao does not explicitly disclose:
the probe response packets each encapsulating one of the probe request packets,
determining positions of the hops in a path,
However, Nakil discloses:
the probe response packets each encapsulating one of the probe request packets ([18:60-19:3] ICMP Time Exceeded message includes the IP header and the first eight bytes of the encapsulated data of flow trace packet),
determining positions of the hops in a path ([42:55-43:54] for each hash, analytics VM will then sort the associated list by timestamp and construct the topology map that the packet has traversed … match the topology map up with the known physical topology of the network … generates the path list, which consists of {switch-1, switch-2 … switch-r; i.e. positions of the hops in a path}),
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao in view of Nakil to have the probe response packets each encapsulate one of the probe request packets and determine positions of the hops in a path in a determined topology of hops. One of ordinary skill in the art would have been motivated to do so to generate a list of the physical next hops, which the virtual network element can return to a device that has requested the physical network path and determine latency in a physical network (Nakil, [4:8-39] [42:55-43:54]).
Regarding claim 12, Xiao-Nakil disclose:
The system of claim 11, set forth above,
Xiao discloses:
wherein the probe request packets comprise Internet control management protocol (ICMP) packets ([8:30-9:4] reply message (e.g., ICMP message), see [4:62-5:20] probe packets may also use … ICMP Echo (i.e. ICMP message responds to ICMP message)).
Regarding claim 13, Xiao-Nakil disclose:
The system of claim 11, set forth above,
Xiao discloses:
wherein the network topology discoverer is configured to generate the entropy value from a combination of source Internet protocol (IP) address, source user datagram protocol (UDP) port, destination IP address, and destination UDP port ([8:30-9:4] probe packets have the same five-tuple (i.e. entropy value) as the user application packets, see [4:12-23] five-tuple … includes the protocol, source IP address, … destination IP address … source port and destination port … UDP header).
Regarding claim 14, Xiao-Nakil disclose:
The system of claim 13, set forth above,
Xiao discloses:
wherein the network topology discoverer is configured to vary the entropy values associated with different ones of the probe request packets to generate probe request packets associated with different packet flows ([8:30-9:4] probe packets have the same five-tuple (i.e. entropy value) as the user application packets (i.e. different user application packets for different flows would have different values), see [4:12-23] five-tuple … includes the protocol, source IP address, … destination IP address … source port and destination port … UDP header [6:3-17] source address of 192.168.1.1 … source port that is used by the user application … assigned by the TCP/IP stack when the application creates the socket (i.e. different applications differing sockets)).
Regarding claim 15, Xiao-Nakil disclose:
The system of claim 14, set forth above,
wherein the network topology discoverer is configured to vary the entropy values by varying source and destination UDP port values in the probe request packets ([8:30-9:4] probe packets have the same five-tuple (i.e. entropy value) as the user application packets (i.e. different user application packets for different flows would have different values), see [4:12-23] five-tuple … includes the protocol, source IP address, … destination IP address … source port and destination port … UDP header [6:3-17] source address of 192.168.1.1 … source port that is used by the user application … assigned by the TCP/IP stack when the application creates the socket (i.e. different applications differing sockets) … destination port of 80 (port 80 corresponds to HTTP; i.e. not HTTP would be not 80)).
Regarding claim 19, Xiao-Nakil disclose:
The system of claim 11, set forth above,
Xiao discloses:
wherein the source node comprises a network endpoint, a test tool, or a router ([10:58-11:8] path discovery controllers and the path discovery filters of each computing device are embodied within the respective computing device as software … computer readable instructions stored on a non-transitory computer readable storage medium [12:32-47] computing device … computer … includes a processor, see [FIG. 5A] e.g. 120 of computing device A 100) and
Xiao does not explicitly disclose:
wherein generating the probe request packets includes generating the probe request packets from a plurality of different Internet protocol addresses.
However, Nakil discloses:
wherein generating the probe request packets includes generating the probe request packets from a plurality of different Internet protocol addresses ([4:8-39] receives a request to determine a physical network path taken by packets of a network packet flow [8:61-9:13] “flow” can be defined by the five values used in a header to a packet … Source IP address, Destination IP address [19:18-37] flow trace module continues generating flow trace packets in this manner until switch 30A receives a confirmation message 49 that one of the subsequent flow trace packets has arrived at another of virtual switches, see [FIGs 2A-B] e.g. servers 1-x, switches 30A-x (i.e. tracing flow paths that source from each of the switches is a plurality of addresses)).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao in view of Nakil to have generated the probe request packets from a plurality of different internet protocol addresses. One of ordinary skill in the art would have been motivated to do so to generate a list of the physical next hops, which the virtual network element can return to a device that has requested the physical network path and determine latency in a physical network (Nakil, [4:8-39] [42:55-43:54]).
Regarding claims 1-5, 9 and 20, they do not further define nor teach over the limitations of claims 11-15, 19 and 11, therefore, claims 1-5, 9 and 20 are rejected for at least the same reasons set forth above as in claims 11-15, 19 and 11.
Regarding claim 10, Xiao-Nakil disclose:
The method of claim 1, set forth above,
Xiao does not explicitly disclose:
wherein the source node comprises a router.
However, Nakil discloses:
wherein the source node comprises a router ([FIG. 2A] virtual switch 30A with FTM 48, see [33:58-34:8] FTM 48 of server 12A receives a request to determine, or “trace,” a physical network path).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao in view of Nakil to have the source node comprise a router. One of ordinary skill in the art would have been motivated to do so to generate a list of the physical next hops, which the virtual network element can return to a device that has requested the physical network path and determine latency in a physical network (Nakil, [4:8-39] [42:55-43:54]).
Claim(s) 6 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (US-9419889-B2) hereinafter Xiao in view of Nakil et al. (US-10565001-B2) hereinafter Nakil further in view of Kamath (US-11784904-B2).
Regarding claim 16, Xiao-Nakil disclose:
The system of claim 11, set forth above,
Xiao discloses:
wherein the network topology discoverer is configured to insert the signature value in a user datagram protocol (UDP) of each of the probe packets ([8:30-9:4] includes the first eight bytes of the probe packet’s transport layer header (i.e. signature) in the payload of the reply packet, see [4:12-23] five-tuple … includes the protocol, source IP address, … destination IP address … source port and destination port … UDP header).
Xiao does not explicitly disclose:
insert the signature value in payload of each of the probe request packets.
However, Kamath discloses:
insert the signature value in payload of each of the probe request packets ([20:3-15] traceroute probes … signature in the payload).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao in view of Kamath to have inserted the signature in a payload of each of the probe request packets. One of ordinary skill in the art would have been motivated to do so to identify a probe (Kamath, [20:3-15]).
Regarding claim 6, it does not further define nor teach over the limitations of claim 16, therefore, claim 6 is rejected for at least the same reasons set forth above as in claim 16.
Claim(s) 8 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Xiao et al. (US-9419889-B2) hereinafter Xiao in view of Nakil et al. (US-10565001-B2) hereinafter Nakil further in view of Chadha (US-20220407800-A1) further in view of Xiao et al. (US-9397920-B2) hereinafter Xiao(2).
Regarding claim 18, Xiao-Nakil disclose:
The system of claim 11, set forth above,
Xiao discloses:
wherein the network topology discoverer is configured to generate a report indicating entropy values for flows that use each path ([7:16-33] a user application packet 62 has a protocol field of UDPv4, a source address of 192.168.1.1, a destination address of 192.168.100.2, a source port used by the user application, and a destination port of 554 (designated for RTSP). In an embodiment, the source port is an ephemeral port number assigned by the TCP/IP stack when the application creates the socket).
Xiao does not explicitly disclose:
wherein the network topology discoverer is configured to generate a report indicating a number of paths between a source and a destination, IP addresses and hop indices for the hops in each path, and a roundtrip time for each of the hops.
However, Chadha discloses:
wherein the network topology discoverer is configured to generate a report indicating IP addresses and hop indices for the hops in each path, and a roundtrip time for each of the hops ([0012] enable a software utility, such as traceroute, to trace and report on connectivity information from a source destination to a destination device, see [0005] as output, the traceroute typically displays how many hops the packet traveled to reach the network destination, identifies each hop along the path by its network address, and shows the round-trip time for reaching each hop.
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao in view of Chadha to have generated a report indicating IP addresses and hop indices for the hops in each path and a roundtrip time for each of the hops. One of ordinary skill in the art would have been motivated to do so to trace and report on connectivity information form a source destination to a destination device (Chadha, [0012]).
Xiao-Chadha do not explicitly disclose:
wherein the network topology discoverer is configured to generate a report indicating a number of paths between a source and a destination.
However, Xiao(2) discloses:
wherein the network topology discoverer is configured to generate a report indicating a number of paths between a source and a destination ([2:3-17] identifies a network topology that is involved in routing of the network traffic between the endpoints … covers all the routing paths … groups together, the receiving interfaces as well as the forwarding interfaces of each forwarding element along different paths between the endpoints, see [6:28-45] two routing paths between the source endpoint and the destination endpoint).
It would have been obvious to one of ordinary skill in the pertinent art before the effective filing date of the claimed invention to modify the invention of Xiao-Chadha in view of Xiao(2) to have generated a report indicating a number of paths between a source and destination. One of ordinary skill in the art would have been motivated to do so to cover all the routing paths in identifying a network topology (Xiao(2), [2:3-17]).
Regarding claim 8, it does not further define nor teach over the limitations of claim 18, therefore, claim 8 is rejected for at least the same reasons set forth above as in claim 18.
Allowable Subject Matter
Claims 7 and 17 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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rangappagowda et al. (US-10892976-B2) Methods, Systems, And Computer Readable Media For Intelligent Network Topology Mapping;
Chowdhury et al. (US-12184528-B2) Methods And Apparatus For Adaptive And Holistic Network Measurements;
Gamage et al. (US-12483493-B2) Systems And Methods For Data Plane Validation Of Multiple Paths In A Network
Chhabra (US-12652249-B2) Egress And Private Router Detection In Internet Protocol Version 6 (IPV6).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Alex Tran whose telephone number is (571)272-8173. The examiner can normally be reached Monday-Friday 10AM-6PM ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kamal Divecha can be reached at (571)272-5863. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Alex Tran/Primary Examiner, Art Unit 2453
Prosecution Insights