DETAILED ACTION
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.
This Office Action is in response to the communication filed on 10/31/2023.
Claims 1-20 are pending for consideration.
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 .
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
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 14-18 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because claim 14 recites a system comprising an application control plane, microservice architecture application and an overall application function. These elements are defined by the applicant’s specification as being merely “software code running on a platform” (see paragraphs 0003-0004 and 0032-0033). Therefore, the system being claimed is software per se which does not fall under any of the statutory categories defined under § 101. Software per se is not a useful process, a machine, a manufacture, or a composition of matter. Therefore claim 14 and its dependent claims 15-18 are directed towards non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Kaimal et al. (U.S. 12,153,948)(hereinafter Kaimal) in view of Palladino et al. (U.S. 11,757,731)(hereinafter Palladino).
Regarding claim 1, Kaimal teaches receiving, by a service of the plurality of services, a request for access or utilization of the service (Kaimal: see Col 1 lines 40-42, "receiving a request at an endpoint for access to a first application remotely hosted on a network");
determining, by an open policy agent (OPA) module embedded in the data plane proxy, whether to authorize the request (Kaimal: see Col 30 lines 25-32, "As shown in step 810, the method 800 may include executing the executable form on a gateway for an enterprise network to manage user access to network locations and resources. For example, the executable form may be executed on a zero trust network access gateway to manage user access to an application for the enterprise network. The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation"); and
transmitting, based on the determining, a decision that authorizes or rejects the request (Kaimal: see Col 27 line 66-67 - Col 28 lines 1-9, "The gateway may also or instead evaluate a security policy for managing user access to the application, e.g., according to any security rules or policies maintained by a threat management facility associated with the user and/or application. The gateway may then grant the user access to application and redirect the browser to the application. In the event that a cookie has expired or there is some other session failure, the user/endpoint can be redirected once again to the identity provider in order to re-authenticate before permitting continued use of the application").
However, Kaimal does not teach a method of authorizing requests in a microservices architecture application comprising a plurality of services, each of the plurality of services being an application program interface (API) performing a piecemeal function of an overall application function and the service comprises a data plane proxy that is configured to perform at least one of routing, load balancing, authentication and authorization, service discovery, or health checking for the service.
Nevertheless, Palladino-which is in the same field of endeavor- teaches teach a method of authorizing requests in a microservices architecture application comprising a plurality of services, each of the plurality of services being an application program interface (API) performing a piecemeal function of an overall application function (Palladino: see Col 17 claim 1 lines 45-49, " establishing a microservice architecture application including a plurality of services, the plurality of services are each an application program interface (API) performing a piecemeal function of an overall application function") and the service comprises a data plane proxy that is configured to perform at least one of routing, load balancing, authentication and authorization, service discovery, or health checking for the service (Palladino: see Col 10 lines 11-14, "In a service mesh, the data plane proxy performs a number of tasks. Example tasks include service discovery, health checking, routing, load balancing, authentication and authorization, and observability").
Kaimal and Palladino are analogous art because they are from the same field of endeavor, API authorization and authentication in microservice architecture applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Kaimal’s use of an Open Policy Agent component with Palladino’s data plane proxy service. The suggestion/motivation for doing so would be centralize access control rules, promote consistent enforcement of policies and scalability.
Regarding claim 2, Kaimal and Palladino teach the service is comprised in a container (Kaimal: see Col 13 lines 12-21, "The compute instance may have one or more layers of containers. The compute instance may have one or more applications, which may be native applications, e.g., for a physical asset or virtual machine, or running in containers within a computing environment on a physical asset or virtual machine, and those applications may link libraries or other code or the like, e.g., for a user interface, cryptography, communications, device drivers, mathematical or analytical functions and so forth") and wherein the OPA module being embedded in the data plane proxy excludes an OPA sidecar service being deployed in the container (Kaimal: see Col 22 lines 13-19, "In embodiments, the gateway 210 may operate as a data plane element for the ZTNA system, and may handle traffic destined for protected resources 214 while facilitating user authentication for connecting to the resource (typically an application) as well as applying policies for authorizing such requests"; Col 30 lines 30-32, "The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation"). Motivation to combine Kaimal and Palladino in the instant claim, is the same as that in claim 1.
Regarding claim 3, Kaimal and Palladino teach the container is a virtual machine (Kaimal: see Col 2 lines 15-16, "The endpoint may be a virtual compute instance executing on a cloud computing platform"). Motivation to combine Kaimal and Palladino in the instant claim, is the same as that in claim 1.
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Kaimal and Palladino, as applied to claims 1-3 above, and in further view of Chandramouli et al. (Attribute-based Access Control for Microservices-based Applications using a Service Mesh) (Hereinafter Chandramouli).
Regarding claim 4, Kaimal and Palladino teach the invention detailed above.
However, Kaimal and Palladino fail to teach the container is a Kubernetes® pod.
Nevertheless, Chandramouli-which is in the same field of endeavor-teaches the container is a Kubernetes® pod (Chandramouli: see Section 2.1 Reference Platform for Orchestration and Resource Management of a Microservices-based Application, "The fundamental building blocks in a Kubernetes platform are: pod, node, cluster, and control plane components. A pod is the smallest object deployed, represents a set of running containers, and is identified by a label that is a name/value pair").
Kaimal, Palladino, and Chandramouli are analogous art because they are from the same field of endeavor, in microservice architecture applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize Kaimal and Palladino microservice architecture application within a Kubernetes® pod. The suggestion/motivation for doing so would be to provide dynamic and modular decision points as mandated by National Institute of Standards and Technology (NIST).
Claims 5-6, and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Kaimal and Palladino, as applied to claims 1-3 above, and in further view of Lippert et al. (U.S. 11,595,445)(hereinafter Lippert).
Regarding claim 5, Kaimal and Palladino teach the invention detailed above.
However, Kaimal and Palladino fail to teach the OPA module is configured to perform API authorization.
Nevertheless, Lippert-which is in the same field of endeavor- teaches the OPA module is configured to perform API authorization (Lippert: see Col 9 lines 61-64, "With continued reference to FIG. 3, the application container 302 includes an application 320 and an authorization decision controller (ADC) 322 (e.g., an open policy agent (OPA))"; Col 17 lines 49-51, "If an access request has been made, a policy decision is determined at the ADC (414). The policy decision is enforced by the application instance (416)").
Kaimal, Palladino, and Lippert are analogous art because they are from the same field of endeavor, in microservice architecture applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize the API authorization of Lippert with Kaimal’s OPA module. The suggestion/motivation for doing so would be to centralize authorization and promote consistency in policy evaluation.
Regarding claim 6, Kaimal, Palladino, and Lippert teach the data plane proxy of each of the plurality of services is communicatively coupled to an application control plane (Palladino: see Fig. 7 items 706 and 708; Col 10 lines 53-57, "The control plane core 706 serves as a central point that other control plane services operate through in connection with the data plane proxies 708. Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane"). Motivation to combine Kaimal, Palladino, and Lippert in the instant claim, is the same as that in claim 5.
Regarding claim 11, Kaimal, Palladino, and Lippert teach the decision is transmitted to the application control plane (Lippert: see Col 17 lines 48-54, "If an access request has not been made, the example process 400 loops back. If an access request has been made, a policy decision is determined at the ADC (414). The policy decision is enforced by the application instance (416). For example, at least one policy decision is received by the instance of the application from the ADC, and enforces the at least one policy based on the policy decision"). Motivation to combine Kaimal, Palladino, and Lippert in the instant claim, is the same as that in claim 5.
Claims 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Kaimal, Palladino and Lippert, as applied to claims 5-6 and 11 above, and in further view of Chandramouli as applied to claim 4 above.
Regarding claim 7, Kaimal, Palladino, and Lippert teach the invention detailed above.
However, Kaimal, Palladino, and Lippert fail to teach the application control plane is configured to apply a default policy for the OPA module in the data plane proxy of each of the plurality of services upon establishment of the microservice architecture application.
Nevertheless, Chandarmouli-which is the same field of endeavor-teaches the application control plane (Chandramouli: see Section 4 - Authentication and Authorization Policy Configuration in Service Mesh, "Fine-grained access control for microservices can be enforced through the configuration of authentication and access control policies. These policies are defined in the control plane of the service mesh, mapped into low-level configurations, and pushed into the sidecar proxies that form the data plane of the service mesh") is configured to apply a default policy (Chandramouli: see Section 4.6.6 Default Authorization Policy, "A default policy should be authored in the system that rejects all requests that are unauthenticated, mandates that service and end-user credentials be present on every request, restricts all communication to services within the application’s own namespace, and allows service communication across namespaces only through an explicit policy") for the OPA module in the data plane proxy of each of the plurality of services upon establishment of the microservice architecture application Kaimal: see Col 22 lines 13-19, "In embodiments, the gateway 210 may operate as a data plane element for the ZTNA system, and may handle traffic destined for protected resources 214 while facilitating user authentication for connecting to the resource (typically an application) as well as applying policies for authorizing such requests"; Col 30 lines 30-32, "The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation").
Kaimal, Palladino, Lippert, and Chandramouli are analogous art because they are from the same field of endeavor, securing microservice applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize the default policy of Chandramouli with the authorization system of Kaimal, Palladino, and Lippert. The suggestion/motivation for doing so would be to provide a base or fail-safe protection for services that may not have defined policies.
Regarding claim 8, Kaimal, Palladino, Lippert, and Chandramouli teach the default policy comprises standardized authentication and authorization rules (Chandramouli: see Section 4.6.6 Default Authorization Policy, "A default policy should be authored in the system that rejects all requests that are unauthenticated, mandates that service and end-user credentials be present on every request, restricts all communication to services within the application’s own namespace, and allows service communication across namespaces only through an explicit policy"; Section 4.3 Higher-level Security Configuration Parameters for Applications, "AHLC-SR-3: Configure the container file system as read-only by default for all applications, overriding only when the underlying application (e.g., database) must write to disk..."). Motivation to combine Kaimal, Palladino, Lippert, and Chandramouli in the instant claim, is the same as that in claim 7.
Regarding claim 9, Kaimal, Palladino, Lippert and Chandramouli teach receiving, upon establishment of the microservice architecture application (Chandramouli: see Section 1.1 Service Mesh Capabilities, “Second, modern implementations (e.g., Istio) allow for dynamic configuration. It is easy to update policies, and updates take effect nearly immediately and without having to redeploy applications”; Section 4 Introduction, “These policies are defined in the control plane of the service mesh, mapped into low-level configurations, and pushed into the sidecar proxies that form the data plane of the service mesh”), a default policy (Chandramouli: see Section 4.6.6 Default Authorization Policy, "A default policy should be authored in the system that rejects all requests that are unauthenticated, mandates that service and end-user credentials be present on every request, restricts all communication to services within the application’s own namespace, and allows service communication across namespaces only through an explicit policy") for the OPA module (Chandramouli: see Section 4.2 Service Mesh Configuration, “It must be mentioned that agents (e.g., OPA) can sometimes be used to play the role of PDPs for the authorization service”) from the application control plane; and installing the default policy on the OPA module (Chandramouli: see Section 4.2 Service Mesh Configuration, “A control plane module in the service mesh that monitors configuration data in the hosting platform, encodes policies, and distributes those policies in the form of configuration to various proxies in the mesh (e.g., ingress, sidecar, and egress”; “These sidecar proxies enforce authentication and authorization policies during application runtime, thus acting as Policy Enforcement Points (PEPs)” ). Motivation to combine Kaimal, Palladino, Lippert, and Chandramouli in the instant claim, is the same as that in claim 7.
Regarding claim 10, Kaimal, Palladino, Lippert, and Chandramouli teach receiving, from the application control plane application (Chandramouli: see Section 1.1 Service Mesh Capabilities, “Second, modern implementations (e.g., Istio) allow for dynamic configuration. It is easy to update policies, and updates take effect nearly immediately and without having to redeploy applications”), a custom policy configuration for the OPA module (Chandramouli: see Section 4.2 Service Mesh Configuration, “It must be mentioned that agents (e.g., OPA) can sometimes be used to play the role of PDPs for the authorization service”) that is different from the default policy; and replacing the default policy with the custom policy configuration module (Chandramouli: see Section 4.2 Service Mesh Configuration, “A control plane module in the service mesh that monitors configuration data in the hosting platform, encodes policies, and distributes those policies in the form of configuration to various proxies in the mesh (e.g., ingress, sidecar, and egress”; “These sidecar proxies enforce authentication and authorization policies during application runtime, thus acting as Policy Enforcement Points (PEPs)” ). Motivation to combine Kaimal, Palladino, Lippert, and Chandramouli in the instant claim, is the same as that in claim 7.
Claims 14 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Kaimal, Palladino, and in further view of Open Policy Agent, December 2022, (hereinafter OPA).
Regarding claims 14 and 19, Kaimal teaches the data plane proxy comprises an embedded software module that is configured to determine whether to authorize the request (Kaimal: see Col 22 lines 13-19, "In embodiments, the gateway 210 may operate as a data plane element for the ZTNA system, and may handle traffic destined for protected resources 214 while facilitating user authentication for connecting to the resource (typically an application) as well as applying policies for authorizing such requests"; Col 30 lines 30-32, "The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation");
a decision authorizes or rejects the request (Kaimal: see Col 27 line 66-67 - Col 28 lines 1-9, "The gateway may also or instead evaluate a security policy for managing user access to the application, e.g., according to any security rules or policies maintained by a threat management facility associated with the user and/or application. The gateway may then grant the user access to application and redirect the browser to the application").
Palladino teaches an application control plane (Palladino: see Fig. 7 item 706) and a microservice architecture application comprising a plurality of services that interact to perform an overall application function, each of the plurality of services being an application program interface (API) performing a piecemeal function of the overall application function, wherein a service of the plurality of services (Palladino: see Col 17 claim 1 lines 45-49, " establishing a microservice architecture application including a plurality of services, the plurality of services are each an application program interface (API) performing a piecemeal function of an overall application function") comprises a data plane proxy that is communicatively coupled to the application control plane (Palladino: see Fig. 7 items 706 and 708; Col 10 lines 53-57, "The control plane core 706 serves as a central point that other control plane services operate through in connection with the data plane proxies 708. Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane");
wherein the application control plane is configured to receive, from the data plane proxy (Palladino: see Col 10 lines 53-57, "The control plane core 706 serves as a central point that other control plane services operate through in connection with the data plane proxies 708. Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane"; Col 10 lines 60-66, "control plane services may include global system configuration settings such as deploy control 710 (blue/green and/or traffic shifting), authentication and authorization settings 712, route table specification 714 (e.g., when service A requests a command, what happens), load balancer settings 716 (e.g., timeouts, retries, circuit breakers, etc.), a workload scheduler 718, and a service discovery system 720"),
However, Kaimal and Palladino fail to teach the service is configured to receive (a) a request for access or utilization of the service and (b) a token associated with the request.
Nevertheless, OPA-which is in the same field of endeavor- teaches the service is configured to receive (a) a request for access or utilization of the service and (b) a token associated with the request (OPA: see External Data - Option 1: JWT Tokens - Flow, "The user provides that JWT token to an OPA-enabled software system for authentication. The OPA-enabled software system includes that token as part of the usual input to OPA").
Kaimal, Palladino, and OPA are analogous art because they are from the same field of endeavor, policy evaluation in microservice applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize the functions of OPA within Kaimal and Palladino OPA module. The suggestion/motivation for doing so would be to utilize existing technologies that are inherent to the module to solve technical problems.
Claims 12-13, 15-17, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Kaimal, Palladino, and OPA, as applied to claims 14 and 19 above, and in further view of Sandall et al. (U.S. 12,032,567)(hereinafter Sandall).
Regarding claim 12, 15, and 20, Kaimal, Palladino, and OPA teach the request is associated with a token (OPA: see External Data - Option 1: JWT Tokens - Flow, "The user provides that JWT token to an OPA-enabled software system for authentication. The OPA-enabled software system includes that token as part of the usual input to OPA").
However, Kaimal, Palladino, and OPA fail to teach the OPA module comprises a policy engine, an authorization database, and a policy database, and wherein the determining comprises: selecting one or more entries in the authorization database that correspond to one or more values in the token; and generating the decision based on applying a policy in the policy database to the one or more values and the one or more authorization entries.
Nevertheless, Sandall-which is in the same field of endeavor- teaches the OPA module (Sandall: see Figure 1A item 120; Col 3 lines 49-52, " The method is performed by a policy agent (e.g., OPA) that executes on a host computer to authorize API calls made to at least one application executing on the host computer") comprises a policy engine (Sandall: see Col 5 lines 38-42, " For example, some embodiments utilize open policy agents (OPAs), which are open source, general-purpose policy engines for enforcing policies in micro-services, Kubernetes, Cl/DC pipelines, API gateways, etc"), an authorization database, and a policy database (Sandall: see Col 6 lines 44-48, " the server set in some embodiments stores the defined API-authorization policies, and collected parameters needed to resolve these policies, in a single hierarchical storage structure (such as a namespace) that can be accessed as a single runtime storage construct"), and wherein the determining comprises: selecting one or more entries in the authorization database that correspond to one or more values in the token (Sandall: see Col 5 lines 25-30, "In this example, the local agent 120 uses a local namespace portion 125 as a local policy and data storage. This namespace contains both (1) policy opcodes to evaluate API calls to determine whether they should be authorized, and (2) operands to use to evaluate and resolve the opcodes"); and generating the decision based on applying a policy in the policy database to the one or more values and the one or more authorization entries (Sandall: see Col 5 lines 36-38, "The local policy agent 120, in some embodiments, is a general-purpose policy engine that decouples policy decision-making from policy enforcement"; Col 8 lines 23-27, "In some embodiments, after retrieving the policy opcode and one or more associated operands, the fetcher 115 directs the rule compiler 130 to create a more optimal runtime rule and parameter structure 135 for the evaluation engine to process"; Col 8 lines 45-59, "Once the rule compiler creates the more optimal rule structure, it notifies the evaluation engine 110 directly, in some embodiments, or through the fetcher 115. The evaluation engine then processes the rules and/or indices in this rule structure, according to some embodiments. In some embodiments, the evaluation engine uses the parameters retrieved from the namespace and/or received with the API request to resolve these rules (e.g., conditions specified by the rules). In some embodiments, after processing the rule structure, the evaluation engine 110 provides its decision with respect to the API call (i.e., the “authorization” or “rejection” of the API call) to the handler 105, which formulates an RPC reply message with this decision in its payload and sends this reply message to the application that sent the request”).
Kaimal, Palladino, OPA, and Sandall are analogous art because they are from the same field of endeavor, policy evaluation in microservice applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize existing policy evaluations such as Kaimal, OPA and Sandal’s OPA modules/functions with the service of Palladino. The suggestion/motivation for doing so would be to design a scalable authorization system that does not require embedding permissions in a token and decreases duplicating permissions across services.
Regarding claim 13, Kaimal, Palladino, OPA and Sandall teach a format of the request, the one or more entries, (OPA: see Rest API - Data API - Get a Document - "input - Provide an input document. Format is a JSON value that will be used as the value for the input document"; Get a Document (with Input) - "Content-Type: application/json", Request Headers: "Content-Type: application/x-yaml: Indicates the request body is a YAML encoded object"), and the decision is a JavaScript Object Notation (JSON) format (see OPA: Integrating OPA - Evaluating Policies, "OPA supports different ways to evaluate policies. The REST API returns decisions as JSON over HTTP”), wherein the policy is formatted using REGO (OPA: see Introduction - Rego, "OPA policies are expressed in a high-level declarative language called Rego. Rego (pronounced “ray-go”) is purpose-built for expressing policies over complex hierarchical data structures"), and wherein the token is a JSON Web Token (JWT) (OPA: see External Data - Option 1: JWT Tokens - Flow, "The user provides that JWT token to an OPA-enabled software system for authentication. The OPA-enabled software system includes that token as part of the usual input to OPA. OPA decodes the JWT token and uses the contents to make policy decisions"). Motivation to combine Kaimal, Palladino, OPA, and Sandall in the instant claim, is the same as that in claim 12.
Regarding claim 16, Kaimal, Palladino, OPA and Sandall teach the service is comprised in a container (Kaimal: see Col 13 lines 12-21, "The compute instance may have one or more layers of containers. The compute instance may have one or more applications, which may be native applications, e.g., for a physical asset or virtual machine, or running in containers within a computing environment on a physical asset or virtual machine, and those applications may link libraries or other code or the like, e.g., for a user interface, cryptography, communications, device drivers, mathematical or analytical functions and so forth"), and wherein the OPA module being embedded in the data plane proxy excludes an OPA sidecar service being deployed in the container (Kaimal: see Col 22 lines 13-19, "In embodiments, the gateway 210 may operate as a data plane element for the ZTNA system, and may handle traffic destined for protected resources 214 while facilitating user authentication for connecting to the resource (typically an application) as well as applying policies for authorizing such requests"; Col 30 lines 30-32, "The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation"). Motivation to combine Kaimal, Palladino, OPA, and Sandall in the instant claim, is the same as that in claim 12.
Regarding claim 17, Kaimal, Palladino, OPA and Sandall teach the container is a virtual machine or a Kubernetes® pod (Kaimal: see Col 2 lines 15-16, "The endpoint may be a virtual compute instance executing on a cloud computing platform"). Motivation to combine Kaimal, Palladino, OPA, and Sandall in the instant claim, is the same as that in claim 12.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Kaimal, Palladino, and OPA, as applied to claims 14 and 19 above, and in further view of Chandramouli as applied to claims 7 and 8 above.
Regarding claim 18, Kaimal, Palladino, and OPA teach the invention detailed above.
However, Kaimal, Palladino, and OPA fail to teach the application control plane is further configured to apply a default policy for the embedded software module in the data plane proxy of each of the plurality of services upon establishment of the microservice architecture application.
Nevertheless, Chandarmouli-which is the same field of endeavor-teaches the application control plane (Chandramouli: see Section 4 - Authentication and Authorization Policy Configuration in Service Mesh, "Fine-grained access control for microservices can be enforced through the configuration of authentication and access control policies. These policies are defined in the control plane of the service mesh, mapped into low-level configurations, and pushed into the sidecar proxies that form the data plane of the service mesh") is configured to apply a default policy (Chandramouli: see Section 4.6.6 Default Authorization Policy, "A default policy should be authored in the system that rejects all requests that are unauthenticated, mandates that service and end-user credentials be present on every request, restricts all communication to services within the application’s own namespace, and allows service communication across namespaces only through an explicit policy") for the embedded software module in the data plane proxy of each of the plurality of services upon establishment of the microservice architecture application (Kaimal: see Col 22 lines 13-19, "In embodiments, the gateway 210 may operate as a data plane element for the ZTNA system, and may handle traffic destined for protected resources 214 while facilitating user authentication for connecting to the resource (typically an application) as well as applying policies for authorizing such requests"; Col 30 lines 30-32, "The gateway may have an Open Policy Agent (OPA) component responsible for policy evaluation").
Kaimal, Palladino, OPA, and Chandramouli are analogous art because they are from the same field of endeavor, securing microservice applications. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art to utilize the default policy of Chandramouli with the authorization system of Kaimal, Palladino, and OPA. The suggestion/motivation for doing so would be to provide a base or fail-safe protection for services that may not have defined policies.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KELAH JANAE MCFARLAND-BARNES whose telephone number is (571)272-5953. The examiner can normally be reached Monday through Friday 8:00am until 4:00pm Central Time.
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, Lynn D Feild can be reached at 571-272-2092. 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.
/KELAH JANAE MCFARLAND-BARNES/Examiner, Art Unit 2431
/TRANG T DOAN/Primary Examiner, Art Unit 2431