DETAILED ACTION
This communication is in responsive to Application 18/904540 filed on 10/2/2024. 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 presented for examination.
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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-3, 5-6, 8, 10-13, 14 and 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar T V (hereinafter Kumar) US 2020/0007427 A1 in view of Myneni et al. (hereinafter Myneni) US 2021/0184914 A1.
Regarding Claim 1, Kumar teaches a method comprising:
sending, by a first computing system, a first plurality of test packets over at least one path in a network to a second computing system (Fig. 6 & ¶0119; at block 610, a first device sends, toward a second device via a communication path between the first device and the second device, a set of test packets having a test packet size. ¶0124; a first device may be configured to execute a set of one or more tests using a communication path between the first device and a second device and determine, based on the set of one or more tests, a PMTU size of the communication path);
receiving, by the first computing system, a second plurality of response packets to the first plurality of test packets over the network from the second computing system (Fig. 6 & ¶0120; At block 620, the first device determines, based on monitoring for response packets associated with the test packets, a service metric associated with the communication path. The response packets may have a response packet size substantially similar to the test packet size (e.g., equal to the test packet size or close enough to the test packet size to evaluate the PMTU size of the communication path to a particular level of granularity));
determining, based at least in part on the first plurality of test packets and the second plurality of response packets, whether a mismatch exists between a network transmission media maximum transmission unit of the first computing system and a discovered path maximum transmission unit of the at least one path (¶0027 because the communication path 111 has a PMTU size associated therewith. In general, the PMTU size of an IP communication path, such as the communication path 111, is the maximum size of an IP packet that can traverse the IP communication path without suffering fragmentation and, thus, will be the smallest MTU size of the MTU sizes of the IP hops of the IP communication path since the MTU size for an IP hop of an IP communication path is the maximum size of an IP packet that can be transmitted without fragmentation over a given medium for that IP hop of the IP communication path. Then see Fig. 6 & ¶0120-¶0121; The response packets may have a response packet size substantially similar to the test packet size (e.g., equal to the test packet size or close enough to the test packet size to evaluate the PMTU size of the communication path to a particular level of granularity). The service metric associated with the communication path may be determined based on matching of test packets sent via the communication path to associated response packets expected to be received via the communication path responsive to the test packets, respectively. The service metric may be a packet loss or other suitable service metric. At block 630, the first device determines, based on the service metric and a service metric threshold, the PMTU size of the communication path… The PMTU size of the communication path may be determined to be the test packet size of the test packets based on a determination that the service metric satisfies the service metric threshold. The PMTU size of the communication path may be determined to be greater than the test packet size of the test packets, using dynamic varying of the test packet size for a second set of test packets, based on a determination that the service metric satisfies the service metric threshold. The PMTU size of the communication path may be determined to be less than the test packet size of the test packets, using dynamic varying of the test packet size for a second set of test packets, based on a determination that the service metric does not satisfy the service metric threshold);
in response to a mismatch existing (¶0120-¶0121),
and repeating the sending, receiving, determining (obvious from Fig. 6 since in step 620 it is monitoring for response packets which implies the repeating and other steps) and reducing until no mismatch exists (Fig. 6 & ¶0124-¶0125; obvious because The test packet size may be raised and lowered in various ways and under various conditions to converge on the actual PMTU size of the communication path or an estimate of the PMTU size of the communication path (e.g., based on tradeoffs in accuracy of PMTU size determination, number of tests to be performed and associated resources which may be expended in performing such tests, or the like, as well as various combinations thereof)).
Kumar does not expressly teach “…taking a remediation action;”
Myneni teaches “…taking a remediation action;” (¶0047 & Fig. 4; remediation actions include adjusting MTU size see 483).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Myneni into the system of Kumar in order to perform remediation actions based on detected network issues (¶0047). Utilizing such teachings enable the system to diagnose and troubleshoot various network issues that may affect data-plane connectivity among hosts and VMs (¶0001).
Regarding Claim 2, Kumar in view of Myneni teaches the method of claim 1, Kumar further teaches wherein taking the remediation action comprises reducing the network transmission media maximum transmission unit of the first computing system by a predetermined amount (see Kumar in ¶0124 & Myneni in ¶0047 & Fig. 4; adjusting MTU size see 483).
Regarding Claim 3, Kumar in view of Myneni teaches the method of claim 1, Kumar further teaches wherein taking the remediation action comprises invalidating a tunnel between the first computing system and the second computing system used to send the first plurality of test packets over the network (obvious from ¶0027 because the communication path 111 has a PMTU size associated therewith. In general, the PMTU size of an IP communication path, such as the communication path 111, is the maximum size of an IP packet that can traverse the IP communication path without suffering fragmentation and, thus, will be the smallest MTU size of the MTU sizes of the IP hops of the IP communication path since the MTU size for an IP hop of an IP communication path is the maximum size of an IP packet that can be transmitted without fragmentation over a given medium for that IP hop of the IP communication path).
Regarding Claim 5, Kumar in view of Myneni teaches the method of claim 1, Kumar further teaches wherein a first portion of the first plurality of test packets include don’t fragment (DF) bits set to one in headers of the first plurality of test packets and a second portion of the first plurality of test packets include DF bits set to zero in headers of the first plurality of test packets (obvious from ¶0045 because the use of test packets in PMTU tests may be controlled in a manner tending to prevent fragmentation of test packets on the communication path 111. For example, in the case of IPv4 test packets, the Don't Fragment (DF) bit may be set to prevent fragmentation of the IPv4 test packets along the communication path 111. For example, in the case of IPv6 test packets, the padding sizes of the test packets may be constrained such that the packet sizes of the test packets do not exceed the maximum MTU size of the egress interface (e.g., the maximum MTU size of the egress interface of the router 121-1) so as to prevent IPv6 source fragmentation. For example, the use of padding sizes of test packets in PMTU tests may be controlled based on the maximum MTU size of the egress interface of the router 121-1 for the communication path since the maximum MTU size of the egress interface of the router 121-1 is the only MTU size of the communication path that is known by the router 121-1. It will be appreciated that fragmentation of test packets on the communication path 111 may be prevented in other ways).
Regarding Claim 6, Kumar in view of Myneni teaches the method of claim 1, Kumar further teaches comprising, in response to no mismatch existing, waiting a predetermined time and repeating the sending, receiving, and determining (obvious from Fig. 6 since in step 620 it is monitoring for response packets which implies the repeating and other steps).
Regarding Claim 8, Kumar in view of Myneni teaches the method of claim 1, Kumar further teaches comprising determining the mismatch by comparing frame sizes of the second plurality of response packets to a current frame size of the first plurality of test packets (obvious from Fig. 6 & ¶0021; Various example embodiments for supporting measurement of a PMTU size of a communication path based on use TWAMP may be configured to use TWAMP to dynamically control test session establishment, test execution (e.g., test initiation, test packet sizes, test monitoring, or the like), testing results analysis, or the like, as well as various combinations thereof. Various example embodiments for supporting measurement of a PMTU size of a communication path based on use TWAMP may be configured to provide various advantages (e.g., supporting measurement of a PMTU size of a communication path for any Internet Protocol (IP) network connection, supporting measurement of a PMTU size of a communication path without relying on a testing protocol (e.g., the Path MTU Discovery protocol of RFC 1191) that is based on a control protocol (e.g., ICMP or the like) that is different than the communication protocol of IP packets of IP network connections, or the like).
Claims 10-13, 14, 17-19 are substantially similar to the above claims, thus the same rationale applies.
Regarding Claim 20, Kumar in view of Myneni teaches the apparatus of claim 19, Kumar further teaches comprising instructions that when executed by the processing circuitry cause the apparatus to: return an error condition in response to all test packets having DF bits set to one and all test packets having DF bits set to zero results in receiving no response packets (obvious from ¶0045 because the use of test packets in PMTU tests may be controlled in a manner tending to prevent fragmentation of test packets on the communication path 111. For example, in the case of IPv4 test packets, the Don't Fragment (DF) bit may be set to prevent fragmentation of the IPv4 test packets along the communication path 111. For example, in the case of IPv6 test packets, the padding sizes of the test packets may be constrained such that the packet sizes of the test packets do not exceed the maximum MTU size of the egress interface (e.g., the maximum MTU size of the egress interface of the router 121-1) so as to prevent IPv6 source fragmentation. For example, the use of padding sizes of test packets in PMTU tests may be controlled based on the maximum MTU size of the egress interface of the router 121-1 for the communication path since the maximum MTU size of the egress interface of the router 121-1 is the only MTU size of the communication path that is known by the router 121-1. It will be appreciated that fragmentation of test packets on the communication path 111 may be prevented in other ways).
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar in view of Myneni and further in view of Cociglio et cl. (hereinafter Cociglio) WO 2019129688 A1.
Regarding Claim 4, Kumar in view of Myneni teaches the method of claim 1, but fails to teach wherein the first plurality of test packets comprises echo requests and the second plurality of response packets comprises echo replies.
wherein the first plurality of test packets comprises echo requests and the second plurality of response packets comprises echo replies (this limitation is well-known in the art and obvious to a skilled artisan because it is built in Ping. See Cociglio background in p. 2 lines 14-24).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Cociglio into the system of Kumar in view of Myneni in order to measure packet loss, one-way delay and/or jitter of packet flows in a communication network is of particular interest for network operators (p. 2, lines 7-10).
Claims 7 and 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Kumar in view of Myneni and further in view of He et al. (hereinafter He) US 2024/0235994 A1 A1.
Regarding Claim 7, Kumar in view of Myneni teaches the method of claim 1, but fails to teach wherein the network comprises an Internet service provider backbone network, and the first computing system and the second computing system are coupled as a software-defined wide area network (SD-WAN) over the Internet service provider backbone network.
He teaches wherein the network comprises an Internet service provider backbone network (This limitation is merely a design choice. See Figs. 3 & 7), and the first computing system and the second computing system are coupled as a software-defined wide area network (SD-WAN) over the Internet service provider backbone network (This limitation is merely a design choice. See Figs. 3 & 7).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of He into the system of Kumar in view of Myneni in order to determine correct paths between devices to improve network performance (common knowledge).
Regarding Claim 15, Kumar in view of Myneni teaches the apparatus of claim 14, but fails to teach wherein the network comprises an Internet service provider backbone network, and the first computing system comprises a first spoke computing system and the second computing system comprises a hub computing system of a software-defined wide area network (SD-WAN) operating over the Internet service provider backbone network.
He teaches wherein the network comprises an Internet service provider backbone network, and the first computing system comprises a first spoke computing system and the second computing system comprises a hub computing system of a software-defined wide area network (SD-WAN) operating over the Internet service provider backbone network (This limitation is merely a design choice. See Figs. 3 & 7).
Regarding Claim 16, Kumar in view of Myneni teaches the apparatus of claim 14, but fails to teach wherein the network comprises an Internet service provider backbone network, and the first computing system comprises a first spoke computing system and the second computing system comprises a second spoke computing system of a software-defined wide area network (SD-WAN) operating over the Internet service provider backbone network.
He teaches wherein the network comprises an Internet service provider backbone network, and the first computing system comprises a first spoke computing system and the second computing system comprises a second spoke computing system of a software-defined wide area network (SD-WAN) operating over the Internet service provider backbone network (This limitation is merely a design choice. See Figs. 3 & 7).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Kumar in view of Myneni and further in view of Saavedra et al. (hereinafter Saavedra) US 2019/0182213 A1.
Regarding Claim 9, Kumar in view of Myneni teaches the method of claim 1, but fails to teach comprising determining the mismatch by comparing payload lengths of the second plurality of response packets to payload lengths of the first plurality of test packets.
Saavedra teaches comprising determining the mismatch by comparing payload lengths of the second plurality of response packets to payload lengths of the first plurality of test packets (¶0238-¶0242; filters are used to compare string’s length at fixed position in data payload or at any position).
It would have been obvious to one of ordinary skill in the art before the effective filling date of the claimed limitation to incorporate the teachings of Saavedra’s teachings of comparing payload lengths (packet sizes) in networking into the system of Kumar in view of Myneni in order to find the balance between overhead efficiency (throughput) and latency resilience (error handling) (common knowledge).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAHRAN ABU ROUMI whose telephone number is (469)295-9170. The examiner can normally be reached Monday-Thursday 6AM-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, Emmanuel Moise can be reached at 571-272-3865. 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.
MAHRAN ABU ROUMI
Primary Examiner
Art Unit 2455
/MAHRAN Y ABU ROUMI/Primary Examiner, Art Unit 2455
Prosecution Insights