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 .
Response to Remarks
This communication is considered fully responsive to the amendment filed on 02/27/2026 .
Claims 1-20 are pending and are examined in this office action.
No new claim has been added and no claim has been canceled.
In view of the Terminal Disclaimer, the previous double patent rejection has been withdrawn.
Response to Arguments
Applicant’s arguments, filled on 02/27/2026 , with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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.
Claims 1-5, 7-12, 14-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over MARKUZE et al. (US 20190158605 A1; hereinafter as “MARKUZE ”) in view of PARAMASIVAM et al. (US 20170317932 A1; hereinafter as “PARAMASIVAM”).
Examiner’s note: in what follows, references are drawn to MARKUZE unless otherwise mentioned.
Regarding claim 8, MARKUZE teaches, an apparatus (see fig. 16: ingress Gateway) of a service provider infrastructure system ( see fig. 16: service provider network with DataCenter, Branch Office 1, Branch Office 2 are connected to Saad Service providers 1620 : “ In the example illustrated in FIG. 16, the message flows come from two branch offices 1655 and 1660 and a datacenter 1665 of two virtual-network tenants, and enter the virtual network 1600 through the same ingress gateway 1670, although this does not necessarily have to be the case. The virtual network 1600 in some embodiments is defined over multiple public cloud datacenters of multiple public cloud vendors. In some embodiments, the virtual-network gateways are part of the managed forwarding nodes, and the TM engines are placed before the NAT engines 1610 in egress MFNs.”: [0220] comprising:
a non-transitory computer-readable storage medium (see fig. 1: Memory 128 ); and
a processor ( Processor 106 in fig. 1 ) that executes instructions stored in the non-transitory computer-readable storage medium ( software with memory and processors: [0395]-[0398] ) to:
obtain ranking data for data transport pathways between the service provider infrastructure system and an external system (==Saad Provider 1… Saad Provider N) (see fig. 16: Ingress Gateway with Ingress CFE obtain and identifies “routing context based on the identifier of the IPsec tunnel (e.g., 806 or 1206) in the received data message. ”: [0176]; “ In the example illustrated in FIG. 16, the message flows come from two branch offices 1655 and 1660 and a datacenter 1665 of two virtual-network tenants, and enter the virtual network 1600 through the same ingress gateway 1670, although this does not necessarily have to be the case. The virtual network 1600 in some embodiments is defined over multiple public cloud datacenters of multiple public cloud vendors”: [0220] :” In some embodiments, the identified routing path for each pair of data message endpoints is a routing path that is deemed optimal based on a set of optimization criteria, e.g., it is the fastest routing path, the shortest routing path, or the path that least uses the Internet. In other embodiments, the path-identifying engine can identify and provide (in the routing table) multiple different routing paths between the same two endpoints. In these embodiments, the cloud forwarding elements 235 of the managed forwarding nodes 150 then select one of the paths based on QoS criteria or other runtime criteria that they are enforcing. Each CFE 235 in some embodiments does not receive the entire routing path from the CFE to the egress point of the virtual network, but rather receives the next hop for the path.”: [0115]; “ Using the computed costs of these pair-wise links, the controller cluster can compute the cost of each routing path that uses one or more of these pair-wise links by aggregating the costs of the individual pair-wise links that are used by the routing path. As described above, the controller cluster then defines its routing graph based on the computed costs of the routing paths, and generates the forwarding tables of the cloud routers of the MFNs based on the defined routing graphs.”{ 0139]; NOTE: traffic from Tenant 2 data center, Tenant 1 Branch office 1, Tennant 2 Branch Office 1 are coming to INGRESS GATEWAY in Fig. 16. Aforesaid INGRESS GATEWAY route or rank those data to send them to Saad Provider 1 to SaaS Provider N as shown in Fig. 16; “ As shown in FIG. 9, the ingress process 900 starts by initially identifying (at 905) the tenant routing context based on the identifier of the IPsec tunnel (e.g., 806 or 1206) in the received data message. In some embodiments, the IPsec gateways or other MFN modules store the tenant IDs for the IPsec tunnel IDs in mapping tables. Whenever a data message is received along a particular IPsec tunnel, the IPsec gateway extracts the IPsec tunnel ID, which this gateway or another MFN module then uses to identify the associated tenant ID by reference to its mapping table. By identifying the tenant ID, the process identifies the tenant routing table or the tenant portion of the VRF namespace to use.”: [0176]; “At 910, the process increments the identified IPsec tunnel's RX (receive) counter to account for receiving this data message. Next, at 915, the process performs a route lookup (e.g., a longest prefix match, LPM, lookup) in the identified tenant routing context (e.g., in the tenant's portion of the VRF namespace) to identify the IP address of the egress interface for exiting the tenant's virtual network that is built over the public cloud datacenters”; [0177]);
wherein a respective data transport pathway from the data transport pathways includes a respective exit node in the service provider infrastructure system in communication with a respective entry node in the external system (==Saad Provider 1… Saad Provider N ) (see fig. 16: IPSec Tunnel can go from Ingress Gateway to Saad Provider 1 or Saad Provider N : “ When a data message reaches an egress gateway 1602 to exit the virtual network on its way to a SaaS provider datacenter 1620, each TM engine 1605 maps the source network address (e.g., source IP and/or port addresses) of these data message to new source network address (e.g., source IP and/or port addresses), and the NAT engine 1610 maps the new source network address to yet another source network address (e.g., another source IP and/or port addresses)”: [0221] ) and
wherein a respective data transport pathway from the data transport pathways includes a respective exit node in the service provider infrastructure system in communication with a respective entry node in the external system, and wherein to obtain the ranking data the processor executes the instructions to obtain at least a portion of the ranking data by testing a service provided by the external system via the entry node
(“configured to optimize the routing of the entity's data messages to their destinations for best end-to-end performance, reliability and security, while trying to minimize the routing of this traffic through the Internet. Also, the virtual network in some embodiments can be configured to optimize the layer 4 processing of the data message flows passing through the network. For instance, in some embodiments, the virtual network optimizes the end-to-end rate of TCP (Transport Control Protocol) connections by splitting the rate control mechanisms across the connection path.”: [0068]; “ optimize the forwarding of the entity's data messages to their destinations for best end-to-end performance and reliability. Some of these processes implement proprietary high-performance networking protocols, free from the current network protocol ossification. For example, in some embodiments, the optimization engine 220 optimizes end-to-end TCP rates through intermediate TCP splitting and/or termination.”: [0101]; “ the best route to be established from each MMCN to each other MMCN or SaaS provider datacenter by selecting the best ingress node for entering the virtual network from the MMCN for the best routing path through the virtual network to the egress node for exiting the virtual network to another MMCN or SaaS provider datacenter.”; [0310]; “ Next, at 915, the process performs a route lookup (e.g., a longest prefix match, LPM, lookup) in the identified tenant routing context (e.g., in the tenant's portion of the VRF namespace) to identify the IP address of the egress interface for exiting the tenant's virtual network that is built over the public cloud datacenters”; [0177]; “ Next, at 2115, the controller cluster generates a routing graph for the particular tenant from the measurements collected by the measurement agents 205 of the MFNs 150 that are candidate MFNs to use for establishing the virtual network for the particular tenant. As mentioned above, the routing graph has nodes that represent the MFNs, and links between the nodes that represent the network connections between the MFNs. The links have associated weights, which are cost values that quantify the quality and/or cost of using the network connections represented by the links. As mentioned above, the controller cluster first generates a measurement graph from the collected measurements, and then generates the routing graph by removing links from the measurement graph that are not optimal (e.g., that have large delays or drop rates).”: [0279]).
MARKUZE does not expressively teach:
allocate a data transport pathway from the data transport pathways to a communication session, wherein the data transport pathway is a highest-ranking data transport pathway in the ranking data.
PARAMASIVAM, in the same field of endeavor, discloses:
allocate a data transport pathway from the data transport pathways to a communication session, wherein the data transport pathway is a highest-ranking data transport pathway in the ranking data ( “controller (==Ingress Gateway in MARKUZE) can identify the service chain of the plurality of service chains comprising a first path having a first instance of the first service and a first instance of the second service. The controller can identify a second service chain of the plurality of service chains comprising a second path having a second instance of the first service and a second instance of the second service.”…. The controller can select the service chain corresponding to the first path based on the first path weight ranking higher than the second path weight (==ranking or routing ). [0013]; “ controller can select the service chain by ranking each service chain of the plurality of service chains based on the path weight (==cost in MARKUZE) for each of the plurality of service chains. The controller can select, based on the ranking, a predetermined number of highest ranking service chains of the plurality of service chains to generate a subset of service chains. The controller can input the path weight for each of the subset of service chains into the load balancing function to select the service chain.”: [0014]; “ the controller 705 can use a machine learning technique to prune the service chains prior to determining path weights, prior to ranking or sorting the service chains, or prior to determining the subset of optimal service chains. By performing a pre-processing, filtering, or pruning technique, the controller 705 can improve the efficiency of identifying the optimal service chains.”: [0306]; “ the controller can sort the service chains based on the path weights such that the highest performing service chain is ranked or sorted as the top service chain. In some cases, the controller can sort the service chains in ascending order such that the last ranked service chain is the highest performing service chain based on the path weight.”: [0350]-[0351]).
Therefore, 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 teaching of MARKUZE to include the above recited limitations as taught by PARAMASIVAM. The suggestion/motivation would be to efficiently provide services for instances that are distributed across the cloud environment because the distribution of instances can impact overhead, cost, latency, throughput, or load. (PARAMASIVAM; [0002).
Regarding claim 1, MARKUZE teaches, A method of automatic network configuration, the method comprising:
obtaining, by a service provider infrastructure system, ranking data for data transport pathways between the service provider infrastructure system and an external system, wherein a respective data transport pathway from the data transport pathways includes a respective exit node in the service provider infrastructure system in communication with a respective entry node in the external system, wherein obtaining the ranking data includes obtaining at least a portion of the ranking data by testing a service provided by the external system via the entry node; and
allocating, by the service provider infrastructure system, a data transport pathway from the data transport pathways to a communication session, wherein the data transport pathway is a highest-ranking data transport pathway in the ranking data (Regarding rest of claim 1, the claim is interpreted and rejected for the same reason as set forth in claim 8).
Regarding claim 14, the claim is interpreted and rejected for the same reason as set forth in claim 8.
Regarding claim 2, MARKUZE in view of PARAMASIVAM teaches the invention of claim 1 as set forth above. Further, MARKUZE teaches, The method of claim 1, wherein: obtaining the ranking data includes identifying a subset of the data transport pathways as a priority pool in accordance with the ranking data; and allocating the data transport pathway includes allocating the priority pool to the communication session (“ To address the possibility that multiple firewall rules match a data message, the firewall enforcing engine 210 stores the firewall rules (that it receives from the controller cluster 160) in a firewall rule data storage in a hierarchical manner so that one firewall rule can have higher priority than another firewall rule. When a data message matches two firewall rules, the firewall enforcing engine applies the rule with the higher priority in some embodiments. In other embodiments, the firewall enforcing engine examines the firewall rules according to their hierarchy (i.e., examines higher priority rules before lower priority rules) in order to ensure that it first matches the higher priority rule in case another lower priority rule might also be a match for the data message.”: [0254]).
Regarding claim 3, MARKUZE in view of PARAMASIVAM teaches the invention of claim 1 as set forth above. Further, MARKUZE teaches, The method of claim 1, wherein obtaining the ranking data includes: identifying one or more available candidate exit nodes in the service provider infrastructure system, wherein the available candidate exit nodes include the respective exit node (See Fig. 16: exit note for each service providers, SaaD Provider 1 has one Exit Node and SaaS Provider N has different exit Node: : [0219]-[0220]).
Regarding claim 4, MARKUZE in view of PARAMASIVAM teaches the invention of claim 1 as set forth above. Further, MARKUZE teaches, wherein obtaining the ranking data includes: identifying attribute data for the respective exit node (higher priority rule includes including matching date messages: [0254]).
Regarding claim 5, MARKUZE in view of PARAMASIVAM teaches the invention of claim 1 as set forth above. Further, MARKUZE teaches, The method of claim 1, wherein obtaining the ranking data includes: generating test results data for the respective exit node. ( “ measurement agent sends pinging messages (e.g., UDP echo messages) periodically (e.g., once every second, every N seconds, every minute, every M minutes, etc.) to each of the measurement agents of its neighboring managed forwarding nodes. Given the small size of the pinging messages, they do not result in large network connection charges. For instance, for 100 nodes with each node sending a ping to each other node every 10 seconds, about 10 Kb/s of ingress and egress measurement traffic is generated for each node, and this leads to network consumption charges of a few dollars (e.g., $5) per node per year, given the current public cloud prices.”: [0110]).
Regarding claim 7, MARKUZE in view of PARAMASIVAM teaches the invention of claim 1 as set forth above. Further, MARKUZE teaches, wherein:
The method of claim 1, wherein: the service provider infrastructure system is a virtual private network service provider infrastructure system; the communication session includes a client system communicating with the external system; and the service provider infrastructure system receives a protocol data unit associated with the communication session from the client system via a virtual private network tunnel ( “ Some embodiments establish for an entity a virtual network over several public clouds of several public cloud providers and/or in several regions. In some embodiments, the virtual network is an overlay network that spans across several public clouds to interconnect one or more private networks (e.g., networks within branches, divisions, departments of the entity or their associated datacenters), mobile users, and SaaS (Software as a Service) provider machines, and other web applications of the entity. The virtual network in some embodiments can be configured to optimize the routing of the entity's data messages to their destinations for best end-to-end performance, reliability and security, while trying to minimize the routing of this traffic through the Internet. Also, the virtual network in some embodiments can be configured to optimize the layer 4 processing of the data message flows passing through the network.”:[abstract]; virtual private network over public network: [0013]-[0014]; Fig. 16: Virtual Network : [0083]-[0087]).
Regarding claim 9, the claim is interpreted and rejected for the same reason as set forth in claim 2.
Regarding claim 10, the claim is interpreted and rejected for the same reason as set forth in claim 3.
Regarding claim 11, the claim is interpreted and rejected for the same reason as set forth in claim 4.
Regarding claim 12, the claim is interpreted and rejected for the same reason as set forth in claim 5.
Regarding claim 15, the claim is interpreted and rejected for the same reason as set forth in claim 2
Regarding claim 16, the claim is interpreted and rejected for the same reason as set forth in claim 3.
Regarding claim 17, the claim is interpreted and rejected for the same reason as set forth in claim 4.
Regarding claim 18, the claim is interpreted and rejected for the same reason as set forth in claim 5.
Regarding claim 20, the claim is interpreted and rejected for the same reason as set forth in claim 7.
Claims 6, 13, 19 are rejected under 35 U.S.C. 103 as being unpatentable over MARKUZE in view of PARAMASIVAM and further in view of Kumar et al. (US 8776209 B1; hereinafter as “Kumar”).
Regarding claim 6, MARKUZE in view of PARAMASIVAM teaches the invention of claim 5 as set forth above. MARKUZE in view of PARAMASIVAM does not expressively disclose: The method of claim 5, wherein generating the test results data for the respective exit node includes: sending, to the external system, via the respective exit node in the service provider infrastructure system and the respective entry node in the external system, a request to access a resource of the external system; and obtaining data indicating whether the resource is available via the respective exit node in the service provider infrastructure system and the respective entry node in the external system.
Kumar, in the same field of endeavor, discloses:
The method of claim 5, wherein generating the test results data for the respective exit node includes: sending, to the external system, via the respective exit node in the service provider infrastructure system and the respective entry node in the external system, a request to access a resource of the external system (“After establishing a tunneling session, a user directs browser 32 to access protected resource 22 on service provider 16. Browser 32 sends a request 56 to access check module 42 requesting access to protected resource 22. The destination hostname for request 56 may be a hostname that is agreed upon by service provider 16 and the organization associated with VPN gateway 14 ”: Col. 15 lines 54-67, col 16 lines 1-3; and
and obtaining data indicating whether the resource is available via the respective exit node in the service provider infrastructure system and the respective entry node in the external system (“In response to receiving request 56, access check module 42 may determine whether the user identified in request 56 already has an established session with service provider 16. Access check module 42 may determine whether a requester has an established session with service provider 16, for example, by accessing a session token or cookie placed in the requester's browser when the session was established. If the user has an established session with service provider 16, access check module 42 may grant access to protected resource 22. Otherwise, if the user does not have an established tunneling session with service provider 16, then service provider 16 determines that the user will need to be authenticated.”: col. 16 lines 3-40) .
Therefore, 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 teaching of MARKUZE in view of PARAMASIVAM to include the above recited limitations as taught by Kumar. The suggestion/motivation would be providing time and cost savings to the enterprise in comparison to installing such resources and applications onto a network server or onto individual network device (Kumar; [Col. 1 lines 11-22).
Regarding claim 13, the claim is interpreted and rejected for the same reason as set forth in claim 6.
Regarding claim 19, the claim is interpreted and rejected for the same reason as set forth in claim 6.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to M MOSTAZIR RAHMAN whose telephone number is (571)272-4785. The examiner can normally be reached 8:30am-5:00pm 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, Derrick Ferris can be reached at 571-272-3123. 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 Mostazir Rahman/Examiner, Art Unit 2411
/DERRICK W FERRIS/Supervisory Patent Examiner, Art Unit 2411
Prosecution Insights