DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to application filed 09/04/2024.
Claims 1-20 are pending and presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 01/17/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 11 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Claim 11 begins with the recitation of “A method, comprising: in response to a receiving a request”. Claim 11 is indefinite as the claim does not recite a method of receiving the request.
Claim Rejections - 35 USC § 101
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.
Claim 1 is rejected under 35 U.S.C. § 101 because the claimed invention is directed to non-statutory subject matter.
Claim 1 recites a system comprising a gateway device, a plurality of orchestrators, and a plurality of task managers. A gateway device is configured to ‘request a first orchestrator’, ‘instruct a first orchestrator’, ‘request a first task manager’, and ‘instruct a first task manager’. An orchestrator is configured to perform ‘request a first task manager among a plurality of task managers from a task factory’. A first task manager is configured to perform ‘creating the first task’, ’triggering execution of the first task’, or ‘updating the first task’. Claim 1 recites a system comprising a gateway device, a plurality of orchestrators, and a plurality of task managers configured to perform the functions of the limitations which encompasses software per se.
In a review of the specification, the DyCon IPVPN functions implemented by the system per ¶0039, “In the non-limiting example of Fig. 1, system 100 includes one or more computing systems 105a-105l (collectively, "computing systems 105"), each of which may include either one or more containers 110a-110m (collectively, "containers 110"; such as shown with respect to computing system(s) 105a) or one or more virtual machines ("VMs") 115a-115n (collectively, "VMs 115"; such as shown with respect to computing system(s) 105b) that may be implemented or run thereon. A container, as used herein, refers to a logical packaging in which software applications can be abstracted from the environment in which they are actually run or executed, by holding all the components (e.g., files, libraries, and environment variables) necessary for running or executing the software applications.” The components comprising the system are “On the container(s) 110 or the VM(s) 115 may be run or implemented a DyCon IPVPN system 120. The DyCon IPVPN system 120 may include a controller or DyCon IPVPN controller 120a, a gateway device or DyCon IPVPN façade system 120b, a callback controller 120c, and a plurality of factories 120d-120g.”,¶0040. Lastly, “Figs. 4A and 4B (collectively, "Fig. 4") depict various example methods 400A and 400B for implementing DyCon IPVPN functionalities, in accordance with various embodiments.” and “…such methods may also be implemented using any suitable hardware (or software) implementation.”, ¶0073, examiner emphasis. Therefore, the system comprising a gateway device, an orchestrator, and a task manager with their respective functionalities is software per se.
Software per se does not fall within at least one of the four categories of patent eligible subject matter. See MPEP 2106.03(I). Therefore, claim 1 does not fall within the statutory categories of invention (i.e., a process) (STEP 1=NO)
RE Claim 1, the dependent claims 2-10 include additional elements. Claims 2-10 recite additional steps building, deleting, creating, updating, handling, requesting, instructing, receiving, and finding functions related to an IPVPN system. Claims 2-10 also recite data format such as lists of tasks, templates of product types, utilized by the functions related to IPVPN system. Claims 2-10 dependent on claim 1, do not amount to significantly more because the gateway device configured to perform the steps of various functions with the associated data formats which amounts to software per se executed on a generic computer component. Therefore, claim 1 is ineligible.
Claims 11 and 17 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
Evidence
Claim 11 recites a method ‘requesting, by a computing system and from an orchestrator factory, a first orchestrator’, ‘instructing, by the computing system, the first orchestrator’, ‘requesting a first task manager’, and ‘instructing the first task manager to build’.
Claim 17 recites a method ‘creating the first task’, ‘triggering execution of the first task’, and ‘updating the first task’. Claim 17 also recites ‘instructing, by the task manager, the first NaaS service system to perform’, ‘building a NaaS API’, ‘deleting a NaaS API’, and ‘obtaining a status of building or deleting a NaaS API’.
Analysis:
Step 1:
Claims 11 and 17 fall within the statutory categories of invention (i.e., a process) (STEP 1=YES)
Step 2A Prong One which tests whether the claim recites a judicial exception.
Claim 11 falls within “Mental Processes” (which is identified as “Abstract Idea (Judicial Exception)” since it recites concepts which can be performed in the human mind (including, observation, evaluation, judgment): Claim 11 recites a method ‘requesting, by a computing system and from an orchestrator factory, a first orchestrator’, ‘instructing, by the computing system, the first orchestrator’, ‘requesting a first task manager’, and ‘instructing the first task manager to build’. Thus, claim 11 recites the “Judicial Exception” in regard to “Step 2A Prong One” test. [STEP 2A Prong One =YES]
Claim 17 falls within “Mental Processes” (which is identified as “Abstract Idea (Judicial Exception)” since it recites concepts which can be performed in the human mind (including, observation, evaluation, judgment): Claim 17 recites a method ‘creating the first task’, ‘triggering execution of the first task’, and ‘updating the first task’. Claim 17 also recites ‘instructing, by the task manager, the first NaaS service system to perform’, ‘building a NaaS API’, ‘deleting a NaaS API’, and ‘obtaining a status of building or deleting a NaaS API’. Thus, claim 17 recites the “Judicial Exception” in regard to “Step 2A Prong One” test. [STEP 2A Prong One =YES]
STEP 2A Prong Two which tests whether the claim recites as a whole “integrates the recited judicial exception into a practical application of that exception.
In regards to Claim 11, this judicial exception is not integrated into a practical application. In particular, the claim only recites one additional element – using a computing system to perform the steps recited in the limitations. The processor is recited at a high-level of generality (i.e., a computing system) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. The claim is directed to an abstract idea. [STEP 2A Prong Two = NO]
In regards to Claim 17, this judicial exception is not integrated into a practical application. In particular, the claim only recites one additional element – using a task manger to perform the steps recited in the limitations. The processor is recited at a high-level of generality (i.e., a task manager) such that it amounts no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The recitation of generic computer components in a claim does not necessarily preclude that claim from reciting an abstract idea. The claim is directed to an abstract idea. [STEP 2A Prong Two = NO]
STEP 2B: The additional element/limitations are:
RE Claim 11, the dependent claims 12-16 include additional elements. Claims 12-16 recite additional steps of instructing, requesting, associating, accessing, deleting, or messaging among other things related to IPVPN system. Claims 12-16 dependent on claim 11, do not amount to significantly more than the abstract idea because the computing system is a generic computer component recited at a high level of generality to implement the abstract idea. [STEP 2B = NO] Therefore, claim 11 is ineligible.
RE Claim 17, the dependent claims 18-20 include additional elements. Claims 18-20 recite additional steps of handling, executing, triggering, updating, building, deleting, auditing or updating among other things related to IPVPN system. Claims 18-20 dependent on claim 17, do not amount to significantly more than the abstract idea because the task manager is a generic computer component recited at a high level of generality to implement the abstract idea. [STEP 2B = NO] Therefore, claim 17 is ineligible.
The claims 11 and 17 purport an abstract idea squarely analogous to the abstract idea concepts identified by the courts; inventive concept linked to a particular technological environment or field, i.e. mental processes are abstract ideas under Alice/Mayo step one. See, e.g., CyberSource Corp. v. Retail Decisions, Inc., 654 F.3d 1366, 1373 (Fed. Cir. 2011) (“[C]omputational methods which can be performed entirely in the human mind are the types of methods that embody the ‘basic tools of scientific and technological work’ that are free to all men and reserved exclusively to none.” (quoting Gottschalk v. Benson, 409 U.S. 63, 67 (1972)); see also Elec. Power Grp., LLC v. Alstom, S.A., 830 F.3d 1350, 1354 (Fed. Cir. 2016) (“[W]e have treated analyzing information by steps people go through in their minds, or by mathematical algorithms, without more, as essentially mental processes within the abstract-idea category.”
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1-3, 6, 9-11, and 13-16 are rejected under 35 U.S.C. 102(a)(1) as being unpatentable by Maheshwari et al. (US 20160127454 A1, hereinafter “Maheshwari”).
RE Claim 1, Maheshwari discloses:
A dynamic connections ("DyCon") Internet Protocol virtual private network ("IPVPN") system (This disclosure describes an interconnection platform for dynamically configuring and managing a cloud-based services exchange, or “cloud exchange,” to facilitate virtual connections for cloud services delivery from multiple cloud service providers to one or more cloud customers. ¶0005; In some examples, the techniques of this disclosure can allow automated API request interception to validate partner access to interconnection assets, thus ensuring security of partner assets through machine-to-machine interaction. In some examples, the techniques of this disclosure can allow on demand access to dynamically set up and tear down virtual circuits through machine-to-machine interaction and direct access to interconnection platform resources. In some examples, the techniques of this disclosure can allow on demand access to schedule setup and tear down of virtual circuits at pre-defined intervals through machine-to-machine interaction and direct access to interconnection platform resources. ¶0310; In accordance with techniques described herein, IP/MPLS fabric 1801 implement IP virtual private networks (IP-VPNs) to connect any of customers 1808 with multiple cloud service provider networks 1820 to provide a data center-based ‘transport’ and layer 3 cross-connect. ¶¶0374, 0383, Fig. 18), comprising:
a gateway device (In some examples, cloud exchange 100 includes an API gateway 112 having one or more processors that executes one or more applications that expose software interfaces defined according to APIs 114. The applications may invoke services that correspond to endpoints of the APIs 114, and the services may themselves invoke the cloud exchange platform service of orchestration engine 118. ¶0041, Fig. 1A, 1B, 1C) configured to:
request a first orchestrator among a plurality of orchestrators from an orchestrator factory based on data contained in a request to perform a first network provisioning service among a plurality of network provisioning services (Examiner interprets ‘orchestrator factory’ as the orchestration engine. Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; As illustrated, the platform services 408 include policy management 408A, profiles and configuration 408B, virtual circuit management 408E, network interface management 408F. Each of platform services may represent a workflow and rules engine for a different aspect of cloud service provisioning. ¶0291; Cloud exchange services includes network provisioning ¶0293); and
instruct the first orchestrator to perform the first network provisioning service (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services. A workflow and rules engine (not shown in FIG. 3B) of orchestration engine 407 may apply defined rules and policies to generate a workflow of cloud exchange API services 409 that, in general, fit within an overall function associated with one of platform services 408. ¶0291; Cloud exchange services include network provisioning ¶0293; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357);
the plurality of orchestrators (A workflow and rules engine (not shown in FIG. 3B) of orchestration engine 407 may apply defined rules and policies to generate a workflow of cloud exchange API services 409 that, in general, fit within an overall function associated with one of platform services 408. ¶0291; Examiner interprets ‘plurality of orchestrators’ as workflows of cloud exchange API services.), each orchestrator being configured to:
request a first task manager among a plurality of task managers from a task factory based on a task type associated with a first task among one or more DyCon IPVPN tasks associated with the first network provisioning service (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.); and
instruct the first task manager to perform the first task (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; The microservices then return respective responses to orchestrator 706 (1508). The responses may include data provided by the microservice. Orchestrator 706 consolidates the data received in the responses from each of the workflows, as necessary to fulfill the client request (1510). Orchestration engine 704 then responds to the client request for cloud exchange services (1512). ¶0354; In this context, microservices are endpoints, and a task is an action currently executing to fulfill a request. One example task could be to call a set of microservices (endpoints), collectively. When you call a particular endpoint, some data is returned, which may be data to be used by the next endpoint, in a chain. In this manner, the workflow may define a chain of tasks to be completed, where data obtained in one task may be used in and/or may determine the next task. ¶0355; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.); and
the plurality of task managers (For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; The microservices then return respective responses to orchestrator 706 (1508). The responses may include data provided by the microservice. Orchestrator 706 consolidates the data received in the responses from each of the workflows, as necessary to fulfill the client request (1510). Orchestration engine 704 then responds to the client request for cloud exchange services (1512). ¶0354. Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.), each task manager being configured to perform (The workflow specifies a set of tasks. For example, the workflow for provisioning the virtual circuit specifies a set of tasks comprising: (i) obtaining port details, (ii) obtaining metro details, and (iii) creating the virtual circuit based on the port details and the metro details. Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. ¶0358) at least one of:
creating the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073);
triggering execution of the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073); or
updating the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073).
RE Claim 2, Maheshwari discloses:
the system, wherein the data contained in the request comprises a first product type among a plurality of product types (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services. A workflow and rules engine (not shown in FIG. 3B) of orchestration engine 407 may apply defined rules and policies to generate a workflow of cloud exchange API services 409 that, in general, fit within an overall function associated with one of platform services 408. ¶0291), the first product type being associated with the first network provisioning service (Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. ¶0353, Fig. 15), wherein each orchestrator is further configured to:
request first transaction data among a plurality of transaction data from a transaction factory based on the first product type (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.);
wherein the first transaction data includes a first ordered list of tasks for the first product type (For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.), wherein the first ordered list of tasks includes the first task among the one or more DyCon IPVPN tasks (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers. A ‘DyCon IPVPN task’ is interpreted as a task associated with provisioning for network configuration.), wherein a task type of the first task is the task type on which the request for the first task manager is based (For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15).
RE Claim 3, Maheshwari discloses:
the system, wherein the system further comprises:
a controller configured to trigger one or more DyCon IPVPN functionalities in response to receiving the request to perform the first network provisioning service (Examiner interprets ‘orchestrator factory’ as the orchestration engine. Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). ¶0353, Fig. 15);
the orchestrator factory configured to select and return the first orchestrator among the plurality of orchestrators based on the first product type associated with the first network provisioning service (Examiner interprets ‘orchestrator factory’ as the orchestration engine. Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). ¶0353, Fig. 15; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.);
the transaction factory configured to perform one of:
accessing one or more template files associated with the plurality of product types (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. ¶0353; In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356), the one or more template files including an ordered list of tasks for each product type (In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356); determining, from a first template file among the one or more template files, the first transaction data, including the first ordered list of tasks (In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356); and sending the first transaction data, including the first ordered list of tasks, to the first orchestrator (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type. A ‘template file’ is a workflow of a workflow library.); or
determining the first transaction data, including the first ordered list of tasks, based on the product type (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint.¶0353); generating the first template file based on the determination (The cloud-based services exchange of any of examples 1-9, wherein the request comprises a request to provision the virtual circuit to provide the customer with access to the cloud service, wherein the interconnection platform further comprises: a network service provisioning service; an orchestration engine; an application programming interface gateway configured to, in response to receiving the request, invoke the orchestration engine to provision the virtual circuit, wherein the orchestration engine generates and executes a workflow to invoke the network service provisioning service, wherein the network service provisioning service establishes the virtual circuit according to parameters of the request.¶0410); and sending the first template file as the first transaction data, including the first ordered list of tasks, to the first orchestrator (In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356); and
the task factory configured to select and return the first task manager based on the task type associated with the first task (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.).
RE Claim 6, Maheshwari discloses:
the system, further comprising:
a callback controller configured (In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706. ¶0358; Examiner interprets publish-subscribe server as the callback controller to notify the orchestrator.) to:
receive a callback message from the downstream system indicating that the first task has been successfully completed (The workflow specifies a set of tasks. For example, the workflow for provisioning the virtual circuit specifies a set of tasks comprising: (i) obtaining port details, (ii) obtaining metro details, and (iii) creating the virtual circuit based on the port details and the metro details. Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706.¶0358; Examiner interprets publish-subscribe server as the callback controller to notify the orchestrator.);
request a second orchestrator among the plurality of orchestrators to perform one of a second task among the one or more DyCon IPVPN tasks associated with the first network provisioning service or a second network provisioning service among the plurality of network provisioning services (Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353); and
instruct the second orchestrator to perform the one of the second task or the second network provisioning service ((API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services. A workflow and rules engine (not shown in FIG. 3B) of orchestration engine 407 may apply defined rules and policies to generate a workflow of cloud exchange API services 409 that, in general, fit within an overall function associated with one of platform services 408. ¶0291; Cloud exchange services include network provisioning ¶0293; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357);.
RE Claim 9, Maheshwari discloses:
the system, wherein the request is included in user input that is received from a user device via an a DyCon IPVPN API (FIGS. 18A-18B are block diagrams illustrating example network infrastructure and service provisioning by an interconnection platform for a cloud exchange that aggregates the cloud services of multiple cloud service providers for provisioning to customers of the cloud exchange provider and aggregates access for multiple customers to one or more cloud service providers, in accordance with techniques described in this disclosure. Customer networks 1808 each include endpoint devices that consume cloud services provided by cloud service provider network 1820. Example endpoint devices include servers, smart phones, television set-top boxes, workstations, laptop/tablet computers, video gaming systems, teleconferencing systems, media players, and so forth. ¶0364, Fig. 18A, 18B).
RE Claim 10, Maheshwari discloses:
the system, wherein the DyCon IPVPN system is implemented within one or more virtual machines ("VMs") (The orchestration engine 704 operates as part of an overall interconnection platform (e.g., interconnection platform 103 of FIGS. 1B, 1C) to seamlessly set up interconnection assets including virtual connections (e.g., virtual circuits) between buyers and sellers, such as between an enterprise and a cloud service provider. In the example of FIG. 13, orchestration engine 704 includes two major components: orchestrator 706 and microservices 708 provided by the cloud exchange system 700. Orchestration engine 704 also includes service discovery engine 710 and process manager 712. Orchestration engine 704 may represent a centralized or distributed application and may execute on a management device such as one or virtual machines and/or real servers of data center 101 (FIG. 1A). ¶0328).
RE Claim 11, Maheshwari discloses:
A method, comprising:
in response to receiving a request to build an Internet Protocol virtual private network ("IPVPN") (This disclosure describes an interconnection platform for dynamically configuring and managing a cloud-based services exchange, or “cloud exchange,” to facilitate virtual connections for cloud services delivery from multiple cloud service providers to one or more cloud customers. ¶0005; In accordance with techniques described herein, IP/MPLS fabric 1801 implement IP virtual private networks (IP-VPNs) to connect any of customers 1808 with multiple cloud service provider networks 1820 to provide a data center-based ‘transport’ and layer 3 cross-connect. ¶¶0374, 0383, Fig. 18; In some examples, cloud exchange 100 includes an API gateway 112 having one or more processors that executes one or more applications that expose software interfaces defined according to APIs 114. The applications may invoke services that correspond to endpoints of the APIs 114, and the services may themselves invoke the cloud exchange platform service of orchestration engine 118. ¶0041, Fig. 1A, 1B, 1C), requesting, by a computing system and from an orchestrator factory, a first orchestrator among a plurality of orchestrators based on a first product type that is associated with the IPVPN in the request (Examiner interprets ‘orchestrator factory’ as the orchestration engine. Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; As illustrated, the platform services 408 include policy management 408A, profiles and configuration 408B, virtual circuit management 408E, network interface management 408F. Each of platform services may represent a workflow and rules engine for a different aspect of cloud service provisioning. ¶0291; Cloud exchange services includes network provisioning ¶0293); and
instructing, by the computing system, the first orchestrator to orchestrate building of the IPVPN (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services. A workflow and rules engine (not shown in FIG. 3B) of orchestration engine 407 may apply defined rules and policies to generate a workflow of cloud exchange API services 409 that, in general, fit within an overall function associated with one of platform services 408. ¶0291; Cloud exchange services include network provisioning ¶0293; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357), by:
requesting a first task manager among a plurality of task managers from a task factory based on a task type associated with a task of building the IPVPN (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.); and
instructing the first task manager to build, or to cause building of, the IPVPN (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; The microservices then return respective responses to orchestrator 706 (1508). The responses may include data provided by the microservice. Orchestrator 706 consolidates the data received in the responses from each of the workflows, as necessary to fulfill the client request (1510). Orchestration engine 704 then responds to the client request for cloud exchange services (1512). ¶0354; In this context, microservices are endpoints, and a task is an action currently executing to fulfill a request. One example task could be to call a set of microservices (endpoints), collectively. When you call a particular endpoint, some data is returned, which may be data to be used by the next endpoint, in a chain. In this manner, the workflow may define a chain of tasks to be completed, where data obtained in one task may be used in and/or may determine the next task. ¶0355; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.).
RE Claim 13, Maheshwari discloses:
the method, wherein instructing the first orchestrator to orchestrate building of the IPVPN (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; The microservices then return respective responses to orchestrator 706 (1508). The responses may include data provided by the microservice. Orchestrator 706 consolidates the data received in the responses from each of the workflows, as necessary to fulfill the client request (1510). Orchestration engine 704 then responds to the client request for cloud exchange services (1512). ¶0354; In this context, microservices are endpoints, and a task is an action currently executing to fulfill a request. One example task could be to call a set of microservices (endpoints), collectively. When you call a particular endpoint, some data is returned, which may be data to be used by the next endpoint, in a chain. In this manner, the workflow may define a chain of tasks to be completed, where data obtained in one task may be used in and/or may determine the next task. ¶0355; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.) further includes:
instructing, by the computing system, the first orchestrator to request first transaction data among a plurality of transaction data from a transaction factory based on the first product type (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.);
wherein the first transaction data includes a first ordered list of tasks for the first product type (For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.), wherein the first ordered list of tasks includes the first task among the one or more DyCon IPVPN tasks (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers. A ‘DyCon IPVPN task’ is interpreted as a task associated with provisioning for network configuration.), wherein a task type of the first task is the task type on which the request for the first task manager is based (For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15).
RE Claim 14,
the method, wherein the transaction factory generates a first template file associated with the first product type that is related to building IPVPNs and sends the first template file as the first transaction data to the first orchestrator (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.), the first template file including an ordered list of tasks for building IPVPNs (For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.).
RE Claim 15,
the method, wherein the transaction factory accesses one or more template files associated with a plurality of product types, the one or more template files including an ordered list of tasks for each product type (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. ¶0353; In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356), wherein the transaction factory determines, from a first template file among the one or more template files, the first transaction data, including the first ordered list of tasks (In another example, a cloud service provider can create a template for onboarding new customers and provide the template to orchestrator, and the orchestrator can easily use the template for onboarding new customers who want to connect with the cloud service provider. Orchestrator 706 can orchestrate any type of workflows, and more than one customer can use the workflows. The same workflow can be used by different customers for executing the functionality they need (e.g., creating a virtual circuit). ¶0356), and sends the first transaction data, including the first ordered list of tasks, to the first orchestrator (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type. A ‘template file’ is a workflow of a workflow library.).
RE Claim 16, Maheshwari discloses:
the method, wherein building of the IPVPN follows a first ordered list of tasks in which the tasks are performed in a first order (Orchestration engine 407 orchestrates an API workflow based on defined rules and responses. For example, workflow and rules engine 306 of orchestration engine 407 can orchestrate the API workflow based on one or more of policies 308A, profiles 308B, configurations 308C, and micro services 308D (FIG. 2). Generally speaking, orchestration engine 407 can invoke one or more services 409 in parallel or in a defined order based on configured rules and/or policies. ¶0300, Fig. 5; The orchestrator 706 may use state machines to implement workflows that invoke multiple microservices 706 in a defined ordering to satisfy an API contract. Microservices 706 (and multiple instances of each of microservices 706) may be deployed in separate containers for isolation and modularity, while also providing enhanced quality and reliability with integrated testing, logging, monitoring, and diagnostic strategies. ¶0345; Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint.¶0353), wherein the method further comprises:
in response to receiving a request to delete the IPVPN, instructing, by the computing system, the first orchestrator to orchestrate deleting of the IPVPN (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073), by:
instructing the first task manager to delete, or to cause deletion of, the IPVPN, by implementing a delete workflow based on a second ordered list of tasks (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; The microservices then return respective responses to orchestrator 706 (1508). The responses may include data provided by the microservice. Orchestrator 706 consolidates the data received in the responses from each of the workflows, as necessary to fulfill the client request (1510). Orchestration engine 704 then responds to the client request for cloud exchange services (1512). ¶0354; In this context, microservices are endpoints, and a task is an action currently executing to fulfill a request. One example task could be to call a set of microservices (endpoints), collectively. When you call a particular endpoint, some data is returned, which may be data to be used by the next endpoint, in a chain. In this manner, the workflow may define a chain of tasks to be completed, where data obtained in one task may be used in and/or may determine the next task. ¶0355; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.), wherein delete tasks in the second ordered list of tasks correspond to build tasks in the first ordered list that are labelled in the first transaction data or the first template file as being included in the delete workflow (Examiner interpretation that a first list is a IPVPN build and a second list is a IPVPN delete are workflows, set of tasks. The two sets of tasks are associated with a same domain contract and therefore have corresponding tasks for a specific IPVPN.; A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.), wherein the second ordered list of tasks includes delete tasks for deleting the IPVPN in a second order that is a reverse of the first order except that delete tasks corresponding to build tasks in the first ordered list that are labelled in the first transaction data (Element is optional) or the first template file as not having delete dependency are triggered asynchronously at a beginning of the delete workflow (Examiner interpretation that a first list is a IPVPN build and a second list is a IPVPN delete are workflows, set of tasks. The two sets of tasks are associated with a same domain contract and therefore have corresponding tasks for a specific IPVPN.; For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. Workflows provide a set of logic that uses one or more state machines as a guide to indicate how to transfer from one state to another to fulfill the request. ¶0353, Fig. 15; Examiner interprets transaction data as a list of tasks as per following limitation. A list of tasks is a workflow of a workflow library that is selected based on customer request, a product type.; Orchestration engine 704 also includes functionality for calling asynchronous jobs 817 including manual provisioning/de-provisioning, order scheduler, order status updater, usage statistics, cloud service provider location discovery, for example. The orchestrator 706 may call these jobs asynchronously. ¶0348); and
instructing each downstream system to return a callback message to a callback system indicating when each delete task that is handled by said downstream system has been successfully completed or has failed (In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706. ¶0358; Examiner interprets publish-subscribe server as the callback controller to notify the orchestrator.; API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 4, 5, 8, 12, 17-20 are rejected under 35 U.S.C. 103 as being unpatentable over Maheshwari, in view of Ritchie et al. (US 20220209992 A1, hereinafter “Ritchie”).
RE Claim 4, Maheshwari discloses:
the system, wherein the one or more DyCon IPVPN tasks (This disclosure describes an interconnection platform for dynamically configuring and managing a cloud-based services exchange, or “cloud exchange,” to facilitate virtual connections for cloud services delivery from multiple cloud service providers to one or more cloud customers. ¶0005; In accordance with techniques described herein, IP/MPLS fabric 1801 implement IP virtual private networks (IP-VPNs) to connect any of customers 1808 with multiple cloud service provider networks 1820 to provide a data center-based ‘transport’ and layer 3 cross-connect. ¶¶0374, 0383, Fig. 18) comprise at least one of:
one or more virtual routing and forwarding ("VRF") tasks (Interconnection platform 103 may receive service requests for creating, reading, updating, and/or deleting end-to-end services of the cloud exchange point 1803. In response, interconnection platform 103 may configure PEs 1802, 1804 and/or other network infrastructure of IP/MPLS fabric 1801 to provision or obtain performance or other operations information regarding the service. Operations for provisioning a service and performed by interconnection platform 103 may include configuring or updating VRFs, installing SDN forwarding information, configuring LSPs or other tunnels, configuring BGP, configuring access links 1816 and aggregation links 1822, or otherwise modifying the configuration of the IP/MPLS fabric 1801. Other operations may include making service requests to an orchestration system for cloud service provider networks 1820, as described in further detail below. ¶¶0383-0384, Fig. 19) including at least one of:
building a VRF instance (¶¶0383-0384, Fig. 19);
deleting a VRF instance (¶¶0383-0384, Fig. 19); or
updating a VRF instance (¶¶0383-0384, Fig. 19);
one or more layer 3 VPN tasks ( For some customers of cloud exchange point 1803, the cloud exchange point 1803 provider may configure a full mesh arrangement whereby a set of PEs 1802, 1804 each couple to a different customer site network for the customer. In such cases, the IP/MPLS fabric 1801 implements a layer 3 VPN (L3VPN) for cage-to-cage or redundancy traffic (also known as east-west or horizontal traffic). The L3VPN may effectuate a closed user group whereby each customer site network can send traffic to one another but cannot send or receive traffic outside of the L3VPN. ¶0377) including at least one of:
building a layer 3 VPN network (Implements a layer 3 VPN, ¶0377);
deleting a layer 3 VPN network (Implements a layer 3 VPN, ¶0377); or
updating a layer 3 VPN network (Implements a layer 3 VPN, ¶0377);
one or more layer 3 VPN API FQM tasks (Element is optional) including at least one of:
creating a layer 3 VPN API FQM (Element is optional); or
deleting a layer 3 VPN API FQM (Element is optional);
one or more billing tasks (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services 408A-408H (collectively, “platform services 408”) in this example. As illustrated, the platform services 408 include billing and invoicing 408C, seller API integration 408D, virtual circuit management 408E, and network interface management 408F. Each of platform services may represent a workflow and rules engine for a different aspect of cloud service provisioning. ¶0277; Cloud exchange API services 409A-409R (collectively, “cloud exchange services 409”) represent services offered by the interconnection platform to modify the cloud exchange network infrastructure, manage content, manage incidents, manage inventory and capacity, ensure secured access, and manage orders/billing for providers and customers, as examples. ¶0292; Orchestration engine 407 can then invoke a billing service (e.g., billing service 409H, FIG. 3B) (480N) and receive a response from the billing service (480O). ¶0308) including at least one of:
building a billing record (¶¶0277, 0292, 0308);
deleting a billing record (¶¶0277, 0292, 0308);
updating a billing record (¶¶0277, 0292, 0308);
one or more billing API FQM tasks (Element is optional) including at least one of:
creating a billing API FQM (Element is optional); or
deleting a billing API FQM (Element is optional); or
one or more inventory tasks (Endpoints 406 represent available logical and/or physical resources accessible to API consumers 402. That is, API consumers 406 may access endpoints 406 to access the interconnection platform of a cloud exchange to get information regarding, create, modify, delete, and/or confirm requests for corresponding resources of the cloud exchange. Endpoints 406 may represent example instances of endpoints 116 of FIGS. 1B-1C. ¶0071) including at least one of:
updating a network resource inventory (¶0071); or
auditing a network resource inventory (¶0071).
Maheshwari does not explicitly disclose, however Ritchie discloses:
one or more network as a service ("NaaS") IPVPN tasks ( In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. ¶0027; In some examples, network provisioning may include automating connections to a virtual private network (VPN), to a public cloud provider, to a private cloud provider, etc. According to an example, the network configurator 112 may operate to interrogate network elements, reserve network resources in the network 106, configure ports on network resources, create a domain path between server instances, delete domain paths, release network resources, and/or perform other edge compute network provisioning interactions based on the requirements sent from the ECS orchestrator 108. ¶0030) including at least one of:
building a NaaS IPVPN network (¶¶0027, 0030);
deleting a NaaS IPVPN network (¶¶0027, 0030); or
updating a NaaS IPVPN network (¶¶0027, 0030);
one or more NaaS API framework for queue management ("FQM") tasks (In some examples, the edge compute system 104 includes an Edge Compute System (ECS) Orchestrator 108 that provides a user interface (UI) 114 and an API 115. The ECS orchestrator 108 may be a software development kit that allows the user 102 to interface with the edge compute system 104. For example, a server configuration orchestrator (SCO) 131 and a network configuration orchestrator (NCO) 130 may operate as API-defined compute and network controllers that can automatically complete the provisioning a server instance on a compute resource 103 and the provisioning of network services between server instances, to the Internet, and/or to the user's private systems based on instructions received from the ECS orchestrator 108. ¶0020; In multi-tiered orchestration, a challenge is concurrency and how to deal with concurrent requests to scale. In some examples, queuing mechanisms may be implemented between different layers (NaaS, MaaS, ACT, L2 and L3 Activation). When accessing resources from the network, decisions on which resources to utilize may be made before configuring them. When concurrent requests are run, queues may be implemented to temporarily store information retrieved from the network before configuration to avoid race conditions associated with accessing a same network resource. ¶0064) including at least one of:
creating a NaaS API FQM (¶¶0020, 0064); or
deleting a NaaS API FQM (¶¶0020, 0064);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 5, Maheshwari discloses:
the system, wherein each task manager is further configured to perform at least one of:
handling one or more task failures associated with implementing the first task (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; In some cases, the sequence of tasks in a workflow may be more complex than just tasks performed in a series. Tasks can fail, and so orchestrator 706 may at times need to deal with timeouts, retries, “stuck” flows, and so forth. Orchestrator 706 may need to recover from a task failure, or from a whole workflow failure. In some examples, orchestrator 706 uses a service discovery engine 710 (FIG. 13) to discover an alternate microservice to use when a first task fails due to the microservice not responding properly or returning an error message. ¶0359);
Maheshwari does not explicitly disclose, however Ritchie discloses:
requesting a first NaaS service system among a plurality of NaaS service systems from a NaaS API factory based on a first resource type associated with the first task (In some examples, the edge compute system 104 includes an Edge Compute System (ECS) Orchestrator 108 that provides a user interface (UI) 114 and an API 115. The ECS orchestrator 108 may be a software development kit that allows the user 102 to interface with the edge compute system 104. For example, a server configuration orchestrator (SCO) 131 and a network configuration orchestrator (NCO) 130 may operate as API-defined compute and network controllers that can automatically complete the provisioning a server instance on a compute resource 103 and the provisioning of network services between server instances, to the Internet, and/or to the user's private systems based on instructions received from the ECS orchestrator 108. ¶0020; In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. ¶0027;); or
instructing the first NaaS service system to perform one of:
building a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030);
deleting a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030); or
obtaining a status of building or deleting a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030);
wherein the plurality of NaaS service systems comprises at least one a NaaS IP service system, a NaaS virtual private cloud ("VPC") service system, a NaaS IPVPN network service system, or a NaaS layer 3 VPN service system (¶¶0020, 0023, 0027, 0030, 0036, 0064);
wherein triggering execution of the first task comprises instructing, via the NaaS API, a downstream system to execute the first task (For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. The NCO API 110 may further enable the ECS orchestrator 108 to receive information from the NCO 130, such as network resource information, status messages, etc. In some implementations, the NCO system 150 may be configured to receive requests directly from the user 102. ¶¶0027, 0037, Fig. 3).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 8, Maheshwari discloses:
the system, wherein:
the plurality of orchestrators comprises at least one of an IPVPN service orchestrator, an IPVPN network orchestrator, or a DyCon IPVPN orchestrator (This disclosure describes an interconnection platform for dynamically configuring and managing a cloud-based services exchange, or “cloud exchange,” to facilitate virtual connections for cloud services delivery from multiple cloud service providers to one or more cloud customers. ¶0005; In some examples, the techniques of this disclosure can allow automated API request interception to validate partner access to interconnection assets, thus ensuring security of partner assets through machine-to-machine interaction. In some examples, the techniques of this disclosure can allow on demand access to dynamically set up and tear down virtual circuits through machine-to-machine interaction and direct access to interconnection platform resources. In some examples, the techniques of this disclosure can allow on demand access to schedule setup and tear down of virtual circuits at pre-defined intervals through machine-to-machine interaction and direct access to interconnection platform resources. ¶0310; In accordance with techniques described herein, IP/MPLS fabric 1801 implement IP virtual private networks (IP-VPNs) to connect any of customers 1808 with multiple cloud service provider networks 1820 to provide a data center-based ‘transport’ and layer 3 cross-connect. ¶¶0374, 0383, Fig. 18); and
the plurality of task managers comprises at least one of a billing task manager (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services 408A-408H (collectively, “platform services 408”) in this example. As illustrated, the platform services 408 include billing and invoicing 408C, seller API integration 408D, virtual circuit management 408E, and network interface management 408F. Each of platform services may represent a workflow and rules engine for a different aspect of cloud service provisioning. ¶0277; Cloud exchange API services 409A-409R (collectively, “cloud exchange services 409”) represent services offered by the interconnection platform to modify the cloud exchange network infrastructure, manage content, manage incidents, manage inventory and capacity, ensure secured access, and manage orders/billing for providers and customers, as examples. ¶0292; Orchestration engine 407 can then invoke a billing service (e.g., billing service 409H, FIG. 3B) (480N) and receive a response from the billing service (480O). ¶0308), or a DyCon IPVPN task manager (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.).
Maheshwari does not explicitly disclose, however Ritchie discloses:
the plurality of task managers comprises at least one of a NaaS task manager ( In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. ¶0027);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 12, Maheshwari discloses:
the method, wherein the computing system comprises at least one of a dynamic connections ("DyCon") IPVPN system (The orchestration engine 704 operates as part of an overall interconnection platform (e.g., interconnection platform 103 of FIGS. 1B, 1C) to seamlessly set up interconnection assets including virtual connections (e.g., virtual circuits) between buyers and sellers, such as between an enterprise and a cloud service provider. In the example of FIG. 13, orchestration engine 704 includes two major components: orchestrator 706 and microservices 708 provided by the cloud exchange system 700. Orchestration engine 704 also includes service discovery engine 710 and process manager 712. Orchestration engine 704 may represent a centralized or distributed application and may execute on a management device such as one or virtual machines and/or real servers of data center 101 (FIG. 1A). ¶0328), a DyCon IPVPN controller (Examiner interprets ‘orchestrator factory’ as the orchestration engine. Orchestration engine 704 receives client requests for cloud exchange platform services, such as via the cloud exchange portal 814 or API gateway 816 (1500). Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). ¶0353, Fig. 15), a DyCon IPVPN gateway device (In some examples, cloud exchange 100 includes an API gateway 112 having one or more processors that executes one or more applications that expose software interfaces defined according to APIs 114. The applications may invoke services that correspond to endpoints of the APIs 114, and the services may themselves invoke the cloud exchange platform service of orchestration engine 118. ¶0041, Fig. 1A, 1B, 1C), a DyCon IPVPN orchestrator (Orchestration engine 704 sends the client request for cloud exchange platform services to orchestrator 706 (1502). Based on the client request, orchestrator 706 selects a workflow from a workflow library or folder (e.g., workflows folder 1612 of FIG. 16 including workflows WF1, WF2, WF3, and WF4), where the selected workflow contains the set of tasks needed to fulfill the request through microservice calls (1504). ¶0353, Fig. 15), a server (¶0328), a cloud computing system (¶0328), or a distributed computing system (The orchestration engine 704 operates as part of an overall interconnection platform (e.g., interconnection platform 103 of FIGS. 1B, 1C) to seamlessly set up interconnection assets including virtual connections (e.g., virtual circuits) between buyers and sellers, such as between an enterprise and a cloud service provider. In the example of FIG. 13, orchestration engine 704 includes two major components: orchestrator 706 and microservices 708 provided by the cloud exchange system 700. Orchestration engine 704 also includes service discovery engine 710 and process manager 712. Orchestration engine 704 may represent a centralized or distributed application and may execute on a management device such as one or virtual machines and/or real servers of data center 101 (FIG. 1A). ¶0328).
Maheshwari does not explicitly disclose, however Ritchie discloses:
the method, wherein the computing system comprises at least one of a NaaS workflow engine (In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. ¶0027);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 17, Maheshwari discloses:
A method, comprising:
receiving, by a task manager of a system and from an orchestrator of the system, a request to perform a first task among one or more dynamic connections ("DyCon") Internet Protocol virtual private network ("IPVPN") tasks (API gateway 112, in response to requests, invokes the cloud exchange platform service of orchestration engine 118, which may orchestrate a workflow of service tasks for the underlying sub-systems 120 to satisfy the request. ¶0048; Sub-systems 120 may apply the service tasks orchestrated by orchestration engine 118, which may include modifying any of cloud exchange points 128 to perform the on-demand setup of virtual circuits between CSPs 110 and customers 108, for example, or otherwise manage cloud exchange points 128 interconnection assets such as ports, metros, data centers, virtual circuits and virtual circuit bandwidth, profiles, and configuration. ¶0050; Orchestrator 706 selects a workflow for provisioning a virtual circuit from workflows folder 1612, loads the selected workflow. ¶0357; Examiner interprets a workflow that executes tasks on a state machine as one of many task managers.); and
performing, by the task manager, the following:
creating the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073);
triggering execution of the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073); and
updating the first task (API gateway 112 translates the resource URI and the optional parameters to cloud exchange platform-related constructs and invokes the cloud exchange platform of orchestration engine 118 according to one of a create, read, update, and delete (CRUD) or confirmation action corresponding to the endpoint 116 specified by the application data. ¶¶0049, 0073);
Maheshwari does not explicitly disclose, however Ritchi discloses:
wherein triggering execution of the first task, after creating the first task (For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. The NCO API 110 may further enable the ECS orchestrator 108 to receive information from the NCO 130, such as network resource information, status messages, etc. In some implementations, the NCO system 150 may be configured to receive requests directly from the user 102. ¶¶0027, 0037, Fig. 3), comprises:
requesting, by the task manager and from a NaaS application programming interface ("API") factory, a first NaaS service system among a plurality of NaaS service systems based on a first resource type associated with the first task (In some examples, the edge compute system 104 includes an Edge Compute System (ECS) Orchestrator 108 that provides a user interface (UI) 114 and an API 115. The ECS orchestrator 108 may be a software development kit that allows the user 102 to interface with the edge compute system 104. For example, a server configuration orchestrator (SCO) 131 and a network configuration orchestrator (NCO) 130 may operate as API-defined compute and network controllers that can automatically complete the provisioning a server instance on a compute resource 103 and the provisioning of network services between server instances, to the Internet, and/or to the user's private systems based on instructions received from the ECS orchestrator 108. ¶0020; In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. ¶0027;); and
instructing, by the task manager, the first NaaS service system to perform one of:
building a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030);
deleting a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030); or
obtaining a status of building or deleting a NaaS API associated with the first NaaS service system (¶¶0020, 0023, 0027, 0030).
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 18,
the method, wherein the system comprises at least one of a DyCon IPVPN system (The orchestration engine 704 operates as part of an overall interconnection platform (e.g., interconnection platform 103 of FIGS. 1B, 1C) to seamlessly set up interconnection assets including virtual connections (e.g., virtual circuits) between buyers and sellers, such as between an enterprise and a cloud service provider. In the example of FIG. 13, orchestration engine 704 includes two major components: orchestrator 706 and microservices 708 provided by the cloud exchange system 700. Orchestration engine 704 also includes service discovery engine 710 and process manager 712. Orchestration engine 704 may represent a centralized or distributed application and may execute on a management device such as one or virtual machines and/or real servers of data center 101 (FIG. 1A). ¶0328), a server (¶0328), a cloud computing system (¶0328), or a distributed computing system (The orchestration engine 704 operates as part of an overall interconnection platform (e.g., interconnection platform 103 of FIGS. 1B, 1C) to seamlessly set up interconnection assets including virtual connections (e.g., virtual circuits) between buyers and sellers, such as between an enterprise and a cloud service provider. In the example of FIG. 13, orchestration engine 704 includes two major components: orchestrator 706 and microservices 708 provided by the cloud exchange system 700. Orchestration engine 704 also includes service discovery engine 710 and process manager 712. Orchestration engine 704 may represent a centralized or distributed application and may execute on a management device such as one or virtual machines and/or real servers of data center 101 (FIG. 1A). ¶0328).
Maheshwari does not explicitly disclose, however Ritchie discloses:
the method, wherein the system comprises at least one of a network as a service ("NaaS") workflow engine (In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. ¶0027);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 19, Maheshwari discloses:
the method, further comprising:
handling, by the task manager, one or more task failures associated with implementing the first task (A workflow defines a task orchestration. Workflows provide a way to decompose a series of complex operations down to a sequence of discrete tasks within a state machine and executed by microservices to satisfy requests received via different request channels like portals and API. Each request can have different associated domain contracts. For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; In some cases, the sequence of tasks in a workflow may be more complex than just tasks performed in a series. Tasks can fail, and so orchestrator 706 may at times need to deal with timeouts, retries, “stuck” flows, and so forth. Orchestrator 706 may need to recover from a task failure, or from a whole workflow failure. In some examples, orchestrator 706 uses a service discovery engine 710 (FIG. 13) to discover an alternate microservice to use when a first task fails due to the microservice not responding properly or returning an error message. ¶0359);
wherein updating the first task comprises updating the first task based on callback information from the downstream system regarding whether or not execution of the first task was successful (The workflow specifies a set of tasks. For example, the workflow for provisioning the virtual circuit specifies a set of tasks comprising: (i) obtaining port details, (ii) obtaining metro details, and (iii) creating the virtual circuit based on the port details and the metro details. Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706.¶0358; Examiner interprets publish-subscribe server as the callback controller to notify the orchestrator.).
Maheshwari does not explicitly disclose, however Ritchie discloses:
wherein the plurality of NaaS service systems comprises at least one a NaaS IP service system, a NaaS VPC service system, a NaaS IPVPN network service system, or a NaaS layer 3 VPN service system (¶¶0020, 0023, 0027, 0030, 0036, 0064);
wherein triggering execution of the first task further comprises instructing, by the task manager and via the NaaS API, a downstream system to execute the first task (For example, the various network provisioning tasks, when executed, may provide end-to-end automated network provisioning services as part of providing on-demand edge compute service to the user 102. The NCO API 110 may further enable the ECS orchestrator 108 to receive information from the NCO 130, such as network resource information, status messages, etc. In some implementations, the NCO system 150 may be configured to receive requests directly from the user 102. ¶¶0027, 0037, Fig. 3);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
RE Claim 20, Maheshwari discloses:
the method, wherein the one or more DyCon IPVPN tasks (This disclosure describes an interconnection platform for dynamically configuring and managing a cloud-based services exchange, or “cloud exchange,” to facilitate virtual connections for cloud services delivery from multiple cloud service providers to one or more cloud customers. ¶0005; In accordance with techniques described herein, IP/MPLS fabric 1801 implement IP virtual private networks (IP-VPNs) to connect any of customers 1808 with multiple cloud service provider networks 1820 to provide a data center-based ‘transport’ and layer 3 cross-connect. ¶¶0374, 0383, Fig. 18) comprise at least one of:
one or more virtual routing and forwarding ("VRF") tasks (Interconnection platform 103 may receive service requests for creating, reading, updating, and/or deleting end-to-end services of the cloud exchange point 1803. In response, interconnection platform 103 may configure PEs 1802, 1804 and/or other network infrastructure of IP/MPLS fabric 1801 to provision or obtain performance or other operations information regarding the service. Operations for provisioning a service and performed by interconnection platform 103 may include configuring or updating VRFs, installing SDN forwarding information, configuring LSPs or other tunnels, configuring BGP, configuring access links 1816 and aggregation links 1822, or otherwise modifying the configuration of the IP/MPLS fabric 1801. Other operations may include making service requests to an orchestration system for cloud service provider networks 1820, as described in further detail below. ¶¶0383-0384, Fig. 19) including at least one of:
building a VRF instance (¶¶0383-0384, Fig. 19);
deleting a VRF instance (¶¶0383-0384, Fig. 19); or
updating a VRF instance (¶¶0383-0384, Fig. 19);
one or more layer 3 VPN tasks ( For some customers of cloud exchange point 1803, the cloud exchange point 1803 provider may configure a full mesh arrangement whereby a set of PEs 1802, 1804 each couple to a different customer site network for the customer. In such cases, the IP/MPLS fabric 1801 implements a layer 3 VPN (L3VPN) for cage-to-cage or redundancy traffic (also known as east-west or horizontal traffic). The L3VPN may effectuate a closed user group whereby each customer site network can send traffic to one another but cannot send or receive traffic outside of the L3VPN. ¶0377) including at least one of:
building a layer 3 VPN network (Implements a layer 3 VPN, ¶0377);
deleting a layer 3 VPN network (Implements a layer 3 VPN, ¶0377); or
updating a layer 3 VPN network (Implements a layer 3 VPN, ¶0377);
one or more layer 3 VPN API FQM tasks (Element is optional) including at least one of:
creating a layer 3 VPN API FQM (Element is optional); or
deleting a layer 3 VPN API FQM (Element is optional);
one or more billing tasks (API gateway 403, in some examples, transforms application data formatted according to a request to any of endpoints 406 and uses the transformed application data to make calls to orchestration engine 407. Orchestration engine 407 may represent one or more real servers and/or virtual machines configured to implement the cloud exchange platform services 408A-408H (collectively, “platform services 408”) in this example. As illustrated, the platform services 408 include billing and invoicing 408C, seller API integration 408D, virtual circuit management 408E, and network interface management 408F. Each of platform services may represent a workflow and rules engine for a different aspect of cloud service provisioning. ¶0277; Cloud exchange API services 409A-409R (collectively, “cloud exchange services 409”) represent services offered by the interconnection platform to modify the cloud exchange network infrastructure, manage content, manage incidents, manage inventory and capacity, ensure secured access, and manage orders/billing for providers and customers, as examples. ¶0292; Orchestration engine 407 can then invoke a billing service (e.g., billing service 409H, FIG. 3B) (480N) and receive a response from the billing service (480O). ¶0308) including at least one of:
building a billing record (¶¶0277, 0292, 0308);
deleting a billing record (¶¶0277, 0292, 0308);
updating a billing record (¶¶0277, 0292, 0308);
one or more billing API FQM tasks (Element is optional) including at least one of:
creating a billing API FQM (Element is optional); or
deleting a billing API FQM (Element is optional); or
one or more inventory tasks (Endpoints 406 represent available logical and/or physical resources accessible to API consumers 402. That is, API consumers 406 may access endpoints 406 to access the interconnection platform of a cloud exchange to get information regarding, create, modify, delete, and/or confirm requests for corresponding resources of the cloud exchange. Endpoints 406 may represent example instances of endpoints 116 of FIGS. 1B-1C. ¶0071) including at least one of:
updating a network resource inventory (¶0071); or
auditing a network resource inventory (¶0071).
Maheshwari does not explicitly disclose, however Ritchie discloses:
one or more network as a service ("NaaS") IPVPN tasks ( In some examples, the abstraction layer 109 may further include a network configuration orchestration (NCO) system 150, which may sometimes be referred to as a Network-as-a-Service (NaaS) system. For example, the NCO system 150 may include a network configuration orchestrator (NCO) API 110 that may operate to provide an interface between the ECS orchestrator 108 and the NCO 130. For example, the NCO API 110 may enable the ECS orchestrator 108 to communicate with the NCO 130 for receiving requests that enable the NCO 130 to integrate with existing network controllers, orchestrators, and other systems to perform various network provisioning tasks (e.g., to build and provision a communication path between server instances) that may be included in a workflow method that may be executed by the ECS orchestrator 108. ¶0027; In some examples, network provisioning may include automating connections to a virtual private network (VPN), to a public cloud provider, to a private cloud provider, etc. According to an example, the network configurator 112 may operate to interrogate network elements, reserve network resources in the network 106, configure ports on network resources, create a domain path between server instances, delete domain paths, release network resources, and/or perform other edge compute network provisioning interactions based on the requirements sent from the ECS orchestrator 108. ¶0030) including at least one of:
building a NaaS IPVPN network (¶¶0027, 0030);
deleting a NaaS IPVPN network (¶¶0027, 0030); or
updating a NaaS IPVPN network (¶¶0027, 0030);
one or more NaaS API framework for queue management ("FQM") tasks (In some examples, the edge compute system 104 includes an Edge Compute System (ECS) Orchestrator 108 that provides a user interface (UI) 114 and an API 115. The ECS orchestrator 108 may be a software development kit that allows the user 102 to interface with the edge compute system 104. For example, a server configuration orchestrator (SCO) 131 and a network configuration orchestrator (NCO) 130 may operate as API-defined compute and network controllers that can automatically complete the provisioning a server instance on a compute resource 103 and the provisioning of network services between server instances, to the Internet, and/or to the user's private systems based on instructions received from the ECS orchestrator 108. ¶0020; In multi-tiered orchestration, a challenge is concurrency and how to deal with concurrent requests to scale. In some examples, queuing mechanisms may be implemented between different layers (NaaS, MaaS, ACT, L2 and L3 Activation). When accessing resources from the network, decisions on which resources to utilize may be made before configuring them. When concurrent requests are run, queues may be implemented to temporarily store information retrieved from the network before configuration to avoid race conditions associated with accessing a same network resource. ¶0064) including at least one of:
creating a NaaS API framework for queue management ("FQM") (¶¶0020, 0064); or
deleting a NaaS API FQM (¶¶0020, 0064);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1)
Claim(s) 7 is rejected under 35 U.S.C. 103 as being unpatentable over Maheshwari, in view of Ritchie, in view of Yang et al. (US 20170063615 A1, hereinafter “Yang”).
RE Claim 7, Maheshwari discloses:
the system, wherein the callback controller is further configured (In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706. ¶0358; Examiner interprets publish-subscribe server as the callback controller to notify the orchestrator.) to:
perform an update function including at least one of:
finding a database record matching a product instance identifier ("ID") of a first product associated with the first task (Orchestration engine 704 may communicate with SaaS web portal 716 (e.g., a CSP portal) using a network protocol such as Hyper Text Transfer Protocol (HTTP), for example, or other network protocol. Orchestration engine 704 can receive requests entered using APIs 717 via an API gateway 718. API gateway 718 may represent any of the API gateways described herein and uses service discovery engine 710 to identify service instances to which to route requests received via APIs 717. ¶0333);
finding a transaction within a service data transfer object ("DTO") model matching a transaction ID of a transaction associated with the first product and the first task (Transact APIs 304B may be usable to dynamically provision end-to-end virtual circuits of varying bandwidths through machine-to-machine interaction, validate virtual circuits requested by a customer, and confirm deletion of virtual circuits, for example. ¶0064; The tables below show an overview of the API resources, their respective URIs, and supported operations on each resource. The APIs are divides in three major sections: Buyer, Seller, and Foundational APIs. Reference herein to XML refers to eXtensible Markup Language, while JSON refers to JavaScript Object Notation. ¶¶0080, 0219-0221; For example, orchestrator 706 may select the workflow based on configured rules or policies (e.g., policies 308A of FIG. 2), and/or based on a profile associated with the client (e.g., profiles 308B of FIG. 2). Orchestrator 706 will automatically load the selected workflow, and the microservices execute according to the workflow (e.g., sequentially and/or in parallel) (1506). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. ¶0353; Examiner interprets the DTO model as a specific workflow identified for a specific customer, identified customer, for configuration of provisioning.);
finding a task with the transaction matching a task ID and a task type of the first task (For example, orchestrator 706 may select the workflow based on configured rules or policies (e.g., policies 308A of FIG. 2), and/or based on a profile associated with the client (e.g., profiles 308B of FIG. 2). Orchestrator 706 will automatically load the selected workflow, and the microservices execute according to the workflow (e.g., sequentially and/or in parallel) (1506). The workflows folder 1612 contains workflows that have been previously defined (e.g., by cloud exchange developers) for each customer endpoint. For example, there may be a first workflow defined for a metro customer endpoint and a second workflow defined for a port customer endpoint. ¶0353);
calling a task manager among the plurality of task managers to update a task status of the first task (Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706. ¶0358; Examiner interprets transaction as a list of tasks.);
updating the first transaction (Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706.¶0358; Examiner interprets transaction as a list of tasks.); or
updating the first network provisioning service (Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706.¶0358);
based on a determination that a task status of the first task is success, initiate implementation of a next task in the first ordered list of tasks (Orchestrator 706 can distribute tasks of the set of tasks across a plurality of workflow runners 1616A-1616D, which access one or more of microservices 1630A-1630D (endpoints) to perform the tasks. The workflow runners 1616 may pick jobs from a queue maintained by data structure store 1610. In some examples, each task in a selected workflow may be executed on a different thread. Tasks may be executed in parallel or sequentially. As each task finishes, publish-subscribe server 1620 is updated, and publish-subscribe server 1620 notifies orchestrator 706. ¶0358);
based on a determination that the first task is a non-critical build task and that the task status of the first task is failure, proceed with a next task among the one or more DyCon IPVPN tasks (Interconnection platform 103 may receive service requests for creating, reading, updating, and/or deleting end-to-end services of the cloud exchange point 1803. In response, interconnection platform 103 may configure PEs 1802, 1804 and/or other network infrastructure of IP/MPLS fabric 1801 to provision or obtain performance or other operations information regarding the service. Operations for provisioning a service and performed by interconnection platform 103 may include configuring or updating VRFs, installing SDN forwarding information, configuring LSPs or other tunnels, configuring BGP, configuring access links 1816 and aggregation links 1822, or otherwise modifying the configuration of the IP/MPLS fabric 1801. ¶0383; For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; In some cases, the sequence of tasks in a workflow may be more complex than just tasks performed in a series. Tasks can fail, and so orchestrator 706 may at times need to deal with timeouts, retries, “stuck” flows, and so forth. Orchestrator 706 may need to recover from a task failure, or from a whole workflow failure. In some examples, orchestrator 706 uses a service discovery engine 710 (FIG. 13) to discover an alternate microservice to use when a first task fails due to the microservice not responding properly or returning an error message. ¶0359);
based on a determination that the first task is a non-critical delete task and that the task status of the first task is failure, proceed with the next task among the one or more DyCon IPVPN tasks (Interconnection platform 103 may receive service requests for creating, reading, updating, and/or deleting end-to-end services of the cloud exchange point 1803. In response, interconnection platform 103 may configure PEs 1802, 1804 and/or other network infrastructure of IP/MPLS fabric 1801 to provision or obtain performance or other operations information regarding the service. Operations for provisioning a service and performed by interconnection platform 103 may include configuring or updating VRFs, installing SDN forwarding information, configuring LSPs or other tunnels, configuring BGP, configuring access links 1816 and aggregation links 1822, or otherwise modifying the configuration of the IP/MPLS fabric 1801. ¶0383; For a given request, orchestrator 706 selects a workflow that uses a sequence of discrete tasks within a state machine to satisfy the domain contract associated with the request. ¶0353; In some cases, the sequence of tasks in a workflow may be more complex than just tasks performed in a series. Tasks can fail, and so orchestrator 706 may at times need to deal with timeouts, retries, “stuck” flows, and so forth. Orchestrator 706 may need to recover from a task failure, or from a whole workflow failure. In some examples, orchestrator 706 uses a service discovery engine 710 (FIG. 13) to discover an alternate microservice to use when a first task fails due to the microservice not responding properly or returning an error message. ¶0359).
Maheshwari and Ritchie do not explicitly disclose, however Yang discloses:
based on a determination that the first task is a critical build task and that the task status of the first task is failure (Examiner interpretation that a critical task is a priority task depending on customer request and associated SLA. Priority based on the quality of service and the cloud infrastructure system for a time period where priority may be basic, silver, or gold levels. ¶0067; As illustrated, requests can be associated with varying numbers of tasks to perform each request. Certain tasks can be associated with provisioning resources to enable a service request. Each service request can, via a policy, be determined to be delineated into a plurality of tasks. The policy can determine which tasks are to be performed, the order of the tasks, or other information related to performance of the tasks. For example, a policy can include one or more processes for provisioning a service. Each of the processes can be associated, via a policy, with a plurality of tasks, as disclosed herein.¶0120), initiating a rollback process and updating an IPVPN state to reflect activation failure (A rollback may be desirable when a task fails within a request requiring resources provisioned by other tasks in the request to be released. For example, a task may request a resource that may not be able to be provisioned. In such a scenario, the status of the remaining resources for provisioning the request of the task could be unknown, leaving the system in an unknown state. It may therefore be desirable to rollback the entire request, including all resources already provisioned for the request, so that the system can be left in a known state. ¶0175, Fig. 11A; Various states associated with a task include ‘started’, ‘failed’, ‘rollback-failed’, ‘rollback-fail-skipped’, and ‘rollback success’. ¶0126; Request-task information table stores information about tasks associated with a request. For instance, request-task information table 822 may identify for each request, each of the tasks for enabling a service for the request and the ‘state’ of execution that the task is currently in. In an embodiment, the tasks associated with each request may be executed in a serialized manner according to a process for provisioning to enable a service. The Process may define an order for execution of the tasks. ¶0124);
based on a determination that the first task is a critical delete task and that the task status of the first task is failure (Examiner interpretation that a critical task is a priority task depending on customer request and associated SLA. Priority based on the quality of service and the cloud infrastructure system for a time period where priority may be basic, silver, or gold levels. ¶0067; Change of service level for a service may include canceling the service. ¶0087; A ‘cancel paused’ state indicates that the request to cancel the request has failed. ¶0124; Examiner interpretation that a cancel request is a delete request.), stopping process of deletion and updating the IPVPN state to reflect disconnection failure(As noted above, in certain embodiments, various states may be associated with a task. These states may include, for instance, a ‘ready’ state to indicate the creation of a task associated with a request, a ‘started’ state to indicate that a task has begun executing, a ‘wait-retry’ state to indicate that a task has failed and is waiting in the queue to retry, a ‘wait-continue’ state to indicate that a task has not yet completed and is waiting in the queue, a ‘completed’ state to indicate that a task has completed, a ‘failed’ state to indicated that a task has failed and that there are no more retries available for the task, a ‘rollback-success’ state, a ‘rollback-failed’ state, a ‘rollback-fail-skipped’ state and so on. ¶0126);
It would have been obvious to one having ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Maheshwari, creating VPN configurations with an orchestrator as part of an interconnection platform, with the teachings of Ritchie, implement orchestrator by a Network-as-a-Service, NaaS for a VPN, with the teachings of Yang, error-handling methods for building or deleting provisioned resources and provide status to task execution.
The motivation in doing so would be to automate the dynamic aspects of cloud services provisioning for a customer to establish, de-install, and err-handling to manage interconnections by configuration of VPNs. (Maheshwari: Abstract, ¶¶0005-0012, 0040, 0044, 0064-0065, Fig. 1A, 1B, 1C, 11; Ritchie: Abstract, ¶¶0005-0007, 0017, 0020, 0027, 0030, Fig. 1; Yang: Abstract, ¶¶0002-0016, 0133-0134, 0162-1064, Fig. 11A, 11D)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
US-20170063648-A1 Nadaf et al.
“FRAMEWORK FOR PROVISIONING NETWORK SERVICES IN CLOUD COMPUTING ENVIRONMENT”
This disclosure relates generally to provisioning network services in a cloud computing environment, and more particularly to framework for provisioning network services in a heterogeneous cloud computing environment. In one embodiment, the disclosure includes a network as a service (NaaS) layer under a cloud provisioning platform. The NaaS layer can be interfaced with any cloud provisioning platform. The NaaS layer serves the networking needs of the heterogeneous cloud environment. It provides network services like monitoring, notifications, QoS policies, network topology and other services. For example, the cloud provisioning platform defines a virtual network and attaches a plurality of virtual machines to it. All the communications related to creation/deletion/update of virtual networks, virtual subnets, virtual ports, virtual router, virtual interfaces etc., are sent to the NaaS layer. On receiving the communication, the NaaS layer takes necessary steps to provide the network services as per the needs of the request. Apart from provisioning, the NaaS layer periodically monitors the network elements as well.
US-20240305604-A1 Dzhigarov et al.
“METHODS AND APPARATUS TO ORCHESTRATE INTERNET PROTOCOL ADDRESS MANAGEMENT”
An example system includes at least one memory; programmable circuitry; and machine-readable instructions to program the programmable circuitry to: select an orchestration integration based on capability tags of a plurality of orchestration integrations and based on constraints of an internet protocol address management (IPAM) integration; and cause execution of a workflow using the orchestration integration, the workflow to cause an IPAM system to allocate an internet protocol address for a resource of a cloud application.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PAUL A. LANGER whose telephone number is (703)756-1780. The examiner can normally be reached Monday - Friday, 8:00 am - 5:00 pm, Eastern.
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, Nishant B. Divecha can be reached at 1 (571) 270-3125. 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.
/PAUL A. LANGER/Examiner, Art Unit 2419
/Nishant Divecha/Supervisory Patent Examiner, Art Unit 2419
Prosecution Insights