The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Notice to Applicant
In response to the communication received on 04/28/2026, the following is a Final Office Action for Application No. 18486228.
Status of Claims
Claims 1-20 are pending.
Response to Amendments
Applicant’s amendments have been fully considered.
Response to Arguments
Applicant’s arguments with respect to the claims have been considered but are moot in light of the new grounds of rejection, as necessitated by amendment.
As per the 101 rejection, Applicant argues that the claims are in favor of eligibility per Prong One of Step 2A, however Examiner respectfully disagrees. Per Prong One of Step 2A, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity. Particularly, the identified recitation falls within the Mental Processes including concepts performed in the human mind (including an observation, evaluation judgment, opinion) and/or Certain Methods of Organizing Human Activity including managing personal behavior or relationships or interactions between people (including social activities, teaching, and following rules of instructions). Since the recitation of the claims falls into at least one of the above Groupings, there is a basis for providing further analysis with regard to Prong Two of Step 2A to determine whether the recitation of an abstract idea is deduced to being directed to an abstract idea. Thus, the rejection is maintained.
Applicant argues that the claims are in favor of eligibility per Prong Two of Step 2A, however Examiner respectfully disagrees. Per Prong Two of Step 2A, this judicial exception is not integrated into a practical application because the claim as a whole does not integrate the identified abstract idea into a practical application. The non-transitory computer-readable medium, computing device, processor and/or memory is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing/transmitting data. This generic processor server limitation is no more than mere instructions to apply the exception using a generic computer component. Further, non-transitory computer-readable medium, computing device, processor and/or memory to inter alia perform the function of running the mesh service which parses the DSL and generates a REST API is mere instruction to apply an exception using a generic computer component which cannot integrate a judicial exception into a practical application. Accordingly, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. In other words, the present claims use a generic processing device and memory medium to inter alia perform the function of running the mesh service which parses the DSL and generates a REST API which is a concept that can be performed in the human mind. The processor is merely used to perform the function(s), and the processor does not integrate the abstract idea into a practical application since there are no meaningful limits on practicing the abstract idea. Thus, since the claims are directed to the determined judicial exception in view of the two prongs of Step 2A, the 2019 PEG flowchart is directed to Step 2B. Thus, the rejection is maintained.
Applicant argues that the claims are in favor of eligibility per Step 2B, however Examiner respectfully disagrees. Therein, the additional elements and combinations therewith are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. It is noted here that the additional elements are to be considered both individually and as an ordered combination. In this case, the claims each at most comprise additional elements of: non-transitory computer-readable medium, computing device, processor and/or memory. Taken individually, the additional limitations each are generically recited and thus does not add significantly more to the respective limitations. Further, non-transitory computer-readable medium, computing device, processor and/or memory to inter alia perform the function of running the mesh service which parses the DSL and generates a REST API is mere instruction to apply an exception using a generic computer component which cannot provide an inventive concept in Step 2B (or, looking back to Step 2A, cannot integrate a judicial exception into a practical application). For further support, the Applicant’s specification supports the claims being directed to use of a generic computer/memory type structure. Taken as an ordered combination, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are directed to limitations referenced in Alice Corp. that are not enough to qualify as significantly more when recited in a claim with an abstract idea include the non-limiting or non-exclusive examples of MPEP § 2106.05. Thus, the rejection is maintained.
In an effort to further expedite prosecution, see: Appendix 1 to the October 2019 Update: Subject Matter Eligibility, Life Sciences & Data Processing Examples, October 2019 30, Example 46. Livestock Management. Per claim 1 of Example 46, the memory, display and processor are recited so generically (no details whatsoever are provided other than that they are a memory, display and processor) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. As an exemplary direction for similar claim limitations to be eligible, see claims 2-4 of Example 46.
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.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims fall within statutory class of process or machine or manufacture; hence, the claims fall under statutory category of Step 1.
Step 2 is the two-part analysis from Alice Corp. (also called the Mayo test). The 2019 PEG makes two changes in Step 2A: It sets forth new procedure for Step 2A (called “revised Step 2A”) under which a claim is not “directed to” a judicial exception unless the claim satisfies a two-prong inquiry. The two-prong inquiry is as follows: Prong One: evaluate whether the claim recites a judicial exception (an abstract idea enumerated in the 2019 PEG, a law of nature, or a natural phenomenon). If claim recites an exception, then Prong Two: evaluate whether the claim recites additional elements that integrate the exception into a practical application of the exception. The claim(s) recite(s) the following abstract idea indicated by non-boldface font and additional limitations indicated by boldface font:
A computer-implemented method for generating a mesh service, comprising:receiving, by at least one processor, an input that comprises a domain specific language (DSL) indicating a plurality of service containers; retrieving a container image from a container repository responsive to the receiving of the input; creating a new container image based on the container image and the plurality of service containers indicated in the input; creating a component by calling an application programming interface (API) of an estration platform, wherein the component comprises at least one of a Pod, a ReplicaSet, an Endpoint, an Ingress, a Service, or a Deployment for the mesh service; creating the mesh service based on the new container image and the component; andrunning the mesh service, wherein the mesh service parses the DSL and generates one or more representational state transfer (REST) APIs that retrieve data from the plurality of service containers.
[or]
A system for generating a mesh service, comprising:a memory; and at least one processor coupled to the memory and configured to: receive an input indicating a plurality of service containers; retrieve a container image from a container repository responsive to the receiving of the input; create a new container image based on the container image and the plurality of service containers indicated in the input; create a component by calling an application programming interface (API) of an orchestration platform, wherein the component comprises at least one of a Pod, a ReplicaSet, an Endpoint, an Ingress, a Service, or a Deployment for the mesh service; creating create the mesh service based on the new container image and the component; andrun the mesh service, wherein the mesh service parses the DSL and generates one or more representational state transfer (REST) APIs that retrieve data from the plurality of service containers.
[or]
A non-transitory computer-readable medium having instructions stored thereon that, when executed by at least one computing device, cause the at least one computing device to perform operations comprising:receiving an input indicating a plurality of service containers; retrieving a container image from a container repository responsive to the receiving of the input; creating a new container image based on the container image and the plurality of service containers indicated in the input; creating a component by calling an application programming interface (API) of an orchestration platform, wherein the component comprises at least one of a Pod,a ReplicaSet, an Endpoint, an Ingress, a Service, or a Deployment for the mesh service; creating the mesh service based on the new container image and the component; andrunning the mesh service, wherein the mesh service parses the DSL and generates one or more representational state transfer (REST) APIs that retrieve data from the plurality of service containers.
The claim(s) recite(s) the following summarization of the abstract idea which includes generating a mesh service based on the new container image and the component executed by the additional element(s) of non-transitory computer readable storage medium, computer device, memory and/or processor. This falls into at least the Abstract Idea Grouping of Mental Processes since the information can be analyzed by an abstract evaluation judgment process. Thus, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity since the identified recitation falls within the Mental Processes including concepts performed in the human mind (including an observation, evaluation judgment, opinion). Per Prong One of Step 2A, the identified recitation of an abstract idea falls within at least one of the Abstract Idea Groupings consisting of: Mathematical Concepts, Mental Processes, or Certain Methods of Organizing Human Activity. Particularly, the identified recitation falls within the Mental Processes including concepts performed in the human mind (including an observation, evaluation judgment, opinion).
Per Prong Two of Step 2A, this judicial exception is not integrated into a practical application because the claim as a whole does not integrate the identified abstract idea into a practical application. The non-transitory computer-readable medium, computing device, processor and/or memory is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing/transmitting data. This generic non-transitory computer-readable medium, computing device, processor and/or memory limitation is no more than mere instructions to apply the exception using a generic computer component. Further, creating a mesh service based on the new container image and the component by a non-transitory computer-readable medium, computing device, processor and/or memory is mere instruction to apply an exception using a generic computer component which cannot integrate a judicial exception into a practical application. Accordingly, this/these additional element(s) does/do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Thus, since the claims are directed to the determined judicial exception in view of the two prongs of Step 2A, the 2019 PEG flowchart is directed to Step 2B.
Per Step 2B, the additional elements and combinations therewith are examined in the claims to determine whether the claims as a whole amounts to significantly more than the judicial exception. It is noted here that the additional elements are to be considered both individually and as an ordered combination. In this case, the claims each at most comprise additional elements of: non-transitory computer-readable medium, computing device, processor and memory. Taken individually, the additional limitations each are generically recited and thus does not add significantly more to the respective limitations. Further, creating a mesh service based on the new container image and the component by a non-transitory computer-readable medium, computing device, processor and/or memory is mere instruction to apply an exception using a generic computer component which cannot provide an inventive concept in Step 2B (or, looking back to Step 2A, cannot integrate a judicial exception into a practical application). For further support, the Applicant’s specification supports the claims being directed to use of a generic computer/memory type structure at ¶0037 wherein “Computer system 300 may include one or more processors (also called central processing units, or CPUs), such as a processor 304.” Taken as an ordered combination, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the limitations are directed to limitations referenced in Alice Corp. that are not enough to qualify as significantly more when recited in a claim with an abstract idea include, as a non-limiting or non-exclusive examples: i. Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f));
PNG
media_image1.png
18
19
media_image1.png
Greyscale
ii. Simply appending well-understood, routine, conventional activities previously known to the industry, specified at a high level of generality, to the judicial exception, e.g., a claim to an abstract idea requiring no more than a generic computer to perform generic computer functions that are well-understood, routine and conventional activities previously known to the industry, as discussed in Alice Corp., 134 S. Ct. at 2359-60, 110 USPQ2d at 1984 (see MPEP § 2106.05(d));
PNG
media_image1.png
18
19
media_image1.png
Greyscale
iii. Adding insignificant extra-solution activity to the judicial exception, e.g., mere data gathering in conjunction with a law of nature or abstract idea such as a step of obtaining information about credit card transactions so that the information can be analyzed by an abstract mental process, as discussed in CyberSource v. Retail Decisions, Inc., 654 F.3d 1366, 1375, 99 USPQ2d 1690, 1694 (Fed. Cir. 2011) (see MPEP § 2106.05(g)); or
PNG
media_image1.png
18
19
media_image1.png
Greyscale
v. Generally linking the use of the judicial exception to a particular technological environment or field of use, e.g., a claim describing how the abstract idea of hedging could be used in the commodities and energy markets, as discussed in Bilski v. Kappos, 561 U.S. 593, 595, 95 USPQ2d 1001, 1010 (2010) or a claim limiting the use of a mathematical formula to the petrochemical and oil-refining fields, as discussed in Parker v. Flook. The courts have recognized the following computer functions inter alia to be well-understood, routine, and conventional functions when they are claimed in a merely generic manner: performing repetitive calculations; receiving, processing, and storing data (e.g., the present claims); electronically scanning or extracting data; electronic recordkeeping; automating mental tasks (e.g., process/machine/manufacture for performing the present claims); and receiving or transmitting data (e.g., the present claims).
The dependent claims do not cure the above stated deficiencies, and in particular, the dependent claims further narrow the abstract idea without reciting additional elements that integrate the exception into a practical application of the exception or providing significantly more than the abstract idea. Since there are no elements or ordered combination of elements that amount to significantly more than the judicial exception, the claims are not eligible subject matter under 35 USC §101.
Thus, viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself. Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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 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 of this title, 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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bahmeit et al. (WO 2023060025 A1) hereinafter referred to as Bahmeit in view of Bahl et al. (US 20210019194 A1) hereinafter referred to as Bahl.
Bahmeit teaches:
Claim 1. A computer-implemented method for generating a mesh service, comprising:
receiving, by at least one processor, an input that comprises a domain specific language (DSL) indicating a plurality of service containers (¶0012 The user interface may receive user inputs (which may be referred to as an input entered via the GUI) such as graphical user inputs to drag and drop or otherwise define a VNR. The user interface may pass these inputs to a network controller as a request by which to configure the VNR. The user may enter the inputs through interactions with the GUI to graphically define the VNR, selecting virtual networks and other network elements to which the VNR is targeted to establish interconnectivity (e.g., mesh connectivity and/or hub-and-spoke connectivity). The network controller may process these inputs and update the GUI to present prompts and other GUIs by which to prompt the user for additional inputs that may be required to define the VNR. The network controller may reduce these inputs defining the VNR into the various policies ¶0214 Each of API server 300A, controller 406A, custom API server 301A, and custom resource controller 302A includes code executable by microprocessor 1310. Custom API server 301A validates and configures data for custom resources for SDN architecture configuration (such as VNs 50 and VNRs 52). A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition. A service may be implemented in part as, or otherwise include, a load balancer. API server 300A and custom API server 301A may implement a Representational State Transfer (REST) interface to process REST operations and provide the frontend, as part of the configuration plane for an SDN architecture, to a corresponding cluster’s shared state stored to configuration store 1328. API server 300A may represent a Kubernetes API server ¶0355 The RI controller patches VNR-1-RT at VNR-RI, and informs the Kube-api of the patch (1774, 1776). The Kube- api updates Etcd on the patch (1778) and interfaces with RI controller to set VNR-1 status to indicate “Success”), whereupon the Kube-api updates Ectd on the success of VNR-1 status (1780). [0360] The following provides the detailed design for the VNR API schema (as YAML files): API Type (Schema) type VirtualNetworkRouterSpec struct { // Common spec fields CommonSpec `json:",inline" ¶0171 Computing device 500 includes in this example, a bus 542 coupling hardware components of a computing device 500 hardware environment. Bus 542 couples network interface card (NIC) 530, storage disk 546, and one or more microprocessors 210 (hereinafter, "microprocessor 510"). NIC 530 may be SR-IOV-capable. A front-side bus may in some cases couple microprocessor 510 and memory device 524.);
retrieving a container image from a container repository responsive to the receiving of the input (¶0198 Based on the container specification data, orchestration agent 592 directs container engine 590 to obtain and instantiate the container images for containers 529, for execution of containers 529 by computing device 500.);
creating a new container image based on the container image and the plurality of service containers indicated in the input (¶0192 Containers 529A may also source inner packets as source virtual network endpoints. Container 529A, for instance, may generate a layer 3 inner packet destined for a destination virtual network endpoint that is executed by another computing device (i.e., not computing device 500) or for another one of containers. Container 529A may sends the layer 3 inner packet to virtual router 506 via the virtual network interface attached to VRF 222A. [0193 Virtual router 506 receives the inner packet and layer 2 header and determines a virtual network for the inner packet. Virtual router 506 may determine the virtual network using any of the above-described virtual network interface implementation techniques (e.g., macvlan, veth, etc.). Virtual router 506 uses the VRF 222A corresponding to the virtual network for the inner packet to generate an outer header for the inner packet, the outer header including an outer IP header for the overlay tunnel and a tunnel encapsulation header identifying the virtual network. Virtual router 506 encapsulates the inner packet with the outer header. Virtual router 506 may encapsulate the tunnel packet with a new layer 2 header having a destination layer 2 address associated with a device external to the computing device 500, e.g., a TOR switch 16 or one of servers 12. If external to computing device 500, virtual router 506 outputs the tunnel packet with the new layer 2 header to NIC 530 using physical function 221. NIC 530 outputs the packet on an outbound interface.);
creating a component by calling an application programming interface (API) of an orchestration platform, wherein the component comprises at least one of a Pod,a ReplicaSet, an Endpoint, an Ingress, a Service, or a Deployment for the mesh service (¶0036 As a result, the SDN architecture components are microservices and, in contrast to existing network controllers, the SDN architecture assumes a base container orchestration platform to manage the lifecycle of SDN architecture components. A container orchestration platform is used to bring up SDN architecture components; the SDN architecture uses cloud native monitoring tools that can integrate with customer provided cloud native options; the SDN architecture provides declarative way of resources using aggregation APIs for SDN architecture objects (i.e., custom resources). The SDN architecture upgrade may follow cloud native patterns, and the SDN architecture may leverage Kubernetes constructs such as Multus, Authentication & Authorization, Cluster API, KubeFederation, KubeVirt, and Kata containers. The SDN architecture may support data plane development kit (DPDK) pods, and the SDN architecture can extend to support Kubernetes with virtual network policies and global security policies. ¶0056 The term “virtual execution element” encompasses virtual machines, containers, and other virtualized computing resources that provide an at least partially independent execution environment for applications. The term “virtual execution element” may also encompass a pod of one or more containers. Virtual execution elements may represent application workloads. As shown in FIG.1, server 12A hosts one virtual network endpoint in the form of pod 22 having one or more containers. ¶0070 In one example, pod 22 is a Kubernetes pod and an example of a virtual network endpoint. A pod is a group of one or more logically-related containers (not shown in FIG. 1), the shared storage for the containers, and options on how to run the containers. Where instantiated for execution, a pod may alternatively be referred to as a “pod replica.” Each container of pod 22 is an example of a virtual execution element. Containers of a pod are always co-located on a single server, co-scheduled, and run in a shared context. The shared context of a pod may be a set of Linux namespaces, cgroups, and other facets of isolation.);
creating the mesh service based on the new container image and the component (¶0293 Each of graphical nodes 2008A-2008C includes a graphical icon denoting a VNR configured to provide mesh connectivity along with text identifying each of graphical nodes 2008A-2008C as a VNR along with text denoting the type of connectivity (e.g., “Mesh”). ¶0319 The user may next select mesh VNR52008C (as shown at dynamic flow step four), whereupon GUI 2000J may, responsive to the input specifying that mesh VNR5 2008C was selected, update graphical representation 2002A (at dynamic flow step five) to reflect a pending connection between VN82004G and mesh VNR52008C. In the example of FIG.10K, GUI 2000K shows the result of completing the dynamic flow via GUI 2000J described above with respect to the example of FIG.10J. Responsive to receiving an input indicating that the dynamic flow has been completed, GUI 2000K may present prompt 2400 that guides the user to review VN label additions to VN8 2004G. ¶0322 FIG.11 is a diagram illustrating a first instance in which a virtual network router may be configured to enable mesh interconnectivity between virtual networks in accordance with various aspects of the techniques described in this disclosure. In the example of FIG.11, a virtual network (“VN”) 1500A (also shown as “VN1”) and a VN 1500B (also shown as “VN2”) are defined and implemented within Kubernetes (or some other orchestration platform) as custom resources, which are then implemented as VNs within an SDN architecture, such as SDN architecture 700 ¶0326 This import/export policy is often referred to as symmetrical because all routes for each VN is exchanged between every other VN, creating a mesh.);and
running the mesh service, wherein the mesh service parses the DSL and generates one or more representational state transfer (REST) APIs that retrieve data from the plurality of service containers (¶0214 Each of API server 300A, controller 406A, custom API server 301A, and custom resource controller 302A includes code executable by microprocessor 1310. Custom API server 301A validates and configures data for custom resources for SDN architecture configuration (such as VNs 50 and VNRs 52). A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition. A service may be implemented in part as, or otherwise include, a load balancer. API server 300A and custom API server 301A may implement a Representational State Transfer (REST) interface to process REST operations and provide the frontend, as part of the configuration plane for an SDN architecture, to a corresponding cluster’s shared state stored to configuration store 1328. API server 300A may represent a Kubernetes API server).
Although not explicitly taught by Bahmeit, Bahl teaches in the analogous art of multi-cloud service mesh orchestration platform:
component comprises at least one of a Pod,a ReplicaSet, an Endpoint, an Ingress, a Service, or a Deployment for the mesh service (¶0062 An advantage of the multi-cloud service mesh orchestration platform 400, among others, is that all of the microservice containers 228 can look the same to clients, regardless of where the microservices are actually running. That is, it can be transparent to clients whether the multi-cloud service mesh is deployed in a single cloud or across multiple clouds. To achieve this behavior, a single logical control plane 402 can be used to manage all of the microservice containers 228. However, the single logical control plane 402 does not necessarily need to be a single physical control plane. For example, in other embodiments, the multi-cloud service mesh orchestration platform 400 can include multiple service mesh control planes that have replicated microservice and routing configurations in each participating cloud. ¶0078 In some embodiments, the request metering module 416 can invoke the logging or monitoring APIs of the CSPs (e.g., AWS CloudTrail®, Google Compute Engine™ Activity Logs, Microsoft Azure® Monitor, etc.) to obtain the request metrics. The APIs may be accessible as Restful State Transfer (REST) API endpoints. REST is a design pattern in which a server enables a client to access and interact with resources via Uniform Resource Identifiers (URIs) using a set of predefined stateless operations (referred to as endpoints). The APIs may also be accessible as SDKs for various programming languages or platforms, such as C++, Go, Java®, JavaScript®, Microsoft .NET®, Node.js, PHP: Hypertext Preprocessor (PHP), Python™ Ruby, and the like. Alternatively or in addition, the request metering module 416 can interface with the control plane 402, and in particular, the policy and telemetry hub 310 of the control plane 402, which can in turn interface with sidecar proxies (e.g., the ingress side car proxies 322 and/or the egress sidecar proxies 324) to obtain the request metrics.);
running the mesh service, wherein the mesh service parses the DSL and generates one or more representational state transfer (REST) APIs that retrieve data from the plurality of service containers (¶0078 In some embodiments, the request metering module 416 can invoke the logging or monitoring APIs of the CSPs (e.g., AWS CloudTrail®, Google Compute Engine™ Activity Logs, Microsoft Azure® Monitor, etc.) to obtain the request metrics. The APIs may be accessible as Restful State Transfer (REST) API endpoints. REST is a design pattern in which a server enables a client to access and interact with resources via Uniform Resource Identifiers (URIs) using a set of predefined stateless operations (referred to as endpoints). The APIs may also be accessible as SDKs for various programming languages or platforms, such as C++, Go, Java®, JavaScript®, Microsoft .NET®, Node.js, PHP: Hypertext Preprocessor (PHP), Python™ Ruby, and the like. Alternatively or in addition, the request metering module 416 can interface with the control plane 402, and in particular, the policy and telemetry hub 310 of the control plane 402, which can in turn interface with sidecar proxies (e.g., the ingress side car proxies 322 and/or the egress sidecar proxies 324) to obtain the request metrics. ¶0099 From the activity 504 or the activity 506, the workflow 500 can proceed to an activity 508 in which the multi-cloud service mesh orchestration platform can partition the service mesh application to be deployed or updated per the received request into the application's constituent components (e.g., layers, services, microservices, etc.). In this example, the platform can determine the microservice containers that make up the service mesh application. For instance, the multi-cloud service mesh orchestration platform can parse the application profile for E_APP to determine that the service mesh application comprises microservice containers E_APP_MICRSVC_1, E_APP_MICRSVC_2, . . . , and E_APP_MICRSVC_N. After the platform determines the constituent components of the service mesh platform, the workflow 500 can continue to an activity 510, an activity 512, and an activity 514 that the multi-cloud service mesh orchestration platform can perform for each microservice container to determine the various deployment and operational parameters of the individual components of the service mesh application. For example, at the activity 510, the multi-cloud service mesh orchestration platform can instantiate microservice configuration objects for each microservice container.).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the multi-cloud service mesh orchestration platform of Bahl with the system for user interface for cloud native software-defined network architectures of Bahmeit for the following reasons:
(1) a finding that there was some teaching, suggestion, or motivation, either in the references themselves or in the knowledge generally available to one of ordinary skill in the art, to modify the reference or to combine reference teachings, e.g. Bahmeit ¶0007 teaches that it is desirable to have VMs, containers, and bare metal servers coexist in the same computing environment with communication enabled among the diverse deployments of applications;
(2) a finding that there was reasonable expectation of success since the only difference between the claimed invention and the prior art being the lack of actual combination of the elements in a single prior art reference, e.g. Bahmeit teaches techniques are described for a creating a virtual network router via a user interface (UI) presented by a software defined network (SDN) architecture, and Bahl teaches a multi-cloud service mesh orchestration platform can receive a request to deploy an application as a service mesh application where the platform can tag the application with governance information and can partition the application into its constituent components and tag each with individual governance information; and
(3) whatever additional findings based on the Graham factual inquiries may be necessary, in view of the facts of the case under consideration, to explain a conclusion of obviousness, e.g. Bahmeit at least the above cited paragraphs, and Bahl at least the inclusively cited paragraphs.
Therefore, it would be obvious to one skilled in the art at the time of the invention to combine the multi-cloud service mesh orchestration platform of Bahl with the system for user interface for cloud native software-defined network architectures of Bahmeit. The rationale to support a conclusion that the claim would have been obvious is that "a person of ordinary skill in the art would have been motivated to combine the prior art to achieve the claimed invention and whether there would have been a reasonable expectation of success in doing so." DyStar Textilfarben GmbH & Co. Deutschland KG v. C.H. Patrick Co., 464 F.3d 1356, 1360, 80 USPQ2d 1641, 1645 (Fed. Cir. 2006). See MPEP 2143(G).
Bahmeit teaches:
Claim 2. The computer-implemented method of claim 1, wherein the input indicates a plurality of REST APIs of the plurality of service containers, and the computer-implemented method further comprises: outputting, to a user, data retrieved by the REST API (¶0214 Each of API server 300A, controller 406A, custom API server 301A, and custom resource controller 302A includes code executable by microprocessor 1310. Custom API server 301A validates and configures data for custom resources for SDN architecture configuration (such as VNs 50 and VNRs 52). A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition. A service may be implemented in part as, or otherwise include, a load balancer. API server 300A and custom API server 301A may implement a Representational State Transfer (REST) interface to process REST operations and provide the frontend, as part of the configuration plane for an SDN architecture, to a corresponding cluster’s shared state stored to configuration store 1328. API server 300A may represent a Kubernetes API server.).
Bahmeit teaches:
Claim 3. The computer-implemented method of claim 1, further comprising:validating the DSL in response to receiving the DSL, wherein the retrieving the container image is performed in response to a validation result indicating that the DSL is valid (¶0110 GUI 60 (via network controller 24) may iterate in this manner until VNR 52A has been successfully defined in a manner that achieves connectivity between VNs 50A and 50N. Network controller 24 may execute configuration node 30 to validate VNR 52A before invoking control node 32 to configure VNs 50A and 50N. Once successfully validated, control node 32 configures VNs 50A and 50N according to the one or more policies to enable one or more of the import and the export of routing information between VN 50A and VN 50N via VNR 52A ¶0214 Each of API server 300A, controller 406A, custom API server 301A, and custom resource controller 302A includes code executable by microprocessor 1310. Custom API server 301A validates and configures data for custom resources for SDN architecture configuration (such as VNs 50 and VNRs 52). A service may be an abstraction that defines a logical set of pods and the policy used to access the pods. The set of pods implementing a service are selected based on the service definition. A service may be implemented in part as, or otherwise include, a load balancer. API server 300A and custom API server 301A may implement a Representational State Transfer (REST) interface to process REST operations and provide the frontend, as part of the configuration plane for an SDN architecture, to a corresponding cluster’s shared state stored to configuration store 1328. API server 300A may represent a Kubernetes API server.).
Bahmeit teaches:
Claim 4. The computer-implemented method of claim 3, further comprising:translating the DSL to a service definition, wherein the retrieving the container image is performed based on the service definition (¶0098 In this respect, administrators may easily interconnect VNs 50 using the logical abstraction shown in the example of FIG.1 as VNRs 50, whereupon network controller 24 may translate VNRs 50 into underlying route targets to automatically (meaning with little or possibly without any human intervention) cause routing information for VNs 50A and 50N to be exchanged and enable communication (meaning, exchange of packets or other data) between VNs 50A and 50N.).
Bahmeit teaches:
Claim 5. The computer-implemented method of claim 1, wherein the retrieving the container image comprises retrieving the container image indicated in the input as a template (¶0196 Container engine 590 includes code executable by microprocessor 510. Container runtime 590 may be one or more computer processes. Container engine 590 runs containerized applications in the form of containers 529A–529B. Container engine 590 may represent a Dockert, rkt, or other container engine for managing containers. In general, container engine 590 receives requests and manages objects such as images, containers, networks, and volumes. An image is a template with instructions for creating a container. A container is an executable instance of an image. Based on directives from controller agent 592, container engine 590 may obtain images and instantiate them as executable containers in pods 502A–502B.).
Bahmeit teaches:
Claim 6. The computer-implemented method of claim 1, further comprising:receiving a resilience configuration file, wherein the retrieving the container image comprises retrieving the container image integrated with a resilience library; and applying a resilience strategy in based on the resilience configuration file and the resilience library (¶0123 For use cases involving an enterprise Kubernetes platform, high-performance cloud-native applications power financial services platforms, online gaming services, and hosted application service providers. The cloud platforms that deliver these applications must provide high performance, resilience against failures, with high security and visibility. The applications hosted on these platforms tend to be developed in-house. The application developers and platform owners work with the infrastructure teams to deploy and operate instances of the organization's applications. These applications tend to require high throughput (>20Gbps per server), and low latency. Some applications may also use multicast for signaling or payload traffic. Additional hardware, and network infrastructure may be leveraged to ensure availability. Applications and microservices will leverage namespaces within the cluster for partitioning).
Bahmeit teaches:
Claim 7. The computer-implemented method of claim 6, wherein the resilience configuration file indicates at least one of a circuit breaker instance, a rate limiter instance, a retry instance, anda bulkhead instance (¶0288 The virtual router 506 traps the ARP request and looks up the MAC address for IP-VM2 in its own forwarding tables and finds the association in the L2/L3 routes that the controller sent it for VM2. • The virtual router 506 sends an ARP reply to VM1 with the MAC address of VM2 • A TCP timeout occurs in the network stack of VM1 • The network stack of VM1 retries sending the packet, and this time finds the MAC address of VM2 in the ARP cache and can form an Ethernet frame and send it out. • The virtual router 506 looks up the MAC address for VM2 and finds an encapsulation route).
As per claims 8-14 and 15-20, the system and manufacture tracks the method of claims 1-7 and 1-6, respectively, resulting in substantially similar limitations. The same cited prior art and rationale of claims 1-7 and 1-6 are applied to claims 8-14 and 15-20, respectively. Bahmeit discloses that the embodiment may be found as a system and manufacture (Fig. 1 and ¶0018).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KURTIS GILLS whose telephone number is (571)270-3315. The examiner can normally be reached on M-F 8-5 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jerry O’Connor can be reached on 5712726787. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/KURTIS GILLS/Primary Examiner, Art Unit 3624
Prosecution Insights