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 .
DETAILED ACTION
2. This action is in response to the application filed February 13, 2025.
3. Claims 1-20 have examined and are pending with this action.
4. The Information Disclosure Statement filed February 13, 2025 has been considered.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
5. Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) and 102(a)(2) as being anticipated by Mahesh et al. (US 2022/0029906 A1).
INDEPENDENT:
As per claim 1, Mahesh teaches a method comprising:
receiving, by a first router located at a remote location of an enterprise organization and from a second router located at the remote location, first routing performance data indicating a first performance of a first path from the remote location to an application infrastructure (see Mahesh, [0005]: “The monitors, policy engines, and/or network configurators may be implemented at the edge, agnostic to physical topologies of internal network, thereby enabling the present traffic engineering solution to be pluggable and customizable. For example, network monitors may be distributed across a network or in a hybrid cloud and programmed to monitor customizable network performance metrics (e.g., loss, latency, jitter, etc.) and/or application performance metrics (e.g., game stream session yield, application quality of service (QoS) metrics, etc.).”; [0017]: “As a result, a new switch or network device may be added to the system, and the existing network monitors and policy engines may communicate with the network configurator corresponding to the new network device to implement any changes to import or export maps, or other routing protocols of the network device.”; [0019]: “As a result, the network configurators may determine policy updates for one or more network devices—such as switches and/or routers—and may implement the routing updates at the target network endpoints. For example, the network configurator may correspond to a core switch configurator that may be used to update a border gateway protocol (BGP) local preference value for a particular egress port of the core switch to force traffic though a particular or desired ISP.”; and [0071]: “The method 400, at block B404, includes analyzing first data representative of first quality metrics corresponding to the first network path and second quality metrics corresponding to the second network path. For example, network performance and/or application performance metrics may be monitored by the network monitor(s) 116 for network paths over the transit ISPs 110A and 110B and the network policy engine(s) 118 may analyze the data therefrom.”);
receiving, by the first router and from a third router located at the remote location, second routing performance data indicating a second performance of a second path from the remote location to the application infrastructure (see Mahesh, [0047]: “The network monitor(s) 116A and/or 116B may monitor for alerts over different network paths for ingress and/or egress traffic—e.g., a first network path including the transit ISP 110A and a second network path including the transit ISP 110B.”; [0070]: “The method 400, at block B402, includes transmitting a first test probe over a first network path via a first ISP and a second test probe over a second network path via a second ISP.”; and [0071]: “The method 400, at block B404, includes analyzing first data representative of first quality metrics corresponding to the first network path and second quality metrics corresponding to the second network path. For example, network performance and/or application performance metrics may be monitored by the network monitor(s) 116 for network paths over the transit ISPs 110A and 110B and the network policy engine(s) 118 may analyze the data therefrom.”);
comparing, by the first router, the first routing performance data and the second routing performance data (see Mahesh, [0005]: “For example, the policy engines may compare certain network and/or application performance metrics to one or more evaluation criteria—e.g., threshold performance values of any number of alternative paths—to determine whether and/or how to update network configuration settings or criteria.”; [0038]: “For example, the network path information corresponding to a current network path including the transit ISP 110A may be compared—e.g., by the network policy engine(s) 118—to network path information corresponding to an alternate network path including the transit ISP 110B to determine a difference in one or more of network and/or application performance metrics.”; and [0065]: “Once an alert is generated, the network policy engine(s) 118 may determine whether the alert is actionable based on comparing the current network path to another network path including a different transit ISP 110. For example, if the difference between a current network path and an alternate path is greater than a change threshold (e.g., 5%, 10%, etc.), updates may be pushed to the network device(s) 124 to update export route maps and/or import route maps.”);
based at least in part on the comparing, determining, by the first router, whether the first path or the second path is an optimal path (see Mahesh, [0058]: “Considering an example scenario, where alerts have been generated for three network paths, L1, L2, and L3. L1 may include 20% loss, 10 ms latency, and 5 ms jitter, L2 may include 10% loss, 20 ms latency, and 6 ms jitter, and L3 may include 12% loss, 22 ms latency, and 4 ms jitter. In such an example, L3 and L2 may be better routes than L1 for loss, and between L3 and L2, L2 loss is five percent better than L3. As such, L2 may be the best network path”; [0059]: “As such, L3 may be the best network path”; and [0071]: “The method 400, at block B406, includes receiving second data representative of an alert indicating that the first network path is of higher quality than the second network path. For example, a network monitor 116 may generate an alert, and the network policy engine 118 may analyze the information from the alert corresponding to each network path to determine a first network path is better than a second network path”;); and
transmitting, by the first router, data traffic to the application infrastructure via the optimal path (see Mahesh, [0005]: “Responsive to policy engine determinations, network configurators may update ingress traffic routing (e.g., prepending AS information to packet headers for penalizing suboptimal routes) and/or egress traffic routing (e.g., to update local-preference weights to direct traffic without requiring external updates to network neighbors) for dynamically reconfiguring network paths to increase performance of target applications.”; [0023]: “For example, in some embodiments, when switching from one ISP to another, this may correspond to switching from a first route (e.g., via a first edge router of the ISP) through an ISP to a second route (e.g., via a second edge router of the ISP) through the same ISP.”; and [0073]: “The method 400, at block B408, includes determining to change a current network path including the second ISP to an updated network path including the first ISP. For example, the network policy engine(s) 118 may determine that policy updates should be implanted to switch the network paths”).
As per claim 8, Mahesh teaches a system comprising:
one or more processors (see Mahesh, [0020]: “Various functions described herein as being performed by entities may be carried out by hardware, firmware, and/or software. For instance, various functions may be carried out by a processor executing instructions stored in memory.”); and
one or more non-transitory computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform operations (see Mahesh, [0036]: “Now referring to FIG. 2, each block of method 200, described herein, comprises a computing process that may be performed using any combination of hardware, firmware, and/or software. For instance, various functions may be carried out by a processor executing instructions stored in memory.”) comprising:
receiving, by a first router located at a remote location of an enterprise organization and from a second router located at the remote location, first routing performance data indicating a first performance of a first path from the remote location to an application infrastructure (see Claim 1 rejection above);
receiving, by the first router and from a third router located at the remote location, second routing performance data indicating a second performance of a second path from the remote location to the application infrastructure (see Claim 1 rejection above);
comparing, by the first router, the first routing performance data and the second routing performance data (see Claim 1 rejection above);
based at least in part on the comparing, determining, by the first router, whether the first path or the second path is an optimal path (see Claim 1 rejection above); and
transmitting, by the first router, data traffic to the application infrastructure via the optimal path (see Claim 1 rejection above).
As per claim 15, Mahesh teaches one or more non-transitory computer-readable media storing instructions that when executed, cause one or more processors to perform operations comprising:
receiving, by a first router located at a remote location of an enterprise organization and from a second router located at the remote location, first routing performance data indicating a first performance of a first path from the remote location to an application infrastructure (see Claim 1 rejection above);
receiving, by the first router and from a third router located at the remote location, second routing performance data indicating a second performance of a second path from the remote location to the application infrastructure (see Claim 1 rejection above);
comparing, by the first router, the first routing performance data and the second routing performance data (see Claim 1 rejection above);
based at least in part on the comparing, determining, by the first router, whether the first path or the second path is an optimal path (see Claim 1 rejection above); and
transmitting, by the first router, data traffic to the application infrastructure via the optimal path(see Claim 1 rejection above).
DEPENDENT:
As per claims 2, 9, and 16, which respectively depend on claims 1, 8, and 15, Mahesh further teaches wherein the second router is exclusively designated to send probes over the first path between the remote location and the application infrastructure, and the third router is exclusively designated to send probes over the second path between the remote location and the application infrastructure (see Mahesh, [0070]: “The method 400, at block B402, includes transmitting a first test probe over a first network path via a first ISP and a second test probe over a second network path via a second ISP. For example, a first test probe may be transmitted over a network path including the transit ISP 110A and a second test probe may be transmitted over a network path including the transit ISP 110B.”).
As per claims 3, 10, and 17, which respectively depend on claims 1, 8, and 15, Mahesh further teaches wherein the remote location is in an edge site colocation facility and the first path and the second path are direct paths between the edge site colocation facility and the application infrastructure (see Mahesh, [0023]: “In addition, although only a single link through each ISP is illustrated, this is not intended to be limiting, and in some embodiments an individual ISP—such as the transit ISP 110A—may include a plurality of separate routes or edge router access points or nodes for the host device(s) 102.”; and [0060]: “With reference to FIG. 3B, a network monitor(s) 116, network policy engine(s) 118, and/or network configurator(s) 120 may be implemented for detecting a class of network failures including link flapping or failover traffic. For example, within the transit ISP 110 network or at the network edge between the transit ISP 110 and the host device(s) 102”).
As per claims 4, 11, and 18, which respectively depend on claims 1, 8, and 15, Mahesh teaches further comprising:
receiving, by the first router and from a fourth router located at the remote location, third routing performance data indicating a third performance of a third path from a regional gateway to the application infrastructure, wherein the fourth router is designated to send probes over a third path to a regional gateway site (see Mahesh, [0005]: “These performance issues may be analyzed by policy engines customized to process outputs or determinations of associated monitors for dynamically controlling network routing with adaptive, delayed feedback mechanisms—e.g., to avoid damping by Internet service providers (ISPs), quality issues with multiple path updates over short periods, and/or the like.”; and [0037]: “FIG. 2 is a flow diagram showing a method 200 for updating network settings based on metrics for a plurality of communication paths, in accordance with some embodiments of the present disclosure”);
comparing, by the first router, the first routing performance data, the second routing performance data, and the third routing performance data (see Claim 1 rejection above);
based at least in part on the comparing, determining, by the first router, whether the first path, the second path, or the third path is an optimal path (see Claim 1 rejection above); and
transmitting, by the first router, data traffic to the application infrastructure via the optimal path (see Claim 1 rejection above).
As per claims 5, 13, and 19, which respectively depend on claims 1, 8, and 15, Mahesh further teaches wherein the application infrastructure is one of:
a software as a service (SaaS); an infrastructure as a service (IaaS); a platform as a service (PaaS); a domain name system (DNS) server; a private data center; or an extranet. (see Mahesh, [0015]: “In some embodiments, an extensible framework may be implemented for improving network ingress and egress path resiliency for data centers—or other backend systems—using pluggable network monitors, network policy engines, and/or network configurators.”)
As per claims 6 and 12, which respectively depend on claims 1 and 8, Mahesh further teaches wherein the application infrastructure is a first application infrastructure and further comprising:
receiving, by the first router and from a fourth router located at the remote location, third routing performance data indicating a third performance of a third path from the remote location to a second application infrastructure (see Claim 4 rejection above);
receiving, by the first router and from a fifth router located at the remote location, fourth routing performance data indicating a fourth performance of a fourth path from the remote location to the second application infrastructure (see Claim 1 rejection above);
comparing, by the first router, the third routing performance data and the fourth routing performance data (see Claim 1 rejection above);
based at least on the comparing, determining, by the first router, whether the third path from the remote location to the second application infrastructure or the fourth path from the remote location to the second application infrastructure is an optimal path to the second application infrastructure (see Claim 1 rejection above); and
transmitting, by the first router, data traffic to the second application infrastructure via the optimal path to the second application infrastructure (see Claim 1 rejection above).
As per claims 7, 14, and 20, which respectively depend on claims 1, 8, and 15, Mahesh further teaches wherein the first path is a different network service provider than the second path (see Mahesh, [0015]: “In some embodiments, an extensible framework may be implemented for improving network ingress and egress path resiliency for data centers—or other backend systems—using pluggable network monitors, network policy engines, and/or network configurators.”; [0021]: “The system 100 may include one or more host devices 102, one or more support devices 104, and/or one or more client devices 106 that communicate over the Internet 108 via one or more internet service providers (ISPs)”; and [0042]: “FIG. 1, the support device(s) 104 may include one or more computing devices—e.g., a data center, or computing devices such as servers, NAS, APIs, etc. thereof—that host web services, such as the control plane services 130. For example, the support device(s) 104 may execute the control plane services 130—e.g., for a hybrid cloud platform—that may enable communication of information corresponding to the network and/or applications between the host device(s) 102 (e.g., a plurality of data centers) and the support device(s) 104 (e.g., one or more data centers hosting the control plane service(s) 130).”).
Conclusion
6. For the reasons above, claims 1-20 have been rejected and remain pending.
7. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL Y WON whose telephone number is (571)272-3993. The examiner can normally be reached on Wk.1: M-F: 8-5 PST & Wk.2: M-Th: 8-7 PST.
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, Nicholas R Taylor can be reached on 571-272-3889. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/Michael Won/Primary Examiner, Art Unit 2443
Prosecution Insights