DETAILED ACTION
1. Claims 1, 3, 5, 7, 11 – 13 and 15 – 20 have been amended.
2. Claim 2 has been cancelled.
3. Claims 1 and 3 – 20 have been examined and are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
Claims 11-18 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
As for Claims 11 and 18, the specification fails to provide support for the limitation(s) “clearing” as recited in Claims 11 and 18, wherein the specification recites reset or resetting (e.g. 0023, 0052, 0085, 0119, 0126). For examining purposes, the Office will consider “clearing the device group identifier” as an equivalent to resetting and/or updating the tag.
Appropriate correction is required.
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 and 9 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2022/0417060 to Sundararajan et al. (hereinafter Sundararajan) in view of US Patent Application Publication No. 2022/0329477 to Chiganmi (hereinafter Chiganmi).
Regarding Claim 1, Sundararajan discloses (¶2) methods and apparatus for automating connectivity to cloud resources, which further includes:
configuring, by a routing controller (Sundararajan discloses (¶49 and Fig. 5) network controller 500 i.e. a routing controller, sending requests and configurations to connect the connectivity gateway 530 and interconnect gateway 550 to any of segments 570-1, 570-2, or 570-3 to any of virtual networks 520-1, 520-2, or 520-3), at least one data traffic route originating (Sundararajan discloses (Fig. 5 and ¶57) data link layer connection originating in interconnect gateway 550 and extending to connectivity gateway 530) from at least one device of a first group of devices (Sundararajan discloses (Fig. 5, ¶50, ¶55) SDWAN fabric 560 can be an on-premises network containing segments 570-1, 570-2, or 570-3 (collectively segments 570 i.e. group of virtual routing functions), and network controller 500 provides connectivity from segments 570) to a first transport gateway (TGW) (Sundararajan discloses (Fig. 5, ¶49) network controller 500 send a configuration to interconnect gateway 550 i.e. transport gateway) and a gateway hub (Sundararajan discloses (Fig. 5, ¶48) a network capable of automating connectivity to cloud resources, wherein the network controller 500 provide configurations and requests to connectivity gateway 530 i.e. a gateway hub).
tagging, by the routing controller (Sundararajan discloses (Fig. 6B and ¶55, ¶108) creating a tag by Network Controller 500, as part of an interconnect connection creation), the at least one data traffic route with a first identifier associated with the first group of devices (Sundararajan discloses (¶55) establishing connectivity from segments 570 to virtual networks 520 and a tag can associated a segment(s) and a virtual network based on one or more factors such as, a common attribute (e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc.), a relationship, a preference, etc.) to send to the first TGW and to a first set of routers of the hub gateway (Sundararajan discloses (¶55-56) connectivity enabled by tags received by network controller 500 indicating that a connection between a segment 570 and a virtual network 520 is established. The tags can map or associate a segment (e.g., a virtual network, a routing domain, a prefix, a subnet, etc.) of the SDWAN fabric 560 to a virtual network (e.g., a virtual private network or routing domain, etc.) in the cloud environment 510, which establishes connectivity between the segment in the SDWAN fabric 560 and the virtual network in the cloud environment 510)
sending, by the routing controller (Sundararajan discloses ¶Fig. 5 Network Controller 500), a tagged data traffic route originating from at least one device of the first group of devices based on the first identifier (Sundararajan discloses (in ¶55 and Fig. 5) connectivity enabled by tags (i.e. first identifier) between a plurality of devices from the group i.e. virtual network 520) to the first TGW and the first set of routers of the gateway hub (Sundararajan discloses tagging the virtual network traffic with a tag (¶118) and the network controller routing the traffic (¶48-¶50 and Figs. 1 and 5) to the first TGW i.e. Connectivity Gateway 530 and further to the first set of routers (i.e. Inter segments 570 - 1,2,3) of the gateway hub i.e. interconnect gateway 550. SDWAN fabric 560 can be a network similar to data center 150, campus 152, brand office 154 or home office 156 or networks 204A and 204B (Fig. 2). The SDWAN fabric 560 can be an on-premises network containing segments 570-1, 570-2, and 570-3 (collectively segments 570). For example, segments 570 can be virtual routing functions)
Sundararajan does not explicitly disclose sending, by the routing controller, the tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to other devices in the first group of devices. However, in an analogous art, Chiganmi teaches:
sending, by the routing controller (Chiganmi discloses (¶30) network controller 132 to establish routes and orchestrate secure connectivity in the data place 140 between and among the edge network devices 142), the tagged data (Chiganmi teaches ¶72 virtual cloud resource VCR tag) traffic route originating from at least one device of the first group of devices (Chiganmi teaches ¶60 enterprise traffic originating from sites 500-1, 500-2, 500-3, 500-4, 500-5, collectively “sites 500”, connected to SDWAN fabric) based on the first identifier to other devices in the first group of devices (Chiganmi teaches ¶39 learning the prefixes and then advertising the routes on attributes such as site identifier, tag, VPN, preference to other devices. Chiganmi teaches ¶50 interconnect gateways 550 as the TGW and routing the traffic (¶60) based on the first identifier i.e. SDCI underlay hands off to a cloud service provider 560 for any virtual cloud resource (VCR) tags corresponding to virtual cloud resources 590 which are to be connected to a site 500) and the first set of routers of the gateway hub, wherein Chiganmi teaches ¶50 hub gateways i.e. connectivity gateways 570 can be routers or network edge devices).
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine configuring, by a routing controller, at least one data traffic route originating from at least one device of a first group of devices to a first transport gateway (TGW) and a gateway hub, tagging, by the routing controller, the at least one data traffic route with a first identifier associated with the first group of devices, to send to the first TGW and to a first set of routers of the hub gateway, sending, by the routing controller, a tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to the first TGW and the first set of routers of the gateway hub, as disclosed by Sundararajan, and sending, by the routing controller, the tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to other devices in the first group of devices, as taught by Chiganmi, for the purpose of implementing (¶2) methods, systems, and non-transitory computer-readable storage media for automating and scaling multi-level redundancy for cloud infrastructure.
Claim 3, Sundararajan and Chiganmi disclose all the elements of claim 1. Further they disclose:
sending, by the routing controller, the tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to at least one device configured in an overlay of a group of agnostic devices (Sundararajan discloses ¶39 the network controller appliance 132 can operate similarly to a route reflector. For example, the network controller appliance 132 can receive routes from the edge network devices 142, process and apply any policies to them, and advertise routes to other edge network devices 142 in the overlay.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 4, Sundararajan and Chiganmi disclose all the elements of claim 3. Further they disclose:
filtering, by the routing controller (Sundararajan discloses ¶77 filtering of the VXC traffic by the network controller 500. Further, Sundararajan discloses (¶78) an implicit filtering of the virtual cross connect layer 2 data link layer connection traffic (VXC) by network controller 500 which validates the request (i.e. it permit or allow or filter them through) and establish connectivity, specified by the tag (i.e. on the basis of the tagged data traffic) received by network controller 500, between interconnect gateway 550 and virtual network(s) 520 via the connectivity gateway 530.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 5, Sundararajan and Chiganmi disclose all the elements of claim 1. Further they disclose:
configuring, by the routing controller, at least one data traffic route originating from at least one device of a second group of devices to a second TGW and the gateway hub (Chiganmi teaches discloses (¶30) network controller 132 to establish routes and orchestrate secure connectivity in the data place 140 such as establishing network redundancy (55 and Fig. 5B) by configuring connectivity between a first interconnect gateway 550 in a first SDCI network 540 and a first connectivity gateway 570, and then configuring connectivity between a second interconnect gateway 550 in a second SDCI network 540 and a second connectivity gateway 570)
tagging, by the routing controller, the at least one data traffic route with a second identifier associated with the second group of devices to send to the second TGW and to a second set of routers of the gateway hub, wherein the at least one data traffic route originates from at least one device of the second group of devices (Chiganmi teaches (¶17) configuring a VCR connection between at least one VCR associated with the at least one VCR tag and the handoff locations for the at least one VCR. Chiganmi teaches (¶35) the method can also include configuring a “color” to identify an individual WAN transport network, and different WAN transport networks may be assigned different colors (e.g., mpls, private1, biz-internet, metro-ethernet, lte, etc.). In this example, the network topology 200 can utilize a color called “biz-internet” for the Internet transport network 160A and a color called “public-internet” for the Internet transport network 160B)
sending, by the routing controller, a tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to the second TGW and the second set of routers of the gateway hub (Chiganmi teaches (¶72) network orchestrator appliance 104 illustrated in FIG. 1 may configure a virtual layer 2 connection between the plurality of SDWAN routers and handoff locations for at least one VCR associated with at least one VCR tag. A VCR tag can logically group workloads and/or routing domains (e.g., virtual networks, prefixes, tenant spaces, etc.) having a common characteristic(s) such as, for example, a common security group, a common network, a common routing domain, a common applicable policy, a common entity, a common function, a common tenant, a common type of traffic, a common type of workload, a common application/service, etc. Chiganmi teaches (¶37) the public colors may be used by the edge network devices 142 to build tunnels to post-NAT IP addresses. If the edge network devices 142 use private colors and need NAT to communicate to other private colors, the carrier setting in the configuration can dictate whether the edge network devices 142 use private or public IP addresses, and using this setting, two private colors can establish a session.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 9, Sundararajan and Chiganmi disclose all the elements of claim 2. Further they disclose:
wherein the first TGW comprises a first dedicated TGW (Sundararajan discloses ¶30 the network management appliance(s) 122 can be a dedicated network management system for a single entity).
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 10, do not teach or further define over the limitations in claim 9. Therefore, claim 10 is rejected for the same rationale of rejection as set forth in claim 9.
Regarding Claim 11, Sundararajan discloses (¶2) methods and apparatus for automating connectivity to cloud resources, which further includes:
configuring a shared Transport Gateway (TGW) coupled between a set of branch routers and a hub gateway (Sundararajan discloses (Fig. 5) a shared interconnect gateway 550 (i.e. Transport Gateway TGW) coupled between a set of segment routers 570-1, 570-2, 570-3 (i.e. branch routers) and a connectivity gateway 530 i.e. hub gateway)
wherein the set of branch routers comprises a first group of devices (Sundararajan discloses (¶55) segment routers are grouped based on a tag that is based on one or more factors such as, for example and without limitation, a common attribute (e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc.), a relationship, a preference, etc.)
learning, by the shared TGW, one or more data traffic routes (Sundararajan discloses (¶40) various types of routes and prefixes are learned from the local site, or service side, of the edge network device 142) that originate from at least one device of the first group of devices (Sundararajan discloses (¶40-¶47) dynamically mapping cloud resources to network segments of network sites such as on-premises networks and prefixes can be originated as static or connected routes, or from within, and redistributed. Sundararajan discloses (¶44) dynamic routing protocol is configured to get appropriate next-hop information so that the control plane may be established and IPSec tunnels can connect to remote sites. Sundararajan discloses (¶39) control plane information, such as route prefixes, next-hop routes, crypto keys, policy information, and so forth, can be exchanged over respective secure DTLS or TLS connections)
the learning including learning a device group identifier for the first group of devices (Sundararajan discloses (¶121) automatically discovers connections affected by the tag i.e. a device group identifier)
in response to the learning clearing by the shared TGW, the device group identifier to enable traffic to be routed through the shared TGW (Sundararajan discloses (¶121) the method 700 include updating the tag, automatically discovering connections affected by the tag, automatically discovering one or more virtual networks on the cloud environment affected by the tag and attaching a new cloud gateway to the one or more virtual networks affected by the tag)
redistributing by the shared TGW, routing data to the first group of devices (Sundararajan discloses (¶122) discloses updating an existing routing table for the one or more virtual networks affected by the tag; enabling route propagation based on the existing routing table; and attaching the new cloud gateway to an affected connectivity gateway belonging to the connections affected by the tag and the one or more virtual networks affected by the tag, wherein updating the tag comprises adding one or more new Virtual networks corresponding to the one or more virtual networks to the tag.)
Sundararajan does not explicitly disclose the routing data indicating that traffic for the at least one device of the first group of devices is to be routed through the shared TGW. However, in an analogous art, Chiganmi teaches:
the routing data (Chiganmi teaches ¶39 learning the prefixes and then advertising the routes on attributes such as site identifier, tag, VPN, preference to other devices) indicating that traffic for the at least one device of the first group of devices is to be routed through the shared TGW (Chiganmi teaches (¶50) the TGW i.e. the interconnect gateways 550 routing the traffic (¶60) based on the first identifier i.e. SDCI underlay hands off to a cloud service provider 560 for any virtual cloud resource (VCR) tags corresponding to virtual cloud resources 590 which are to be connected to a site 500)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 12, Sundararajan in view of Chiganmi disclose all the elements of claim 11. Further they disclose:
wherein the routing data indicates a re-originated route for the at least one device of the first group of devices (Sundararajan discloses (¶55) segment routers are grouped based on tag. Sundararajan discloses ¶40 Overlay Management Protocol (OMP) advertise various types of routes, which correspond to prefixes that are learned from the local site, or service side, of the edge network device(s) 142 (Fig. 1). The prefixes can be originated as static or connected routes, or from within, for example, the OSPF or BGP protocols, and the routes can advertise attributes such as transport location and other attributes such as origin, originator, preference, site identifier, tag, and virtual private network)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 13, Sundararajan in view of Chiganmi disclose all the elements of claim 12. Further they disclose:
wherein the shared TGW attracts data traffic from the first group of devices and a second group of devices (Sundararajan discloses (¶55) segment routers are grouped based on tag. Sundararajan discloses ¶55 a tag can associate segment(s) 570-1, 570-2, and 570-3 and virtual network(s) based on one or more shared common attributes (e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc.), a relationship, a preference, etc.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 14, Sundararajan in view of Chiganmi disclose all the elements of claim 13. Further they disclose:
creating, by the shared TGW, one or more re-originated routes that correspond to one or more learned data traffic-originated routes (Sundararajan discloses ¶40 the OMP advertise various types of routes, which correspond to prefixes that are learned from the local site, or service side, of the edge network device(s) 142 as shown in Fig. 1).
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 15, Sundararajan in view of Chiganmi disclose all the elements of claim 11. Further they disclose:
acting, by the shared TGW, as a gateway for (i) one or more data traffic routes that originate from the first group of devices or the second group of devices and (ii) one or more data traffic routes that originate from a second group of devices (Sundararajan discloses (¶55) segment routers are grouped based on a tag that is based on one or more factors such as, for example and without limitation, a common attribute (e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc.), a relationship, a preference, etc. Network controller routes traffic between shared TGW (i.e. interconnect gateway 550) and corresponding segment 570 and virtual network 520 via connectivity gateway 530.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 16, Sundararajan in view of Chiganmi disclose all the elements of claim 15. Further they disclose:
wherein the shared TGW is not configured with a group device identifier to accept data traffic routes that originate from the first device group of devices (Sundararajan discloses (¶55) segment routers are grouped based on a tag. Sundararajan discloses (¶117) the method 700 can include adding, to the routing table, a default route pointing to the cloud gateway which enables route propagation associating the cloud gateway to the connectivity gateway.)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 17, Sundararajan in view of Chiganmi disclose all the elements of claim 11. Further they disclose:
wherein the shared TGW is configured without the device group identifier enables the shared TGW to act as a gateway for data traffic routes from a plurality of device groups (Sundararajan discloses (¶55) segment routers are grouped based on a tag. Sundararajan discloses (¶109) if the tag is modified, network controller can detect and adjust the connectivity accordingly. Sundararajan discloses (¶117) adding, to the routing table, a default route pointing to the cloud gateway which enables route propagation associating the cloud gateway to the connectivity gateway)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 18, Sundararajan in view of Chiganmi disclose all the elements of claim 11. Further they disclose:
wherein one or more data traffic re-originated routes avoids being subject to outbound filtering by a routing controller based on clearing of a group device identifier to be used by the re-originated routes that enables the shared TGW to act as a gateway for inter-device group traffic between one or more devices of a device group (Sundararajan discloses (¶55) segment routers are grouped based on a tag. Sundararajan discloses (¶109) if the tag is modified, network controller can detect and adjust the connectivity accordingly. Sundararajan discloses (¶117) adding, to the routing table, a default route pointing to the cloud gateway which enables route propagation associating the cloud gateway to the connectivity gateway)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 19, do not teach or further define over the limitations in claim 11. Therefore, claim 19 is rejected for the same rationale of rejection as set forth in claim 11.
Claim 20, Sundararajan, Chiganmi and Jain disclose all the elements of claim 19. Further they disclose:
filtering, by a routing controller, re-originated data route traffic being sent from at least one device of either the first group of devices or the second group of devices based on the device group identifier (Sundararajan discloses ¶77 filtering of the VXC traffic by the network controller 500. Sundararajan discloses (¶78) an implicit filtering of the virtual cross connect layer 2 data link layer connection traffic (VXC) by network controller 500 which validates the request (i.e. it permit or allow or filter them through) and establish connectivity, specified by the tag (i.e. on the basis of the tagged data traffic) received by network controller 500, between interconnect gateway 550 and virtual network(s) 520 via the connectivity gateway 530)
The motivation to combine the references is similar to the reasons in Claim 1.
Claims 6 – 8 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2022/0417060 to Sundararajan, in view of US Patent Application Publication No. 2022/0329477 to Chiganmi and in view of US Patent Application Publication No. 2024/0073127 to Jain (hereinafter Jain).
Claim 6, Sundararajan in view of Chiganmi disclose all the elements of claim 5. Sundararajan in view of Chiganmi does not explicitly disclose sending, by the routing controller, the tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to other devices in the second device group. However, in an analogous art, Jain teaches:
sending, by the routing controller, the tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to other devices in the second device group (Jain teaches (¶Fig. 2:202) a software-defined-networking (SDN) controller configured to implement jurisdictional data sovereignty policies to route network traffic between user sites using the destination group tags (DGTs, ¶Fig. 2:204) and source group tags (SGTs, ¶Fig. 2:206), and determining based in part on the DGT and the SGT, a routing operation to perform (¶Fig. 2:214) associated with the network traffic flow).
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine configuring, by the routing controller, at least one data traffic route originating from at least one device of a second group of devices to a second TGW and the gateway hub, tagging, by the routing controller, the at least one data traffic route with a second identifier associated with the second group of devices to send to the second TGW and to a second set of routers of the gateway hub, wherein the at least one data traffic route originates from at least one device of the second group of devices, sending, by the routing controller, a tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to the second TGW and the second set of routers of the gateway hub, as disclosed by Sundararajan in view of Chiganmi, and sending, by the routing controller, the tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to other devices in the second device group, as taught by Jain, for the purpose of implementing (¶1) jurisdictional data sovereignty policies providing region specific data sovereignty, regional breakouts, and service insertion within multisite networks.
Claim 7, Sundararajan, Chiganmi and Jain disclose all the elements of claim 6. Further they disclose:
filtering, by the routing controller, the tagged data traffic based on the second identifier for distributing to the second TGW and the second set of routers of the gateway hub (Sundararajan discloses ¶77 filtering of the VXC traffic by the network controller 500. Sundararajan discloses (¶78) an implicit filtering of the virtual cross connect layer 2 data link layer connection traffic (VXC) by network controller 500 which validates the request (i.e. it permit or allow or filter them through) and establish connectivity, specified by the tag (i.e. on the basis of the tagged data traffic) received by network controller 500, between interconnect gateway 550 and virtual network(s) 520 via the connectivity gateway 530.)
The motivation to combine the references is similar to the reasons in Claim 6.
Claim 8, Sundararajan, Chiganmi and Jain disclose all the elements of claim 6. Further they disclose:
sending, by the routing controller, the tagged data traffic route originating from at least one device of the second group of devices based on the second identifier to at least one device configured in an overlay of group of agnostic devices (Sundararajan discloses ¶39 the network controller appliance 132 can operate similarly to a route reflector. For example, the network controller appliance 132 can receive routes from the edge network devices 142, process and apply any policies to them, and advertise routes to other edge network devices 142 in the overlay. The edge network devices 142 are then responsible for traffic forwarding (¶32) and routing (e.g., BGP, OSPF, etc.), among other tasks.)
The motivation to combine the references is similar to the reasons in Claim 6.
Response to Arguments
Claim Rejections - 35 USC § 103
Applicant’s arguments and amendments, filed on 05/04/2026 with respect to the Claims 1 – 5 and 9 – 20 have been fully considered and they are not persuasive. Hence, the 35 USC § 103 rejection is maintained.
Applicant’s arguments and amendments, filed on 05/04/2026 with respect to the Claims 6 – 8 have been fully considered and they are persuasive. Hence, the 35 USC § 103 rejection is withdrawn. However, based on the claim amendments and the newly introduced limitations, the search is updated and a new reference, US Patent Application Publication No. 2024/0073127 to Jain has been introduced for the 35 USC § 103 rejection.
In response to Applicant’s argument on Page 9 of 13, “Applicant respectfully submits that the Office has not shown that Sundarajan teaches at least the following features of Applicant's amended claim 1: tagging, by the routing controller, the at least one data traffic route with a first identifier associated with the first group of devices to send to the first TGW and to a first set of routers of the hub gateway; sending, by the routing controller, a tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to the first TGW and the first set of routers of the gateway hub; and sending, by the routing controller, the tagged data traffic route originating from at least one device of the first group of devices based on the first identifier to other devices in the first group of devices,” the Examiner notes that the combination of Sundararajan and Chiganmi clearly discloses (Fig. 6B and ¶55, ¶108) creating a tag by Network Controller 500. Further, Sundararajan discloses (¶55) establishing connectivity from segments 570 to virtual networks 520 and the tags are associated with segment(s) and virtual networks based on one or more factors such as, a common attribute e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc., a relationship, a preference, etc. Then, Sundararajan discloses (¶56) enabling connectivity by using tags as received by the network controller 500 indicating that the tags can map or associate a segment (e.g., a virtual network, a routing domain, a prefix, a subnet, etc.) of the SDWAN fabric 560 to a virtual network in the cloud environment 510, which establishes connectivity between the segment in the SDWAN fabric 560 and the virtual network in the cloud environment 510. Also, Sundararajan discloses ¶Fig. 5 Network Controller 500 tagging the virtual network traffic with a tag (¶118) and the network controller routing the traffic (¶48-¶50 and Figs. 1 and 5) between the segments 570-1,2,3, virtual networks 520-1,2,3 the interconnect gateway 550 and connectivity gateway 530. SDWAN fabric 560 can be a network similar to data center 150, campus 152, brand office 154 or home office 156 or networks 204A and 204B (Fig. 2). The SDWAN fabric 560 can be an on-premises network containing segments 570-1, 570-2, and 570-3 (collectively segments 570). Moreover, Chiganmi discloses (¶30) network controller 132 to establish routes and orchestrate secure connectivity in the data place 140 between and among the edge network devices 142 and teaches ¶72 virtual cloud resource VCR tag and teaches ¶39 learning the prefixes and then advertising the routes on attributes such as site identifier, tag, VPN, preference to other devices. Chiganmi teaches ¶50 interconnect gateways 550 as the TGW and routing the traffic (¶60) based on the first identifier i.e. SDCI underlay hands off to a cloud service provider 560 for any virtual cloud resource (VCR) tags corresponding to virtual cloud resources 590 which are to be connected to a site 500) and the first set of routers of the gateway hub, wherein Chiganmi teaches ¶50 hub gateways i.e. connectivity gateways 570 can be routers or network edge devices and teaches (¶60) routing of the enterprise traffic originating from sites 500-1, 500-2, 500-3, 500-4, 500-5, collectively “sites 500”, connected to SDWAN.
In response to Applicant’s argument on Page 10 of 13, “the Office has not shown that Sundarajan teaches at least the following features of Applicant's amended claim 11: learning, by the shared TGW, one or more data traffic routes that originate from at least one device of the first group of devices, the learning including learning a device group identifier for the first group of devices; in response to the learning, clearing, by the shared TGW, the device group identifier to enable traffic to be routed through the shared TGW; and redistributing, by the shared TGW, routing data to the first group of devices, the routing data indicating that traffic for the at least one device of the first group of devices is to be routed through the shared TGW,” the Examiner notes that the combination of Sundararajan and Chiganmi clearly discloses (Fig. 5) a shared interconnect gateway 550 (i.e. Transport Gateway TGW) coupled between a set of segment routers 570-1, 570-2, 570-3 (i.e. branch routers) and a connectivity gateway 530 (i.e. hub gateway), wherein Sundararajan discloses (¶55) segment routers are grouped based on a tag that is based on one or more factors such as, for example and without limitation, a common attribute (e.g., a common service or functionality, a common set of associated users/groups/devices, a common security group or policy, a common set of requirements, etc.), a relationship, a preference, etc. Further, Sundararajan discloses (¶121) automatically discovers connections affected by the tag i.e. a device group identifier. Sundararajan discloses (¶121) the method 700 include updating the tag, automatically discovering connections affected by the tag, automatically discovering one or more virtual networks on the cloud environment affected by the tag and attaching a new cloud gateway to the one or more virtual networks affected by the tag. Moreover, Sundararajan discloses (¶122) discloses updating an existing routing table for the one or more virtual networks affected by the tag; enabling route propagation based on the existing routing table; and attaching the new cloud gateway to an affected connectivity gateway belonging to the connections affected by the tag and the one or more virtual networks affected by the tag, wherein updating the tag comprises adding one or more new Virtual networks corresponding to the one or more virtual networks to the tag.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN ABDUR-RAHMAN KHAN whose telephone number is (313)446-6574. The examiner can normally be reached TEAPP - (M-Sa) 9/30/17-9/30/18, 6am-10pm IFP.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached at (571) 272-8328. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/H. A. K./
Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451
Prosecution Insights