DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the Amendment filed on July 8, 2026, in which claims 1 and 19 have been amended. Accordingly, claims 1-20 remain pending for examination.
Status of Claims
3. Claims 1-20 are pending, of which claims 1-15 and 17-20 are rejected under 35 U.S.C. 103. Claims 1-20 are also rejected under 35 U.S.C. 101.
Response to Arguments
4. Applicant’s arguments, see pages 8-9, filed July 8, 2026, with respect to Objections of Claims 8, 9 and 19 have been fully considered and are persuasive. The Objections of Claims 8, 9 and 19, as set forth in the previous Office action, have been withdrawn.
5. Applicant’s arguments, see pages 9-10, filed July 8, 2026, have been fully considered but they are not persuasive.
(A) Applicant argued on pages 9-10 of Remarks, “Without conceding to the appropriateness of the rejection and solely in the interest of advancing prosecution, claims 1 and 19 are amended based on paragraph [0084] of the Specification. For example, amended claim 1 recites, in part, ‘applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected” (Recited from page 9 of Remarks). “Even assuming arguendo that a human mind can ‘writ[e] out’ the section to which the multi-transmission path policy, in which Applicant does not concede, a human mind cannot practically apply the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected. That is, a human mind cannot ‘writ[e] out’ the policy to the interface of the PE such that the policy is applied to the interface of the PE. In addition, hardware elements such as the PE and the CE are not directed to generic computer elements such as ‘processors’ and ‘memory’ as alleged by the Examiner. Therefore, Applicant respectfully submits that at least the claimed feature of ‘applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected’ cannot be performed in the human mind” (Recited from pages 9-10 of Remarks).
As to point (A), Examiner respectfully disagrees. To begin with, Examiner wishes to point out that while the use of physical aids would be used by most humans (e.g., graph paper, pen and/or pencil for writing/drawing a series of nodes and their corresponding links/edges to represent a network map, and then determining where - i.e., which region/subregion of the graph - to apply a multipath policy), nevertheless, this does not negate the mental nature of the “setting” and “completing” limitations. As well, while Applicant has amended independent claim 1 to now include the limitation of “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected,” and has likewise amended independent claim 19 to now recite the limitation of “an operation of applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected,” nevertheless, this fails to result in either an inventive concept, integration of a practical application of the judicial exception (i.e., the abstract idea) in Step 2A Prong 2, or reciting significantly more than the exception in Step 2B, because the newly added limitation fails to impose any meaningful limits on practicing the abstract idea, as 1) it amounts to mere instructions to “apply” what is performed in the limitations above (i.e., the abstract idea and results thereof) to an interface of a provider edge (PE) equipment, and/or 2) it merely recites post insignificant extra-solution activity. That is, the newly added “applying” limitation fails to go into any detail whatsoever with respect to how the “multi-transmission path policy” is applied to the interface of the PE (i.e., whether the PE provisioned with rules, policies or how paths are selected, whether quality of service (QoS) characteristics are taken into account, etc.). The claims are completely silent in this regard and merely recite a broadly drafted notion/idea of “applying” the “multi-transmission path policy” to an interface of a PE, without going into any detail as to what that means. Moreover, while Applicant argues that “hardware elements such as the PE and the CE are not directed to generic computer elements such as ‘processors’ and ‘memory’,” nonetheless, Examiner respectfully points out that the recited “PE” and “CE” are not actually being used to implement the abstract idea. Rather, the recited “PE” is a network element (i.e., provider edge router) that the solution of the abstract idea is now being provided to (i.e., “applied to”), and which happens to be “somehow” connected to a customer equipment (CE). As noted in the Non-Final rejection mailed April 8, 2026, hereinafter “Non-Final Rejection,” however, Examiner illustrated that the “computing system” of claim 1 and the “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” and “a storage storing the computer program, wherein the computer program comprises instructions” of claim 19 are recited at a high-level of generality (i.e., as generic processors/systems/memories performing a generic computer function of setting a multi-transmission path policy for the virtual network domain, and completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied (as evidenced from, and described in paragraphs [0113]-[0115] and [0118] of Applicant’s instant Specification)). To reiterate, mere instructions to “apply” an exception using generic computer components cannot provide an inventive concept. Furthermore, as indicated in the Non-Final Rejection, under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A, prong two should be re-evaluated in Step 2B. Here, the applying step can also be considered to be post-insignificant extra-solution activity, in prong two of Step 2A, and thus is re-evaluated in Step 2B to determine if it is more than what is well-understood, routine, conventional activity in the field. Again, the instant Specification does not provide any indication that the “computing system,” “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” and “a storage storing the computer program, wherein the computer program comprises instructions” are anything other than generic, off-the-shelf computer components (See again, instant Specification, paragraphs [0113]-[0115] and [0118]), and the cited Network Working Group RFC documents, namely, RFC 4364, which was published in February 2006, as well as RFC 2547, which was published in March 1999, demonstrate that the process of applying a multipath policy to the interfaces of provider edge (PE) devices, which connect to customer edge (CE) devices, or otherwise, “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected,” as currently being recited in each of independent claims 1 and 19, is a well-understood, routine, and conventional function when claimed in a merely generic manner (as it is here). Again, Examiner notes the evidentiary requirement from MPEP § 2106.07(a), section III to expressly support the rejection in writing with a citation to a publication that demonstrates the well-understood, routine, conventional nature of the additional element(s), in lieu of a citation to one or more of the court decisions discussed in MPEP § 2106.05(d), subsection II. Accordingly, a conclusion that the newly added “applying” step is a well-understood, routine, conventional activity is supported under Berkheimer. For these reasons, there is no inventive concept in the claims, and thus the claims are not patent eligible. Therefore, Examiner respectfully submits, amended claims 1 and 19 still fail to satisfy the eligibility requirement under 35 U.S.C. 101.
6. Applicant’s arguments, see pages 10-13, filed July 8, 2026, have been fully considered but they are not persuasive.
(A) Applicant argued on page 12 of Remarks, “Applicant respectfully submits that the cited references, either individually or in combination, do not teach or suggest the claimed feature of ‘applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected.’ For example, Bahl merely describes a stitching component 250 that provides a routing policy 252 to the routing agent 230. Bahl at paragraph [0036]. The routing agent 230 is responsible for configuring the partner network 210 to route traffic according to the routing policy. Id at paragraph [0044]. However, Bahl does not teach that the routing agent 230 applies a multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected. That is, the routing agent 230 does not apply a policy to an interface of an edge equipment of a WAN that is connected to another edge equipment of the partner network. Therefore, Applicant respectfully submits that the cited references, either individually or in combination, do not teach or suggest claim 1. Based on at least the above reasons, Applicant respectfully submits that independent claim 1 is patentable over the cited references. “Amended independent claim 19 recites similar features as noted above with respect to claim 1. Therefore, Applicant respectfully submits that claim 19 is patentable for similar reasons as noted above with respect to claim 1” (Recited from page 12 of Remarks).
As to point (A), Examiner respectfully disagrees. As discussed and shown in the Non-Final Rejection, Bahl teaches that the partner network 210 (See again, FIG. 2), which includes a number of virtual network entities 212, each of which comprise routers 112 and user plane functions (UPFs) 106, may be a customer of the wide area network (WAN) 240, and pay for routing traffic from sources to destinations (See Bahl, FIG. 2, paragraphs [0042]-[0043]). As such, Examiner thus interprets Bahl to disclose partner network 210 as comprising a number of customer equipments (“CEs”), as again, partner network 210 is a customer of WAN 240. Furthermore, WAN 240, as discussed and shown by Examiner in the Non-Final Rejection, includes a number of virtual network entities 242 (See again, FIG. 2), each of which may be associated with a geographic location and represent physical computing resources controlled by the WAN 240 in the geographic location (See Bahl, FIG. 2, paragraph [0037]). Examiner further wishes to point out that the virtual network entities 242 of FIG. 2 may be viewed as being analogous to the front-end devices 142 of FIG. 1, which Bahl refers to as edge devices including routers and/or servers (See Bahl, FIG. 1, paragraph [0034]). Moreover, Bahl further notes as an example, that the WAN may be a cloud services provider that provides infrastructure as a service (IaaS) services such as virtual machines (VM), platform as a service (PaaS) services such as databases and serverless computing, and software as a service (SaaS) services such as authentication platforms, and that the WAN may host services for users of the partner network, which may be an enterprise network (See Bahl, paragraph [0002]). Thus, Bahl discloses, teaches and/or suggests that the WAN is a provider network, that the provider network includes [provider] edge devices (i.e., front-end devices 142/virtual network entities 242), and that the partner network 210 is a customer of provider network (WAN) 240, and includes customer equipments (i.e., virtual network entities 212) connected to the [provider] edge devices (again, the front-end devices 142/virtual network entities 242). As further discussed and shown in the Non-Final Rejection, Bahl discloses that the stitching component 250 of the WAN 240 provides the routing policy 252 to the routing agent 230 of the partner network 210 (See again, FIG. 2). Bahl teaches that the routing policy 252 may identify traffic for the destination to route through the WAN 240 via a selected peering location (e.g., virtual network entity 212a, or otherwise, one of virtual network entities 212 - See FIG. 2) (See again, Bahl, FIG. 2, paragraph [0044]). Examiner notes that each of the peering locations (i.e., 212a, 212b, 212c) forms a peering location with a corresponding, respective virtual network entity 242 (i.e., 242a, 242b, 242c). Indeed, Bahl expressly teaches that the peering locations may have a direct connection with a device of the WAN 240, as Bahl indicates that, e.g., virtual network entities 212a, 212b, and 212c may be peering locations with the north virtual network entity 242a, west virtual network entity 242b, and south virtual network entity 242c, respectively (See Bahl, paragraph [0038]). As further disclosed at paragraph [0044] of Bahl, the routing policy 252 may identify a 5-tuple (source IP address, source port, destination IP address, destination port, and protocol) for traffic to route through the WAN 240 via the virtual network entity 212a. In some implementations, the routing policy 252 may identify additional virtual network entities 212 along the selected path. The routing agent 230 may be responsible for configuring the partner network 210 to route traffic according to the routing policy 252 (See again, Bahl, FIG. 2, paragraph [0044]). While Applicant is correct that Bahl teaches that the partner network 210 is configured by the routing agent 230, to route traffic according to the routing policy 252 supplied by the stitching component 250, nevertheless, the routing agent 230 thus enforces the traffic to be routed according to the given policy, and the associated paths selected, traversing the virtual network entities 212, which partner up with their respective virtual network entities 242 at the given peering locations. Examiner wishes to respectfully point out that the newly added limitation is silent with respect to what exactly performs the “applying” limitation, much less what this exactly entails. As Bahl teaches that the routing agent 230 configures the partner network 210 so that appropriate traffic is routed accordingly through the appropriate peering location, the policy is necessarily thus being applied at the interface of the connected virtual network entity 242 (e.g., say, virtual network entity 242a), according to the 5-tuple, which will include the destination 246 of the service 146 and/or virtual network entity 242d hosting the service 146 (See again, Bahl, FIG. 2, paragraphs [0037], [0038] and [0044]). Again, the routing agent 230 may configure one or more routing devices to identify traffic according to the 5-tuple and may route the traffic to a front-end device at the peering location associated with the selected virtual network entity 242 (See Bahl, FIG. 2, paragraph [0044]). Therefore, Examiner respectfully submits, Bahl does disclose, teach and/or suggest the claimed feature of “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected”. Due to the amendment however, Examiner has updated citations to more accurately reflect claim mappings, and has elaborated on interpretation of claim language, as well as application of the reference to assist the reader in understanding the rejection.
Claim Rejections - 35 USC § 101
7. 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
8. Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without an inventive concept/significantly more. The claims recite creating a customer-dedicated virtual network domain based on user input; setting a multi-transmission path policy for the virtual network domain; completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied; and applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected in claim 1, and an operation of creating a customer-dedicated virtual network domain based on user input, an operation of setting a multi-transmission path policy for the virtual network domain, an operation of completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied; and an operation of applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected in claim 19. The limitations of setting a multi-transmission path policy for the virtual network domain, and completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitations in the mind but for the recitation of generic computer components. That is, other than reciting “the method being performed by a computing system” in claim 1, and “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” as well as “a storage storing the computer program, wherein the computer program comprises instructions” in claim 19, nothing in the claim elements preclude the above steps from practically being performed in the mind. For example, “setting” and “specifying” in the context of these claims encompasses a user visually/mentally, and perhaps with pen and paper, identifying/determining a multi-transmission path/multi-path policy to apply to a customer-dedicated virtual network domain, and writing out (i.e., “specifying”) a section to which the multi-transmission path policy is to be applied. Examiner notes that even if most humans would use a physical aid (e.g., pen and paper, a slide rule, or a calculator) to help them complete the recited setting and specifying, the use of such physical aid does not negate the mental nature of these limitations. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract ideas. Accordingly, the claims recite an abstract idea. This judicial exception is not integrated into a practical application because each of claims 1 and 19 recite only two additional steps of “creating a customer-dedicated virtual network domain based on user input” and “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected”. The “computing system” of claim 1, and “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” and “a storage storing the computer program, wherein the computer program comprises instructions” in claim 19 are recited at a high-level of generality (i.e., as generic processors/systems/memories performing a generic computer function of setting a multi-transmission path policy for the virtual network domain, and completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied (as evidenced from paragraphs [0113]-[0115] and [0118] of Applicant’s instant Specification)) such that they amount to no more than mere instructions to apply the exception using generic computer components. In addition, the limitation of “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected,” fails to result in either an inventive concept, integration of a practical application of the judicial exception (i.e., the abstract idea) in Step 2A Prong 2, or reciting significantly more than the exception in Step 2B, because the newly added limitation fails to impose any meaningful limits on practicing the abstract idea, as 1) it amounts to mere instructions to “apply” what is performed in the limitations above (i.e., the abstract idea and results thereof) to an interface of a provider edge (PE) equipment, and/or 2) it merely recites post insignificant extra-solution activity. That is, the newly added “applying” limitation fails to go into any detail whatsoever with respect to how the “multi-transmission path policy” is applied to the interface of the PE (i.e., whether the PE is provisioned with rules and/or policies or how the paths are selected, whether quality of service (QoS) characteristics are taken into account, etc.). The claims are completely silent in this regard and merely recite a broadly drafted notion/idea of “applying” the “multi-transmission path policy” to an interface of a PE, without going into any detail as to what that means. Mere instructions to “apply” an exception using generic computer components cannot provide an inventive concept. Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. As well, the additional steps of “creating a customer-dedicated virtual network domain based on user input” and “applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected” of claims 1 and 19 are recited at a high level of generality (“creating a customer-dedicated virtual network domain” and “applying a multi-transmission path policy to an interface of a provider edge (PE)”) and are pre-insignificant and post-insignificant extra-solution activities, respectively. The claims are directed to an abstract idea. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception, nor do the claims provide an inventive concept. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a “computing system,” “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” and “a storage storing the computer program, wherein the computer program comprises instructions” to cause performance of the setting and specifying steps amount to no more than mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. As well, under the 2019 PEG, a conclusion that an additional element is insignificant extra-solution activity in Step 2A, prong two should be re-evaluated in Step 2B. Here, the creating and applying steps were considered to be pre-insignificant and post-insignificant extra-solution activities, respectively, in prong two of Step 2A, and thus are re-evaluated in Step 2B to determine if they are more than what is well-understood, routine, conventional activities in the field. The instant Specification does not provide any indication that the “computing system,” “one or more processors,” “a memory loading a computer program to be executed by the one or more processors,” and “a storage storing the computer program, wherein the computer program comprises instructions” are anything other than generic, off-the-shelf computer components (See again, instant Specification, paragraphs [0113]-[0115] and [0118]), the cited sample chapter from the book “Exam Ref 70-533 Implementing Microsoft Azure Infrastructure Solutions, 2nd Edition” by Rick Rainey et al., which describes the creation of customer-dedicated virtual network domains and their prevalence, indicates that mere creation of a customer-dedicated virtual network domain (i.e., creating a virtual network based on a received user input), as well as the cited Network Working Group RFC documents, RFC 4364 and RFC 2547, which disclose the state of the art as far back as March 1999, clearly demonstrate the prevalence of the process of applying a multipath policy to the interfaces of provider edge (PE) devices, which connect to customer edge (CE) devices (i.e., applying a multi-transmission path policy to an interface of a provider edge (PE) equipment), are well‐understood, routine, and conventional functions when claimed in a merely generic manner (as they are here). Examiner notes the evidentiary requirement from MPEP § 2106.07(a), section III to expressly support the rejection in writing with a citation to a publication that demonstrates the well-understood, routine, conventional nature of the additional element(s), in lieu of a citation to one or more of the court decisions discussed in MPEP § 2106.05(d), subsection II. Accordingly, a conclusion that the creating step is a well-understood, routine, conventional activity is supported under Berkheimer. For these reasons, there is no inventive concept in the claims, and thus the claims are not patent eligible. With respect to dependent claims 2-18 and 20, each recite additional limitations that either further limit the creating, the setting of the multi-transmission path policy, including selecting different line qualities, as well as selecting different service contracts based on service quality, including a default path, further narrowing the line/path selected, as well as measuring a usage of traffic for each transmission path (Examiner notes that claim 10 is silent with regard to how this occurs), billing based on the measured traffic (a human user can determine how much to bill for services), setting lines applied to the paths based on traffic usage by time, setting detour/rerouting based on traffic usage exceeding thresholds, based on detected security attacks, based on response speed of selected applications falling below thresholds, extracting information using a generative AI model (i.e., humans can rely on generative AI/large language models (LLMs) to mentally make decisions), and creating input rules and other rules/policies based on the extracted information, and calculating a shortest path and resetting the path in response to network failure (i.e., base, equipment, line, etc.), which of course can be done mathematically using pen and paper (Examiner notes that while dependent claim 16 recites that the “extracting” is “based on” (emphasis added) a generative AI model, nevertheless, dependent claim 16 fails to recite that the extracting is performed by the generative AI model itself). However, none of dependent claims 2-18 or 20 include additional elements that are sufficient to amount to significantly more than the judicial exception, nor integrate the abstract idea into a practical application because they fail to impose any meaningful limits on practicing the abstract idea.
Claim Rejections - 35 USC § 103
9. 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.
10. 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.
11. 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.
12. Claims 1-4, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Groenewald et al. (United States Patent No. US 11,546,219 B1), hereinafter “Groenewald” in view of Bahl et al. (United States Patent Application Publication No. US 2023/0016213 A1), hereinafter “Bahl”.
Regarding claim 19, Groenewald discloses a cloud virtual network management apparatus comprising: one or more processors (wherein FIG. 5 illustrates operations 500 for enabling users of a cloud provider network to create and use virtual regions, and of which some or all of the operations 500 (or other processes similarly described, variations, and/or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) executing collectively on one or more processors. See also FIG. 8, including processors 810) (Groenewald, FIGS. 5 and 8, col. 13, ll. 27-36, col. 17, ll. 21-23); a memory loading a computer program to be executed by the one or more processors (at least impliedly, as program must be loaded from storage to memory, to be executed by processors. See also again, FIG. 8, illustrating system memory 820, which may store instructions and data accessible by processor(s) 810. In various embodiments, system memory 820 may be implemented using any suitable memory technology, such as random-access memory (RAM), static RAM (SRAM), synchronous dynamic RAM (SDRAM), nonvolatile/Flash-type memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions, such as those methods, techniques, and data described above are shown stored within system memory 820 as service code 825 and data 826) (Groenewald, FIGS. 5 and 8, col. 17, l. 23, col. 17, ll. 43-53); and a storage storing the computer program (wherein the code is stored on a non-transitory computer-readable storage medium, e.g., in the form of a computer program comprising instructions executable by the one or more processors. See again, FIG. 8, illustrating a computer-accessible medium which may include non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to computer system 800 via I/O interface 830. A non-transitory computer-accessible storage medium may also include any volatile or non-volatile media such as RAM (e.g., SDRAM, double data rate (DDR) SDRAM, SRAM, etc.), read only memory (ROM), etc., that may be included in some embodiments of computer system 800 as system memory 820 or another type of memory) (Groenewald, FIG. 5, col. 13, ll. 37-41, col. 18, ll. 53-63), wherein the computer program comprises instructions for performing an operation of creating a customer-dedicated virtual network domain based on user input (wherein again, operations 500 of FIG. 5 include, at block 502, receiving a request to create a virtual region associated with a user account of a cloud provider network, wherein the request includes identifiers of a plurality of infrastructure locations associated with the cloud provider network at which computing resources can be launched in association with the user account) (Groenewald, FIG. 5, col. 13, ll. 44-50). Groenewald does not explicitly disclose an operation of setting a multi-transmission path policy for the virtual network domain, an operation of completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied; and an operation of applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected. However in an analogous art, Bahl discloses an operation of setting a multi-transmission path policy for a virtual network domain (wherein with reference to FIG. 2, Bahl discloses a stitching component 250 that may provide a routing policy 252 to a routing agent 230. The routing policy 252 may identify traffic for a destination to route through WAN 240, which may be referred to as a virtual WAN (vWAN 248), via a selected peering location (e.g., virtual network entity 212a). For example, the routing policy 252 may identify a 5-tuple (source IP address, source port, destination IP address, destination port, and protocol) for traffic to route through the WAN 240 via the virtual network entity 212a. Bahl teaches that the vWAN 248 may include a plurality of virtual network entities 242, with each virtual network entity 242 associated with a geographic location and representing physical computing resources controlled by the WAN 240 in the geographic location) (Bahl, FIG. 2, paragraphs [0037] and [0044]), an operation of completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied (wherein the routing policy 252 may identify additional virtual network entities 212 along the selected path. The routing agent 230 may be responsible for configuring the partner network 210 to route traffic according to the routing policy 252. For example, the routing agent 230 may configure one or more routing devices to identify traffic according to the 5-tuple and route the traffic to a front-end device at the peering location associated with the selected virtual network entity 242. Where the routing policy 252 identifies one or more virtual network entities 212 along the selected path, the routing agent 230 may configure routing devices (e.g., routers 112) associated with each virtual network entity 212 to route the identified traffic to a device associated with a next virtual network entity 212 along the selected path. In some implementations, the routing agent 230 may configure one or more routing devices to label traffic within the partner network 210 based on the selected peering location) (Bahl, FIG. 2, paragraph [0044]); and an operation of applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected (wherein again, Bahl teaches that the partner network 210 is a customer of WAN 240, and includes each of the virtual network entities 212, while the WAN includes virtual network entities 242, which connect and form peering locations, with the virtual network entities 212. Each virtual network entity 242 may be associated with a geographic location and represent physical computing resources controlled by the WAN 240 in the geographic location. The peering locations may have a direct connection with a device of the WAN 240. For example, virtual network entities 212a, 212b, and 212c may be peering locations with the north virtual network entity 242a, west virtual network entity 242b, and south virtual network entity 242c, respectively. As such, Bahl teaches that virtual network entities 212, which may be viewed as customer devices having a direct connection with [provider edge] devices (virtual network entities 242), form peering locations with virtual network entities 242. As well, the routing agent 230 may configure one or more routing devices to identify traffic according to the 5-tuple identified by the routing policy 252, and route the traffic to a front-end device at the peering location associated with the selected virtual network entity 242. Where the routing policy 252 identifies one or more virtual network entities 212 along the selected path, the routing agent 230 may configure routing devices (e.g., routers 112) associated with each virtual network entity 212 to route the identified traffic to a device associated with a next virtual network entity 212 along the selected path. Accordingly, the routing agent 230 thus enforces traffic to be routed according to the given policy, and the associated paths selected, traversing the virtual network entities 212, which partner up with their respective virtual network entities 242 at the given peering locations) (Bahl, FIGS. 2 and 3, paragraphs [0037], [0038] and [0044]). Groenewald and Bahl are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald and Bahl before him or her, to modify the operations 500 of Groenewald to include the additional limitations of an operation of setting a multi-transmission path policy for a virtual network domain, an operation of completing service configuration of the virtual network domain by specifying a section to which the multi-transmission path policy is to be applied, and an operation of applying the multi-transmission path policy to an interface of a provider edge (PE) equipment to which a customer equipment (CE) is connected, as disclosed by Bahl, with reasonable expectation that this would result in a method of enabling users of a cloud provider network to create and use virtual regions while having the added benefit of a stitching component 250 and a routing agent 230 (See again, Bahl, FIG. 2), that had adequate knowledge about the optimal path by which to route data, and via the appropriate peering location, resulting in better overall connectivity management between the local/enterprise network and the cloud from which services are rendered (See Bahl, paragraphs [0003] and [0005]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Bahl. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald with Bahl to obtain the invention as specified in claim 19.
Claim 1 includes a “method” claim that performs limitations substantially as recited in “cloud virtual network management apparatus” claim 19, and does not appear to include any additional features with regard to novelty and/or non-obviousness; therefore, it is rejected under the same rationale.
Regarding claim 20, Groenewald-Bahl discloses the apparatus of claim 19, wherein the operation of setting the multi-transmission path policy for the virtual network domain comprises an operation of setting a transmission path for each application for the virtual network domain (wherein with reference to FIG. 1, Bahl further notes that conventionally, the data centers 144 (e.g., data centers 144a, 144b, and 144c) may include servers that host applications such as service 146. In particular, if service 146 is hosted on a data center 144c, the partner network 110 may route traffic to either the front-end device 142a or the front-end device 142b to reach the service 146. Bahl teaches that in some cases, the quality of the connection to the service 146 may vary based on which front-end device 142 is selected. The quality of the connections to the service 146 may theoretically be improved by selecting the better front-end device 142, but the partner network 110 may lack information about the WAN 140 to make such a selection. As such, with continued reference to FIG. 2, Bahl teaches that the stitching component 250 may select a virtual network entity 242 (e.g., virtual network entity 242a) to receive traffic for the service 146 based on delay metrics associated with the peered virtual network entities 212 of the partner network 210. For instance, the stitching component 250 may select the virtual network entity 242 associated with the least delay in the partner network 210, and may select the virtual network entity 242 based on delay values for the WAN 240. That is, the stitching component 250 may select a path with a shortest total delay value from a source in the partner network 210 to a destination (e.g., service 146) in the WAN 240) (Bahl, FIGS. 1 and 2, paragraphs [0034], [0035] and [0040]), and the transmission path is configured as a line of a different quality depending on at least one of a dedicated line, an Internet line, speed, duplexing, and a telecommunications service provider (wherein again, the delay profile 232 may include a number of network metrics, such as latency, bandwidth and cost) (Bahl, paragraph [0039]). As discussed and shown above, Groenewald and Bahl are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald and Bahl before him or her, to modify the operations 500 of Groenewald to include the additional limitations of wherein the operation of setting the multi-transmission path policy for the virtual network domain comprises an operation of setting a transmission path for each application for the virtual network domain, and the transmission path is configured as a line of a different quality depending on at least one of a dedicated line, an Internet line, speed, duplexing, and a telecommunications service provider, as disclosed by Bahl, with reasonable expectation that this would result in not only on improved communication between topology information and improved routing efficiency (See Bahl, paragraph [0005]), but also improved speed (i.e., reduced latency) through the network (See again, Bahl, paragraph [0039]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Bahl. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald with Bahl to obtain the invention as specified in claim 20.
Claims 3 and 4 include “method” claims that perform limitations substantially as recited in “cloud virtual network management apparatus” claim 20, and do not appear to include any additional features with regard to novelty and/or non-obviousness; therefore, they are rejected under the same rationale.
Regarding claim 2, Groenewald-Bahl discloses the method of claim 1, wherein the creating of the customer-dedicated virtual network domain comprises receiving input for selecting a region to which the virtual network domain is to be applied (wherein Groenewald further teaches that a cloud provider network 100 provides “wizard” user interfaces that help guide a user through the process of identifying and selecting infrastructure locations to comprise a virtual region based on input obtained from the user related to their desired use case) (Groenewald, col. 10, ll. 7-11). The motivation regarding the obviousness of claim 19 is also applied to claim 2.
13. Claims 5-9 are rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of SZILAGYI et al. (United States Patent Application Publication No. US 2022/0377131 A1), hereinafter “SZILAGYI” in view of Shenoy et al. (United States Patent Application Publication No. US 2019/0036808 A1), hereinafter “Shenoy”.
Regarding claim 5, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises: selecting any one of a plurality of service contract types for the virtual network domain; and setting a default path to a high-quality line and setting an exception path to a medium-quality line if the selected service contract type is a premium service. In an analogous art, however, SZILAGYI discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for a virtual network domain (wherein SZILAGYI discloses leveraging network slicing and multiple protocol data unit (PDU) sessions to fulfill service level agreements (SLAs) and provide traffic steering to edge locations. In particular, SZILAGYI teaches that a cloud platform receives a user input (from a user of the cloud platform) regarding the desired characteristics for an edge cloud (e.g., via user selection of a “SLA tier” (e.g., “Bronze”/sub-100 millisecond latency, “Silver”/sub-50 millisecond latency, or “Gold”/sub-20 millisecond latency) and a geographic area (e.g., Texas)). For clarity, Examiner maps the selected SLA tier to the recited “service contract types”. The cloud platform provides an indication of the desired characteristics for the edge cloud to the communication service platform via an application programming interface (API). Responsive to receiving the indication of the desired characteristics for the edge cloud, the communication service platform determines a network slice that is capable of supporting the desired characteristics of the edge cloud (e.g., the specified SLA and geographic area)) (SZILAGYI, paragraphs [0035]-[0036]). Groenewald-Bahl and SZILAGYI are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and SZILAGYI before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for a virtual network domain, as disclosed by SZILAGYI, with reasonable expectation that this would result in a method of enabling users of a cloud provider network to subscribe to and select from a number of different service packages, thereby enabling the subscribers to customize their level of service according to their desired characteristics (See SZILAGYI, paragraph [0036]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of SZILAGYI. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with SZILAGYI to obtain the invention as specified in claim 5. Groenewald-Bahl-SZILAGYI does not expressly disclose setting a default path to a high-quality line and setting an exception path to a medium-quality line if the selected service contract type is a premium service. However in an analogous art, Shenoy discloses setting a default path to a high-quality line and setting an exception path to a medium-quality line if a selected service contract type is a premium service (wherein Shenoy discloses a spoke router 10A (See FIG. 1) that may receive default summary routes including their respective path communities from virtual route reflector (VRR)17 and may import these route advertisements into corresponding tables, where each table corresponds to virtual routing and forwarding instances (VRFs) 14A, 14B and default VRF 14C. For example, spoke router 10A may install a default summary route into VRF 14A and install a default summary route into VRF 14B. Spoke router 10A may also install a specific path along one of links 11 for each of VRFs 14 based on the respective path communities included with the default summary routes. Continuing the example above, based on the path community, spoke router 10A may install a default route for VRF 14A with a path along link 11A, and a default route for VRF 14B with a path along link 11B. Shenoy teaches that in some examples, spoke router 10A may also install routes with all paths for default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B. For example, spoke router 10A may install a default route for VRF 14A such that if the primary path (e.g., link 11A) for VRF 14A fails, spoke router 10A may forward traffic along the available paths in default VRF 14C (e.g., link 11B). For clarity, Examiner maps the recited “default path” to the disclosed default routes configured in each of the VRFs 14A, 14B, along respective links 11A, 11B, and maps the recited “exception path” to the disclosed route taken by the default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B) (Shenoy, FIG. 1, paragraphs [0052]-[0054]). Groenewald-Bahl-SZILAGYI and Shenoy are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl-SZILAGYI and Shenoy before him or her, to modify the operations 500 of Groenewald-Bahl-SZILAGYI to include the additional limitation of setting a default path to a high-quality line and setting an exception path to a medium-quality line if a selected service contract type is a premium service, as disclosed by Shenoy, with reasonable expectation that this would result in the ability to select a path in accordance with service level agreements such that the routers forwarded traffic generated by an application on the selected path that satisfied a given SLA/service contract (See Shenoy, paragraph [0055]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl-SZILAGYI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Shenoy. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl-SZILAGYI with Shenoy to obtain the invention as specified in claim 5.
Regarding claim 6, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises: selecting any one of a plurality of service contract types for the virtual network domain; and setting a default path to a medium-quality line and setting an exception path to a high-quality line if the selected service contract type is a standard service. However SZILAGYI discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for the virtual network domain (wherein as above, SZILAGYI discloses leveraging network slicing and multiple protocol data unit (PDU) sessions to fulfill service level agreements (SLAs) and provide traffic steering to edge locations. In particular, SZILAGYI teaches that a cloud platform receives a user input (from a user of the cloud platform) regarding the desired characteristics for an edge cloud (e.g., via user selection of a “SLA tier” (e.g., “Bronze”/sub-100 millisecond latency, “Silver”/sub-50 millisecond latency, or “Gold”/sub-20 millisecond latency) and a geographic area (e.g., Texas)). For clarity, Examiner maps the selected SLA tier to the recited “service contract types”. The cloud platform provides an indication of the desired characteristics for the edge cloud to the communication service platform via an application programming interface (API). Responsive to receiving the indication of the desired characteristics for the edge cloud, the communication service platform determines a network slice that is capable of supporting the desired characteristics of the edge cloud (e.g., the specified SLA and geographic area)) (SZILAGYI, paragraphs [0035]-[0036]). As discussed and shown above, Groenewald-Bahl and SZILAGYI are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and SZILAGYI before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for a virtual network domain, as disclosed by SZILAGYI, with reasonable expectation that this would result in a method of enabling users of a cloud provider network to subscribe to and select from a number of different service packages, thereby enabling the subscribers to customize their level of service according to their desired characteristics (See SZILAGYI, paragraph [0036]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of SZILAGYI. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with SZILAGYI to obtain the invention as specified in claim 6. Groenewald-Bahl-SZILAGYI does not expressly disclose setting a default path to a medium-quality line and setting an exception path to a high-quality line if the selected service contract type is a standard service. However in an analogous art, Shenoy discloses setting a default path to a medium-quality line and setting an exception path to a high-quality line if the selected service contract type is a standard service (wherein as discussed and shown above, Shenoy discloses a spoke router 10A (See FIG. 1) that may receive default summary routes including their respective path communities from virtual route reflector (VRR)17 and may import these route advertisements into corresponding tables, where each table corresponds to virtual routing and forwarding instances (VRFs) 14A, 14B and default VRF 14C. For example, spoke router 10A may install a default summary route into VRF 14A and install a default summary route into VRF 14B. Spoke router 10A may also install a specific path along one of links 11 for each of VRFs 14 based on the respective path communities included with the default summary routes. Continuing the example above, based on the path community, spoke router 10A may install a default route for VRF 14A with a path along link 11A, and a default route for VRF 14B with a path along link 11B. Shenoy teaches that in some examples, spoke router 10A may also install routes with all paths for default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B. For example, spoke router 10A may install a default route for VRF 14A such that if the primary path (e.g., link 11A) for VRF 14A fails, spoke router 10A may forward traffic along the available paths in default VRF 14C (e.g., link 11B). For clarity, Examiner maps the recited “default path” to the disclosed default routes configured in each of the VRFs 14A, 14B, along respective links 11A, 11B, and maps the recited “exception path” to the disclosed route taken by the default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B) (Shenoy, FIG. 1, paragraphs [0052]-[0054]). As discussed and shown above, Groenewald-Bahl-SZILAGYI and Shenoy are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl-SZILAGYI and Shenoy before him or her, to modify the operations 500 of Groenewald-Bahl-SZILAGYI to include the additional limitation of setting a default path to a medium-quality line and setting an exception path to a high-quality line if the selected service contract type is a standard service, as disclosed by Shenoy, with reasonable expectation that this would result in the ability to select a path in accordance with service level agreements such that the routers forwarded traffic generated by an application on the selected path that satisfied a given SLA/service contract (See Shenoy, paragraph [0055]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl-SZILAGYI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Shenoy. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl-SZILAGYI with Shenoy to obtain the invention as specified in claim 6.
Regarding claim 7, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises: selecting any one of a plurality of service contract types for the virtual network domain; and setting a default path to a normal-quality line and setting an exception path to a high-quality line or a medium-quality line if the selected service contract type is a light service. However SZILAGYI discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for the virtual network domain (wherein again, SZILAGYI discloses leveraging network slicing and multiple protocol data unit (PDU) sessions to fulfill service level agreements (SLAs) and provide traffic steering to edge locations. In particular, SZILAGYI teaches that a cloud platform receives a user input (from a user of the cloud platform) regarding the desired characteristics for an edge cloud (e.g., via user selection of a “SLA tier” (e.g., “Bronze”/sub-100 millisecond latency, “Silver”/sub-50 millisecond latency, or “Gold”/sub-20 millisecond latency) and a geographic area (e.g., Texas)). For clarity, Examiner maps the selected SLA tier to the recited “service contract types”. The cloud platform provides an indication of the desired characteristics for the edge cloud to the communication service platform via an application programming interface (API). Responsive to receiving the indication of the desired characteristics for the edge cloud, the communication service platform determines a network slice that is capable of supporting the desired characteristics of the edge cloud (e.g., the specified SLA and geographic area)) (SZILAGYI, paragraphs [0035]-[0036]). Again, Groenewald-Bahl and SZILAGYI are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and SZILAGYI before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises: selecting any one of a plurality of service contract types for a virtual network domain, as disclosed by SZILAGYI, with reasonable expectation that this would result in a method of enabling users of a cloud provider network to subscribe to and select from a number of different service packages, thereby enabling the subscribers to customize their level of service according to their desired characteristics (See SZILAGYI, paragraph [0036]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of SZILAGYI. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with SZILAGYI to obtain the invention as specified in claim 7. Groenewald-Bahl-SZILAGYI does not expressly disclose setting a default path to a normal-quality line and setting an exception path to a high-quality line or a medium-quality line if the selected service contract type is a light service. However in an analogous art, Shenoy discloses setting a default path to a normal-quality line and setting an exception path to a high-quality line or a medium-quality line if the selected service contract type is a light service (wherein as discussed and shown above, Shenoy discloses a spoke router 10A (See FIG. 1) that may receive default summary routes including their respective path communities from virtual route reflector (VRR)17 and may import these route advertisements into corresponding tables, where each table corresponds to virtual routing and forwarding instances (VRFs) 14A, 14B and default VRF 14C. For example, spoke router 10A may install a default summary route into VRF 14A and install a default summary route into VRF 14B. Spoke router 10A may also install a specific path along one of links 11 for each of VRFs 14 based on the respective path communities included with the default summary routes. Continuing the example above, based on the path community, spoke router 10A may install a default route for VRF 14A with a path along link 11A, and a default route for VRF 14B with a path along link 11B. Shenoy teaches that in some examples, spoke router 10A may also install routes with all paths for default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B. For example, spoke router 10A may install a default route for VRF 14A such that if the primary path (e.g., link 11A) for VRF 14A fails, spoke router 10A may forward traffic along the available paths in default VRF 14C (e.g., link 11B). For clarity, Examiner maps the recited “default path” to the disclosed default routes configured in each of the VRFs 14A, 14B, along respective links 11A, 11B, and maps the recited “exception path” to the disclosed route taken by the default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B) (Shenoy, FIG. 1, paragraphs [0052]-[0054]). Again, Groenewald-Bahl-SZILAGYI and Shenoy are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl-SZILAGYI and Shenoy before him or her, to modify the operations 500 of Groenewald-Bahl-SZILAGYI to include the additional limitation of setting a default path to a normal-quality line and setting an exception path to a high-quality line or a medium-quality line if the selected service contract type is a light service, as disclosed by Shenoy, with reasonable expectation that this would result in the ability to select a path in accordance with service level agreements such that the routers forwarded traffic generated by an application on the selected path that satisfied a given SLA/service contract (See Shenoy, paragraph [0055]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl-SZILAGYI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Shenoy. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl-SZILAGYI with Shenoy to obtain the invention as specified in claim 7.
Regarding claim 8, Groenewald-Bahl-SZILAGYI-Shenoy discloses the method of claim 5, wherein the default path is automatically set using line information preset for the selected service contract type (wherein SLA controller 22 (See again, FIG. 1) may determine whether one or more links 11 satisfies a given SLA and may select a path along the link that satisfies the given SLA. SLA controller 22 may instruct virtual route reflector (VRR) 17 to add a unique path community associated with the selected path to the route advertisements received from hub router 6. VRR 17 may then reflect the default summary routes including their respective path communities to spoke router 10A) (Shenoy, FIG. 1, paragraph [0051]), and the exception path is set based on input for selecting at least one of source IP information, destination IP information, port information, protocol type, and location information of an application (wherein the forwarding plane of spoke routers 10 may also map applications to the specific VRFs 14 using application-filter rules (e.g., Deep Packet Inspection (DPI) based on L3/L4 or higher layer protocol parameters or packet content) such that route lookup for traffic generated from a specific application occurs on a specific VRF 14. As well, Hub router 6 may advertise a default route for default VRF 14C with a local-address of hub router 6. The default route may include an RD and BGP extended community that uniquely identifies default VRF 14C. As shown above, spoke router 10A may thus install the routes with all paths for the default VRF 14C in case of a failure to one of the paths installed for each of VRFs 14A, 14B. For example, spoke router 10A may install a default route for VRF 14A such that if the primary path (e.g., link 11A) for VRF 14A fails, spoke router 10A may forward traffic along the available paths in default VRF 14C (e.g., link 11B)) (Shenoy, FIG. 1, paragraphs [0050] and [0054]). Again, Groenewald-Bahl-SZILAGYI and Shenoy are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl-SZILAGYI and Shenoy before him or her, to modify the operations 500 of Groenewald-Bahl-SZILAGYI to include the additional limitations of wherein the default path is automatically set using line information preset for the selected service contract type, and the exception path is set based on input for selecting at least one of source IP information, destination IP information, port information, protocol type, and location information of an application, as disclosed by Shenoy, with reasonable expectation that this would result in providing a means by which external BGP (EBGP) route advertisements could be forwarded throughout the network (See Shenoy, paragraph [0032]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl-SZILAGYI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Shenoy. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl-SZILAGYI with Shenoy to obtain the invention as specified in claim 8.
Regarding claim 9, Groenewald-Bahl-SZILAGYI-Shenoy discloses the method of claim 7, wherein the high-quality line is a dedicated optical cable (including cable modems/networks) (Shenoy, paragraph [0020]), the medium-quality line is a dedicated line of a telecommunications service provider (wherein intermediate network 4 may be a service provider network that is owned and operated by a service provider, such as a telecom provider) (Shenoy, paragraph [0021]), and the normal-quality line is an Internet line of a telecommunications service provider (further including an Internet line, as provided by intermediate network 4) (Shenoy, paragraph [0021]). Again, Groenewald-Bahl-SZILAGYI and Shenoy are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl-SZILAGYI and Shenoy before him or her, to modify the operations 500 of Groenewald-Bahl-SZILAGYI to include the additional limitations of wherein the high-quality line is a dedicated optical cable, the medium-quality line is a dedicated line of a telecommunications service provider, and the normal-quality line is an Internet line of a telecommunications service provider, as disclosed by Shenoy, with reasonable expectation that this would result in providing multiple means of communication, with different classes of service (See Shenoy, paragraph [0021]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl-SZILAGYI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Shenoy. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl-SZILAGYI with Shenoy to obtain the invention as specified in claim 9.
14. Claims 10-12 are rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Furr et al. (United States Patent No. US 9,141,947 B1), hereinafter “Furr”.
Regarding claim 10, Groenewald-Bahl discloses the method of claim 1, but does not explicitly disclose further comprising measuring a usage of traffic for each transmission path transmitted according to the multi-transmission path policy set for the virtual network domain. In an analogous art, however, Furr discloses measuring a usage of traffic for each transmission path transmitted according to a multi-transmission path policy set for a virtual network domain (wherein Furr discloses a billing manager that may be operable to obtain different sets of summed traffic measurements for services and direct connect links, and to generate billing information for each client based on the client’s usage of the links and services and on the billing policies agreed to with the client. Examiner notes the virtual compute instance in FIG. 1, which may thus include a virtual network domain) (Furr, FIG. 1, col. 4, ll. 54-59, col. 6, ll. 16-21). Groenewald-Bahl and Furr are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Furr before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of measuring a usage of traffic for each transmission path transmitted according to a multi-transmission path policy set for a virtual network domain, as disclosed by Furr, with reasonable expectation that this would result in giving service providers the ability to bill the customers for whom such links are set up based on, e.g., appropriate link usage levels, while also reducing periods over which network paths are underutilized, thereby resulting in a greater return on the network operators’ investments on networking equipment (See Furr, col. 1, l. 63-col. 2, l. 7). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Furr. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Furr to obtain the invention as specified in claim 10.
Regarding claim 11, Groenewald-Bahl-Furr discloses the method of claim 10, further comprising performing billing based on the usage of traffic measured for each transmission path (wherein again, the billing manager obtains different sets of summed traffic measurements for services and direct connect links, and generates billing information for each client based on the client’s usage of the links and services) (Furr, col. 4, ll. 54-58). As discussed and shown above, Groenewald-Bahl and Furr are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Furr before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of performing billing based on the usage of traffic measured for each transmission path, as disclosed by Furr, with reasonable expectation that this would result in giving service providers the ability to bill the customers for whom such links are set up based on, e.g., appropriate link usage levels, while also reducing periods over which network paths are underutilized, thereby resulting in a greater return on the network operators’ investments on networking equipment (See Furr, col. 1, l. 63-col. 2, l. 7). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Furr. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Furr to obtain the invention as specified in claim 11.
Regarding claim 12, Groenewald-Bahl-Furr discloses the method of claim 1, wherein the setting of the multi-transmission path policy for the virtual network domain comprises setting a line applied to each transmission path by time based on a usage of traffic transmitted through each transmission path by time (wherein more particularly, Furr teaches that a default billing behavior may be that each client that requests a service should be billed for the network traffic that is generated at the corresponding resource collection for that service, and every client that uses a dedicated private link should be billed for traffic that flows through the link. Because of the potential for traffic being counted multiple times, e.g., once during service-related traffic measurement and once during direct connect measurement, different billing policies may be used to override the default behavior. One such billing policy may, e.g., indicate that the billing manager should charge the client at a certain rate for the traffic that passes through the client’s private links, but that the client should not be charged again for that same traffic being measured at the resource collections for services requested by the client. In an embodiment where such a billing policy is implemented, Furr teaches that the billing manager may obtain, e.g., from the various metering agents, both a direct connect traffic summation metric for the client and a service traffic summation metric. The service traffic metric may sum up, e.g., all the traffic transmitted to or from one or more resource collections on behalf of the client to obtain a service or services at the resource collection during a given time period, such as a month or a week. The direct connect traffic metric may sum up, e.g., all the traffic transmitted over a given direct connect link that is allocated to the client, over the same time period. The billing manager may then, in such an embodiment, provide composite billing information to the client for the client’s network traffic usage. Furr teaches that in accordance with the billing policy, the composite billing information may include a first billing amount dependent on the direct connect traffic metric, and a second billing amount that depends on the difference (if any) between the service traffic metric and the direct connect traffic metric, with the billing amount dependent on the direct connect traffic metric being deducted from (i.e., factored into) the composite. For example, if during a given billing period, ten gigabytes of traffic were measured at the resource collections and six gigabytes were measured at the direct connect link or links, the client may be charged only once for the six gigabytes (at the rates applicable for direct connect traffic), and service-related charges would then be applied to the four remaining gigabytes of the ten gigabytes of service-related traffic originally measured) (Furr, col. 4, l. 59-col. 5, l. 32). Again, Groenewald-Bahl and Furr are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Furr before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of the multi-transmission path policy for the virtual network domain comprises setting a line applied to each transmission path by time based on a usage of traffic transmitted through each transmission path by time, as disclosed by Furr, with reasonable expectation that this would result in preventing customers from being over charged for services rendered using the same traffic (See Furr, col. 4, l. 59-col. 5, l. 6). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Furr. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Furr to obtain the invention as specified in claim 12.
15. Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Venkataswami et al. (United States Patent Application Publication No. US 2014/0177447 A1), hereinafter “Venkataswami”.
Regarding claim 13, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises setting a detour to a second base with a low traffic usage to be made in response to a traffic usage increasing to or above a threshold at a first base on each transmission path. In an analogous art, however, Venkataswami discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a detour to a second base with a low traffic usage to be made in response to a traffic usage increasing to or above a threshold at a first base on each transmission path (wherein Venkataswami discloses a data center network 100 in the context of software defined networking (SDN), which utilizes an Open Flow (OF) controller 150, including an aggregation layer 120 with switches 121-1, 121-2, 121-3, 121-4, 121-5, 121-6, 121-7, and 121-8, collectively referred to by Venkataswami as aggregation switches 121, as well as a backbone layer 130 may include switches 131-1, 131-2, 131-3, and 131-4, collectively referred to as backbone switches 131. In particular, Venkataswami teaches that according to some embodiments, link 161-1 between aggregation switch 121-1 and backbone switch 131-1 may have a heavy traffic polarization with respect to link 160-2. Link 160-2 couples aggregation switch 121-1 and backbone switch 131-2. For example, while link 161-1 may carry about nine (9) Gigabit per second (GBs) of data flow, link 161-2 may carry only one (1) or less GBs of data flow. Accordingly, OF controller 150 may decide to re-route the ingress data packet from link 161-1 to link 160-2, using a re-routing strategy. Venkataswami teaches that the decision to re-route the ingress data packet may be triggered when a traffic flow in a link exceeds a pre-selected threshold value. The pre-selected threshold value may be 5 GBs, 6 GBs, or more, according to the number of ports and configuration of the switch supporting the link) (Venkataswami, FIG. 1, paragraphs [0022] and [0025]). Groenewald-Bahl and Venkataswami are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Venkataswami before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a detour to a second base with a low traffic usage to be made in response to a traffic usage increasing to or above a threshold at a first base on each transmission path, as disclosed by Venkataswami, with reasonable expectation that this would result in addressing imbalances and inefficiencies in data center traffic management, particularly by engineering the traffic in a way that avoided congestion and bottlenecks in the links at data center networks (See Venkataswami, paragraphs [0005] and [0007]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Venkataswami. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Venkataswami to obtain the invention as specified in claim 13.
16. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Avadhanam et al. (United States Patent Application Publication No. US 2024/0273192 A1), hereinafter “Avadhanam”.
Regarding claim 14, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises setting a detour to a fourth base, which is safe from a security attack, to be made in response to the security attack being detected at a third base on each transmission path. However in an analogous art, Avadhanam discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a detour to a fourth base, which is safe from a security attack, to be made in response to the security attack being detected at a third base on each transmission path (wherein Avadhanam discloses a framework that can be used to continuously monitor hardware instruction sets to continuously protect against computing attacks. In particular, an artifact (parameters indicative of a computing attack) can be memory mapped to allow a central processing unit to make decisions as to how to respond to a detected computing attack. Once a computing attack has been detected, the framework can be used to migrate workloads to compute instances that have not been infected with a computing virus. For example, if a cloud service provider has a data center in, e.g., Phoenix that is the victim of a computing attack, the described framework can reroute the traffic to another data center in, e.g., Washington) (Avadhanam, paragraph [0041]). Groenewald-Bahl and Avadhanam are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Avadhanam before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a detour to a fourth base, which is safe from a security attack, to be made in response to the security attack being detected at a third base on each transmission path, as disclosed by Avadhanam, with reasonable expectation that this would result in increased security and protect against network attacks (See Avadhanam, paragraphs [0002] and [0041]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Avadhanam. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Avadhanam to obtain the invention as specified in claim 14.
17. Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Cherukuri et al. (United States Patent Application Publication No. US 2018/0167450 A1), hereinafter “Cherukuri”.
As to claim 15, Groenewald-Bahl discloses the method of claim 1, but does not explicitly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises setting a line applied to a specific application to be automatically changed in response to a response speed of the specific application being detected to be equal to or lower than a preset reference value. In an analogous art, however, Cherukuri discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a line applied to a specific application to be automatically changed in response to a response speed of the specific application being detected to be equal to or lower than a preset reference value (wherein Cherukuri discloses a load-balancer 404 (See FIG. 4) that can monitor performance of data transmitted through an application chain according to each end-to-end application path and record data describing performance of each end-to-end application path in an application path table. This can include data such as failure statuses, error code responses, response time, latency metrics, etc. Load-balancer 404 can continuously gather flow data and update the application path data. Cherukuri further teaches that in some embodiments, load-balancer 404 can mark an end-to-end application path as unusable for a specified period. For example, in response to determining that the performance level of an end-to-end application path has degraded below a threshold level, load-balancer 404 can update the performance status of the end-to-end application path to indicate that particular end-to-end application path should not be used. This can be indefinite or, alternatively, for a predetermined period of time, after which load-balancer 404 will again use the end-to-end application path) (Cherukuri, FIG. 4A, paragraphs [0051] and [0053]). Groenewald-Bahl and Cherukuri are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Cherukuri before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises setting a line applied to a specific application to be automatically changed in response to a response speed of the specific application being detected to be equal to or lower than a preset reference value, as disclosed by Cherukuri, with reasonable expectation that this would result in optimizing the load through the paths to a given application in the virtual network domain, by selecting the best end-to-end application path through the application chain (See Cherukuri, paragraphs [0012] and [0053]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Cherukuri. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Cherukuri to obtain the invention as specified in claim 15.
18. Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Huides et al. (United States Patent No. US 12,244,505 B1), hereinafter “Huides”.
Regarding claim 17, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises creating a rule based on an AI model to delete a first transmission path and use a second transmission path in response to traffic usage for the first transmission path applied to a specific application exceeding a preset upper limit. However in an analogous art, Huides discloses wherein the setting of a multi-transmission path policy for a virtual network domain comprises creating a rule based on an AI model to delete a first transmission path and use a second transmission path in response to traffic usage for the first transmission path applied to a specific application exceeding a preset upper limit (wherein a managed cloud networking service (MCNS) analyzes flows of network traffic of an application deployed within a cloud network. In particular, MCNS 110 (See FIG. 1) monitors the application by obtaining metadata 144 over time, e.g., according to a schedule, on an event-driven basis, or the like. The MCNS 110 may accordingly update network path graphs 138, such as when additional application components, network components, and/or interconnections therebetween are discovered. The MCNS 110 may also update the flow data and attributes 136, e.g., upon observing different utilization metrics, different flows beginning, or the like. See again, FIG. 1. In addition, the MCNS 110 may utilize a predictive machine learning model (e.g., a predictive model that operates on time-series data) to generate a “forecast” of predicted traffic (e.g., in terms of requests, network size, or the like) for a particular flow for a particular period (or set of periods of time), such as an expected amount of traffic for the next hour (or on an hour-by-hour basis), for the next day, or the like. An analysis engine 12 (See again, FIG. 1, particularly at circle 5) may utilize graph 138 and flow data 136 to determine if any network components 118 may currently (or soon, based on the historic and/or predicted metadata) reach a “high” usage, such as an amount of traffic (in number of requests, size, or the like) passing some threshold amount - e.g., currently or predictively exceeding a defined maximum number of requests that the network component is known (e.g., per component capability data 140 and/or flow data 136) to be able to handle, or currently or predictively exceeding some component-specific threshold (e.g., exceeding 90% of network component request or throughput capacity, exceeding some threshold of introduced latency created by the network component, etc.). The MCNS 110 may automatically begin implementing a recommended change, which may occur based on the user 104 having given earlier consent (e.g., via an “opt-in” procedure) to allow the MCNS 110 to perform such actions on their behalf. Huides teaches that this may include connectivity adaptation engine 114 (See again, FIG. 1) sending a command to deploy or use a new type of network component (to a first service of services 108) and may send one or more commands (potentially to other services 108) to cause one or more network flows to change their path, e.g., via updating an application component 116 to inform it of a new destination/sink for its traffic, to update routing rules, to update firewall rules, to update DNS resolution processes (e.g., to map a hostname to a new address), etc.) (Huides, FIG. 1, col. 10, ll. 7-16, col. 10, ll. 20-27, col. 10, ll. 42-55, col. 11, ll. 24-29, col. 11, ll. 36-45). Groenewald-Bahl and Huides are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Huides before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of wherein the setting of a multi-transmission path policy for a virtual network domain comprises creating a rule based on an AI model to delete a first transmission path and use a second transmission path in response to traffic usage for the first transmission path applied to a specific application exceeding a preset upper limit, as disclosed by Huides, with reasonable expectation that this would result in benefits such as increased application and system uptime (e.g., due to eliminating or quickly responding to overloaded networking components) and also performance (e.g., improved application execution time, perceived performance via improved time-to-respond, etc.) that can be substantially improved through traffic-sensitive dynamic zero-downtime networking reconfiguration techniques (See Huides, col. 3, ll. 52-59). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Huides. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Huides to obtain the invention as specified in claim 17.
19. Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Groenewald-Bahl, and further in view of Vasseur et al. (United States Patent Application Publication No. US 2012/0233473 A1), hereinafter “Vasseur”.
Regarding claim 18, Groenewald-Bahl discloses the method of claim 1, but does not expressly disclose wherein the setting of the multi-transmission path policy for the virtual network domain comprises calculating a shortest path for a specific application and resetting a transmission path in response to a failure of at least one of a base, equipment, and line of the transmission path applied to the specific application. However in an analogous art, Vasseur discloses calculating a shortest path for a specific application and resetting a transmission path in response to a failure of at least one of a base, equipment, and line of the transmission path applied to the specific application (wherein a routing engine 360 (See FIG. 3) may be used by a policy determination engine 350 to determine impact of implementing network policies computed by the policy determination engine 350. For example, based on instructions received from the policy determination engine 350, the routing engine 360 may compute a shortest-path-first (SPF) update to routing fabric in the network after removing a presently-active network device that is considered for deactivation by the policy determination engine 350, based on the computed network policies. In case of a network that implements MPLS (Multiprotocol Label Switching) Traffic Engineering, the routing engine 360 may compute a CSPF (constrained shortest path first) update to the routing fabric in the network, where the constraint may represent minimum bandwidth required per link, end-to-end delay, or the maximum number of links traversed. The routing engine 360 takes into account the network utilization while performing the SPF computation and may use one or more pre-determined algorithms to infer the routing fabric based on the network utilization. The routing engine 360 may also perform a second order optimization to ensure that there are redundant paths in the network to satisfy network reliability, and that service level agreements (SLAs) for important applications are satisfied in the event that a link or node fails in the network when the computed network policies are implemented. The routing engine 360 transmits the results of the SPF computation and the second order optimization to the policy determination engine 350. If it is determined that the SLAs and network reliability can be satisfied, policy determination engine 350 sends the computed network policies to the transmitter 370) (Vasseur, FIG. 3, paragraph [0034]). Groenewald-Bahl and Vasseur are analogous art because they are from the same problem solving area, namely, providing networking and cloud services to customers over multiple geographic regions and locations. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of Groenewald-Bahl and Vasseur before him or her, to modify the operations 500 of Groenewald-Bahl to include the additional limitation of calculating a shortest path for a specific application and resetting a transmission path in response to a failure of at least one of a base, equipment, and line of the transmission path applied to the specific application, as disclosed by Vasseur, with reasonable expectation that this would result in a virtual network domain having the added benefit of improved resource utilization, saved energy and reduced costs (See Vasseur, paragraphs [0011] and [0012]). This method for enabling users of a cloud provider network to create and use virtual regions of Groenewald-Bahl was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Vasseur. Therefore, before the effective filing date of the claimed invention, it would have been obvious to one having ordinary skill in the art to combine the teachings of Groenewald-Bahl with Vasseur to obtain the invention as specified in claim 18.
Conclusion
20. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. For instance, Herrero et al. (NPL Document entitled, “MPLS Layer 3 VPN Migrations,”) teaches systems and methods associated with migrations related to MPLS BGP-based L3VPNs, focusing on integrating networks as BGP-based Layer 3 VPNs and migrating through different interconnect models (See Final Introductory Paragraph from Chapter 5, page 376).
21. THIS ACTION IS MADE FINAL. 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.
22. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. 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, Kamal B. Divecha can be reached at 571-272-5863. 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.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2453
Prosecution Insights