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 .
Allowable Subject Matter
Claims 5-7 and 19-20 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.
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.
Claims 1-2, 10-12, 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2016/0248658 to Patel et al. (“Patel”) in view of U.S. Patent Publication No. 2019/0158605 to Markuze et al. (“Markuze”).
As to claim 1, Patel discloses a method (Patel: fig 1-14) comprising:
receiving, by a control plane executing on a computing device, values for a plurality of properties of network paths including one or more computing infrastructure elements (Patel: fig 1-14, [0006-138]: cloud-based route reflector (CBRR) 330 includes route reflection capabilities and edge routers ER1-4 and area border routers ABR1-2 are route reflector clients (RR-clients) of CBRR 330 which may be a virtual or physical router in cloud network 315 ... CBRR is not in the forwarding path of the autonomous system and therefore can run BGP-ORR 60 with root selection logic 60 and optimized best path selection logic 62 (receiving ... values for a plurality of properties of network paths) and configured to receive and send control plane information only (... by a control plane executing on a computing device ... paths including one or more computing infrastructure elements) [0061] ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [0045]).
Patel did not explicitly disclose the one or more computing infrastructure elements including at least one of one or more cloud computing networks and one or more colocation providers.
Markuze discloses the one or more computing infrastructure elements including at least one of one or more cloud computing networks and one or more colocation providers (Markuze: fig 1-45, [0023-324]: for optimal routing, multi-homed MMCN measure performance e.g. delay, loss, etc between MMCN and different public datacenters to which MMCN connects (the one or more computing infrastructure elements including at least one of one or more cloud computing networks and one or more colocation providers) ... MMCN equipped with SD-WAN capabilities operating as part of control plane for deploying virtual network implemented by cluster of two or more controllers ... controller cluster identifies a subset of N MFNs from N different cloud regions that are closest to (colocation providers) a particular MMCN edge node ... MFNs have at least one candidate MFN from each cloud provider within a certain distance (colocation providers) of a particular MMCN ... DNS servers operated by virtual network provider(s) ... identifies edge nodes in public clouds that are near (colocation providers) particular MMCNs (the one or more computing infrastructure elements including at least one of one or more cloud computing networks and one or more colocation providers) ... each MMFN edge node has measurement agent that quantify quality of connections to each of the N MFNS in list [0313-317] ... embodiments connect multi-machine compute nodes e.g. branch office or datacenter of a tenant to a tenant’s public cloud virtual network through multiple connection links to multiple public clouds e.g. multiple public data centers ... multi-machine compute nodes (MMCNs) and public cloud virtual networks allows virtual networks to be highly available ... allows best route from each MMCN to each other MMCN or SaaS provider datacenter selecting best ingress node(s) for entering virtual network(s) from MMCN for best routing path through virtual network to egress node(s) for exiting virtual network(s) to another MMCN or SaaS provider datacenter [0310]).
Patel and Markuze are analogous art because they are from the same field of endeavor with respect to virtual networks.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Markuze into the method by Patel. The suggestion/motivation would have been to provide for selecting best ingress node(s) for entering virtual network(s) from MMCN for best routing path through virtual network to egress node(s) for exiting virtual network(s) to another MMCN or SaaS provider datacenter (Markuze: [0310]) and it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network (Patel: [00045]).
Patel and Markuze are receiving, by the control plane (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]),
fee information of the one or more computing infrastructure elements, the fee information including charges for at least one of ingress, egress, and transfer of data with respect to the one or more computing infrastructure elements (Patel: fig 1-14, [0006-138]: edge routers 355 represent ASBRs CEs PEs POPs and any other node provisioned at the edge or perimeter of an autonomous system that can be an egress point and participate in BGP sessions with CBRR 330 in cloud network 315 [0055] ... Area border routers (ABRs) represent routers located near a border of one or more areas or levels of IGP ... ABR1 and ABR2 each provide an ingress and egress point for network traffic flowing to nodes (... at least one of ingress, egress, and transfer of data with respect to the one or more computing infrastructure elements) within their respective routing groups or from nodes in other routing groups ... ABR1 and ABR2 are selected by CBRR 330 as root nodes of their respective clusters A and B [0056] ... routing information in an ORR RIB table 395 may include but not limited to router IDs, IGP metrics e.g. cost, distance (fee information of the one or more computing infrastructure elements) that enable optimum path selection ... measured from a root node of a cluster e.g. ABR1 ABR2 ABR3 (see with [0056] - fee information including charges for at least one of ingress, egress, and transfer of data with respect to the one or more computing infrastructure elements) [0070]);
receiving, by the control plane (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]),
route selection criteria with respect to a first computing device and a second computing device remote from the first computing device (Markuze: fig 1-45, [0023-324]: ... groups of components that form MFNs ... VPN gateways for establishing VPN connections with entity’s compute nodes e.g. offices, private datacenters, remote users etc that are external machine locations outside of public cloud datacenters (... and second computing device(s) remote from the first computing device) ... forwarding elements ... define overlay virtual network over shared public cloud network fabric ... measuring agents for obtaining measurements regarding connection quality (route selection criteria ...) between public cloud datacenters to identify desired paths through public cloud datacenters (... with respect to a first computing device and a second computing device remote from the first computing device) [0074] ... allows different private networks and/or different mobile users of corporate tenant to connect to different public clouds that are in optimal locations e.g. measured in terms of distance, in terms of connection speed, loss, delay and/or cost and/or in terms of network connection reliability etc (see with [0074] - route selection criteria with respect to a first computing device and a second computing device remote from the first computing device) [0085];
Patel: fig 1-14, [0006-138]: ... nodes 50 20 are network elements, such as routers, that offer intra-domain routing for data between end nodes 25 within respective autonomous systems AS1 AS2 ... and inter-domain routing ... and may be physically remote from AS1 accessible over the internet or wide area network that interconnects AS1 with node 30 [0028]);
selecting, by the control plane (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]),
a selected route for connecting the first computing device to the second computing device according to the route selection criteria, values for the plurality of properties, and the fee information (Markuze: fig 1-45, [0023-324]: ... identified routing path for each pair of data message endpoints in a routing path that is deemed optimal based on a set of optimization criteria ... then selects one of the paths based on QoS criteria or other runtime criteria they are enforcing (see with [0074;85] - a selected route for connecting the first computing device to the second computing device according to the route selection criteria, values for the plurality of properties, and the fee information) [0115]); and
configuring, by the control plane (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]),
the one or more computing infrastructure elements to implement the selected route (Markuze: fig 1-45, [0023-324]: ... identified routing path for each pair of data message endpoints in a routing path that is deemed optimal based on a set of optimization criteria ... then selects one of the paths based on QoS criteria or other runtime criteria they are enforcing (see with [0074;85] - the one or more computing infrastructure elements to implement the selected route) [0115]).
Same motivation applies as mentioned above to make the proposed modification.
As to claim 2, Patel and Markuze disclose wherein configuring the one or more computing infrastructure elements to implement the selected route comprising provisioning (Patel: fig 1-14, [0006-138]: a route reflector may be embodied as any type of router, including border or edge router deployed (provisioning) on the perimeter of an autonomous system or as a distributed router in a cloud system ... virtual route reflectors (VRRs) and possibly other route reflectors may be placed within clusters ... or outside of clusters [0037]),
by the control plane (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]),
one or more virtual routers in the one or more computing infrastructure elements (Patel: fig 1-14, [0006-138]: a route reflector may be embodied as any type of router, including border or edge router deployed (provisioning) on the perimeter of an autonomous system or as a distributed router in a cloud system ... virtual route reflectors (VRRs) and possibly other route reflectors may be placed within clusters ... or outside of clusters (one or more virtual routers in the one or more computing infrastructure elements) [0037]).
For motivation, see rejection of claim 1.
As to claim 10, Patel and Markuze disclose configuring the one or more virtual routers to transmit monitoring traffic (Markuze: fig 1-45, [0023-324]: ... controller cluster repeatedly performs costing, graph building and forwarding table updates periodically as it receives measurement updates from measurement agents of the MFNs (see with [0174;177] - configuring the one or more virtual routers to transmit monitoring traffic) [0139] ... figs 9-11 ... message-handling performed respectively by ingress, intermediate and egress MFNs ... controller cluster configures the CFE of each MFN to operate as an ingress, intermediate, and egress CFE, each CFE is a candidate to serve as ingress, intermediate and egress CFE for different data message flows [0174] .. performs a route 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 built over public cloud datacenters (see with [0139] - configuring the one or more virtual routers to transmit monitoring traffic) [0177]).
For motivation, see rejection of claim 1.
As to claim 11, Patel and Markuze disclose wherein the plurality of properties include at least one of latency or throughput (Markuze: fig 1-45, [0023-324]: ... identifies best path between any two MFNs by first costing each link between e.g. based on metric score that reflects a weighted sum of estimated latency and financial cost ... can include link delay measurements, estimated message latency, cloud charges [0138]).
For motivation, see rejection of claim 1.
As to claim 12, Patel and Markuze disclose wherein the plurality of properties include at least one of jitter or packet loss (Markuze: fig 1-45, [0023-324]: ... deemed to be optimal based on set of criteria such as distance, network connection speed, cost, delay and/or loss (see with fig 5 block 510 remove bad links with excessive packet loss), network compute cost, etc [0135]).
For motivation, see rejection of claim 1.
As to claim 14, Patel and Markuze disclose where the route selection criteria includes at least one of a latency requirement and a throughput requirement (Markuze: fig 1-45, [0023-324]: ... identifies best path between any two MFNs by first costing each link between e.g. based on metric score that reflects a weighted sum of estimated latency and financial cost ... can include link delay measurements, estimated message latency, cloud charges [0138]).
For motivation, see rejection of claim 1.
As to claims 15-16, see similar rejection to claims 1-2, respectively, where medium is taught by the method.
Claims 3-4, 8 and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2016/0248658 to Patel et al. (“Patel”) in view of U.S. Patent Publication No. 2019/0158605 to Markuze et al. (“Markuze”) and further in view of U.S. Patent Publication No. 2015/0304206 to Filsfils et al. (“Filsfils”).
As to claim 3, Patel and Markuze disclose the method of claim 1 (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]).
For motivation, see rejection of claim 1.
Patel did not explicitly disclose wherein configuring the one or more computing infrastructure elements to implement the selected route comprising configuring, by the control plane, the one or more virtual routers to implement segment routing.
Filsfils discloses wherein configuring the one or more computing infrastructure elements to implement the selected route comprising configuring, by the control plane, the one or more virtual routers to implement segment routing (Filsfils; fig 1-11, [0006-274]: fig 11 ... block 1110 receive instructions from a controller device (... configuring, by the control plane ...) to segment route a selected flow via particular egress peering segment (configuring the one or more computing infrastructure elements to implement the selected route comprising configuring, by the control plane ...) ... routing services may perform functions related to virtual routing protocols such as maintaining virtual routing and forwarding (VRF) instances (see with fig 11 - the one or more virtual routers to implement segment routing) [0028] ... segment routing with egress peer engineering including solution consisting in running internet routes in a VRF (see with fig 11 - the one or more virtual routers to implement segment routing) [0271]).
Patel, Markuze and Filsfils are analogous art because they are from the same field of endeavor with respect to virtual networks.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Filsfils into the method by Patel and Markuze. The suggestion/motivation would have been to provide for segment routing with egress peer engineering including solution consisting in running internet routes in a VRF (Filsfils: [0271]) and it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network (Patel: [00045]).
As to claim 4, see similar rejection to claim 3 where method is taught by the method.
As to claim 4, Patel, Markuze and Filsfils further disclose wherein configuring the one or more computing infrastructure elements to implement the selected route comprising configuring, by the control plane, a virtual routing function (VRF) for the one or more virtual routers, the VRF corresponding to the selected route (Filsfils; fig 1-11, [0006-274]: fig 11 ... block 1110 receive instructions from a controller device (... configuring, by the control plane ...) to segment route a selected flow via particular egress peering segment (configuring the one or more computing infrastructure elements to implement the selected route comprising configuring, by the control plane ...) ... routing services may perform functions related to virtual routing protocols such as maintaining virtual routing and forwarding (VRF) instances (see with fig 11 - a virtual routing function (VRF) for the one or more virtual routers, the VRF corresponding to the selected route) [0028] ... segment routing with egress peer engineering including solution consisting in running internet routes in a VRF (see with fig 11 - a virtual routing function (VRF) for the one or more virtual routers, the VRF corresponding to the selected route) [0271]).
For motivation, see rejection of claim 3.
As to claim 8, Patel, Markuze and Filsfils disclose wherein selecting the selected route comprises selecting segments according to a segment routing protocol, the segments corresponding to network paths including the one or more computing infrastructure elements (Filsfils; fig 1-11, [0006-274]: ... using MPLS labels as SIDs the SR architecture can be implemented using existing MPLS dataplane with no change on forwarding plane and only minor extensions to existing link-state routing protocols ... a segment may be encoded as an MPLS label, an ordered list of segments encoded as a stack of labels (one example of - selecting the selected route comprises selecting segments according to a segment routing protocol, the segments corresponding to network paths including the one or more computing infrastructure elements) [0031] ... segment routing can also be applied to IPv6 architecture with a new type of routing extension header ... segment may be encoded as an IPv6 address and ordered list of segments encoded as ordered list of IPv6 addresses in the routing extension header (different example of - selecting the selected route comprises selecting segments according to a segment routing protocol, , the segments corresponding to network paths including the one or more computing infrastructure elements) [0032]).
For motivation, see rejection of claim 3.
As to claims 17-18, see similar rejection to claims 3-4, respectively, where medium is taught by the method.
Claims 9 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Patent Publication No. 2016/0248658 to Patel et al. (“Patel”) in view of U.S. Patent Publication No. 2019/0158605 to Markuze et al. (“Markuze”), U.S. Patent Publication No. 2015/0304206 to Filsfils et al. (“Filsfils”) and further in view of U.S. Patent Publication No. 2021/0288902 to Arora et al. (“Arora”).
As to claim 9, Patel, Markuze and Filsfils disclose the method of claim 1 (Patel: fig 1-14, [0006-138]: ... it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network [00045]).
For motivation, see rejection of claim 3.
Patel did not explicitly disclose wherein the values for the plurality of properties of the network paths and the fee information is associated with the segments.
Arora discloses wherein the values for the plurality of properties of the network paths and the fee information is associated with the segments (Arora: fig 1-6, [0004-64]: ... in enhanced segment routing, enhanced BGP AFI/SAFI include fields for carrying relevant business priority information in addition to traditionally provided network parameters (values for the plurality of properties of the network paths ... is associated with the segments) ... business priority information 124(1) may carry values related to bandwidth carrying monetary cost (fee information) e.g. cost per GB to carry data through AS 104(3) and/or performance parameters of AS 104(3) such as bandwidth, availability, latency, reliability, etc (the values for the plurality of properties of the network paths and the fee information is associated with the segments) ... cost values may be added to give a cumulative cost (total cost) ... may add the bandwidth carrying monetary cost values of multiple Ass 104 to arrive at a cumulative cost (total cost) ... therefore, enhanced SR-PCE controller may better respond to requests for segment routes ... performing enhanced segment routing techniques using the collected business priority information [29-32]).
Patel, Markuze, Filsfils and Arora are analogous art because they are from the same field of endeavor with respect to segment routing.
Before the effective filing date, for AIA , it would have been obvious to a person of ordinary skill in the art to incorporate the strategies by Arora into the method by Patel, Markuze and Filsfils. The suggestion/motivation would have been to provide enhanced segment routing across computer networks improving network operations and client services (Arora: [0001]) and it will be apparent that the feature applicable to BGP-ORR network could be extended to any cloud-based router that is incapable of forwarding that needs to be part of a control plane in a network (Patel: [00045]).
As to claim 13, Patel, Markuze, Filsfils and Arora disclose wherein the route selection criteria includes a total cost for transferring data between the first computing device and the second computing device (Arora: fig 1-6, [0004-64]: ... cost values may be added to give a cumulative cost (total cost) ... may add the bandwidth carrying monetary cost values of multiple Ass 104 to arrive at a cumulative cost (total cost) ... therefore, enhanced SR-PCE controller may better respond to requests for segment routes ... performing enhanced segment routing techniques using the collected business priority information [30-32]).
For motivation, see rejection of claim 9.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUNE SISON whose telephone number is (571)270-5693. The examiner can normally be reached 9:00 am - 5:00 pm.
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.
/JUNE SISON/Primary Examiner, Art Unit 2455