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 .
Claims 1 – 20 have been examined and are pending.
Drawings
3. The applicant’s submitted drawings are acceptable for examination purposes.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 05/09/2024 and 12/10/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has been considered by the examiner.
Specification
The disclosure is objected to because of the following informalities: In spec, at ¶74 and ¶110, “a group of agonistic devices” should be “a group of agnostic devices”.
In spec, at ¶123, “a group device identifier” should be --a device group identifier--
Appropriate correction is required.
Claim Objection
Claim 1 is objected to because of the following, “wherein the at least one data traffic route originates from at least one device of the first group of devices” is redundant as it is recited earlier in the claim that the traffic originates from at least a first device. See line 2 “configuring, at least one data traffic route originating from at least one device of a first group of devices”.
Claim 3 is objected to because of the following phrase, “a group of agonistic devices” should be “a group of agnostic devices”. Appropriate correction is required.
Claim 7 is objected to because of the following, it appears references to “first” should be –second—as claim 7 appears to mirror claim 4 but should be referring to second identifier and second set of routers. Appropriate correction is required.
Claims 16 and 18 are objected to because of the following phrase, “a device group identifier” should be –the device group identifier--. Appropriate correction is required.
Claim 17 is objected to because of the following phrase, “a group device identifier” should be “the device group identifier”. 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 – 18 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 teaches (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 teaches (¶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 wherein the at least one data traffic route originates from at least one device of the first group of devices (Sundararajan teaches (¶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).
Sundararajan does not explicitly disclose 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 hub gateway. However, in an analogous art, Chiganmi teaches:
and 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), a 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 the first TGW (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 hub gateway (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 wherein the at least one data traffic route originates from at least one device of the first group of devices, as disclosed by Sundararajan, and 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 hub gateway, 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 2, Sundararajan and Chiganmi disclose all the elements of claim 1. Further they disclose:
sending, by the routing controller (Sundararajan ¶Fig. 5 Network Controller 500), 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 (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) 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). For example, segments 570 can be virtual routing functions)
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 3, Sundararajan and Chiganmi disclose all the elements of claim 2. 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 agonistic 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), the tagged data traffic based on the first identifier for distributing to the first TGW and the first set of routers of the hub gateway (Sundararajan discloses (¶77 - ¶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, do not teach or further define over the limitations in claim 1. Therefore, claim 5 is rejected for the same rationale of rejection as set forth in claim 1.
Claim 6, do not teach or further define over the limitations in claim 2. Therefore, claim 6 is rejected for the same rationale of rejection as set forth in claim 2.
Claim 7, do not teach or further define over the limitations in claim 4. Therefore, claim 7 is rejected for the same rationale of rejection as set forth in claim 4.
Claim 8, do not teach or further define over the limitations in claim 3. Therefore, claim 8 is rejected for the same rationale of rejection as set forth in claim 3.
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 and 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.)
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 a first group of devices, or a second 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)
in response to learning of the data traffic route that originates from at least one device of the first group of devices or the second group of devices, resetting, by the shared TGW, a device group identifier to tag a first data traffic re-originated route or a second data traffic re-originated route (Sundararajan discloses (¶44) dynamic routing protocol is configured to get appropriate next-hop information (i.e. route resetting in response to learning of the data traffic route) 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.)
Sundararajan does not explicitly disclose and redistributing, by the shared TGW, either the first data traffic re-originated route or the second data traffic re-originated route to the first group of devices or the second group of devices. However, in an analogous art, Chiganmi teaches:
and redistributing, by the shared TGW, either the first data traffic re-originated route or the second data traffic re-originated route to the first group of devices or the second group of devices (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. Chiganmi teaches ¶60 enterprise traffic originating from sites 500-1, 500-2, 500-3, 500-4, 500-5, connected to SDWAN fabric. 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).
The motivation to combine the references is similar to the reasons in Claim 1.
Claim 12, Sundararajan and Chiganmi disclose all the elements of claim 11. Further they disclose:
wherein the first data traffic re-originated route or the second data traffic re-originated route corresponds to the first data traffic route or the second data traffic route that originated from the at least one device of the first group of devices, or the second 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 and Chiganmi disclose all the elements of claim 12. Further they disclose:
wherein the shared TGW attracts data traffic from either the first group of devices or the 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 and 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 and Chiganmi disclose all the elements of claim 11. Further they disclose:
acting, by the shared TGW, as a gateway for one or more data traffic routes that originate from either the first group of devices or the 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 and Chiganmi disclose all the elements of claim 15. Further they disclose:
wherein the shared TGW is not configured with a device group identifier to accept data traffic routes that originate from either the first device group of devices or the second 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 and Chiganmi disclose all the elements of claim 11. Further they disclose:
wherein the shared TGW is configured without a group device 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 and 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 resetting of a device group 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.
Claims 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US Patent Application Publication No. 2022/0417060 to Sundararajan, and in view of US Patent Application Publication No. 2024/0333648 to Delecroix (hereinafter Delecroix).
Regarding Claim 19, 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 and 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.)
Sundararajan does not explicitly disclose learning, by the shared TGW, a specific device group identifier that has been tagged for a data traffic route that originates from at least one device of at least one of the first group of devices or the second group of devices, in response to learning of the data traffic route that originates from at least one device of either the first group of devices or the second group of devices, preserving, by the shared TGW, the specific device group identifier for use as an identifier of a data traffic re-originated route that is to be created by the shared TGW, creating, by the shared TGW, the data traffic re-originated route with a specific device identifier using a preserved specific device group identifier to either the first group of devices or the second group of devices. However, in an analogous art, Delecroix teaches:
learning, by the shared TGW, a specific device group identifier that has been tagged for a data traffic route that originates from at least one device of at least one of the first group of devices or the second group of devices (Delecroix discloses (Fig. 1c) Controller 166 (i.e. TGW) with Route Learning Logic configured to learn the routes of different regions and global VPC (¶79 and Fig. 4B) and it maps the tag identifiers 480, 490 of the VPC / Tenant traffic of the on-prem network i.e. group of devices tagged (¶80) with a tag value 480, 490 corresponding to its region)
in response to learning of the data traffic route that originates from at least one device of either the first group of devices or the second group of devices, preserving, by the shared TGW, the specific device group identifier for use as an identifier of a data traffic re-originated route that is to be created by the shared TGW (Delecroix discloses (¶79) preserving and storing the route tags, identifiers and the corresponding mapping in the VPC data store 410 which is programmed and maintained by the control plane and utilized by the multi-cloud network. The data store 410 is configured with a destination IP range (destination subnet) 470, route tags 480 and next hop identifiers 490. The destination IP range 470 identifies the advertised network address. The route tags 480 identify tag values associated with the workloads, such as a first entry pair 411/412 identifies tag values associated with communications sourced by the workload 450 while a second entry pair 413/414 identifies tag values associated with communications sourced by the workload 460)
creating, by the shared TGW, the data traffic re-originated route with a specific device identifier using a preserved specific device group identifier to either the first group of devices or the second group of devices (Delecroix discloses (¶33) controller is configured to detect, without user intervention, one or more route changes, and as a result, re-program routing information using the gateway data store(s) 410)
It would have been obvious as of the effective filing date to one of ordinary skill in the art to combine configuring a shared transport Gateway (TGW) coupled between a set of branch routers and a hub gateway, wherein the set of branch routers comprises a first group of devices and a second group of devices, as disclosed by Sundararajan, and learning, by the shared TGW, a specific device group identifier that has been tagged for a data traffic route that originates from at least one device of at least one of the first group of devices or the second group of devices, in response to learning of the data traffic route that originates from at least one device of either the first group of devices or the second group of devices, preserving, by the shared TGW, the specific device group identifier for use as an identifier of a data traffic re-originated route that is to be created by the shared TGW, creating, by the shared TGW, the data traffic re-originated route with a specific device identifier using a preserved specific device group identifier to either the first group of devices or the second group of devices, as taught by Delecroix, for the purpose of implementing (¶2) a software-defined cloud overlay network with ingress and egress based on regional preference.
Claim 20, Sundararajan and Delecroix disclose all the elements of claim 19. Further they disclose:
in response to tagging of the data traffic re-originated route, 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 (¶55) segment routers are grouped based on a tag. Sundararajan discloses (¶77 - ¶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 identifier-tag data traffic) received by network controller 500, between interconnect gateway 550, and virtual network(s) 520, via the connectivity gateway 530. Sundararajan discloses (¶109) once the tag (i.e. the identifier) is modified, network controller can detect and adjust the connectivity accordingly.)
The motivation to combine the references is similar to the reasons in Claim 19.
Conclusion
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
U.S. Patent Application Publication No. 2018/0278517 to Narayanan et al. (EFFICIENT ALGORITHM TO ELIMINATE REDUNDANT SPECIFIC PREFIXES IN FORWARDING INFORMATION BASE USING TRIE)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HASSAN KHAN whose telephone number is (313) 446-6574 and fax number is (571) 483-7559. The examiner can normally be reached on MONDAY - THURSDAY.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor Christopher L. Parry can be reached on (571) 272-8328. 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:/Awww.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.
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:/Awww.uspto.gov/interviewpractice.
/H. A. K./
Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451